Thinking about side channel attacks
When Cyrus wanted to capture Babylon, he attacked the river that flows through the city, drying it out and then sending his army under the walls through the river entrance and exit points. In a similar way, the ventilator is a movie favorite, used in both Lord of the Rings and Star Wars, probably along with a thousand other movies and stories throughout time. What do rivers and ventilators have to do with network security?
Side channel attacks. Now I don’t know if the attacks described in these papers, or Cyrus’ attack through the Euphrates, are considered side channel, or just lateral, but either way: the most vulnerable point in your network is just where you assume you can’t be attacked, or that point where you haven’t thought through security. Two things I read this week reminded me of the importance of system level thinking when it comes to security.
The first explores the Network Time Protocol (NTP), beginning with the general security of the protocol. Security in a time protocol is particularly difficult, as the entire point of encryption is to use algorithms that take a lot of time for an attacker to calculate—and there’s probably some relationship between solving the equation as an attacker and solving the equation as a receiver. While you have the key in one case, and you don’t in the other, the harder the algorithm is to solve for an attacker, the harder it’s likely to be for the receiver. The time lag of advanced encryption probably makes it more difficult to accurately distribute time across a set of widely distributed devices. So somehow encrypting NTP seems problematic in terms of it’s primary purpose.
But what if we leave NTP exposed? According to this paper, a number of attacks become feasible once you’ve altered the time. For instance, TLS certificates (used to secure most of the ‘web and email traffic in the world) are vulnerable to NTP attacks. DNSSEC uses time based keys to authenticate DNS records, caching system often use global timers to ensure the consistency of caches stored in different places, various authentication systems use time to determine how long someone should remain logged in and when they should change their password… Even the RPKI is grounded in timers. Time, then, is an excellent side channel (or ventilator, if you like) to use to find a way through systems otherwise hardened against attack.
The second is RFC7739, Security Implications of Predictable Fragment Identification Values. In this case, the attack is against fragment identifiers in IPv6. By attacking the fragment space, it’s apparently possible to cause sessions between two devices to fail consistently (denial of service), to monitor telemetry information, or to inject information into a flow from some point in the middle. There are ways to prevent this sort of attack, of course (see the RFC), but nonetheless, it’s instructive that here, under the covers of a protocol (or an abstraction, if you like), there is a set of operations that very engineers would think to check on.
So, what’s the point?
The point is this: networks are systems made up of individual components pulled together through interaction surfaces. While abstraction is a useful tool to focus on solving a single problem at a single point in time, it’s also important to step back and take a systematic view of the network as a system, paying particular attention to ventilators, in order to really assess security and threat levels.
Don’t wait until an Orc destroys your wall with a well placed explosive charge, or an X wing fighter drops a torpedo down an unprotected shaft.