How to import custom scan configuration using CLI
We have Burp Suite professional - and evaluating to migrate to 2.x.
In 1.7.x we have set the Scan issues (under Scanner -> Options tab. E.g. Scan for only only "LDAP Injection"), and exported it in configuration file. Then as part of our test automation workflow, using Burp Suite CLI we load it, and perform active scan for it.
How to mimic this flow when using 2.x?
If you select Burp → Configuration library from the main menu, you will initiate the Configuration library dialog. From here, if you click New and then select the type of configuration that you wish to carry out (for LDAP Injection only you would select New → Auditing). This will initiate the New configuration wizard, which allows you to make changes to the default configuration. Once you have saved your desired configuration with a relevant name, you can then click the Export button within the main Configuration library screen in order to export the created configuration to a file and location of your choosing. This is explained in the following link:
Once the custom configuration has been created and saved as a file you should then be able to load the configuration file via the command line as before.
Please let us know if you need any further assistance.
I have follow up questions when using CLI:
A) To load custom (user crafted) configuration library, I would assume to use "--config-file" argument. Is that right?
B) How about if I want to load built-in configuration library, e.g. "Audit checks - critical issues only" -- how should I load this configuration via CLI?
Please kindly provide an example (syntax) for such.
a) That is correct. For a full list of command line arguments, please visit https://support.portswigger.net/customer/portal/articles/2928360-using-burp-s-command-line-arguments (or use —help as an argument)
b) If you go to “Burp > Configuration library > Select your desired configuration > Export”, then you can save a configuration file to use in your command line arguments.
thanks for the quick reply, however something is not adding up. Let me explain our existing workflow which uses Burp Suite v1.7.37 with specific burp settings.
1) For which issues Burp to check for, under "Select individual issues" we have set all High severity issue types. These settings are saved in .json file
2) Launch Burp Suite via commandline, and loads all needed configuration files + our custom Burp Suite extension
3) From our automation tool, we communicate to Burp Suite via our extension and performed the active scan. This works and honor our pre-defined settings types of attack Burp to perform and saves time!
NOTE: Above workflow has been working well for us quite some time.
Now, using same workflow we are trying to migrate to BSP version 2.x Professional in
1* I created new configuration library for Audit task with desired settings (checking for High severity type issues only)
2* When launching Burp Suite via commandline, we passed this new configuration file as suggested.
3* From our automation tool, we communicate to Burp Suite via our extension and performed the active scan. This doesn't seem to works the same way anymore. From the dashboard, I see a new task "Extension driven active audit".
When looking the settings for this configuration - it uses the default settings. (which scans for: Passive, Light active, Medium active..etc.)
I was expecting that it would only scan "High severity" type issues, based on my configuration files.
What am I doing wrong? Can you please advise how to achieve above workflow in regards for me to successfully migrating from BSP 1.x to 2.x.
Apologies for the earlier confusion, I believe I can now see where the issue might be arising.
Burp 2.x has moved to a new task based model, which means that you can now run multiple parallel scans, each with their own settings and configuration, which was not possible using the top level tools available in past versions of Burp (Previously, the loaded scan configuration was applied across all scans that were carried out). The scan configurations are now held in the Configuration Library and, once imported into a Burp instance, they are always available and do not need to reloaded unless they are deleted.
I believe that the issue you are seeing might be due to the fact that a loaded scan configuration is no longer applied to all scans and instead has to be specified on a scan by scan basis (otherwise the default configuration is used). I assume that previously you would load Burp with requisite scan configuration and then your extension/tool would perform an active scan? Do you have any further details of how your extension/tool are working with the 1.7x version of Burp so that I can look into this further?
sorry for the late response on this thread. Please see my response below, and let me know if you have any additional question or potential solution for us.
>> I assume that previously you would load Burp with requisite scan configuration and then your extension/tool would perform an active scan?
Yes, that is correct.
>> Do you have any further details of how your extension/tool are working with the 1.7x version of Burp so that I can look into this further?
Here is technical details I got from our dev team, regarding how our Burp Suite extension works:
1. We capture the IBurpExtenderCallbacks object within the method registerExtenderCallbacks()
2. We then call IBurpExtenderCallbacks.doActiveScan, passing values for all variables, and capturing the IScanQueueItem that is returned from the method.
3. We call IScanQueueItem.getStatus() periodically until the method returns “finished”. At this point we can see in the UI that Burp Suite does the scan and finds issues.
4. Then we call IScanQueueItem.getIssues(). At this point Burp Suite 2.x returns no issues, while 1.7 returned issues that were found.
One side note that may or may not be relevant. When we originally built our extender, we needed to include duplicate copies of all classes in the Burp Suite Java API. I don’t remember why we had to do that, but we did. The extender still contains those classes – for version 1.7. I wonder if the presence of the older version of those classes doesn’t work in the new version of Burp Suite, since some of the APIs have since changed? Although the APIs I mentioned above don’t look like they have changed much.