SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with an application’s queries that makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to the other users, or any other data that the application itself can access. In many cases, an attacker can modify or delete this data causing persistent changes to the application’s content or behavior.
It is one of the most common vulnerabilities in web penetration testing. The tools that we used to exploit SQLi are SQLMap, Burp Suite, and online tools. Here, we tried to automated the injection and came across a few problems on the journey. Before addressing the problems, let’s look at the scenario.
About The Application:
The application that we are up against is a portal to deal with suppliers and vendors. Which has various functionalities such as details of suppliers/vendors. Additionally, the creation, modification, deletion, approval, and rejection of tickets generated by other users over an issue, they(supplier/vendors) face during the course of action.
SCENARIO:
A web application has a table displaying the issues raised by the other users and it has search functionality. Hence, we begin with searching for the issues raised by a specific user’s SSOID that contains 175, and the issues raised by that particular user are returned (Figure 1).
Figure 1
To test, we entered 175’ and it returned no result. Concerning this, we now suspect a possible SQL injection. Subsequently, we tried to balance the query with a “- -” (double-dashed comment) i.e., 175’- –. Due to this, we successfully got the result of the user. Out of all this, we identified that SQL injection is possible.
For further confirmation, we injected a Boolean-based payload. First, we injected a query that returns ‘FALSE’ i.e., 175’ AND 1=2–. The data is not returned (indicating that the web application is vulnerable to SQL injection) as shown in Figure 2.
Figure 2
Later, we injected a query that returns ‘TRUE’ i.e., 175’ AND 1=1–. Thence, we got the result of the user (Figure 3).
Figure 3
To automate the exploitation, we are going to use SQLmap. With the help of Burp Suit, we intercepted the request and figured that the request body is getting encrypted. As the request body is encrypted, we can’t just use SQLmap. To achieve this, we need to decrypt the encryption. As encryption is done on the client side, we looked for the key in the .js file and we found the key in the aes.js file. Looking at the internet, we realized that the developer must have replicated the publicly available code from the internet and didn’t change the key. To make SQLmap work explicitly, we’ve added a parameter. (e.g., itest=QWERTYUIOP==)
As we now have the key. We decrypted the encryption using an online tool and we got the request body in plain text.
To get SQLmap to work, we need to decrypt and then encrypt the request body as the server only understands the encrypted data. Now to analyze the response which is again encrypted, we need to decrypt it. Hence, we came up with an optimized solution! we created a tamper script that crafts the query with a payload from an already decrypted query and encrypts the whole request body.
We explicitly told SQLmap to use only Time-Based Queries to analyze the received data. By this, the complexity of the decryption of the response body reduces. After SQLmap encrypts the request body it looks like this “itest=QWERTYUIOP==”. Since the server only understands this form “QWERTYUIOP==” we made Burp Suite a middleman and removed “itest=” using its feature Match & Replace.
In the above scenario, the problems faced during the process are addressed below:
A. Request Body gets encrypted so can’t use tools like SQLmap directly for the exploitation of SQLi. Need to find the key as encryption is done on the client side.
To decrypt the encrypted data, a key is required. We analyzed all the .js files. We found out they are using AES with EBC cipher mode. We found the key but it was encoded in Base64 format. With the help of online tools or Burp suit’s Decoder, we’ve attained the cipher key.
B. Request format for SQLmap differs from the Server acceptance format.
The legitimate request body format for a server is (e.g., QMBCIIOJKLMNBVCZAQWER==). However, SQLmap only understands parameter value (e.g., Q=” Ownux”) to execute the SQL injection. Hence, we need to explicitly add “Q=” before it.
C. We Need to decrypt the request body before sending it to SQLmap.
Theoretically, for successful exploitation, we need to decrypt the data and send it to the SQLmap. Later, SQLmap will insert payload and we need to encrypt the data before sending it to the server. For SQLmap to analyze the response, we must decrypt the encrypted response again.
D. Need to Encrypt the data with a payload before sending it to the server.
An optimized solution has been found. Instead of decrypting the request and response, we wrote a script that crafts the query with payload from an already decrypted query and then encrypted it using the SQLmap’s Tamper functionality. Now comes the data exfiltration which also requires decryption, instead we explicitly told the SQLmap to run only Time-Based queries.
E. Make the request in a server-acceptable format.
Now after the request data is encrypted using SQLmap which is in the format of (e.g., Q=QMBCIIOJKLMNBVCZAQWER==). On the other hand, the server only accepts encrypted data (e.g., QMBCIIOJKLMNBVCZAQWER==). To convert the request, we used Burp suite’s match & replace functionality where we defined the rule like this:
Find: “Q=”
Replace: <none>
by this, the request would look from this “Q=QMBCIIOJKLMNBVCZAQWER==” to this “QMBCIIOJKLMNBVCZAQWER==” which is in a server acceptable format.
TO SUM UP:
A few of the problems faced through the process are encryption of the request body which makes the process of exploiting SQLi harder, and so on. In a quest to find the solutions to the problems, we found out that SQL injection is possible and retrieved the data of the user using a Boolean-based payload injection. To automate this, we wrote a tamper script that is compatible with the application’s environment. And that’s how we were able to automate the SQL injection by bypassing client-side encryption.