It is useful here to step back and summarize which operational practices we have exploited to take over the two domain controllers:
- The firewall had a port open that was not actually used on an internal host. Using a port redirection tool, we were able to get a GUI shell through that port. For more information on how to mitigate this type of attack, turn to Chapter 7.
- Next we used the extremely common administrative practice of using high-level accounts to log on to untrusted servers. Using high-security credentials on low-security machines compromises high-security machines. This practice, known as an administrative dependency, is discussed in detail in Chapter 8.
- After we took over the data center DC, it was a simple task to dump out the password hashes and crack those. Although password hashes theoretically do not represent a vulnerability in and of themselves -- the vulnerability is allowing untrusted users access to them -- several users had passwords that were easy to crack. For more information on why, and how to avoid it, refer to Chapter 11.
- We then found a flawed network segmentation that allowed us unrestricted access from the DMZ DC to the corporate network. This allows us to exploit any dependencies between systems in the DMZ and those on the corporate network. Information on how to design a proper logical segmentation is available in Chapter 9.
- Finally, we used another form of administrative dependencies by exploiting the fact that at least one user had administrative accounts on both the DMZ network and the corporate network; and used the same password for both accounts. More information on these kinds of administrative dependencies and how to detect them is available in Chapter 8.
How to get an attacker out of your network
After the network has been compromised, as the system administrator you now have a couple of options for how to deal with the compromise:
- Update your resumé
- Hope the hacker does a good job running the network (say, better than you did?)
- Drain the network
Cleaning out the attacker is not a viable option. There are probably Trojans all over the network by now, new accounts in strategic places, back doors, and all manner of other attacker tradecraft to ensure that all the attacker's hard work is not wasted. Cleaning attackers out of a network works on the same principle as cleaning undesirable liquids out of a pool. No amount of drain cleaner or chlorine poured into the pool is going to accomplish that job. Consider the following common practices when cleaning a hacked system:
- You cannot clean a compromised system by patching it. Patching only removes the vulnerability. After the attacker got into your system, he probably ensured there were several other ways to get back in.
- You cannot clean a compromised system by removing the back doors. Attackers will put back doors into any system they need in the future, and the better the attacker, the stealthier the back door. Although you may be able to find these back doors if you can load the current state of the system onto a known good host and compare it to known pre-attack snapshot, you can never guarantee that you found all the back doors the attacker put in. The fact that you cannot find any more may only mean you do not know where to look -- or that the system is so compromised that what you are seeing is not actually what is there. Looking at the system while it is running is meaningless, because the attacker will show you things that do not exist and hide those that do, to make you believe the system is clean.
- You cannot clean a compromised system by using some vulnerability remover. Suppose you had a system hit by Blaster. A number of vendors published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? We would not. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it?
- You cannot clean a compromised system by using a virus scanner. A fully compromised system cannot be trusted to tell you the truth. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. Note that if you can guarantee that the only thing that compromised the system was a particular virus or worm, AND you know that this virus has no back doors associated with it, AND the vulnerability used by the virus was not available remotely, THEN you can use a virus scanner to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability used by the worm was available remotely without user action and you cannot guarantee that the worm was the only thing that used that vulnerability, the system may be more compromised than it appears. In addition, if the user double-clicked the e-mail attachment titled "FREEPORNHERE," which other e-mail attachments did he run? In general, give a user a choice between dancing pigs and security and you find that dancing pigs win just about every time. We would rather just flatten the system and rebuild it to be assured of a clean system.
- You cannot clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that lie to the installer. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have installed back doors in non-operating system components.
- You cannot trust any data copied from a compromised system. After an attacker gets into a system, all the data on it may be modified. Copying data off of a compromised system and putting it on a clean system will in the best-case scenario give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a Trojan or back door hidden in the data.
- You cannot trust the event logs on a compromised system. After an attacker gets full access to a system, it is simple to modify the event logs to cover his tracks. If you rely on the event logs to tell you what the attacker has done to your system, you may just be reading what he wants you to read. If you can synchronously get the logs off the system before the action the attacker is taking is completed, you may trust the logs. However, if the logs are copied asynchronously (i.e., while the action is proceeding) or after the fact, those logs may be compromised as well.
- You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs may not be trustworthy enough to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system.
- The only proper way to clean a compromised system is to flatten and rebuild. A system that has been completely compromised should be wiped clean and rebuilt from scratch. Alternatively, you could of course work on your resumé instead, but we do not want to see you doing that.
If you consider the alternatives, it seems highly worthwhile to spend some effort to keep systems from getting hacked in the first place. In the rest of this book, we look at all the things we can do to protect our networks. To see a summary of the steps used in the attack, see Appendix A, "How to Get Your Network Hacked in 10 Easy Steps."
Click for the next excerpt in this series: Summary
Click for the book excerpt series or visit Addison-Wesley to purchase the book.