Legal Disclaimer

The vulnerability discussed in this tutorial has been made public in the interests of public security. It was released to Bugtraq (http://seclists.org/bugtraq/2014/Aug/86) on the 17th of August, 2014 after careful decision and deliberation about what to do with the bug.

Furthermore, the vendor has responded to, as far as I am aware, at least the HEAD vulnerability, by stating "Please note there are number of reported "security vulnerabilities" for Kolibri webserver.
So let me clarify that Kolibri+ is not secure and will never be secure for the same reason bicycles don't have airbags." However this is not immediately apparent, as one has to navigate to the Kolibri+ Webserver page (available at http://www.senkas.com/kolibri-plus/) to see this notification, and there is no notification about this on the Kolibri Webserver page. From what I am aware of, Kolibri+ is meant to be the new edition of Kolibri Webserver, therefore it would seem likely that it is built on the same code base, but I have yet to verify this. Something to investigate if your interested :)

Anyway, getting back to the story. When I put all of this together I decided to go full disclosure on the issue as the vendor clearly has no intention of fixing the numerous bugs within the code, and with the combination of the public HEAD and GET exploits which have the same impact on the program and which take the same vulnerable code branch, I saw no reason why making my exploit public would harm anyone. Thus this is why I chose the full disclosure approach. Upon later investigation, it also appears that this product hasn't been updated since 2008, so it appears to have been abandoned by the software developer.

Disclosure Process

August 7-8th to the 16th: Work on making a proper PoC to demonstrate RCE

August 16th 2014: Request CVE-ID from MITRE by emailing cve-assign@mitre.org.

August 17th 2014: Get email back from mitre.org saying they have assigned CVE-2014-5289 to the issue and add a note of the other CVE-ID's for the other vulnerabilities.

August 17th 2014: Send off email to BugTraq mailing list with the details, and explanation of the bug, and a working PoC that popped a reverse shell to prove the vulnerability.

August 19th: Vulnerability taken by others and posted to numerous sites including 1337day.com and packetstormsecurity.com, is assigned a number in the OSVDB (110142 as can be seen here: http://osvdb.org/show/osvdb/110142).

August 20th: Contact MITRE to let them know the issue is public and has been posted to BugTraq. Email them a link to the BugTraq post, along with the other resources I found that had the exploit code to prove that the issue had now gone public.

The Proper Intro

What is the Bug?

Essentially speaking, this is not a very complex bug. If you've looked at some of my previous tutorials, this bug might seem very simple to you. If not, you should have a good understanding of:

Egghunters

SEH Overflows

Debuggers in general

If you don't understand those concepts or how to do common exploits/work a debugger, you may want to look at some of Corelan's or Lupin's tutorials at TheGreyCorner and come back when you have more experience. If you have no idea what the heck I am saying, a) Your in the wrong place and b) Go to Lupin's TheGreyCorner and start reading all of his tutorials. When your done, read up to tutorial 6 from Corelan. Then come back here.

Back to the bug. The bug is essentially a buffer overflow when parsing an overly long URL for a POST request. Thus the following request will cause a crash:

POST /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

HTTP/1.1\r\n

User-Agent: Wget/1.13.4\r\n

Host: 192.168.99.142:8080\r\n

Accept: */*\r\n

Connection: Keep-Alive\r\n

Content-Type: application/x-www-form-urlencoded\r\n

Content-Length: 50

licenseID=string&content=string&paramsXML=string

Setting Up

All good? Ok. So here is what your going to need to continue following along with this tutorial:

A Windows 7 machine, can be x86 or x64, though to start off with you may want the x86 version, otherwise you'll have to wait for the WoW64 egghunter portion of the tutorial to get the 64 bit version working.

First set up your Kali Linux machine. Then install Kolibri onto the Windows machine, and set up Immunity Debugger and optionally install mona.py. Once we have done this we can start fuzzing Kolibri for flaws.

Explaining the Fuzzing Code

This was actually done whilst probing
for existing vulnerabilities for my CTP course to make some SPIKE
templates. During this time I was testing Kolibri webserver for its
vulnerable GET overflow and thought that I might as well expand the
example and try creating a POST template as well, since GET and POST
share some similarities in their parameters.

Funnily
enough, after less than 2 minutes of fuzzing, the program fell over with
an exploitable crash. The spike template that I used for fuzzing the
program was:

What
this code does is first declare the static string "POST /" (minus the
quotes, those are just for clarity) that will always be sent first. This
will be follow not by a new line, but rather by a variable string which
will change constantly according to a predefined set of checks defined
in SPIKE. The first string that it will test however is the value
currently defined in the quotes, namely
"enlighten/calais.asmx/Enlighten" (again, sans quotes). The rest of the
s_string declarations should be fairly straightforward if you got the
earlier s_string example with "POST /".

The part after
this is a bit more confusing. The line 's_blocksize_string("data", 2)'
says to the spike fuzzer that we would like to insert a 2 byte value
representing the size of the block called "data" at this location. The
line 's_block_start("data");' starts the definition for this block of
data (ironically named "data") of which the length needs to be tracked
for the s_blocksize_string line so it can insert the correct length of
the string into the packet it sends to the server. We then declare a
variable string (tbh we don't need to as we never get to fuzzing this
before the program crashes, but hey, I wanted to show a different way of
doing things ;)) with the line
"s_string_variable("licenseID=string&content=string&paramsXML=string");".
Following this we use s_block_end("data") to end the block "data", thus
the block "data" now contains one element, a string of arbitrary
length, who' size can be tracked with the earlier s_blocksize_string
line.

Finally, after declaring all of the parts of the
packet that we will send line by line, we then recv the banner response
from the server, as Kolibri will send a banner to anyone who connects to
its server port, and we would like to retrieve this if possible.
Following this, we sleep for 5 seconds to allow the server to properly
handle our requests and not get overwhelmed. For some reason Kolibri is
not very good at handling multiple requests simultaneously, thus the
long wait period. You can tune this down to about 3 seconds if you want
to speed things up, but any shorter might cause problems.

Fuzzing the Server

At this point we now need to fuzz the server and observe any crashes that occur. Save the script I mentioned above as post.spk on your Kali machine:

Ok at this point, we now need to set up the Windows machine so Kolibri is listening and Immunity is attached to it so we check for crashes and capture any of them of them in Immunity for further inspection.

First off we will start up Kolibri. We will then attach Immunity to Kolibri so we can debug any crashes:

Once you have done this, press F9 to run the program, and then hop on over to your Backtrack/Linux machine where we'll start up the fuzzer and use Wireshark to capture the traffic that is sent over the wire.

If you encounter an error when accessing 00000000 on startup, just press shift and F9 together and the program will carry on running.

On the Backtrack host, set up Wireshark to listen on the interface that you will be using to send the packets (I'm assuming at this point you know how to use Wireshark or a similar tool, if not, Google is your friend). We will then navigate to the directory of our post.spk SPIKE file (or whatever you have named the SPIKE file we created earlier) and will execute the following command:

generic_send_tcp 192.168.82.129 8080 post.spk 0 0

In this command we use the generic_send_tcp command included with the SPIKE toolkit to fuzz a generic TCP request using the SPIKE fuzzing template we created. We tell it to connect to 192.168.82.129 on port 8080 to preform the fuzzing and tell it to start from the first variable we wish to fuzz (we defined 2 in our SPIKE file), and to use the first fuzzing case generated for it (the second 0 you see in the command).

If we wanted to, we could change these last two parameters to skip the fuzzing of the first variable and instead start from the second variable, or to skip over certain test cases that may crash the program in a nonexploitable way. This won't be necessary today, but I would like to make you aware of this in case you wish to explore further ;)

Now that we have that all set up, lets set off the fuzzer!

As you can see, we have Wireshark in the background capturing any and all packets that are being transmitted over the wire so I can try and pinpoint where the application is crashing. In the foreground you can see the progress of SPIKE as it slowly fuzzes the application.

The reason we place a long delay in (see the file for where we add "sleep(3);"), is that Kolibri is incredibly slow at responding to requests by web server standards. To ensure requests don't intermix and the results from the crash are as clear as possible, I decided to make the wait time sufficiently long so that the application can handle the requests in adequate time. If you wish you can make this shorter, but if you get odd results I did warn you! In the meantime I recommend you get a light snack, and wait.

If you continue to monitor the status of the fuzzing, you should eventually see something like this on the 30th request (at least for me it was like that). If you don't get this, skip this section and move on to where I create the PoC. The application is really slow to respond and can be a little buggy.

Anyway this is what it looks like before the crash, when its accepting requests:

And after the crash we see EBX is fully in our control and points to somewhere within our buffer of A's that were sent (A = \x41 in hex). If we look carefully at the stack we can also see a pointer to our buffer there as well:

This may not seem exploitable (the real error that occurs, excuse the screenshot, is an access violation), but if we check the SEH overflow we can see we have successfully overwritten the SEH handler:

So we know we can now control the SEH handler and subsequently EIP and we also have control over EBX. Lets make a PoC to test our theory. If we look at the request that corresponds to request 30 in the command line we see this:

Running this program against the target generates the same crash as before. If we now click on the first address in the SEH chain, right click on it and select "Follow In Stack" and then scroll to the bottom of the stack, we will notice our first error. We appear to have written past the end of the stack:

If we click on the address of the previous SEH handler and then scroll up to the beginning of our A's, we can see that it takes 687 hex bytes, or 1671 bytes to overwrite the previous SEH handler.

If we send this to the target and then observe the SEH chain afterwards, we can see that we successfully overwrite the current and previous SEH handler.

A Problem Appears

At this point we run into a small problem. When looking at the available modules in mona to find what ones are not SafeSEH enabled, we see that only the application itself is not SafeSEH enabled:

Further experimentation reveals the end of the request is being terminated by a \x0D byte. Because of this we can't even use a 3 byte overwrite and rely on the null terminator to supply the final \x00 we need to use addresses from the binary itself.

However if we adjust the code and reduce the size of our overwrite, we can actually get the request to be terminated with a null byte. The code that causes this overwrite can be seen below:

And as you can see, the request is terminated with a \x00 byte, resulting in the SEH handler being set to 00CCCCCC:

The next part comes in bypassing ASLR on Windows, which is the first of several protections we will need to bypass to get around EMET (which will be discussed in a seperate blog post).

From the earlier post where we examined that SafeSEH is not enabled for the application binary itself, we can also notice that the application binary itself is the only one not subject to DEP, ASLR, or pretty much any protections at all. As thus, if we can find an address within this binary that holds a POP POP RETN instruction, we can use this in combination with the fact that our requests are now terminated with a null byte (the first byte of the binary's addresses start with a \x00 so we need to use this trick to be able to use addresses from the binary itself) to create a ASLR friendly SEH overwrite.

Sending this results in us hitting our POP POP RET (the breakpoint was set after this photo was taken, but make sure to set one there before you try sending the exploit):

And executing these instructions lands us in the 4 byte space we are presently using for the NSEH address:

As we can see in the exploit code, the solution to this is to use the sequence \xeb\xF0\x90\x90 or a short jump backwards to gain more space to jump backwards.

Once this jump was executed, we need a bigger jump backwards to get to the start or near the start of our shellcode. The bytes \xE9\xF3\xFC\xFF\xFF will satisfy this requirement and perform a long jump back near the beginning of our shellcode, as can be seen in our debugger:

As you can see this results in us hitting somewhere near the beginning of our shellcode:

Ok, now all we have to modify the exploit one last time to include the exploit code for a windows/shell_bind_tcp shell on port 4444, excluding the bad characters \x00\x20\x3F:

If we execute this now, and pause right after we execute the long jump, we can see we hit around about the middle to end of our NOP sled:

Executing this code results in port 4444 opening:

Connecting to this port returns a shell:

Conclusion

Hopefully this was a good tutorial on how to find your own vulnerabilities and turn them into an exploit. I always wanted to do something like this as soon as I found my first proper vulnerability so here you go :)

In
a future tutorial I will cover how I modified this exploit to do a
partial bypass of EMET minus DEP. In the meantime I hope you enjoyed
this tutorial. Let me know if there is anything that is not clear or if
you would like me to expand any of the sections to explain things more.

Tuesday, September 16, 2014

Signing Up

If you have done OSCP before, signing up should be fairly familiar. For those of you masochists out there, the sign up process generally consists of you proving your identity in some way, usually by a scan of your driving license or alternatively, your passport. Because Offsec already had my details on file from when I did the OSCP, I did not need to do anything but click on the personalized link they had sent me for future signups, whereby my details were then passed onto them automatically upon signup.

Once Offsec have received your details and checked your identity, they will then give you the option to pay for the course. As this course is more advanced then OSCP, the price is a little bit higher, at $1500 for 60 days of lab time, or $1200 for 30 days of lab time. Retakes of the exam are $100 per retake.

In my personal experience I would say the best method to take would be to set aside 3 months, as like the OSCP and to take the 60 day option. The reason for this is that granted, you won't need the full 60 days to cover the course, but it gives you the option to train for 45-50 days, take the exam, rest for a day or two, and then figure out where you went wrong on the first try in time for a second exam try.

Furthermore, from experience and what I've heard from others, most people tend to fail this exam on their first try. My personal opinion is that unless you have been doing this sort of stuff for a long time, its highly unlikely you will manage to get it on the first time. So don't expect for that to happen.

Do however expect to fail, and to learn a lot from the mistakes that will occur during your first exam attempt. The period between my first and second exam attempt where I did a lot of personal research into the various topics was actually where I learned the most, and is where two future posts's topics were researched in further detail, to give an example of the level of learning that occurs here.

After you have paid the fee for the course, you will be given access to a calendar from which you can book the start of your course. Please note that your lab access time will start from the start of your course. Contrary to some people's belief, it does not start from the moment you access the labs. You could spend the entire time not in the labs and the timer will still count down. So use the labs to your advantage! :)

There will also be a link to a sample VPN connection pack that you can use to make sure you can VPN into the labs. If you have any problems during this stage, contact Offsec to find out what might be wrong and how to fix it.

Once you have done all of that, congrats, you now have signed up for CTP :)

Starting the Labs

Two days prior to starting your labs, you will get an email reminding you of your starting date. This is to make sure that everything is okay with you and to remind you to get prepared :) On the day of the access to the labs, at exactly the time specified or a few minutes after it (depends on your connection speed) you will get a lab email.

In the email will be several details that you will need to be aware of. In particular there are 4 links. Please note that these links will only be valid for 72 hours. Therefore you need to download all of these and keep a backup of them. If you loose them, good luck mate. Offsec will not provide backup copies.

Therefore, its best to download all of these links and save them to a safe place. There are:

Lab videos (this is going to be a fairly large download)

CTP manual

Lab connectivity guide (if you've done OSCP this should be familiar)

Lab connectivity pack

You will also get your username and password for the lab VPN at this point, as well as access to the control panel for the machines.

Now students of OSCP may find this surprising, but these machines are entirely yours. No one else's. No more fights over control. There just yours to play around with without any delays. You'll soon learn why you need this though, as a lot of the challenges aren't very tolerant of faults and changes in the way you do things.

Finally for the course, Offsec recommends you to use a 32 bit VM of Kali Linux, and provides a link for you to download the VM to your local drive. I would highly recommend using this as not only does this provide a layer of abstraction between your host system and the labs, but it also helps later on if you have any problems with the labs.

Finally, a while later you will receive a email that contains your OSID, your login to the Offensive Security forums, and a link to schedule your exam. Save this email somewhere safe as you will need it when you book your exam.

Getting Started in the Labs

In the labs you will have access to several machines (I am deliberately not telling you how many as that is a secret for those in the labs I believe. Also to avoid possible pitfalls related to giving hints away, and I'd really like to keep my OSCE if you don't mind :P )

On those machines will be various software components that will relate to the exam handbook. Each chapter of the handbook focuses on a different scenario that Offensive Security experienced when they were doing real world pentests and explains the problem as well as how they walked through each of the steps to solve it. Finally, the problem at the end usually asks you to recreate their work in the labs and might suggest trying to do improvements to it in some way to gain further understanding.

Topics Covered

I will now provide a breakdown of the topics covered and explain in
detail what they entail and my opinion and review on each of them:

Cross Site Scripting Attacks

This was a pretty easy chapter, but went into how to use XSS in more interesting scenarios and how to use it to steal cookies to hijack sessions as well as how to use XSS to get a shell via a client side attack. This was a nice section however I felt a little bit cheated when they went from "Oh, so we now have admin control" to "Lets get a shell on the system". Thus I might have liked to see some more interesting scenarios being presented here, but the ones presented were beautifully explained.

Web Fu

At this point the course starts to take a turn for the more interesting as we look into a multi stage web application attack example that takes advantage of one of the flaws that existed in an old version of PHPNuke and examines how we can take what appears to initially look like a simplistic vulnerability that has minimal impact into full fledged system access on the computer by abusing 2 vulnerabilities within the PHPNuke software, combined with a couple of handy tricks.

This was one of my favorite chapters of the entire course, as it really changed by perspective on how even simple vulnerabilities can cause problems when combined later down the line. This was a valuable and important lesson to learn at this stage in the game as it would quickly become more apparent later on how we could abuse this.

The Backdoor Angle

This course was a nice introduction to LordPE and some of the various tools you would be using in the next chapter. I was surprised to learn how easy it is to backdoor a file but to be honest, when I saw the method they presented, it made a lot of sense. Maybe some more interesting alternative methods could be presented here like alternative data streams, as the section does seem to be quite focused around just the one area in particular, but it was a nice introduction none the less.

Bypassing Antivirus Systems

Oooh this was another fun module. Taking on the stuff learned in the previous chapter, one is taught how to evade common antivirus signature detection technology, the most popular detection mechanism in use today, thus dropping detection rates quite significantly.

The method for this is quite similar to the previous example, with the exception of the code stub. A sample code stub is supplied, but it leaves you enough room and explanation to code your own if you ever need to. The logic behind it not complex if you have a decent familiarity with x86 assembly and even if you don't they walk you through the assembly code so that you understand everything that is going on within the stub.

Pretty brilliant module tbh. Didn't really have any complaints with it minus the fact that I would like to see this updated with a section on bypassing heuristics. These techniques do tend to update more frequently, however at the end of the day there will always be some AV out there that relies on old techniques and thus this would serve well for learning how to bypass it. Furthermore, by studying old techniques, one can learn some common pitfalls of past AV's and search for new methods to bypass AV when the old methods get patched.

Bypassing ASLR on Vista

This module was one of two modules I think Offsec could have done without in their course. The example of bypassing ASLR on Vista with a sample exploit and a 3 byte overwrite was brilliant, and I have actually incorporated a similar idea into one of the exploits I plan to release in another blog.

However the main downfall of this module is that there is no other place this or similar protection mechanisms such as DEP are talked about. Its just the 3 byte overwrite example and then bamn, next chapter. I would have like to see this section expanded a bit or more examples/technology bypassing included. Perhaps that would push it more into AWE space, but I feel just adding one example for ASLR doesn't serve it any justice.

Cracking The Egghunter

To me this module was a little bit boring as I have done egghunters for a long time before this course (I started using egghunters in exploits back when I did my OSCP to give you an idea).

That being said, I think it was still a very well written chapter. The Offensive Security guys take you though Skape's popular egghunter, how each piece of the code works, and how it all fits together, and then demonstrates it on a sample exploit. They also explain the benefits of using this egghunter vs making several long jumps.

Overall I liked this, but it was a bit repetitive for me having past experience in egghunters.

Windows TFTP Server

This was a nice chapter, and was really the section where I learned a lot. In this section one takes a look at a buffer overflow in a popular TFTP server and looks at how to write a Spike fuzzing template for it.

Along the way, I learned many mistakes that can be made when one tries to write a Spike fuzzer and learned how to make a Spike template for a target protocol fairly quickly.

From there one was able to write the fuzzer, run it, wait for a few minutes, and get a controllable crash. The rest of the chapter then walked through how to exploit the crash in a semi-difficult environment.

HP NNM

The monster, the beast, the main challenge, pain made in hell itself. Whatever you want to call it, this one is going to take at least 3-4 times the time of the other modules in order for you to fully understand it all. So don't be afraid of it, just realize its a fairly complex exploit.

Overall this module was probably the second one that really taught me a lot. From custom encoding shellcode to making my own shellcode to figuring out really stupid problems with my code, this one caused me a bit of grief and strife. But this was only a taste of what was to really come. Alas this was and still is to this day what I consider one of the nastiest exploits I have come across.

I really can't say too much about this one besides from that, just make sure you study this one well. A lot of the course's lessons and knowledge derive from this one section, so take some time out of your day to understand this section really well.

The Exam Try 1

So after 1 month of study and another few weeks off for vacation, I decided to do my OSCE exam. It was a tight squeeze to get it to fit in time, but I managed to make it work.

Boy. Did that thing kick my ass black and blue. For a good solid 8 hours I got stuck on one of the challenges, only to realize my mistake was due to trying to do things too fast. Once I figured that out, it only took me 2 hours to figure out how to get full privileges on that system.

Aside from that, I was only able to pop one other machine, however it was so easy for me that I didn't feel any satisfaction really in popping it minus the points value.

After that I was stuck with X (a number between 1 and 5) other machines. I didn't realize it at the time, but I had actually completed another without my knowledge, due to a misreading of the instructions. Later, on my second try, I realized this mistake and was able to fix it.

Post Exam Try

The other machines I was unable to compromise. At this point I was a messy pile of half stress, half satisfaction and half confusion. I had trained for this? I should be able to get at least a bit more than this? I mean I know its meant to be hard but it shouldn't be that bad right? It quickly came to me that I was going to have to do more research into the various sections I missed.

So I took some time off and researched whilst I had a few family vacations I couldn't move around (Greencards and other important stuff). Along the way I managed to find a vulnerability in Kolibri WebServer 2.0 via an overly long POST request (http://seclists.org/bugtraq/2014/Aug/86), and trained my skills in developing fuzzer templates for various protocols.

I also learned custom shellcode and made some nifty examples for use the second time around. I also made some tools to automate some of the problems that I had in the labs, which came in handy thought-out the exam, especially one of the tools which I estimate cut the time down for one of the sections by about 2 hours in total.

By the time I was done, I had working solutions for each of the targets in the exam lab ready to go. I then went ahead and rebooked my exam. This date was then moved again after I learned that I had to undergo dental surgery for my wisdom teeth which might potentially result in me being very out of it during the exam. As thus I then scheduled my exam for the Monday after the appointment, which also gave me the time to go see a friend (@TheColonial) and some mates (@stevelord, @n0x00, @_Freakyclown_) the day before for dinner.

The Exam Try 2

The second try of the exam was much much easier, as I had a general idea of my previous pitfalls and knew roughly what to expect and how to get around my previous issues that I faced.

The whole process ended up taking quite a long time as I had to do new screenshots for each of the hosts, and there were a lot of screenshots, but eventually I manged to complete the first two machines. By this point I was at pretty much the same point as last time.

I then tried the one I didn't get last time. For some reason the exploit worked locally, but not remotely. I checked with an Offsec admin that this was to be expected, and after confirming that it was, went back to work on the target. I tried many solutions against the target, all working locally but not remotely. Eventually I realized I was getting nowhere.

At this point I then went back to the other targets that I had missed and got them done. Having feeling satisfied that I had managed to nail the other ones, I went back to the challenge one.

From then on, this thing proceeded to kick my ass. Despite my best attempts, I was only able to get partial access to this box. However I didn't even know if I would get partial points on it. The instructions and specifications for the points for this target in particular where a little bit unclear and left me on the edge of passing.

Realizing this, I decided to send an email off to challenges AT offensive-security DOT co(take a guess you spam bots). However they said they would be unable to answer any of my questions until I submitted the exam documentation in. Alright then....guess theres only one way to figure this out.....going to have to do this report.

Writing the Report

Report writing is never fun, but this one was a real pain. In total it took me just under the 24 hours prescribed to write the report with a 4-5 hour nap during all of that. This was probably due to me including too much detail, and is something that I need to work on in my report writing. I like writing very detailed reports but there is a certain point where you just start adding detail for the sake of it rather than trimming it down to only what is needed to get your point across. Hopefully as I write more reports I'll learn from my mistakes and be able to tweak that but at present it remains one of my main pitfalls.

Anyway, after 24 long hours, I finally managed to get my report in by 11 am. At this point all I had left to do was wait for the results. After fixing some issues with Gmail being a right pain with the documentation format I eventually decided to submit everything as a text file with instructions on how to turn the files back into their respective formats to get around the filtering. At this point I was getting really tired, so I decided to go to sleep and check the results in 2 days.

2 days later went back to check my results. It turns out that within 24 hours of me taking the exam, they had emailed me to confirm that I had passed! I was ecstatic. Finally after all this time I had gotten the OSCE certification! All the hard work and pain had finally paid off in one spectacular email :)

Review and Reflections

Overall this course was a hell of challenge. But I would definitely recommend it to anyone who wants to improve their security skills to the next level. It is a lot of work and your going to need some time to understand all the concepts throughly, but it is well worth your time and will greatly help to advance your skills in the realm of web application security, exploit development and creative thinking.

What will I be doing on from here on out? Well to be honest I am not sure. I have a final year of university I need to finish first before I do anything job related. However at the same time with only about a class a day I might still have time to conduct spare research and activities outside of my classes and outside class research time (which will be needed for my dissertation). My primary focus this year is going to be my dissertation of course as that counts for two of my regular courses.

With that aside, I would quite happily do another Offsec certification. I have my eyes on AWE next, but due to the costs involved with that and a lack of sponsorship, I may have to wait for now whilst I save the money up for a hotel, the course, and food/general living expenses, as well as travel.

Anyway, I hope you enjoyed this review of the OSCE certification. Let me know if you agreed or disagreed with my opinion on anything in this post. I'm interested to hear what you think.

Tuesday, August 5, 2014

Lessons Learned from OSCE

Lesson 1: Things are Never What They Initially Appear to Be

Ouch. This one was a very tough lesson to learn, but it taught me a lot. A lot of things in the CTP exam appear to be easy or very hard or contain steps that make sense at first, but when you actually get down to them, they are either easier than you thought they were, or, more often, they take more jiggling than what was initially covered on the course.

A prime example of this was the NNM exploit. This one was a pain in the fing ass for lack of better words to describe it. For a good solid 3 weeks this thing proceeded to get me close to where I wanted (I'm being deliberately vague here to avoid tripping on to spoilers where Offsec might get offended), but it just wasn't quite there. Turns out in the end the exploit wasn't what I had initally envisioned it to be and I had to adjust my expectations and assumptions to get it correctly working again.

A simple change, but it drives a point home. Don't assume that something is easy or hard just cause someone else tells you it is. Take their advice into consideration for sure, but you won't know until YOU do it.

Lesson 2: Never Give Up

Woot, I've hit the first cheesy line of this entire thing. But its actually one of the most important on this list. There were many times in the exam (which as of writing, I still haven't passed) and the CTP coursework itself where I just felt like giving up. A few times I even decided to take the a few hours off cause of the rage that was enduced from continuously banging my head against the problem.

However one has to learn to continue on if you want to succeed. I still haven't managed to perfect this skill but OSCE has taught me that I need to really get a grip on this so as to prevent myself from wasting additional time. There were a few times in the exam where I took too long of a break cause I thought I wanted to just stop working.

I never wanted to plainly give up though, which is what kept me going in the end, but there were definitely a few moments where I just wanted to hit the sack and call it a day. Finding a motive that you want to achieve or a next small step will help you get over the ruts that occur when you just can't seem to get anywhere and you just want to throw the towl in.

Lesson 3: Time Management

Yeah. I suck at this more than others. Particularly with the OSCE exam. There is a lot of things going on there and you have to keep yourself aware of what your doing and how long you are spending on it. I ended up spending way too long on a particular task, which, while I did manage to crack at the end of the day, ended up taking a significant proportion of the exam time and left me too tired to end up getting the final target I needed.

Ironically enough, when I wasn't pressured by time, I managed to figure out how to get into the third target in matter of probably about 2 hours max. Its that exam pressure that can lead to you making stupid mistakes and lack of cohesive judgement. As @TheColonial helpfully pointed out to me throughout the exam (big thanks to him), its best to remain calm and focused. Panicking will only start to set you back and will result in you overlooking things that could be the key to your success.

Lesson 4: Your Never Truly Good At Something Until You Do It Hands On

Honestly I think a lot of people don't realize this. You can't simply read a book and expect to know how to do something. I'm not saying don't read books at all or just skip the theory. If you do that, well....good luck ;)

However what I am saying is that I do know of several people in my life or past life who seem to think that they can just read the book and then magically do the material when asked to. Sure, some people can do that by stroke of luck or very quick learning skills, but for the majority of us, your going to have to practice those skills hands on.

The reason for this is that I find there are a lot of things that are different between how someone describes something as happening, and what actually happens in real life. Especially on the CTP course, there a LOT of things that can go pear shaped really fast if you don't try things out and learn from your mistakes. This also applies to other concepts in general.

If you can I would suggest trying to build a lab and get some practice under your belt with real world concepts; it will help more than you think. I'm hoping to do this myself soon, and if I do, I'll try post a guide to help others out. There are already quite a few guides out there already for those who want to get set up now though ;) I'll leave you to go Google for them, but Rapid7 has a fairly nice one if you look that up :)

Lesson #5: Think O.T.B

In other words, think outside the box. Some of the best learning is done when you really stretch your mind to think of different possibilities that are outside of what you would consider normal. This kind of thinking also allows you to bypass assumptions that might have been put in place by developers or manufacturers and is a good skill to have in general as it allows you to flexibly adapt to different situations and craft solutions to them on the fly.

To give an example, say you have a file that your trying to hide from an antivirus. You could pack the file, but then the packer's signature might get detected. Whats another way you could get around it? Well you could try encrypt the packer's signature to get around the antivirus detection, but what obfuscating the file? Or how about encrypting only the sections that get detected? What if you don't include the payload in the file at all and instead download it from a remote source? What if you add in delays to the file's execution to hinder heriustics? What if you add delays and then split the program up into child processes that then report to one child process that kills the other children once it is done?

Theres a lot of different ways to get to the answer. Depending on your situation you may need to be more or less creative and put in more or less effort, but there is almost always a way to get to the solution. You just have to be patient and willing to get the job done ;)

Lesson #6: The Last One, Friends

Ok, kinda cheesy, but a good, close group of friends helps much more than you think it will. Especially in the OSCE exam where your emotions will be tested as you ride the emotional roller coaster that is that challenge.

You ideally should have a group of friends that come from different backgrounds. This will allow you to get detailed insight from different friends about various problems that your having from a variety of perspectives and skillsets, which will help you form a more accurate picture about the problem.

You might also find them helpful to have around when you simply want to bounce some ideas off of someone and explain your logic out loud to them, which can help you realize your errors when you have to explain them to someone else.

Conclusion

Hope that helped some people learn from some of the mistakes that I've had in the CTP course, even if they seem obvious or silly. There all my honest mistakes that I've made in the recent past so none of these are ones I've made up for demonstrations sake.

Let me know what you think of these, if you think there is anything else to add, or if I should start a list of tips and tricks from various mistakes people have made (could be a fun community list :) )

Thursday, April 24, 2014

Just a quick update to let you know a few changes that will be occuring. To start off, I have switched over emails from the old gmail one to riseup.net. The new email will be tekwizz123 *spamblock* @ riseup.net (obviously remove the spamblock part ;) ). For now this will act as a running test, and I've also added a PGP key for that email in the event anyone would like to send encrypted email for queries or otherwise.

In other news, I would like to discuss some plans that I have for summer. These are not finalised and may change, but the direction that I'm looking at is to try to obtain my OSCE certification sometime over this summer. Once that is done, I am also looking at beefing up my skills in web penetration testing, as I realize these are severely lacking at present and I would really like to improve on this.

To do this I'm planning on taking The Web Application Hacker's handbook and actually reading through it and doing all the examples from front to back. Along the way I'm hoping to also do some blog posts on this to serve as a reminder and to also try and help inform others who might also be looking to improve in this area.

Other than that, the main plan for the summer is to use the 3 months as effectively as possible in order to get my skills up to speed whilst learning as much as possible. I also have plans for a side project with my brother, so you might see a few details of that being posted on here from time to time if I discover something interesting ;)

One last final note. I will be presenting at Bsides London 2014 on the rookie track this year on the topic of metadata and Recon-ng. Recon-ng is an incredibly useful tool, but I feel it is missing out on an incredibly useful feature by not including the ability to extract information from the metadata of a company's public documents. I will be presenting on my work that I have done over the last 3 months on working on a solution to this and will be making the source code publicly available to everyone at the conference. Essentially its FOCA for Recon-ng :)

If this sounds interesting to you and you would like to contribute, please feel free to drop me a line giving your current skills and what you could bring to the project and I'm happy to work something out. There's a lot of things that still need to be done to bring the project up to scratch so don't feel like you're going to overcrowd the project at all ;) If you don't have a ticket to Bsides London, don't worry as I hear there will be videos being taken at the conference itself, so I'll try get a copy and post it online if I can.

Anyway, I think thats enough updates for now. Hope to see you all at Bsides, otherwise plans should start kicking into action at the end of May or beginning of June.

Sunday, February 9, 2014

Intro

Just before we start, a little shoutout to http://formatmysourcecode.blogspot.co.uk/ for making all the exploit code look neat n tidy in this post :)

The exploit we will be working on is the Audio Converter 8.1 SEH buffer overflow from sud0, as detailed here: http://www.exploit-db.com/exploits/13763/. We will need the following tools to develop this exploit:

Switching DEP On By Default

By default Windows 7 comes with OptIn DEP. This would essentially mean that when we exploit the program, the only protection it would have is ASLR. But hey, that would be boring right? I mean come on, only one protection? Nah, lets change this:

Click on Start in Windows, then right click on Computer and click properties you should see the following menu:

Click Advanced System Settings then click the Advanced tab:

Under Performance click Settings, then navigate to the Data Execution Prevention tab and click the option "Turn on DEP for all programs and services". You will have to restart your computer for the effects to take place.

Ok all good? Lets get started!

Baby steps Scotty....baby steps

So to start off, we need to figure out how to trigger the vulnerability. So lets start off with a very basic exploit structure. We'll use the following for the exploit:

We'll save this file as audioExploitDEPDemo.py. Run this python file and then run the resulting file as follows:

Find the the audconv.exe executable within the Audio Converter file in Program Files and open it in Immunity Debugger.

Next, click cancel on the popup menu that appears and then click on File -> Add Playlist.

The program will now hit an access violation. Click on View -> SEH Chain. You should now see that we have overwritten the SEH handler, as seen above.

Finding The Offsets

Ok, so now we know that the target is vulnerable to a SEH overwrite. So lets see if we cant find the offsets. Well we have mona.py installed, so why don't we generate a quick metasploit pattern to figure the offsets?

Ok I'm going to assume you know to reload the file by now. So lets restart the program, run our Python script and load the new .pls file that is created. The program crashes again. Lets see the SEH chain. The second entry is the SEH handler:

Ok so the NSEH handler is overwritten with 39724638 (remember this number may be different for you, this is just what I get on my machine so find this for your machine).

We can then find the offset by running:

!mona pattern_offset 39724638

The result is shown below:

We can see that it found our offset 4436 bytes in where we overwrote the NSEH handler. Lets change the exploit code to reflect this. Remember that we overwrite the NSEH first then the SEH handler in a SEH exploit, so lets change this slightly to reflect this.

If we run this python script and load the resulting .pls file into the program we get the following in the SEH chain view:

Nice, so now we can control the SEH chain.

Stack Pivoting - The Beginning of Our ROP Journey

Ok so now that we have control over SEH, we want to see how much we are away from the beginning of our payload on the stack. We then need to do a stack pivot (aka a stack adjustment) in order to change the top of the stack to point to our payload.

To start off with, lets replace the SEH overwrite with an address from the DLL. We know this because the main executable and the DLL are both not compiled with any protection (SafeSEH is enabled on the main executable, but we won't be using it for this exploit so its not a problem for us). You can verify this by doing:

!mona modules

Any address from the audconv.dll file will work though, I just chose a random one from within the DLL. Our new exploit should look like this:

Note that we are using little endigan here so the address is actually 0x1004C7A6 in my example. Using the new resulting file, we set a breakpoint on this address and run the program, which gives us the following:

If we double click on the current stack address in the lower right pannel, we can see the offset that we need to adjust the stack by to get it to point to the start of our payload.

This can be seen in the screenshot below:

So it looks like we will need to adjust the stack 0x8E0 bytes to get it to point to the beginning of our buffer. However since we are using ROP, we will be reusing the program's code. As thus we have to get the adjustment as close to 0x8E0 bytes as we can, but it won't be exact.

However we need this stack adjust instruction to replace our current SEH address, and we need it to have a RETN instruction afterwards so that we can continue executing instructions off of the stack. So we want it to look like:

Instruction to adjust ESP
RETN

We can use a useful feature of Immunity Debugger to find instructions that suit these requirements. To do this right click on the upper left panel in Immunity Debug, then select Search For -> All Sequences In All Modules.

After this type in:

ADD ESP, CONST
RETN

And click search. This will search all modules for all sets of instructions where some constant number is added to ESP and there is a RETN instruction following it. Remember that we are looking for a number above or equal to 0x8E0 but that is still fairly close to that number in audoconv.dll. The best one we can use that doesn't contain null bytes appears to be located at 0x1001A762:

Setting a breakpoint on this address and running the program with the new file gives us this:

If step though the program and execute the RETN instruction, we see that we land 0x814 bytes into our buffer. This is equivalent to 2068 bytes in decimal format.

Knowing this lets so some restructuring of our payload. We will have to subtract the 2068 bytes by 4 to get 2064, which is the number of bytes of junk we need before we insert the address that we want to use as our first ROP instruction:

If we then execute this without any breakpoints, the program should execute our GGGG instruction (sorry I lost the screenshot for this apparently, but you should see GGGG in EIP, if not, double check your work. If you still can't get it, feel free to contact me)

Ok, so this is all good. Now what we need to do is form a ROP chain. Remember mona.py from earlier? Well your going to love him right about now :)

At this point the sky opens up and ROP chains of awesomeness open up to us. Or in other words, we basically get free generated ROP chains that we can use. And who doesn't like a bit of automation every once in a while?

Once your PC unfreezes and mona finishes running, open the rop_chains.txt file (there will be several generated) which is located at:

What you want to now do is scroll down to the bottom where it shows ROP chains using the VirualAlloc() mechanism. It should look something like this:

At this point all we need to do is copy it across and incorporate it into our exploit, then fiddle around to make sure we get it to allocate our shellcode. With some shuffling around and organization of the length calculations, our new exploit code looks like this:

Run this new code and run the program with the new file. Set a breakpoint on the SEH handler, and step through the code with the F8 button whilst watching the stack. Eventually you should see the call to VirtualAlloc and its parameters on the stack. This should look something like the following:

If we look at the parameters to the VirtualAlloc call, we can see that the address pushed to the call is 0x0012D50C. We need to find out how far this is from the beginning of our buffer so that we can position the shellcode in the appropriate location.

We see that it is 0x854 or 2132 bytes till the allocation so we will need 2128 junk bytes before our shellcode for this to work correctly.