[1]https://www.ryanpickren.com/safari-uxss
Hacking the Apple Webcam (again)
Gaining unauthorized camera access via Safari UXSS: the story of how a
shared iCloud document can hack every website you've ever visited.
Background
Apple fixed my last 0day chain (CVE-2020-3852 + CVE-2020-3864 +
CVE-2020-3865) by making camera access drastically more difficult. Now
multimedia access is only allowed when the protocol is "https:" and the
domain matches your saved settings. This means that cleverly malformed
URIs won't cut it anymore. Now we need to genuinely inject our evil
code into the target origin. In other words, we need to find
a Universal Cross-Site Scripting (UXSS) bug.
But what exactly is UXSS? Google Project Zero has a nice summary in
their paper, "[2]Analysis of UXSS exploits and mitigations in Chromium"
-
"UXSS attacks exploit vulnerabilities in the browser itself [...] to
achieve an XSS condition. As a result, the attacker does not just get
access to user session on a single website, but may get access to any
[website]."
The authors of this paper go on to call UXSS "among the most
significant threats for users of any browser" and "almost as valuable
as a Remote Code Execution (RCE) exploit with the sandbox escape."
Sounds pretty great, right? Imagine building a website that can jump
into [3]https://zoom.com to turn on the camera, hop
into [4]https://paypal.comto transfer money, and
hijack [5]https://gmail.com to steal emails.
Before we go any further, I should clarify how exactly this bug differs
from my last [6]Safari Camera Hacking project. That bug specifically
targeted stored multimedia permissions. It did not give me the ability
to execute code on arbitrary origins. Check out my [7]attack diagram to
see which origins were being used. In other words, that hack let me
leverage Skype's camera permission but did not let me steal Skype's
cookies.
Let's try to find a UXSS bug in the latest version of Safari (Safari
v15 beta at time of writing). As always, the first step is to do a
lot of research into prior work. After all, the best security research
comes from [8]standing on the shoulders of giants.
The Attack Plan
After reading numerous write-ups about patched Safari UXSS bugs, I
decided to focus my research on [9]webarchive files. These files are
created by Safari as an alternative to HTML when a user saves a website
locally.
Screen Shot 2021-08-12 at 10.43.16 AM.png
Safari saving a website as a Webarchive file
This is an awesome trick to let Safari rebuild the context of the saved
website, but as the Metasploit authors [10]pointed out back in 2013, if
an attacker can somehow modify this file, they could effectively
achieve UXSS by-design.
[11]According to Metasploit, Apple did not view this attack scenario as
very realistic because "the webarchives must be downloaded and manually
opened by the client." Granted this decision was made nearly a decade
ago, when the browser security model wasn't nearly as mature as it is
today.
Apple's decision to support this ultra-powerful filetype gave way to an
era of hackers trying to forcefully open them on victims' machines.
Fundamentally, this attack can be broken into two steps:
1) Forcefully download an evil webarchive file
2) Forcefully open it
Until recently, there were no protections to prevent step #1. Prior to
Safari 13, no warnings were even displayed to the user before a website
downloaded arbitrary files. So planting the webarchive file was easy.
([12]Now with Safari 13+, users are prompted before each download)
Opening the webarchive file was trickier, but still manageable by
somehow navigating to the file:// URI scheme. Back when Safari's error
pages lived on the file:// scheme, hackers figured out how to purposely
invoke an error page to just alter its pathname, a hack delightfully
dubbed "Errorjacking." See [13]here and [14]here for two
variations. [15]Another approach that worked back in the day was to
simply set the tag to file://.
Fast forward to 2022 and things get a lot harder. Not only are
auto-downloads prevented by default, but webarchive files are
considered malicious applications by [16]macOS Gatekeeper. This means
that users can't even manually open foreign webarchives themselves
anymore. Apple seems to have changed their 2013 stance about how
dangerous these files can be.
Screen Shot 2021-08-12 at 1.17.50 PM.png
Download prompt in Safari 13+
Gatekeeper Webarchive Prompt
Gatekeeper Launch Prevention
Still, webarchive files just seem too juicy to give up on. Let's
explore how this old-school hack can still occur on the latest Safari
and macOS builds.
Exploration of custom URI Schemes
I found success with my last [17]Safari Camera Hacking project by
conducting a deep dive into [18]official IANA-registered URI schemes.
This project was heavily guided by RFCs and public documentation. But
there is an entire world of [19]custom URL schemes that I neglected to
talk about. These unofficial and (mostly) undocumented schemes are
usually used by third party iOS/macOS apps as a form of deep linking.
There is actually an entire community built around [20]discovering and
using these schemes cross-app for
both [21]fun and [22]hacking projects.
An interesting note is that several first-party system apps such as
Apple Help Viewer (help://), FaceTime (facetime-audio://), and Apple
Feedback (applefeedback://) also support custom URI schemes. Abusing
these schemes from a website in Safari is not a novel technique.
Indeed, hackers have been finding ways to use custom schemes to launch
(and exploit bugs in) system applications for a while now. Hacks range
from [23]annoyingly placing calls, [24]aiding in social engineering,
to [25]arbitrary file execution. Seriously, there is some [26]awesome
research in this space.
To help combat these attacks, modern versions of Safari warn the user
before blindly launching secondary applications. That is, unless they
are one of the hardcoded exceptions identified in this
great [27]Blackhat presentation.
Screen Shot 2021-08-12 at 2.33.07 PM.png
Custom URI Schemes that Safari will launch without Prompt
All of these schemes are registered with [28]Launch Services, so you
can list them (and others) via this command:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks
/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep
-B6 bindings:.*: | grep -B6 apple-internal
After digging through internal Apple schemes and cross-referencing them
with the ones trusted by Safari, I found one that caught my eye-
"icloud-sharing:". This scheme appears to be registered by an iCloud
Sharing Application called "ShareBear."
Screen Shot 2021-08-12 at 2.38.00 PM.png
LaunchServices data about the icloud-sharing: scheme
ShareBear was interesting to me because sharing iCloud documents seemed
like a plausible path towards downloading & launching webarchive files.
I couldn't find any publicly available documentation or research about
this scheme so I just started poking at it myself.
ShareBear Application
At this point we have identified an application that can be
automatically launched by Safari, however we do not know how to
correctly open it yet. Luckily, it was pretty straight forward.
Some quick research shows that [29]iCloud File Sharing can generate a
public Share Link.
d69b081b8b7300b9da7fe35cb6fdaad1.png
Creating a public iCloud Share Link
These Share Links look something like this:
[30]https://www.icloud.com/iclouddrive/01fooriERbarZSTfikqmwQAem
Simply replacing "https" with "icloud-sharing" is all that's needed to
have Safari automatically open ShareBear with this file as a
parameter.
evil.html
Great, so what does ShareBear do now? Some quick testing showed this
behavior:
sharebear.png
ShareBear Behavior Flowchart
There is a subtle, but wildly impactful, design flaw with this
behavior. Let's dig into what happens if the user has not opened this
file before. The user will be shown a prompt, similar to the one below.
propt.png
ShareBear Open Prompt
This innocuous little prompt, with the default value of "Open," seems
pretty straightforward. A user should expect to have the
image, example.png, opened if they agree. But in actuality, they are
agreeing to much more than that.
Once the user clicks Open, the file is downloaded onto the victim's
machine at the location /Users//Library/Mobile
Documents/com~apple~CloudDocs then automatically opened via Launch
Services. Then the user will never see this prompt again. From that
point forward, ShareBear (and thus any website in Safari) will have the
ability to automatically launch this file. The truly problematic part
of this agreement is that the file can be changed by anybody with write
access to it. For example, the owner of the file could change the
entire byte content and file extension after you agree to open it.
ShareBear will then download and update the file on the victim's
machine without any user interaction or notification.
In essence, the victim has given the attacker permission to plant
a [32]polymorphic file onto their machine and the permission to
remotely launch it at any moment. Yikes.
Agreed to view my PNG file yesterday? Well today it's an executable
binary that will be automatically launched whenever I want.
Apple fixed this behavior in [33]macOS Monterey 12.0.1 as a result of
my report without issuing a CVE because it is more of a design flaw
than a bug per-se.
Bonus Bug: Iframe Sandbox Escape
While fuzzing the icloud-sharing://scheme, I stumbled upon a fun bug
unrelated to the UXSS hunt. ShareBear appears to check the path of the
URL for "/iclouddrive/*" before performing the behavior outlined above.
If the path happens to be "/photos/*" then ShareBear makes a pretty
silly mistake. It will tell Safari to open a new tab pointing to the
iCloud web app... but it does not verify that the domain name is
actually the iCloud web app.
Quarantine and Gatekeeper
Quick reminder of where we are -
Our website can prompt the user to open a shared PNG file. If the user
agrees, we can automatically launch this file at any point in the
future, even after we alter the file content and extension.
Shortcuts
The above technique to open local apps is reminiscent of an
old-school [34]symlink attack. It basically just uses a "[35]shortcut"
to trick software into opening something it doesn't expect.
Lots of different operating systems and applications have reinvented
the wheel over the years when it comes to shortcuts. Nowadays, the term
"shortcut" could be referring to a Unix symlink, a macOS alias, a
Window's linkfile, a Safari webloc, an Edge bookmark, etc.
I was hopeful that I could use this technique to bypass Gatekeeper and
open a webarchive file. This idea seemed promising to me because the
actual application I want to open is Safari (an existing, approved,
application). Gatekeeper doesn't have a problem with me launching
Safari, it just gets upset when I attempt to open any file ending in
".webarchive".
So I needed to find a shortcut filetype that launches Safari, then
tells Safari to open a different file. After some trial and error, I
found just that - the ancient [36]Windows URL File!
Full Chain
Using ShareBear to download and open a webarchive file for us can be
broken down into 3 steps:
Conclusion
This project was an interesting exploration of how a design flaw in one
application can enable a variety of other, unrelated, bugs to become
more dangerous. It was also great example of how even with macOS
Gatekeeper enabled, an attacker can still achieve a lot of mischief by
tricking approved apps into doing malicious things.
I submitted these bugs to Apple in mid July 2021. They patched all
issues in early 2022 and rewarded me $100,500 as a bounty
References
1. https://www.ryanpickren.com/safari-uxss
2. https://storage.googleapis.com/pub-tools-public-publication-data/pdf/f5a8289d4f69e9e34b38a1e7c05ef4818b22cd5b.pdf
3. https://zoom.com/
4. https://paypal.com/
5. https://gmail.com/
6. https://www.ryanpickren.com/webcam-hacking
7. https://static.wixstatic.com/media/149864_ec31bf9c57244f2c9c45113067800963~mv2_d_1954_1420_s_2.png/v1/fill/w_1510,h_1096,al_c,usm_0.66_1.00_0.01/finaldiagram.png
8. https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants
9. https://en.wikipedia.org/wiki/Webarchive
10. https://www.rapid7.com/blog/post/2013/04/25/abusing-safaris-webarchive-file-format/
11. https://www.rapid7.com/blog/post/2013/04/25/abusing-safaris-webarchive-file-format/
12. https://www.cultofmac.com/675928/how-to-stop-safari-asking-permission-to-download-everything/
13. http://vttynotes.blogspot.com/2011/03/safari-errorjacking-cve-2011-0167.html
14. http://joevennix.com/2015/06/24/Adventures-in-Browser-Exploitation-Part-II-Safari-8-UXSS.html
15. http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html
16. https://en.wikipedia.org/wiki/Gatekeeper_(macOS)
17. https://www.ryanpickren.com/webcam-hacking
18. https://en.wikipedia.org/wiki/List_of_URI_schemes#Official_IANA-registered_schemes
19. https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app
20. https://github.com/phynet/iOS-URL-Schemes
21. https://ios.gadgethacks.com/how-to/use-google-maps-waze-with-siri-instead-apple-maps-0192301/
22. https://grepharder.github.io/blog/0x03_learning_about_universal_links_and_fuzzing_url_schemes_on_ios_with_frida.html
23. https://www.cvedetails.com/cve/CVE-2013-6835/
24. https://www.bitcoininsider.org/article/29392/i-give-you-working-exploit-stable-chrome-mac
25. https://bugs.chromium.org/p/project-zero/issues/detail?id=1040
26. https://conference.hitb.org/hitbsecconf2017ams/materials/D2T2 - Yu Hong - Attack Surface Extended by URL Schemes.pdf
27. https://i.blackhat.com/eu-20/Thursday/eu-20-Zhou-Cross-Site-Escape-Pwning-MacOS-Safari-Sandbox-The-Unusual-Way.pdf
28. https://developer.apple.com/documentation/coreservices/launch_services
29. https://support.apple.com/guide/mac-help/share-files-with-icloud-file-sharing-mchl91854a7a/mac
30. https://www.icloud.com/iclouddrive/01fooriERbarZSTfikqmwQAem
31. http://www.icloud.com/iclouddrive/01fooriERbarZSTfikqmwQAem"
32. https://en.wikipedia.org/wiki/Polymorphic_code#Malicious_code
33. https://support.apple.com/en-us/HT212869
34. https://capec.mitre.org/data/definitions/132.html
35. https://en.wikipedia.org/wiki/Shortcut_(computing)
36. http://www.lyberty.com/encyc/articles/tech/dot_url_format_-_an_unofficial_guide.html