You’ve probably already heard about protocol handlers (sometimes referred as pseudoprotocols). Every time you open Atom from browser, you’re using atom:// url, which is a protocol handler. You can read more about protocol handlers on MDN.
Some protocol handlers are available on OS level: like xcode:// and itms:// in macOS.
- Slack disclosed on HackerOne: OSX slack:// protocol handler...
- Researchers: Steam URL protocol can be abused to exploit game vulnerabilities
- Apple iTunes itms:// URL Protocol Handler Remote Arbitrary Code Execution Vulnerability
I strongly recommend you to read this post about help:// disk:// and afp:// protocols which allowed to make terrible things through browser. Also, note that this post was written in 2004 — 14 years ago.
As you see, protocol handlers are popular in security.
Applescript:// URL 🍎
In macOS, there is applescript:// protocol handler which invokes “Script Editor” app.
“Script Editor” comes with default macOS setup. The purpose of “Script Editor” is creating scripts for automation using AppleScript language. In some sense, AppleScript is similar to Visual Basic in Windows.
The most interesting thing is that you could navigate to applescript:// to open/focus “Script Editor”.
Downloads in Chrome
Chrome cares about users and protects them from downloading dangerous files (shame on you, Safari). Bypassing downloads protection is even distinguished in Chrome Reward program in own topic. Files with extensions .py .sh .dmg (and many other) are treated as dangerous by default. Different files have different dangerous levels, like ALLOW_ON_USER_GESTURE DANGEROUS and so on. You can see the full list of extensions here.
Note that dangerous level of file extensions depends on OS.
However, Chrome doesn’t treat .applescript and .scpt file extensions as dangerous and automatically downloads these files without warnings.
Script Editor handles .applescript files in macOS by default.
When you open downloaded .applescript file, this file opens in “Script Editor”.
It’s irrational for user to run a downloaded script in “Script Editor”. So, the fact that Chrome downloads .applescript file without warnings couldn’t be considered as a security issue.
NOTE: However, Chrome offers a bounty for such findings, according to their bug tracker. You could find more such bugs by searching for “Download protection” in Chrome tracker.
Note that Script Editor runs scripts on “Cmd + R”.
Let’s summarize 🗒
As of now, we know:
- Chrome could download .applescript file without warning message.
- “Script Editor” could be opened/focused by navigating to applescript://.
- MacOS opens .applescript files in “Script Editor” by default.
- It’s possible to run a script using “Cmd + R”.
It seems impossible to execute a downloaded script without user’s notice.
CVE-2018–6095 and user interaction ⌨️
Sometimes specific user’s gestures could lead to vulnerability:
- Web page asks for “Enter“ keypress.
- User starts pressing “Enter”.
- Click on <input type="file" webkitdirectory> initiated by web page.
- User continues pressing “Enter” by inertia.
- “Downloads” directory gets uploaded to attacker.
Do you catch what we need to execute downloaded .applescript file? Yeah, keyboard events.
FYI: this bug was patched in Chrome, but some browsers continue being vulnerable 😉
Attack scenario ☠️
It works best with XSS on any “trusted” resource or with URL spoofing. In this case, attacker is sure that user interacts with the exploit in “right” way.
- User visits a web page.
- Web page asks to make “Script Editor” as the default handler for applescript:// and opens new applescript:// window.
- Web page downloads exploit.applescript or exploit.scpt (scpt looks less dangerous).
- User opens the file from “Downloads” toolbar. Chrome lose focus, “Script Editor” obtains focus.
- Web page initiates alert() or any other focusing action to make Chrome focused again.
- At this point, we’ve got “Script Editor” with opened exploit file and focused Chrome.
- We could ask user to press “Cmd + R” and init navigation to applescript:// on “Cmd” keypress. As a result, “Cmd” keypress and “R” keydown get interpreted in “Script Editor”.
- Downloaded exploit.applescript file executes in “Script Editor”.
Attacker could trick user to execute downloaded malicious file with user-level privileges outside of Chrome by leveraging intuitive user gestures.
- This vulnerability exists only in Chrome.
- It couldn’t be completely fixed just by preventing automatic download of .applescript files.
- That means any new download protection bypass makes this vulnerability actual again.
Exploit’s weak sides
That’s obvious that this attack requires some user interaction. However, don’t think that it’s still impossible to implement this, and user interaction makes this vulnerability non-interesting. Executing file through browser can’t be non-interesting.
User should allow `applescript:` urls open “Script Editor” by default
Not a big deal.
Let’s assume this!
It’s not wrong to make a small assumption. Moreover, it’s ok to assume something if it leads to RCE outside of Chrome 😉.
Website could say that AppleScript is “Flash for Mac” and ask to enable it. This trick looks logical enough.Social engineering || one more vulnerability
It’s simple to trick user and obtain this permission. Most users don’t have tech background and don’t care what’s going on inside their browser. For most people, this is yet another black-box.
Imagine, attacker has XSS on facebook.com or URL spoofing vulnerability in Chrome. It’s really easy to trick user and get required user interaction.
Non-tech users don’t care why FB wants access to applescript:// or other resources.
Trusted site wants access to <something>? OK.Phishing is considered as one of the most significant security problems in the world. Just read “Phishing” on wiki, and you’ll find out many interesting things you even couldn’t assume.User has to open a file using “downloads” toolbar
However, Chrome treats exploit.applescript as non-dangerous. Additionally, “Script Editor” is the default handler for .applescriptand .scpt file extensions, so the only required action is to press the file’s tab in “downloads” toolbar.
When was the last time you opened non-dangerous downloaded files through Finder instead of Chrome’s toolbar on your Mac? I’m sure, you can’t recall.User has to press Cmd + R
That’s not a problem too. Cmd + R is known as a hotkey for refresh. We could force user to reload the page using Cmd + R. (e.g., by hanging browser and waiting for keyboard events, sure that it’s possible).
Note: this part was simplified in PoC exploit, so you need to press “CMD” + hit “R” twice. However, it’s possible to develop more “intuitive” keypress handler.Also, let’s forget for a moment that “Cmd + R = page refresh”. What type of web apps sometimes requires strange keypresses from you? Games is a real-world example of such applications. I’m sure that it’s possible to find at least 10 examples, where page asking for specific keypresses looks logical for users.
Response from Chrome security team
I contacted Chromium team about this bug ~2 days ago. That’s almost immediate resolution for security report.
You can find the link to the report below:
The actual response:
Given that the the exploit scenario is very-high-touch social engineering that would work regardless of what Chrome can do, I think marking the additional extensions as dangerous is all we can do about this bug. I’m going to track it as a security feature request, not as a vulnerability.
I disagree with this, and that’s why:
No automatic download = No vulnerability
The fact that Chrome treats .applescript as dangerous is the fact that this vulnerability patched and can’t be reproduced without additional vulnerabilities.
Attacker can’t trick user if browser shows “This file could harm your device” warning during download. Otherwise, it’d be irrational.
No automatic download != No vulnerability
This attack scenario could be accomplished again if download protection bypassed.
I know a trick for this, but let’s keep it for another post 😉
That means this vulnerability is exploitable until some additional fixes except marking .applescript file extension as dangerous, will be implemented. For example, blocking applescript:// or disabling an option to set “Script Editor” as the default handler for applescript:// should works well. And I’m sure that it’s possible in Chromium.
How is it possible to execute “safe” file using 2 keypresses in browser and file opening?That’s possibly the main argument.
Just give me one example, when user could execute downloaded malicious code…
- Without leaving browser: “Script Editor” opens silently for user, user only interacts with Chrome.
- By opening “safe” file: there are no similar “safe” files, that could be executed in Chrome without an extension with certain permissions.
- And pressing 2–3 keys: user could press any keys in Chrome, but it can’t lead to file execution by default.
- Moreover, no errors and warnings should be shown during steps 1–3.
I bet you’ll not find any similar cases or examples, or even theoretically possible examples.
I’ve found only one similar case when MS Edge on Win10 allows to open apps using microsoft-edge protocol without asking a user. However, the author didn’t show any working RCEs.Similar bugs from Chrome trackerThis topic makes me angry.
I was researching browser security for a long time, and even “collected” DB with exploits for different browsers vulnerabilities. So, let’s compare described above bug with some low-severity vulnerabilities I found in Chrome tracker:
- .as files should be downloaded only by user’s gesture — 2k$, valid vulnerability.
- URL spoofing with Cyrillic symbols (spoof twitter.com withтшіттег.com)— 500$, valid vulnerability.
- Can open chrome:// urls from devtools (!)— 0$, assigned CVE-2018–6112
- (This post) Malicious file could be silently executed by opening it from “Downloads” toolbar with some user interaction — not a vulnerability at all, that’s a “security feature request”.
I hope, you agree with my opinion that marking those bugs as vulnerabilities and ignoring the attack described in this post isn’t correct.
“All we can do.”
First of all, let me clarify that I don’t have anything against Chrome security team (except resolution status of this bug). I think that they are professional coders, hackers, and researchers (that’s evident from how cool is Chromium!). Their understanding of Chrome security architecture is much deeper than my or somebody else’s.
However, I think that renaming report’s title from “Silently execute downloaded AppleScript file using Chrome”, to “Mark additional AppleScript file extensions as dangerous” is not fair, because:
- That makes it less possible to find this report in the bug tracker for other security researchers, who’re searching for logic flaws in Chrome.
- This attack could be accomplished even when a file has ALLOW_ON_USER_GESTURE dangerous level. [additional “download protection bypass” or high level of user’s “trust” required]
- I absolutely agree that bug tracker isn’t a suitable place for beautiful but misleading titles. However, renaming it to “Mark AppleScript files as dangerous to prevent opening Script Editor” or “Mark AppleScript files as dangerous to prevent code execution in Script Editor” is more declarative and fair, from my opinion.
The report was made public immediately after the initial response so that it couldn’t be qualified as a security bug anymore. I couldn’t even advocate why it is a vulnerability, or say that it’s a valid download protection bug, because it’s already public.
Personally, I still consider it as significant vulnerability even with user interaction.
If you check some issue in Chrome bug tracker, you could see that in most reports researcher could advocate why this bug should be considered as a vulnerability or attach additional improved PoC after the initial response from the security team. (e.g., CVE-2018–6112 or CVE-2016–5218)
Safari shows an alert every time navigation to applescript:// occurs. So, there is no way to execute AppleScript in Safari silently.
It looks like there is no automatic silent download in Firefox for .applescript files. So this attack doesn’t work in Firefox too.
That means Chrome is the only vulnerable browser. From my point of view, that’s an additional factor that makes this bug a complete vulnerability.
Chrome team is right, you’re wrong!
Chrome VRP guidelineQ: Will Google reward for bugs that are not specifically listed in the table above?A: Yes — we’re interested in rewarding any information that enables us to better protect our users…
In some sense, yeah. Chrome isn’t responsible for a user who runs malicious downloaded files outside of Chrome. However, this is obviously not a similar case.
Why I wrote this post
I wrote this post primarily for 2 reasons:
- To share my opinion that resolution of this bug is incorrect. From my point of view, it’s a vulnerability.
- To illustrate such a non-standard way of executing malicious script through browser.
If you saw similar vulnerability somewhere, please, share it in comments.
Personally, I think that it’s not a standard technique. That’s not a typical UaF/BoF in rendered or UXSS using timers + history API or frames detach.
It’s a combination of multiple low-severity bugs that could compromise device with comparatively little interaction from a user.
Additionally, this attack doesn’t consume much memory, doesn’t crash a browser and could be actively used in real-world.
Assumptions are anywhere
You can find tons of attack scenarios from valid security reports, in which users have to paste something in address bar to compromise themselves, or stay for a long time on the same page (like this new CSS attack), or malicious extension installation assumed, or users have to drag&drop a link to the specific element and so on. I think that assumptions in these attacks are equal or greater to assumptions in “my” attack.
The downloaded file is safe for Chrome. Additionally, opening a “safe” file from “downloads” toolbar and pressing “Cmd + R” are intuitive actions.
That’s not a non-typical behavior, like drag&drop another tab to the iframe on a webpage ignoring the fact that page suddenly starts loading (some CVE involving tabs DnD to obtain info from another origin).
Note: I strongly recommend you to search for drag&drop URL spoofing vulnerabilities. There are at least 50 examples of such bugs in different browsers, and a big part of this bugs typically have one or more assumptions.
The only required non-typical action — allowing to open “Script Editor” from applescript:// by default. I’ve probably already repeated my arguments on this, so let’s move to another interesting topic.
Security should always assume that users don’t know what they do. Assumptions are ok.
Browser security is completely underestimated
BountiesReddit users agree that Google pays too low for browser security. https://tinyurl.com/y8ort2qj
You submit XSS in Google service and get from 3113$ to 7500$ (or even more).You submit UXSS in Chrome and get 7500$ in the best case.UXSS = Same-Origin-Policy bypass
Imagine, an attacker could get cookies from all pages you’ve visited, register own ServiceWorkers, embed Beef hooks, and make other funny things.
Just realize, that UXSS that compromises millions of Chrome users is considered at least equal to XSS in one of Google’s services.
As far as I remembered, one XSS on accounts.google.com was estimated in 13k$. Max bounty for UXSS is 7500 + 1337 for patch, assuming report includes a PoC and explanation.
Chrome browser installed on millions or even billions of devices isn’t as valuable for Google as their services and platforms.
Just compare Google to some companies on Hackerone (e.g., Uber). Yeah, these companies pay more than Google for vulnerabilities affecting only their services&reputation and nothing more.Nobody cares about your browserhttps://tinyurl.com/y8ort2qj Even if it sounds “crazy”, it makes sense
I hope, it’s obvious now, that Google underestimates browser security. Google should sometimes recall that Chrome has almost 65% global market share.
Instead, they’re offering a big bounty (100k$) for ChromeOS which global market share is even hard to figure out (approximately 0.5–0.6%).
Note, that I didn’t say that Google doesn’t care about security. Google cares but in some ridiculous way.
Chrome security team and Project Zero work well. Low bounties possibly could be explained by Google’s approach to rely only on internal teams.
However, you can check found CVEs during any Chrome release, and find out that independent researchers and project members(not employees) report many (or even most) issues. So, low bounties can’t be explained by approach to rely on internal research only.
Apple doesn’t need to help somebody hack you, because they already helped
Do you remember that case, when Apple rejected to help FBI in bypassing Touch ID? That’s a good PR move only.
Why it’s a PR move only? Because, Google Project Zero’s member (lokihardt) has found (at least) 22 UXSS during 2016 Dec — 2017 Mar. Some of them were regression tests, like CVE-2017–2508.
CVE-2016–6755 = CVE-2017–2508 = regression test
That means, developers have known that this vulnerability was patched only in Chrome, and the problem has been persisting in Safari for more than 1 year until Project Zero found it during research.
Another good example is CVE-2017–2364. I bet that it was found or even used before Project Zero’s audit because it’s very simple to exploit compared to other vulnerabilities.
Apple doesn’t care
Let’s note that Apple doesn’t have a bug bounty program for Safari(Webkit). As opposite to Google, which has bug bounty programs, Apple probably wants from hackers to submit their research directly to “black market”.
So, all these posts and news about how much Apple cares about users privacy and security are just myths. Additionally, it could be proofed by comparing the number of CVEs in iOS/MacOS/Webkit with CVEs in Android/Chrome in last few years. You possibly already have seen such comparisons.
Even Firefox has Web and Browser bug bounties. However, Mozilla Foundation is a non-profit organization, not a 1 trillion dollars company.
- It’s possible to execute Applescript through Chrome: applescript:// + “Script Editor” + Chrome window re-focus + "safe download” of .applescript + keypresses.
- Yes, it requires some user interaction, but it’s still a valid vulnerability.
- Google’s security team said that my report is a security feature request and this problem has zero impact.
- I wrote this post and described my arguments on this. I continue to think that this attack should be qualified as a valid vulnerability.
- Chrome continues being vulnerable to this attack scenario until Chrome 69 will be shipped as stable(Jul 19th, 2018).
- Apple doesn’t care about browser security as much as should.
In some sense, Google and Apple are the main creators of “black market”.Some folks said that browser vendors want to have 0-days in their products. Do you think it makes sense? 😉
Thanks for reading 😈
Live PoC: https://chrome-applescript.now.sh
Other exploits: https://github.com/Metnew/uxss-db
Report in Chrome tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=850261
Sorry for mistakes and typos if any.
I give you a working exploit for stable Chrome on Mac was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.