The rising use of honeypots and the need for a better mousetrap

[b][red]This message was edited by 684867 at 2005-3-25 10:56:59[/red][/b][hr]
Message to all Blackhats: The number of Honeypots is rising.
Message to all Whitehats: The number of Honeypot-detection/defeat
strategies is increasing as well.

There is an increasing trend in computer security to track and analyze
the activities of hackers on the internet, using so called "honeypots"
to bait blackhats into an environment where their tactics can be monitored and analyzed. These honeypots are systems tailored to appeal to the blackhat desire for challenge, yet appear easy enough as to warrant the risk associated with compromising a system.

The honeypot may appear to be a switch, router, server, firewall or other network device. Its actual description is concealed
(theoretically) from detection by the hacker. Often the honeypot is a system running emulation software in a virtual environment. The host system executes the virtual environment while tracking its current state over time to reveal the presence and nature of an attack.

The deployment of honeypots have two main objectives: (1) identify vulnerabilities and (2) identify perpetrators. This identification
leads to two profitable outcomes: (1) the patching of the vulnerability and (2) the tracking of the attacker for analysis and later apprehension.

However, the problem arises that in many cases blackhats have detected
the presence of the honeypot. On detection of the trap, the blackhat
either (1) abandons his operation or (2) continues to probe the honeypot for further study of the "new problem." (read challenge). Which outcome occurs seems to be the result of the honeypot operators' reaction to evidence that their trap is detected. If the security team in question reacts poorly, so as to tip their hand to the attacker,
they risk scaring the subject off and losing the opportunity to further study the attacker. Thus, every effort should be made to entertain the blackhat, to entice his ego and increase his sense of bravado. This will result in the collection of much more information concerning the attacker and the discovery of further vulnerabilities/flaws in the honeypot's implementation.

With the rise of the honeypot comes the rise of awareness in the
blackhat community. This awareness has lead to the increasing attempts and ability to detect and defeat the honeypot. In most cases, the honeypots appear to be running in UML (User Mode Linux) or on VMWare. Two such machines were identified recently by the author, using anonymous public computers, as running "free" x-rated sites. Features of the servers were intentionally made vulnerable, so as to entice a "theoretical" attacker to steal passwords from the sites. Upon analysis of the data gained from the mock attack, it was discovered that the sites were running in user mode and that the passwords gained from the exercise were not legitimate passwords. Rather they lasted only a half-hour each attempt, necessitating repeat entries into the servers. E-mail to the webmaster revealed that (1) the webmaster was looking to patch vulnerabilities (2) the server was running as a honeypot--albeit a poorly constructed one at that and (3) said
webmaster was appreciative of the feedback given him regarding the obviousness of his strategy.

However, I have degressed. Is the detection of VMware/UML a bad thing?
Not necessarily. Virtualization is economical in large server farms.
As the ratio of processing power to purchasing price continues to
increase, a lot of organizations will convert into a distributed processing environment where virtual machines can operate over large networks of decentralized machines. Therefore, the detection of virtualized computing environments will not necessarily indicate that a honeypot exists. However, if a virtual environment is properly implemented, the attacker should not know that it is virtual. Hence he/she may be tracked and analyzed. The overall vulnerability to the machine itself can be minimized and the state of a crashed virtual machine should be capable of restore with minimal data loss.

However, recall that the range of skill levels among the blackhat
community is wide and diverse. Many attacks will be compromised if running in a virtual environment. Those who devise these attacks are not the true targets of the honeypot. They expend the resources of the security team on insufficient skill levels and merely provide the aspiring hacker a playground/lab in which to learn. Once detected, the attack can be thwarted by the restart of the virual machine. It is the higher-skill level true hacker that should concern security teams.

The "economical" attacker uses automata "bots" to exploit machines.
This creates a force multiplier easily capable of overwhelming the industry, unless the capability exists to detect the patters in the attacker's strategy and deploy a rapid response. Simply awaiting the attack's climax by deploying second level (help desk) reactions to the fix what is now broken is inadequate. The honeypot has to be capable of concealing its true nature and tracking all activity within its domain. Human-based attacks will more likely discover the honeypot, even if properly implemented.

But the automata (such as the agobot) will not discover the deception. It can then be detected by analysis software on the host machine.
The next question is what to do with a virtual machine once the malware
is detected. The answer is two parts: (1) create a snapshot of the
virtual environment and file system and (2) transparently redirect all
malicious network activity to other virtual hosts so as to perpetuate the deception while allowing the malware to execute. The first reaction allows a security team to submit copies of malicious code to vendors for development of patches/pattern files. The second reaction allows the malware (which could be intended to perpetrate a DOS attack) to continue its mission. This permits the security team to virtualize the network/internet environment and intercept all inbound and outbound traffic, to identify any controlling servers/operators and to protect others from attack by the malware now operating inside the honeypot.

With a firm strategy for the detection of and reaction to an attacker
using this honeypot, attention should be turned to the development of a
virtual environment which does not reveal itself. Discovery of VMWare on a machine is not theory, it has been documented in cases of the notorious Agobot (also known as a Gaobot), which uses the following code to detect the presence of VMWare:

int IsVMWare() {
int version=VMGetVersion();
if(version) return true; else return false; } . . .

This same bot can detect single-step debugging, SoftICE and other
Windows debuggers. The author's purpose appears to have been aimed at avoiding malware analysis. This supports the belief that blackhats are very much aware that many organizations doing malware analysis are dependent on VM environments. (The fact that detection is so easy reveals the known fact: VMWare and its counterparts are not intended for this duty.)

If an Agobot can detect VMWare, can it disable the VM environment and
affect the host machine? This is not known at this time. However, if the user sends keyboard commands to the virtual machine (albeit through the real machine) to cause control of the machine to revert to the host machine, it may be possible to disable the VM. The author has not attempted this, but note that if the VM can be detected then the VM may have other vulnerabilities to allow its exploitation.

The ability of the VM environment to be compromised so easily means the
honeypot environment can be compromised. The attacker could compromise
the deception and turn it over to some arbitrary counter-ploy. As such, the VM must be patched extensively. But is there another answer to the honeypot?

The obvious response would be to take the honeypot into another
dimension: Bait and hook. The bait is the machine the blackhat cannot resist, a server with something the hacker wants to control/access. The hook is a second machine that does not execute code. This machine is attached to the network only as a "listening" device. As such, the hook controls (through serial connection?) the bait computer and listens to the traffic between the internet and the bait machine. Once a pattern of attack is detected, either by monitoring network traffic or by monitoring data from the serial "console" connection to the bait computer, the hook can begin launching its response script (using the bait machine's stdin).

The response script could cause the transfer of the suspect malware to
another location for analysis by dumping the same to the console (stdout), so as to avoid detection. The hook machine could also begin executing commands on the bait machine, so as to perpetuate the deception and further entice the attacker. Either way, the hook is isolated from the attack. Malicious code in the attack becomes benign data for the hook (which plays the role of overwatch). Further the malware is given free reign over the bait machine. Virtualization is not used, and therefore, cannot compromise the operation.

Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.


  • Message to Microsoft and VMware: Honeypots are vulnerable!

    Recently I established a honeypot under controlled circumstances. This was done by installing a server running Redhat 7.2 with VMware installed atop the OS running another instance of Redhat.

    The server was connected to a cable modem connection. An associate (known to this site as Will_E_Coyote) was then solicited to compromise the server (without knowing anything more than the IP address of the machine. The Coyote was asked to break in and recon the machine.

    The Coyote was initially able to compromise the Virtual server layer and take control of the machine. Thereafter a new installation of the OS was made and the server was reconfigured. A second compromise was sucessful within one week.

    This result repeated three times. It was then that I discovered that the underlying OS was compromised. I have no data as to when Coyote managed to detect VMware or to escape into the root machine. The Coyote will not disclose this information, other than to say that he followed the posting I made to this sight.

    Evidently there is a serious vulnerability.

    Excellence Breeds! Go Hard or Go Home.

    Let Penguins rule the earth.
    Break some windows today.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


In this Discussion