eEye Digital Security
Vice Newsletter - January 18, 2006
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.
The feature article this month is from Drew Copley, a regular contributor to VICE. The article below will be presented in person during the Black Hat Federal Briefings 2006 taking place from January 23-26, but we are giving our readers an early look at the tool which uses an agent/master relationship to detect protection systems on the host. However, everyone will have to wait until after the presentation before the corresponding binaries are released. More information about the conference and Drew's talk can be found in the Etcetera section below.
As always, we have reviewed the questions from the pool of responses received since our last edition and the eEye Research Team has provided expert comments and answers. Please keep your questions, comments, and/or criticisms coming.
Enjoy!
Christopher Imes, Editor in Chief
In This Issue
Vulnerability Exposed!
Angel Recon System (ARS) Preview: Heuristic Vulnerability Analysis and Attack
ARS is a heuristic vulnerability analysis system which is meant to heuristically detect the protection systems in place in that system: it does this through an innovative decision tree cloning process. ARS is both offensive and defensive in nature and is designed with three primary key goals in mind:
- Maximum stealth
- Maximum survivability
- Maximum information
The primary goal of ARS is to be a robust reconnaissance system for proof of concept. It is designed to enter the system and very carefully gain crucial information about the nature of the system while keeping itself from quarantine long enough to safely report back this information to the target controller. The secondary nature of ARS is as a defensive heuristic analysis system.
As an attack system ARS is not created to work alone. It is designed as an initial probing system. The real world parallel is found in the usage of the term "reconnaissance".
Technical Overview of ARS
The primary, underlying concept which makes ARS possible is through a system best termed: "cloning".
An advantage in the virtual world for reconnaissance processes is that they can create as many clones of themselves as they wish.
These clones are created and tasked with various dangerous tasks to perform. If the clone succeeds or fails in the tasks designated to it, the master process is informed of this and adds this intelligence to its final analysis. The final analysis is then sent back over the wire to a receiving system.
In general, successes are communicated back to the master process through the creation of flat files. This method of communication has been chosen because it is extremely generic and safe.
In general, failures are found out through the usage of timers in the master process: the clone system is given a dangerous task and does not report back after a liberal amount of time -- it is then assumed that this clone failed at its task and has been stopped by a defensive system. At each step of testing the system, the master process makes decisions based on the returns of past tests. Tests are run according to the returns of previous tests. This is a logical tree structure which very quickly expands until you have a wide variety of end points.
For instance, we try first to create a clone, if we could create a clone, the clone attempts to get some basic information about the system such as: Are we admin? Can we get a list of current security privileges? If we are admin, is the Task Scheduler enabled? If the Task Scheduler is not enabled, can we enable it? If we can, can we bring another clone up to System through it? And so forth.
The clones themselves continue to act as independent agents. For instance, maybe a clone is Admin but can not start the Task Scheduler. Then, that clone attempts to get to System by hooking into winlogon and running a new clone from there. If that does not work, it has another clone attempt to hook into explorer as a basic hooking test. Whatever works or does not work is finally communicated back to the master process.
In the above example we see where this situation can quickly get very complicated. What if the clone was able to get to system by AT.EXE? Then it attempts to hook into winlogon so it can complete the hooking process. What if we are not admin? Then we attempt to hook into explorer. And so forth.
In a defense scenario what you come out with is an analysis like so: a binary was able to perform such and such dangerous actions and gather such and such information such as: whether it is admin, whether it could hook, whether it could get as system through two different sample methods, whether it could write files and where it could write files, whether it could send network traffic, whether it could control services, whether it could get privileges, and so forth.
As additional privileges are found to be had, the system becomes more bold in its' actions automatically -- or it remains stealthy if additional privileges are not to be had.
Examples of more bold attacks would be network communication, file altering, process altering techniques and the like. These kinds of techniques have a higher probability of being generically protected against. Less bold techniques include creating files, copying files, passing information through flat files, and the like. These techniques are extremely generic in scope and are extremely difficult therefore to protect against generically.
The attack scenario relies on the fact that defensive software generally will not look at the parent process ID when quarantining files and consider the creating process a malicious file itself. The quarantined file is caught, but the Recon System, itself, survives. All along the messaging process is designed to operate like any common setup file: which create files, read files, write files, makes copies of itself, and so forth. That is, until it has conclusive evidence that it can act more boldly.
Further, even when a system might look at a Parent Process ID, every pain is made in order to make sure that value is meaningless to the security system. This is done through having winlogon or explorer execute the actual trojan, and through grandfathering processes where deemed useful: further this is done through making sure that the parent process is as innocuous and unknown as possible. This leads us to the metamorphic anti-signature based protection system.
Avoiding Signature Based AV Systems
This whole system is entirely useful if it is not known to signature based systems which inspect binaries looking for static or pseudo-static fingerprint signatures. In any covert operation you want to have deniability: there should be portions of the code which are known. Anyone then catching the code will dismiss it as a mere unknown variant of a known trojan.
They, therefore, will not see a custom made dangerous looking trojan which no one has seen before. Deniability.
We can ensure the master system is known system to AV systems and anyone who would examine it merely by doing a public release. We can try to ensure that the actual used system is an unknown variant by enforcing within it a metamorphic system.
I am just illustrating here, however, the problems and potential solutions from an offensive standpoint. From the defensive standpoint it is simply nice to have an unknown, custom variant in order that the system does not require for AV systems to be turned off for it to run.
From time to time signature based AV solutions have been able to trumpet their ability to find such and such trojan or rootkit: these systems only find the known variant, in the vast majority of these cases. Such security has an useful place in the overall model of security protection, but it is a limited place and should not be overly relied on.
It is always the unknown variant people need to be concerned about.
The Staging System
In the current implementation there are three primary stages. Stage Two is ended with a possible nine different conclusion points. Stage Three consists of sending this preliminary reconnaissance intelligence – the "final analysis" as it is at this stage - back across the network from the vantage point of one of the nine Stage Two possible conclusion points.
Stage Three continues to operate according to the cloning process, excepting that if we have found we have the ability to hook into processes, we use that ability to transmit through the network through potentially trusted processes.
Stage Three ends with seven primary end states. These ending states are the beginning states for Stage Four, which is not implemented.
The seven primary end states for Stage Three:
- NH-U (No Hook Userland)
- NH-S (No Hook System)
- UH-U (User Hook Userland)
- UH-S (User Hook System)
- SH-S (System Hook System)
- Never ran clone
- SH-A (System Hook Admin No AT.EXE)
Stage Three is a prototype stopping point. A more complete Stage Three would also have to take in account failures from Stage Three so that more covert channeling means might be tested: for instance, reverse client connect back testing for firewalled systems which have active IM clients onboard that might be piggybacked, etc. In any complete system, every system should be assumed to be firewalled. However, in this current implementation of ARS it is assumed that testing is done entirely behind the firewall on a local network.
Testing the existence and functionality of an application firewall or other network safeguards is a primary goal of ARS. For maximum stealth and survivability ARS should ensure that it attempts to try every possible route out starting with the stealthiest and only utilizing clones to do so.
Stage Four would be the grounding Stage whereby ARS runs the next round of tests, which would consist, for instance, of attempting to see if changes to existing files is allowed or not and various registry checks.
The complexity of the ARS system is found in the logical treeing system: clones are created by the master process, but they are also created by other clones at certain times. Where hooking is allowed through CreateRemoteThread, then cloning is not used but other processes in effect become clones themselves by being forced to run the hijacked thread.
The clones know who they are by the manner in which they are run, that is various clones are run with various parameters and in the main procedure, the clone understands what it is and what it is to do according to its' given set of parameters.
Release Timeline and Philosophy
The ARS prototype will be showcased and released in January 2006 at Black Hat Federal.
The philosophy on publishing such code is that such systems are inevitable, if not already in use, further many of the components of this system I have seen in the wild. My primary work is on defensive systems designed to combat such attack systems. It is very useful in this work to come up with modern threats, as well as to come up with proof-of-concepts for future, yet unknown attacks.
The primary philosophy behind this is to make such attacks known so that not only might I better fight against it in my own defensive work, but also so that other developers of defensive systems might adapt to such attack techniques before they become a huge problem. Therefore, such releases are a win-win for the consumer.
An additional philosophy behind this release, though one which I believe has already been implied and highlighted, is to educate end users about these potential vulnerabilities in existing security systems. That is, to bring what is in darkness to the light, so that it might become as light.
To further clarify these aims I have designed this system as a defensive analysis system. Like signature based vulnerability scanners have both an offensive and defensive purpose, I have designed this system from the start so that it has immediately applicable defensive applications as a heuristic vulnerability analysis system.
Conclusion
Largely, ARS is designed as a "proof of concept" prototype. It operates under an "assume nothing" master protocol which takes into factor three major design goals: maximum stealth, maximum survivability, and maximum information.
It is released as a defensive tool for examination and study with a primary insight being one of looking at the limitations of current security models and how they operate. The offensive applications of ARS are understated as I only consider such uses legal for military and intelligence purposes.
Addendum: Prior Work
As for the cloning and staging system:
This work arose from experience in this field. If there was a system that I was aware of that already used these kinds of mechanisms, I would have just relied on these systems instead and improved upon them. I do not think the actual cloning activity itself is something that requires a degree in Rocket Science to come up with. On the contrary, these requirements were painfully obvious: and surely inevitable.
Since writing the prototype I have found some mention of these types of technology. In the 70s some Motorola developers made a series of applications called “Robin Hood and Friar Tuck”. You can read about this interesting story online. No doubt I had read of this before and had simply forgotten it.
I got that reference from Peter Szor’s book on Anti-Virus solutions. I simply had not read the chapter this was in until that. He notes my kind of solution where processes look out after each other for survivability as a potential downfall of some AV security products. He is correct. This is not surprising.
He also mentions a variant of a worm which may use this kind of protection scheme.
Also, I found a program called “Ghost” by Guillaume Kaddouch which is a leaktester for application firewalls that uses this kind of scheme. Ghost operates by starting a process, attempting to try to access the network, then killing itself off and starting up again in order to access the network. It is a similar theory.
The largest outside influence on my work, however, which I am aware of, is from the world of physical security. Angel is designed to operate like a reconnaissance agent, ala, SOG or Special Forces style: go behind enemy lines, find target, radio back coordinates for surgical strike. The role of reconnaissance agents is not new, however, and it is really simply a derivation of the very old profession of spying, in general.
Lastly, an amusing excerpt from the old Robin Hood and Friar Tuck work:
"Naturally, the operator called in the operating-system developers. They found the bandit ghost jobs running, and X'ed them... and were once again surprised. When Robin Hood was X'ed, the following sequence of events took place:Reference: Dave Platt, Coherent Thought!X id1Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently-slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system."
id1: Friar Tuck... I am under attack! Pray save me! (Robin Hood)
id1: Off (aborted)
id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men!
id3: Thank you, my good fellow! (Robin)
Source: Drew Copley, Senior Research Engineer
Ask Research
Q: [In reference to your Q&A from last issue defining buffer overflows] I sent out your articles to our web application developers, and they are using Macromedia ColdFusion 8 and .NET 2003. They responded with the answer below saying they are not affected by memory overflow. Any comment on what's been said?
"Since the CLR for .NET and the JVM for ColdFusion manage memory independently from the operating system we can not cause serious memory problems to the point of crashing the servers. Certainly the risk of outsiders doing this exists but no-one needs to worry about me writing a poorly coded application causing memory leaks. Unless we start coding in C/C++, we are safe from this."
A: There are two major points to address: First, if you can do low-level work, you can most likely create memory access problems. Second, the system that processes your code could itself have problems -- you should never make assumptions that the problem is completely taken care of by someone else.
It is okay to say, "I work in a very safe environment, and it is very unlikely that I will have any memory access problems", but thinking that you will not ever have memory access problems could keep you from ever learning and understanding the potential problems.
There are also potentially countless security bugs not related to memory access in these products, and these can be even harder to find and test for than the memory access problems. Understanding secure coding from all angles will be the key factor for developing secure applications.
Have a question you would like answered? Send it to vice@eeye.com, and win an eEye t-shirt if we select your question for an upcoming newsletter.
Etcetera
January 23-26: Black Hat Federal Briefings 2006
The Black Hat Briefings was created to fill the need for computer security professionals to better understand the security risks to information infrastructures and computer systems. Black Hat accomplishes this by assembling a group of vendor-neutral security professionals and having them speak candidly about the problems businesses face and the solutions to those problems. Drew Copley, Senior Security Researcher at eEye Digital Security, will present on his Angel Recon System (ARS) Prototype, which is a Heuristic Vulnerability Analysis and Attack program.
February 1-3: Network & Distributed Systems Security Symposium
The Network and Distributed System Security Symposium Conference is a three day conference in San Diego, CA which brings together innovative and forward thinking members of the Internet community. The eEye Research Team will be hosting a full-day workshop including five presentations on various security issues.
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.