Wednesday, September 10, 2014

Killing the Rootkit

By Shane Macaulay


Cross-platform, cross-architecture DKOM detection

To know if your system is compromised, you need to find everything that could run or otherwise change state on your system and verify its integrity (that is, check that the state is what you expect it to be).

“Finding everything” is a bold statement, particularly in the realm of computer security, rootkits, and advanced threats. Is it possible to find everything? Sadly, the short answer is no, it’s not. Strangely, the long answer is yes, it is.

By defining the execution environment at any point in time, predominantly through the use of hardware-based hypervisor or virtualization facilities, you can verify the integrity of that specific environment using cryptographically secure hashing.

Despite the relative ease of hash integrity checks, applying them to memory presents a number of significant challenges; the most difficult being identifying all of the processes that may execute on a system. System process control registers describe the virtual-to-physical memory layout. Only after all processes are found can integrity verification of code, data, and static/structural analysis be conducted.

These articles present recent work on understanding and detecting DKOM classes of rootkits:
http://jessekornblum.com/presentations/dodcc11-2.pdf
http://bsodtutorials.blogspot.ca/2014/01/rootkits-direct-kernel-object.html

“DKOM is one of the methods commonly used and implemented by Rootkits, in order to remain undetected, since this the main purpose of a rootkit.” – Harry Miller

Detecting DKOM-based processes has largely been conducted at the logical layer (see the seven different techniques https://code.google.com/p/volatility/wiki/CommandReference#psxview). This is prone to failure and iterative evasion since most process detection techniques are based on recognizing OS artifacts.


Finding Processes by Page Table Detection

When an OS starts up a process, it establishes the ability for virtual memory to be used (to enable memory protection), by creating a page table. The page table is itself a single page of physical memory (0x1000 bytes). It is usually allocated by way of a cache-optimized mechanism, which makes locating it somewhat complicated. Fortunately, we can identify a page table by understanding several established (hardware) requirements for its construction.

Even if an attacker significantly modifies and attempts to hide from standard logical object scanning, there is no way to evade page-table detection without significantly patching the OS fault handler. A major benefit to a DKOM rootkit is that it avoids code patches, that level of modification is easily detected by integrity checks and is counter to the goal of DKOM. DKOM is a codeless rootkit technique, it runs code without patching the OS to hide itself, it only patches data pointers.

IOActive released several versions of this process detection technique. We also built it into our memory integrity checking tools, BlockWatch™ and The Memory Cruncher™.


Process-based Page Table Detection

Any given page of memory could be a page table. Typically a page table is organized as a series of page table entries (PTEs). These entries are usually traversed by selecting some bits from a virtual address and converting them into a series of table lookups.

The magic of this technique comes from the propensity of all OS (at least Windows, Linux, and BSD) to organize their page tables into virtual memory. That way they can use virtual addresses to edit PTEs instead of physical memory addresses.



By making all of the offsets the same with the entry at that offset pointing back to the page table base value (CR3), the page table can essentially be accessed through this special virtual address. Refer to the Linux article for an exhaustive explanation of why this is useful. 


Physical Memory Page 

If we consider any given page of random physical memory, we can detect the following offsets as a valid PTE. Windows has proven to consume, for every process, entry 0, entry 0x1ED (self map), and a couple of additional kernel regions (consistent across all Win64 versions).



PTE Format

typedef struct _HARDWARE_PTE {
    ULONGLONG Valid : 1; Indicates hardware or software handling (Mode 1 and 2)
    ULONGLONG Write : 1; 
    ULONGLONG Owner : 1;
    ULONGLONG WriteThrough : 1;
    ULONGLONG CacheDisable : 1;
    ULONGLONG Accessed : 1;
    ULONGLONG Dirty : 1;
    ULONGLONG LargePage : 1; Mode 2 
    ULONGLONG Global : 1;
    ULONGLONG CopyOnWrite : 1;
    ULONGLONG Prototype : 1; Mode 2
    ULONGLONG reserved0 : 1;
    ULONGLONG PageFrameNumber : 36; PFN, always incrementing (Mode 1 and 2)
    ULONGLONG reserved1 : 4;
    ULONGLONG SoftwareWsIndex : 11; Mode 2 
    ULONGLONG NoExecute : 1;
} HARDWARE_PTE, *PHARDWARE_PTE;

By checking the physical memory offsets we expect, extracting a candidate entry, we can determine if the physical page is a valid page table (see MProcDetect.cs for implementation). There are a number of properties we understand about physical memory: the address of page frame number (PFN) will always increase from earlier pages and will not be larger than the current linear position + memory gap ranges.  


What About Shadow Walker Tricks?

Shadow walker abuses the nature of the TLB of a running system. Execution may occur at a different address than when reading. If you look/scan/check memory, the address will be cloaked onto what you expect when reading, while execution will actually occur somewhere different.

This is one reason why we analyze memory extracted from a hypervisor “guest” OS snapshot. Analyzing memory from behind a hypervisor establishes a “semantic gap” that ensures our static memory analysis includes all possible memory pages, unaffected by split I/D TLB games.


What About Hardware Rootkits?

Using a hypervisor makes verifying device memory easy. Verification at the host or physical layer is extremely complicated. Different hardware vendors have vastly different ways to extract and interact with firmware, UEFI may be verifiable with Copernicus2 or other tools.

In order for a hypervisor to be effected by a hardware rootkit, the hypervisor has to have been “escaped”, which is currently a rare and valuable exploit. It is probably not worth risking such a valuable exploit for a hardware rootkit that can be mitigated by the network. Extracting physical system memory in a consistent way (immune to attack and evasion) has historically been very hard.
If you are concerned about hardware rootkits, there are some extreme techniques that may help.


IOActive has Everything

Now that we have established a method for finding everything, the next task is relatively simple. Do some checking to ensure that what we found is what we expected.
Using cryptographically secure hash checks in a whitelist fashion is a straight-forward and hard-to-attack technique for integrity verification.
IOActive’s current solution, BlockWatch™, does just that. It manages memory extraction and hash checking that testifies to what we have found.


Weird Rootkits

I classify “weird rootkits” as anything from a RoP-based rootkit to some form of script injection or anything else where the attacker can coerce an application to behave in an unexpected (and rootkit-like) way.  

Detecting a RoP is actually quite easy (stack checking a memory snapshot). I covered some of this in a CanSecWest presentation I gave earlier this year. Each return address on a stack must be preceded by a call instruction. You can then validate that the opcode exists and the return address is not spurious (as is the case for a RoP attack). RoP stacks are also exceedingly large and are atypical of normal threads.

What about other attacks, rootkits implemented in server scripts and anything else? If we have found the address spaces for all of the processes and are able to validate the integrity of all of the kernel code, then any scripts or weird rootkits will be observable through normal profiling and logging interfaces.


Summary

By leveraging the unique ability of a hypervisor to expose the physical memory of a system in a way that is consistent (not modified by an attacker), we can use a high-assurance process detection technique combined with integrity checking to detect any rootkit.


Additional References

Tuesday, August 19, 2014

Silly Bugs That Can Compromise Your Social Media Life

By Ariel Sanchez

A few months ago while I was playing with my smartphone, I decided to intercept traffic to see what it was sending. The first thing that caught my attention was the iOS Instagram app. For some reason, the app sent a request using a Facebook access token through an HTTP plain-text communication.

Thursday, August 14, 2014

Remote survey paper (car hacking)

Good Afternoon Interwebs, 
Chris Valasek here. You may remember me from such nature films as “Earwigs: Eww”
Charlie and I are finally getting around to publicly releasing our remote survey paper. I thought this went without saying but, to reiterate, we did NOT physically look at the cars that we discussed. The survey was designed as a high level overview of the information that we acquired from the mechanic’s sites for each manufacturer. The ‘Hackability’ is based upon our previous experience with automobiles, attack surface, and network structure. 
Enjoy! 


  • cv & cm 

Tuesday, August 5, 2014

Upcoming Blackhat & DEF CON talk: A Survey of Remote Automotive Attack Surfaces

Hi Internet,

Chris Valasek here; you may remember me from such movies as ‘They Came to Burgle Carnegie Hall’. In case you haven’t heard, Dr. Charlie Miller and I will be giving a presentation at Black Hat and DEF CON titled ‘A Survey of Remote Automotive Attack Surfaces’. You may have seen some press coverage on Wired, CNN, and Dark Reading several days ago. I really think they all did a fantastic job covering what we’ll be talking about.

We are going to look at a bunch of cars’ network topology, cyber physical features, and remote attack surfaces. We are also going to show a video of our automotive intrusion prevention/detection system.

While I’m sure many of you want find out which car we think is most hackable (and you will), we don’t want that to be the focus of our research. The biggest problem we faced while researching the Toyota Prius and Ford Escape was the small sample set. We were able to dive deeply into two vehicles, but the biggest downfall was only learning about two specific vehicles.

Our research and presentation focus on understanding the technology and implementations, at a high level, for several major automotive manufacturers. We feel that by examining how different manufacturers design their automotive networks, we’ll be able to make more general comments about vehicle security, instead of only referencing the two aforementioned automobiles.

I hope to see everyone in Vegas and would love it if you show up for our talk. It’s at 11:45 AM in Lagoon K on Wednesday August 6.

-- CV

P.S. Come to the talk for some semi-related, never-before-seen hacks.

Thursday, July 31, 2014

Hacking Washington DC traffic control systems

By Cesar Cerrudo @cesarcer

This is a short blog post, because I’ve talked about this topic in the past. I want to let people know that I have the honor of presenting at DEF CON on Friday, August 8, 2014, at 1:00 PM. My presentation is entitled “Hacking US (and UK, Australia, France, Etc.) Traffic Control Systems. I hope to see you all there. I'm sure you will like the presentation.

I am frustrated with Sensys Networks (vulnerable devices vendor) lack of cooperation, but I realize that I should be thankful. This has prompted me to further my research and try different things, like performing passive onsite tests on real deployments in cities like Seattle, New York, and Washington DC. I’m not so sure these cities are equally as thankful, since they have to deal with thousands of installed vulnerable devices, which are currently being used for critical traffic control.

The latest Sensys Networks numbers indicate that approximately 200,000 sensor devices are deployed worldwide. See http://www.trafficsystemsinc.com/newsletter/spring2014.html. Based on a unit cost of approximately $500, approximately $100,000,000 of vulnerable equipment is buried in roads around the world that anyone can hack. I’m also concerned about how much it will cost tax payers to fix and replace the equipment.

One way I confirmed that Sensys Networks devices were vulnerable was by traveling to Washington DC to observe a large deployment that I got to know, as this video shows: 



When I exited the train station, the fun began, as you can see in this video. (Thanks to Ian Amit for the pictures and videos.)



Disclaimer: no hacking was performed. I just looked at wireless data with a wireless sniffer and an access point displaying it graphically using Sensys Networks software along with sniffer software; no data was modified and no protections were bypassed. I just confirmed that communications were not encrypted and that sensors and repeaters could be completely controlled with no authentication necessary.

Maybe the devices are intentionally vulnerable so that the Secret Service can play with them when Cadillac One is around. :)

As you can see, Washington DC and many cities around the world will remain vulnerable until Sensys Networks takes action. In the meantime, I really hope no one does hack these devices causing traffic problems and accidents.

I would recommend a close monitoring of these systems, watch for any malfunction, and always have secondary controls in place. These types of devices should be security audited before being used to avoid this kind of problems and to increase their security. Vendors should also be required, in some way, to properly document and publish the security controls, functionality, and so on, of their products in order to quickly determine if they are good and secure.

See you at DEFCON!


By the way, I will also be at IOAsis (http://ioasislasvegas.eventbrite.com/?aff=PRIOASIS), so come through for a discussion and demo.


Wednesday, July 30, 2014

DC22 Talk: Killing the Rootkit

By Shane Macaulay

I'll  be at DefCon22 a to present information about a high assurance tool/technique that helps to detect hidden processes (hidden by a DKOM type rootkit).  It works very well with little bit testing required (not very "abortable" http://takahiroharuyama.github.io/blog/2014/04/21/memory-forensics-still-aborted/). The process  also works recursively (detect host and guest processes inside a host memory dump).


Plus, I will also be at our IOAsis (http://ioasislasvegas.eventbrite.com/?aff=PRIOASIS) , so come through for a discussion and a demo.

Monday, June 16, 2014

Video: Building Custom Android Malware for Penetration Testing

By Robert Erbes  @rr_dot 

In this presentation, I provide a brief overview of the Android environment and a somewhat philosophical discussion of malware. I also take look at possible Android attacks in order to help you test your organization's defenses against the increasingly common Bring Your Own Device scenario.