Thursday, June 22, 2017

BURP Automation and Build Integration

Introduction

Continuous Integration of security tools are always desired to save manual efforts and save time.  BURP is meant for manual testing and is a very powerful tool when used manually for a security testing for its plethora of features like Scanner, Intruder, Repeater, Sequencer etc. However the BURP scanner component can be integrated with the build to facilitate automated generation of security scan report.

How to Integrate

The Extender feature of BURP opens multiple APIs that can be used to invoke different functions of BURP. You can write your own plugin in Java/Python/Ruby to programmatically interact with BURP to initiate your scan from the build system. Some reference implementations for this purpose are - GDS Burp API, Jython Burp API. However, there is a 3rd party BURP App available in BApp store in BURP that already does the job for you – “Carbonator”.

You can install the plugin to enable calling BURP scan features from the command line. This documentation describes the setup and use of Carbonator to facilitate calling BURP features from the command line, so that it can be used by any build agent.

Using Carbonator

Setting up the plugin


Carbonator is written in Python, so to enable its use you have to download Jython standalone JAR file from http://www.jython.org/downloads.html and set it in the ‘Python environment’, under the ‘Options’ tab of ‘Extender’ 

Once the environment is set, come to the ‘BApp Store’ tab select ‘Carbonator’ from the list and install.

Make sure that the following option is checked –

Now, close BURP gracefully to ensure the extension is saved within the BURP JAR.

Next time when you open BURP, to confirm that it is installed properly, you have to confirm that it is listed and ticked under the ‘Extensions’ tab of ‘Extender’.

Running BURP from Command-line

Now, to invoke BURP scan from the command line, you have to enter the following command –
java -jar -Xmx2g path/to/burp.jar scheme fqdn port app-path
For example:
If you want to scan http://127.0.0.1:8080/dvwa/ from Windows, the command should be -
java -jar -Xmx2g “path\to\burp.jar” http127.0.0.1 8080 /dvwa

When you invoke this command, it will –
  • Start BURP
  • Set the URL to Scope
  • Start the Spider and populate the site-map
  • Start the scanner
  • Once scan is done, generate the report and place it under the same directory where BURP JAR is located
  • Close BURP

If the GUI is invoked using the previous command, there will be need of some manual interaction in the GUI while the BURP is starting. That cannot be afforded when build agent is calling BURP. So you have to add another option to stop invoking the GUI and get it done without any interruption (if everything is configured properly) -
-Djava.awt.headless=true
So the command to be included in the build script is –
java -jar -Xmx2g -Djava.awt.headless=true  “path\to\burp.jar” http127.0.0.1 8080 /dvwa

(Please read ahead, the story is not over yet)

Issues with automated crawling

When you are invoking BURP using the command mentioned before, the tool has no way to authenticate to the app. In without authentication, it is not possible to cover the complete application during scan. More to that how the command line trigger will know the values for form submission? So in order to properly crawl the complete application (and subsequently scan), few more pieces need to be added.
We can set the user creds and form submission values (and lot more) using the GUI.  So while we are configuring the build integration, after the Carbonator plugin is setup, we need to do few more steps –

Configuring the crawler

Under ‘Spider’ -> ‘Option’ -> ‘Application Login’, set the admin credentials (admin privilege is required in order to ensure maximum coverege)

Under ‘Spider’ -> ‘Option’ -> ‘Form Submission’, populate the table properly with all the field names in your application

Additionally you can set the options for the scanner to improve scan performance, e.g. changing the number of threads for scanning, which issues to look for.

Save the configuration

Save the configuration. The output will be a JSON file that should be put as an additional parameter while invoking BURP.


Running BURP with the configuration file

If this file is used while invoking BURP, the instance created will use the configurations while running. So BURP will be able to authenticate to the app and able to automatically submit the forms it find. To command to use would be –
java -jar -Xmx2g -Djava.awt.headless=true  “path\to\burp.jar” http127.0.0.1 8080 /dvwa --config-file=path\ProjOpt.json
Once the command is executed successfully the report will be available in the same folder, where BURP is located with the name IntegrisSecurity_Carbonator_scheme_fqdn_port.html. e.g IntegrisSecurity_Carbonator_http_127.0.0.1_80.html

NOTE: Manual interventions might be needed

  • The project configuration required will change very often across versions of the same product (with the change of creds or advent of new fields). So periodic review/recreation of the configuration file, might be required.
  • The version of BURP or Plugin might need upgrade periodically. So, manual efforts are required to upgrade them in the build agent.

Proxychain tool in a nutshell

In order to do penetration testing anonymously and decrease the possibility of identity detection, hackers need to use an intermediary mach...