As I mentioned earlier, Facebook does not use SSL on their new XMPP server. All of their security is based on an algorithm called Digest-Md5. As the name says this is based on the popular MD5 hashing algorithm that is
no longer considered secure. From
Facebook:
No. At this time, Facebook Chat does not support SSL.
Regarding MD5:
US-CERT, the US Department of Homeland Security's Computer Emergency Readiness Team, says:
- "Do not use the MD5 algorithm"
"Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use."
- "Scrutinize SSL certificates signed by certificates using the MD5 algorithm"
"Users may wish to manually analyze the properties of web site certificates (...) Certificates listed as md5RSA or similar are affected. Such certificates that include strange or suspicious fields or other anomalies may be fraudulent. Because there are no reliable signs of tampering it must be noted that this workaround is error-prone and impractical for most users."
No SSL:
What happens when you don't use SSL for your chat? People sniffing the network can see what you are saying. This is very simple to do.
Either use tcpdump from the command line (works on Mac,linux etc) or grab a packet sniffer like
wireshark . I would recommend wireshark anyway because it makes the next part even easier. If you used tcp dump, this you would have something like this
sudo tcpdump -i en0 -s500 -w ~/Desktop/DumpFile01.pcap -vv
Lets say you have a network dump somehow and you open up wire shark. set it to filter jabber and you will start to see something like this. I've highlighted a message packet so you can see that I was able to read this message someone sent.
Now everything sent on the network can be read and the password "security" is based on MD5 right? behold a captured password sequence:
cmVhbG09ImNoYXQuZmFjZWJvb2suY29tIixub25jZT0iNjdFRDdCQTg3NjgwN0MyOEIzQUI2RkE2MzRGQTE2MDUiLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=
this decodes from base64 to:
realm="chat.facebook.com",nonce="67ED7BA876807C28B3AB6FA634FA1605",qop="auth",charset=utf-8,algorithm=md5-sess
Excellent we have some information. The client replied with:
dXNlcm5hbWU9InNvbWVvbmUiLHJlYWxtPSJjaGF0LmZhY2Vib29rLmNvbSIsbm9uY2U9IjY3RUQ3QkE4NzY4MDdDMjhCM0FCNkZBNjM0RkExNjA1Iixjbm9uY2U9ImQzM2M4ODYyMTI2NjI2NTYzNzcxMDk3YjcwIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NoYXQuZmFjZWJvb2suY29tIixyZXNwb25zZT01MjBhMjdiOWRjOTE5NWRjMTJjNTVjZGY4MTUyOWI2MixjaGFyc2V0PXV0Zi04
this decodes from base64 to:
username="someone",realm="chat.facebook.com",nonce="67ED7BA876807C28B3AB6FA634FA1605",cnonce="d33c8862126626563771097b70",nc=00000001,qop=auth,digest-uri="xmpp/chat.facebook.com",response=520a27b9dc9195dc12c55cdf81529b62,charset=utf-8
Nonce and cnonce are used to calculate the encrypted "response". This is where the password is. nonce and cnonce are really there for one time use to prevent a replay attack.
What do we know now?
password hash:
520a27b9dc9195dc12c55cdf81529b62
nonce: 67ED7BA876807C28B3AB6FA634FA1605
cnonc: d33c8862126626563771097b70
qpop: auth
nc: 00000001
password hash is based on a series of md5 hashes:
first hash (X) is of username:realm:password
we know this to be = someone:chat.facebook.com: (password)
Next hash (Y) is X:nonce:cnonce
we know this to be: (password hash): 67ED7BA876807C28B3AB6FA634FA1605: d33c8862126626563771097b70
Next hash (Z) fully known to be of AUTHENTICATE:xmpp/chat.facebook.com
Final hash is the response value, which is also known and we know it is in the form:
Y:nonce:nc:cnonce:qop:Z
we fully know Z, nonce, cnonce, qpop, nc
The only thing missing here is Y, which is dependent on X, which is just an unsalted MD5 hash based on a password. How would you crack this? There are a few ways, but the simplest in most cases is just to use rainbow tables but compute the hash 2 times more using the other parts of the string from above and see if it matches the response. I'm going to stop the explanation here for obvious reasons. More info on rainbow tables here:
http://www.freerainbowtables.com/
http://en.wikipedia.org/wiki/Rainbow_table
There is also the possibility of finding another string that will create the same password hash. This is called a hash collision. In this case, the attacker doesn't even need to know the actual password. They can just use this other string in its place and access an account just the same.
If the person is using a short or insecure password a dedicated attacker (identity thieves, spammers etc) should have it cracked easily and since the packet was captured, the attacker can test against the password as much as he likes on his own machine.
