Ping of Death

Not long ago a popular denial-of-service attack involved sending out an ICMP Echo Request packet also known as a ping. Most TCP/IP implementations ship with a built-in ping command, named after the sound radar makes in movies about submarines. An ICMP Echo Request packet checks to see whether the destination host is alive. When received, the target responds with an ICMP Echo Reply command. Only one message is needed to ping a system, although most versions allow for repetitive test packets. One of the ping options is to send an arbitrary text string along in the packet.

Many UNIX variants started from the same source code base, and consequently, a bug found in one version of UNIX has a better-than-average chance of appearing in other UNIX systems. The Ping of Death attack is not really a network problem but rather a buffer overflow problem. The IP stack on the receiving end of the ping did not perform adequate bounds checking on the input and would overflow if a message larger than 65,535 bytes was received. Some IP implementations choked on small packet sizes. The error-recovery procedures of the particular IP implementations by UNIX vendors varied, but most of them would hang. If the attacker was clever enough to encode the buffer just right, the receiving computer could be tricked into executing arbitrary commands.

Once again, poor programming practices lead to this weakness. By the way, you are not required to run the Ping of Death attack with an impersonated address, but would you want to launch one from your own valid IP address? You might as well crank call everyone with a Caller-ID box.

Are Your Mission-Critical Applications Safe from Attacks?

Information about Internet application weaknesses is readily found in books about firewalls. Each commonly known IP-based service is considered in turn and concerns about the protocols used are described. Based on these texts, firewall administrators get a good feel for what services to enable or deny at the firewall. What is so amazing is that few people spend the time to interrogate the protocols in use by home-grown client-server applications running in the corporate network.

The Internet applications that are critiqued in other texts have undergone years of public analysis and inspection. The same probably cannot be said for home-grown distributed applications. It is bad enough when these applications are running inside of private networks, but some people even put the client or server directly on the Internet. With some of these private protocols, the consequences of address impersonation are more serious than in the previous examples. Imagine the damage potential if your mission-critical applications are susceptible to address impersonation attacks. If you have an automated manufacturing facility, and the client-server communications depend only on IP address based authentication, a disgruntled employee or a paid saboteur can easily foul things up.

Sometimes, a weakness in the protocol between the client and server adds to the trouble. For example, you might have a private authentication protocol between the client and server, and it could even depend on cryptography for protection. Still, there could be flaws in the protocol design, which gives an edge to an attacker. Building robust client-server protocols is difficult. Designing secure authentication protocols is considerably harder. You should make an effort to review the security aspects of any client-server applications in use at your site. If any cryptographic authentication between the client and server exists, and you do not feel confident in your abilities, seek expert help in searching out weaknesses. Even very skilled programmers from prestigious companies have released commercial products with protocol problems.

Impersonating One Half of a Session

If network traffic between two nodes flows in the clear and if you know the protocol that the nodes are using, you can disable one of the nodes and impersonate that node using IP address impersonation. Disabling a node is accomplished by physical sabotage or by flooding the target node with continual network traffic (so that it is unable to respond to the other half of the connection). This hack is different from the pizza trick because this attack assumes that a series of messages must be exchanged as part of the protocol.

Even if the protocol is not publicly available in source code form, or via a formal definition such as through an RFC, a determined adversary can piece together the protocol through packet sniffing. Security through obscurity provides no long-term protection. Assuming that a private protocol is safe because no one knows how the protocol works is a poor basis for security. If the protocol depends on IP addresses sent in the clear for authentication, someone eventually can impersonate at least one half of the connection.

Session Hijacking

If you are an attacker and your node is in between two other nodes, you can hijack the session and impersonate two (or more) nodes. Even if the two nodes you are subverting have completed an initial strong authentication dialogue, it is possible to hijack the session if the remainder of their messages are sent in the clear. If the two nodes rely on cryptographic techniques for privacy, integrity, or authenticity, you will not be able to hijack the session unless you can discover the key or find a flaw in the protocol.

Session hijacking is conceptually simple. Two endpoint nodes of a communication session send traffic in the clear. Your location is such that all traffic between these two nodes must flow through a node that you control. On your node ,you sniff packets and create arbitrary IP traffic. You must handle both sides of the communication if you want to spoof both nodes into doing what you want.