Example Sins

Man-in-the-middle attacks are pretty well known, and weve seen this problem repeatedly in real-world systems that were built by starting with books and then trying to build a cryptosystem from that. Additionally, many systems built on top of SSL or TLS are susceptible to this problem.

There are even tools out there for exploiting generic instances of this kind of problem, including SSL and SSH man-in-the-middle attacks, such as dsniff.

Beyond common SSL/TLS misuse, there are instances where authenticated key exchange protocols like Kerberos are used to authenticate, but the resulting key isnt actually used for cryptography. As a result, theres no cryptographic binding between the authentication and subsequent messages (and usually, no cryptography performed on those subsequent messages at all).

Currently, there are only 15 Common Vulnerabilities and Exposures (CVE) advisories that contain the term man-in-the-middle. Yet, we have found that this problem is far more common than CVE would suggest.

Novell Netware MITM Attack

Heres an example of building your own protocol from parts and getting it wrong. In February of 2001, BindView discovered a man-in-the-middle attack on Novells Netware where they were improperly authenticating a home-made key exchange/authentication protocol. Their home-made protocol used an RSA-based scheme for key exchange instead of Diffie-Hellman. They attempted to authenticate by using a password-based protocol, but did not properly authenticate the key exchange messages themselves . The password protocol was encrypted with the RSA keys, but the password wasnt used to validate that the keys were owned by the right parties. An attacker could spoof the server, in which case the client would public-key encrypt a password validator to the attacker. Then, the attacker could replay that validator to the server, which would succeed, allowing the attacker to be a man in the middle.

CAN-2004-0155

Plenty of systems that use high-level protocols such as SSL fall prey to these problems. There have even been spectacular failures in the actual core implementations for major security software. CVE entry CAN-2004-0155 is a great example of this.

The Kame IKE (Internet Key Exchange) Daemon is part of an implementation of the IPSec protocol, the popular standard for VPNs. The KAME IPSec implementation is the default in several OS distributions. On connection, authentication occurs generally using either preshared keys or X.509 certificates with RSA-based digital signatures. When using X.509 certificates, the Daemon would validate the fields within the certificate, but would not properly check the validity of the RSA signature.

The developers clearly thought that a function they were calling returned a success indicator, based on whether the signature was valid, but in reality, the function did nothing of the sort , and always returned success. Thus, the signature check always succeeded. And, as a result, anyone could create a bogus X.509 certificate with the right data fields, sign it, and authenticate.

This isnt a problem with IPSec per se. Its a problem in one implementation of the protocol. It shows that even implementing well-defined protocols can be hard. The same kinds of problems have affected Microsofts CryptoAPI (CAN-2002-0862) and Ciscos VPN software (CAN-2002-1106).



19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them
Writing Secure Code
ISBN: 71626751
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net