Apple forgot to sanitize the Phone Number field for lost AirTags

A plastic tag hangs from a young man's backpack.
Enlarge / Apple AirTags, as seen on a backpack, allow users to try to find their own device through the location relay of other Apple users. If all else fails, the user can enable a “lost mode” intended to display their phone number when a finder scans the missing AirTag.

The hits keep coming to Apple’s bug bounty program, which security researchers say is slow and inconsistent in responding to its vulnerability reports.

This time, the vuln of the day It is due to a failure to disinfect a user input field, specifically the phone number field that AirTag owners use to identify their lost devices.

The attack of the good samaritan

AirTags are tiny button-shaped devices that can be personalized with engraving and attached to devices that are easily lost, either directly or via
Enlarge / AirTags are tiny button-shaped devices that can be personalized with engraving and attached to devices that are easily lost, either directly or via “loop” holders.

Security consultant and penetration tester Bobby Rauch discovered that Apple AirTags—Tiny devices that can be placed on items that are frequently lost, such as laptops, telephones, or car keys — do not disinfect user input. This oversight opens the door for AirTags to be used in a fall attack. Instead of seeding a target’s parking lot with malware-laden USB drives, an attacker can drop a maliciously prepared AirTag.

This type of attack does not need a lot of technological know-how: the attacker simply types a valid XSS in the AirTag phone number field, then puts the AirTag in Lost mode and drops it somewhere where the target is likely to find it. In theory, scanning a lost AirTag is a safe action; you are only supposed to open a web page at The problem is that then embeds the content of the phone number field on the website as displayed in the victim’s browser, without disinfecting.

The most obvious way to exploit this vulnerability, Rauch reports, is to use plain XSS to open a fake iCloud login dialog on the victim’s phone. This doesn’t require a lot of code:

Yes innocently embeds the above XSS in the response of a scanned AirTag, the victim gets a pop-up window showing the contents of badside.tld/page.html. This could be a zero-day exploit for the browser or just a phishing dialog. Rauch hypothesizes a fake iCloud login dialog, which can be made to look like the real one, but instead downloads the victim’s Apple credentials to the target’s server.

Although this is a compelling exploit, it is by no means the only one available: almost anything you can do with a web page is on the table and available. That ranges from simple phishing as seen in the example above to exposing the victim’s phone to a zero-day clickless browser vulnerability.

More technical details, and simple videos showing both the vulnerability and the network activity generated by exploiting the Rauch vulnerability, are available on Rauch’s public site. divulgation in the middle.

This public disclosure presented by Apple

According to reports from Krebs on security, Rauch is publicly disclosing the vulnerability due in large part to Apple’s communication flaws, an increasingly common refrain.

Rauch told Krebs that he initially disclosed the vulnerability privately to Apple on June 20, but for three months all the company told him is that it was “still investigating.” This is an odd answer for what appears to be an extremely simple bug to check and mitigate. Last Thursday, Apple emailed Rauch to tell him that the weakness would be addressed in an upcoming update, and asked him not to discuss it publicly in the meantime.

Apple never responded to the basic questions Rauch asked, such as whether it had a timeline for correcting the error, whether it planned to give him credit for the report, and whether he would qualify for an award. Cupertino’s lack of communication prompted Rauch to leave public on Medium, despite Apple requiring researchers to be silent about their findings if they want credit and / or compensation for their work.

Rauch expressed his willingness to work with Apple, but asked the company to “provide some details of when it plans to remedy this and if there will be any recognition or reward for errors.” He also warned the company that he planned to publish in 90 days. Rauch says Apple’s response was “basically, we’d appreciate it if you didn’t leak this.”

We’ve reached out to Apple for comment and will update here with any responses.

Leave a Reply

Your email address will not be published. Required fields are marked *