Tanguy Ortolo: XMPPloit explained

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 to study this attack and explain it.

Goals

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:

1. In XMPP, the clients opens a connection to the server as plain text. In
   this case, with the attacker between them.
2. 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.
3. The client authenticate over the plain text connection.

Comments

• 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.

Article source: Go to Source
Feed source: http://planet.debian.org/rss20.xml
License: The original licenses are retained