Aimject 1.0 Released
Friday, November 24, 2006
Aimject facilitates man-in-the-middle attacks against AOL Instant Messenger's OSCAR protocol via a simple GTK interface. This 1.0 release brings Aimject functionality to the masses, being available for Linux, BSD, OS X, and Win32 platforms.
Introduction
Instant messaging and real-time network communication are becoming increasingly prevalent in both personal lives and the workplace. While recent events have brought IM privacy to the attention of mass media, security in most systems has not been properly addressed. Given the growing reliance on IM communication for a wide variety of purposes, focused investigation of potential security attacks is long overdue.
Aimject is a tool that demonstrates the ease of executing these security attacks against existing IM protocols, specifically the popular AOL Instant Messaging (AIM) service which uses the OSCAR protocol. By performing a hybrid network and application layer MITM attack, Aimject can manipulate communication flow and gain authority over several aspects of the AIM service.
The major features of Aimject include message viewing, muting, and injection. The message viewing will decode all intercepted AIM communications and organize them into browsable conversations. Message muting allows selective blocking of communication to and/or from AIM users at a conversation-level granularity. Last, but not least, Aimject allows bidirectional injection of arbitrary messages into conversations. All of these features are accessible via a simple, intuitive GTK interface that even an inexperienced user would have no problem interacting with.
Technical Details
Aimject provides integrated ARP and DNS spoofing, so performing the MITM attack and intercepting AIM connections is completely automated and does not rely on any external utilities. The ARP spoofing component will broadcast ARP replies to the network, advertising the host running Aimject as the gateway. This will cause hosts on the local network to send their traffic through the Aimject host instead of directly to the gateway, setting up our DNS attack. The DNS spoofing component will listen for DNS A record queries for login.oscar.aol.com traversing the Aimject host and send spoofed replies with its own IP.
When a client logs in to AIM, several connections are established. The first connection contacts login.oscar.aol.com and authenticates the client's credentials. The OSCAR login server will then return the address of the next server that the client must connect to in order to utilize AIM services. Due to this unique login sequence, Aimject must intercept the first connection, then dissect and manipulate the server's response to effectively redirect the client's following connection to Aimject as well. At this point, the MITM technique has been successfully initialized and the client is now vulnerable to our attacks.
Injecting and dropping arbitrary packet payloads during a MITM attack is usually a trivial task. However, the OSCAR protocol utilizes its own upper-layer sequence numbers and FNAC ids, so keeping these attributes synchronized is necessary to maintain proper connection state. While these attributes actually serve no functional purpose since TCP sequence numbers already provide the necessary reliability guarantees, perhaps OSCAR was originally designed to operate on top of a transport protocol that did not provide such facilities.
Aimject also tracks subtleties such as font style and screenname formatting. For example, a client could have a message font style with a yellow background and blue foreground. If an attacker were to inject messages posing as that client, they would be easily detected by the recipient since the font style of the injected messages would be drastically different from the other ones. Similarly, screenname formatting changes are tracked and updated appropriately to avoid detection by a client.
Conclusion
Given the ease of use and public availability of Aimject, it would be unwise to unconditionally trust any communication from the AIM service. While Aimject is currently specific to AIM, it would be trivial to extend to other IM protocols that share the same inherent vulnerabilities. Existing solutions such as SSL-enabled IM services and off-the-record (OTR) messaging can provide end-to-end security and mutual authentication but unfortunately are not widely deployed. Hopefully tools such as Aimject will raise awareness of current security issues and spur the adoption of alternate secure instant messaging solutions.