Offensive Security » Exploit Developmenthttps://www.offensive-security.com
Offensive SecurityTue, 03 Mar 2015 19:24:15 +0000en-UShourly1http://wordpress.org/?v=4.1.1Disarming and Bypassing EMET 5.1https://www.offensive-security.com/vulndev/disarming-and-bypassing-emet-5-1/
https://www.offensive-security.com/vulndev/disarming-and-bypassing-emet-5-1/#commentsTue, 18 Nov 2014 14:46:58 +0000http://www.offensive-security.com/?p=10400Last week Microsoft released EMET 5.1 to address some compatibility issues and strengthen mitigations to make them more resilient to attacks and bypasses. We, of course, were curious to see if our EMET 5.0 disarming technique has been addressed by the latest version of the toolkit.
]]>EMET 5.1 released

Last week Microsoft released EMET 5.1 to address some compatibility issues and strengthen mitigations to make them more resilient to attacks and bypasses. We, of course, were curious to see if our EMET 5.0 disarming technique has been addressed by the latest version of the toolkit.

After a quick analysis of the EMET.dll function that verifies which protection needs to be applied whenever a critical function is called, it is clear that now the global variable (EMET+0xF2A30 in EMET 5.1) we used in our previous techniques to disarm EMET 4.X and 5.0 is better protected.

Mitigations Switch Hardening

As previously seen, this global variable stores a pointer to a structure (we called it CONFIG_STRUCT in our previous posts) that among other information, includes a flag acting as a general switch for most of the EMET mitigations at CONFIG_STRUCT+0x558. EMET 5.0 hardened this pointer by encoding it with the Windows API EncodePointer. In EMET 5.1 a pointer to CONFIG_STRUCT is stored in another variable that we called EMETd, as can be seen in the next figure. It is the EMETd address that is now stored in the global variable at EMET+0xF2A30.

EMETd is a 12 byte structure defined as follows:

struct EMETd{
DWORD size;
LPVOID lpCONFIG_STRUCT;
DWORD writable;}

Both CONFIG_STRUCT and EMETd are initialised in a function at EMET+0x254D5 (refer to previous figure). EMET 5.1 adds an “extra safety layer” by using the result of a CPUID instruction to xor-encode the EMETd pointer, after encoding it with EncodePointer.

CPUID is called passing 0x1 as an argument (EAX=0x1), which means the toolkit uses “Processor Info and Feature Bits” to perform the xor encoding. The instruction returns the CPU’s signature in EAX, feature flags in EDX and ECX and additional feature info in EBX.

Another important change is the fact that the data structure is now located on a read-only memory page, which of course increases the difficulty in switching off EMET mitigations by overwriting the general switch flag.

Adapting the Disarming Approach

Rather than trying to build a ROP chain to recreate the xor-decoding logic, we tried to look for an easier option. More specifically we looked at borrowing a code chunk in an EMET.dll function that would do the work for us. The code starting at basic block EMET+0x67372 is a good candidate, as it decodes the EMETd pointer and returns the CONFIG_STRUCT address in the EDX register.

As shown in the previous figure, to successfully return from the above code, we need to control both EBP and ESI registers. The next step is to take care of the memory page protection.

In our last post we showed how CONFIG_STRUCT can be leveraged to obtain a list of unhooked Windows APIs, and we stressed the fact that this could lead to further points of failure. In our case, we can for example, access ntdll!NtProtectVirtualMemory at CONFIG_STRUCT+0x1b8 (the offset didn’t change from EMET 5.0 to 5.1) and change the CONFIG_STRUCT memory page protections before zeroing out the global mitigations switch at CONFIG_STRUCT+0x558.

Of course once the unhooked ntdll!NtProtectVirtualMemory is available to us, other options are possible – like for example directly patching EMET shims in order to bypass the checks.

EAF and EAF+ were once again bypassed by calling the unhooked version of ntdll!NtSetContextThread located at POINTER(CONFIG_STRUCT+0x518) as we did for EMET 5.0.

Wrapping Up

To summarise the technique, a successful disarming ROP chain will need to perform the following steps:

Gather the EMET.dll base address.

Get the “decoding helper” code at address EMET+0x67372.

Return into EMET+0x67372 and obtain the CONFIG_STRUCT address in the EDX register.

Call ntdll!NtProtectVirtualMemory to make the CONFIG_STRUCT memory page writable.

Zero out the global protections switch at POINTER(CONFIG_STRUCT+0x558).

We have used this technique and implemented a proof of concept bypass using the Internet Explorer 8 Fixed Col Span ID exploit we’ve used to bypass EMET 4.x and 5.0. The full EMET 5.1 disarming exploit code can be downloaded from the Exploit-DB. The technique was tested against 32-bit systems and results were compared across different operating systems (Windows 7 SP1, Windows 2008 SP1, Windows 8, Windows 8.1). A video of this exploit in action can be seen below:

Conclusion

We started looking at EMET since version 4.0 and it’s come a long way since. There’s no doubt that Microsoft are stepping up their efforts at making EMET ever more effective. This sort of layered defense goes a long way in disrupting commodity attacks and increasing the level of effort required for successful exploitation.

]]>https://www.offensive-security.com/vulndev/disarming-and-bypassing-emet-5-1/feed/0Disarming EMET v5.0https://www.offensive-security.com/vulndev/disarming-emet-v5-0/
https://www.offensive-security.com/vulndev/disarming-emet-v5-0/#commentsMon, 29 Sep 2014 17:11:39 +0000http://www.offensive-security.com/?p=10230In our previous Disarming Emet 4.x blog post, we demonstrated how to disarm the ROP mitigations introduced in EMET 4.x by abusing a global variable in the .data section located at a static offset. A general overview of the EMET 5 technical preview has been recently published here. ]]>INTRODUCTION

In our previous Disarming Emet 4.x blog post, we demonstrated how to disarm the ROP mitigations introduced in EMET 4.x by abusing a global variable in the .data section located at a static offset. A general overview of the EMET 5 technical preview has been recently published here. However, the release of the final version introduced several changes that mitigated our attack and we were curious to see how difficult it would be to adapt our previous disarming technique to this new version of EMET. In our research we targeted 32-bit systems and compared the results across different operating systems (Windows 7 SP1, Windows 2008 SP1, Windows 8, Windows 8.1, Windows XP SP3 and Windows 2003 SP2). We chose to use the IE8 ColspanID vulnerability once again in order to maintain consistency through our research.

ROP PROTECTIONS CONFIGURATION HARDENING

The very first thing that we noticed is that the global variable we exploited to disarm the ROP Protections (ROP-P) routine is not pointing directly to the ROP-P general switch anymore. This variable, which is now at offset 0x000aa84c from the EMET.dll base address, holds an encoded pointer to a structure of 0x560 bytes (See CONFIG_STRUCT in Fig. 1). The ROP-P general switch is now located at CONFIG_STRUCT+0x558 (Fig. 1, Fig. 2).

Figure 2: ROP-P General Switch

Encoded pointers are used to provide a layer of protection for the actual pointer values. These pointer values can be decoded by using the appropriate DecodePointer Windows API. Our first idea was to try to use the DecodePointer function to get the required pointer and then to zero out the general ROP-P switch. This API can usually be found in the Import Address Table (IAT) of several modules loaded by target processes. Additionally, since EMET.dll needs DecodePointer, we can extract the offset from the DLL base address directly from its IAT. The first step, as shown in our previous blog post, is to gather the EMET.dll base address. In this particular case, we will also save the EMET base address somewhere in memory in order to get the absolute address of DecodePointer later on. Once we decode the encoded pointer, disarming ROP becomes a very similar exercise as in our previous exploit.
The following ROP gadgets were used to disable the ROP Protections in the IE8 ColspanID exploit:

EAF

In our previous blog post, we bypassed EAF by using a known technique presented by the security researcher Piotr Bania. The technique makes use of the Windows syscall NtSetContextThread to clear the hardware breakpoints set by EMET on the Export Address Table of kernel32.dll and ntdll.dll. EMET 5 now protects the KERNELBASE.dll Export Address Table as well, but the only new protection implemented in version 5 against the use of the above technique is that now NtSetContextThread as well as NtContinue (which can also be used in a similar way to bypass EAF) are hooked by the toolkit.
“Unfortunately”, the hook eventually calls into the ROP-P routine, and since all the checks are already disarmed by the previous ROP chain, it is completely ineffective. The result is that no further changes to the shellcode were needed to bypass EMET 5 with all of its mitigations enabled except for EAF+. By resolving and calling NtSetContextThread, we were once again able to bypass EAF and successfully obtain a remote shell.

EAF+

EAF+, on the other hand, introduces a few extra security checks. First of all, it offers the possibility of blacklisting specific modules that should never be allowed to read protected locations (EAT and MZ/PE header of specific modules). For IE, EAF+ blacklists by default mshtml.dll, Adobe Flash flash*.ocx, jscript*.dll, vbscript.dll and vgx.dll. However, since in our case we are resolving NtSetContextThread by directly calling GetProcAddress, we are implicitly bypassing this mitigation.
When we ran our exploit with EAF+ enabled, IE crashed without any explanations or EMET-related log entries in the Windows Event Viewer. Our first thought was that EMET detected the stack register being out of the allowed boundaries, as this check and the detection of a mismatch of stack and frame pointer registers are the other two mitigations introduced by EAF+.
We were able to verify this by setting a breakpoint at EMET+0x40BA6 (Fig. 3), which is a basic block belonging to the EAF/EAF+ ExceptionHandler (EMET+0x4084A) installed by the toolkit.

Figure 3: EAF+ Stack Register Check

Since we have already disarmed EMET ROP mitigations as well as DEP/ASLR at this point, we were able to bypass the stack registers check executing the following instructions just before resolving NtSetContextThread:

The first three instructions simply recover the StackBase pointer value for the executing thread from the Thread Environment Block (TEB). We then add a negative offset to fall within StackBase and StackLimit and set ESP to point to this value.

At this point, we were happy enough as our exploit was working nicely with all the protections enabled. However, as we were reversing the EAF/EAF+ ExceptionHandler, we noticed something interesting. At offset EMET+0x00040E75 (Fig. 4) there is a call to NtSetContextThread, but rather than calling into the hooked Windows Native API, EMET calls a stub that sets up the syscall number into the EAX register and then jumps into NtSetContextThread+0x5 to bypass the EMET shim (Fig. 5).

Figure 4: Call to the Unhooked NtSetContextThread

The interesting part is that the pointer to this stub is an entry in the configuration structure that we used to disarm the ROP Protections. In other words, we can use this stub as an alternative way to bypass EAF+ as we can directly call into POINTER(CONFIG_STRUCT+0x518) without the need to resolve the NtSetContextThread address.

Figure 5: NtSetContextThread unhooked stub

This discovery made us even more curious and we started to snoop around the entire structure. We saw that at specific static offsets from the beginning of the structure, you can find pointers to respective stubs for all the hooked Windows APIs:

This is particularly troublesome as it provides the attacker with access to the most powerful APIs completely unhooked and without the need of resolving their addresses once EMET CONFIG_STRUCT is gathered. However, since Deep Hooks are enabled by default, if the attacker plans to use one of the above APIs without disarming EMET in first place, they would need to call the deepest API in the chain.

As usual, the full exploit can be found at The Exploit Database. The exploit uses the stub at POINTER(CONFIG_STRUCT+0x518) to bypass EAF+ as well as the ROP chain presented in this blog post.

Figure 6: Remote Shell with EMET 5 enabled

ASR

The Attack Surface Reduction (ASR) feature in EMET 5.0 helps reduce the exposure of applications by preventing the loading of specific modules or plugins within the target application. This protection can really be effective in cases where an attacker forces the target application to load a specific DLL to bypass ASLR (Java msvcr71.dll is a very typical case).
Protection provided by ASR does not affect our exploit in any way because we are using a memory leak to bypass ASLR in the IE ColspanID exploit. We are also not loading any extra modules to bypass DEP. Nevertheless, we conducted some research to understand where this mitigation is located within EMET.dll. Once again, we noticed that the actual checks are done within the very same ROP-P routine, thereby making ASR entirely ineffective once the ROP-P general switch has been zeroed out. However, if an attacker is planning to force the target application to load a blacklisted module to bypass ASLR, he wouldn’t be able to disarm the EMET ASR protection using our technique before loading the forbidden DLL.

PORTABILITY

Our testing on older operating systems shows that the offset to the CONFIG_STRUCT global variable changes to 0x000b0b4c due to the fact that a different EMET.dll is in use.
Nevertheless, offsets within the structure are consistent in all pre- and post-Vista Windows versions, both for the ROP-P general switch and for the unhooked APIs stubs. The only real differences are present when certain API functions are simply not available in the OS, such as in the case of KERNELBASE.DLL in Windows versions prior to Windows 7.

CONCLUSION

As we managed to successfully demonstrate, the difficulty in disarming EMET 5 mitigations has not increased substantially since version 4.x. More than anything, only our ROP chain has increased in size, while achieving the same effect of bypassing the protections offered by EMET. Here’s a video of our PoC IE exploit bypassing EMET v5.0:

]]>https://www.offensive-security.com/vulndev/disarming-emet-v5-0/feed/0Symantec Endpoint Protection 0dayhttps://www.offensive-security.com/vulndev/symantec-endpoint-protection-0day/
https://www.offensive-security.com/vulndev/symantec-endpoint-protection-0day/#commentsTue, 29 Jul 2014 14:46:22 +0000http://www.offensive-security.com/?p=10123In a recent engagement, we had the opportunity to audit a leading Antivirus Endpoint Protection solution, where we found a multitude of vulnerabilities. Some of these made it to CERT, while others have been scheduled for review during our upcoming AWE course at Black Hat 2014, Las Vegas. Ironically, the same software that was meant to protect the organization under review was the reason for its compromise.]]>Symantec Endpoint Protection Vulnerability

In a recent engagement, we had the opportunity to audit the Symantec Antivirus Endpoint Protection solution, where we found a multitude of vulnerabilities. Some of these made it to CERT, while others have been scheduled for review during our upcoming AWE course at Black Hat 2014, Las Vegas. Ironically, the same software that was meant to protect the organization under review was the reason for its compromise.

We’ll be publishing the code for this privilege escalation exploit in the next few days. In the meantime, you can check out our demo video of the exploitation process – best viewed in full screen.

More shameless Kali Dojo plugs

If you’re attending the Black Hat, Brucon or Derbycon 2014 conferences, don’t forget to come by our free Kali Dojo Workshops for some serious Kali Linux fu. See you there!

]]>https://www.offensive-security.com/vulndev/symantec-endpoint-protection-0day/feed/0Disarming Enhanced Mitigation Experience Toolkit (EMET)https://www.offensive-security.com/vulndev/disarming-enhanced-mitigation-experience-toolkit-emet/
https://www.offensive-security.com/vulndev/disarming-enhanced-mitigation-experience-toolkit-emet/#commentsTue, 01 Jul 2014 19:04:08 +0000http://www.offensive-security.com/?p=10054
With the emergence of recent Internet Explorer Vulnerabilities, we've been seeing a trend of EMET recommendations as a path to increasing application security. A layered defense is always helpful as it increases the obstacles in the path of an attacker. However, we were wondering how much does it really benefit? How much harder does an attacker have to work to bypass these additional protections? With that in mind, we started a deep dive into EMET. ]]>
With the emergence of recent Internet Explorer Vulnerabilities, we’ve been seeing a trend of EMET recommendations as a path to increasing application security. A layered defense is always helpful as it increases the obstacles in the path of an attacker. However, we were wondering how much does it really benefit? How much harder does an attacker have to work to bypass these additional protections? With that in mind, we started a deep dive into EMET.

The protections implemented by EMET are well described in its user guide. In addition, there are also some publicly available papers that describe various EMET mitigation bypasses, such as EMET 4.1 Uncovered and Bypassing EMET 4.1.

Once we test the exploit against our system with EMET installed, we notice that it is effectively stopped, with a closer look at the event logs showing that the HeapSpray mitigation from EMET caused our exploit to fail.

As noted in the EMET 4.1 Uncovered paper, this protection consists of allocating guard pages at commonly used addresses in current exploits however, as the paper mentions, this can easily be bypassed by choosing a different address to which you redirect execution to. Running the exploit again still causes EMET mitigations to kick in however, this time we see that instead of the previous HeapSpray mitigation, we are stopped by the StackPivot one.

Looking at previous publications that discuss EMET mitigation bypasses, we see that the StackPivot protection checks whether or not the stack has been pivoted, with this check being done upon entering a critical function. The list of critical functions can be reviewed in EMET 4.1 Uncovered. In our case, the critical function was “VirtualProtect”, which is one of the common APIs used to bypass DEP.

Since bypassing EMET mitigations has been thoroughly discussed in Bypassing EMET 4.1, we wanted to take a different approach. Instead of bypassing the mitigations introduced by EMET, we focused more on finding a way to disarm EMET. The main advantages of such a method are:

The ability to use generic shellcode such as the ones generated by Metasploit;

A generic way to disable all protections rather than dealing with them one by one during the development cycle of an exploit;

Not having to rely on functions that are not critical to EMET when trying to defeat the MemProt ROP protection, especially when having “Deep Hooks” enabled.

After taking a close look at EMET.dll, we noticed that the ROP mitigations provided are controlled by two global variables in the .data section, which are located at static offsets. Of these two variables, the first one is probably the most interesting as it acts as a switch to enable or disable the entire set of ROP protections at runtime. To make things even easier, this global variable is located on a memory page marked with read/write permissions. At this point, the security implications of these findings are becoming more apparent. If we manage to zero out the general switch, all the ROP mitigations implemented by EMET would be disabled. This requires an attacker to build a ROP chain that will dynamically retrieve the base address of EMET.dll and overwrite the global variable with a zero.

The DLL we use to generate our ROP chain, as do many others, imports kernel32!GetModuleHandle. Since we have the base address of the DLL, we can easily fetch GetModuleHandle from the Import Address Table (IAT). Also, we are not parsing the Export Address Table of kernel32.dll or ntdll.dll, we will not trigger the EAF checks from EMET. In addition, GetModuleHandle is not considered a critical function by EMET. The ROP chain used can be observed below:

If we execute our exploit at this stage with our debugger attached, we successfully receive our shell however, as soon as we try it outside of the debugger, we notice that the exploit no longer works. This is due to the EAF checks which kick in once the generic/Metasploit shellcode tries to parse the export table address of kernel32.dll. This is confirmed by attaching a kernel debugger to the exploited process.

EAF bypass techniques have been discussed in the past and we decided to disarm EAF using a method posted by the security researcher Piotr Bania. We chose this method as it would allow us to keep our generic/Metasploit shellcode without any modifications. The exploit code was modified to resolve the function using kernel32!GetProcAddress obtained from the IAT of our DLL rather than hard-coding the systemcall value of ntdll!NtSetContextThread.

After all the changes have been made, we successfully get a shell outside of the debugger. The full EMET-disarming exploit code can be downloaded from the Exploit-DB.

We have not seen this method of bypassing EMET in public exploits, however we do believe that Microsoft became aware of it as it has been corrected in Technical Preview versions of EMET 5 and greater.

What this shows is that while EMET is definitely a good utility and raises the bar for exploit developers, it is not a silver bullet in stopping these types of attacks. We have been able to modify this example to disarm an EMET v5 preview and are waiting to see what the final release will look like. Those of you that are coming to our sold out AWE class at Black Hat Vegas will have the opportunity explore EMET hands on in one of the modules that will be covered in the class.

Of course, a video of this process is in order. Best viewed in HD and full screen!

]]>https://www.offensive-security.com/vulndev/disarming-enhanced-mitigation-experience-toolkit-emet/feed/0NDPROXY Local SYSTEM exploit CVE-2013-5065https://www.offensive-security.com/vulndev/ndproxy-local-system-exploit-cve-2013-5065/
https://www.offensive-security.com/vulndev/ndproxy-local-system-exploit-cve-2013-5065/#commentsWed, 04 Dec 2013 02:11:58 +0000http://www.offensive-security.com/?p=9129In the past few days there has been some online chatter about a new Windows XP/2k3 privilege escalation, well documented by FireEye. Googling around, we came across a Twitter message which contained a link to a Chinese vulnerability analysis and PoC.]]>In the past few days there has been some online chatter about CVE-2013-5065, a new Windows XP/2k3 privilege escalation, well documented by FireEye. Googling around, we came across a Twitter message which contained a link to a Chinese vulnerability analysis and PoC for CVE-2013-5065.

Due to the fact that the extended instruction pointer is set to 0x00000038 at the time of the crash, this bug can easily be exploited on Windows XP, which offers little resistance, as it allows non-privileged users to map the null page within the context of a user process. From there, it was trivial to produce a fully working exploit, which we will have posted on the Exploit-DB.

]]>https://www.offensive-security.com/vulndev/ndproxy-local-system-exploit-cve-2013-5065/feed/0Fun with AIX Shellcode and Metasploithttps://www.offensive-security.com/vulndev/aix-shellcode-metasploit/
https://www.offensive-security.com/vulndev/aix-shellcode-metasploit/#commentsTue, 20 Nov 2012 13:53:50 +0000http://www.offensive-security.com/?p=8382In one of our recent pentests, we discovered an 0day for a custom C application server running on the AIX Operating System. After debugging the crash, we discovered that the bug could lead to remote code execution and since we don't deal very often with AIX exploitation, we decided to write an exploit for it. The first steps were accomplished pretty quickly and we successfully diverted the execution flow by jumping to a controlled buffer. At this point, we thought we could easily generate some shellcode from MSF and enjoy our remote shell.]]>AIX Shellcode and Metasploit

In one of our recent pentests, we discovered an 0day for a custom C application server running on the AIX Operating System. After debugging the crash, we discovered that the bug could lead to remote code execution and since we don’t deal very often with AIX exploitation, we decided to write an exploit for it. The first steps were accomplished pretty quickly and we successfully diverted the execution flow by jumping to a controlled buffer. At this point, we thought we could easily generate some shellcode from MSF and enjoy our remote shell.

MSF AIX Shellcode Failure

Unfortunately for us, none of the MSF PowerPC payloads was working correctly. As you can see in the following pictures, the shellcode embedded in a simple C program, is executing “/bin/csh” but it’s not binding it to a tcp port as it should.

At this point, we were forced to dig around a bit more into the AIX shellcode internals in order to understand what was wrong.

Metasploit Source to the Rescue

As usual, the Metasploit framework is a huge source of information and by looking at the code of an AIX bind shell present in the external subdirectory (/opt/metasploit/msf3/external/source/unixasm/aix-power-bndsockcode.c in Backtrack), we realized what was going on:

The bindshell code in the above picture supports different versions of the AIX operating system but even minor version changes in the OS have an impact on the payload implementation. By looking at the actual msf bindshell payload module (/opt/metasploit/msf3/modules/payloads/singles/aix/ppc/shell_bind_tcp.rb in Backtrack) , it became evident that the differences are related to the system call numbers used in order to invoke the operating system services.

A quick Google search on the topic confirmed all of the above:

AIX Shellcode in Metasploit

All of the AIX metasploit payload modules import the aix.rb library, which can be found at /opt/metasploit/msf3/lib/msf/core/payload/aix.rb in BackTrack. Looking through the code in this library helps provide us with a direction to follow in getting our shellcode to work.

The easiest way to port the existing MSF AIX shellcodes to other operating system versions is by adding a ruby hash with the relative sys call set to the aix.rb library:

At this point, we identified the target OS version of our exploit:

aix-box$ oslevel -s6100-07-00-0000

This above output tells us that we are running AIX Version 6 Technology Level (TL) 7 with no service packs (00-0000). The term Maintainance Level in the above tweet is now reserved for legacy AIX systems. The new IBM methodology dictates two TL releases per year.

Finding System Call Numbers

To identify the right system call numbers for our AIX specific version, we compiled a C program that uses the same function set used by our shellcode. A bind shell C program found on the Internet, for example, can do the trick:

By setting a few breakpoints on the involved functions (socket, bind, listen, accept, close, kfcntl, and execve), we can step through the system call invocation in gdb and check the argument values:

In the PowerPC architecture, the sc instruction is used whenever the operating system services are to be called. The r2 CPU register denotes the system call number and registers r3-r10 are appropriately filled with the given system call arguments (AIX 6.1 Information, “AIX PowerPC buffer overflow step by step”). In our case, r2, before branching the ctr register to execute the system call, is holding the value 254; we now know the socket sys call number for AIX 6.1.7.

We then identified the remaining sys call numbers and filled up an aix_617_syscalls hash in the aix.rb library:

and added a line to the version hash:

Our final step was to generate and test our newly edited payload:

Success! Our AIX shellcode works as expected. We have updated the MSF AIX payloads to include these newer versions of AIX Patch Levels – these should be committed to Metasploit soon.

]]>https://www.offensive-security.com/vulndev/aix-shellcode-metasploit/feed/0CA ARCserve – CVE-2012-2971https://www.offensive-security.com/vulndev/ca-arcserve-rwslist-remote-code-execution/
https://www.offensive-security.com/vulndev/ca-arcserve-rwslist-remote-code-execution/#commentsTue, 30 Oct 2012 18:12:27 +0000http://www.offensive-security.com/?p=8278On a recent penetration test, we encountered an installation of CA ARCserve Backup on one of the target systems that piqued our interest. Like most "good" enterprise applications, ARCserve has processes that are running as SYSTEM so naturally, we went straight to work looking for vulnerabilities.]]>On a recent penetration test, we encountered an installation of CA ARCserve Backup on one of the target systems that piqued our interest. Like most “good” enterprise applications, ARCserve has processes that are running as SYSTEM so naturally, we went straight to work looking for vulnerabilities.

Affected Product Information

According to the vendor, CA ARCserve Backup delivers industry-leading, enterprise-class data protection for a wide range of operating environments. The CA ARCserve authentication service (caauthd.exe) validates the caroot user login and equivalence. It is required for GUI and backup server communication and uses a dynamic TCP port to serve incoming connections. Through our analysis, CA ARCserve Backup r16 sp1 fully patched was proven to be vulnerable and earlier versions, including r12.5, r15.0 and r16.0, were found to be vulnerable as well.

Vulnerability Description and Impact

By replacing a particular xdr_rwslist object expected in an RPC authentication packet with another xdr_rwobject, the function sub_416E80 will call a non-existent or invalid virtual function that can be controlled by the attacker. Authentication is not required to trigger the bug and successful exploitation of this vulnerability for the caauthd.exe process will lead to remote code execution with NT AUTHORITY\SYSTEM privileges. Failed exploitation attempts will lead to a denial of service condition on the target system.

Since the caauthd.exe service does not check the type of the xdr_rwobject before dereferencing its vtable at address 0x00416F40 (Figure 1), omitting the RWSList object container can allow an attacker to load an invalid address into the EAX register, eventually controlling the execution flow (CALL EAX instruction at 0x00416F48, Figure 1).
The Exception Analysis previously presented refers to the caauthd.exe service crash induced by the following RPC packet (opcode 0x7a):

In the above code, the xdr_rwlist object was simply removed from the original buffer and sent to the target. As can be seen below, the vtable for the xdr_rwstring object does not contain a valid virtual function at offset +64h:

The resultant crash leads us to reach the following conclusion: the “vtable escape” forces the value 0x2f to be loaded into the EIP register instead of a valid virtual function address, causing an access violation while trying to execute instructions at that invalid memory location.

Proof of Concept

One possible way to control the execution flow is to replace the xdr_rwstring presented in the previous section with another xdr_rwobject. To quickly prove remote code execution with Data Execution Prevention disabled, we used the xdr_rwtime object. For this object, the vtable entry at offset 64h points to the middle of an ASCII string belonging to the .rdata section of rwxdr.dll as shown below.

Since the address 0x276e7365 falls within the heap range, an attacker could try to remotely allocate shellcode at that memory location, sending malicious crafted packets to the caauthd.exe service, before triggering the vulnerability.
“Unfortunately”, at least one function was proven to leak memory while processing incoming RPC packets. The function rwxdr.dll!xdr_string3, which performs the username xdr_string3 structure deserialization, doesn’t seem to correctly deallocate memory after its use.

Figure 2: Allocating Function Used for Remote Heap Spray

As a result, sending multiple crafted RPC packets and specifying a large size for the username field, an attacker can reach the 0x276e0000 memory range in a couple of minutes.

During a routine scan of new vulnerability reports for the Exploit Database, we came across a single post in full disclosure by Martin Tschirsich, about a Remote Code Execution vulnerability in FreePBX. This vulnerability sounded intriguing, and as usual, required verification in the EDB. At first glance, the vulnerability didn’t jump out at us, especially as we are not familiar with the inner workings of asterisk. After a couple of emails back and forth with Martin, the path to code execution became clearer:

The $to paramteter in recordings/misc/callme_page.php does not get sanitized. After a short trip in between various functions, $to ends up written to the Asterisk Management Interface socket.

We quickly whipped up a Metasploit module for this, and gave it a shot.

The exploit worked out of the box for both the FreePBX and Elastix community distributions, given a known extension or username. The malicious URL actually triggers a phone call to the specific extension, and when the call is answered (or goes to voicemail), our payload is executed on the VOIP server.

Interestingly enough, Elastix has the following in its /etc/sudoers file:

This reminded us of a paper we once read (http://www.exploit-db.com/papers/18168/) which discussed a situation exactly like this. By abusing the nmap –interactive command we can easily escalate to root privileges:

The vendor has been contacted and provided with a patch several times since Jun 12, 2011. Since no intention to address this issue was shown, I felt it was in the best interest to disclose the vulnerability.

ph33r.

Elastix FreePBX Exploit in Action

Lastly, the nerd in us found it pretty awesome that an exploit calls you…If you’re using FreePBX systems…you might want to think twice before answering your phone….

]]>https://www.offensive-security.com/vulndev/freepbx-exploit-phone-home/feed/0MS11-080 Exploit – A Voyage into Ring Zerohttps://www.offensive-security.com/vulndev/ms11-080-voyage-into-ring-zero/
https://www.offensive-security.com/vulndev/ms11-080-voyage-into-ring-zero/#commentsTue, 06 Dec 2011 06:00:27 +0000http://www.offensive-security.com/?p=4483Every patch Tuesday, we, like many in the security industry, love to analyze the released patches and see if any of them can lead to the development of a working exploit. Recently, the MS11-080 advisory caught our attention as it afforded us the opportunity to play in the kernel and try to get a working privilege escalation exploit out of it.]]>Every patch Tuesday, we, like many in the security industry, love to analyze the released patches and see if any of them can lead to the development of a working exploit. Recently, the MS11-080 advisory caught our attention as it afforded us the opportunity to play in the kernel and try to get a working privilege escalation exploit out of it.

After downloading the patch from the Microsoft website, we extracted it, decompiled the afd.sys driver, and ran a diff on an unpatched version. The results of our diff showed that only the AfdJoinLeaf function was changed:

In analyzing the vulnerable AfdJoinLeaf function, we determined that it could be triggered by sending a specific IOCTL (0x120bb) to the afd driver:

From the patch diff, we saw that only one code chunk was changed at 00016CFC but in order to reach the block, a few branches in the code need to be taken by precisely crafting the DeviceIOControlFile input buffer beginning with the Input/Output buffer size:

Our next requirement is that the 4th DWORD in the input buffer must be 0x00000001:

The value pointed to by (input buffer + 0x10) increased by 0x8 must be less or equal to (input buffer size – 0xC):

At this point, we have bypassed the necessary checks and have made it to the vulnerable code chunk:

Now, by setting the size of the output buffer to 0, we can bypass the code that checks if the output buffer is a writable address residing in user space. By circumventing this check, we will be able to specify any kernel address we choose as the address for the output buffer.

However, in the AfdJoinLeaf function, there doesn’t seem to be an obvious way to trigger the pointer overwrite. One possible path is to craft our attack to reach the call to AfdRestartJoin in the basic block at 00016F54:

This function, once reached, will eventually call AfdConnectApcKernelRoutine:

AfdConnectApcKernelRoutine will try to write a NTSTATUS code in the IRP output buffer. In order to reach AfdRestartJoin, we once again need to take a couple of branches in the right direction, beginning with the branch at 0x00016DBD. The stack variable input+8 must be equal to 0x00000000:

In the branch at 0x00016FEA, the socket state is checked. We need to have a TCP socket in the CONNECTING state (0x2) in order to take the jump and get to AfdRestartJoin:

Now, with the various checks successfully bypassed, we reach the AfdRestartJoin function:

We are getting closer to the end at this point but we are still passing an invalid kernel address for the output buffer:

Not surprisingly, this invalid address causes AfdConnectApcKernelRoutine to crash while trying to write an NTSTATUS code (STATUS_INVALID_ADDRESS_COMPONENT) to the provided address:

The hard work is all done up to this point although we don’t entirely control the DWORD that will be written to the output buffer address as the address will a NTSTATUS code (in our case, 0xC0000207). This bug then, is not quite a “write what, where” but all is not lost as we can still write wherever we want to in kernel space. Furthermore, by writing the 0xC0000207 value in a misaligned way, we will be able to call our shellcode in user space at 0x000207XX:

We decided to use a token-stealing shellcode in order to escalate to SYSTEM privileges on our vulnerable machine. To view the full code, check out our MS11-080 Privilege Escalation Exploit that works on 32-bit Win XPSP3 and Win 2K3SP2 Standard/Enterprise.

]]>https://www.offensive-security.com/vulndev/ms11-080-voyage-into-ring-zero/feed/0Advanced Windows Exploitation Updatedhttps://www.offensive-security.com/vulndev/advanced-windows-exploitation-updated/
https://www.offensive-security.com/vulndev/advanced-windows-exploitation-updated/#commentsWed, 12 Oct 2011 19:38:24 +0000http://www.offensive-security.com/?p=4426Our Advanced Windows Exploitation (AWE) live course in Columbia, Maryland is fast approaching with a start-date of October 24. Not only is the first time we have offered this training outside of BlackHat, it is also the first time we are able to offer a full 5 days of training and a limited number of seats are still available for this intense course.]]>Our Advanced Windows Exploitation (AWE) live course in Columbia, Maryland is fast approaching with a start-date of October 24. Not only is the first time we have offered this training outside of BlackHat, it is also the first time we are able to offer a full 5 days of training and a limited number of seats are still available for this intense course.

Along with the new site and extra day of training, we have also updated one of the modules with a very interesting vulnerability discovered by Chris Rohlf and Yan Ivnitskiy of Matasano Security in June 2011. We decided that this particular vulnerability would make an intriguing case study so we developed the integer overflow vulnerability into a working Mozilla Firefox exploit, controlling an invalid Javascript Array object index value being used to access element properties.

The reduceRight method executes a user defined callback function once for each element present in the array. As you can make the array point out of bounds, the attacker can pass a fake sprayed object address to the callback function. At this point code execution can be gained in different ways triggering a method of the fake object.
Code execution on Windows 7 obviously requires some fun playing with pointers and memory to bypass DEP and ASLR protections, both of which this exploit manages to do.

This proves to be our most exciting AWE class so far. If you would like to learn how to take your exploitation skills to the next level, sign-up now while there’s still time and available seats.