Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Scan Freezes at Active Phase 1

Pentester | Last updated: Mar 25, 2020 11:42PM UTC

Hello, I'm having an issue with the scan functionality on Burp Suite Professional v2020.2.1. The same exact request works with no issues on one of the earlier versions of Burp Suite Professional's scanner, v1.7.37. This is on Kali Linux 2020.1. To initiate the scan, I've tried right clicking the request > scan > Audit checks - all except JavaScript analysis. I've also tried the default scan configuration. In both cases, it completes the "passive phases", but is stuck indefinitely on the first "active phase" of the scan. I've tried rebooting Kali Linux and reinstalling Burp Suite Professional, but this issue persists. Moreover, there are no errors or anything to indicate connectivity failure. No event logs whatsoever. Please advise of a potential solution.

Pentester | Last updated: Mar 26, 2020 12:38AM UTC

I'd like to include that the Burp Suite Pro scanner is responsive, it's just the scan task that does not move forward for this particular request. Scans for the same target are working properly for other parameterized requests. The current scanner does not like this particular request, but it works on the old scanner and I'm trying to find out why.

Pentester | Last updated: Mar 26, 2020 12:40AM UTC

I meant the application is responsive.

Uthman, PortSwigger Agent | Last updated: Mar 26, 2020 08:39AM UTC

Hi, The scanner for version 2 was completely re-built. That may explain why it is working in 1.7.37 but not in the latest version. Can you please install the Logger++ extension and see if any requests are timing out? What error handling rules have you set up in your scan configuration for the Audit/Crawl? Can you send some diagnostics and more information to support@portswigger.net, please?

Pentester | Last updated: Mar 26, 2020 02:54PM UTC

Hello Uthman, I've installed Logger++ as instructed and there are no logs which indicate request time outs. I see the requests from passive phases 1 and 2, but it simply stops sending requests after the scan reaches "phase 1". The scanner is not paused and there are 0 errors or event logs to indicate failure of any kind on the application or network layer. The error handling rules which are configured are the default "Audit checks - all except JavaScript analysis" so 2 it skips insertion points/fails after 2 consecutive audit check failures and pauses at 10 consecutive audit item failures with 1 follow-up pass to retry failed operations. However, I've tried a custom configuration with all of these application handling configurations cleared out (no value in each box) to turn it off. Same result freezing on active phase 1. I've send the diagnostics to support@portswigger.net with subject line - ATTN: Uthman - Scan Freezes at Active Phase 1

Uthman, PortSwigger Agent | Last updated: Mar 26, 2020 02:57PM UTC

Thank you for that information. I will have a look at the diagnostics now.

Pentester | Last updated: Mar 28, 2020 12:23AM UTC

I've identified the issue with scanner 2020.2.1 and wanted to share my findings. So apparently the new scanner hates the following parameters/cookie which are skipped by default but are case sensitive, so the capitalized/mixed case versions of the parameters were not skipped and completely halted the scan. __VIEWSTATE __EVENTVALIDATION __EVENTTARGET ASP.NET_SessionId Once I implemented those ignored insertion points, the scanner worked properly for the request and completed successfully in a reasonable time frame. Any idea why the scanner would just stop sending requests indefinitely instead of prompting some sort of error or fail safe action to keep the scan going?

Oscar | Last updated: Feb 09, 2021 07:56PM UTC

This still happens. How come this has not yet been fixed?

Oscar | Last updated: Feb 09, 2021 09:42PM UTC

Got it working but I had to add more exclusion than Pentester. I did it like this: Create a new Scan configuration with the following Ignored Insertion Points: Match item - Body parameter: __EVENTTARGET __EVENTARGUMENT __LASTFOCUS __VIEWSTATE __VIEWSTATEGENERATOR __VIEWSTATEENCRYPTED __ASYNCPOST Match item - Cookie: ASP.NET_SessionId .ASPXAUTH Name or value: Name Match type: Is

vpb | Last updated: Jun 07, 2022 09:38AM UTC

Still an issue after 2 years in a core feature...

Hannah, PortSwigger Agent | Last updated: Jun 07, 2022 10:37AM UTC

Hi Could you drop us an email at support@portswigger.net with some more details on the issues you are facing, please?

vpb | Last updated: Jun 07, 2022 02:05PM UTC

This is not a solution, rather a workaround to the cascade effect of the problem, hope it helps someone: - Assume a resource pool of 3 parallel threads - Tasks A,B,C are stuck at phase 1 for some unknown reason - Burp is restarted, Status of A,B,C are empty (no indication of them using the resource pool) - New task D is added to the audit - Task D runs through phase 1 then gets stuck: state is "Scanning", but no messages are sent by the Scanner. - Cancel A,B,C -> now they are in "Cancelled" state - D runs fine. Now the issue seems to be that A,B,C are locking up the resource pool, although there is no indication about this on the GUI. But this is contradicted by the fact that phase 1 of D runs fine...

Michael | Last updated: Jul 16, 2022 06:08AM UTC

I had this issue a few months ago, but now it's back. I had added the same ignore insertion points as Oscar awhile ago. A few version updates later, this issue came back and then came back to this post. Went back and check my scan configuration and notice the configs I added are gone. I'm currently doing the deep scan where it discovered 337 URLs in the audit. I already notice two URLs stuck. It doesn't always get stuck on the same URLs.

Hannah, PortSwigger Agent | Last updated: Jul 18, 2022 08:34AM UTC

Hi Michael Could you drop us an email at support@portswigger.net with your diagnostics info (Help > Diagnostics) and any further information?

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