![]() Any details you can provide about the root cause identification and resolution would be greatly appreciated. The headers are the normal/standard headers with most IIS servers. This is a simple POST request to a Microsoft-IIS/8.5 server. 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. The application interacted with that domain, indicating that the injected SQL query was executed. 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 payload ' declare varchar(99) set exec _dirtree was submitted in the username parameter. The username parameter appears to be vulnerable to SQL injection attacks. Here is the issue detail for the OOB SQL injection detection for Burp v2.0.07beta: This is unfortunate as Burp Scanner has been unknowingly broken for some time now. Please allow me some time to redact what is necessary.Īfter 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. You should review the contents of the error message, and the application's handling of other input, to confirm whether a vulnerability is present.Īre you able to share the full requests/responses when this issue has been manually identified? I can share some of these details. Two single quotes were then submitted and the error message disappeared. A single quote was submitted in the username parameter, and a general error message was returned. Here is the issue detail from the positive detection: Here is where by testing currently stands:īurp v2020.12.1 - Version did NOT detect the SQL injection.īurp v2.1.03 - Version did NOT detect the SQL injection.īurp v2.0.07beta - Version DID detect the SQL injection. I am still testing other versions but so far testing have revealed that the early versions are still detecting the issue. Yes, the URL is show in the list of audited URLs for the scan task.Īre the earlier versions of Burp still finding these issues on this particular site? 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? 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. Thank you for the prompt response Michelle. No host based firewall or filtering is in use.Ĭan you please advise on what may be causing the issue? Thank you. I was never able to get the Scanner to detect the SQL injection as previously detected. I tried scanner 5 different times with max audit coverage, only selecting SQL attacks, and normal configuration. ![]() Manual Repeater/Intruder correctly identified the vulnerability 5 out of 5 times.īurp scanner never identified the vulnerability, neither time or OOB. SQLMap correctly identified the vulnerability 5 out of 5 times. And I know these exact payloads and SQL injections were previously being correctly identified. Here are the successful payloads that Burp scanner is missing now for some reason. I pulled the payloads and information directly from Web Sec Academy: I know in versions 1.7 and 2.0beta this exact scenario was correctly identified several times. The Professional version scanner is not detecting a simple blind SQL injection in Microsoft SQL server. ![]()
0 Comments
Leave a Reply. |