Hacking Through IDSs

In order to help you plan your security strategy, this section will show you how hackers exploit vulnerabilities in IDSs.

Fragmentation

Fragmentation , or packet splitting, is the most common attack against IDSs. By splitting packets into smaller pieces, hackers can often fool the IDS. A stateful IDS can reassemble fragmented packets for analysis, but as throughput increases , this consumes more resources and becomes less accurate.

Spoofing

In addition to fragmenting data, it is also possible to spoof the TCP sequence number that the IDS sees. For example, by sending a post-connection SYN packet with a forged sequence number, the IDS will be desynchronized from the host. That is because the host will drop the unexpected and inappropriate SYN, whereas the IDS might reset itself to the new sequence number. Thus, the IDS will ignore the true data stream, because it is waiting for a new sequence number that does not exist. Sending a RST packet with a forged address that corresponds to the forged SYN can also close this new connection to the IDS.

HTTP Mutation

Whisker (available from http://www.wiretrip.net) is a software tool designed to hack Web servers by sneaking carefully deformed HTTP requests past the IDS. For example, a typical cgi-bin request has the following standard HTTP format:

GET /cgi-bin/script.cgi HTTP/1.0

Obfuscated HTTP requests can often fool IDSs that parse Web traffic. For example, if an IDS scans for the classic phf exploit

/cgi-bin/phf

then you can often fool it by adding extra data to your request. For example, you can issue this request:

GET /cgi-bin/subdirectory/../script.cgi HTTP/1.0

In this case, you request a subdirectory, and then use the /../ to move back up to the parent directory and execute the target script. This sneaking in the back door is referred to as directory traversal , and is one of the most well-known exploits of all time.

Whisker automates a variety of such anti-IDS attacks. Because of this, Whisker is known as an Anti-IDS (AIDS) . Whisker has split into two projects: whisker (the scanner), and libwhisker (Perl module used by whisker) and has been updated regularly.

The Future of IDSs

As shown here, the field of intrusion detection is still in its infancy. In addition, as hackers evolve , IDSs must attempt to keep pace. Table 14.1 lists future trends that pose threats to IDSs, and potential solutions.

Table 14.1. Potential Solutions to Future Difficulties in IDSs

Problem	Solution
Encrypted traffic (IPsec)	Embed IDS throughout host stack
Increasing speed and complexity of attacks	Strict anomaly detection
Switched networks	Monitor each host individually
Increasing burden of data to interpret	Geometric display of data

The following sections will examine each of these growing problems, along with a potential solution.

Embedded IDSs

IPsec is becoming a popular standard for securing data over a network. IPsec is a set of security standards designed by the Internet Engineering Task Force (IETF) to provide end-to-end protection of private data. Implementing this standard enables an enterprise to transport data across an untrustworthy network such as the Internet while preventing hackers from corrupting, stealing, or spoofing private communication.

By securing packets at the network layer, IPsec provides application-transparent encryption services for IP network traffic, as well as other access protections for secure networking. For example, IPsec can provide for end-to-end security from client-to-server, server-to-server, and client-to-client configurations.

Unfortunately for IDSs, IPsec becomes a dual-edged sword. On the one hand, IPsec enables users to securely log into their corporate network from home using a VPN. On the other hand, IPsec encrypts traffic, thus rendering promiscuous-mode IDSs useless. Therefore, if a hacker compromises a remote user 's machine, he will have a secure tunnel through which to hack the corporate network!

To account for IPsec, future IDSs will need to be embedded throughout each level of a host's TCP/IP stack. This will enable the IDS to watch data as it is unencapsulated and processed through each layer of the stack, and to analyze the decrypted payload at higher levels.

Strict Anomaly Detection

Another growing problem is that as both the speed and complexity of attacks continue to increase, IDSs are struggling to keep pace. One answer to this dilemma might be the growing use of strict anomaly detection . This means that every abnormality, no matter how minor, is considered a true positive alarm.

Again, such a method would require that the IDS move onto individual hosts , rather than the network as a whole. An individual host should have a more predictable traffic pattern as opposed to the entire network. Each critical host would have an IDS that detects every anomaly. Then the administrator can make rules (exceptions) for acceptable variations in behavior. In this way, IDSs monitor behavior in much the same way that firewalls monitor traffic.

How would you design an IDS that performs host-based, strict anomaly detection? In this case, you're dealing with individual hosts that are somewhat isolated by firewalls and routers, so you can customize your IDS for each unique host. Because you're dealing with only the host, you know that any packets received are destined for that specific host. You can then set your sensitivity very high to look for any abnormality.

For example, at the packet level, the host-based anomaly detector would scan packets as they are processed up the stack. You could ask the IDS to monitor any of the following:

Unexpected signatures
TCP/IP violations
Packets of unusual size
Low TTL
Invalid checksums

Similarly, at the application level, you can ask the anomaly detector to scan for unusual fluctuations in the following system characteristics:

CPU utilization
Disk activity
User logins
File activity
Number of running services
Number of running applications
Number of open ports
Log file size

When any abnormality is detected , an alert will be sent to the centralized console. This method has high sensitivity, but unfortunately generates a great deal of data. This problem is dealt with in the next section.

Host Versus Network-Based IDS

The increasing use of switched networks hinders IDSs that monitor the network using promiscuous-mode passive protocol analysis. It is therefore becoming more difficult to monitor multiple hosts simultaneously . There have been attempts to rectify this by using spanning (spy) ports to monitor multiple ports on a switch, but to date such solutions have been ineffective . In addition, the growing use of encrypted traffic foils passive analysis off the wire. Thus, IDSs are moving more towards host-based monitoring.

Geometric Display of Data

As bandwidth and attack complexity increases , it is becoming more difficult to generate meaningful alerts. The amount of alert data generated by IDSs can quickly overwhelm human operators. Unfortunately, excessive filtering of data for human use can severely limit its effectiveness.

One solution to this problem is the geometric display of data. Humans understand geometric shapes intuitively, so this is often the easiest way to present massive amounts of data. When an operator senses an anomaly in the graphical display, she can later drill down manually to investigate the problem.