Some Observations On Duo Security's "WoW64 and So Can You" Paper

So presently I haven't been posting a lot due to ongoing work at NCC Group but I stumbled across something interesting I thought would be good for a quick post whilst reading Duo Security's "WoW64 and So Can You" paper. In the paper, they describe how many of EMET's protections, whilst properly applied in pure 32 and 64 bit contexts (with the limitation that a few ROP mitigations don't work so well on 64 bit programs if I recall correctly, though this may have been fixed since then), are not applied well or even at all within WoW64 contexts. As described very nicely within their paper (which I am just briefly sumarizing here for simplicity and convience's sake) WoW64 is essentially a compatability layer for 64 bit operating systems to run pure 32 bit applications within their 64 bit environment.

The real problem for EMET is that the way this is implemented is essentially to have two contexts running for the application at the same time, one to support 32 bit (aka protected mode) operations and one to support 64 bit (aka long mode) operations. When I say two contexts I really do mean two contexts here. There are sepearte TEBs (thread execution block, which handles the threads for the program), PEBs (process execution block, which contains data structures which apply for the entire process), and a number of different DLL imports and redirects which all help to ensure that the application is able to run on the 64 bit operating system.

The problem that occurs here when one considers that an application can switch between 32 bit and 64 bit modes during execution with a single instruction. At this point it becomes very hard for EMET to properly enforce it's protections as whilst it may intially implement it's function hooks, hardware breakpoints and other protection mechanisms under the assumption that the application is running as 32 bit code, as soon as the application switches to 64 bit mode, these protections are essentially rendered useless as now different code, libraries, and execution environments are being used which are no longer subject to the protections implemented on the 32 bit code. To add further complications to the matter, even if these protections where to somehow be brought over from the 32 bit code, one has to reimplement them in 64 bit code to match the new execution environment, otherwise they would not function correctly.

What I found particularly interesting was in their"Address Space Layout Section" where they described how they attempted to find where the 64 bit copy of ntdll.dll that was loaded into the WoW64 process is located so they can start calling functions from it within their shellcode. In particular I found particular interest in their second point, which I'll quote here:

The order in which modules are loaded is reliable, resulting in predictable module alignment presuming no change in module size (in practice, we have found this alignment to be reliable across a variety of patch levels).(https://www.duosecurity.com/static/pdf/WoW64-Bypassing-EMET.pdf)

You may recall my post An Theoretical Approach to Getting Around EMET's EAF Protection in which I described a way to potentially get around EMET's EAF protection in a similar manner. By looking up a function with the export table which is located in the same DLL as the function we wish to call, we were able to obtain a base address from which to start our calculations. From there we abused the fact that functions within a DLL tend to be located at set offsets from one another to find the location of the function we wished to call by taking the address of the function that we had located from the export table and adding or subtracing the offset to get the address where our desired function had been loaded in memory. I did also note after some comments from Reddit that the exact offset may change across patch levels due to the fact that the size of different functions within the DLLs may change, thus affecting the exact size of the offsets between functions.

In a similar manner, Duo Security managed to abuse the fact that the order in which the DLL's are loaded into a WoW64 process on Windows 7 are always located at set offsets from one another, assuming no change in module size. That sounds rather familar right? They even mention how changes in module (aka DLL) size and patch versions will mess up their technique. So it seems to be rather similar to the technique that I ended up using in my research paper.

I just wanted to point this out in case anyone was interested and also to bring up another point to think about when considering EMET bypasses, namely that whilst ASLR does have a large impact by preventing an attacker from learning the location where modules are loaded in memory, there are still ways, in the right environment, by which one can figure out their location without resorting to memory leaks or other exploits.

Will be interesting to see if anyone takes Duo Security's research and applies it to some real world public exploits as I would be interested to see how such techniques handle themselves when confronted with different vulnerable targets and exploit scenarios.

Until next time,
Grant (aka @tekwizz123)

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

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

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.

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