Thursday, September 24, 2015

I Tried Harder - OSCP Edition

After about two and half months of dedicating the majority of my time to the certification, I successfully became an OSCP. I have read many different blogs that gave great advice but I thought I would add my spin on it as well.

This certification is very time intensive. However, I feel it is the most worth-while certification for an entry level Penetration Tester, and will give you some credibility within the community. Throughout the certification, your primary focus will be exploiting and escalating privilege on vulnerable hosts.

In preparation, I spent some time working on some vulnerable hosts on Vulnhub. In this site, people develop vulnerable machines very much like the ones you will see on the OSCP. You download and host the vulnerable machine on your computer and attack it.  This is great practice for those who are unsure if the OSCP is for them.

My favorites I have completed are:
Lord of the Root <- I created this one. My solution is here.
Troll 1 and 2

If you can complete these, even with a little help of the walkthroughs, you should be at the right skill level for the OSCP.

Also, I developed a script much like Mike at Security Sift to help automate the enumeration process. Since I have a developer background, this was relatively easy and painless. It was really time effective to have my enumeration process be completely automated. However, this is not essential.

I recommend going through all the exercises. If you do not, you may not have all the tools you need for the job. Also, it will teach you buffer-overflows in great detail. It wouldn't hurt to review this multiple times. I did. Also, pay close attention to the enumeration section. This is the majority of what you will be doing for the rest of the certification.  You will also need to be prepared to take copious amounts of notes in both the lab and exam environment regarding your path of exploitation and privilege escalation. This will help you greatly with the writeup!

In the lab environment, enumeration is the key! Many machines will be much easier if have all of the information available. Also, some machines have dependencies on other network machines. If there doesn't seem to be a point of entry and you have enumerated well, the data you need is probably on another machine. Move on and try again later.

I compromised almost all of the public network with a couple of machines in each of the other networks. I would recommend compromising most, if not all, of the public network before taking your exam. Also, the Admins in the IRC are a great resource for helping push you in the right direction on the lab machines. 

The exam is really where the rubber meets the road. In preparation for the exam, I wrote up my entire lab writeup. This included the exercises, labs, executive summery, remediations, conclusion, and any other piece necessary. I created a template for each machine to fill in once I had completed the exam. I did this because the last thing I wanted to do is spend all of the next 24 hours writing a long report after I had exhausted myself cracking machines for most of the night. Using my template, I was able to reduce my lab writeup time to two hours to complete the exam writeup.

I was told that if your exam is on the threshold of passing, reporting on your Lab machines and exercises will greatly improve your likelihood of passing the OSCP. Begin working on your reporting early and be thorough. I don't want to get too specific about the exam but what I can say, is that if you have worked hard on the lab environment, it shouldn't be anything that well beyond your understanding.

After reflecting on my exam, I learned I should have taken care of my body better. Get as much sleep as you can the day before, and as much as you may want to work until the exam is completed, DON'T.  Getting some sleep and looking at it fresh will help you not to spin your wheels. I spent too much time spinning my wheels in stubbornness. 

1. Enumerate, Enumerate, Enumerate
2. Take detailed notes in exercises, labs, and the exam. It will make report writing exponentially faster.
3. Write most of your final report BEFORE the exam.
4. Take care of your body during the test.

I hope this all helps! Good luck and remember to "Try Harder!"

Tuesday, September 22, 2015

Hacking Lord Of the Root

I created this machine to help others learn some basic CTF hacking strategies and some tools. I aimed this machine to be very similar in difficulty to those I was breaking on the OSCP. This is a walkthrough to guide those who get stuck to complete the challenge. This is a boot-to-root machine and will not require any guest interaction.

Note: There is one local privilege entry and there are two different root privilege escalations.

The OVA can be found at: Vulnhub.

Upon booting up the machine I did an entire TCP scan of the host and only ssh is open.

Upon banner grabbing we see:

Knock Friend? 1,2,3? That seems like port knocking to me..

Another full nmap scan reveals a web server has opened!

After an examination of the webapp with Nikto and Dirb there is nothing of interest. But I was able to find some things through manual testing and examination.

But there is a comment on the 404 page...
The comment seems to be base64 so we decode that:
 This URL takes us to a php login page that is vulnerable to SQL injection!

 So we dump the data with sqlmap:

The root Mysql password was also weak:

We checked for password reuse on ssh:
We are in low privilege!

There are two privilege escalations and both are described.

Escalation A Buffer overflow:

We found a suid buffer overflow contained within /SECRET directory. There are three files but when you look at the size of all of them, one is smaller than the other two. This smaller one is the BufferOverflow.
We moved an exploit dev file into temp so we didn't have to deal with the switching and verified the crash.
Next, we download GDB Peda. This gdb extension is the absolute best for exploit dev!

Verified the crash on Peda using out exploit code. Notice we have overwritten EIP with 0x41414141. the Ascii characters "AAAA".

We also check for security precautions. But there are none.
Using GDB Peda, we find our EIP offset.

Next, we verify control the EIP register. Notice the crash is on 0x42424242. Which is "BBBB"

We generate our shellcode using Peda and add our shellcode to the exploit.

Now that we know we have ASLR to circumvent, we need to modify our exploit code.

Due to ASLR randomizing address space and there are no good jmp esp instructions to use, we do not have a pre-defined location in memory to go to. This means we need to bruteforce the solution. I ran the program in gdb a handful of times to get a feeling of where the stack was landing on execution, due to it being different every time.  I was noticing that it always started with BF and the last 6 bytes were different. So I chose CC because it was in the middle of my random sample of stack locations. The last 4 digits I used were arbitrary. Next we will make a GIANT NOP sled. I used 20480 but it could be potentially larger.

Lastly, I created code to find the smallest buffer overflow file size to run just in case the file tries to switch mid run and we put that code in a while loop to run it indefinitely. This is because if we get a seg fault, it will replay the request and if we land our shell code it will stop on the shell giving us shell access.

This was our final code:

Note: You will notice back-off in the os call. This is expected because os.system is a blocking call. You can try to make it non-blocking to improve the script. But I used os.system for a quick and dirty solution.


Escalation B MYSQL:

Since we have the MySQL Root password and Mysql is running as root, we can use UDF's to escalate.
Success! We are in!

I hope you enjoyed the Lord Of The Root!

Monday, September 21, 2015

A New Security Blog

I started this blog as a way to begin to give back to the security community. I know that many blogs have aided me in my pursuit of security knowledge. This will probably include a wide variety of things including: hacking guides, certification thoughts, and small tools I have worked on. I don't claim to be an excellent hacker but hopefully this blog can help people learn, compromise hosts, and fix some bugs they have been dealing with.