We can immediately see that in userdb.php the application shows an additional field intro that is not present in the sample and some output seem to be truncated…
Anyway: XML => XXE Injection! Let’s spin up Burp and perform some modification on the payload.
The parser truncate some fields but it seems that <intro> is left untouched: this will be our printer node.
We injected the classic XXE payload to read the /etc/passwd and we added some random char to see what the application can do.
<!DOCTYPE root [<!ENTITY test SYSTEM 'php://filter/convert.base64-encode/resource=/etc/passwd'>]>
This payload uses the PHP filter wrapper to read a stream and convert it to base64. The encoding is used to avoid embedding bad chars into the application HTML/template/parser.
Unfortunately the payload is blocked by a WAF. To bypass a simple WAF, usually, the first thing to try is to URL-encode all chars.
To easily URL-encode the XXE we used a plugin: Hackvertor. This add-on can be used to specify a tag with the encoding around the payload; Burp will do the rest for us.
This time the WAF do not blocked the request but we didn’t get any output: something broke the XML parser.
Let’s try another encoding:
After testing other encodings we read about an XXE WAF bypass that used a UTF-16 encoding: https://mohemiv.com/all/evil-xml-with-two-encodings/. The encoding, thus, must not be used only for the malicious payload but for the upload file itself.
Hackvertor can be used to add the tag <@utf16_0> at the begin and end of the file.
Issuing the request we got some base64 junk in the <group> node. We removed the injection output from <intro> node to avoid other possible errors.
The base64 is:
1
root:x:0:0:root
The bypass works and we got the begin of /etc/passwd. Let’s print all the file using <intro>.