DEF CON 25 Patrick Wardle Death By 1000 Installers on macOS and it's all broken!

Summary

Highlights

• Patrick Wardle reveals the systemic issues in macOS installers leading to privilege escalation. 🚀
• Malware exploits include spoofing pop-ups and modifying installer scripts to gain root access. 🐛
• Authorization execute with privileges function lacks verification, leaving systems vulnerable. 🔓
• Examples include popular apps like Chrome and VMware exploiting these vulnerabilities. 🤯
• Wardle emphasizes caution as these issues are more about social engineering than technical flaws. 🤔

Key Takeaways

• Privilege escalation exploits vulnerabilities in macOS installers and updates. 😱
• Malware often forges authentication prompts to gain user credentials. 😲
• Authorization execute with privileges function is widely used despite security flaws. 🛑
• Non-privileged code can modify privileged execution paths due to lack of verification. 🚨
• User caution is advised when encountering authentication prompts. ⚠️

Overview

Chapters

• 00:00 - 00:30: Introduction and Overview The chapter titled 'Introduction and Overview' begins with Patrick Wartell introducing himself. He discusses his role as the chief security researcher at Cenac, a company that specializes in crowdsourced vulnerability discovery. The company works with vetted security researchers to identify vulnerabilities in web apps, mobile apps, and IoT devices. Patrick encourages interested individuals to sign up as freelance researchers to find vulnerabilities and get paid for their efforts. The chapter sets the stage for a session promising to cover a variety of interesting topics.
• 00:30 - 01:00: Privilege Escalation on macOS This chapter explores the concept of privilege escalation on macOS systems. It begins by examining applications running with user-level privileges that need to perform more privileged actions. The focus is on the core issues that arise during this temporary escalation of privileges and how they lead to numerous bugs. The chapter delves into methods for identifying these bugs, presents real-world vulnerabilities, and concludes with practical exploit demonstrations. The primary goal is to provide a comprehensive description of achieving reliable privilege escalation on macOS.
• 01:00 - 01:30: Authentication Prompts and Vulnerabilities The chapter explores the process of privilege escalation, which is a critical step that malware often executes after gaining initial access to a system. Initially, malware operates in a restricted environment with the privileges of a regular user rather than having full control as a root user. The focus of the chapter is on step two of this process, which involves malware attempting to elevate its privileges to root level. This section will delve into methods and vulnerabilities related to privilege escalation and how attackers exploit these in cybersecurity contexts.
• 01:30 - 02:00: Exploiting Installers and Updates The chapter focuses on exploiting bugs and vulnerabilities within application installers and updates.
• 02:00 - 02:30: Authentication API and Behind the Scenes The chapter discusses actions that are privileged and commonly executed by installers or updaters, such as writing files to the system directory or updating a kernel extension, which need higher privileges. It also covers actions like Apple debugging or changing operating system settings, which may require reauthentication to grant higher privilege access. The narrator mentions encountering such privilege actions regularly.
• 02:30 - 03:00: Security Agent and Authentication Dialog The chapter discusses the behind-the-scenes process that occurs when an application, such as an installer, attempts to perform a privileged action. It highlights the initial invocation of an authentication API, which generates an IPC (Inter-Process Communication) message sent to an authorization daemon. This daemon refers to an authorization database, typically requiring re-authentication before permitting the action to proceed.
• 03:00 - 03:30: Abusing the Process and Issues This chapter discusses the process of how a user request for higher privilege actions is handled in a system. It explains how an application initiates a process to perform an action requiring elevated privileges by sending a message to a security agent. The security agent is then responsible for prompting the user for authentication. Once the user provides the correct credentials and they are validated, the application is allowed to execute the desired higher privilege action. The chapter takes a closer look at each step involved in this process, using an example of an installer application.
• 03:30 - 04:00: Mac Malware Examples and Threats In this chapter titled 'Mac Malware Examples and Threats,' the discussion revolves around a function, authorization execute with privileges. The function is described in terms of its operational mechanism, where a path is specified for execution with elevated privileges upon user authentication. The text explores the open-source nature of the function, describing how it internally uses exec V to execute a privileged system binary known as security_off_trampoline. This execution results in the sending of an X BC message, setting the stage for a deeper dive into potential vulnerabilities and misuse in the context of Mac malware threats.
• 04:00 - 04:30: Core Vulnerabilities and Race Conditions The chapter "Core Vulnerabilities and Race Conditions" discusses the security aspects related to authorization daemons and the handling of messages by system utilities. It particularly focuses on the process where the authorization daemon receives an authorization request (X BC message) and consults the authorization database. It highlights the role of system utilities like LS MP in monitoring these communications. The chapter also discusses the system's handling of admin privileges requests.
• 04:30 - 05:00: Finding and Exploiting Bugs This chapter discusses dumping an authorization database to find and exploit bugs. It focuses on how privileges are managed within an application, specifically how the authorization daemon processes requests to execute functions that require elevated privileges. The chapter highlights the role of the daemon in granting temporary privileges and mentions that a user must reallocate resources for this process to occur. An important technique is the use of ex PC messages, which are sent by the daemon to facilitate the reallocation and privilege granting.
• 05:00 - 05:30: Exploitable Bugs in Applications The chapter discusses how security measures in applications are designed to protect user passwords from being accessed by applications requesting higher privileges. It explains that the authentication dialog is displayed by a trusted system utility, the security agent, rather than the application itself. This design ensures that the application never has access to the user's actual password. The chapter also mentions the use of the LS app info utility to verify the security agent as the last process handling the authentication message.
• 05:30 - 06:30: Real-world Exploits and Tools The chapter discusses how real-world exploits and tools function, particularly focusing on authentication processes. It explains how a system spawns processes upon receiving execution requests from an authentication daemon, displaying prompts for user verification. Once credentials are confirmed, the control flows back to a security utility, which then executes the originally requested application. This flow ensures that only verified users can proceed with executing certain binaries.
• 06:30 - 07:30: Apple's Installation Process Vulnerabilities In the chapter titled "Apple's Installation Process Vulnerabilities," the transcript explores the intricacies and security loopholes present in Apple's installation processes. It begins by detailing how utilities set with UID root privileges operate, where binaries or scripts requested by applications are executed with root access. The chapter then shifts focus to potential abuses of this process, highlighting core vulnerabilities. One significant issue discussed is the inability to easily manage the pop-up dialogues that accompany these requests, which can pose security risks.
• 07:30 - 08:30: Elevating Privileges and Exploitation The chapter 'Elevating Privileges and Exploitation' discusses how seemingly legitimate prompts, such as those from applications like Slack, can be used maliciously to trick users into providing credentials. It questions the necessity of certain applications requiring elevated privileges and highlights how these prompts can potentially be exploited. The discussion is supported by real-life examples illustrating how attackers abuse these situations to escalate privileges or execute malicious actions.
• 08:30 - 09:30: Advanced Kernel and System Exploits The chapter begins by discussing the exploitation of trust in authentication prompts, explaining that while these aren't 'real' vulnerabilities per se, they're UI issues that have garnered attention. The speaker shares an anecdote about how others reacted to the topic, highlighting its relevance and controversy. The wider discussion aims to address more severe vulnerabilities beyond this UI concern. Additionally, there's a focus on how Mac malware frequently exploits these trust assumptions to gain access, setting up later discussions on more critical security flaws in systems.
• 09:30 - 10:30: Exploiting Authorization Prompts In this chapter, the focus is on exploiting authorization prompts through a real-world example. The discussion is centered around a Mac malware known as OS X Proton. Hackers accessed and infected the legitimate website of the open-source application Handbrake, which is a video transcoder. By injecting malicious code into the application, any future downloads from the compromised website would also be infected, illustrating a common method of exploiting authorization prompts for malicious purposes.
• 10:30 - 11:30: Apple's Installer and Dynamic Libraries In this chapter, the discussion centers around a specific type of malware related to Apple's Installer and dynamic libraries. The malware displays a fake authentication window, mimicking a legitimate security prompt. When users enter their passwords into this fake window, the malware captures the actual credentials, compromising the user's security. This process can be observed in a debugger by attaching it to the malware as the user inputs their password.
• 11:30 - 12:30: Exploitation Demonstrations The chapter titled 'Exploitation Demonstrations' explores how malware can exploit system vulnerabilities to execute tasks with elevated privileges. It reveals that malware can access stored passwords in the system's memory to perform operations as the root user. Additionally, malicious code can easily create an authentication prompt using system APIs such as 'authorization execute with privileges'. This method requires minimal code to deceive users into granting elevated access by providing legitimate-looking prompt. The chapter underscores the ease with which attackers can manipulate system authorizations for malicious purposes.
• 12:30 - 13:30: Secure Authorization with SMJobBless The chapter discusses how to create a convincing but malicious application using SMJobBless by replicating the icons from legitimate applications like Slack. It explains the process of setting the app's icon using the icon file key in the app's info.plist file, making the malicious authentication dialog appear legitimate to users. The chapter highlights the ease of making such a pop-up convincing for executing malicious intents.
• 13:30 - 14:30: Conclusion and Final Thoughts In this chapter, the focus is on the security vulnerabilities inherent in system authentication processes. The chapter highlights how easily users can be misled by frequent pop-up authentication dialogs, specifically discussing the danger when these dialogs are used maliciously. An exemplified case involves a malware called 'iron', which was distributed through cracked applications on Pirate Bay. This malware exploits user trust, bundling a desired application like Photoshop with malicious code, thus compromising system security once users unknowingly grant execution permissions as root. The chapter underlines the imperative need for heightened user awareness and more secure authentication mechanisms.

DEF CON 25 Patrick Wardle Death By 1000 Installers on macOS and it's all broken! Transcription

• 00:00 - 00:30 my name is Patrick Wartell I have worked at a variety of acronym places currently the chief security researcher at Cenac so briefly at Cenac we do crowdsource vulnerability discovery with vetted security researchers so if you're interested in signing up with with us to be a freelance researcher hacker to get paid to find vulnerabilities in our customer web apps mobile apps and IOT devices check out Cenac comm alright so today we're going to be covering a lot of interesting stuff we're gonna start
• 00:30 - 01:00 by looking at what happens when an application which is running at the privileged level of the user wants to perform a more privileged action well then discuss some core issues with how apps perform this temporary elevation of privileges and due to these core issues will then show a lot of bugs we'll talk about how to find these bugs discuss some actual vulnerabilities and then with end with some exploits so our goal is today is is to describe a reliable
• 01:00 - 01:30 way to locally escalate privileges such privilege escalation is often an essential step that malware wants to accomplish so again step one malware kind of gets on your box normally then it's gonna be running and somewhat of a constrained environment or at least at the privileged level of normal user not root so then for step number two the malware is going to want to escalate its privileges generally to root so today we're gonna be focusing on this second step step number two and talk about how to escalate privileges specifically by
• 01:30 - 02:00 exploiting bugs and vulnerabilities in installers and updates so first let's look at how an application can authenticate with the operating system to be authorized to temporarily perform high privilege actions so if you're a Mac user I'm sure you're very familiar with these authentication dialogues is what Apple calls them will also refer to them as authentication or off prompts so apps run at user privileges but sometimes they need to perform higher
• 02:00 - 02:30 privilege actions most commonly installers or updaters you know they're gonna have to write files to the system directory perhaps update a kernel extension obviously this needs to be done at higher privileges other actions for Apple debugging another process or even changing operating system settings such as the time will often require the user to Rihanna Kate in order for the application to perform that higher privilege action so these are quite common I get about one a day on my box and you know if not that at least a few
• 02:30 - 03:00 every week so first let's look at a conceptual overview of kind of what happens behind the scenes when an application for example an installer wants to perform a privileged action so first it's going to invoke authentication API and we'll talk about what these are on the next slide this will generate an ex PC message which is sent to the authorization daemon this demon then consults the authorization database and it usually says ok I will allow you to perform this action but first you have to re-authenticate so it
• 03:00 - 03:30 does this by sending another ex PC message to the security agent this agent is then responsible for showing the actual authentication prompt and then once the user enters the correct credentials and they're validated the application that requested this higher privilege action is that allow to perform it so let's take a closer look at these steps can assume we have an application for example an installer that wants to perform a higher privilege action so it kicks this off usually by
• 03:30 - 04:00 invoking something like authorization execute with privileges and this is a function we'll talk about what you can see on the slides when you invoke this function you basically just specify a path of what you want to be executed with these higher privileges and once the user is authenticated this will then be executed so if you look at this function it's open source we can see it calls exec V to execute a set UID system binary named security underscore off trampoline this binary is what sends the X BC message to the
• 04:00 - 04:30 authorization daemon off D we can verify this by using the LS MP utility which is a utility that can show you sending and receiving of mock messages all right so once the authentication daemon off the receives this X BC message which is basically an authorization request it will consult as I mentioned the authorization database this is in slash var slash DB auth dot dB and the system off trampoline requests the system dot privileges dot admin
• 04:30 - 05:00 right so we can dump this authorization database and we can see that privilege exists and as the Komets or the information in the database shows this is off associated with the authorization execute with privileged function which is what the application just invoked so again the authorization daemon is probably going to say sure I'll allow you or I'll grant you this privilege temporarily but first the user is going to have to reallocate so in order to facilitate this the daemon then sends an ex PC message as I mentioned to the
• 05:00 - 05:30 security agent so the security agent now has received this ex PC message and it is what displays the authentication dialog now this is done by design because Apple didn't want the user to have to trust the application with their password so since a trusted system utility is displaying this authentication prompt the application that's requesting the higher privilege actually has no access to the users actual password so we can use the LS app info utility and see yes security agent is actually the last process that was
• 05:30 - 06:00 spawned and again this is because it spawned on demand when it gets these ex PC requests from the authentication daemon it again displays that prompt and handles the verification of the users credentials once the user has verified him or herself control flow returns back to the security underscore trampoline utility which via had a call to exec V execute the binary that the application originally requested and again since this security underscore off trampoline
• 06:00 - 06:30 utility is set UID and owns and is owned by root the binary or the script that the application requested to be executed will now be executed with root privileges okay so that was a behind the scenes look what happens again when an application requests or needs to perform some action at a higher privilege level now let's talk about how to abuse this process starting with some core or fundamental issues so one of the main issues is these pop-ups cannot be easily
• 06:30 - 07:00 verified anybody can smooth them they're just a window asking for credentials so on the Left we have a legit pop up from the slack application and on the right who knows is this spoofed you know is this some Mauer just asking for credentials or is it even a little Ajith authentication prompt that was spawned via the security agent but is gonna execute something malicious and what is slack doing anyways like why does it need to perform the privilege action so we'll look at some real-life examples that abuse this again playing
• 07:00 - 07:30 off the fact that the user generally trust these authentication prompts and they're not easily verified now I do want to point out though that these are not in my opinion real vulnerabilities I mean there's somewhat like UI issues but you know when I mentioned to a few people that this is what my talk was gonna be about a lot of people immediately jumped on this so again as we'll see we're actually talk about some more problematic vulnerabilities but I wanted to mention this and cover this here especially since Mac malware often uses this or abuses this in order to get
• 07:30 - 08:00 rooted credentials so the first example is a Mac malware called OS X proton be what happened was the malware authors or hackers infected the legitimate application website of an application named transmission sorry handbrake handbrake is an open source video transcoder so again the hackers access that website got access to the application infected it with some malicious code and then any time moving on in the future when the users would
• 08:00 - 08:30 then download this application they themselves would become infected so when the malware runs the first thing it does is spawns one of these windows but it doesn't do it through the security agent it creates its own NS window so it's a hundred percent fake but it mimics and looks exactly like a real authentication uh prompt however when the user enters their password since it's fake the malware has access to the actual bytes or value of the user's password so we can see this in a debugger if we attach to the malware when the user enters
• 08:30 - 09:00 their password we can see it's present in the malware's memory and then the malware used this to execute something as root now there's also nothing stopping malicious code from creating a real authentication prompt and then get something to be executed as root once the user authenticates and by real I mean via these system API such as authorization execute with privileges again it's about three lines of code so here's an example how trivial it is to create a legit authentication prompt that will then
• 09:00 - 09:30 execute something malicious if you want to make it malicious but convincing very easy to do here I just grab the actual icons from the legitimate slack application copied them into my Xcode project you then set the icon icon file key in the apps info.plist file which then will be displayed in this legitimate albeit malicious authentication dialog so if we execute this a pop-up will be displayed on screen and it's legit again in the sense that this is being displayed by this
• 09:30 - 10:00 system security agent and since slack at least on my box is popping up this authentication dialog all the time like you know it's very easy to trick users and once they enter their credentials whatever we asked to be executed as root will be so here's an example of a piece of malware that actually does this I were so iron was distributed via cracked applications on Pirate Bay so users think that they would be getting for example a copy of Photoshop and they would but it would also be packaged with
• 10:00 - 10:30 Iowan when the malware was executed it would invoke the authorization execute with privileges function which would then display an authentication prompt now users would likely in enter their password because again there's no way to verify this and also they're installing software so that are used to seeing this especially when they're performing some installer now once the user enters their credentials the malware executes something named zero and this will be executed as root if we look at what that zero binary does it persists the malware is a launch daemon which means the
• 10:30 - 11:00 malware will now be always running as root persistently now again the malware spoofing or creating these authentication prompts pretty much comes down to social engineering these are not bugs these not vulnerabilities but they work so we can't knock it too much now I want to talk about some real issues some fundamental core vulnerabilities so we've been talking about this authorization execute with privileged API function the good thing about this API is it's very easy to use again you just specify whatever you want
• 11:00 - 11:30 to be executed as root and then the system will take care of everything else displaying the authentication prompt and then when the user verifies and enters his or her credentials whatever you ask to be executed by route will be by the system so that's great the problem is it performs no verification of what it's executing and is open to a massive race condition so an example a legitimate application say an installer needs to perform some privileged Act action needs to execute something as root so what it will do is
• 11:30 - 12:00 it'll invoke that authentication execute with privileged function and give it a path to something to execute for example an installer script in the meantime while the user is entering their credentials some local malicious code that doesn't have these higher-level privileges can actually modify that installation script and then once the user finishes entering his or her credentials the system will blindly execute what the app originally requested with no validation or verification that it hasn't been modified or infected in some manner
• 12:00 - 12:30 another issue is legit applications imagine they have authenticated securely and we'll talk about how to do this in a minute often then do authorized actions that are insecure so for example they can persist non-validated components they can create insecure temporary files they can even load and execute other non validated components so imagine for an example there's an installer that's now running as root it's been authenticated securely incorrectly but then it creates in the temporary directory a property
• 12:30 - 13:00 list or plist file a few seconds later it then moves that pilas file out of temp into the system's launch daemon directory where the watch daemon will be executed as root obviously again some local non-privileged code can modify that property list while it's in the temporary directory and then when it's moved into the launch Damons directory they'll at local malicious code will have just inherited root permissions all right so now let's talk about actually finding some of these bugs and since we'll see this is such a systemic
• 13:00 - 13:30 problem we're actually only gonna look at software that I had installed on my box so first let's look at who calls this horribly insecure authorization execute with privilege function so you can grip the filesystem looking for binaries that import this start may be by looking at slash application or it actually turns out that whenever this API is called Apple will log this specifically to the var slash log slash diagnostic messages logs now unfortunately these logs are only kept
• 13:30 - 14:00 for a few days but you can start by looking there to see basically who has displayed one of these authentication prompts because they invoked the authorization execute with privileges function so if we grab or dump these we can see that pretty much everyone calls this function again on my box slack VMware fusion Chrome Little Snitch freedome Sparkle everybody now just because someone calls this function doesn't mean it's necessarily an exploitable bug it's kind of similar to sister copyright we Noster copy is like a dangerous API but if ster copy is used
• 14:00 - 14:30 correctly doesn't necessarily mean that there's gonna be a buffer overflow an example of a safe use of this function is imagine an installer wants to perform a privilege system command for example it wants to execute reboot now obviously local malicious code can't modify the /s pin reboot utility rights protected with system integrity protection and etc etc etc so this for example is safe so in order though for something to be
• 14:30 - 15:00 exploitable what authorization execute with privileges is about to execute has to be writable modifiable and flexible by the local non privilege code turns out though this is pretty much always the case so the question is how do we tell that what is about to be executed as root is verify it is accessible by this you know local unprivileged code so the question is first what is this going to execute and then is this writable so there's two ways to tell or figure out
• 15:00 - 15:30 what this function is about to execute the first is if you use a process monitor utility I wrote a free one that's open source and will be online after this talk we can basically look at the arguments to the security underscore auth trampoline again this is the set UID process that gets invoked when someone calls authorization execute with privileges so here for example we can see it's downloading or rather going to execute an install our application that's in /downloads obviously local non privilege code could modify that another
• 15:30 - 16:00 example is you could basically just debug the process and set a breakpoint on the authorization execute with privileged function and then look at the arguments specifically the third argument RSI and look at what this is again this will be the path of what is about to be executed as route and once we know what is about to be executed we can check the permissions of this file it usually a script or binary and if it's owned by the user which it normally is this means code that's running as ruse er user not root can modify this code again wants the user then I'll think
• 16:00 - 16:30 authenticates we will have root so later we'll talk also about how apps should securely authorize or authenticate themselves but as we mentioned even if they do that securely if then they execute other actions which themselves are insecure this still gives us gives us an opportunity to elevate our privileges to root so in order to find these bugs pretty much what I do at least this monitor the file system or watch what processes these higher elevated privileges applications will
• 16:30 - 17:00 then execute so again the question is can the unprivileged code modify these example a property list that and install our application it might have in its slash resource folder in the Downloads directory it might be authenticated correctly and securely but then goes to execute that that secondary component itself has not been validated so again perhaps local malicious code can modify that and get root via that means alright enough with the conceptual blabbering it's time to talk about some exploitable
• 17:00 - 17:30 bugs in this section we will talk about the bugs and then in the next section how to generically exploit such vulnerable --'tis and note if I don't mention a CVE associated with a vulnerability it's a zero-day or a bug that the vendor has decided not to patch so the first bug is in a popular IOT device one that I use drop gap basically when you buy a new Dropcam and you go to configure it the instructions say plug it into the computer this will mount something on a
• 17:30 - 18:00 drive double-click that which is the installer application and then follow the authentication prompt and it will install and configure the Dropcam for you basically setting up the Wi-Fi networks etc for the IOT device so it turns out though when it executes this application off this mounted share what it does it makes a copy of the installer application into the users temporary directory it then executes this via the authorization execute with privileged function in order to execute that with root privileges so what we can
• 18:00 - 18:30 do is we can attach to this process with the debugger here we use LL dB we set a breakpoint on the authorization execute with privileged function and when we hit this breakpoint we can dump the third argument again RSI and this is the path to what is about to be executed with root privileges and again we can see it's the Installer application that has been copied into the users temporary directory now again there's a large window of time when the user is legitimately authenticating where local
• 18:30 - 19:00 malicious code could modify that installer application in the temporary directory and again since the authorization executes with privilege function does not validate what is about to be executed as soon as the user completes the authentication our malicious code will be executed now with root privileges next is chrome this is a rather popular browser that I use on my box it also invokes the authorization execute with privileged function in a variety of instances for example if you're installing it as a non admin user
• 19:00 - 19:30 or if you're setting things up like Auto updates so we can observe this by running our process monitor and again we see that security underscore auth trampoline process and if we look at what that is about to execute this route we can see it's a script named Keystone underscore promote underscore preflight Sh this script which again is run as root once the user authenticates is owned by a normal user so this means at any point any local non route code on
• 19:30 - 20:00 your box could modify that and then when the user performs for example sets up an auto update chrome will blindly execute that as root next up is Little Snitch this is everyone's firewall on Mac OS something I used to run till I wrote my own unfortunately their installer had a local privilege escalation and this is an example of something that authenticates correctly but then performs malicious actions that then non-privileged local code could leverage
• 20:00 - 20:30 to elevate its privileges to root so the issue was the authorized installer which again is running as root wrote a property list to the temporary directory and then move that into the launch daemons directory where I would be loaded and executed as root so again what local privilege code could do was modify that property list when it was in the world writable temporary directory and then was moved into the system launch daemon directory and executed the malicious code would get root so if we
• 20:30 - 21:00 take a closer look at this bug on the screen at the top right we can see the Little Snitch installer calls something right plist owner mode to file and we can see this calls the NS temporary directory function to get the user's temporary directory and write out what will be the launch demons property list so what we can do is we can attach a debugger to the Installer and then set a breakpoint on the method execute command as root and we can see what this this command is then doing is moving the
• 21:00 - 21:30 plist from the temporary directory into the system launched daemon directory and then setting it to be owned as root obviously again while this is in temp a user who doesn't have correct privileges or some malicious malware could modify that and then it would be execute with higher privileges to root Little Snitch actually patch this really quickly so kudos kudos on their response as CVE 2017 2675 I also do a lot of malware analysis so I use VMware so whenever you
• 21:30 - 22:00 go to install VMware or when it tells you that there's an update what it does is it saves various scripts into the users temporary directory and then execute them as route via the authorization execute with privileges functions so we can see this by debugging the VMware installer or updater again you set a breakpoint on the authorization and execute with privileges function and then when the breakpoint is hit dump the third arg and you can see what's being executed again it's these scripts that are out of the world writable temporal directory again
• 22:00 - 22:30 nothing is verified so these will then be executed as root alright more security software yes this is the VPN I run f-secure freedom turns out it is vulnerable as well so when you install this VPN it tells you hey I'm about to show you a pop-up please enter your credentials and then when this pop-up is displayed it doesn't actually say freedome is doing it it says something named OS a script which is Apple script so I wondered you know what is Apple script executing so
• 22:30 - 23:00 if you disassemble freedome you have some disassembly on the slide we can see it's executing an apple script to authenticate and then execute something as route via the do shell script script with admin prints this then cause Apple script to display on authentication prompt and when the user enters their credentials whatever was requested is executed as root so our process monitor shows that the Apple script is executing a script in the applications bundle which is of course writable or modifiable by local non privilege code
• 23:00 - 23:30 next up is Sophos yes due to you know work compliance I have to run antivirus on my computer my boss told me though if I found a vulnerability in it I could uninstall it and so this is kind of the motivation for that gonna hold them to that so when you download Sophos to zip file when you unzip it it executes s-- and installer application and you guess this this then in turn executes the secondary component via the authorization execute with privileges
• 23:30 - 24:00 and we can dump via the debugger what's it about to execute and it's something called installation dot deployer again if there's some malicious code on the box that has not root privileges it can modify this component and then that will be executed as root all right finally we've got sparkle now sparkle is an auto update library that's used in a good number of apps now I do want to point out this is nearly a list of apps from 2016 that use Sparkle I have not validated if these are all vulnerable I
• 24:00 - 24:30 just wanted a list let's look an example or specific instance of an application that uses Sparkle that is vulnerable so I do a lot of reverse engineering I use hopper app occasionally it's a nice app anytime it has an update or a new version the sparkle library that's compiled in displays this pop up telling me that there's a new version if we click on it Sparkle will download something auto-update app into a non protected cache directory and then execute this now depending on the user's permissions
• 24:30 - 25:00 for example if there are standard user versus an admin user this will display an authentication prompt if we view this in a debugger attaching to the auto update process set a breakpoint on authorization execute with privileges we can see it's trying to execute something named file up out of user writable cache directory again there's any local non privileged code it can obviously modify which anything in this cache directory and then that will be executed by root when sparkl completes the update process
• 25:00 - 25:30 all right enough knocking on third-party apps I think by this time we understand that the authorization executes with privilege function is you know shitty don't use it but everyone pretty much does so I want to talk about some issues in Apple's code now you know they're not safe from these issues either so the first thing is I'm not really sure if this is a bug it's more of a silly issue but when a user dragged something via finder into a higher privileged directory the finder app displays an authentication prompt basically saying
• 25:30 - 26:00 hey you know you need to provide correct creds in order for me to complete this copy action problem is it doesn't validate that what the user originally meant to copy wasn't modified during the time they were authentic eating so we can imagine a scenario where a user is trying to move an act for example into slash applications they have to provide their credentials again some local unprivileged code could perhaps modify what they were moving into applications and then the move would still succeed and now they've just got some malicious
• 26:00 - 26:30 code into a higher privileged directory which might be executed by other users all right something know that I think is a real issue so apples packages installer is called installer app basically when you double-click on a PKG file install our app will be automatically executed to handle the installation of this package and why does this happen well if we dump the info dot plist file of the Installer dot app we can see it advertises as the
• 26:30 - 27:00 default handler for packages note also it's a signed utility via Apple and also has some special privileges or entitlements so here's an example when again at user double clicks on a pkg file installer I'll app will be executed to handle that it will display this nice installation prompt and then request user permissions again this is all just standard stuff I took a closer look at this process and realize that this sign trusted installer application would load dynamic libraries from slash temp I have no idea why now
• 27:00 - 27:30 we'll talk shortly about weaponizing this but let's look at what is going on so when the user double clicks on a pkg file that has a plugins directory installer dot app would take those plugins copy them into the users directory and then load them into its trusted process context in a debugger we can set a breakpoint on DL open in the Installer dot application and then we can dump what is about to be loaded and we can see yes it's about to actually load an unsigned dynamic library from
• 27:30 - 28:00 the users temporary directory it also use an application like task Explorer which I wrote we can filter on unsigned dynamic libraries and see yep there is an unsigned dynamic library loaded from the temporary directory all right so that's about thousand ways to get route but what if you want more and not because we're greedy but on recent versions of Mac OS you actually are still somewhat limited when you have root permissions you can't bypass the system integrity protection to modify operating system components you cat can
• 28:00 - 28:30 also not run unsigned code in the kernel so the books I find found that I'm gonna talk about here need root in order to trigger but once you then exploit these vulnerabilities you have these even higher privileges so the first bug allows us to bypass system integrity protection and also survive a full OS upgrade this is something that now we're would like to do all right so it's time to upgrade what happens is the user will download the OS update from the axe store
• 28:30 - 29:00 long story short an entitled binary named OS I helper D will tell the system to boot off an installer image install ESD dmg this is what is downloaded from the App Store and then this is when the system reboots what actually installs the new version of the operating system so our goal is to get into this installer image because once the system has booted off it we're essentially booting or executing outside the context of the operating system so operating system level protections such
• 29:00 - 29:30 as system integrity protection are no longer in play so Apple generically realized this attack vector well that is to say blessing off an untrusted disk image so they block that ability unless you have the correct entitlements which an Apple utilities such as OS is helper D has so step one is to get a dial it into the OS installer application which is downloaded from the App Store when the user wants to perform an upgrade and we can use a neat runtime die live injection technique which I like to call
• 29:30 - 30:00 die Lib proxying basically what you do is you replace a dynamic library that the application is dependent on and then proxy requests to the original one as not to break any system functionality and then when that application is executed the dynamic loader will naively and blindly load the malicious dilib in place this was a technique that was used in some Israeli malware on the Windows platform I haven't seen it used on the Mac operating system I'm not sure why kind of a neat technique all right
• 30:00 - 30:30 so now we have code executed in the trusted context of the operating system installer application so what we can do now is in Mott is modify or infect the install ESD disk image and then the OS is helper D blesses it oops there's no validation that what it's about the blessèd has not been tampered with so now the system reboots we are running in the process context outside the operating system and so we can obviously bypass system integrity protection and ensure also that our malware fully lives
• 30:30 - 31:00 or survives through a full OS upgrade so as a proof of concept I took AI worm which is a well-known piece of malware that we talked about earlier and injected this into the installation image and then during this install process I copied it into a system integrity protection protected directory which means that once the OS install upgrade completed that malware was essentially undeletable Apple fixed this as CBE 2017 69 74 all right what about a pure kernel bug
• 31:00 - 31:30 again our goal is to get unsigned the arbitrary code running in the context of the kernel again root for this bug is a prerequisite but we showed a lot of ways to get root privileges so that's okay so I stumbled across this bug I was writing some code that used the audit subsystem and I noticed that was an interesting B copy so B copy is essentially a mem copy copy something from source to destination by some number of bytes here we can see the B copy source is a sock adder struct named
• 31:30 - 32:00 sa destination is a sock add or underscore storage named Arg sock adder and it's max size of the destination buffer is 128 now interestingly the number of bytes that are copied is the size of the sock adder source structure so anytime you see a B copy where it's using the number of bytes to copy based on the source always take a closer look at that so how do we know the destination object is of max size 128 so the question then becomes can we make
• 32:00 - 32:30 the source object a sock add or structure bigger than that turns out the answer is yes we can create a UNIX socket that has a path which allows us to create a socket structure that's bigger than 128 bytes so what we do is we create that and then we call bind which will trigger the vulnerable B coffee because it's trying to audit that socket operation and via the diagram we can see that since the sock adder structure is bigger than 128 this will cause a heap overflow for example here we can see the 41 41 41 is now in a kernel pointer we control so
• 32:30 - 33:00 exploiting this bug will give us arbitrary unsigned code execution in the context of the kernel all right so that was a good deal of bugs but what good are bugs if we can't exploit them so let's talk about now how to exploit such vulnerable ease all right so again back to the user assisted elevation of privileges a goal is to get root when a vulnerable but legitimate application invokes or displays an authentication prompt so as a limited process or
• 33:00 - 33:30 limited local code to do the exploit we have to do three things we have to wait for a vulnerable application to start VMware Sophos Sparkle Little Snitch whatever now we have to wait for it to form insecure authentication requests and then while the user is entering their trench quickly infect the vulnerable file and then as soon as the user completes the authentication we will have route so step one we need a monitor for the execution of these vulnerable application turns out this is really easy to do you don't have to have special privileges
• 33:30 - 34:00 you can use the NS workspace Notification Center and register a notification for application launches and exits so in our notification hand R we bail if it's an application that's not an interest for example calculator but if it is for example it's Sophos vmware or one of the myriad of other applications we talked about we move on to step two which is monitoring for the vulnerable file to be created we also care about application exits because we want to stop monitoring once the application exits okay so as non
• 34:00 - 34:30 privileged code you can watch for specific files or directories using FS events so here's some code where we watch for a target file now this will be application specific for Little Snitch for example it's a property list in the users temporary directory for freedom it's a script in their application bundle for Sparkle it's the auto update down application that's downloaded either way though we can detect when these vulnerable files are created and once we get a call back in our callback
• 34:30 - 35:00 handler we know it's go time let's go in fact all right so now we've seen the file has been created again once the user authenticates this will be executed as root with no verification so we mentioned again this file will be application specific so this dictates the infection technique so for example for a property list or plist file we're probably going to modify the program arguments array and point it to a malicious binary for a script you can just infect it by adding some extra
• 35:00 - 35:30 commands that you want to be executed as route and if it's going to execute a mock Obion areas route you can either infect that or you can actually just replace it with your own binary and again that will be executed as root and a very valid question is don't we have to win a race and the answer is yes so again the application is usually going to drop whatever wants to execute his route then throw up the authentication prompt and then while the user is authenticating we can jump in and in so this user authentication usually
• 35:30 - 36:00 takes at least one or two seconds and like that's a massive window that we can always win now a prerequisite of this exploitation is that this non-privileged local malicious code has to have the ability to write to the item that's about to be executed right if it's non writable we can't modify or to touch it this is usually just an issue not because we don't have the correct permissions but because of what is about to be executed is on a read-only share so one example is due to gatekeeper so I
• 36:00 - 36:30 found a bunch of issues with gatekeeper and the way app will fix them is to implement call something called app translocation basically now on modern versions of Mac OS X if you download a zip file from the internet when you go to double click and unzip and execute the app within it its transparently copied to a read-only share and executed from that share and this is to deal with a bunch of gatekeeper issues this read only is bad for us because imagine that application is executing something in
• 36:30 - 37:00 its application bundle as root now it's sitting on this read-only share so we can't modify that anymore well it turns out this is pretty easy to bypass again if your local non privilege code you can just remove the quarantine attribute from that downloaded zip file and then translocation won't happen the application will remain in the Downloads directory and you can modify it as much as you want recall also apple's installation app which is the default handler for pkgs can be coerced into loading unsigned malicious die labs what if the package
• 37:00 - 37:30 though doesn't have plugins well would be great if we could basically infect arbitrary PKG files so normally PKG files are distributed on disk images DM g's and when you double click a dmg it's mounted but on a read-only share so again this is problematic for us what we can do though is as local non privileged code we can register to be the default handler for dmg images then when the user double clicks on that it'll execute our code and we can then force that dmg to be
• 37:30 - 38:00 mounted with read/write privileges we can then modify that package inject a malicious plugin and then when the user double clicks on that that militia unsigned dynamic library will be loaded into the trusted process context of Apple's installation application alright so that was generally how to exploit some vulnerabilities and how to deal with read-only issues let's now look at some actual exploits so demo time here we have VMware it's telling us to do an
• 38:00 - 38:30 update and we're good users so we know that when an application requests an update we should listen because it's gonna patch security fixes and give us all these great new features so in the demo we'll see the exploiter utility which is running with normal low-level privileges it's going to detect that VMware is running it's going to register a file watch for the scripts that VMware drops into the temporary directory and then infects those scripts and then when the updater completes by asking the user to please provide their credentials we will pop calc as root so watch closely
• 38:30 - 39:00 we're waiting for VMware we see VMware's running we detected that the script is about to be present in a second in fact that vmware legitimately asked for creds via the authentication execute with privilege function as soon as that execute whatever vmware asked to be executed which were scripts out of the temperature rectory are now executed as root and again there's no verification on these so we've popped calc as root
• 39:00 - 39:30 here's a yes [Applause] I saw a funny tweet it was like clap at DEFCON if you see calculator running this out gotta use calc even on Mac so here's another demo with Chrome this is pretty much the simplest stupidest exploit ever basically you have a Python script that's running as a non privilege user and it's going to infect that script that chrome runs or request to be run with root privileges again chrome
• 39:30 - 40:00 ask the user to authenticate and they do will be able to Paul calc really the hardest thing here was they basically get calc to run as root so we run our Python script it infects that stripped because we have the right privileges chrome asks the user to authenticate because they want to execute this script as root again there's no validation so then chrome execute the script is root which we've infected to execute calc again chrome said and we're not gonna fix this finally let's talk about exploiting apple's installer i think
• 40:00 - 40:30 this is kind of my favorite why it's because people use installer dot app all the time and what we can do is basically inject malicious code unsigned dynamic libraries into the package that is about to be installed and then install it on application will load them so in three steps we basically expand the PKG inject our malicious dialogs into it repackage it up and then when the user double clicks to execute this installer app will load our malicious unsigned die
• 40:30 - 41:00 libs into its process context so now we're running within installer dot app so what we do here well we can either display our own authentication prompt which everyone will trust because it's the installer application displaying an authentication prompt with what it always does anyways or to be even more stealthy we can just wait until installer dot app requests the user to authenticate anyway and then piggyback off that i reported this is apple via their bug reporting website got no response maybe they're just sick of
• 41:00 - 41:30 hearing for me probably they don't really like me alright so let's start by wrapping or end by wrapping this all up so hopefully you have a healthy paranoia of these authentication prompts i do why first they can be spoofed like there's no way really to easily validate that this is not completely fake and even if it is a legitimate you know pop-up that the security agent has displayed like how do you know what it's about execute and again every freaking application invokes
• 41:30 - 42:00 this insecure API meaning local code that's on your box if it wants to elevate its privileges root can very very easily infect that so if you're a malware author you know stop spoofing these boxes like it's really lame like do something a little cooler you know I'm getting bored as a Mac analyst Mountain my our analyst is seeing these comet knows what I'm talking about he complains to me all the time so instead like be patient wait till one of these vulnerable applications which is pretty
• 42:00 - 42:30 much most applications needs to perform an upgrade or is installed and again what you can then do is piggy back into that and then when the user authenticates you will have route again a lot more stealthy a lot more elegant so what is the answer well the answer is to use SM job less this is an API that was recently introduced by Apple and it does allow you or applications to do secure authentication but it's incredibly complicated so what you have to do is put whatever you want to be executed is route this is called the
• 42:30 - 43:00 helper tool in the contents slash library slash launch services directory then in your applications info dot P list file you have to identify the signing information of the helper tool then you invoke SM job less which will cause the service management demon to copy your helper application into a secure location then in that secure location it is cryptographically verified that it hasn't been tampered with only then once that verification is validated it's copied to the system
• 43:00 - 43:30 launch daemon directory and executed as root via a launch daemon so here's code to do it because he is actually not too complex in code once you get everything set up and again this will allow you to securely install and execute something with higher privileges that local malicious code cannot tamper with so why aren't people using it why is chrome VMware Sophos Little Snitch why is everyone using the insecure variant well first your application has to be signed which means you have to give Apple $99 a year
• 43:30 - 44:00 also you can't specify command-line arguments you can't pass command-line arguments to whatever you're about to execute you can use X PC but this is kind of a pain in the butt I consider myself a decent coder took me hours to get working and also then it persistently installs something as a launch daemon this is like massive overkill if all you want to do is run a simple installation script and then there's kind of a catch-22 this you know watch agent has been stalled and running his route your app can't actually now uninstall it because it's running with
• 44:00 - 44:30 higher privileges so again you have to set up this X PC channel or tell the launch statement on its stall itself just incredibly complicated and usually way it overkill all right so before we end I assume we're at this talk because you're somewhat interested in Mac security shameless plug for my Mac security website but everything here is free so I hope this isn't sound like a sales pitch in my free time I like to write security tools blog about this kind of stuff write about a lot of malware analysis etc so if you're interested in this stuff check it out
• 44:30 - 45:00 all right well that's a wrap again thank you so much for attending my talk and again if you're interested in being a security researcher with syn/ack check out cynic calm or come chat with me so if there's any questions or I'll be here afterwards I'd love to chat with you more about this thank you