iMessage Preview Forging - Research Update 1

It appears that I am not the only researcher who had found that iMessage on the latest iOS and Mac OS gives away your IP and device information.

Perhaps I should have distributed that post more; seeing as research by others has gotten more traction. meh.

Here is my previous post on iMessage: https://protoxin.net/your-iphone-mac-is-giving-you-away-imessage/

This post is going to be quite lengthy compared to my usual; go grab some coffee. Here we go!!!


Intro

Regardless of the basic privacy concerns for iMessage previews, another issue became greatly recognised. I realised that I can be the one that owns the server/destination (whodathought). Seeing as I can be the malicious actor, I decided to explore attack vectors for this iMessage Preview issue.

With the iMessage Preview issue, one can attempt a small level of social engineering by dynamically altering web server responses.

Viewing Requests and Previews

When you send a link via iMessage, various types of metadata is grabbed from the destination site. Most of the metadata is pulled from the HTML <head> section. Before we get too far into the metadata, what do the initial requests look like when you send a link in iMessage?

Initial requests to a web server via iMessage

There are the requests we've been hearing about! Okay, time to focus on that metadata. When the initial GET / request is made, iMessage does some parsing of the <head> tag. What exactly gets parsed? Mostly the title and main site image. For example, iMessage will parse the following from this site:

<head>  
...

<meta property="og:title" content="ProToxin.Net" />

<meta property="og:image" content="https://protoxin.net/content/images/2016/10/7375_1_other_wallpapers_eagle_flag_eagle-4.jpg" />

...
</head>  

Once this data is parsed, it is displayed in an iMessage Preview as follows:

iMessage preview after parsing data.

Here is a very high level diagram of the iMessage Preview process:

This made me realize something...I can control what data is within the <head> section based on the request to my web server.

The Server

Okay, we know what the requests look like and now we know 'how'. Setting up a web server is easy to do with Python. Due to the fact that I'm still researching and trying to see what else can be done, I'm holding off on releasing my code. Code will be released once research has finished, I promise!

We know the following about iMessage Previews:

  • iMessage has quite a specific User-Agent
  • Previews are constructed via parsing <head> element
  • Once the sender has parsed the HTML, the receiver is sent parsed data and does not need to request resources from the server
  • Previews opened by the receiver are opened through Safari (or default browser)

Seeing as we own the server, we can create an interceptor. The interceptor responds with a set of specific response headers the moment an iMessage user sends someone a crafted URL which points to our interceptor.

Since the receiver's iPhone, Mac, or iPad will disclose what device it is via User-Agent strings, our interceptor can then display any content we so choose.

Here is a high-level flow diagram of how our server will work:

Example flow of server logic

I know...kind of a 'okay...' thing, however, the next section explains why this is so useful.

Attacking

The most obvious reason for spoofing/forging iMessage Previews is some level of social engineering. Aside from obtaining the receiver's device data (useful for crafting exploits...more on this later), we obtain their IP. With BYOD and employers offering their own WiFi to employees, this make obtaining an IP address something important...not to mention if we are a Nation-State Actor and need to know the IP of a target.

Now that we have our server returning bogus metadata when we send a crafted iMessage, our target will see what we want them to see.

For example, when sending one of my web sites to an iPhone/iMessage user, both parties will see the following:

On the server side, we will see the following (receiver is disclosed once the link is clicked):

Now we know that the target is using an iPhone as well as their IP. Imagine if you had an informant send this link to fellow iPhone users or if an informant/target posted this in a group message with iPhone users.

Heck, since your Apple products disclose device info, they can still just post a bogus url in a group chat and wait for Apple devices to click...

Scary Consideration

While working on all of this, something dawned on me. New models of iPhones (since the 6? correct me if I'm wrong) have ForceTouch. ForceTouch allows apps to behave differently when a user applies varying levels of pressure on the screen.

For example, when you use lightly press on a message within iMessage, the following happens:

I realised that when I applied pressure to thumbs-up my own intercepted request, my iPhone began to request resources from my interceptor server; even though I quickly let just a tiny bit of pressure go (too much pressure triggered the preview feature to open the site) and continued to thumbs-up it.

This means that if a target so much as puts just a bit extra pressure for not even one (1) full second, they will connect to our interceptor server without seeing anything happen on their phone.

*It is also worth noting that by including remote resources, such as the NSA logo, you will disclose the sender's IP to the remote server. I haven't gone too far with this finding, however, it is another portion of iMessage to experiment with.

End

This concludes this post. As I said, I'm continuing research and seeing what else can be done to/with iMessage. Once I deem that my research is over, I will be posting code for what I've completed/been able to do.

Be sure to check back once in a while to see what else I've found with iMessage!

Until next time, folks!
-ProToxin

Join EFF!