Exploiter Beta

General:
Exploiter is a tool that demonstrates how SQL Injection vulnerabilities in a Web Application can be exploited to retrieve database information such as usernames, passwords, credit card numbers etc.

• Exploiter is capable of using a single SQL Injection (SQLi) vulnerability to extract an entire database.
• Exploiter does not find SQL Injection vulnerabilities. You need to use a tool such as Watchfire AppScan for that.
• Supported databases:
  1. SQL Server
  2. MS Access
  3. Oracle
• Supports 3 methods of exploit:
  1. Using SQL Convert
  2. Using SQL Union
  3. Blind SQL Injection
• Supports SSL and multi threading.
• Can run as standalone, or as an eXtension of AppScan. As an eXtension, it will automatically load all SQLi requests from AppScan.
• Performs brute force search if it fails to extract table or column names; this is mainly used for MS Access.

Terms of Use | Download Extension | View Exploiter Demo

How It Works:
Exploiter receives as input one or more HTTP requests with parameters that are vulnerable to SQL Injection. Exploiter then goes over these requests one by one and attempts to inject specially crafted SQL queries that reveal information about the database that is used by the Web Application. Exploiter tries to extract all information from the database, including table names, column names, and database entries for these tables.

Running Exploiter:

• Launch the tool from the Tools -> Extensions menu of AppScan
  • The tool loads all the SQLi requests
  • Note that if the requests include any cookies for session IDs, they need to be updated manually; this issue will be addressed in the future.
  • Note that for requests we import from AppScan we take the Original Request, not the Test Request. This is required for Blind SQL Injection to work correctly.
• Click "Injection Requests" to add or remove requests. For each request, you need to specify the parameter where the injection is possible. You may also check or uncheck requests; unchecked requests will not be used by the tool.
• Click "Go".
  • Exploiter will go over all the Injection Requests one by one, and will attempt to exploit them.
  • Injection Requests that Exploiter failed to exploit will be marked with an "X" icon. The Injection Request that Exploiter is currently trying to exploit is marked with a star icon. If exploit is successful, the Injection Request that was successfully used will be marked with a "V" icon.
  • While running, Exploiter's top panel gives indications of what is going on:

• For each Injection Request the tool will attempt all its possible "techniques" one by one, until one is successful or until all have failed. This includes attempting to use all possible methods (Convert, Union, Blind), attempting to use SQL syntax for all supported databases, attempting to apply brute force search, etc.
• With MS Access the tool is not able to extract any information about table names or column names. Instead it uses brute force to try and guess this information. The file Guess.xml in the installation folder includes the dictionary used for this brute force. This can be customized by the user.
• If the tool has extracted at least 1 table, it considers the exploit successful. In that case the tool stops (it won't continue to the next requests). It also automatically exports all results to the Results.txt file in the installation folder.

Logs and Settings

• Logs:
  • An "Action Log" is created, including details on everything the tool tries to do, the SQL queries it performs etc. Look for the file ActionLog.txt in the installation folder.
  • A full Request/Response log is saved in the file RequestLog.txt in the installation folder.
  • By default, logs are automatically purged every time you click "Go". This can be changed in the Settings.xml file (see below).
• In the installation folder you may also customize the Settings.xml file. It includes:

Option Name (XML Element)	Description	Default Value
MaxTables	Max number of tables	100
MaxColumns	Max number of columns per table	100
MaxRecords	Max number of records per table	20
NumThreads	Number of threads	5
AutoPurgeLogs	Auto purge logs every time the user presses Go	True
ImportRequestsFromAppScan	Whether or not to automatically import SQLi requests from the current scan, when launching Exploiter as an eXtension from AppScan.	True
PreloadedInjectionRequest	(Optionally) a default request that will always be loaded when the tool is launched - very useful for debugging or running the tool repeatedly on a certain site	N/A

For example, to preload an Injection Request to Exploiter add the following piece of XML code to Settings.xml:

<PreloadedInjectionRequest param="passw" ssl="false">

<![CDATA[GET /bank/login.aspx?uid=jsmith&passw=Demo1234&btnSubmit=Login HTTP/1.1

Host: demo.testfire.net

Connection: Keep-Alive

]]>

</PreloadedInjectionRequest>

• Tip: You can open the installation folder for quick access to XML and log files by choosing "Open Exploiter Folder" from the Logs menu.

Editing Injection Data
Exploiter is unique in which it lets you view and edit all the SQL queries it uses. All the SQL queries and supported exploit methods can be seen in the InjectionData.xml file in the installation folder. This is where you go to enable/disable specific methods, and/or customize the SQL queries the tool sends. By editing this file it is also possible to add support for new databases - no code changes are required.

Note: Throughout the file InjectionData.xml, text in the format $$VALUE$$ is used as a placeholder for other text.

The file InjectionData.xml included several element types:

• Injectors - these determine how to inject SQL queries into a parameter value. Each injector includes several "variants" of injection formats (called "Needles").
  • Convert SQL Injector: Each needle is tested using the Test value, and if the expression specified in ExtractionRegex is found in the response, this needle will be used.
  • Union SQL Injector: Here things get slightly more complicated. First we find a needle, the same way as in Convert SQL Injector. We also enumerate on the number of columns (this is done in code and can't be seen in the XML). We then attempt to create a database type conversion error in one of the values in one of the columns, using the format specified in the "Inner Needle".
  • Blind SQL Injector: Here we have two tests for each needle. The two are sent and their responses are compared with the original response. If one test response is similar to the original response and the other test response is not, it means this needle can be used for injection. With Blind SQL Injection we also need to specify a format for comparing a single string character to an ASCII value. This is done in the Char Comparison Tests. Here we use different SQL syntax for the different databases. All tests are performed until one is successful.
• Extractors - These determine the SQL syntax for extracting table names, column names, and data records. We have different extractors for the different databases, because of the slight SQL syntax differences between databases. A test is used to determine whether this extractor can be used. Then the queries for extracting table names and column names are repeatedly used until all table names and column names have been found. We then move to count the number of unique values in each column to determine which column to extract first (the "Leading Column"). Leading Column values are extracted, followed by the other columns. This is repeated for all rows of all tables.
  • Note: it is possible to add support for a new database by adding a new extractor, as well as adding a Char Comparison Test to the Blind SQL Injector.
• Guesser - these determine the SQL query format used for guessing table and column names. This is primarily used for MS Access databases.

Known Issues and Troubleshooting
If the tool is unsuccessful at exploiting:

• The #1 reason is probably out of date cookies. Make sure you update Session IDs in the injection requests. Note the tool is unable to perform login, or even verify it is logged in while it is running.
• Make sure you marked the correct parameter for each request.
• Make sure to use the Original Request and not the Test Request when taking issues from AppScan.
• Check the Action Log to see what the tool was trying to do.
• Use the Request Log to see how the server responded to the tool's requests; it could give a clue into what's the problem.
• Currently, Exploiter only extracts information from the database object that is used by the web application and will not extract information stored on tables in other databases.

Terms of Use | Download Extension | View Exploiter Demo