Wizer CTF #19: Calculator

Link to challenge: CTF #19

Goal

In this challenge, we're identifying a tricky Code Injection vulnerability.

Description of code

The code below showcases a simple calculator endpoint. The developer figured this would be safer than just using eval because they read about scopes in JavaScript and noticed that Function() runs in a different scope. Today we prove that it's not safer at all! A requirement of the feature was to allow the consumers of the endpoint to take advantage of the `mathjs` library to enable calculations such as `100 + Math.sqrt(1000)`. To achieve that, the developer provided `require` as an external argument to the scope so that the isolated scope is able to run the following calculation: `100 + argument[0]('mathjs').sqrt(1000)`.

What’s wrong with that approach?

The `require` argument can be misused to import libraries which will provide unauthorized access to data/files and assets.

What would a successful Command Injection attack look like in this case?

An attacker could use the `require` argument to import the `fs` library and read the contents of any file including `/etc/passwd`. Dynamically requiring the `fs` library, makes functions like `readFileSync('[path]')` accessible.

So what?

Code Injection is an extremely dangerous vulnerability, once an attacker gains access to execute any code and basically any library by controlling user-input, the range of opportunities is broad starting from reading secret keys, through server and infrastructure take over.

Main Takeaways:

• Never use `eval` nor `String(Function())` involving user input:
  Avoid the use of `eval` and Function constructors with user input. If you must use them, make sure that the input is sanitized and validated. In this case for instance, assuming we had to provide access to `mathjs`, it could have been sent as an argument instead of the wildcard `require` argument, which was likely provided as part of potential future functionality. Yet, even if the `require` argument was completely absent, the `String(Function())` approach is still vulnerable to code injection and there are ways to bypass the need to use `require` and still import general functionality into the isolated scope.
• Never skip user-input sanitization:
  Always validate and sanitize user input. In this case, the developer could have used a whitelist of allowed functions and arguments to prevent the injection of malicious code.
• Apply a least privilege approach upon deployment of the code:
  Make sure that the code is running with the least amount of privileges possible. In this case, the code could have been running in a container with limited access to the host machine. If you aren't the guy who's responsible for the deployment, make sure to communicate the potential risks to the person who is.

Code Wizer!