Understanding Downgrade MITM Attacks

A downgrade MITM attack allows an attacker to force the client and/or server to use a less secure protocol or set of functionality that is supported for legacy client/server compatibility. Sometimes clients support connecting to servers that contain different features or different versions of a feature. Clients and servers often negotiate which features and feature versions should be used. For example, many Secure Shell (SSH) clients support both versions 1 and 2 of the SSH protocol and several different encryption ciphers. (SSH is an encrypted network protocol for connecting to machines to provide command-line access.) Version 1 contains protocol flaws that can allow an attacker to see the normally encrypted data exchanged between the client and server. This flaw is described in detail at http://www1.corest.com/common/showdoc.php?idx=82&idxseccion=10 . For this reason, most people use SSH version 2. However, for backward-compatibility reasons, many servers and clients still support version 1. Using an MITM attack, an attacker can tell the server and client to use the vulnerable SSH version 1 protocol before encryption begins. To prevent this attack, most SSH clients and servers can be configured to use only version 2 of the protocol. An easy way to test that the client honors this restriction is to proxy the network traffic and tell the client to use an older version.

Several clients have issues around downgrade attacks. In July 2003, Marco Valleri and Alberto Ornaghi presented information on several protocols that have downgrade problems, including SSH, Internet Protocol Security (IPSec), and Point-to-Point Tunneling Protocol (PPTP). Their presentation can be found on the Black Hat Web site ( http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-ornaghi-valleri.pdf ).

Important  

Some Web logon forms are displayed using HTTP and are submitted securely over Secure HTTP (HTTPS). This is dangerous! Similar to downgrade attacks, if attackers are able to hijack the HTTP response, they can specify the place to which the logon information will be submitted, such as to their server. To prevent this, it is recommended that the server use SSL to send forms requesting sensitive information and receive sensitive form data.