Unfortunately, caged environments come with a large amount of risk. There are two areas of greatest risk for jail deployments. The first is signatures, which makes it is very easy for an attacker to determine they are within a chrooted environment. The second is breakouts. Attackers can break out of the jail and attack the host operating system.
Once a honeypot is identified by its true purpose, its value can greatly diminish. Attackers now know to avoid the system, or they can introduce false information, hiding their true motives or activities. Once an attacker has gained access, jails are relatively easy to detect. It is extremely difficult to replicate an entire operating system within a jail. There are a variety of binaries, configuration files, system libraries, and devices that have to be created and copied. This is an extremely complex process, one that most attackers will likely detect. You will want to ensure that for whatever reason you use jailed honeypots, their value does not dramatically decrease upon detection by attackers.
The second, and by far greater, risk is one of jail breaking. Once an attacker is within a jail, she can potentially break out of the jail and attack the host system, then using that host system to attack, harm, or infiltrate other systems or organizations. Chroot(1) is not bulletproof. In his paper "Using Chroot Security" (included on the CD-ROM), Anton Chuvakin states the following.
Second, the number of ways that a root user can break out of chroot is huge. Starting from simple use of a chroot() call with no chdir()to esoteric methods as the creation of your own /dev/hda or /dev/kmem devices, injection code into the running kernel, using open directory handles outside chroot or chroot-breaking buffer overflows. While system capabilities can be used to render inoperable many of these methods, new ones will likely be found by smart attackers
Commonly used holes within the chroot utility have been patched, making the breaking-out process much more difficult. But no jail can contain an attacker forever. More advanced or persistent attackers can most likely break out of your chrooted environment if you provide too much functionality or fail to take the necessary precautions.
Summary
We have now discussed homemade honeypots, focusing on two types. The first, port monitoring, is a low- interaction honeypot primarily used for capturing malicious attacks and payload. Implementations vary, depending on whether they imitate a service or simply accept connections. The value is not in protecting an organization through detection but rather in providing research capabilities, gaining intelligence on threats that exist in cyberspace. This intelligence can then be used to mitigate the risk of a new threat.
The second type of homemade honeypot we focused on is jails, a medium-interaction solution. This functionality is limited mainly to Unix systems, using the command chroot(1). This command binds a process to a new subdirectory. The process then believes this new directory is actually its root directory. If an attacker exploits the process, he is contained to the subdirectory. Information gathering is based on the application logs and additional utilities from the host system, such as the IDS Snort or strace(1). However, jails were not developed as a honeypot solution but as a security mechanism to reduce risk. Jails can potentially be detected and broken out of. Because of these risks and the complexity in building them, their value is limited to primarily advanced Unix security professionals.
The next two chapters discuss ManTrap and Honeynets, respectively. Both are what I consider high interaction honeypots. These honeypots go beyond what we have discussed so far. In both cases, the attacker is given a full operating system to interact with. These solutions demonstrate the maximum capability in gaining information on attackers. They can also be one of the most challenging.
References
[1] Sub7 Trojan http://www.sub7.org.uk/main.htm
[2] Tutorial on Sub7 http://www.lockdowncorp.com/trojandemo.html [3] Incidents.org http://www.incidents.org
[4] CERT Warning concerning W32/Leaves: Exploitation of previously installed SubSeven Trojan Horses http://www.cert.org/incident_notes/IN-2001-07.html
[5] National Infrastructure Protection Agency http://www.nipc.gov [6] Article covering apprehension of possible creator of W32/Leaves worm http://www.newsfactor.com/perl/story/12828.html
[7] Documentation of FreeBSD Jail functionality http://docs.freebsd.org/44doc/papers/jail/jail.html [8] Wietse Venema, "Strangers in the Night,"Dr. Dobb's Journal, November 2000.
Chapter 10. ManTrap
We have discussed four honeypot solutions so far: three prepackaged low-interaction honeypots, and homemade solutions. Each technology has its advantages and disadvantages. The primary purpose of these honeypots is either detection or research. We are about to move on to a far more powerful and unique honeypot solution: ManTrap. ManTrap has a variety of feature sets that no other solution currently offers, making it an extremely flexible technology. It is also one of the first high-interaction honeypots we will cover. Not only can ManTrap be used to detect attacks but it can be used to gather extensive amounts of information. However, this added functionality and flexibility come at the cost of greater complexity and risk.
ManTrap is a high-interaction commercial honeypot created, maintained, and sold by Recourse Technologies.[1] ManTrap is unique in that it is designed to be not only attacked but also compromised.
Like the homemade jailed environment discussed in the previous chapter, ManTrap creates a highly controlled operating environment that an attacker can interact with. However, ManTrap goes a significant step further and creates a fully functional operating system containing virtual cages rather than a limited operating system. The cages are logically controlled environments from which the attacker is unable to exit and attack the host system. However, instead of creating an empty cage and filling it with certain functionality, as we discussed in Chapter 9, ManTrap creates cages that are mirror copies of the master operating system. Each cage is a fully functional operating system that has the same capabilities as a production installation.
This approach creates a very powerful and flexible solution. Each cage is its own virtual world with few limitations. As an administrator, you can customize each cage as you would a physically separate system. You can create users, install applications, run processes, even compile your own binaries. When an intruder attacks and gains access to a cage, to the attacker it looks as if the cage is a truly separate physical system. He is not aware that he is in a caged environment where every action and keystroke is recorded. Unlike jailed environments, the attacker has a complete set of binaries, devices, and system libraries with which he can interact, just as he would find on a normal system. However, like a jailed environment, the master operating system can monitor and control the attacker.
Another useful feature is that ManTrap can create up to four virtual environments on a single, physical system. Using a single computer, up to four cages can be created, in effect creating four honeypots with one physical system. This functionality is similar to CyberCop Sting or NetFaçade, which we discussed in Chapter 3. These solutions had the capability to emulate multiple operating systems at the same time, creating almost an entire network of honeypots.
ManTrap, however, also has some limitations. First, because ManTrap does not emulate systems but uses caged technology, the logical cages are the same as the base operating system. In fact, the cages are the same version and patch level of the master system.
Also, ManTrap can only support certain operating systems. This is not a software solution that can be installed on any operating system. Instead, it is a highly customized solution designed to modify specific systems. As of early 2002, ManTrap functions only on the Solaris operating system. It cannot be used with any other resource, such as NT, OpenBSD, or Linux. ManTrap is also limited to a specific type of Solaris installation—in this case "Developer plus OEM" packages. This is due to certain software dependencies. ManTrap does not support minimized Solaris builds.