This is the fourth in a series of posts about internally developed computer security training classes that have been taught at MITRE (Technical Training) and have been publicly released.
In this post, the editor continues an interview with Xeno Kovah. We pick up the thread on his two-day training class, Rootkits: What they are and how to find them, previously released to the Open Training community.
Editor: What training topics come under the hood of Rootkits?
Xeno Kovah: This class ties together all the previous classes we discussed and adds new topic-specific material. So, deriving material from the Intro x86 class, we cover how attackers can change the assembly language at the start or end of functions in order to gain control of the code execution and monitor or filter actions on the system. This is called "inline hooking." Then, deriving material from The Life of Binaries, we describe an alternative scenario, where the attacker changes the Import or Export Address Table data so that some of the code calls the attacker instead of calling the intended functions. This is called "IAT/EAT hooking." Finally, deriving material from Intermediate x86, we talk about how attackers can manipulate data structures, such as the IDT, GDT, or page tables, in order to gain leverage for hooking and hiding. Once we cover those topics, we get into some specifics on how rootkits can operate on a system, but more importantly, we talk about key tools that can allow defenders to detect rootkits.
As with the other classes I have put together, you can scroll to the bottom of the http://OpenSecurityTraining.info/Rootkits.html training page, and click on the p (pi) symbol to see a work-in-progress map of the granular details of what is covered in the class.
[Ed.]: Why do you think it's important that people know how rootkits operate?
[XK]: For this particular class, the first reason I wanted people to know the information is so they could help develop Checkmate, the project I was working on ;). The second reason was so that users of the final system would then understand, for instance, what it meant when Checkmate said that there was an SSDT hook present.
In general, though, I think rootkits are pretty fascinating and that should be reason enough for any cyber defender to learn about them. Prior to state-sponsored attacks, like Stuxnet, proof-of-concept rootkit attacks were in many ways the apex of malware—exhibiting the most sophistication and depth of knowledge about the systems they were targeting. The proof-of-concept techniques developed by Invisible Things Lab continuously pushed the boundaries of how deep into a system an attacker could embed. In some ways, these proof-of-concept rootkits were the perfect epitome of the inherent asymmetry in attacks vs. defense in computer security. An attacker gets to focus on knowing more about a system than the defender in a very narrow area. That knowledge then allows attackers to subvert detection mechanisms. This is directly related to the topic of exploits, where an attacker, knowing code logic better than a developer or system deployer, leads to subversion of access control.
[Ed.]: What kind of cyber defender type jobs can make use of this knowledge?
[XK]: I don't know if "deep system security research" is an actual designation, but it seems to me like an apt term to describe it. There's plenty of research on how to design better detectors for deep system subversion, and how to make system properties trustworthy, and so on. But knowledge of how stealth malware, like rootkits, subverts detectors can lead to better systems that are also more robust against such attacks.
As mentioned in the Intermediate x86 post, knowledge of that material plus knowledge of this material makes for a specialty malware analyst, one who can understand what's going on with kernel-based malware. This particular kind of specialty is a niche (kernel-based malware) within a niche (malware) within a niche (security).
As I noted previously, NSA has a Center for Academic Excellence in Cyber Operations. Check out the specific type of knowledge that the NSA wants, and you'll discover that it includes Operating Systems Theory and Vulnerabilities (calling rootkits out specifically), both of which are both covered in this class.
[Ed.]: I bet your work at MITRE on Checkmate made solid use of this material, right?
[XK]: Yes. The current public paper on Checkmate primarily covers the trustworthiness component, but there's also a memory integrity verification (MIV) component, since you can't trust 3rd party software if the OS is compromised. Checkmate needs to check key kernel code and data structures in order to make sure that they have not been tampered with. So, the knowledge conveyed in this class about data structures that are manipulated by malware relates directly to the things we set out to verify with Checkmate.
[Ed.]: We've been following your series of classes, but have not focused on how they all relate or fit into a larger program of training. Could you elaborate?
[XK]: Yes. Viewing the course maps at the bottom of the class training page will more clearly show the relationship between this class and the other classes. But as was already mentioned, this is the class that my other 3 classes were meant to lead up to. This class is the capstone for my initial class development efforts. It fits well into both the "malware analysis" and "deep system security & trusted computing" knowledge trees.
[Ed.]: If rootkits is the capstone, do you have any future classes planned?
[XK]: Right now I'm mostly focused on improving my existing four classes. The rootkit class focused on malware that runs on 32-bit Windows XP. In the updated class, the material will talk about the techniques used on 32- and 64-bit Windows 7. Thanks to improvements in Windows security, it is more difficult to get malicious code into the kernel and to manipulate anything attackers might want to manipulate once they're in. This has meant attackers focus on fewer techniques, but techniques that are less easily countered by Microsoft (although Windows 8 secure boot is one of the upcoming countermeasures).
I'm hoping I'll be able to integrate some interactive game-like experiences into the classes either with randomized faux-malware or with randomized installation of malware into a VM. But for this class, it's not yet clear where the gaming element would come into play.
[Ed.]: Thanks, Xeno. Your classes have laid a foundation for understanding more about host-based security. I'm sure we'll check in with you again on your future developments. Next up, we'll discuss vulnerability assessment.
