NISCC IPSec Vulnerability?

OK, I know I promised that the next article would be about a non-existant DDI,
but work has been so busy lately that I’ve been unable to cobble together the
little demo program I had in mind at the time. One day soon, I promise.

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;
        [...]

So, to summarize, these attacks are real, they have been known about for a
while, and it is a well-understood best practice to never configure encryption
without also having a way to authenticate the encrypted data. Every major
encryption protocol I know of does this, or at least enables it.

2 Replies to “NISCC IPSec Vulnerability?”

  1. Great summary! Of course this "vulnerability" does not come as a great surprise. Every cryptography textbook warns against it!

Leave a Reply

Your email address will not be published. Required fields are marked *