XMPPloit is an exploit tool for a so-called “flaw” in the XMPP protocol. It has been published recently under the GPLv3 license, and has received much comment. However, it does not seem anybody took the time to study this attack and explain it.
XMPPloit is designed to serve as a transparent man-in-the-middle between an XMPP client and its XMPP server, in order to force the client not to encrypt its communications, so that it is possible to read them and modify them on-the-fly.
That allows to force the client to use a clear text authentication mechanism, to display its login and password, and to modify any message it sends or receives.
Mode of operation
If you were expecting a tricky, undetectable attack against the XMPP protocol itself, you will be disappointed. This attack could not be simpler:
- In XMPP, the clients opens a connection to the server as plain text. In this case, with the attacker between them.
- The server offers the STARTTLS extension. The attacker blocks it, that is, does not transmit this offer to the client, so the connection stays in plain text.
- The client authenticate over the plain text connection.
- This is not at all a flaw of the XMPP protocol. It is applicable to POP, IMAP, SMTP, in fact to any protocol that uses clear text connections and upgrades them using a STARTTLS-like mechanism. This includes HTTP with redirection to HTTPS.
- This is not transparent, at least not with XMPP client that respect the RFC recommendation that Clients SHOULD use TLS to secure the streams prior to attempting the completion of SASL negotiation. In Gajim for instance, the user would be informed that the authentication is going to happen without encryption, and asked for a confirmation.
In fact, this is only an exploit against design flaws of some XMPP clients that would not warn the user that they are about to send their credentials on a clear text channel.
Actually, the protocol most vulnerable to this type of attack is HTTP. Many websites that identify their users are made available over clear text HTTP, with an automatic redirection to HTTPS. Unless they use HSTS, this redirection can be blocked by an attacker without being noticed by most users. And, contrary to XMPP, not warn the user of an insecure login is not the fact of some broken clients, but of all the available browsers. I repeat: not a single browser will currently tell the user: “Hey, you are about to transmit a password in clear, it could be intercepted!”. Yes, there are browser that warn their users this way the first time: “Hey, you are about to transmit your answers to a form in clear! Do you wish to do that, and do you want me to warn you next time?” but this not quite the same, and it is just badly designed and in practice neither useful nor usable so everybody disables that.