Apple’s iMessage Flaw Exposes Your Data to Spammers
When you send or receive a link through iMessage, the added URL extracts some text and an image to show the content more conveniently. This is something that Facebook, Twitter and Slack have been doing as well. With the latest updates to iMessage, Apple has also introduced these small content cards for whenever you share a URL in a chat window. While these content cards come in handy, offering a preview of what the shared link is going to be about, iMessage is handling its content cards in a far less secure manner.
When you are sharing links using Facebook, the website you are linking to receives a request from Facebook. During the process, the service scans the shared link, accesses its content to retrieve data such page title and its thumbnail image, and embeds the content card inside the user’s chat window. All of this is done from the servers of the service (Facebook or Slack), not user’s. During this information exchange, metadata of your IM service’s servers is exposed to a linked website, while the user stays secure.
Security researcher Ross McKillop has said that links shared using iMessage shows the request from your device, revealing your IP address, device type and its operating system.
What’s the problem with iMessage sharing your metadata
Doesn’t sound too bad? After all it just shares your device type and your IP address. But, as Mckillop points out an attacker or spammer could send its victims links to an infected site, trying to get user information. Even if the user never clicks on this shared link, iMessage would connect with the website to retrieve preview information. An attacker could collect data for every user using this simple sharing technique. The researcher has said that this could lead to sophisticated attackers learning about your location, your ISP provider and possibly your name too.
This data is critical as it could be used to devise future attacks, especially spam and spear phishing campaigns that localize attacks according to regions and devices.
As this request is clearly being made, and parsed, by Safari from the User-Agent string it’s reasonable to believe that there is potential that an exploit found in Safari could be triggered without the target even browsing to the site, simply by sending them aniMessage containing that URL.
McKillop further explains that the request to the shared link’s website is sent from each of the iOS devices that the receiver owns. This means an attacker could send a URL to determine if the target is at home or elsewhere based on the IP addresses.
Currently, there is no way for users to switch off automatic request behavior as iMessage offers no option to turn link previews off. McKillop suggests Apple could fix this issue by requesting for link preview data using its own servers and then insert the preview data inside iMessage, just like other services. Another solution presented is to “extract the metadata on the sending device (they obviously trust the URL) and encapsulate that as metadata within the message.”
Apple added the link preview feature to iMessage in iOS 10 and macOS 10.12, released two weeks ago. The company is expected to fix the data leaking bug in an upcoming update.
Earlier, we saw reports of iMessage sending a user’s contacts to Apple servers. While the conversations remain encrypted thanks to end-to-end encryption, Apple does receive details of who a user might be contacting with over iMessage.