NISCC IPSec Vulnerability?

Anyway, there is something more interesting to talk about. Stupid security vulnerabilities! Security is such an important topic that I believe that all coders should understand the basics. NTDEV is full of e-mails about how to correctly (or incorrectly!) apply encryption and authentication to drivers, and these issues pop up at least as often in user space too.

Now, I'll be the first to point out that Security Is Hard. Bruce Schneier is fond of saying that anyone can design a cryptosystem that cannot be broken by oneself. Really, good security design is 1/3 intelligence, 1/3 experience, and 1/3 peer review. You cannot hope to get it right without experience and peer review, no matter how smart you (think you) are.

With that in mind, I was eager to read Friday's NISCC Vulnerability Advisory IPSEC - 004033, allegedly detailing a new security threat had been found in IPSec. (And by the way, it's "IPSec", not "IPSEC", IMNSHO. Looks prettier that way.) IPSec has a little bit of a history on security problems, but they're all (to my knowledge) well addressed, and anyway, the problems were only found because of the vast number of eyeballs pointed at it. Other protocols (i.e. proprietary protocols) have nothing to brag about until the same number of eyeballs examine them. This story seemed to get a lot of press, including articles on Slashdot and elsewhere.

Well, I have analyzed this, and it is my opinion that this advisory is basically junk, mainly because it has been known about for years. Most vendors, including FreeSWAN, OpenSWAN, and StrongSwan, prevent the mis-configuration that this advisory's vulnerabilities rely on. Still, there are other reasons why this is less significant than the media would have you believe.

To recap, there are three attack vectors that all basically exploit the same mis-configuration. The mis-configuration is choosing to encrypt the data without choosing to authenticate that same data. In other words, you choose to use ESP (one of the payload protocols in IPSec), but you don't turn on any sort of hash to make sure that the encrypted message arrives intact. Now why would you care if a few bits are flipped in the ciphertext? Because it will change the plaintext. Sometimes, it'll change the plaintext dramatically. So when you decrypt the ciphertext, what you end up is NOT what the sender sent.

Some who know a thing or two about crypto might point out that any good encryption algorithm (and the ones generally in use in the IPSec world, like 3DES and AES certainly are good algorithms) will exhibit a property known as the avalanche effect. This means, roughly speaking, that any given bit flip in the ciphertext should have as close as possible to a 50/50 probability of affecting each bit in the plaintext. In other words, very tiny changes made to the ciphertext should result in major changes to the plaintext. So, with that in mind, how can this attack be practical? Wouldn't the receiving IP stack just trash such a badly-mangled datagram?

Well, there was an implicit assumption contained in that theory; namely, that the algorithm was using Electronic Codebook (ECB) mode of the cipher. ECB mode does the naive thing and just encrypts every block-sized block of data (64 bits in 3DES, 128 bits in AES) independently. The problem with that is that identical blocks of plaintext will encrypt to identical blocks of ciphertext. This reveals patterns in the plaintext, and can wind up leaking sensitive information through a statistical analysis.

Most cryptosystems use Cipher Block Chaining (CBC) mode instead, to address this issue. IPSec uses 3DES-CBC and AES-CBC. CBC mode XORs the output from an encryption operation (i.e. a 64/128-bit block) with the input of the next operation, thereby creating an encrypted chain of data. An explicit Initialization Vector (IV) is chosen for the first XOR operation. In CBC mode, the statistical properties of the plaintext that are revealed by ECB mode are hidden. However, this comes at a price: CBC is open to a relatively straightforward plaintext modification attack. Because the decrypted plaintext is based on an XOR of the previous block, that block can be manipulated to affect specific bits pretty reliably in the next block to be decrypted. As usual, Wikipedia has amazingly good pictures and details of this stuff. Wikipedia is the Best Thing Ever™.

So, this attack takes advantage of the CBC modification attack to deterministically manipulate the plaintext in a few key ways. The ways differ depending on which vulnerability we're exploiting. In every case, you have to be in the packet path. The vulnerabilities addressed in the advisory are:

• Destination Address Rewriting - using the above-mentioned technique, we modify the destination address in the IP datagram. Some computers (although very few by default) will inspect the destination address of the packet, and if it isn't one of the local host's addresses, will forward the datagram on to the real destination based on the routing table. This is just good old fashioned IP routing, and the attack takes advantage of the fact that the IPSec endpoint probably won't re-encrypt the packet unless it happens to have an SA with the target. Even if it does, the new destination will be able to read the complete plaintext. This attack only works if the host has IP routing on, which is unusual in general but more common on boxes that also terminate IPSec tunnels.
• IP Options Rewriting - The attacker tweaks the IP options fields to attempt to elicit an ICMP Parameter Problem message. The source address of the packet must also be modified so that the ICMP message won't be encrypted on return to sender. This attack takes advantage of the fact that ICMP messages include the first 8 bytes of the IP datagram that elicited the message as payload, so that the sender can attempt to correlate the ICMP error to a particular application. This exposes 8 bytes of plaintext, and doesn't require any special configuration on the target host. Remember, however, that those 8 bytes of plaintext are almost always transport layer headers - TCP's header is at least 20 bytes, and UDP's and ICMP's are 8. Because anyone can define a new IP protocol, I can't say for sure which ones are vulnerable to having their payload revealed with this attack, I can say that there aren't many.
• Protocol Field Rewriting - This attack relies on the fact that IP datagrams that are targeted to invalid IP protocol IDs elicit an ICMP Destination Unreachable (Protocol Unreachable) message that also includes 8 bytes of the original datagram. This attack works similarly to IP Options Rewriting.

These attacks would certainly work if you could manage to get into the packet path, and if the IPSec tunnel you're attacking doesn't use authentication on its packets. Getting into the packet path is difficult in general, but often possible. However, as mentioned above, most vendors explicitly forbid the configuration of IPSec security associations that don't include some sort of encryption. From the OpenSWAN page:

notification_t parse_ipsec_sa_body(

        [...]
        switch (esp_attrs.auth)
        {
            case AUTH_ALGORITHM_NONE:
                if (!ah_seen)
                {
                    DBG(DBG_CONTROL | DBG_CRYPT
                        , DBG_log("ESP from %s must either have AUTH or be combined with AH"
                            , ip_str(&c->spd.that.host_addr)));
                    continue;   /* try another */
                }
                break;
        [...]