Python framework that implements a working PoC for exploiting the POODLE vulnerability. This is a preemtive move so that I can use this code as reference if this flaw ever comes up in a CTF.
The poodle module contains a POODLE class which implements the logic
for exploiting the POODLE vulnerability.
We'll look at poodle-sample-1.py as an example to explain how this PoC works and
make parallel with how this would be exploited in the real world.
There are 3 components to this attack: a client, a server and an attacker-controlled MitM proxy.
The server, implemented by SecureTCPHandler here, is a perfectly normal
SSL server. This would typically be a HTTP server which accepts requests
from any client. The attacker cannot "read" the data being exchanged between
the server and the client.
The client, implemented by POODLE_Client here, would typically be a web
browser. The client holds a secret, which in reality would be a HTTP cookie,
which the attacker wants to read. The attacker does not have access to read
the client requests nor the server's responses, but it does have the ability
to influence the client to make arbitrary requests. If the attacker is in a
Man-in-the-Middle situation between the client and the server, this could be
done by injecting a small snippet of javascript on any HTTP website
visited by the client which forces the client to makes AJAX POST requests to
the victim server. All requests would contain the HTTP cookie that the attacker
wants to recover. In poodle-sample-1.py, this exact situation is replicated
by sending messages in which the attacker controls two fields:
s.send('%s|secret=%s|%s' % (prefix, secret, suffix))prefix takes the role of the URI path, and suffix takes the role of the
request body. The attack revolves around the fact that these two fields can
be made to change lengths by the attacker.
A MitM proxy, sitting between the client and the SSLv3 server, implemented
by MitmTCPHandler here. The attacker cannot decrypt the SSL traffic, but
he can modify parts of the message.
The actual attack is started by calling POODLE.run(). A subclass of POODLE
has to implement the logic in trigger(). This method has to force the client to
make a request to the server, which goes through the MitM proxy. The implementor
also has the responsibility of extracting the encrypted Application Data message
from the SSL stream and call POODLE.message_callback() with the data. The method
will return the altered data that the implementor must forward via the MitM
proxy. One of the two methods POODLE.mark_error() or POODLE.mark_success()
has to be called depending on whether the SSL connection terminated early,
indicating a decryption failure (error), or continued as normal (success).
This all has to be done before the call to trigger() returns. Provided these
conditions are met, the POODLE class will handle the rest.