Exploitation

Welcome back to Security Misconfiguration session. In this second part, we will review some security misconfigurations we have already found in previous hands-on exploitations. We will jump straight to our intentionally vulnerable application and then move to the mitigation part. In our first session, we exploited the SQL injection vulnerability in the login form. At that time, we also found the security misconfiguration, but we didn’t give it too much attention. Let’s do it now.

As in our first session, submitting our payload returned an internal server error response. Let’s check the response body.

We got the JSON object, which we will copy to our text editor so that we can read it easily.

The return JSON has a single top level property called error, which includes several other properties and values that we will carefully analyze to compile information about our target system.

Starting with the message property, we see that the error was triggered by the database engine, which we now know that is a SQLite.

Let’s keep track of system knowledge we get from this error message.

The syntax error happens near this string, which is not something we have submitted. In fact, it looks like a hash. We will find several hash algorithm detectors online. Let’s try one of them.

So we now know that passwords are hashed using the MD5 algorithm.

Next, we have stack trace. Stack traces give us a few execution steps immediately before an exception has occurred.

In this case, based on the called script path, we know the application location in the file system.

We also know the application is written in Node.JS based on the node_modules folder in the path.

In the same way we know that implementation uses the npm sequelized package.

Continuing through the JSON error object, we can even find the exact SQL queries sent to the database, and now, we also know that there’s a users table which has at least three fields– email, password, and deletedAt.

There are other implementation details we may assume based on the error message. For instance, because of the deleteAt table field, user accounts shall not be really deleted, but instead soft deleted or flagged as deleted.

In our XML external entities session, XXE exploitation was only possible due to a security misconfiguration. Let’s check it.

While authenticated as a regular user, we have access to the Complain feature, which allows invoice uploads. We used it before to upload our malicious XML file.

This business-to-business feature has been deprecated, but the upload and the XML processing is still possible. Next, we will discuss what makes the application vulnerable and how to prevent it.