git.openssl.org Git - archaic-openssl.git/log

Matt Caswell [Wed, 29 Jun 2016 09:23:28 +0000 (10:23 +0100)]

Add a POC demonstrating DTLS Finished message injection

This simulates an attack where a MITM can inject its own Finished message
into a DTLS handshake. In this POC OpenSSL is acting as the server. The peer
is assumed to be a non OpenSSL client that will tolerate very small MTUs
such that the Finished message will be fragmented (OpenSSL itself will never
do this). The attack could work equally well where OpenSSL is the client
and some other DTLS implementation is the server - although I have not
attempted to show this in the POC.

The attack described here is a "near miss" from a security point of view.
It does not appear to be exploitable in a real scenario because of the
issues described at the end below.

The MITM requires the following capabilities:
- The ability to manipulate the MTU that the client selects such that it is
  small enough for the client to fragment Finished messages. I have
  simulated this in the POC by making a hack in the previous commit to
  OpenSSL itself. This would not be required if we were using a real third
  party DTLS implementation that tolerated very small MTUs.
- The ability to selectively drop and modify records sent from the client
- The ability to inject its own records and send them to the server

The MITM forces the client to select a small MTU such that the client will
fragment the Finished message. Ideally for the attacker the first fragment
will contain all but the last byte of the Finished message, with the second
fragment containing the final byte.

During the handshake and prior to the client sending the CCS the MITM
injects a plaintext Finished message fragment to the server containing all
but the final byte of the Finished message. The message sequence number
should be the one expected to be used for the real Finished message.

OpenSSL will recognise that the received fragment is for the future and will
buffer it for later use.

After the client sends the CCS it then sends its own Finished message in
two fragments. The MITM causes the first of these fragments to be dropped.
OpenSSL will then receive the second of the fragments and reassemble the
complete Finished message consisting of the MITM fragment and the final byte
from the real client.

The advantage to the attacker in injecting a Finished message is that this
provides the capability to modify other handshake messages (e.g. the
ClientHello) undetected. A difficulty for the attacker is knowing in advance
what impact any of those changes might have on the final byte of the
handshake hash that is going to be sent in the "real" Finished message. In
the worst case for the attacker this means that only 1 in 256 of such
injection attempts will succeeed.

In practice the MITM would need to be able to perform the same attack
against both the client and the server. If the attack is only performed
against the server (say) then the server will not detect the modified
handshake, but the client will and will abort the connection. Fortunately,
although OpenSSL is vulnerable to Finished message injection, it is not
vulnerable if *both* client and server are OpenSSL. The reason is that
OpenSSL has a hard "floor" for a minimum MTU size that it will never go
below. This minimum means that a Finished message will never be sent in a
fragmented form and therefore the MITM does not have one of its
pre-requisites. Therefore this could only be exploited if using OpenSSL and
some other DTLS peer that had its own and separate Finished message
injection flaw.

The POC just injects dummy Finished data and therefore the connection never
succeeds and errors with a "digest check failed" error. This error message
is sufficient to show that the injected Finished message was received and
processed by the OpenSSL server - which it should not do. It should be
possible to improve the POC further to actually get it to succeed 1 in 256
times - but I have not attempted that.