Writing Secure Code

Most programmers think that once data gets dropped on the network, it will be very hard for an attacker to do anything nefarious to it, besides maybe read it. Often, the developer doesnt worry about network-level confidentiality because it hasnt been an explicit requirement from customers. But, there are tools out there that can redirect traffic and even give the attacker the ability to manipulate the data stream.

The mental model most people have is that data gets sent upstream too quickly for an attacker to get in the middle, then it goes from router to router where it is safe. Those programmers who have switches on their networks often feel more confident that there wont be an issue.

In the real world, if attackers have a foothold on the local LAN for either side of a communication, they can have a good shot of launching a network-based attack, taking advantage of the lack of security in the underlying infrastructure. If the attackers are on the same shared network segment as one of the endpoints (for example, attached to a hub), they see all traffic on that segment, and can usually arrange to intercept it all. Even if the attackers are plugged into a switch (a hub where the individual ports dont see each others traffic), theres a technique called Address Resolution Protocol (ARP) spoofing, where attackers pretend to be the gateway and redirect all traffic to themselves . They can then send out the traffic after processing it. There are several other techniques that work, too. For example, some switches can be ARP-flooded into promiscuous mode where they basically end up acting like hubs.

How does this work? ARP is a protocol for mapping layer 2 (Ethernet MAC) addresses to layer 3 (IP) addresses. Attackers simply advertise their MAC addresses as ones bound to the gateway IP. Once machines see the change, they will start routing all their IP traffic through an attacker. This problem doesnt have a practical and universal short- term fix, because there need to be fundamental services at the Ethernet level that are only now starting to be discussed within standard bodies. Oh, and these problems all get worse on most wireless networks.

Even at the router level, its probably not safe to assume that there are no attack vectors. Popular routers tend to be large, complex C programs, and they can be susceptible to buffer overflows and other issues that would allow an attacker to run arbitrary code on a router. Until router vendors implement technologies to make such catastrophic consequences more or less impossible , this will continue to be a risk. And, indeed, there have been buffer overflows in routers before. See, for example, from the Common Vulnerabilities and Exposures (CVE) dictionary (at http://cve.mitre.org): CVE-2002-0813, CVE- 2003-0100, and CAN-2003-0647.

Network attacks can take a wide variety of forms:

• Eavesdropping The attacker listens in to the conversation and records any valuable information, such as login names and passwords. Even if the password isnt in a human-readable form (and often, it is), its almost always possible to take eavesdropped data and run a brute-force dictionary attack to recover the password. And, sometimes, the password can be recovered directly, as it is only obfuscated .

• Replay The attacker takes existing data from a data stream and replays it. This can be an entire data stream, or just part of one. For example, one might replay authentication information in order to log in as someone else, and then begin a new conversation.

• Spoofing The attacker mimics data as if it came from one of the two parties, but really the data is bogus . This generally involves starting a new connection, potentially using replayed authentication information. This kind of attack can, in some cases, be launched against network connections that are already established, particularly virtual connections running over a connectionless transport (usually, User Datagram Protocol, or UDP). It can be very tough (but not impossible) to do with connection-based protocols on operating systems that properly randomize Transmission Control Protocol (TCP) sequence numbers .

• Tampering The attacker modifies data on the wire, perhaps doing something as innocuous as changing a 1 bit to a 0 bit. In TCP-based protocols, its a bit more complicated than this because of cyclic redundancy checks (CRCs), but since CRCs are not cryptographically secure, they are easy enough to circumvent when there are a few bits to play with that dont have a significant impact on the way the data is processed .

• Hijacking The attacker waits for an established connection, and then cuts out one of the parties, spoofing the partys data for the rest of the conversation. Its pretty difficult to inject/spoof new traffic in the middle of a conversation these days (at least, when using TCP and the operating systems of the endpoints are up-to-date), but its still not impossible.

If youre worried about the security of your network connections, you should know what kinds of services its reasonable to expect applications to provide. Well talk about those basic services here, then talk about how to achieve those goals in the Redemption Steps section. Anyway, in order to protect against these kinds of attacks, you will generally want to provide three basic security services:

• Initial Authentication You want to ensure that the two endpoints mutually agree on who theyre talking to. There are lots of ways to do this, but passwords are the most common, because theyre the most usable solution. In this sin, we will skip over authentication issues, but we address them to some degree in Sins 10, 11, and 17.

• Ongoing Authentication Once you know who youve connected to, you want to make sure youre still talking to the same person throughout the conversation. This is a stricter version of message integrity. Its okay to check to ensure the message arrived as sent, but you do want to differentiate when an attacker sent the message and when the legitimate sender did. For example, TCP provides weak message integrity checking, but not ongoing authentication.

• Confidentiality This is probably the least important security service. There are plenty of cases where you still want to ensure that all the data is authentic and its okay to go without encryption. But, it usually makes no sense to have confidentiality without both initial and ongoing authentication. For example, when an attacker uses a stream cipher mode such as RC4 (this includes the popular modes of operation for block ciphers, as well), the attacker can flip random bits in ciphertext , and without proper message authentication, one would generally never know. If attackers know the data format, they can do even more cruel things by flipping specific bits.