HW 10(12)
Sam@98&
Chapter10.docxChapter 10. Scenarios
I have always been a big fan of learning from the mistakes of others. In the computer security realm, by carefully noting the errors of other people, we can gain major insights into how attackers take advantage of these mistakes and undermine computers and networks. Most important, we can also make sure that we apply the appropriate procedural and technological defenses on our own systems so that a similar fate doesn't befall us. I also enjoy seeing concrete scenarios and case studies, instead of abstract ideas. By watching an attack in action, I can get a good feel for how it works and how to apply the necessary defenses in my own environment.
With those ideas in mind, this chapter covers three malware attack scenarios. These case studies explore ideas we've covered in chapters throughout the book, using a variety of different types of malware, including backdoors, worms, and kernel-mode RootKits. Each of these scenarios is based on common mistakes made by computer users, system administrators, and security personnel. The technical details of these cases are all based on fact, representing a synthesis of attacks I've seen in various incidents my colleagues and I have handled. To disguise the corporations, government agencies, and educational institutions originally plagued in these attacks, I've adapted the scenarios to certain familiar themes, and have changed the names to protect both the innocent and the guilty. Any similarities to real persons, living or deceased, are purely coincidental.
As we progress through each scenario, we'll discuss the mistakes made by the victim users and administrators, so we can learn lessons from their errors. We'll also illustrate the advance of malware through a target network environment with numerous figures. In these pictures, when a malware specimen conquers a given machine, we'll show the fact pictorially using the icon from Figure 10.1 .
Figure 10.1. A machine conquered by an attacker's malware.
Now, go grab yourself a bag of fresh, buttery popcorn and an extra-large soda. Draw the shades, dim the lights, and sit back in your easy chair, as we take a look at three different horror-themed scenarios:
A Fly in the Ointment.
Invasion of the Kernel Snatchers.
Silence of the Worms.
In our first scenario, we'll look at how some common mistakes by an end user can result in a major malware infection.
Scenario 1: A Fly in the Ointment
The eminent physicist Dr. Steph Grundle was about to unleash a technological revolution. His masterpiece, a human teleportation system, would completely remake the transportation, shipping, telecommunication, and computer industries overnight. Steph was on the verge of completing his life's work with a maiden voyage across his laboratory. His invention could transfer a human being from one of his prototype telepods to the other in mere seconds. The telepods transferred all data describing the teleported person across a TCP/IP network using Steph's new Human TeleporTation Protocol (which he called "HTTP" for short). "Talk about a killer app!" shouted an excited Steph, unaware of the irony of his own statement.
Steph's lab was located inside an abandoned factory, and featured a small network linking together three systems, as illustrated in Figure 10.2 . Each of his two telepods was hooked up to a machine running Windows 2000, which was used to transfer the data needed to reconstitute the teleported person. The overall teleportation process was controlled from a third Windows system, which Steph called the teleportation controller.
Figure 10.2. Steph's network included three Windows systems.
To finish the project and launch the first actual test, Steph needed one more gizmo: a molecular analyzer. Given his tight budget, he decided to shop on the Internet to find one at a reasonable price. To surf the Internet, Steph used the teleportation controller system. The machine had a fast processor, which was ideal for controlling the teleportation process and rendering Web pages quickly
Mistake Number 1: Steph used a critical production server to surf the Internet instead of a desktop machine. This activity exposes the production system to a large number of possible browser-based vulnerabilities. Compromise of a desktop system isn't a cheery thing, but it's certainly much better than a compromise of a critical infrastructure server. Internet surfing should be prohibited from critical Web, DNS, e-mail, and application servers. In fact, uninstalling the browser from such machines is a reasonable idea, as they should never need to use its capabilities. Any updates or patches loaded onto these systems should be manually transferred and installed by an administrator.
Steph's favorite Internet search engine returned hundreds of hits for e-commerce companies selling his needed device. He started at the top of the list, clicking on each link returned by the search engine, as shown in Figure
10.3 . The first three links included some nice tools, but at too steep a price. He absent-mindedly clicked on the fourth link, which actually took him to the Web site of a nasty computer attacker who had included the words molecular analyzer all over his Web page. The attacker was targeting physicists, and used these words to try to draw them to his Web site like flies to flypaper.
Figure 10.3. Steph surfed the Internet using the teleportation controller machine.
Unfortunately for Steph, the attacker included a malicious script on his Web page that would automatically run inside of unpatched Web browsers that visited the page. Steph hadn't patched his Web browser in over six months, so a script from the attacker's site was able to exploit a well-known hole in his
browser. Now, this browser vulnerability didn't let the evil Web site execute an arbitrary program on the browser. It was far more limited. Instead, the hole let the malicious script from the Web site write a file called Notepad.com to Steph's computer, as illustrated in Figure 10.4 .
Mistake Number 2: Steph surfed the Internet with an unpatched Web browser. Older browsers have huge numbers of flaws that let an attacker read or write files on an unpatched machine. Some of them even let a bad guy execute arbitrary programs on a victim's machine. New vulnerabilities are constantly being discovered as well. You should strive to keep your browser up-to-date, applying patches, hotfixes, and service packs from the browser vendor in a timely manner.
Figure 10.4. The Attacker's Web site used a script to write the Notepad.com file to Steph's computer.
Tragically, Steph was running his browser while logged into an account on his machine in the local administrator's group. Therefore, the attacker's script could run with administrator privileges, and write the Notepad.com file to the teleportation controller's System32 folder. The System32 folder contains many of the commonly used programs on a Windows machine, such as Notepad.exe, Calc.exe (the built-in Windows calculator), and Sol.exe (the Solitaire program). Running with administrator privileges, the script could easily dodge the file system's security permissions and write to this directory.
Mistake Number 3: Steph had surfed the Web using an account in the administrator's group. Therefore, the attacker's script could write a file containing malware in the System32 directory. If Steph had used another account, the script likely would not have had permission to write in this
folder, even with a vulnerability in the Web browser. As we discussed in Chapter 4 , for day-to-day use on a Windows system, do not log on as an account with Administrator privileges, either the Administrator account or as a user in the Administrators group. Never read e-mail or browse the Internet as an administrative user. If an attacker can trick you into running a program and you are logged in as Admin, the attacker will have complete control of your machine. If you need to perform administrative tasks, login as a nonadministrative user and use the Windows RunAs feature to start programs. To use RunAs from the GUI, hold down the Shift key and right-click the program's icon to select RunAs.... From the command line, simply use the runas command by
typing runas /user:[username] [program].
After the attacker's page with the nasty script loaded onto his system, Steph looked around the page, but didn't see anything for sale. He just saw screen after screen of the words molecular analyzer, so he hit the Back button. Back at his search engine, Steph clicked on the link for the next result, which took him to a company selling the equipment he needed, and at a great price. Even better, this company offered one-hour shipping to anyone working in the factory district of Steph's town. Steph quickly entered his order, smiling about how lucky he was to have found exactly what he wanted.
In reality, Steph's teleportation controller system now housed the evil Notepad.com file. To create this file, the attacker had used a binder program to fuse the normal Notepad.exe together with a backdoor program. By binding Notepad.exe and a backdoor together, the attacker had created a monstrous combination.
An hour later, a delivery man rang the doorbell and dropped off Steph's analyzer. Steph rapidly installed the new hardware, as he got ready for his first attempt at teleportation. For posterity, Steph was in the habit of recording a diary in real time of all of his activities in a text file. Due to the historic importance of this impending event, Steph updated his diary to express his excitement. He ran the Notepad text editor to update his diary. To kick off Notepad, Steph clicked the Start menu of the teleportation controller and selected Run…. In the resulting dialog box, he typed "notepad" to bring up the editor.
Mistake Number 4: Steph ran Notepad by typing only "notepad", and not "notepad.exe" into the Run dialog box. As we discussed in Chapter 2 , when a user doesn't provide a file suffix for a program to run, Windows first looks for .COM files and then .EXE files. Steph should have typed "Notepad.exe", giving the full name of the program he wanted to run.
Because Steph typed only "notepad", Windows executed the Notepad.com file written to the machine by the attacker's script. When first executed, this nasty file ran the real Notepad.exe program the attacker had included in the bundled package, bringing up the familiar text editor on Steph's machine. Everything looked perfectly normal. However, in the background, the other, hidden component of Notepad.com ran. This program undermined the security of Steph's machine from the inside, installing a backdoor on the teleportation controller machine, as illustrated in Figure 10.5 .
Figure 10.5. Steph inadvertently installed the backdoor on the teleportation controller machine.
Unaware that the backdoor had just installed itself on his machine, Steph typed in a single sentence as a journal entry into Notepad: "I'm about to make my first jump!" Happily, Steph had installed a personal firewall on the teleportation controller, so the backdoor could not make contact with the attacker. The malware author had configured the backdoor to try to shovel shell back across the Internet, but Steph's personal firewall repelled its attempts to reach across the Internet. Steph had also installed an antivirus program on his system. Unfortunately, he only updated its virus signatures once per month. Therefore, the attacker's code was blocked by the personal firewall, but undetected by Steph's antivirus program.
Mistake Number 5: Steph had installed a personal firewall, and
benefited from its protection. However, he updated his antivirus tool only once per month, leaving it out of date most of the time. As we discussed in Chapter 2 , new viruses are released and discovered almost daily, so signatures should be updated at least weekly or even each time the system boots up. Some antivirus tools periodically poll the antivirus company and update their signatures continuously. From a desktop system, it is extremely important to use both a personal firewall and an up-to-date antivirus program. One without the other isn't adequate protection.
Although it couldn't shovel shell back to the attacker, the backdoor had another trick up its sleeve. After it was installed, it began searching the network looking for available file shares. Steph had configured Windows file sharing between the teleportation controller and his telepod computers so he could quickly move files between his lab systems. When the malware found these shares, it wrote itself into a file called Notepad.com on the Windows machines connected to the telepods, as shown in Figure 10.6 .
Figure 10.6. The malware spread to the telepod machines.
Steph had just purchased the telepod computers two weeks earlier and installed up-to-date software on them. These systems included a more recent set of antivirus signatures. When Notepad.com arrived on the telepod computers, the installed antivirus program detected it instantly. It alerted Steph, and automatically surfed to the antivirus vendor's Web site to display details about this particular malware specimen. Using the browser, the antivirus program popped a dialog box on the screen, shown in Figure 10.7 .
Figure 10.7. The message from the antivirus program
displayed on the telepod computers.
Steph heard the telepod computers' bleep tones as the warning message appeared on the screen. Looking at the telepod systems, he clicked the Uninstall Virus option in the antivirus program's interface, eradicating the malware from the telepod boxes. "Glad I found that little gnat," Steph muttered to himself. Unfortunately, the malware still resided on the teleportation controller box.
Mistake Number 6: With a virus on two machines in his rather small internal network, Steph should have updated his antivirus program on his third system. If one of your machines detects the presence of malware, you should eradicate it, and then look for the same specimen on other machines where it might not have been detected. Steph did not do this, a mistake he would pay for dearly.
The time had finally come for Steph to test his teleporter. He finalized and double-checked all configuration options on the teleportation controller and the two telepods. The 10-second countdown had begun as he walked into one of the telepods. Just as he stepped inside, a small housefly zoomed into the telepod with Steph. Normally, this little intruder wouldn't be a problem at all, because Steph had written a short program that could decouple two genetic patterns. This Gene_decoupler.exe program, installed on the teleportation controller, was designed to send two or more different beings through the teleporter without any ill consequences.
However, out of pure maliciousness, the attacker had designed the backdoor program to start killing running processes on a victim machine if it couldn't successfully shovel shell back to the attacker. Just as the teleportation sequence started to run, the backdoor began shutting down processes on the teleportation controller, as shown in Figure 10.8 .
Figure 10.8. The backdoor started shutting down processes on the teleportation controller at precisely the wrong instant.
At exactly the wrong moment, the malware killed the Gene_decoupler.exe process. With a brilliant flash of light and a loud "Zap," the teleportation process worked! Steph had been transmitted across his laboratory, making history. He was completely thrilled. Unfortunately, the housefly that entered the telepod with Steph was nowhere to be found. At what should have been his ultimate moment of triumph, Steph's life (to say nothing of his genetic code) was scrambled by malware.
So, Steph's mistakes cost him dearly. However, end users aren't the only ones who make mistakes. In our next tale, we'll analyze some errors committed by an incident handler that allowed an attacker to manipulate the kernel of various target machines inside a corporation.
Scenario 2: Invasion of the Kernel Snatchers
It had all started last Thursday. Miles Burnile, head of the computer incident response team for SantaMira Corporation, had just returned from a week-long information security conference. He had enjoyed the training, but didn't pay very much attention in class. The instructor was a bit quirky, frequently using bizarre and obscure movie references to hammer home a point. As he strolled into his office, Miles received an urgent call from Ed Ministrator, one of the company's best system administrators. Ed was in charge of managing several of SantaMira's most important systems, including several crucial internal Web servers.
"What's wrong?" questioned Miles.
"I think there's a problem with one of our main internal Web servers," Ed responded. "At first glance, everything looked the same, but it isn't. It is as though something evil has taken possession of the machine." The SantaMira Corporation network, including the affected internal Web server, is illustrated in Figure 10.9 . SantaMira relied on a textbook trihomed firewall architecture. Inside the network, we can see the impacted internal Web server, as well as the internal DNS system, an IDS sensor, and Miles' own computer.
Figure 10.9. The SantaMira Corporation network, including the troublesome internal Web server.
"Have you looked for unusual files, processes, or listening TCP and UDP ports,"
Ed responded, "Yes. I even ran our file integrity checking tool, but no changes were reported. That's just it … there is no difference you can actually see. The box is just dull and lifeless, not as responsive as it normally is. I just can't put my finger on any changes, though."
Without any concrete evidence of an attack, Miles was growing impatient. After all, his job involved catching bad guys invading SantaMira's computers, not troubleshooting performance problems for system administrators.
"Well, I gotta run. Call me back if anything else turns up," said Miles, as he quickly extracted himself from what he thought was a waste of his valuable time.
Mistake Number 1: Miles ignored a serious plea from a knowledgeable system administrator. System administrators are a crucial line of detection and defense against malware. If you are on a security team and receive a report from a solid system administrator about some anomalous behavior, pay careful attention. Many good system administrators develop a gut feel for whether their system is behaving appropriately, and you ignore their pleas at your own peril.
Two hours later, Miles received an urgent message on his pager from the company's network-based IDS. Miles had many other faults, but he was very careful to make sure that he deployed network-based IDS sensors near crucial internal systems, such as the primary internal DNS server. One of the internal IDS probes had detected a buffer overflow attack against SantaMira's Linux-based primary internal DNS server, as illustrated in Figure 10.10 . Buffer overflows are one of the most common attack types on the Internet today, and they involve entering more data into a program than the coders originally expected. By overflowing a buffer, the attacker (or an automated worm) can take over and completely control a victim machine. Thousands of buffer overflow attacks exist, and this piece of malware exploited a well-known buffer overflow in the internal DNS server. Publicly available code exploiting this vulnerability had been posted on the Internet for more than two months. The source address of the attack was the internal Web server that Ed Ministrator called about earlier, and the source port of the attack was UDP port 4564.
Figure 10.10. The internal IDS probe detected an attack against the internal DNS.
Although Miles was able to sprinkle network-based IDS sensors on the internal network, he was not able to convince management to implement a thorough patching process for keeping internal systems up to date. Sure, the company rapidly deployed patches to their externally accessible DNS, Web, and mail servers on the Internet-facing DMZ, but internal servers, including the internal DNS and Web servers, often languished without patches for six months to a year.
Mistake Number 2: SantaMira Corporation did not vigorously apply patches to critical internal systems. The primary internal DNS server is one of the crown jewels of a company, and attackers know this. By breaking into an internal network through a renegade modem or wireless access point, an attacker can quickly locate an internal DNS server. If it hasn't been recently patched, the bad guy could employ one of several buffer overflow attacks against DNS servers to take over the internal machine. With control of the internal DNS server, an attacker can alter DNS records to redirect traffic on the internal network. Organizations should carefully patch their most critical internal servers, especially the primary internal DNS server.
With the internal DNS server potentially compromised, Miles needed to see for himself what was going on. As shown in Figure 10.11 , he used the secure shell tool to remotely log in to the internal DNS server using an account that had been created for the incident handling team. Once logged in to this Linux system, Miles switched to a root-level account so he could investigate what the attacker might have done.
Figure 10.11. Miles logged into the internal DNS server to
investigate.
Staring at the root command shell prompt of the Linux-based internal DNS server, Miles wanted to quickly verify the system's IP address and network configuration, so he typed:
# ipconfig
Miles had inadvertently typed the Windows command for checking the network configuration, when he had meant to type the UNIX command ifconfig, with the letter f instead of a p. Under normal circumstances, the system would have responded with a "Command not found" error. However, these circumstances were not normal. You see, the account Miles was using on the internal DNS server had ".", the current working directory, in its path. Therefore, when Miles absent-mindedly typed ipconfig, the system searched his path, including his current working directory, looking for a program named ipconfig.
Mistake Number 3: Miles' account included "." in its path. Typos happen, but you don't want a simple typographical error like ipconfig to completely undermine a system. Also, you don't want an attacker to create an evil backdoor program with the name of an existing command
(e.g., ls, ifconfig, or netstat) that will be executed if "." is in your path. Therefore, on UNIX machines, make sure your path doesn't have a "." in it, as we discussed in Chapter 6 .
Although Miles didn't realize it, the attacker's original buffer overflow exploit code had not gained root-level privileges on the victim machine. The attacker's exploit code merely broke in as a low-level user account using a DNS server buffer overflow exploit. However, even from this low-level account, the attacker was able to put a file named ipconfig on the victim machine in a common, publicly accessible directory on the system. The attacker's ipconfig file included an installation package that, when executed with root permissions, installed a RootKit on the victim machine. By typing ipconfig from a root-level account, Miles had inadvertently installed the RootKit for the bad guy. In one fell swoop, the head of the incident handling team had accidentally given the bad guy root access and installed a RootKit to hide that access. The attacker had even set up the evil ipconfig tool so that it ran the ifconfig command after installing the RootKit. Therefore, when Miles ran ipconfig, he saw the output of the ifconfig command. As illustrated in Figure 10.12 , the internal DNS server now had a RootKit installed on it.
Figure 10.12. Miles inadvertently installed a RootKit on the internal DNS server.
After running ipconfig and viewing the resulting system configuration, Miles continued to look around the system. He looked for listening ports using the netstat na and lsof i commands. He ran ps and top to look for unusual
Mistake Number 4: To look for suspicious activity, Miles used the built-in commands loaded onto the potentially compromised system. Miles ran netstat, lsof, ps, and other commands from the file system of the victim machine. An attacker might have altered these commands with a user-mode RootKit. By altering these commands, the bad guy's RootKit could hide network usage, files, and processes on the victim machine, foiling Miles' attempts to look for signs of the attack. As we discussed in Chapter 7 , to get more trustworthy answers during an investigation, Miles should have used statically linked binaries from a trusted CD-ROM (e.g., the FIRE or Knoppix distributions of Linux), and not the commands installed on the system. Although a kernel-mode RootKit can fool even statically linked binaries from a CD, their results are still far more trustworthy than the embedded commands on the machine.
Because Miles didn't see any evidence of a successful attack against the internal DNS server, he logged out of the machine, shrugging off the whole situation to a false positive from the IDS sensor. Typically, he received about three or four false positives per week, so he wasn't about to lose any sleep over this issue.
After another hour passed, Miles' phone rang again. It was Ed Ministrator, this time much more frantic. "You'd better get over here right away!" exclaimed Ed. "That internal Web site I told you about earlier just crashed. I looked at the logging server, which said that the hard drive was full. However, I verified just this morning that over 10 Gigs of space were left on the disk!" The crashed internal Web server is highlighted in Figure 10.13 .
Figure 10.13. The internal DNS server crashed.
Miles responded, "That's three different events associated with that box: sluggish performance, an apparent source of a potential buffer overflow attack against the internal DNS server, and a crash, all within a couple of hours." Given this mounting evidence, Miles' attitude toward these events now changed. He didn't know what it wascall it a premonitionbut in the back of his mind, a bell was ringing.
Miles raced over to the data center to meet Ed within five minutes. In the data center, they yanked the hard drive from the internal Web server so Miles could make a backup of the machine for more detailed analysis. Ed rebooted the server, which, to their surprise, started to function normally again. The drive didn't appear to be full, and still had over 10 GB of free space.
Miles went to his analysis laboratory and proceeded with his analysis of the hard drive. He put the drive into a machine in his lab, and booted from it. Again, he started to search for unusual files, processes, and network port usage. As before, nothing out of the ordinary turned up.
Mistake Number 5: Miles performed his analysis by booting from the hard drive image of the impacted system. The attacker had actually employed a kernel-mode RootKit, so Miles was relying on an untrustworthy kernel to perform his analysis. Of course, the kernel-mode RootKit had hidden all signs of the attack. As we discussed in Chapter 8 , Miles should have performed his laboratory analysis by booting from a trusted CD-ROM (e.g., FIRE or Knoppix) and mounted the suspect hard drive. That way, the analysis tools and the kernel itself can be trusted during the analysis.
Miles puzzled through this strange set of circumstances in his mind. Then, on a
whim, he installed the chkrootkit tool from a CD-ROM. He ran the tool, which performed several diagnostic checks to look for inconsistencies in the system. Sure enough, chkrootkit discovered some hidden directories on the file system. The chkdirs component of chkrootkit had discovered that the link count of the /home directory didn't match the apparent number of directories inside /home. As we discussed in Chapter 8 , the link count of a given directory should equal the number of subdirectories plus two, as one link is needed for its parent (the ".." link), one for itself (the "." link), and then one for each directory inside. Chkrootkit had caught the system in a lie, as there were more directory links inside of /home than the ls command could see. Miles pondered the situation and then slapped his forehead. "I'll bet we've got a kernel-mode RootKit here," he shouted.
Miles quickly rebooted the system, but this time configured the machine to boot from his FIRE CD-ROM. After FIRE loaded onto the system, Miles mounted the hard drive and changed to the home directory. Running the FIRE kernel and commands from the FIRE CD-ROM, Miles quickly observed two previously hidden files inside of /home called PoD and ipconfig. The ipconfig file was merely a script to install PoD on a victim machine. An identical copy of the ipconfig file was also loaded into a user's home directory on the machine. Comments inside the ipconfig script indicated that PoD was an acronym for Portal of Destruction. In reality, PoD was a souped-up version of the SucKIT kernel-mode RootKit. Some attackers had altered the machine's kernel, replacing valuable kernel functionality with the SucKIT malware.
The bad guys had improved on SucKIT, however, by adding features that automatically tried spreading the code to DNS servers using worm propagation techniques to exploit a buffer overflow. Miles faced some combo malware, which included a kernel-mode RootKit and a worm. When PoD was installed on a victim machine, a timer began running. After two hours, PoD would try spreading itself via a buffer overflow attack against accessible DNS servers, writing the malicious ipconfig and PoD on target DNS servers.
"Oh my gosh!" thought Miles, "Our internal DNS server was infected by the PoD-people just over two hours ago. It's going to start spreading." Just then, Miles received a pager notice from the IDS sensor on his Internet DMZ. The external DNS server had been hit! As illustrated in Figure 10.14 , his pager alert showed that the packet had originated on the internal DNS server machine, from a UDP source port of 4564.
Figure 10.14. The internal DNS server attacked the external DNS server, triggering the external IDS.
Miles needed to contact the external DNS administrator, and fast. His frenzied search through his contact info for various administrators turned up dry. He didn't have the name or phone number handy for the external DNS administrator.
Mistake Number 6: By not having the name and phone number for the administrator of a vital DMZ system, Miles wasted valuable time. An incident handling team should have a complete, up-to-date list of the administrator names and phone numbers for all critical Internet-facing servers, as well as mission-critical servers on the internal network.
After 15 minutes of searching for the right number, Miles finally called Ed, the administrator for the internal DNS server. Miles asked Ed for the phone number for his counterpart in charge of SantaMira's external DNS server. Ed gave him the number for Sally Operator. Miles called Sally, and explained to her that the external DNS server had been compromised. Making matters worse, this external DNS server could send packets directly to the Internet. If they didn't stop the PoD spread at SantaMira's external DMZ, the attacker's tool could jump to systems all over the world. Miles frantically shouted to Sally, "Listen! If you don't … if you won't … if you fail to understand, then the same incredible terror that is menacing me will strike at you and the rest of the Internet!" Miles feared that the external DNS server would start spreading the PoD malware across the Internet, as shown in Figure 10.15 .
Figure 10.15. Miles feared that PoD would spread from SantaMira across the Internet.
Miles and Sally worked with the router management team to implement a packet filter rule on the external border router that would block all outgoing packets from UDP port 4564. After they deployed the filter to arrest the PoD spread, as shown in Figure 10.16 , Miles and Sally rebuilt the external DNS server from scratch, installing the operating system, DNS server, DNS configuration files, and all relevant patches. Knowing that the software on the machine couldn't be trusted at all, they rebuilt the entire system. While the rebuild occurred, the uninfected secondary DNS server handled all DNS resolution for SantaMira Corporation.
Figure 10.16. An egress filter blocked the spread while Miles and Sally fixed the infected server.
Thank goodness Miles was able to save the world from that kernel-manipulating malware. In our next scenario, we'll turn our attention to a worm-wielding bad guy, and the mistakes made by an e-commerce company that allowed the worm to dominate its internal network.
Scenario 3: Silence of the Worms
Hannibal Cracker wanted to "own" some computer systems. Not "own" in the sense that he had title and deed to the machines; he wanted complete remote control of other people's computers. Hannibal wasn't an attacker for glory and fame. Cold, hard cash was his prize. Hannibal Cracker had a lifestyle to maintain: an appetite for overseas travel, some debts accumulated over the years, and a desire for cool electronic gadgetry. Hannibal's economic situation was pretty bleak as he had recently lost his job. He was pretty good at slinging code, and fancied himself something of a security expert.
Hannibal cooked up a scheme to make a little money from a computer attack. To understand his plan, let's look at the world viewed by Hannibal, as shown in Figure 10.17 . Hannibal's computer, shown wearing a black hat, was connected to the Internet through a cable modem. Of course, the Internet is the home of enormous numbers of vulnerable computers operated by a huge number of unsuspecting potential victims. In our scenario, one such potential victim was Clarice Commerce, a medium-sized online financial site, which allowed customers to engage in generic financial exchanges. The Clarice Commerce network architects took a sandwich approach to implementing their DMZ, with two layers of firewalls separating the DMZ from the Internet as well as the internal network. The external firewall blocked nearly all traffic, except for incoming Web and e-mail traffic. The inside firewall was also quite limiting, but did allow incoming File Transfer Protocol (FTP) connections from the DMZ Web server, so that the Web server could deposit financial information on the internal network.
Figure 10.17. Hannibal's system and the Clarice Commerce network.
Hannibal custom-crafted a worm to carry out his attack. While he cut and pasted from some of the publicly available worm code he found on the Internet, he also used his programming skills to tailor the worm to his own desires. This wasn't one of those loudmouth worms you read about all of the time, busting into systems and making major, noticeable changes. Whereas a lot of worm writers look for quick fame by creating a program that defaces Web sites or launches packet floods, Hannibal's worm attempted to keep quiet.
Hannibal's silent worm propagated to several systems on the Internet, taking them over by exploiting a buffer overflow vulnerability found in many publicly accessible Web servers. Hannibal selected a new buffer overflow exploit discovered one month earlier by security researchers, and embedded it in the worm he unleashed on the Internet, illustrated in Figure 10.18 .
Figure 10.18. Hannibal launched the worm.
After a second round of attacks, the worm spread further and faster. Eventually, Hannibal's worm began to encounter some very interesting servers. Among numerous other systems, the worm took over the Web server of Clarice Commerce, as shown in Figure 10.19 .
Mistake Number 1: Like many others on the Internet, Clarice Commerce failed to install a patch to repair a recently discovered vulnerability in its Web server. Many software vendors release security vulnerability fixes on a frequent basis. If these patches are not applied in a timely fashion, an attacker can take over a target system. To defend your own systems, you must have an explicit process for determining when patches are available. Someone on your staff should subscribe to vendor and security mailing lists that distribute such warnings.
Mistake Number 2: Clarice Commerce did not configure their systems to minimize security vulnerabilities, allowing the worm to easily take over the system. As we discussed in Chapter 7 , your organization should have detailed security hardening guidelines and employ tools to configure your systems securely, such as the Bastille Linux hardening tool available at www.bastille-linux.org .
Figure 10.19. The worm continued its malevolent spread, hitting Clarice Commerce.
Hannibal programmed his worm to send an e-mail after a specified interval of time elapsed. The worm sent the e-mail to an anonymous e-mail account Hannibal owned at a popular free e-mail site on the Internet, as illustrated in Figure 10.20 . The worm's e-mail included the Internet address of the victim
machine, as well as a copy of the default home page of the Web server that was just compromised.
Mistake Number 3: The Clarice Commerce Web site was allowed to send outgoing e-mail. For most organizations, an Internet-accessible Web server shouldn't be allowed to send e-mail. As we discussed in Chapter 3 , all outgoing connections from the Web server should be blocked, except responses to Web requests, and any other communication with a vital business need, such as database access or management traffic. The firewall and routers protecting a Web server should block all connections other than those explicitly required.
Figure 10.20. The worm sent e-mail with the default Web pages of compromised machines.
Of course, Hannibal wanted to read this e-mail. However, he didn't want to log in directly to the free e-mail service, as that might give away his source location. Instead, his worm had another trick up its virtual sleeve. Hannibal designed his evil worm to forward e-mail requests from Hannibal, through a worm-infected Web server, to the free e-mail service. In essence, Hannibal used his worm running on a victim machine to bounce his connection for reading e-mail, as shown in Figure 10.21 . If and when investigators started to look for him, they would have to follow a confusing trail of bounced connections. On receiving e-mails from his worm minions, Hannibal began to browse the messages looking at the default Web pages of the Web sites his worm had conquered. "Where can I find someone with money?" Hannibal asked.
Figure 10.21. Bouncing off of one victim, Hannibal retrieved anonymous e-mail.
"Hello, Clarice," Hannibal snarled, using his monotone gravelly voice when he spotted the Web page from Clarice Commerce. By quickly scanning the home page in his e-mail, he surmised that this Web site accepted sensitive customer financial information across the Web. Hannibal's worm had discovered hundreds of other similar sites. Although Hannibal attacked many of these victims, to keep our focus, our narrative will center on Hannibal's actions against Clarice Commerce.
Next, as shown in Figure 10.22 , Hannibal started sending commands to the worm waiting on the Clarice Commerce Web site. Hannibal's worm included a backdoor, so he could send it commands to have it do his bidding. He used an Internet Control Message Protocol (ICMP) backdoor to carry his communication with the worm, so all traffic on the network looked like a ping and ping response, with no TCP or UDP ports in use. With the backdoor embedded inside the worm, Hannibal had complete remote control access of the Clarice Commerce Web site.
Mistake Number 4: Clarice Commerce had inadequate intrusion detection capabilities. Many remotely accessible backdoor programs use defined patterns for communicating across a network. An IDS analyzing the network traffic can alert a company to the use of these types of tools. Such an alert can trigger an investigation so an organization can minimize damage early in the attack process. An IDS cannot detect all such anomalous behavior, but it can certainly help. Organizations should deploy some form of intrusion detection capabilities on their sensitive
networks, such as their Internet gateways.
Figure 10.22. Hannibal remotely accessed Clarice Commerce using an ICMP backdoor.
Using the ICMP backdoor, Hannibal installed a user-mode RootKit on the Web server machine. This RootKit hid the ICMP backdoor process, as well as other changes Hannibal made on the system, by replacing critical operating system executables.
Mistake Number 5: Clarice Commerce did not utilize a file integrity checking tool on their external Web site. Because of this major oversight, they could not detect the user-mode RootKit installed by Hannibal. As we discussed in Chapters 7 and 8 , an organization should deploy a solid file integrity checking tool on vital servers, such as publicly accessible Web, mail, and DNS servers, to look for unauthorized changes to those machines.
Hannibal poked around on the Clarice Commerce Web server, looking for sensitive customer information. He found a dozen customer names and credit card numbers in a local cache. Although this limited number of credit card numbers was useful, it was not yet the motherlode of sensitive data Hannibal was after.
Mistake Number 6: Clarice Commerce allowed sensitive data to sit on its Web server machine for a period of time. Internet Web servers are extremely popular targets for computer attackers. Any sensitive data
gathered through such a Web server should not be stored locally. If the Web server has a vulnerability, an attacker will be able to steal any information sitting on this machine. Therefore, your Web application should gather the required data from a user and quickly move it to another, more secure machine that does not have a Web server installed on it. The Web application should encrypt the data and send it to a database, transaction, or other application server immediately.
Using his access on the external Web server, Hannibal uploaded computer vulnerability scanning tools to look for security weaknesses on the rest of the network. From the vantage point of the Web server, Hannibal scanned the internal network looking for vulnerabilities. The firewall screened most of the traffic from the Web server going into the Internal network. However, the firewall did allow the Web server to transmit FTP packets into the network. Hannibal therefore focused his scan on weak FTP servers as shown in Figure 10.23 .
Figure 10.23. Hannibal began scanning the internal network for weak FTP servers.
As shown in Figure 10.24 , Hannibal's scan of the internal network was successful. "Wonderful!" growled Hannibal. He had discovered an internal FTP server with a security flaw allowing him to take it over. A configuration error on the machine let Hannibal compromise the system. He quickly took over the FTP server and installed the Netcat program we discussed in Chapter 5 to implement a backdoor.
Mistake Number 7: The internal FTP server was not securely
Figure 10.24. Hannibal took over a misconfigured internal FTP server and used it to implement a backdoor.
In addition to a backdoor, Hannibal installed a sniffing tool on the internal FTP server. Sniffers grab all data passing across the network interface. Because the FTP server was located in a data center on the same network segment as many other systems, Hannibal was able to steal sensitive customer information flowing on the internal network. Many sniffers do not work well on a switched network, such as the one employed by Clarice Commerce. However, Hannibal used Address Resolution Protocol (ARP) cache poisoning to redirect traffic on the switched network so he could sniff it as we discussed in Chapter 5 .
As depicted in Figure 10.25 , Hannibal's sniffer grabbed all kinds of sensitive information on the internal network. In addition to sensitive corporate e-mail messages and passwords, Hannibal also sniffed customer names, accounts, and credit card information from the internal network. This information was the motherlode Hannibal desired!
Mistake Number 8: Clarice Commerce sent sensitive data across their internal network without any encryption. Although this is unfortunately a very common occurrence on many corporate, government, and even
Figure 10.25. Hannibal sniffed sensitive customer data, including personal information and credit card numbers.
Now that Hannibal had his much desired data, it was time for him to cash in. He sent an extortion note to Clarice Commerce, as shown in Figure 10.26 . The extortion e-mail said:
From: Security Consultants R Us
To: Web Admin
Subject: Hire Us To Help Fix Your Poor Security
It has come to our attention that your Web site and internal networ
have serious security vulnerabilities! We would like to offer our
services to help you fix those problems. Because we know you are ve
busy, we have worked hard to make this simple for you. We have a
qualified, professional staff that can remotely access your systems
apply the patches without any work on your part!
Keep in mind that these vulnerabilities are major, and can be used
extract sensitive data about your customers. For example, a moderat
skilled attacker could easily grab the following information from y
systems:
John Doe
Fred Smith
Cred Card # XXXXXXXX, Account info:
Cred Card # YYYYYYYY, Account info:
To accept our offer, please transfer $25,000 into our offshore acco
# ZZZZZZZ.
Keep in mind that if you do not transfer this money by tomorrow at
PM, it is quite likely that nasty computer attackers will release y
data on publicly available Web sites all over the Internet, causing
certain embarrassment for you and potential client loss! To avoid s
unfortunate circumstances, please send the payment for your securit
services immediately!
Figure 10.26. Hannibal sent an extortion note, jumping off of intermediate points.
The Clarice Commerce Web administrator received the message and did not know what to do with it. The administrator thought it was probably just some kids messing around, so he deleted the message. Unfortunately for Clarice Commerce, however, Hannibal followed through on his threat. He released information from a dozen client accounts to a public mailing list, hinting that Clarice Commerce might be having some security difficulties.
Mistake Number 9: Clarice Commerce did not have adequate security awareness activities for their employees. Without knowledge about how to handle these situations, the Web administrator did not know how to alert the security organization to mobilize the incident response team. Further compounding the problem, Clarice Commerce did not have an established computer incident response team to quickly and professionally handle this problem. As we discussed in Chapter 2 , your organization must have clear awareness training for employees, directing them in security issues ranging from avoiding untrusted programs downloaded from the Internet to reporting security incidents. Also, you should form an incident response team made up of security, technical operations, legal, human resources, and public relations personnel. This team should agree on incident response procedures to be utilized if and when an attack occurs.
After releasing the data on the public mailing list, Hannibal sent a follow-up message, this one considerably less polite:
From: Security Consultants R Us
To: Web Admin
Subject: Pay Us Or You're In Real Trouble
If you do not hire us as security consultants immediately, major
amounts of your customer data (tens of thousands of records) will b
publicly released.
To accept our offer, transfer $25,000 into our offshore account
# ZZZZZZZ, or else!
At this point, the Web administrator realized he was in over his head. He forwarded the message to the chief financial officer of Clarice Commerce. She, in turn, contacted law enforcement to begin an investigation.
Mistake Number 10: The hesitation on the part of the Clarice Commerce Web administrator delayed contacting law enforcement. When evidence of a crime is discovered, your incident response team should consult with legal counsel and contact law enforcement early in the process. Your legal team and law enforcement can provide excellent advice on how to minimize the damage and maximize your ability to achieve justice.
As it turned out, a large law enforcement agency was already onto Hannibal's trail. In addition to Clarice Commerce, Hannibal had tried to bilk millions out of other sites hit by his worm. By coordinating information from the Clarice Commerce system with other victims, law enforcement officials were able to track Hannibal down before he released any more information from Clarice Commerce. After a detailed and protracted international investigation, law enforcement officials were able to build a case and bring Hannibal to justice. Although Clarice Commerce did avoid having all of its customer records exposed publicly, the small number of records released by Hannibal did
damage the company's reputation. After getting this wake-up call, senior management at Clarice Commerce established a security team to learn from their mistakes and implement corrective controls to avoid similar events in the future.
In this chapter, we've seen how bad guys can exploit a series of typical mistakes to completely undermine a target's computer systems using various forms of malware. It's important to note that each of these mistakes is commonplace in computer systems around the world today. However, all is not lost. By carefully applying the lessons learned in this chapter, together with the recommendations we've covered throughout the book, we can mount a credible defense against these types of attacks.
Also, if you enjoy scenarios like these, please feel free to look at my Web site, www.counterhack.net . Each month, I write a new scenario that highlights a particular type of computer attack and defense and make it freely available on my Web site. All of my scenarios are based on real-world computer incidents I've handled myself or heard about from a colleague. As of this writing, I have more than 12 different scenarios to tickle your fancy, and, I hope, help us all improve the state of our defenses against malware and other types of computer attacks.
Summary
Observing the mistakes of others is a low-pain, high-gain way to learn about information security. In this chapter, we explored three different scenarios involving malware attacks against various-sized networks. In each scenario, a series of common errors led to complete compromise of a target network.
In Scenario 1, the victim was surfing the Internet from a critical infrastructure system. Compounding the problem, the victim hadn't recently patched the Web browser on the machine and was even surfing the Internet while logged in as an administrator for the machine. Together, these three problems (surfing from a critical system, using an unpatched browser, and logging in as administrator) allowed an attacker to send malicious mobile code in the form of a script to the victim machine.
This script wrote a malicious file called Notepad.com in the System32 directory of the victim machine. The user inadvertently executed this file by running Notepad from the Start Run dialog box, instead of typing "Notepad.exe". Because Windows runs files with a .COM suffix before a .EXE suffix, the malware installed itself on his machine, which also had out-of-date antivirus signatures. When the malware tried to spread across the network through Windows file sharing, the victim received a warning from other systems' antivirus tools. Still, virus warnings on some machines didn't cause the victim to exercise more scrutiny against his other critical system, with disastrous results.
In our second scenario, an incident handler ignored the pleas of an experienced system administrator who noticed some anomalies on a critical internal server. This company failed to patch its internal DNS servers, some of the most important machines on its entire network. Exploiting a buffer overflow on these Web servers, a worm spread the code for a kernel-mode RootKit in a file called ipconfig. Because the incident handler account on the Linux-based DNS server had "." in its path, the incident handler accidentally installed the RootKit by typing the ipconfig command instead of ifconfig.
With the malware installed, the incident handler used the netstat, lsof, and other commands located on the victim system hard drive. These commands could have been compromised, so the incident handler should have relied on statically linked binaries on a CD-ROM instead. When the internal DNS server crashed, the incident handler finally paid much closer attention to the attack. Still, while performing an analysis of an image of the impacted system, the handler did not boot from a trusted CD-ROM, thereby contaminating any
results. Only after running the chkrootkit tool did the attacker finally discover a kernel-mode RootKit on the machine. The investigation was further slowed down, however, because the incident handler did not have a full contact list for administrators of critical systems.
In our third scenario, an attacker released a worm on the Internet. The worm exploited a buffer overflow vulnerability in Internet-accessible Web servers. The victim hadn't applied a patch or hardened its systems against this type of attack. After gaining a foothold on the victim's Web server, the worm sent e-mail from the Web server back to the attacker. The firewall should have blocked outgoing e-mail from the Web server system. The attacker read this e-mail by bouncing his connections off of worm-infected sites. When he found an e-commerce-related site, the attacker communicated with a backdoor embedded in the worm using ICMP to avoid opening up a TCP or UDP port. The attacker solidified his access to the system by installing a user-mode RootKit.
The victim site did not utilize IDS or file integrity checking tools on its external systems, allowing the attacker to maintain his access without detection. The Web application housed data on the Web site itself, holding it for a period of time. Over this duration, the attacker harvested some critical data and started to scan the internal network. Through a misconfigured FTP server, the attacker broke into the internal network and installed a sniffer. He gathered critical data sent without any encryption across the internal network. On receiving an extortion notice from the attacker, the Web site administrator did not know where to forward the message, slowing down the investigation and exposing customer data in the process. Despite all of these mistakes, the bad guy was brought to justice, with coordinated effort involving law enforcement.
