Read an Excerpt
Managed Code Rootkits
Hooking into Runtime Environments
By Erez Metula
Syngress
Copyright © 2011 Elsevier, Inc.
All right reserved.
ISBN: 978-1-59749-575-2
Chapter One
Introduction
INFORMATION IN THIS CHAPTER
• The Problem of Rootkits and Other Types of Malware
• Why Do You Need This Book?
• Terminology Used in This Book
• Technology Background: An Overview
We live in a world in which we can't trust our computers. For example, how can we know for sure that our hardware manufacturer did not hide malicious code in the system's microchip? Or that our freshly installed operating system does not contain backdoors created by a rogue developer from the OS development team?
The fact is that we cannot be sure our computers are free of such harmful software. And unfortunately, our need to use a computer overcomes our lack of trust in this regard.
Malware is a piece of software designed to perform malicious activities on a victim's machine without his consent. Malware is a general term used to describe "evil" software, such as viruses, Trojan horses, backdoors, rootkits, worms—essentially any kind of code designed to cause harm or spy on a victim's activities. Once the malware is installed, the attacker's intent is to stay unnoticed as long as possible while main- taining control of the system. Although early malware writers practiced their craft primarily for the intellectual challenge involved in developing such software and to watch how the malware affected the target machine, today's malware writers do it for profit. A well-established economy has evolved surrounding malware, from zero-day exploits to full-blown malware applications capable of producing very sophisticated and surreptitious attacks on the fly, more or less unbeknownst to their victims.
The "bad guys" use such malware as a tool to spy on their victims, control their machines, steal sensitive information, deny them access to their machines (as in a denial-of-service or DoS attack), force the machines to become "zombies," or even act as a bridge to internal networks. It all depends on what the attacker instructed the malware to do. Each type of malware has its own characteristics—for instance, viruses infect other executables, Trojan horses are concealed as innocent-looking files, and worms infect remote machines and spread via the network. But rootkits are a bit special and deserve a closer look.
Originally, rootkits were designed to allow attackers to replace important parts of the UNIX operating system so that they could gain administrative "root" access to the machine, but they have evolved tremendously since then. Today there are rootkits for many "layers" of the computation model, such as rootkits for the kernel, hardware, hypervisor, and so on.
This book covers managed code rootkits (MCRs), a new type of rootkit targeted at managed code environments in which special types of rootkits can operate. In this chapter, we'll discuss malware in general, and then take an introductory look at MCRs, including what they are and what attackers can do with them.
THE PROBLEM OF ROOTKITS AND OTHER TYPES OF MALWARE
Business organizations, private investigators, journalists, armies, countries—all of these legitimate entities would be happy to have an edge over their opponents, or at least to know what they're doing. One way to gain that edge and that knowledge is to control the opponent's machines, applications, and data. And rootkits are a very efficient tool for doing that.
In fact, the use of rootkits by legitimate entities has become so popular in the past decade that even Sony deployed rootkit technology as a copy protection mechanism, called Extended Copy Protection (XCP), on its music CDs in 2005. The rootkit was designed to check that the CDs were genuine and hadn't been illegally copied, but it interfered with proper playback. What's more, when a user attempted to play a CD, the rootkit embedded in the CD installed itself on the user's machine, without the user's approval, and it had its own set of security vulnerabilities that exposed the user to malware.
Rootkits deserve a special place in the malware space. Although most other types of malicious code are designed to allow attackers to gain access to a machine, a rootkit helps an attacker control the machine once he has gained that access—for example, by hiding his presence on the system, extracting sensitive data handled by the machine, deploying hard-to-detect backdoors; basically anything the attacker wants to do.
Sometimes an attacker will mix a rootkit with other types of malware, such as a worm, to hide its presence on a machine; this is known as multistage malware. It is even possible to mix different levels of rootkits—for instance, mixing a kernel-level rootkit with an MCR to create a second-order hybrid rootkit attack.
It is crucial to understand multistage malware and multilevel rootkits to employ better countermeasures and properly investigate malware attacks. Only when you fully understand the ins and outs of rootkits can you truly assess the potential damage a rootkit can cause. Toward that end, throughout this book we will discuss the different techniques and attack vectors an attacker can use when utilizing managed code malware. We're focusing on managed code environments, where code is executed under management of an application VM runtime (environments such as Java, .NET, and Flash), because managed code environments are the future. We will discuss this in more detail in the remainder of Part I of this book.
WHY DO YOU NEED THIS BOOK?
This book covers application-level rootkits and other types of malware, hidden inside the application VM runtime. It is the first book on this subject, covering a concept rather than vulnerability—a problem that won't go away by simply installing a missing patch.
Most of this book was written from the attacker's point of view, to teach you (one of the "good guys") what the bad guys probably already know. Part II of the book covers techniques for developing and deploying MCRs. We'll cover the basics of managed code environments, and move on to malware deployed as managed code inside the VM. We'll also talk about practical problems the attacker needs to resolve when deploying malware on your system.
Attackers aren't the only ones who can employ MCR techniques for tasks such as manipulating the runtime, as we'll be covering in Part II. You can use these techniques to create your own version of a VM—for example, to create a subclass of a VM that is dedicated to solving issues with security and performance, fixing bugs, and basically doing anything you want your VM to do. The same techniques used to deploy a backdoor, for example, can be used to deploy security mechanisms for creating a "hardened" VM. It all depends on the user and his intentions.
How This Book Is Organized
Before digging into the details of MCRs, let's review the book's structure. The book is divided into four main parts, titled "Overview," "Malware Development," "Countermeasures," and "Where Do We Go from Here?"
Part I: Overview
In Part I of the book, which comprises this chapter and Chapter 2, you'll receive an overview of MCRs. In this chapter, we'll explore managed code environment models and how they use application VMs so that we can understand how managed code can be related to rootkits. In Chapter 2, we'll discuss attack scenarios and discover why MCRs are attractive to attackers.
Part II: Malware Development
In Part II, which comprises Chapters 3 through 8, you'll learn all about MCR development, from analysis to successful deployment. You'll do that while focus- ing on interesting MCR attack vector scenarios—from backdooring authentication forms, to deploying secret reverse shells inside the VM, performing DoS attacks, and stealing encryption keys, among other scenarios.
We'll start in Chapter 3, where we'll look at what tools are used to produce and deploy MCRs. Then we'll move on to Chapter 4, where we'll demonstrate how you can change the meaning of a programming language, thereby forcing the language grammar to change and creating different meanings for keywords.
Next, in Chapter 5, we'll discuss how to manipulate the runtime, before moving on to Chapter 6, where we'll go over the steps required to strategically develop an MCR, along with the ability to extend the language grammar by adding a new malware API to the language via function injection.
Next, we'll take a look in Chapter 7 at ReFrameworker, a language modification tool that helps tremendously with the intense process of deploying an MCR.
We'll round out Part II with Chapter 8 and a discussion of advanced topics related to MCR deployment and language manipulation.
Part III: Countermeasures
Part III, which consists of Chapter 9, deals with the possible countermeasures you can deploy to protect yourself from an MCR.
We'll start with a discussion of how MCRs are everybody's problem, from developers to system administrators to end users, and what we can do to minimize the risks associated with MCRs.
We'll also talk about technical solutions, focusing on prevention, detection, and response tactics.
Part IV: Where Do We Go from Here?
Part IV of the book, which consists of Chapter 10, provides a gateway for further research. Specifically, we look at how MCR-like techniques can be applied as an alternative problem-solving approach to creating more secure runtimes, performing runtime optimizations, and so on. We'll also see how to use ReFrameworker to help us in these tasks.
How This Book Is Different from Other Books on Rootkits
Most malware books are related to unmanaged (native) code, such as assembly, C, or C++, and cover malware topics from an OS point of view.
In this book, we talk about high-level attacks developed in intermediate languages (i.e., languages that are executed by an application VM). This book covers those attacks from an application-level point of view. Specifically, in Part II, we talk about attacking mechanisms inside the applications rather than looking at the system as a whole.
Also, we focus on three popular runtimes based on an application VM—the .NET CLR, the Java JVM, and Android Dalvik, which we'll use in case studies to demon- strate the concepts and ideas expressed in this book. Since the concept we cover is not tied to a specific OS or VM, it is intended to serve as a stepping-stone for research of other platforms as well.
Application VMs and managed code environments are becoming increasingly important and are often seen today as a better option for new software projects, whether in .NET, Java, or some other platform based on managed code concepts in which use of a VM software layer provides many functionalities, such as exception management, memory management, and garbage collection that takes care of runtime exceptions, memory allocation, cleanup, disposal, and addressing. With application VMs and managed code environments, the significance of critical security problems such as buffer overflows, heap overflows, array indexing, and so on, which have been major vulnerabilities in unmanaged code such as C/C++, is minimized. A buffer overflow or array indexing problem that could overwrite the return address on the stack, for instance, is now caught by the runtime, which throws an exception. Although it is still possible to create a DoS attack since the application can crash due to uncaught exceptions, the attack surface has been reduced drastically.
Application VMs are even integrated deep into the OS. Take the Microsoft Windows family, for example, in which the .NET Framework and its associated CLR are performing more OS functions than ever before. As Table 1.1 shows, the .NET Framework has been preinstalled in the Windows family of operating systems since Windows Server 2003.
Similarly, the Java JVM is preinstalled in many OSes, such as Mac OS X, various Linux OS distributions, and the Solaris OS, among others.
In the future, Microsoft plans to release an entire OS developed in managed code. In this experimental OS codenamed Singularity, which has been in development since 2003, the kernel, device drivers, and applications are all written in managed code. Although the lowest-level interrupt code is written in assembly language and C, most of the OS core, including the kernel, is using a runtime written in the Sing# language (an extension of C#). For more information, please refer to the Microsoft Research homepage on the Singularity OS: http://research.microsoft.com/en-us/ projects/singularity/.
Other interesting managed code OSes include the following:
• Midori Microsoft's future OS based on the Singularity research project
• SharpOS An open source General Public License (GPL) OS in C#
• Cosmos An open source Berkeley Software Distribution (BSD) OS in C#
In other words, rootkits considered user-mode rootkits today are the kernel or Ring 0 rootkits of the future.
TERMINOLOGY USED IN THIS BOOK
This section defines some of the terms used in this book. Although most of these terms will be described in depth throughout the book, they are introduced here to give you a solid base from which to proceed.
• Virtual machine An application VM providing a platform-independent programming runtime that allows applications to execute in the same manner on different platforms. The virtual machine acts as a "bridge" to the real environment, hiding the details of the operating system and hardware. Do not confuse this term with system virtual machines, such as VMware, Virtual Server, and Xen, which enable you to run multiple OSes on a single piece of hardware. In this book, our focus is on application virtual machines.
• Runtime The environment upon which the VM execution model is based. Do not confuse the word runtime with the word run-time, which in this book refers to the execution time of a program.
• Framework The term "framework" is often used in the context of managed code environments as a synonym for the term "runtime" (as described above). Examples for that are the .NET Framework and the Dalvik Framework.
• Managed code Code that executes under the management of a virtual machine and that requires the VM for its execution. While the term was originally coined by Microsoft to refer to .NET VM runtime-based code, this definition fits other runtimes as well. See the Note sidebar at the end of this list.
• Unmanaged code (or native code) Code that executes directly on the CPU, without the use of an intermediate machine. In languages such as C, C++, and COBOL, the source code is compiled to the machine code assembly that is specific to the machine's CPU.
• Intermediate language (IL) bytecode Instruction sets that are designed for efficient execution by a software interpreter (such as a VM), which can then compile them into machine assembly code.
• Runtime binaries The binary files containing the runtime's IL bytecode composing its classes.
• Object A fundamental data type in object-oriented programming. Objects are seen as abstract data structures, or data components, with the procedures that manipulate them.
• Class A template for creating objects, or a description of the state and behavior that the objects of the class share. An object of a class is called an instance of that class.
• Inheritance (or subclassing) A mechanism for creating new classes by deriving from existing, defined classes. Inheritance reuses existing code by extending its attributes and behavior to form a new class.
• Method (or function) The behavior of a class; a subroutine that is associated with an object or a class that implements a specific behavior.
• MCR An acronym for managed code rootkit; malicious code planted in the VM internals that can influence all applications that depend on that VM.
Before moving on, let's have a brief overview of managed code runtimes.
(Continues...)
Excerpted from Managed Code Rootkits by Erez Metula Copyright © 2011 by Elsevier, Inc.. Excerpted by permission of Syngress. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
