XMPPloit explained

01 09 | 2012

Written by Tanguy

Classified in : Homepage, Debian, Jabber

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.

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:

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.

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.

Tags : XMPPloit, XMPP, attack, exploit, flaw, SSL, TLS, explanation, MITM

8 comments

saturday 01 september 2012 à 20:08 Anonymous said : #1

That said, a note to the designers of any *new* protocol: STARTTLS is a bad idea, just require SSL and don't allow an unencrypted connection.

saturday 01 september 2012 à 21:24 Mika said : #2

@Anonymous: No! Do require STARTTLS! Port+IP-based SSL is so horrible, because you can't negotiate anything. The server as well as the client can only ever offer one certificate per IP, which is a pain. It's the reason why you can't use VirtualHosts together with https today, which requires massive amounts (one per hostname) of IPs just to serve different domains from one server.

@the problem: Additionally, pidgin for example has the option to actually require encryption and by default does not allow authentication to happen via plain text. Which of course degrades this man-in-the-middle attack to a simple denial of service attack - if you can become the man in the middle, you can stop pidgin from connecting. Duh.

sunday 02 september 2012 à 15:04 Antonio said : #3

@Mika:
Check out the TLS SNI extension.

@Tanguy:
Thank you for bringing attention to the insecure defaults of some clients.

However, the choice of name for this tool is really unfortunate. It's not exploiting the protocol, and it scared me (and I assume others as well) needlessly when I read this headline.

For the record, Psi+ defaults are

Encrypt connection: When available
Allow plaintext authentication: Over encrypted connection

which, when attacked by this/similar tools will protect your password (by forcing DIGEST-MD5/Kerberos I guess), but the rest of your communication will be MITMed just fine.

monday 03 september 2012 à 09:02 Jan Hudec said : #4

The problem with HSTS of course is that the MITM can simply delete the header. If the client should refuse to continue if it ever saw that header for given URL and does not see it this time, but some hole remains open.

@Mika: It is actually possible to create one certificate that is valid for multiple hosts using alternate names, so you can have virtual hosts with https. It may not work with some buggy clients though as it's rarely used and thus untested.

monday 03 september 2012 à 10:17 Tanguy said : #5

@Jan Hudec : Yes, HSTS requires a trusted first connection, so it is not a complete solution indeed.

About subjectAltName, I must object: this is quite used, and very well supported but it is has major drawbacks (when you add a new domain name, you must regenerate the certificate for everything you already have), as opposed to SNI which is very flexible but not supported by antique systems such as Windows XP's crypto library.

monday 03 september 2012 à 17:13 mirabilos said : #6

Right #1 – just use port 5223 and it works.

This is also important for firewalls (packet filters): so, people can *know* that there’s no way to not encrypt.

friday 03 august 2018 à 16:42 livy said : #7

I have created a TCP socket which replies to the STARTTLS request from server as a TLS negotiation. However, the negotiation fails with "bad packet" (I am using the .NET AuthenticateAsClient()method). The same script works when auth over 443, however, the "bad packet" only occurs when attempting to reply to the SERVER HELLO : REQUEST CERTIFICATE....Any suggestions on what "certificate" the XMPP server is looking for over port 5222? Again, the certificate I am using successfully authenticates and negotiates TLS when over port 443...

friday 07 august 2020 à 06:10 barund said : #8

<h1>Nice information</h1>

Rss feed of the article's comments

Tanguy Ortolo