eEye Digital Security
Vice Newsletter - July 27, 2005
Again, welcome on behalf of the eEye Research team to another issue of VICE, a free technical newsletter featuring content from the team representing the foundation of eEye as a company and culture.
It is that time of the year when security experts from around the world gather in Las Vegas to share information and techniques at the Black Hat Briefings held at Caesar's Palace. This year eEye Digital Security and the Research Team will make an encore visit and will present two topics which promise to offer unique and insightful techniques which affect the Windows Kernel. Be sure to check out our presentations as we will have lots of the infamous eEye t-shirts to give away. The details of the briefings are presented below in the Etcetera section. Look for the eEye logo in Vegas, and don't hesitate to talk with us over a mandatory drink. Of course, please continue to send your written questions, comments and criticisms to vice@eeye.com.
The Vulnerability Exposed! featured article this month is an expert review from regular contributor Drew Copley discussing "Sleeper Agents". He presents an overview, the attack methods, and concludes with steps to protect your network through review of several case studies.
Enjoy!
Christopher Imes, Editor
In This Issue
| 1. | ||
| • | Sleeper Agents: Stealthy Attack and Defense Technology | |
| 2. | ||
| • | Remote Windows Kernel Exploitation - Step In To the Ring 0 | |
| • | eEye BootRoot | |
Vulnerability Exposed!
Sleeper Agents: Stealthy Attack and Defense Technology
The "Sleeper Agent" model of attack technology revolves around the core ingredient of any infiltration model from the assassin to the intelligence agent: disguise of both physical appearance and behavior. In this paper I will go over a wide variety of "sleeper agent" type attacks -- as they have happened already and as they are bound to eventually happen -- as well as some methods of protection against these attacks.
Typical Methods of Stealth Attack Technology
In computer security we have not yet seen many sleeper agent type models of attack. In system infiltration we can conceive of two primary means of detection evasion: subverting control of detection either directly or indirectly. In the first case, where detection control is subverted directly, I am talking about the following kinds of scenarios:
- The malware directly attacks the detection agent.
- The malware looks for detection agents and subverts their detection capabilities.
- The malware directly subverts the Operating System itself.
- The malware hooks into or rewrites part of the underlying Operating System so as to evade either programmatic detection or manual detection.
- The binary is obscured through encryption.
- The behavioral capacities of the binary are obscured.
- The malware is obscured through dynamic change, such as poly or metamorphic capabilities.
"Sleeper Agent" Attack Stealth Technology Overview
In the sleeper agent model of offensive stealth technology there are two core ingredients. The attack agent may disguise itself innocuously, and the attack portions of the code are run infrequently.
The innocuous "disguise" of the attack agent may include:
- Innocuous appearances by literally "sleeping" or doing nothing, such as in timer or calendar based attacks.
- Innocuous appearances by performing some legitimate function or appearing to perform some innocuous function.
- Innocuous appearances by actually being embedded within legitimate code.
In the last scenario, we actually see an increase of much of this kind of behavior from spyware. There is a growing monetary angle to this method of attack. New malware is created daily, and the ease of making money from this kind of attack has created a powerful demand. And, where there is demand, there will be supply.
Ultimately, however, the move towards "sleeper" type of stealth has been sloppy and poorly thought out. Instead of being a carefully planned attack, it has come about as a type of attack which has coalesced through sheer effort and numbers in true capitalistic fashion.
This said, the reasons behind such an attack increasing in both complexity and frequency are many. This is a case where the computer security world has not listened to the physical security world. Instead, computer security attack programmers have been operating as if they were trying to reinvent the wheel, or in this case, the model of the infiltrator, the spy, and the assassin.
Instead of discussing the various reasons for why this technology is inevitable, I will go immediately into technical applications of this style of stealth attacks under the assumption that the value of these attacks will be made readily apparent.
I will discuss the specifications of two hypothetical sleeper agents.
Sleeper Agent Specifications: "Paranoia"
"Paranoia" is a sleeper agent ActiveX. A few key specifications of "Paranoia":
- Paranoia is scriptable from a webpage.
- Paranoia's communication model is all clients based, therefore it can traverse all firewalls.
- Paranoia's commands can be passed to it through ordinary channels: email, newsgroups, and webpages.
- Paranoia's communication is steganographically occluded, either in ordinary HTML, in whitespace, or in ordinary seeming but specific sequences of words.
- Paranoia relies on the obscurity of ActiveX technology itself.
- ActiveX allows the agent to sleep, until it is required by the controller to "wake"; the OS cooperates by calling it through legitimate channels.
ActiveX is already taken advantage of by many spyware agents; however rarely has it been used in an attack scenario of much magnitude. In "Paranoia's" case example, you see that the covert channel and control is the key ingredient here.
Any sleeper agent has a problem with "when to wake up". Usually, such agents will have to rely on some kind of timer. This means it has to actually run on a frequent basis so as to check the time. The less frequently it checks the time, the stealthier it is, but the less accurate it is. And, having to "wake up" on any kind of frequency at all introduces potential detection avenues.
"Paranoia" also offers the advantage of hiding communication channels in client side traffic. In "the old days" trojans would always listen on a port. Today, most malware continues to listen on a port. Obscuring such open ports are generally done through direct subversion of the Operating System, whether it is through subverting a carrier application listening on a port, or by subverting the ability of the OS of reporting open ports or promiscuous adapters. These subversion methods are "always on", however, and so limited in stealth.
(It almost goes without saying, but the subversion of the OS need not be "always on". Do not think that I am intending to say that other methods are useless. Quite the contrary, in such work one must be as objective as possible -- whatever works is what matters.)
In the instance of "Paranoia" some subversion of the email client on the system is likely, and even permanent subversion may be required. However, such clients are often subverted without the notice of file protection software, though available apis or outside rule settings, or by the mere fact that they tend not to be considered "system" critical.
Sleeper Agent Specifications: "P-2"
P-2 is a sleeper agent that runs on a manmade timer. In this case, P-2 is related to Paranoid in the fact that it relies on Windows underlying ActiveX system to restart. P-2 likely would best be run whenever someone views a webpage with a popular ActiveX in it.
The advantages of piggy backing the ActiveX or COM subsystem are many. The subsystem is obscure, so it is more difficult to trace. The subsystem also has multiple channels for running, including INI files, methods, and such, so there is a wide possibility that the actual ActiveX binaries themselves may not have to be altered. For instance, the file could be called by the registry. In addition, there are many popular ActiveX which can be dependably and frequently run on a system. Finally, the ActiveX subsystem contains a lot of executables which are less likely to be guarded by the Windows File Protection System.
The main point of "P-2" is not how it restarts, but that it does not restart on reboots using any normal means. This type of "run" method is perfect for this example, and as you will see later on, the "run" method or "reboot" method this system ultimately decides on could be anything.
But, for practical reasons, let's pretend it operates in this manner for a moment.
The objective of P-2 is to operate as an information gatherer. This itself is difficult in stealth attack technology. Keyloggers and similar programs typically require extensive hooking into the system.
There are multiple weaknesses to a keylogger type of system:
- If it is not always running, it is missing potentially crucial information.
- There are a finite number of ways to operate a keylogger, and so a finite number of channels to protect against.
- Because keyloggers demand intrinsic system cooperation, any bugs of nearly any kind could reveal this system.
There are three primary difficulties with P-2.
- How do you stealthily search the system?
- How do you stealthily store the pilfered information?
- How do you stealthily send the pilfered information on?
As far as stealthy searching goes, let's consider some points:
- You want to search extremely slowly.
- You want to operate the disk system when other software is operating the disk system, so as to hide disk system traffic.
- You want to have "user awareness". Is the user on right now? Did the user just get off the system? How long has the user been off the system? If the user just got off the system, he may be eating a sandwich. Or, maybe he is watching television right next to the system. If it is the early morning and he has been offline for several hours, it is likely he is asleep. And so on.
If the user never seems to sleep - over a sample of several days – then P-2 would have to operate while the user is online. In this case you would want to operate the searching mechanism with other disk traffic. This means you want to hook into the disk subsystem itself.
Another means of performing such an action could be, for instance, hooking into the local anti-virus on-demand scanner, or hooking into a search agent, such as the one built into Windows or another popular downloaded agent. Such tools require a lot of disk action and they already search out every file. Any good, universal system can not be dependant on only one such product. It needs to have a generic approach. This is not very difficult if you can merely identify the presence and activation of a large variety of AV on-demand scanners and system search agents.
As far as watching the user, this means the system will need to take statistics, taken from various processes which are user driven, various apis which are user driven, and you would want to deal with a wide range of different user behavior. Some systems will rarely ever have a user on it. Some systems will have users on it all day, but not at night. Some systems will have late-night users on it, but none during the day. Some systems will be used every day. Some systems will be used every other day. And so on.
With unusual start methods a system like P-2 requires careful consideration and adaptation to its own start method. Maybe this particular system just will not run frequently because the chosen run method simply is unlikely here.
In this case, we have to note that with P-2, the initial run method needs to be multiple. The initial launch needs to be aware of multiple copies of itself, and it needs to log the time and date of its run. It needs to be able to compare this time and date with the time and date of the initial infection. It needs to be able to assess the system as it is currently set up and choose from a number of different potential run or reboot choices for this system.
You may note that this system is pretty hefty. It must be modular, since it does not want to run with all of this information every time it runs. It needs hefty outside files from which it reads, and which it writes to. It will load up functionality as it is required, and some functionality it may never use. Further, this system will be potentially archiving a lot of data. How can it deal with this kind of secret storage?
Secret storage is actually the second primary key to this type of system.
So you have 1) a core analytical engine, as discussed above, and 2) a secret storage and retrieval system which can deal not only with writing out and holding key documents, but also with storing modular functionality from DLLs to key INI files.
There are many ways to keep secret storage. A good system needs to always be adaptable, as I have outlined above. My finding is that the key storage system should be within the disk itself. For systems with inadequate disk space, the files should be stored innocuously on the system as innocent sounding DLL, executable, and other binary type files. These files should not - in anyway - be marked as hidden.
You may be thinking, "There is not adequate disk space, so you are going to hide these files anyway? That does not make any sense." That would be the clever thing to think. Because what I mean by "adequate disk space" is not what is commonly meant. What I mean is there must be adequate free disk space so as to hide the files in chunks, across the free disk space.
For a complete specification, I should note that there must be several alternatives here. There should be several ways to hide the required files in plain sight, and there should be several ways to hide the files secretly. Pragmatically, we will select three file hiding methods. For the fourth solution - when there is simply no space whatsoever to safely operate - the system should fail out; it should email the anonymous collection agent, open a security hole within the system, and delete all evidence of itself.
Let's run through these four possibilities:
Case One - Adequate Free Disk Space: In this case the files to be stored would be stored in free disk space. A good way to do this is to chunk the files in a manner so that individual chunks may be lost, but if enough chunks are discovered the file can be reconstructed. (This kind of technique has been popularized in many P2P agents, satellite communications technology, and is also seen in Usenet binary downloading "PAR" files).
Case Two - Not Adequate Free Disk Space: In case two, a less then optimum case, the analytical engine gets the directory information for the Windows folder and makes a judgment: Is this a system that is relatively clean, or does it have a lot of installs? If it has a lot of installs, then hide the flat files in the System32 folder as binary files.
Case Three - Not Adequate Free Disk Space, Clean System: Hide the files as a single or several large compressed files, open up a security hole, and report back to the controller that the system is operational but under extraordinary duress.
Case Four - Failout: Failout should open a security hole in the system and wipe all presence of itself from the system. There are many reasons for this failout procedure being called. The security hole opened should be something in the client-side system, so it may continue to surmount the firewall. Likely, several security holes should be opened.
[Note: If you do not have the proper privileges to write to the raw disk, you would have to default to case two or three.]
What some people may be asking here is "how do you secretly open a security hole on a system"? This is a subject which is very rewarding to look into on its own, but here are some basic suggested guidelines:
- Open a security hole by installing a mini "P-1" or "Paranoia" ActiveX component. This evades the problem of dealing with altering potentially protected binaries.
- Find a way to open a security hole in client and server applications without altering them directly.
- Adjust files that are not likely to be protected so that they now contain a minor buffer overflow or subtle heap manipulation hole.
[Note 2: Is it possible to generically attack generic system binary protections? Yes, it is. However, this goes beyond the immediate scope of this paper.]
As far as the secret storage mechanism goes, the reason for chunking out the files across the "unused" portions of the disk offer several advantages. To start, the system allows for writing over of information; it is a redundant, distributed chunking system. This system also eludes raw disk inspection of any nearly any kind. It does not require altering of any files within the disk system. With a distributed chunking system where there is adequate disk space, you do not even need to worry about altering sections of the disk management system, though you would want to make sure you do not select a section marked as a bad cluster in the bad cluster file (I would not suggest playing with that file, as you would be altering a primary system file). Finally, writing to unused portions of the disk remains relatively easy to do, as long as you have the proper privileges; however, "easy" to do is not a primary goal in any of this, but simply a nice secondary advantage to have.
Are there other methods, potentially, for secret storage? Of course. In the raw disk system alone, there are many potential solutions. With all of the information we store on our systems today, there is almost endless opportunity.
Protection
As you can see, there are a lot of potential avenues here for some unusual and highly effective attack technology.
How can we protect against such attacks? First of all, understanding how such attacks might happen is the first step, which is why I stepped through these examples. Let's go over some basic conclusions we can make about protection strategies:
- Pure signature-based strategies are not enough; there are too many unknowns. This may have worked for the first few years of the Internet, but far more people are coming online and there are many attackers becoming more sophisticated. This said, signature technology is, and will remain, a bedrock of computer security – just as it is a bedrock of physical security.
- Generic protection has always been around. Generic protection is on every system just as surely as the OS can separate users by privilege level or as the OS protects system binary files. However, we need more generic type protection mechanisms that utilize intelligence in order to protect against emerging and inevitable threats.
- Good security designers must be experts in attack and defense. This is how excellent safes are made, this is how excellent security software is made, and this is how every manner of excellence may be found in any security arena.
- We can not afford to think in paradigms imposed by others, but we must be cognizant of the latest paradigms out there and contemplate constantly on new potential avenues of attack.
- We may consider some signature attacks; if we have seen the binary of such malware, we can make a signature for it. This signature may be for the binary itself. It may be for the behavior of the binary. Or, the signature may be for the chunking method itself, in the case of the P-2 malware's chunking "secret storage" system.
- Generic, heuristic protection would consist of locking down the behavioral possibilities for such software attacks. In simplest terms this would mean locking down ActiveX which can be "safely scriptable from a webpage", locking down alterations to current ActiveX and their flat files, locking down the IM, email, and browser clients.
- Generic, heuristic protection would also consist of locking down the file volume object. Raw access to the file volume object is highly dangerous, likewise locking down protection to this system is highly important. This means users must not only run in a user account without administrator privileges, but they must have accounts designed to expect surmounting of those privileges.
- Above all we should be entirely cognizant of the fact that regardless of how minute and powerful our heuristic and generic protection mechanisms may be, our job is still not over.
- There are raw disk scanners and comparison systems. These systems are great for finding files not found by the OS, which may be subverted. Some forensic tools may search the entire hard disk. Others merely make a comparison between the files found by the system OS and the files found by a raw search. Naturally, one may hide a file more properly by hiding it "in plain sight" and so avoid such direct detection -- however one can also hide it "outside" of the OS entirely by hiding it in alternate space on the raw disk.
- There are anti-hooking methods which can detect all userland hooks and anti-hooking mechanisms for detecting all kernel level hooks. If nothing is ever hooked, these systems will tell you that these systems are clean. Secondarily, there is always a "war of hooks", the hooking agent can always detect the anti-hooking agent and subvert it.
- I may note at this point that where there may be a "war of hooks", a detection agent may need to become poly or metamorphic itself to ensure the anti-anti-virus agent is never able to detect it. Scaling AV software is easy enough to do, but scaling virus software to detect such attacks is extremely complex and difficult to do while still remaining stealthy.
- Ultimately, any detection agent is likely to be attacked by an anti-detection agent. This means modern malware are increasingly being forced to act as the very agents which operate against them, and as such, detection agents will be forced to return in kind.
- There are hidden process detection agents. There are many types of these detection agents, and these are good to have. In fact, what is run on your system is the single most basic point of both attack and defense, apart from the point where files are written to your system. However, for sleeper agents, this kind of detection mechanism will be limited -- at least for process scanners.
- There are process execution gating agents. These agents forbid or allow execution entirely on systems based on whether or not the process is considered "clean". This is a core issue. Systems that change very little are much easier to protect then systems which are continually running new processes. One avenue of protection eEye is working on is how can we help examine potentially new processes heuristically, so that you can proverbially "have your cake and eat it too".
- Ultimately, even if the execution pathway for malware is through trojanized libraries, initial execution must take place somewhere for the libraries to be trojanized in the first place.
- Behavioral signature based systems. These systems gate behaviors which are allowed or not allowed based on signatures for rules of what is "bad" and what is "good". The difficulty for such a system is in defining the system's understanding of "good" and "bad". A lot of false positives are going to happen with this type of system, and at the same time, such a system is going to be very resource intensive.
General Conclusions
In this paper I have detailed some alternative attack methods and some alternative protection methods against "sleeper agent" style of attacks.
Hopefully, this paper was encouraging and entertaining from an offensive and defense standpoint. I hope that it raises as many questions as answers it provides.
Source: Drew Copley, Senior Research Team Member
Etcetera
Look for us at Black Hat this year and ask your questions in person. Don't forget that our researchers can be bribed with beer, and we will have lots of T-Shirts to give away. The eEye Research Team will be in Las Vegas and individual members will be presenting the following topics:
Remote Windows Kernel Exploitation - Step In To the Ring 0
Presented by: Barnaby Jack, Senior Research Engineer
Time: Day 1, July 27, 2005, 11:15 - 12:30
Almost every possible method and technique regarding Windows exploitation has been discussed in depth. Surprisingly, a topic that has rarely been touched on publicly is the remote exploitation of Win32 kernel vulnerabilities; a number of kernel vulnerabilities have been published, yet no exploit code has surfaced in the public arena. I predict we will see more kernel vulnerabilities in the future, as more core networking components are being implemented at the driver level.
In this presentation I will walk through the remote exploitation of a kernel level vulnerability. A number of payloads will be discussed and demonstrated, and I will explain how to overcome the various obstacles that arise when attempting to exploit ring 0 vulnerabilities. As a final demonstration, we will say goodnight to the Windows OS entirely.
eEye BootRoot
Presented by: Derek Soeder, Software Engineer and Ryan Permeh, Senior Software Engineer
Time: Day 1, July 27, 2005, 15:15 - 16:30
This presentation will cover the eEye BootRoot project, an exploration of technology that boot sector code can use to subvert the Windows NT-family kernel and retain the potential for execution, even after Windows startup—a topic made apropos by the recent emergence of Windows rootkits into mainstream awareness. We will provide some brief but technical background on the Windows startup process, then discuss BootRoot and related technology, including a little-known stealth technique for low-level disk access. Finally, we will demonstrate the proof-of-concept BootRootKit, loaded from a variety of bootable media.
How to Subscribe
To subscribe to this and other eEye newsletters, please visit: http://www.eeye.com/html/resources/newsletters/subscribe.html
Feedback
The eEye newsletter staff welcomes any comments, questions or suggestions from our readers. We hope that you will not hesitate to contact us with any feedback you may have. Send all feedback to vice@eeye.com.
Disclaimer
The information within this newsletter may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Opinions expressed are not necessarily those of eEye Digital Security.
Notice
Permission is hereby granted for the redistribution of this newsletter electronically. It is not to be edited in any way without the express consent of eEye. If you wish to reprint the whole or any part of this newsletter in any other medium excluding electronic medium, please email vice@eeye.com for permission. Permission to reprint readers' comments or questions, and edit where necessary for length and clarity, is assumed unless explicitly forbidden.