Automated systems often generate graphical user interfaces, applications, and websites that describe a project. For project number four, submitted to Sir Shahzaib Ali on April 7th, 2023, the topic is SQL injection to bypass web application firewalls (WAFs).

In particular, WAFs protect web-based applications and APIs from malicious external HTTP traffic that includes cross-site scripting and SQL injection attacks. Although WAFs function as a defense for web applications, they are still vulnerable to different techniques that attackers can use to bypass them.

SQL injection is a prevalent type of attack that WAFs encounter frequently. While WAFs were initially created for web application security in the early 2000s, organizations currently use them to protect their data. As such, WAFs are considered an essential defense mechanism for applications and securing various information types stored in server databases. Additionally, WAFs are increasingly used to protect cloud-based management platforms connected to embedded systems, including routers and other devices.

Attackers using this innovative approach to bypass WAFs should know how WAFs identify and mark SQL syntax as dangerous. Attackers can then locate SQL syntax that WAFs are not aware of. Exploiting different vulnerabilities and exploits, the attackers may gain access to databases and exfiltrate data via server access or cloud-based platforms.

This project aims to bypass WAF to retrieve sensitive data stored in the database. However, a WAF system analysis revealed several limitations that could be exploited to bypass the firewall:

1. Only integers can be retrieved as returned rows.

2. Returned rows are random in order.

3. Only a limited number of rows can be returned in each request.

To overcome the first restriction, we had to return integers (since the initial request returned integers). However, the data that we aim to extract, such as login tokens or SSH keys, is almost always strings. Therefore, we cast the desired string to an integer array using SQL functions such as (string_to_array) and (ASCII) to extract each character as a separate row.

The second limitation specifies that the http server would return multiple rows in random order. To bypass this constraint, we added a row index through the row number SQL function, which transforms the character's index number to the returned integer. We then attach the index number multiplied by a thousand (I * 1000) to the result. This helps ensure that the character order is maintained, despite the asynchronous activities responsible for the randomized row orders.

After retrieving the exfiltrated data, we split each returned row by 1,000 to determine the character index. Using the modulus operation on the result, we can also retrieve the actual character ASCII value. By using these methods to bypass WAFs, we can gain access to the sensitive data stored in databases.

The third limitation to our extraction process is the inability to return a large number of rows in one request. This is due to a timeout issue where the server can't handle the extra operations required for each returned record, along with additional SQL queries and data processing. To compound this issue, the API endpoint is slow which makes fetching one record at a time unfeasible.

Our solution to this problem is to create an integer from multiple rows instead of returning one row for each character. This is possible due to the differences in byte size between integers and characters. An integer in PostgreSQL is four bytes long, while the character we need to exfiltrate is only one byte long (if we are referring to ascii characters). Therefore, we can store four distinct characters in each integer by performing basic byte operations. We can even increase each entry to eight bytes by casting our integer into a BIGINT in our union statement, which is available in PostgreSQL.

By attaching eight bytes to each character and exfiltrating it to a BIGINT, we can extract seven times more characters in each request (with one byte reserved for the character index). Using this technique, we can easily exfiltrate up to eight times more data in each request, reducing the time it takes to extract meaningful data and making the exploitation scenario possible.

To construct our payload, we combined the solutions to our three limitations into one big payload that can extract any data we want. When we used this payload, we managed to exfiltrate sensitive information from the server, ranging from session cookies to tokens, SSH keys, and hashed passwords.

In conclusion, we have found that new techniques and technology can bypass WAFs and extract information from cloud vendor servers. WAF bypass is a tool that can be used to gain access to stored data.