Remote Mac Exploitation Via Custom URL Schemes

an offensive cyber-espionage campaign infects macs with a novel infection mechanism







Love these blog posts? You can support my tools & writing on patreon :)

Background

In recent blog posts we've discussed vulnerabilities or flaws in macOS that allow malicious code to perform all sorts of nefarious actions such as: bypassing SIP, approving kernel extensions, dumping the keychain and much much more! However, exploiting these flaws all require that the malicious code has (somehow) already gained initial code-execution on the targeted system. In other words they are local attacks, which generally would be used in the 2nd-stage of an offensive cyber operation.Today, we discuss a remote attack that malware has been leveraging as a means to gain initial access to fully patched macOS systems. This 1st-stage attack, when coupled with the various aforementioned 2nd-stage attacks could create an elegant, yet damaging attack against macOS.

Note:

This attack, though remote, requires some user interaction(s).



However it has already proven successful against security conscious macOS targets. In other words, handle with care!

WINDSHIFT APT is an obscure cyber espionage actor, discovered recently targeting individuals working at a government. This actor has a dedicated and advanced spear phishing infrastructure, able to serve spear phishing emails and SMS to track individuals continuously during the reconnaissance phase, and deceiving targets during the credentials harvesting phases through the impersonation of global and local platform providers.

What makes WINDSHIFT APT different from the rest of APT actors is their sole focus on specific individuals for espionage and surveillance purposes and their very hard to attribute Modus Operandi (MO) that we will present during this talk. WINDSHIFT APT rarely engage targets with malware, Dark Matter LLC uncovered very few targeted attacks from this actor and was able to uncover and analyze macOS malwares used. Finally, WINDSHIFT APT have unique macOS infection tricks abusing macOS native functionalities to automatically spread malware to targets.

On August 30th, at Hack in the Box GSEC , Taha Karim (of DarkMatter, LLC), presented "The Trails of WINDSHIFT APT" . His abstract:One of the intriguing aspects of the talk was the initial infection vector that the attackers (ab)used to successfully remotely infect Mac systems of governments somewhere in the Middle East.

Note:

My aim of this blog post isn't to simply regurgitate Taha's excellent talk.



Instead let's build off it and dive a little deeper into the infection mechanism of the malware:

■ discussing some relevant macOS internals

■ provide some proof of concept code snippets

■ discuss mitigations of this remote attack

Document Handlers & URL Schemes

In a nutshell, the

WINDSHIFT

foo

bar

APT abuses custom URL schemes to remotely infect macOS targets. Although user interaction is required, it is minimal and can be "influenced" by the attacker. Moreover, the fact that this infection vector has succeeded in the wild (against government targets in the Middle East), conclusively illustrates that such interactions are not a "show stopper".On macOS, applications can "advertise" that they can support (or 'handle') various document types and/or custom URL schemes. Think of it, as an application saying,You've surely encountered this on macOS. For example when you double click a

.pdf

document

Preview.app

is launched to handle the document. Or in a browser you click a link to an application which lives in the Mac App Store, the

App Store.app

is launched to process that request.Unfortunately the way Apple decided to implement (specifically, "register") document handlers and custom URL schemes, leaves them ripe for abuse!

Note:

Though document handlers and url schemes are slightly different, from an OS point of view, they are essential the same (and thus implemented in similar manners).

Let's first take a quick look at document handlers, as this is something I've researched and blogged about before.In a previous blog post, "Click File, App Opens" I analyzed a piece of adware,

Mac File Opener

that abused custom document handlers as a stealthy way to achieve persistence. In short, as the malware "advertised" that it supported over 200 types of files, whenever the user opened one of these file types, the malware would be automatically launched by the OS to handle (in theory to display) the document. Persistence with a twist!

Note:

If there is already an application registered for a file type (e.g. .pdf, .html, etc), this (AFAIK) cannot be usurped.

Of course the first question was, how did the

Mac File Opener

adware (or any application for that matter of fact) "advertise" which files it supported (and thus should be invoked when such a documented was accessed by the user). And secondly, how does the OS process and register this information? I recommend reading the blog post as the answers to both questions are covered in great detail. But, we'll briefly summarize it here as well.So how does an application tell the OS what type of files it is capable of handling? The answer is in it's

Info.plist

file. As noted,

Mac File Opener

supports over 200 file types, which we can see by dumping its

Info.plist

In the 'raw' plist, this information is stored in an array (key:

CFBundleDocumentTypes

"CFBundleDocumentTypes (Array - iOS, OS X) contains an array of dictionaries that associate one or more document types with your app. Each dictionary is called a type-definition dictionary and contains keys used to define the document"

). Apple states:Below, we see

Mac File Opener

's entry for the file type

.7z

(7Zip). Note the

CFBundleTypeExtensions

$ cat "Mac File Opener.app/Contents/Info.plist"

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>BuildMachineOSBuild</key>

<string>14F27</string>

<key>CFBundleDevelopmentRegion</key>

<string>en</string>

<key>CFBundleDocumentTypes</key>

<array>

<dict>

<key>CFBundleTypeExtensions</key>

<array>

<string>7z</string>

</array>

<key>CFBundleTypeName</key>

<string>DocumentType</string>

<key>CFBundleTypeOSTypes</key>

<array>

<string>????</string>

</array>

<key>CFBundleTypeRole</key>

<string>Viewer</string>

<key>LSHandlerRank</key>

<string>Alternate</string>

<key>NSDocumentClass</key>

<string>Document</string>

</dict>



key, whose value is set to the file extension the adware claims to handle:To answer the second question, we need to determine how macOS handles the "registration" of these file, or "document" handlers. As noted in the "Click File, App Opens" this happens automatically! And when does this occur? As soon as the application is saved to disk! Specifically (to summarize):■ An application (or malware) is downloaded or saved to the file system■ This triggers an

XPC

message sent to the launch services daemon (

lsd

■ The

lsd

# fs_usage -w -f filesystem | grep Info.plist

open /Users/user/Desktop/Mac File Opener.app/Contents/Info.plist lsd.16457

fstat64 F=4 lsd.16457

read F=4 B=0x18a97 lsd.16457



# /usr/libexec/lsd

...



(lldb) po $rsi

<LSDatabase 0x7fe66183e600>{ path = '/var/folders/np/85lyz_4545d5lz8wvy04xvlm0000gn/0//com.apple.LaunchServices-134501.csstore' }



daemon parses the application, to extract and save its 'document handlers' to a persistent database.We can dump

lsd

's database via the

lsregister

(found in

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/

). When invoked with the

-dump

flag, it will displaying all applications that specify 'document handlers', which were automatically registered (by

lsd

). For example, we can see the malicious application,

Mac File Opener

is present, along with the documents (file types) it registered for (e.g.

.7z

$ lsregister -dump

...

Container mount state: mounted

bundle id: 2592

Mach-O UUIDs: 88225C07-0FDC-3875-A3B4-C5328E509B9E, 20A99135-975D-3A7B-A8DD-B7DF2CE428D0

path: /Users/user/Downloads/Mac File Opener.app

name: Mac File Opener

identifier: com.pcvark.Mac-File-Opener (0x80025f61)

executable: Contents/MacOS/Mac File Opener

--------------------------------------------------------

claim id: 31508

name: DocumentType

rank: Alternate

roles: Viewer

flags: doc-type

bindings: .7z

...



, etc):Once an application (or adware's) document handlers have been (automatically!) registered that application will be automatically invoked anytime a user attempts to open a document whose type matches a registered handler.This is handles by the

launch services framework

. Specifically the

_LSBundleCopyOrCheckNode

method (and

_LSBundleCopyOrCheckNode_block_invoke

(lldb) b ___LSBundleCopyOrCheckNode_block_invoke

...

(lldb) x/gx $rdx

0x700000115c48: 0x00007fd3b4a9c520

(lldb) po 0x00007fd3b4a9c520

<FSNode 0x7fd3b4a9c520> { flags = 0x00000020, path = '/Users/user/Desktop/Mac File Opener.app' }



) handle this lookup (of matching a document type to a registered application) and then execution of registered application:

Recap:

■ Applications can "advertise" that they handle various documents or file types

■ The OS will automatically register those "document handlers" as soon as the app hits the disk

■ As files are opened, the "launch services" database is consulted to execute the appropriate app

Ok, so that's "document handlers"... time to discuss custom URL scheme handlers! Again, from macOS's point of view, such url scheme handlers, are basically just document handlers...but for urls!Which also means custom URL scheme handlers:■ are registered automatically by macOS as soon as application (that "advertises" support for such handlers) hits the file-system■ will trigger the execution of the (automatically registered) handler application, when the custom url scheme is invokedAs both of these actions can be triggered from a webpage, it should be easy to see where this all goes wrong!I've previously talked about custom URL schemes at Hack in the Box 2017 (see: "Oversight: Exposing Spies on macos" ).However this was this was not in the context of malware nor exploitation.Since I don't (yet) have access to the

WINDSHIFT

malware samples, I wrote my own proof of concept to illustrate how an attacker could abuse custom URL scheme handlers to remotely infect a Mac (noting again, some user interaction is required).We start in Xcode, with the Cocoa App template:The logic of the application is irrelevant, however we must edit the app's

Info.plist

file to "advertise" that fact that we will support a custom URL scheme. In Xcode, we add a

URL types

array and specify the name of our scheme (

windshift://

) and a URL identifier:Examining the raw plist illustrates this maps to keys such as

CFBundleURLTypes

CFBundleURLSchemes

, and

CFBundleURLName

<key>CFBundleURLTypes</key>

<array>

<dict>

<key>CFBundleURLSchemes</key>

<array>

<string>windshift</string>

</array>

<key>CFBundleURLName</key>

<string>com.foo.bar.WindShift</string>

</dict>

</array>



As soon as this application is compiled (or downloaded!) the launch services daemon will parse its bundle (specifically its

Info.plist

), detect the presence of the custom URL scheme handlers, and register it (them). Again, note this all happens automatically!To confirm, dump the 'launch services' database (via

lsregister -dump

). Yups, there is our proof of concept application (

WindShift.app

) along with our custom URL scheme (

CFBundleURLSchemes: (windshift)

--------------------------------------------------------------------------------

BundleClass: kLSBundleClassApplication

Container mount state: mounted

bundle id: 168204

Mach-O UUIDs: E2E77A08-F458-36C1-B7BD-99F409B4DEAC

Device Familie

Counterpart ID

sequenceNum: 168204

FamilyID: 0

PurchaserID: 0

DownloaderID: 0

installType: 0

appContainer: #

dataContainer: #

path: /Users/patrick/Projects/WindShift/DerivedData/WindShift/Build/Products/Debug/WindShift.app

name: WindShift

....

executable: Contents/MacOS/WindShift

....



CFBundleURLTypes = (

{

CFBundleURLName = "com.foo.bar.WindShift";

CFBundleURLSchemes = (

windshift

);

}

);

}





claim id: 386204

name: com.foo.bar.WindShift

rank: Default

roles: Viewer

flags: url-type

icon:

bindings: windshift:





):If we now hop over to a browser (let's go with

Safari

), and "browse" to our custom URL scheme,

windshift://

Remote Exploitation

, we can confirm that the custom url scheme was automatically registered:If we click "Allow" (more on this alert later!), the application will be launched!If you're somewhat 'evil' minded (or watched Taha talk!) you probably see where this is going. We're going to now describe a method to remotely target (and ideally infect) Mac users, by (ab)using custom URL schemes.First, we're the target must browse to a website we control. The

WINDSHIFT

APT group (successfully) used phishing emails.Once the target is visits our malicious website, we trigger the download of an archive (

.zip

) file that contains our malicious application. If the Mac user is using

Safari

window.location.replace('windshift://');





Normally an applications cannot have a extension such as .txt or .com .



However, as the name of the application can contain unicode characters, we can leverage a



This allows us to name the malicious application something like Attachment.TXT (where the 'X' is really the Carian Letter X). Note:Normally an applications cannot have a extension such asorHowever, as the name of the application can contain unicode characters, we can leverage a homograph attack.This allows us to name the malicious application something like(where the 'X' is really the Carian Letter X).

, the achieve will beunzipped, as Apple thinks it's wise to automatically open "safe" files. This fact is paramount, as it means the malicious application (vs. just a compressed zip archive) will now be on the user's filesystem, which will trigger the registration of any custom URL scheme handlers! Thanks Apple!Now that the malicious app's custom URL scheme are registered (on the target's system), code within the malicious webpage can load or "browse" to the custom url. This is easy to accomplish in JavaScript:Behind the scenes macOS will lookup the handler for this custom URL scheme -which of course is our malicious application (that was just downloaded). Once this lookup is complete, the OS will kindly attempt to launch the malicious application to handle the URL request!Luckily (for Mac users) the most recent versions of Safari this will trigger a warning:However the characters between the quotation marks are attacker controlled, as they are the name of the application Thus, we can easily make this popup look rather mundane, unintimidating, or even amusing:While recent versions of

Safari

will prompt the user before launching an the application that has been registered to handle custom URL requests, older version of Safari (e.g default install on El Capitan) do not! Instead, such versions of Safari show no warning and blindly attempt to launch the (malicious) application!Regardless of Safari version, we have one more hurdle: File Quarantine.File Quarantine is responsible for the popup that is displayed anytime you execute an application that is downloaded from the internet:The good news is that some percentage of Mac users will click

Cancel

. The good news is that some percentage of Mac users will click

Allow

(which was confirm by Taha, who noted in his talk that the

WINDSHIFT

APT was successful in leveraging this attack vector).Also, we still control the name of the application, so perhaps can increase the likelihood of users clicking 'Allow' ... maybe by adding emojis!?

Note:

You might be wondering about Gatekeeper??



In its default configuration, Gatekeeper allows signed applications. The malware used by the WINDSHIFT APT group was signed (as is most Mac malware these days). So Gatekeeper doesn't even come into play!

Conclusion

Before wrapping this all up, I made a diagram to illustrate the steps of this "custom URL scheme handler" attack:It's not everyday that we see APT groups targeting Mac users. And even less common does such malware leverage rather novel infection vectors. However, we'd be naive to think that Mac users are safe from such threats, as the

WINDSHIFT

APT group has clearly illustrated!In this blog post we discussed features of macOS such as document handlers and custom URL scheme handlers and showed how they're (actively) abused by malware. Luckily, such attacks (especially on modern versions of macOS) require some user interaction. However, both have proven successful in the wild, so if you're looking for a decently reliable way to infect Mac users....And if you're a Mac user concerned about security, use Google Chrome:If you are stuck with Safari, at least turn off the automatic unzipping of downloaded files, as the registration of the (malicious) custom URL scheme handlers is only triggered when the application is unzipped!To turn this off, open Safari's preference, then in the

General

tab, uncheck the option

Open "safe" files after downloading



Love these blog posts & tools? You can support them via patreon ! Mahalo :)

):Also, it can't hurt to set Gatekeeper to only allow apps from the Mac App Store (and then selectively and carefully allow external 3rd-party applications as needed)!