OSCP Preperation 2

Over the last week, there have been a few new things that have made their way into my notes and that are worth mentioning. I’ve primarily been working on HTB machines and one of the machines that I completed about 2 weeks ago (Jeeves) has been retired and I do plan to do a full write-up on that box here soon. There was a big takeaway from the Jeeves box that was a brand new concept to me. So let’s dig in.

[hr]

[Windows] NTFS Alternate Data Streams:

When we create a file, say a text file, we open it up, write something, save it, and exit. We know that when we revisit that file, the data we wrote will reside within this file. However, the NTFS file system has a feature called alternate data streams which is a way for a singular file to hold more than one stream of data. The second data stream is not readily apparent to a user unless you know what you are looking for. The original premise behind alternate data streams was to provide compatibility with files in OSX.

Create an Alternate Data Stream –

We create an alternate data stream with the origin file being “password”.

Read the Password File –

We can edit the password file to contain any data we wish. In this case, I’ve added the text “No password here!!”.

View and Read the Alternate Data Stream –

If we use the command dir /r we can easily see there is an alternate data stream available. We can read this alternate stream with the native windows more command.

[hr]

XXE Vulnerabilities:

XML External Entities is number 4 on the OWASP top 10. XXE is deadly and I did not understand it completely until this last week when I experienced a box with an XXE vulnerability. Essentially, XXE attacks exploit an XML processor (usually a .PHP page) via a HTTP Post. That is, you send pre-defined XML formatted data that the server is looking for and will parse via an HTTP Post and can obtain remote code execution (RCE). The exploit does not directly lead to a reverse shell however; you can easily enumerate a system to obtain information that may lead to a shell.

Let’s look at example [Full Disclosure, I stole this example  from Black Hills InfoSec]:

Setup PHP Environment:

1. Check Current PHP Version of your kali machine
   1. php –version
2. Install php-xml subject to your version number (My version is 7.2):
   1. apt-get install php7.2-xml
3. Open Burp Suite and make sure Proxy is on
4. Verify Proxy is set within Firefox to catch the web server request.

Create a Vulnerable PHP Page:

Start PHP Web Server:

php -S <ip>:80 -t <directory>

Playing with the Vulnerable PHP Page:

There are several ways we can probe the webpage to check if it is vulnerable. First, we need to make sure we can get a valid reply back by sending the page an XML document. Let’s do this first with Curl:

And now we can send this XML document to the PHP server via curl and we should see our string come back:

Awesome, we get our string back. Now, I am going to move to Burp Suite and continue to exploit since I can just send our GET HTTP request to repeater, change the GET to POST and add the XML data without having to use the curl command each time. First, let’s draft some XML Exploit code for remote code execution.

We can take this code and add it to our BurpSuite Post and boom, we get the /etc/passwd:

[hr]

[Kali Tool] dotdotpwn:

I’ve always explored Local File Inclusion (LFI) vulnerabilities by hand but, having to work with a more expedited time frame in regards to the OSCP, I’ve started using a new tool that’s native in Kali. I won’t go too in-depth with this tool as it’s pretty cut and dry. Long story short, it looks for LFI for you. It’s not perfect but, it should be something you have in your back pocket of tricks and tools.