A Look at Jabber/XMPP

by windwaker  (windwaker101@gmail.com)

After the release of Google Talk, where Google set up a Jabber server and released a Jabber client, we should take a look at the possible design vulnerabilities in the protocol Jabber uses, Extensible Messaging and Presence Protocol (XMPP), as over a thousand people were able to log into the unannounced Google Talk server before the program was even released.

To log into a Jabber server, information is sent in the form of user@domain/resource (called a JID), followed by the password.

This data is sent through a TCP connection, so sniffing password wouldn't be hard at all.  The server then establishes a connection with the authentication server and sends an XML stream to it with the information the Jabber server received from the client (i.e., when you log into Google's Jabber server, talk.google.com, it opens a connection with mail.google.com to see if you have a legitimate mail account).

When the client wants to send a message to another user, it initiates a TCP connection and sends data to the Jabber server, which either routes an XML stream of the message to another user on that messaging network or routes it to a foreign messaging network server.

This inherently is good.  Everything is routed through a single server rather than setting up direct connections with other users, giving clients more power.

A problem with this is that the protocol makes everything too compartmentalized.

For instance, let's say that there is a message that can be sent through the Jabber server and into a foreign messaging network that only crashes the foreign messaging network's clients, or even its servers.

If the data isn't cleaned properly when sent to the Jabber server, then it could be the foreign networks that the data is being sent to are at risk.  The Jabber server does not have enough information about the foreign network's server.  Therefore it can't be secure preemptively.

When a message is sent to a Jabber server, the Jabber server creates an XML stream that it sends to the client receiving the message.  The huge exploit here would be sending data directly to a client while spoofing your hostname so that it appears that you are the Jabber server.  You could appear as if you are anyone.

However, one could skip all authentication while logging into the server.

Incompatibility between Jabber and foreign network servers could also be a major issue in the future.  If the foreign network's client programs don't check if the data has been routed through the authentication server, people could imitate other users by sending information that mimics a Jabber server and pretending that the data had been authenticated already.

This would work both ways, too.  A user on a foreign network could send information to Jabber servers while avoiding authentication from the foreign network's servers with the ability to skip the entire authentication server process in the XMPP protocol.

Two messaging networks would have to share almost total information about their servers to be able to set up a secure, inter-networking messaging service.  And when there are corporations like AOL that can't even keep their own networks foolproof, I do not see this happening.

While compatibility between foreign networks seems convenient, a single user spoofing a foreign network server is a problem that the XMPP protocol has not been able to get around and cannot feasibly defeat.

For more information on the XMPP protocol and the RFC, go to www.xmpp.org.