Wizer CTF #33: Get my profile

Link to challenge: CTF #33

Goal

In this challenge, we're exploring an Insecure Deserialization vulnerability. Let's dive in!

Description of code

The code in this challenge showcases the handling of a profile object, which has been Base64 encoded to make it easily transferable between platforms. The `/getMyName` endpoint parses the profile and deserializes it into an object. Once that's done, it extracts the name out of it. You can imagine that there could have been other fields on that object which are handled in the same way.

What’s wrong with that approach?

The issue with the approach is that deserializing user inputs can be dangerous, more specifically if we're using a library which has the ability to deserialize functional elements and not only data. This means that an attacker could potentially send a maliciously crafted profile object that could lead to code execution on the server.

What would a successful Insecure Deserialization attack look like?

In an Insecure Deserialization attack, an attacker can exploit vulnerabilities by sending a maliciously crafted serialized object that executes code on the server upon deserialization. Here, the attacker could leverage the name field to transmit a serialized object containing executable code.
In this scenario, the node-serialize library is known to be vulnerable to insecure deserialization, making it susceptible to such attacks. Take a look at the following example Node.JS - 'node-serialize' Remote Code Execution. Crafting a payload with executable functionality, an attacker could run commands directly on the server. For instance, a payload like this:
`{"name":"_$$ND_FUNC$$_function (){require('child_process').exec('ls', function(error, stdout, stderr) {console.log(stdout)})()"}`
Would execute the ls command on the server, logging the directory contents back into the `name` field.
Could you craft a payload that would send the content of `etc/hosts` file back to you?
Remember, the payload should be Base64 encoded before being sent as part of the profile object! This encoding ensures it’s properly transmitted and recognized by the server during deserialization.

So what?

Insecure Deserialization vulnerabilities can have severe consequences, as they allow attackers to execute arbitrary code on the server. This can lead to a range of attacks, from data exfiltration to full server compromise. In this case, an attacker could exploit the deserialization of the profile object to execute arbitrary commands on the server, potentially leading to data theft, server compromise, or other malicious activities. It's crucial to be aware of the risks associated with deserializing user input and to implement proper security measures to prevent such attacks.

Main Takeaways:

• Be on the lookout for Insecure Deserialization vulnerabilities in any 3rd party libraries you're using:
  When adding a library to your code, always read about its known vulnerabilities. If you're using package managers like `npm`, review the vulnerability report produced by the tool upon installing a library. In this case, the node-serialize library is known to be vulnerable to insecure deserialization, which can lead to code execution on the server.
• Avoid deserializing user inputs:
  Deserializing user inputs can introduce security risks, especially if the input contains executable code. In this challenge, the server deserializes the profile object sent by the user, which could be exploited by an attacker to execute arbitrary commands on the server. To mitigate this risk, avoid deserializing untrusted user inputs and implement proper input validation and sanitization mechanisms.
• Always minimize the app service permissions to the bare minimum:
  Limit the permissions of your application to the minimum required for its functionality. By reducing the scope of permissions, you can mitigate the impact of potential attacks. In this case, restricting the access of the process running the app to only essential resources, can help prevent attackers from executing arbitrary commands on the server or gaining access to files outside of the scope of the app.

Code Wizer!