If You Can't Break Crypto, Break the Client: Recovery of Plaintext iMessage Data
by Joe DeMesy, Shubham Shah, and Matthew Bryant, on Apr 8, 2016 5:50:20 AM
The below video demonstrates this attack in action:
Though the embedded WebKit library used by Messages for OS X executes in an applewebdata:// origin, an attacker can still read arbitrary files using XMLHttpRequest (XHR) GET requests to a file:// URI due to the lack of a same-origin policy (SOP). By abusing XHR to read files, an attacker can upload a victim’s chat history and attachments to a remote server as fast as the victim’s Internet connection will allow.
The only user interaction required for a successful attack is a single click on a URL. Furthermore, if the victim has the ability to forward text messages from their computer (SMS forwarding) enabled, the attacker can also recover any messages sent to or from the victim’s iPhone.
Want to know all the gritty details? Then keep reading.
Messages for OS X
Messages for OS X depends upon an embedded version of the HTML rendering engine WebKit for much of its user interface. When messages are sent or received, HTML is inserted into the DOM to render the UI and any accompanying attachments/media content. All messages sent through the application are rendered in a DOM; hence, common client-side web vulnerabilities can affect the Messages for OS X application.
When testing the Messages for OS X client, arbitrary protocols schemes were found to be automatically converted into links and inserted into the DOM. The example URIs below are all inserted as links into the WebView when messaged:
Since the attacker’s code is executing in a full WebKit implementation, XMLHttpRequest is available at runtime. One of the most notable differences between an embedded version of WebKit and a web browser like Chrome or Safari is that WebKit does not implement any same-origin policy (SOP) because it is a desktop application. An attacker can take advantage of this to read files from the local filesystem without violating the same-origin policy by sending XMLHttpRequest GET requests to file:// URIs. The only requirement is that the attacker must know the full file path. Relative file system paths (e.g., ~/.ssh/id_rsa) cannot be used.
The Messages for OS X application DOM can execute the following to read the /etc/passwd file:
function reqListener ()
// send back to attacker’s server here
var oReq = new XMLHttpRequest();
After being converted into a URI payload, the code resembles the below:
When clicked in the Messages application, the following prompt appears:
Due to the OS X application sandbox, files were only accessible if they were located in ~/Library/Messages/* and some other non-user system directories such as /etc/.
Taking the Messages Database and Attachments
When messages and attachments are received by Messages for OS X, they are saved in this directory:
These messages’ textual content and other metadata are stored in a SQLite database located at:
This database also contains the locations for all attachments located on a user's machine. To steal this database, and subsequently all attachments ever received or sent by a victim, a more advanced attack payload becomes necessary.
The Exploit Overview
The following steps need to be carried out before data can be successfully removed by an attacker.
- Obtain the current user (~cannot be used)
- Generate a full path with the username for the chat.db file i.e.,
- Use XMLHttpRequest to read the db database and query it for attachment's file paths
- Upload the database and all attachments using XMLHttpRequest (or HTML5 WebSockets)
We can determine the currently logged-in user by requesting and parsing/Library/Preferences/com.apple.loginwindow.plist. This file is readable from in the OS X application’s sandbox, which makes it trivial to construct the full path to the user's chat.db.
The attacker next performs a little obfuscation to make the URL’s appearance more realistic:
If a victim clicks the above URI in the Messages for OS X application, the victim's entire chat history and all associated attachments are transferred to the attacker.
Exploit code for this is available on our Github.
Client-side content injection flaws are no longer limited to the browser, and haven’t been for some time now. While it’s certainly helpful for developers to use web technologies such as WebKit or its more dangerous kin nw.js to build desktop applications, these libraries can have adverse effects on application security when used naively. It is clear that embedded web frameworks allow common vulnerabilities, such as cross-site scripting (XSS), to be leveraged in a more devastating way than previously possible.
This vulnerability also demonstrates the power a URI has over your machine. To the novice user, a URI is simply a link to a website, but this is only one variant of a much more complicated ecosystem. Much like an email attachment, users should never click a URI unless you trust the source it came from, and even then exercise prudence.
We’d like to thank Apple for communicating with us throughout this process and their cooperation in quickly remediating this vulnerability.