Essential Insecurities Part 6 — Conclusion

When you add functionality, you add vulnerability. This is true whether your network powers a small business, or a Fortune 500 company. This is true whether you are looking at a single Lan, or a world-wide Wan. Every piece you add brings with it risk.

We use controls to mitigate risk. Mainly these are directive, preventative, and detective controls. Directive or policy controls define appropriate use of the system. Sometimes people will follow these policies, sometimes they will not. Of course, technology allows us to set permissions and therefore implement preventative controls to keep people from doing certain things. For the times when people do not follow policy and the system does not (or cannot) stop them, detective controls are there to leave an audit trail.

When we add functionality, we need to consider these controls. Now let us work our way from cables to computers.

When deploying a network switch and cabling, ask, how could this break? What can we do to protect it? Consider fault-tolerant designs such as full-mesh for connecting multiple switches and cabling with Fibre instead of copper. Consider directive controls to specify who can access the switch and how. Consider preventative controls such as locked rooms and climate controls. Consider detective controls such as check-in forms and electronic monitoring.

What are Ethernet’s risks and what controls are available? Directive controls could include specifying how a computer gets connected to the Ethernet Lan. It could also specify who is allowed to run sniffers. The preventative controls would be locking down the switch ports to specific Mac addresses, thereby making it difficult to connect a computer without first following procedure. Consider enabling the switch manufacturer’s protection against ARP cache poisoning, such as Cisco’s Dynamic ARP Inspection. Detective controls enabling the switch’s audit logs, and regularly scanning for network cards in promiscuous mode with tools like Sentinel.

What about IP’s risks and controls? Design IP networks to address concerns about addressing and fragmentation. Use directive controls to specify who can access what IP and Internet resources, and who is responsible for addressing and naming. Preventative controls include securing Dhcp address servers and Wins/Dns name servers. Detective controls include auditing and logging. Monitor for IP address and name conflicts, and excessive traffic to Wins/Dns.

Good design along with proper controls will protect integrity and availability. All along, we have been assuming that there is no confidentiality. We have suggested that the place for this is in applications (application, presentation, session, transport layers). Ask your vendors for recommendations on how to securely run their applications. First build a solid network infrastructure, and then turn your attention towards securely delivering applications over it.

The Internet Protocol or IP is what makes the World Wide Web go around. IP packet is divided up into the header and the data.

The IP header has fields such as the source and destination IP address, and fragment offset. What can go wrong here? We’ll use the typical Alice and Bob for two people on a network.

Take the example of Alice’s computer talking to Bob’s. Alice’s will use a name service to look up the IP address, like DNS or WINS. If all is well, then this name service sends back an IP address. Alice’s computer builds a packet with this address as the destination. But can you trust the name service? No, of course not. An attacker can poison these services with incorrect information. Alice’s packet could be sent to the attacker’s machine.

But let us suppose that we are using only IP addresses, without any names or name services. This makes more work for the Alice and Bob, of course, but remembering a few IP addresses is a small price to pay for security. Right? Ok, to prevent poisoning we skip the name lookup and instead send a packet to Bob’s computer’s IP address.

When the response arrives, Alice looks to see if it came from Bob. From the source address alone, can she be certain who sent this packet? No. Attackers can falsify or spoof their IP addresses. Now if the attacker is outside the network, he could pretend to be a computer on the inside. This might fool a router or firewall into allowing the connection. The packet with Bob’s address could really be from anyone inside or outside the network.

The fragment offset field can also be misused. The idea here is networks have a maximum size for the packets transmitting packets. When a packet exceeds this maximum transmission unit (MTU), the router fragments the packet. The offset is the number of bytes into the packet. The destination computer then uses the offset field to reassemble the packet. Just like IP addresses, an attacker can falsify the fragment offset.

Fragmentation can be used to hide data or attack availability. For instance, say you are watching the router for some bad command (like format C:). At attacker could send this in two fragments, “form” and “at C:”.  Other ways are to send fragments with offsets that overlap or send only the initial fragment without the rest of the packet. These can confuse the OS, chewing up memory and eventually make the computer unavailable.

This is significant because to spoof Bob’s computer, the attacker will first have to knock Bob off the network. An IP address has to be unique on a segment and hence only one computer can use the address at a time.

Network communication is divided up into seven layers: application, presentation, session, transport, network, data link, and physical. We will examine the primary data link protocol, Ethernet, in this entry.

Ethernet transports data between network devices. There are, as always, concerns about availability, integrity, and confidentiality. Attackers can block or disrupt the flow of Ethernet frames. Or they can quietly gather these frames, reassemble them, and glean confidential information. Ethernet passes information across a shared network media; an untrusted medium.

On a shared media, only one Ethernet device can talk at a time. Ethernet has methods to detect that some device is talking and to wait. These are CSMA/CD for wired and CSMA/CA for wireless connections. CD means detection and CA means avoidance. These can be thought of as listening for your turn versus raising your hand and asking to speak.

Both can be exploited to disrupt availability. For instance, if wired into the Lan, an attacker constantly talks. The victim patiently waits its turn to talk. When it never detects silence, the victim never sends its data. Now, imagine the attacker and victim both are on a wireless network. The victim requests to communicate with the access point. Basically, it raises its hand. The attacker then sends a response to wait. And the victim does, never transmitting. Silence is the result.

Instead of silencing the victim, however, the attacker may wish to listen in. The attacker puts his network card into promiscuous mode. Depending on one’s point of view, this might sound immoral or rather interesting. Actually, however, it simply means the attacker’s computer now receives all frames on the shared network media. The frames can then be reassembled and the confidential information gained.

On the network, assume no confidentiality. Wait, some people may say, this may be true for shared media like hubs and wireless connections. What about switched media, like network switches?

Switches were once sold partially as security devices. The rule of thumb was to never use a hub. Network hubs repeat traffic out all ports. This means that any device connected can listen in on all communications. Switches are better in that they only send traffic to the destination port. Time marches quickly in InfoSec, however, and it has been shown that switches can be subverted.

Suppose Alice’s computer talking to Bob’s. Alice asks for Bob’s computer by name. Her computer then turns the name into an IP address, and the IP address into an Ethernet MAC address. This last bit is done with ARP and the information is stored in the switch’s ARP cache. The attacker can poison this cache and trick Alice’s computer into sending Bob’s frames to the attacker’s MAC address. The attacker then can listen in to all network communications between Alice and Bob, even though they are on a switch.

ARP cache poisoning is a lot of work. An easier attack on confidentiality is to overload the switch’s firmware. Most vendors would rather degrade than fail. So instead of dropping connectivity, an overloaded switch downgrades to acting like a hub. Of course, this could break the network altogether.

If the network is down then all devices are down, of course, which brings us back full circle. The bottom line is that there are a number of ways an attacker can abuse the Ethernet protocol to disrupt the business or to gather confidential information.

There are many ways to hook up cables and computers. Bus, ring, mesh, and star topologies all have availability and integrity concerns. (Again, we are putting confidentiality aside for the moment. We will come back to it higher in the networking stack.) The best for availability is mesh, though its cost and complexity usually relegate it to the switch backbone and Wan links. Lans are usually physically a star and logically switched.

Peer-to-peer networks take less time and money to setup. Yet they are inherently insecure. The company’s information is in the hands of people who are very good at doing their job, yet likely not very good at doing the job of a systems administrator. Central control and formal policy is better, which is what domains are intended for.