Grep in PHP
Introduction
It is a common misconception that companies need to purchase complicated and expensive software to find security vulnerabilities (bugs) within their applications.
These specialized software applications, whether they be black box or white box, Open Source or commercial, do make the process of finding security vulnerabilities easier and in some cases quicker.
The truth is, all of these specialized vulnerability scanning tools have their particular strengths and weaknesses. Some may be ASP based whereas others more geared towards PHP.
The development team may have taken the decision to limit requests in order to improve speed, they may not check for vulnerabilities which they deem unworthy to be reported. If you want to find as many security vulnerabilities as possible within a certain time frame you need to use all of the tools at your disposal.
No vulnerability scanner or technique is going to find 100% of the vulnerabilities which may affect your web application. Even if you use every tool and technique at your disposal, and buy it cupcakes, software is never perfect.
In this article I will introduce you to one more way you can hunt down those bugs very quickly by just using the command line tool: grep.
Black Box and White Box
Lets take a step back and clarify the white, grey or black box concept.
A black box assessment is where you have no prior knowledge of the application, network or company you are assessing.
A white box assessment is completely the opposite. You may have any information that you require to make your job easier. This may include network ranges, source code, phone numbers, etc..
A grey box assessment is somewhere in between. In reality, most assessments are grey box assessments. It is rare you either have no prior knowledge or all the knowledge you need.
Grepping for bugs would be classified as a white box assessment or source code review. A web application vulnerability scanner such as Netsparker, Nikto, Acunetix, w3af and others would be classified as black box tools as in most cases they will not have access to any server side source code.
If you want to find as many security vulnerabilities as possible, a mixture of black box Web application assessment tools or techniques and a white box source code review should be employed.
Grep
If you are reading this article I would imagine you are familiar with the basic concepts of the grep tool. But if you are not familiar, here is a brief introduction to such a powerful utility.
Grep was created by Ken Thompson and released in 1973 to be used as a UNIX search utility that uses regular expressions to match lines in files. Most, if not all Unix-like operating systems today will come with grep pre-installed.
On a Unix-like operating system we can use the command man grep to view the tools’ extensive functionality. Alternatively, we can use the command grep --–help for a list of switches and their usage.
For this article I have used GNU grep version 2.5.4. If you are running an older version of GNU grep some of the commands in this article may not work. To check your version of GNU grep use the command grep -V.
Damn Vulnerable Web Application (DVWA)
DVWA is an intentionally vulnerable Open Source Web application I originally developed while at university to teach myself web application security. Since then it has grown with the help of many talented individuals which range from Web developers to security professionals from around the world.
The DVWA Live CD will be perfect for practicing grepping for bugs as it is developed in PHP, it is Open Source, easy to setup and, if I do say so myself, pretty awesome.
The LiveCD or the standalone files can be downloaded from the official DVWA home page.
If you have opted for the Live CD version, either burn it to CD and boot it in a spare machine on your local network, or, the easier method is to boot the Live CD ISO within virtualization software such as the Open Source Virtualbox.
Once you have setup DVWA within Virtualbox and booted from it, you should be able to connect to it via your preferred browser.
As we are grepping, the server side PHP source code we will need to ssh to the DVWA Live CD installation.
To do this the command is sudo ssh dvwa@192.168.1.107 and enter the password password. Note that the IP address for the SSH command depends on what IP your DHCP server has assigned to the DVWA Live CD.
From here we change the current directory to the DVWA Live CD web server root directory located at/opt/lampp/htdocs/.
Grepping for Cross-Site Scripting (XSS)
For a brief description of XSS I quote the Open Web Application Security Project ( OWASP ): XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
To identify XSS vulnerabilities in PHP code we need to identify the lines within the code base where user supplied input is output back to the user without first being validated or properly encoded.
By reading the low.php file we get a better understanding of what it does. We can see that the only check in place is whether or not the $_GET['name'] variable is empty or null before it gets put into another variable called $html. All user supplied input should be sanitized or encoded to help prevent XSS vulnerabilities.
We can now safely assume that the $html variable is output to the browser at some point due to its name and contents. However if the $html variable is properly sanitized or encoded where it is output we may not have found a valid XSS vulnerability.
The user supplied input which comes from $_GET['name'] in the low.php file is outputted via the $htmlvariable within the index.php file. Both input and output is left without sanitization or encoding. There is only one way to be 100% certain that we have an XSS vulnerability, and that is to exploit it.
Now the security level has been changed to low lets navigate to the XSS reflected page by clicking on theXSS reflected button on the left hand menu.
In PHP user supplied input is mostly handled by either $_GET, $_POST, $_COOKIE, or $_REQUEST. However user supplied input can also be handled with $_FILES, $_SERVER and others.
Lets start by looking for user supplied input via HTTP GET requests. To do this we will use grep combined with a couple of flags and a regular expression.
The command we will use to search for user supplied input is: grep -i -r “\$_GET” *
We have used the following options: -i to search for text regardless of the case and -r to search recursively for files within sub directories.
Our regular expression which will attempt to match the PHP $_GET superglobal variable is "\$_GET”. We first enclose the regular expression in double quotes, we escape the dollar symbol with a forward slash as the dollar symbol has special significance in regular expressions. Then we give it the keyword to search for $_GET. We finish off with a wildcard symbol * to tell grep to search within all files it comes across.
As you can see we have many results from our simple grep command, let us try and be more specific to narrow down the potential possibilities.
In PHP, output is normally handled by the echo construct. Lets see what happens if we search for user supplied input which is then directly output within the page without first being sanitized. To do this we will try the following command: grep -i -r “\$_GET” * | grep “echo”
Our new command will search through our original results looking for the “echo” keyword.
In this instance no results were found. Lets take another look at our original results more closely to try to identify why this is the case.
The following line within our results looks as though it may be outputting data.
It looks as though the GET HTTP request with the name of name is being appended to a variable called$html. Lets try and find out where the variable was originally set or where it ends up. To do this we will take a look at the server side source code of the /opt/lampp/htdocs/vulnerabilities/xss_r/source/low.php file with the following command: cat vulnerabilities/xss_r/source/low.php
To find where the $html variable is output to the user lets do some further investigation. As we can see, the low.php file is in the vulnerabilities/xss_r/source directory. Lets see what else is in the same directory with the following command: ls vulnerabilities/xss_r/source
As you can see from the output of our command, we have three files, high.php, medium.php and low.php. Lets take a look at the contents of a file within the same directory, maybe they yield some clues as to where the $html variable is output. We will issue the following command: cat vulnerabilities/xss_r/source/medium.php
The medium.php file looks almost exactly the same as the low.php file. However the medium.php file does some basic input sanitization by replacing the <script> string with nothing in the $_GET['name'] input variable.
There could be some possible XSS here too, however this is still using the $html variable to output the data to the user. We still need to find where the $html variable is outputted in order to verify the XSS vulnerability. Lets look in the parent directory for some clues by issuing the following command: ls vulnerabilities/xss_r/
The index.php file looks interesting, lets take a look at its server side source code by issuing the following command: cat vulnerabilities/xss_r/index.php
Bingo! By reading through the file we notice the $html variable is present! Issue the following command to view the index.php files contents with line numbers: cat -b vulnerabilities/xss_r/index.php
And there we have it, at line 47!
Lets open up the web application in a browser and login with the username admin and passwordpassword.
Once logged in, navigate to the DVWA Security tab on the left hand menu. From here change thevulnerability level of DVWA to low and hit the submit button.
Note that from our grepping we noticed that our input was in the low.php file. For each vulnerability in DVWA there are three different levels of security which determines the vulnerabilities exploitability. By changing the vulnerability level of DVWA to low we are making the application as vulnerable as possible.
To quickly verify that user supplied input or output is not sanitized or encoded we can use the <blink> html tag. Lets input the following as our name: <blink>I am vulnerable!</blink>
As you can see our <blink> HTML tag has been output to the user without being sanitized or encoded. We can now confirm that we have HTML injection, but what about XSS?
Lets try inputting the following as our name: <script>document.write(document.cookie);</script>
As you can see from the above screenshot we have successfully executed JavaScript by inputting it into the web application and having it output back to us without first being sanitized or encoded. Ladies and gents, we have XSS!
For further reading on the subject of Cross-Site Scripting (XSS) please see the provided links within DVWA under the More info title.
Grepping for Command Injection
For a brief description of Command Injection I quote again the Open Web Application Security Project(OWASP): The purpose of the command injection attack is to inject and execute commands specified by the attacker in the vulnerable application.
Within PHP there are a few different functions which will facilitate the execution of commands on the underlying operating system. If the user supplied input is used within one of these functions without being properly sanitize, it may be possible to inject our own commands on the operating system.
We will try our luck and search for the exec() PHP function with the following command: grep -i -r “exec(” *
Our grep command seems to have given us a lot of results. Lets refine our grep command a little to be more specific.
It looks as though the developers of DVWA have left the .svn hidden directory within the application. There also seems to be an Intrusion Detection System (IDS) within the external directory.
Both of these folders are giving us a lot of output which look like false positives. We will use grep to exclude both the .svn directory and external directory to refine our search with the following command:grep -i -r –exclude-dir={.svn,external} “exec(” *
We can see from the file contents that the ‘$target’ variable accepts user supplied input on line 5. It is then placed straight into the ‘shell_exec()’ PHP function on lines 10 and 15 depending on the operating system the script is run on.
Here we have user supplied input being put straight into a function that executes operating system commands. Bad idea!
Comments