ICQ, AIM, Yahoo Messenger, MSN Messenger — instant-messaging applications are now installed on a substantial fraction of internet-connected desktops. The user base, particularly among younger users, is approaching ubiquity. The security properties of these tools have not received much attention.
I have been looking at them this month, partly because friends asked about safety and partly because I expect this to be a growing source of compromise. A first writeup of what I have observed.
What the protocols look like
None of the major IM protocols are open standards in 2000. Each is proprietary, with the protocol details either undocumented or known only through reverse-engineering. Several open-source clients exist that interoperate with the major networks; their existence has come from systematic reverse engineering rather than from cooperation with the owners.
The broad shape of the protocols, from the open-source implementations:
Cleartext on the wire, mostly. ICQ traffic, for instance, is unencrypted. Anyone observing the network can read message contents, file transfers, and the user's status updates. AIM is similar.
Single point of authentication, at login, with a fixed password sent to the central server. The server holds an authoritative password database. No proper public-key model, no certificate-based authentication, no mutual authentication.
Centralised relay for messages between users. Your message to a friend travels: your client → IM provider's server → friend's client. The server can read every message; users have no way to verify message integrity or to ensure end-to-end confidentiality.
File transfer between peers in some configurations, with the server brokering the connection. The peer-to-peer aspect is a separate attack surface — your IM client opens listening ports to receive transfers, and these are reachable by the attacker who can manipulate the broker.
Buddy-list information stored centrally and synchronised across the user's devices. The provider knows everyone you talk to and has a complete graph of social connections.
The attack surface
A few specific vectors I have been thinking about.
Network eavesdropping. Anyone in a position to observe the network — at the user's local network, the user's ISP, any intermediate carrier, the IM provider — can read every message. Most users are unaware of this. The tooling for passive observation exists and is straightforward.
Client vulnerabilities. ICQ and AIM clients have had multiple buffer-overflow advisories in the past two years. Each client is C code processing untrusted input from the network; the patterns I have written about for other internet-facing daemons apply equally here.
Social engineering through trust. When a message arrives from someone in your buddy list, the trust assumption is high. Attackers exploit this — by compromising one person's account and using it to social-engineer their contacts. The phenomenon has its own emerging name: "impersonation attacks".
Account hijacking. ICQ in particular has been the target of systematic account-hijacking campaigns. The mechanism is: passwords are weak (most users picked easy ones); the central authentication is brute-forceable with sufficient effort; once the password is known, the attacker has comprehensive access to the user's communications and contact graph. There are underground markets specifically trading hijacked ICQ accounts.
Malware distribution. Some IM systems support rich messages, including HTML and embedded URLs. Malicious URLs distributed through trusted channels are an effective attack — the recipient sees the link as coming from a friend, follows it, lands on a malicious site.
Trojan distribution. File transfer through IM is a vector for remote-control trojans. The attacker sends a friend a "funny picture" that turns out to be a Sub7 installer.
The structural problem
IM is not designed for the threat model of the modern internet. The protocols were designed in the late 1990s, when the assumption was that participants were broadly cooperative and the network was largely benign. The protocols make assumptions that worked for a friendlier internet:
- Servers will not snoop. (They can.)
- Users have strong passwords. (They do not.)
- Messages have integrity by virtue of source authenticity. (They do not — anyone with the password can impersonate.)
- Network traffic is private because it is on TCP. (It is not.)
- File transfers from contacts are safe because contacts are trusted. (Trust is not transitive.)
Fixing this requires substantial protocol redesign. The vendors are not motivated — fixing it would mean breaking existing clients, requiring upgrades, slowing user adoption. The economic incentive favours leaving the protocols as they are.
What defenders can do
For a security-conscious user:
Treat IM as cleartext communication. Do not send anything you would not say in a postcard. Sensitive information, credentials, internal corporate details — none of these belong in IM.
Pick a strong password. The brute-force attacks succeed because most passwords are weak. A passphrase-style password (xkcd-style: four random words concatenated) is far more resistant.
Disable file transfer, or set it to require explicit approval for every transfer. The trojan-distribution vector is essentially eliminated by this.
Verify identity out of band for unexpected messages from contacts. "Did you really send me this link?" via a different channel is the easiest way to defeat impersonation attacks.
Patch promptly. The IM clients have been the target of vulnerability advisories repeatedly. The patching cadence should be at least as careful as for other internet-facing software.
Be careful with auto-accept settings. Many IM clients have settings to auto-accept messages, files, and even chat invitations. Default-on is the wrong default. Manually approving each interaction is more friction but is meaningfully safer.
For an operator running a network where IM is in use:
Decide whether IM is permitted. Many enterprises ban it; many home users have it; many small businesses are in between. The decision should be deliberate, not default.
If permitted, monitor it. Snort signatures for IM traffic are widely available and easy to deploy. Aggregate metrics — how many users using which IM service — are useful operational visibility.
Block file transfer at the perimeter unless there is a specific reason to permit it. The risk-benefit favours blocking by default.
Plan for impersonation incidents. A user whose account is hijacked will try to recover it. The procedure should be documented, with clear steps the user can take.
What I expect over the next several years
Three predictions, in roughly increasing order of confidence.
Encrypted-IM alternatives will emerge but will not replace the dominant platforms. Several attempts at encrypted instant messaging are visible. None will reach the user base of ICQ or AIM in the next three years. The network effect favours the existing platforms regardless of their security weaknesses.
The major platforms will add basic encryption eventually. Probably first as an opt-in feature, eventually as default. The driver will be specific embarrassing incidents — high-profile users finding themselves embarrassed by intercepted messages — rather than concerted security improvements.
IM-borne attacks will be a significant component of the malware landscape. The combination of vulnerable clients, social-trust exploitation, and the size of the user base makes IM a target-rich environment. By 2002 or 2003 I expect to see IM-distributed worms with the impact of ILOVEYOU.
A small reflection
I do not personally use any of these IM systems. Most of my friends communicate with me through email or IRC. The protocols I do use have their own weaknesses (IRC is also cleartext, also unauthenticated) but the user populations are smaller and the attacker incentives correspondingly smaller.
For friends who do use IM, I have given them roughly the advice in this post — treat it as cleartext, use strong passwords, do not accept files. The advice is well-received and largely ignored, which is the standard pattern for security advice everywhere.
The broader observation is that IM is a new category of always-on, identity-bearing communication that the security model of the wider internet has not adapted to. The defensive maturity catches up over years, not months. We are in the early part of a long catch-up curve. More to write about as the curve develops.