Burp Suite User Forum

Create new post

OctoDeploy Code Scans with Headless Burp Scanning? Oh My!

Kevin | Last updated: Nov 28, 2017 03:42PM UTC

Hello Everyone, I am attempting to accomplish the following and I need some advice. End Goal: Setup Burp Suite to run in headless mode on a CentOS 7 box for scanning of company-owned domains on demand. We are using OctoDeploy for code scans which can create an SSH pipe into the CentOS 7 Burp box and issue a command to scan domains of our choice. With that in mind, I've performed these tasks: 1. Configured a minimal install of CentOS 7 and updated the box 2. Copied the Burp Suite Pro v1.7.27 and hython-standalone-2.7.0 jar files to the box 3. Installed the Carbonator Bapp extension 4. Launched the GUI for Burp and configured carbonator and Bapp. I also ensured that under "Extender > Extensions" that The Carbonator extension have a checkmark beside "extension loaded" When I login to the box, I'll typically run the following command just as a test: java -jar -Djava.awt.headls=true -Xmx2g /srv/data/burpsuite_pro_v1.7.27.jar HTTPS sitenamehere.com 443 The next thing that happens is that I'll see, "Proxy: Proxy service started on 127.0.0.1:8080" When I watch the resource monitor, I see that there is a spike in network activity and CPU usage for a short period of time, and then it just drops off. Nothing ever seems to complete with this scan and the site isn't very large that I'm using as a tester, so it shouldn't take long to scan. Any configuration/setup tips would be GREATLY appreciated as I have a tight timeline to get this project working. And additionally, I have all default settings within the app, so perhaps I need to tweak settings there. I know the firewall is not causing a problem, as I've watched the traffic on the firewall pass as PERMIT without any issues. Thanks in advance!

PortSwigger Agent | Last updated: Nov 28, 2017 03:48PM UTC

Hi Kevin, Thanks for your message. You may need to add this option: --unpause-spider-and-scanner If that doesn't work, run Burp with the command you were using, but without -Djava.awt.headls=true This will cause the GUI to open, and Carbonator will start the Spider & Scan. You should be able to figure out from the GUI why it's getting stuck, and resolve that. Please let us know if you need any further assistance.

Burp User | Last updated: Nov 28, 2017 06:23PM UTC

Hi Paul, Thanks for the quick response! I found that the capitalized HTTP is not liked by Burp Suite, however, "http" is. Hurray for case sensitivity... doh! I attempted to disable collaborator, as we do not need to get to an external site (due to the strict nature of our business operating environment). The current command I'm using: > java -jar -Djava.awt.headless=true -Xmx2g /srv/data/burpsuite_pro_v1.7.27.jar https sitehere.com 443 > Output Proxy: Proxy service started on 127.0.0.1:8080 Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Scanner: java.net.SocketException: Connection reset Suite: Failed to connect to the configured Collaborator server. Scanner: Failed to connect to sitehere.com Spider: Failed to connect to sitehere.com It appears to be stuck at the SocketException screen at this point, but at least we've got some movement! Any suggestions for resolving the SocketException by chance? Thanks in advance!

PortSwigger Agent | Last updated: Nov 29, 2017 09:12AM UTC

Hi Kevin, Thanks for following up. Looks like you're making some progress. SocketException may not be a problem, unless it's happening excessively. Scanner deliberately sends malformed requests to the server and sometimes the server just resets the connection instead of returning an error. If you run Burp with the GUI (i.e. NOT headless) you can monitor the Scan Queue. A small number of errors can occur in normal operation. If there are many, the queue item's status will change to "abandoned - too many errors" It looks like Collaborator is still enabled. The best way to disable it is: open the GUI, go to Project options > Misc > Burp Collaborator Server and disable it. Then in the Burp menu use Project options > Save project options and select a file like myoptions.json. You then need to include this command line switch: --config-file myoptions.json Please let us know if you need any further assistance.

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