- The Threat
- The Tactics
- The Tools
- The Motives
- Changing Trends
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Changing Trends
Over the past several years we have noticed several changes in blackhats' tools and tactics. These changes pose a growing threat to the security community. Four of the most dramatic changes are in their scanning tactics, use of encryption, sophisticated rootkits, and worms.
Scanning tactics are becoming increasingly aggressive. Traditionally, blackhats took the time to identify systems vulnerable to a specific exploit before attempting to exploit them. Now, however, the trend is for blackhats not to even bother identifying such systems; they just identify a service and attempt to exploit it, regardless of the operating system or version. For example, we maintain default installations of both Linux and Solaris honeypots, both systems running rpc.statd service. On average, these systems were scanned one to three times a day, often forRPC. We would then log blackhats' determining whether rpc.statd was running on these systems (rpcinfo query). Then the blackhats simply launched their exploit script. However, the same exploit script was run against both the Linux Intel system and the SPARC Solaris system, even though the exploit works only against Linux systems.
During January 2001, 19 rpc.statd exploits were ran against the Solaris honeypot, even though the exploit would not work on them. This indicates that the blackhats were not taking the time to positively identify vulnerable systems. When in doubt, they simply launch their exploits and move on to the next system. These aggressive tactics could potentially harm systems by crashing services or even the system. Also, this proves that "security through obscurity" does not work. Security through obscurity is a common belief that if the vulnerability is hidden or unknown, the system is secure. For example, organizations change the version number on applications to make a nonsecure application appear secure. Organizations also modify the application so that it does not reveal the version number. Organizations believing that they there are secure using these methods are fooling only themselves. Keep in mind that blackhats often do not even bother verifying versions; they simply attack systems and move on to the next one. The Honeynet Project has seen these tactics used again and again.
The second trend, encryption, makes tracking blackhats more difficult. Traditionally, the Honeynet Project tracked blackhat activity by capturing their keystrokes, by sniffing the network. However, this method is no longer valid, as blackhats are using encryption to communicate with compromised systems. Many operating systems, such as Linux or OpenBSD, come with ssh. Once a system is compromised, blackhats will use ssh instead of TELNET to control the exploited system. Ssh encrypts all blackhat traffic, protecting it from intrusion detection systems or sniffing on the network. Even if encryption utilities are not installed, the blackhats will install their own. In the past five attacks on our honeypots, blackhats uploaded and installed their own encryption utilities to ensure that their actions could not be monitored. In all cases, trojaned versions of ssh were installed, not only encrypting their activity but also putting a backdoor into the system. Encryption makes tracking blackhats far more difficult. In response, we have been monitoring blackhat activity at the system level, such as trojaned shells or kernel drivers that capture keystrokes, and forwarding that activity to a trusted system.
The third development the Honeynet Project has seen is the use of more advanced rootkits. Traditional rootkits replaced system binaries, hiding the blackhat's activities and implementing backdoors. Recently, we have seen more advanced rootkits used, loadable kernel module rootkits, such as Adore, which modify the kernel of the operating system. Then no activity on the system can be trusted. Even if you upload trusted binaries on the system, such as ls or find, their output cannot be trusted, as the kernel cannot be trusted. Blackhats are becoming more and more difficult to track once they compromise a system. What is significant about these kernel-level rootkits is that the binaries on the system are not modified. With traditional rootkits, an attacker modifies the binaries, such as ls or whois, which means that programs like Tripwire can detect that the file has been modified. But because the modifications are being done at the kernel, the binary files do not change, which means that programs like Tripwire can no longer detect that a rootkit has been installed. These kernel-level rootkits are both very powerful and very difficult to detect.
The fourth trend we have seen is one of the most frightening. Blackhats have created worms that not only automate the probing and attacking but also are self-replicating. This means that systems can be exponentially exploited by the blackhat community, with little or no involvement on their part. After compromising a system, the worm then uses that system as a base to replicate itself by scanning and exploiting other systems. The worm continues this process, gaining control of as many systems as possible. We see an example of one such worm in the next chapter. Traditionally, worms have been limited to Windows-based systems. However, in early 2001, we witnessed a growing number of worms, such as Ramen, Lion, or Sadmind/IIS1 that attack UNIX systems. These worms are based on the same tools and vulnerabilities we have discussed so far; it is the fact that they are self-replicating that makes them so dangerous. You can find team member Max Vision's detailed writeup of the worm Lion at Vision at http://www.whitehats.com/library/worms/lion/index.html, or on the CD-ROM that accompanies this book.