| I l@ve RuBoard | |
We organize our penetration-testing efforts around a goal of compromising the network without detection. It is important to examine the effectiveness of the IDS and the responsiveness of those monitoring it in order to assess the overall security posture of a network.
Hopefully the target of the test detects the attack and logs the relevant actions. In such a case, even if a hacker does deface a Web site, his or her actions and source IP address may be recorded, the original Web site can more quickly be restored, and the option for prosecuting the hacker remains. It should be noted that successful prosecution of hacker activity can be very difficult, especially if the intruder has sanitized or deleted the relevant log files or the administrator took inappropriate action when assessing the attack and inadvertently destroyed critical evidence.
To circumvent an IDS you need to find holes in its rules, signatures, and/or thresholds. Though it is unlikely to have complete information on the rule set of an existing IDS, many hackers and security consultants do have an understanding of the common IDS rule set, including typical threshold values. They develop their penetration strategy around bypassing the common IDS configuration.
While several IDS vendors are moving to offer integrated network and host-based IDS solutions, network-based IDSs are more common than host-based ones. The techniques we mention are generally geared toward avoiding detection by a network-based IDS; however, they do apply to both.
Here are five points to keep in mind as you attempt to avoid detection by an IDS.
Be patient. As mentioned above, there is a collection of events that trigger an alert only if they occur multiple times over a certain, relatively small, time period. Many times these thresholds are set high to minimize a false positive rate, and you can use that to your advantage. By keeping a slow pace of activity on your port scans, brute force attempts, and other attacks, you may avoid raising a red flag.
If we are manually attempting to access a login account, we generally make two password guessing attempts at a time on the same account, then move to another user account if unsuccessful. After a sufficient time period, we can return to make two additional attempts on each user account. Since we are making limited password attempts, we cannot use brute force techniques and must instead rely on intelligent guessing by using common default passwords, such as “test,” “password,” and “p@ssw0rd.”
Similarly, SNMP queries can go undetected if we space them out over time. By spacing these queries by a few minutes we may exceed the typical time limit for an IDS detection window.
Be quiet. Limited traffic against a target network from an outside (and unknown) source may get by the sensors of an IDS. It is likely that a high volume of traffic of any kind from an unknown source will generate an alert on a network that does not expect such traffic.
Go manual. When attempting to avoid detection, we do not run commercial vulnerability scanners, which fairly quickly run through a large collection of tests and exploits—such scanners are noisy. Vulnerability scanners are designed to find security holes, not to avoid detection. If an IDS cannot detect a vulnerability scanner, it is probably misconfigured and can't detect much of anything else either. Commercial scanners certainly have their place in the security consultant's tool kit. But they should not be used when you are trying to avoid detection. An IDS cannot be evaded using these tools.
In place of such tools, we do things manually as much as possible. This goes hand in hand with both of the above suggestions. Manually trying just a few telnet passwords at a time forces us to be patient and allows us to minimize the noise we make. If we stick to one or two login attempts per user name over a five-minute interval, we may avoid setting off an IDS.
Use untraceable and/or multiple IP addresses. If at all possible, try to use an IP address that is not tied directly to you. We have seen hackers use spoofed IP addresses. With a fake IP address, even if your activities generate a long list of alerts, if the target is not able to trace the activity back to you, they will be less able to respond effectively. In addition, by using multiple phony IP addresses as decoys, you may be able to confuse the target and IDS into thinking the attack is a false positive alert.
Unfortunately, we are not always able to use fake IP addresses during our penetration-testing engagements. We generally have to inform our clients where our activity will be coming from so that they will recognize that such activity is not an actual hacking attempt. Also, the organization may track the phony IP address to a legitimate company and accuse it of trying to attack their network. This could lead to confusion and legal problems. Therefore, if you do spoof an address, choose the address carefully. Finally, address spoofing mainly works for attacks that do not require a response. If a response is required, you must use redirection either at the target router or at the spoofed IP address.
Use IP fragmentation. IP fragmentation can make it more difficult for IDSs to flag potentially dangerous traffic since the signatures are broken up into multiple packets. While several IDSs do have flags that indicate traffic has been broken into multiple packets, selecting these flags can generally lead to a great deal of false positives. Web traffic, for instance, is often broken up into multiple packets.
IP fragmentation can be done through various tools, such as Nmap, which can fragment its scans, as well as Fragrouter (a tool developed by Anzen Computing, which has been purchased by NFR). Fragrouter is a software tool that acts as a router and can fragment all outbound traffic.
Depending on the activity, these guidelines may not always be easy to follow. Furthermore, the time factor associated with penetration-testing engagements may not allow you to be patient. This is especially true with activities such as brute force login access attempts, which simply run through a large number of potential passwords in a short amount of time.
A caveat: If the target is running an IDS on a fast processor in promiscuous mode and if it is configured correctly, it will probably catch everything you do, including Nmap FIN scans. In such cases, we use decoy addresses as much as we can and try to redirect or bounce our attacks off other hosts if possible. In most cases, we just proceed with our testing. We try to identify a vulnerability as quickly as possible, exploit it, capture the flag files (if that is the goal), and get out. Often an IDS catches something, sets off its on-screen red alert, sends a page, and so on, and still the administrator takes no action. The unpreparedness of security administrators is not something we like to count on, but it happens more often than one would guess and does in fact contribute to many of the compromises and intrusions that occur today.
The guidelines described above also pertain to port scanning. SYN, FIN, null, and XMAS scans offer more obscurity than general port scanning, however, as a tradeoff, the more obscurity they provide, the more time consuming and less accurate they may be. A SYN scan seems to best balance obscurity and effectiveness in port scanning.
Nmap performs all of these types of scans and offers several additional options to help you go undetected. (Nmap is discussed in detail in Chapter 13.) Here we highlight features that can aid in performing port scans undetected. For example, you can use the timing capabilities(with the -T option) to set the interval between successive packets sent out. This allows you to probe fewer ports in a given monitoring window. The computer industry is always trying to make things go faster. If you just slow down your testing activities, you reduce your risk of being detected.
In addition, using the -P0 option with Nmap generally reduces the amount of noise generated since it will not ping hosts before conducting the port scan. Ping packets are often detected by an IDS; avoiding them will help keep your activity unnoticed. Be aware that this will cause you to port scan every host in your host list, even those that are not live or responsive to pings, causing the scan to take more time.
You can counter this by scanning only a few machines and ports at a time. Avoid running a port scan on all 65535 ports at once. There is nothing wrong with scanning all ports if you feel there may be a higher-numbered port open. In fact, toward the end of the test, we recommend scanning all ports to find any you may have missed. However, in order to help remain undetected, port scans should be done more surgically, a few at a time. We scan no more than 100 ports per host when we are attempting to avoid detection, and we recommend scanning ports in a random order (with the -r option).
Nmap's decoy capabilities allow you to use fake IP addresses, which can help to distribute any attention given to the scanning to a collection of IP addresses rather than just your own. It may also confuse security administrators into thinking they are experiencing the preliminary stages of a distributed denial-of-service attack. As for the IP addresses to select as decoys, remember to use only addresses for which you have permission. Using random IP addresses as decoys can lead to some potentially embarrassing and confusing incidents.
We have seen hackers successfully take this decoy option a step further by using IP addresses that could be legitimate sources of port scans that the system administrator will have to investigate. When doing this, hackers do not spoof source addresses such as whitehouse.com or yahoo.com. These Web addresses are not likely to be involved in scanning a target host. Therefore, a security administrator would be able to eliminate them, reducing the effectiveness of the decoy. It is more effective to use IP addresses that ISPs own and dynamically assign to their dial-up customers. Dial-up customers are a potential source of Nmap port scans. Be aware that ISPs record the IP addresses they assigns to users. The ISP and its customers will likely not get in any trouble because they did not do the port scan, but it can cause them a lot of grief along with time and money spent in proving their innocence. As professional security consultants, we do not resort to this step since it may inconvenience others, but it is something that we have seen hackers do.
To further augment the effectiveness of Nmap's stealth capabilities, Nmap scans can be fragmented with the -f option. Using this approach makes the scans take a great deal of time, so you must carefully weigh the added benefit against the significantly increased time requirements. We do employ this approach for at least a portion of our scanning to gauge the target's ability to detect port scans.
Using this same approach, you can also perform SNMP queries slowly so as to avoid detection. Since SNMP is often used to perform network management, SNMP_GET queries do not always trigger alerts. Therefore a few SNMP_GET commands at a time can fly under an IDS's radar. Of course, you should make sure SNMP is running before making any queries.
There are techniques we do not like to perform during our tests, but since we have seen them used in the real world, they are worth mentioning.
If you take down the host machine of the IDS sensor with a denial-of-service or buffer overflow attack, the IDS will not be able to identify what you are doing. However, this doesn't mean you are in the free and clear. While that sensor may not be able to detect future commands or exploits you run, many IDSs register a “Down Sensor” red alert for being unable to communicate with the victim sensor. Though this is not the same as the IDS identifying you by your host IP address, it should draw the attention of the security administrators, and they may investigate the situation while rebooting the machine. Denial of service against an IDS sensor is a risk, but there are ways to defend against it. System administrators can configure IDS sensors to be in stealth mode to avoid detection. In other words, the sensor can be placed in promiscuous mode and be managed out of band on a separate network interface card (NIC). The IDS may also be resistant to denial-of-service attacks to help ensure this type of attack would not be successful.
If you are not able to knock out the IDS sensor entirely, you can use the sensor itself to overload the system administrator who may be monitoring the system. This can be done by simply launching several (fake) attacks at the sensor, causing it to send a high number of alerts to the management console. The system administrators may then take these alerts to be false positives, given their unusually high number, and then disregard further alerts from the sensor.
Another aggressive technique to cover your tracks is to hack onto the machine where IDS logs are being stored and corrupt or delete the logs. Without the logs, there may be no record of an intrusion. This, however, poses its own difficulties. The logs are likely to be protected or stored on an out-of-band server. The permissions settings on log files may not allow any operations from users on remote hosts. The logs may be written to a machine not reachable over the Internet. This is another reason for out-of-band management and for storage of IDS logs on a separate server to guard against this scenario.
| I l@ve RuBoard | |