Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

How to import custom scan configuration using CLI

Vinay | Last updated: Dec 07, 2019 02:18AM UTC

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? Thanks, Vinay

Ben, PortSwigger Agent | Last updated: Dec 09, 2019 10:37AM UTC

Hi Vinay, 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: https://portswigger.net/blog/the-new-configuration-library 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.

Burp User | Last updated: Dec 31, 2019 03:13AM UTC

Hi Ben, 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. Thanks, Vinay

Hannah, PortSwigger Agent | Last updated: Jan 02, 2020 10:11AM UTC

Hi Vinay 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.

Burp User | Last updated: Jan 02, 2020 06:22PM UTC

Hi Ben, 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. Thanks, Vinay

Ben, PortSwigger Agent | Last updated: Jan 03, 2020 08:49AM UTC

Hi Vinay, 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?

Burp User | Last updated: Jan 18, 2020 12:42AM UTC

Hi Ben, 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. -------- Thanks, Vinay

Hannah, PortSwigger Agent | Last updated: Jan 20, 2020 11:51AM UTC

Could you provide some detail on how you are initiating your scans? Are you using the Burp REST API (User options > Misc > REST API)? Using that, you can initiate a scan with your scan-configuration, as well as receive updates on scan progress. There are a few deprecated functions, but the extender API hasn't changed much. You can see our most up-to-date documentation here: https://portswigger.net/burp/extender/api/index.html

Hannah, PortSwigger Agent | Last updated: Jan 20, 2020 11:59AM UTC

Hi Vinay None of the functions you have mentioned are deprecated. If you are calling IScanQueueItem.getIssues(), then the issues for that scan queue item should be returned. Since Burp 2.x moved to a task-based model, it could be that the scan queue order is different from 1.7, so your first scan queue item doesn't have any issues to report. Have you tried calling IBurpExtenderCallbacks.getScanIssues(java.lang.String urlPrefix)? This one should return all of the current scan issues for URLs matching the specified literal prefix.

Burp User | Last updated: Jan 20, 2020 05:31PM UTC

Hi Hannah and support team, to answer your question "Are you using the Burp REST API (User options > Misc > REST API)?" No. We aren't using API in this manner. We explained our workflow and usage our extension in previous response. As mentioned previously we use this workflow for a while using BSP 1.7.37 and older versions. Would it possible from your side to test this or explain any changes in 2.x would have break this communication and/or how to address it? Thanks, Vinay

Burp User | Last updated: Jan 21, 2020 10:43PM UTC

Hi Hannah, I don't have access to our Extender source. But if we (our dev team) implement or try what you are suggesting then we will provide additional information. For now, as end-user point I see, there were changes introduced in 2.x is not backward compatible. And preventing our team to migrate to it. Thanks, -Vinay

Hannah, PortSwigger Agent | Last updated: Jan 22, 2020 09:38AM UTC

Hi Vinay I'm sorry to hear you are unable to migrate. Please let me know how your implementation goes, if you try it. If you are just using your extension to initiate a scan, then if you were still interested in migrating over, I would recommend using the REST API that is implemented in Burp Suite Professional. If you were interested in trying that, you would need to change your user-config-file so that the REST API is running on startup. Then, once your installation is running you can interact with the API using curl commands. For example: - Starting a scan: curl -vgw "\n" -X POST 'http://127.0.0.1:1337/v0.1/scan' -d '{"scan_configurations":[<YOUR_SCAN_CONFIG_HERE>],"urls":[<YOUR_URL_HERE>]}' - Scan progress: curl -vgw "\n" -X GET 'http://127.0.0.1:1337/v0.1/scan/<YOUR_TASKNAME_HERE>'

Burp User | Last updated: Jan 22, 2020 11:23PM UTC

Hi Hannah, I am a developer at Parasoft who is on Vinay's team and is assisting him with his usage of Burp Suite. Using the method IBurpExtenderCallbacks.getScanIssues() does indeed return the list of issues, so it looks like we can modify our extender to call that API. However, it looks to me like there is a bug in the Burp Suite Java API. You suggested that perhaps the "first" IScanQueueItem does not have any issues to report, but we only have a single item, and it is the item that was returned to us by the call to IBurpExtenderCallbacks.doActiveScan(). On that item, we called the following methods and got the following results: - IScanQueueItem.getStatus() - returned "finished" - IScanQueueItem.getNumRequests() - returned 556 (this matches the value we saw in the Burp Suite UI) - IScanQueueItem.getNumInsertionPoints() - returned 7 The values returned for the three API calls above imply to me that we have the right IScanQueuItem, especially since the number of requests returned by the API matches what we saw in the Burp Suite UI. However, the following two API calls both return 0, which is not what I expect: - IScanQueueItem.getPercentageComplete() - returned 0 - IScanQueueItem.getScanIssues() - returned 0 The Burp Suite API looks like it is returning the wrong values for these methods. We are now unblocked since we can use IBurpExtenderCallbacks.getScanIssues() and it appears to work in both 1.7 and 2.x. But you may want to look into the Java API because it appears to be broken in 2.x.

Hannah, PortSwigger Agent | Last updated: Jan 23, 2020 10:45AM UTC

Hi Nathan I'm glad to hear that you are now able to use Burp 2.1. I've gone and investigated the Extension API with the developers and have the following responses: IScanQueueItem.getPercentageComplete() This function is deprecated, therefore it is expected that it returns zero. You should have also seen an alert, warning you that the function was deprecated, in your dashboard event log. IScanQueueItem.getIssues() Between Burp1 and Burp2, there was a major change in how scanning and the scan queue works. Previously, there was only one scan queue, that reported the issues each time as it encountered them. In Burp2, this changed. You can now have multiple scans and audits contained in different tasks. There was also a change implemented where only new issues are reported. As Burp has already encountered the issues that you are scanning for previously, it does not rereport them in the IScanQueueItem. This is why it is returning zero. By using IBurpExtenderCallbacks.getScanIssues(), this returns all of the issues for that scan found by Burp, whether they have been previously reported or not. Please let me know if you have any further questions that I can help you with.

Juan | Last updated: Dec 12, 2023 12:05AM UTC

Is there any way to load or select the configuration library from the extension before calling IBurpExtenderCallbacks.doActiveScan()? I tried with IBurpExtenderCallbacks.loadConfigFromJson(config) but it doesn't seem to solve this problem.

Hannah, PortSwigger Agent | Last updated: Dec 12, 2023 10:10AM UTC

Hi Are you referring to attempting to provide your extension with a scan configuration? Unfortunately, this is not possible outside of specifying active or passive checks. Just a quick point to note - we've released a new API for extending Burp called the Montoya API. The level of functionality around scanning is still the same as the legacy Extender API. However, it is much easier to use in comparison. We are also actively providing new functionality to the Montoya API, whereas the legacy Extender API is no longer maintained. If you'd like to check out Montoya, you can find our documentation here: https://portswigger.net/burp/documentation/desktop/extensions/creating

Juan | Last updated: Dec 13, 2023 06:57PM UTC

Hi Hannah, I was checking the Montoya API, I see there is an access to BChecks but I only see methods to import, is there any way to run BChecks over requests?

Juan | Last updated: Dec 14, 2023 12:02AM UTC

Use case: Create an extension to intercept specific requests through the proxy and execute BChecks on those requests.

Hannah, PortSwigger Agent | Last updated: Dec 14, 2023 03:14PM UTC

Hi Bchecks are a part of scanning functionality. If you have a "passive" BCheck enabled, and your default live passive audit task is running, then your BCheck will automatically be run against your proxy traffic. If you have more in-depth BChecks that are not passive, you would need to run an active scan against an item. This is possible to do using the Montoya API. However, as you cannot control the specific scan configuration used, other audit checks will also run. Please let me know if you'd like any more information!

Juan | Last updated: Dec 15, 2023 05:30PM UTC

Do you know if they are already working on being able to select the scan configuration, maybe indicate the name of the configuration library?

Hannah, PortSwigger Agent | Last updated: Dec 15, 2023 05:44PM UTC

Hi This is not currently in our plans for the near future. If you are interested in the ability to provide the Montoya API with a specific scan configuration then we can add your +1 to the ongoing feature request for this functionality, if you would like?

Juan | Last updated: Dec 15, 2023 08:44PM UTC

Hi Hannah, Sure, any way they can implement to run a given BCheck from the api, that would be awesome.

Hannah, PortSwigger Agent | Last updated: Dec 18, 2023 11:29AM UTC

Hi Juan Just to verify - are you looking to run specific BChecks, like when using the BCheck testing tool, or running all enabled BChecks?

Juan | Last updated: Dec 18, 2023 02:44PM UTC

Hi Hannah, Run all enabled BChecks.

Hannah, PortSwigger Agent | Last updated: Dec 19, 2023 09:39AM UTC

Thanks for that information! I've added your +1 to our ongoing feature request to be able to adjust the scan configuration used with the Montoya API. If there's anything else we can help with, then please let us know.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.