You've Been Hacked! A Valentine's Day Challenge.
Answers by Raul Siles (raul.siles@hp.com)


1. The reason for the lack of security in the connection between Meg and Tom was mainly due to two different factors:

A) AIM Privacy Settings: (From the "Preferences..." menu, go to the "Privacy" category)
These settings allow controlling how users can see your presence and activity while you are online, but they only apply to the primary screen name and not to other additional screen names.

- "Who can contact me": defines the list of users allowed/blocked to talk with you. If block they will see you as "Signed Off".
- "Allow users to see...": authorizes other users to see if you are typing, how long have you been idle and your limited capabilities if you are using a mobile device (such as a slower connection which involves a bigger delay in your messages).
- "Allow users who know my e-mail address to find...": defines if other users will be able to find more info about you once they know your e-mail address, such as your screen name, account existence or other info, using the "Find a Buddy" AIM feature.

It is supposed that both, Meg and Tom, set the strictest privacy settings, something like:
- Allow all users to contact me (see why bellow).
- Uncheck all users to see information about me: idle time, typing progress...
- Set that if anyone knows my e-mail address he couldn't find anything about me.

It seems that Meg didn't set the strictest settings for the "Who can contact me" option, because "Th3R3alShak3sp3ar3" was able to send her and IM message (see question 4 for security recommendations). The blocking feature works with both, primary screen names and linked names.

All these options set up AUTHORIZATION security features, but are not related at all with data ENCRYPTION. Once any AIM user has authenticated into the AIM network, he could or could not (is authorized to) do some actions based on this setting.

B) AIM Security Settings: (From the "Preferences..." menu, go to the "Security" category)
This is the only AIM setting directly related with the ENCRYPTION of the information sent through the network. It has two main purposes:
- Encryption certificate: allows specifying the certificate to be used for hiding the information to/from non-trusted third parties, encrypting the data exchanged. This would ensure ENCRYPTION.
- Signing certificate: allows specifying the certificate to be used for verifying the sender of the information and to sign all data sent, confirming the source of the data. This would ensure AUTHENTICATION and INTEGRITY.

Option "B)" is the one to be used in order to establish a secure encrypted channel, but it is based on the usage of digital certificates, called X.509v3 certificates, which are based on asymmetric encryption methods and the usage of a PKI [2]. Each party should have a digital certificate (public and private key) in order to set a secure channel. This would ensure the data privacy expected by Meg and Tom.

All the data sent by Meg to Tom should be encrypted using Tom's public key so Tom will be able to decrypt it using its own private key, and viceversa, all the data sent by Tom to Meg should be encrypted using Meg's public key and she will decrypt it using its private key.
Apart from that, all the data sent by Meg could be signed (only by her) using her private key and viceversa, allowing both parties to confirm that the other (and only the other) sent a specific piece of information.

In this case Tom didn't have a certificate, so it was impossible to establish the encryption channel.


2. In order to use the AIM encryption features, they just need that Tom will obtain its own digital certificate.

The AIM solution uses the S/MIME encryption standard and is focused on corporations, under the "Enterprise AIM Services" program. The certificates could by issued by your company, if it is registered in the previously mentioned program, or they can be obtained from Verisign (a well known CA, in partnership with AIM). Both, Meg and Tom, should have AIM version 5.2.3211 for Windows or higher in order for the AIM client to support digital certificates.

It seems that Meg had a digital certificate obtained previously somehow, probably paying for it at Verisign (http://www.verisign.com/client/enrollment/aim.html) or getting a free 60-day evaluation version, and she imported it into her AIM client.

The AIM security method presented at the begining of question 2 is known as an "end-to-end encryption" solution, or PKI-based, where the data travels encrypted from the source user to the destination user, and it is the best encryption IM solution nowadays.

Other Instant Messaging infrastructures use SSL-based encryption solutions [3]. The IM SSL solution works like the common nowadays secure Web environments (HTTPS), where a secure connection is established between the end-user and the server, in this case the IM gateway.

For IM networks, this is a less secure method because the encryption channel is established between the end-user and the IM gateway, not end-to-end. There are two parties communicating, so a second "secure" channel should be created between the gateway and the destination user, existing a clear text translation at the gateway level before re-encrypting and sending the message to the intended recipient.

Therefore, in the SSL solutions, the IM gateway is the weakest link and if compromised, all the IM conversations could be eavesdropped.

There is even an old IM "secure" communication method based on using an HTTPS proxy server, where the data could travel in cleartext due to a bad implementation of the outbound CONNECT method to port 443 to a destination where no SSL-enabled device is listening.

If Tom cannot afford to get a digital certificate, denoting its love for Meg is less than $14.95 per year ;-), they could think about using a different IM infrastructure based on SSL, where client certificates are not required.

Apart from the "America Online Instant Messenger (AIM) (http://www.aim.com)" these are the other well-known IM solutions and almost all them implement some security features [5]:
- Yahoo! Messenger (http://messenger.yahoo.com): http://messenger.yahoo.com/messenger/security/
- Microsoft MSN Messenger (http://messenger.msn.com).
- ICQ (http://www.icq.com): http://www.icq.com/support/security/

There is also a multi-network IM client, called "Trillian" (http://www.ceruleanstudios.com), that uses its own proprietary encryption algorithms, called "SecureIM" (also vulnerable, see [8]).

Additionally, there is an open source solution called "Jabber":
- Jabber (http://www.jabber.org): http://www.yabber.org/design/security.html

There are several security features involved in IM, such as antivirus protection, hiding identity (user, e-mail address, IP address...), fighting spam, filtering/ignoring users & events, password protection... [4] but we are going to focus on the traffic encryption capabilities (for other encryption capabilities, such as the username and password during the authentication process see [7]).

For example, from all the available Jabber clients for all the different OS platforms, in order to find encryption aware clients check the column called "SSL support":
- http://www.jabber.org/user/clientlist.php?Platform=Windows
- http://www.jabber.org/user/clientlist.php?Platform=Linux
- http://www.jabber.org/user/clientlist.php?Platform=Mac
- http://www.jabber.org/user/clientlist.php?Platform=Other

There are other specific and propietary IM commercial security solutions, most them focused on the enterprise level, such as:
- "NetIQ imMarshal" to monitor MSN activities: http://www.netiq.com/products/ima/default.asp
- "IM FaceTime" security monitoring solutions for AIM, MSN and Yahoo IM: http://www.facetime.com
- "Vericept" monitoring IM traffic: http://www.vericept.com
- "OmniPod" subscription service interoperable between the three networks: http://www.omnipod.com
- "IPSwitch IM": http://www.ipswitch.com/Products/instant_messaging/security.html
- "Sybary Antigen": http://www.sybari.com/products/AntigenForIM.asp
- "Top Secret Messenger" by Encrsoft, offering also PKI security for ICQ and MSN: http://www.encrsoft.com/products/tsm.html
- "Akonix", IM and P2P security management and control: http://www.akonix.com


3. Once analyzing the network flow going out from Meg computer to the AIM messaging system, the network packets contain confidential information exchanged during the "session establishment", such as, the sign-on username, the client version and language/country, the screen name (such as "th4124" ;-)) or the account e-mail address.

The unencrypted information exchanged during the IM session can be sniffed and is available in any of the locations pointed out by the question, Meg and Tom personal computers, a system between both or in the AOL messaging system. Therefore, based on the available information, any of them could be owned by the attacker.

There are specific tools to sniff IM traffic, such as "msgsnarf" (http://monkey.org/~dugsong/dsniff/), focused on chat session of AIM, ICQ 2000, IRC, MSN Messenger, or Yahoo Messenger.

Given the fact that Meg is the more technical astute of the duo, we'll suppose their PC is secure enough not to have been compromised. Following the same reasoning, it has not sense focusing in the "interesting" conversation between Meg and Tom if you have been able to compromise the whole AOL messaging system (AIM gateways or AIM servers), so let's discard this item too. Considering this last fact, compromising an intermediate system (for example, located in some ISP environment) will probably provide useful and relevant information other than the one involved in the Meg and Tom romance conversations.

So, the most likely compromised systems is Tom's computer, who has been chatting and "Internet'ing" around during the last years, using several services, such as IRC, e-mail, IM... All these activities involve a high risk in order to have being infected by some kind of malware that opened a backdoor in his computer, compromising his computing environment.

Only if Meg really configured her AIM client with the strictest settings, it was her computer the most likely compromised element because the attacker would need to change the AIM client configuration to open up it to accept conversations from other parties different than Tom, such as "Th3R3alShak3sp3ar3". Let's suppose this was not the situation and that her client was misconfigured (it is probable she would also like to receive messages from other cyber-Casanovas ;-)).


4. The first step to secure their communications would be Tom going to the Verisign website and getting a digital certificate to confirm his online love for Meg ;-) This will avoid other people out of their computers to eavesdrop their messaging sessions.

It would be recommended that both really set the strictest privacy settings, only allowing the other party to contact them:
- "Preferences... --> Privacy --> Who can contact me --> Allow only the users bellow", and adding only the other party screen name.

If for some reason they want to receive other unknown people IM messages, at least they should block messages from "Th3R3alShak3sp3ar3" screen name:
- "Preferences... --> Privacy --> Who can contact me --> Block the users bellow", adding the "Th3R3alShak3sp3ar3" name in the list.

Based on the evidence obtained, at least the attacker knows one of the IP addresses (only if they have a xDSL connection with an static IP address and have not connected through DHCP) and their AIM screen names.

Additionally, trying to secure their computing love environment as much as possible, they should install an antivirus software to protect both, the IM channel and other computer activities and they should configure a personal firewall to block all non-used services.

But before that, it should be checked if any of their computers was the compromised system; if so, reinstalling it and hardening both, the OS and the applications running on top of it, should be desired.

In an extreme case, they could contact out of band (by phone or mail) and establish a new communication channel, for example, choosing another Instant Messaging solution (this is the advantage of the incompatibility between the IM networks ;-)) where the attacker couldn't find its online existence..., although only cowards flee ;-)


REFERENCES:
[1]- "How Instant Messaging Works": http://computer.howstuffworks.com/instant-messaging.htm
[2]- "AIM certificates": http://enterprise.aim.com/products/aim/personalcerts/
[3]- "AIM certificates study": http://enterprise.aim.com/products/aimsvcs/Ferris_AOL_IB.pdf
[4]- "Instant Messaging Security Concerns and Recommended Best Practices": http://www.giac.org/practical/GSEC/Frank_Reiss_GSEC.pdf
[5]- "IM security news": http://www.instantmessagingplanet.com/security/
[6]- "Instant Messaging and Presence Protocol (IMPP)": http://www.ietf.org/html.charters/impp-charter.html and http://www.imppwg.org
[7]- "Instant Messaging Security": http://infosecuritymag.techtarget.com/2002/aug/cover.shtml
[8]- http://www.dshield.org/pipermail/list/2002-November/006055.php


"Again, Ed, it has been a pleasure learning and enjoying new network protocols, services and their security issues while answering this challenge questions".

Raúl Siles