Andy Grant - Unpacking Pkgs A Look Inside MacOS Installer Packages - DEF CON 27 Conference

Summary

Andy Grant's talk at DEF CON 27 explores the intricacies of MacOS installer packages, offering a deep dive into their structure and potential security vulnerabilities. With over 20 years of experience in security, Grant details his journey into unraveling these packages, fueled by his innate trust issues. He outlines the composition of MacOS X installer flat packages, exploring tools like package util and Suspicious Package, and walks through unpackaging them both the 'hacker way' and via standard procedures. Grant highlights several real-world vulnerabilities, illustrating how scripts and payloads within these packages could potentially be exploited. The presentation offers insights into both the technical and security facets of MacOS installations, underscoring the importance of robust auditing and the implications of application whitelisting bypasses.

Highlights

• The complexity of MacOS X installer flat packages, with .PKG extension, is explored, including their structure and lack of comprehensive Apple documentation. 📂
• Grant emphasizes using package util and third-party software like 'Suspicious Package' for auditing and checking packages' security aspects. 🔧
• Various vulnerabilities such as privilege escalation, symbolic link abuse, and arbitrary code execution are discussed with real examples. 🛡️
• Unpacking packages the 'hacker way' to fully understand and audit the installation process is encouraged. 💻
• The potential for one-click installations and bypassing application whitelisting adds to the intrigue and challenges of MacOS package security. 🎮

Key Takeaways

• Delving into MacOS installer packages reveals their complex yet fascinating structure. 🧐
• Security auditing of packages can uncover significant vulnerabilities, emphasizing the importance of in-depth analysis. 🔍
• Uncovering how scripts and payloads in installer packages can be exploited highlights potential risks. ⚠️
• Auditing tools like package util and Suspicious Package are vital for understanding and inspecting these packages. 🛠️
• Bypassing application whitelisting through creative scripting demonstrates both potential risks and advanced techniques. 🚀

Overview

Andy Grant's presentation at DEF CON 27 on MacOS installer packages pulls back the curtain on the complexities of these seemingly simple files. With his extensive background in security, Grant delves into the anatomy of MacOS X installer flat packages, shedding light on their intricate components and potential pitfalls. From distribution XML files and compressed archives to scripts running amok, the session unpacks the unseen yet crucial parts of software installations.

Grant doesn't just stop at explaining the package structures; he digs into the vulnerabilities that come with them. Through various real-world examples, he demonstrates how these packages can harbor threats like privilege escalation and symbolic link abuse. His talk is a wake-up call for anyone involved in software installation and security, highlighting why auditing these packages is not just necessary, but essential.

The exploration doesn’t just end with identifying problems; Grant also offers insights into bypassing application whitelisting using creative scripting techniques. His analysis is both a technical deep-dive and a strategic overview, ensuring that even those new to MacOS internals can understand and appreciate the security concerns and solutions discussed.

Chapters

• 00:00 - 01:30: Introduction and Speaker Background In this chapter, Andy Grant introduces himself and the topic of his talk, which is Mac OS packaging. Andy has been a professional in application security for over 11 years and has had an interest in security for more than 20 years. He shares his journey of starting as a self-taught enthusiast in his early teens and attending DefCon 9 as his first DefCon conference.
• 01:30 - 03:30: Understanding MacOS Installer Packages The chapter begins with the author's academic background, having completed a science degree from Stanford University with a focus on computer security. Following this, the author describes their career trajectory, starting with joining ISEC Partners, a security consulting group that was later acquired by NCC Group. The author details their progression within the company, starting with performing penetration tests on applications to identify vulnerabilities. They eventually rose through the ranks to lead the San Francisco team, joining management and leading a team for five years.
• 03:30 - 06:00: Tools for Inspecting Packages The chapter introduces a person who shares his professional journey, from managing a team of 30 people to returning to technical work. He is also recognized for being the husband of Dana Vollmer, an athlete, and expresses support for her career. The chapter sets the stage for a discussion on tools used for inspecting packages.
• 06:00 - 13:00: Package Structure and Security Concerns The chapter delves into the author's journey into computer security which was spurred by personal trust issues and a desire to understand the intricacies of package installations. Initially driven by curiosity about their own laptop, the author begins to explore what occurs during software installations, especially focusing on the potential vulnerabilities and risks posed by these packages. The narrative highlights the critical role of understanding package contents and installers in maintaining computer security, setting the stage for discussions on structure and security concerns in software distribution.
• 13:00 - 22:00: Vulnerabilities and Exploits The chapter titled 'Vulnerabilities and Exploits' discusses the inherent risks that come with executing unknown programs. The speaker highlights a scenario where a program might prompt the user, 'Do you want to continue?' without revealing what the program does or what it will run, creating a security risk. The speaker reflects on the fortunate position of being paid to assess such programs, especially when applications do not work as intended. In such cases, the evaluation relies heavily on the installer and process environment. The chapter encourages delving into the specific details of 'packages', specifically identifying them by their technical term 'Mac OS'. Overall, it underscores the importance of understanding what is installed and run on systems to mitigate potential vulnerabilities and exploits.
• 22:00 - 28:00: Demo: Finding and Exploiting Vulnerabilities This chapter discusses the nature of X installer flat packages in OS X, which have a.pkg extension. It highlights the lack of official documentation from Apple, though some unofficial reverse-engineered information exists, albeit outdated and incomplete. The chapter notes that these packages are single files known as eXtensible ARchives (XAR). Before OS X 10.5, these were bundle packages.
• 28:00 - 32:00: Final Notes and Closing Remarks This chapter discusses tools and methods for inspecting installed software packages on macOS, specifically focusing on security. It highlights the use of 'packageutil', a preinstalled tool on macOS, which helps in inspecting packages on the system. The chapter also mentions a third-party package designed to assess security aspects of software packages, although details of this package are not provided within the transcript.
• 32:00 - 36:00: Application Whitelisting and Conclusion This chapter discusses methods of identifying potentially malicious software packages using tools like 'Suspicious Package'. This tool aids in verifying code signing signatures and examining the components of software for any red flags indicative of malware. A question is posed about the reliability of using pre-installed utilities for this purpose, suggesting a more manual, cautionary approach where one might create a separate directory to unpack and analyze the contents independently. This reflects a broader cybersecurity mindset characterized by a lack of trust in automated processes and a preference towards deeper, manual inspection of software.

Andy Grant - Unpacking Pkgs A Look Inside MacOS Installer Packages - DEF CON 27 Conference Transcription

• 00:00 - 00:30 >>Andy Grant’s here to to talk to us a little bit about uh Mac OS packaging. Thank you. >>Awesome. Thank you. Yeah. So I’m going to talk about the packages used to install software on Mac systems, on Apple software laptops. First I’m going to start a little bit about myself, I’ve been doing professional security for 11 years focusing on application security. Been doing security as a hobby for 20 plus years. I came to DefCon 9 as my first DefCon. Uh I went up through self-taught ranks when I was in my early teens. Got a computer
• 00:30 - 01:00 science degree from Stanford University focusing on computer security. Went on to join the comp the security consulting group, ISEC Partners. I was acquired by NCC Group and continued to do that to today. I got started just doing the regular pen tests, looking at applications, finding the vulnerabilities. Moved my rank way up the ranks to become um uh the leader of the San Francisco team. Joined the management. Did that for 5 years. Ran a team of
• 01:00 - 01:30 30 people. Spent most of my time running that team of 30 people trying to find an excuse to do the projects my team was supposed to be doing so I gave up the management stuff and I’m back doing the technical work and here presenting today. [applause] Uh thank you. Uh I’m probably best known though by my alias of Dana Vollmer’s husband and um and you can find out more about me and my time off to support her career online. So we’re going to cut talk about
• 01:30 - 02:00 what lead me to looking at packages and installers. Then to open up the packages, look inside ah and then see what can go wrong in uh with these installations. So first, I’ve got trust issues. That’s whats got me into computer security at the start. Digging into what was going on in my laptop. I wanted to better understand what was happening. You have these pop ups sometimes when you’re installing software that says “This package is going to run a
• 02:00 - 02:30 program. Do you want to continue?” Then you don’t get to know what that program is or what got ran. Just it’s going to run something. Plus I’m lucky enough that I get paid to do this as I was saying and sometimes the client pays you to look at their application and their application doesn’t work so really all you have to go on is the installer and the process and then you kinda have to give them their money’s worth out of just that working environment. So let’s look inside what these packages are. So their technical term, their full name is “Mac OS
• 02:30 - 03:00 X installer flat packages” that have a dot PKG extension. There’s not a whole lot of documentation provided by Apple on them. Uh but you can find some reverse engineered unofficial documentation but it’s kind of out of date and um and incomplete. Uh the flat package aspect of this is that it’s a single file. It’s actually an eXtensible ARchive or XAR and it in in pre 10 dot 5 OS X these used to be bundles uh bundle packages and so those
• 03:00 - 03:30 were more like directories like your dot app um package uh app bundles. There’s some helpful tools. One even comes preinstalled on uh MAc OS called package util. This allows you to inspect uh the packages installed on your system. Inspect a specific package and go through and open open them up which is what we’re going to get into. There’s uh nifty uh third party uh package out there that’s specifically designed to look at the security aspects of
• 03:30 - 04:00 these packages and that’s called “Suspicious Package”. It will highlight the code signing signature. It’ll it’ll let you look at some the files that get run and will highlight some um nuances of that application that might raise a red flag. If it might be a malware installation. So let’s let’s look inside. What’s inside these? The easiest way to do it is to use your preinstalled package util. Give it the expand command and then give it the package in the output directory and it will expand everything out there. But we don’t want the easy way, we want to do it the hacker way. We got trust issues. We don’t trust what package util is doing, we want to make our own directory. We understand that command. We go into that directory because
• 04:00 - 04:30 the uh ways are to extract these files works it just um outputs right into the current working directory and so now we’re going to go through and extract the package files. After you’ve extracted them, this is sort of the typical structure you find inside. You have a distribution XML file. You have a resources directory. And then you have one or more package directories. These package directories contain a bill of materials, a package info, another plain text
• 04:30 - 05:00 XML file, and then two compressed archives, ah payload and scripts. So the distribution file. This is a customization of the installer window. It says gives it the title, the welcome text, if there’s a license, if there’s um ah readme, the background logo that that is displayed, and sort of uh determines whether you restart or shutdown or don’t need to do anything after the installation is complete. These can also include javascript. Specifically
• 05:00 - 05:30 a subset called installer JS and this is supposed to be what triggers that pop up of some uh code is gonna run to check to see if your system’s compatible. It’s an compatibility check. You have the package info. This is more information about the individual packages are just installed with that distribution. It has the specific requirements of that
• 05:30 - 06:00 package. The install location where that payload’s uh that package payload will be extracted to. And then it’ll also also include any paths to the scripts that will be run. Then you have the bill of materials . This is um a special file that lists out all the files that will be installed, updated, or removed during the installation process and it includes the file permissions, the owner and group that they will have. The size of the files
• 06:00 - 06:30 and creation time and some other uh file meta data. Now we have these um compressed archives. These archives are actually CPIO archives that have been gzip compressed. The payload includes all those files that are gonna be installed, that are listed in the um bill of materials and the installation process here is actually just extracting this archive into the install-location specified in the package info. You have the scripts um if there’s any
• 06:30 - 07:00 scripts to be run before or afterwards. Same type of archives, CPIO archive. You have pre-installation and post-installation scripts but really this can contain any executable file that has an appropriate shebang at the first line so it’s typically bash, python, perl. Uh this gets extracted um during by the installer into a random directory and gets executed from that location. So to unpackage those packages, those archives
• 07:00 - 07:30 within within it you um you can go like I said, it’s a gzip CPIO file and so you can cap this. The ah uh archive into the decompression, into the archive extraction or CPIO actually natively detects that it’s been gzip compressed and so you can just put it right into the CPIO and say its input and um and then away you go. It’ll dump right into the current directory all the contents of that. If you did it the easy way to begin with, the expand command
• 07:30 - 08:00 actually goes ahead and extracts this archive already and instead of having the scripts um object be a uh archive it is already a directory with the contents inside of it. You do the same thing as scripts for payload. You go through the CPIO command. Um sometimes in going that payload and extracting the files it has further packages in it so you just recurse through if you
• 08:00 - 08:30 want to find everything that’s going to happen during the course of your install. Unlike with scripts though, the package util does not auto expand this and you do have to go through the manual process of extracting the payload files if you want to see what’s going to be installed on the system. So this walks through what happens when you actually launch the installer with one of these packages. The you start with the distribution file. Um then we’re working through sort of more than the code execution flow. So you it checks to see is there any
• 08:30 - 09:00 installer check, if so it looks for the java script that it’s going to be there that javascript is defined within the XML file at between script tags and it goes through and executes that javascript. Then if the package info de um said there was any pre-installation scripts it goes and runs that pre-installation script. Then you install the files. You extract the payload into the install location and then you do the post-installation scripts if
• 09:00 - 09:30 there’s any specified in the package info. So now we’re going to get into sort of the security concerns that can happen during the installation that um that can occur. You have the scripts in the payload which is where most of this is happening and the scripts you’re going to look at the pre-installation, the post-installation. These can also include helper scripts and other files so you’ll want to look at what’s going on there. The plain text like I was saying, bash, python, perl, pretty easy to audit and understand what’s going on and
• 09:30 - 10:00 look for common mistakes. Within the payload you also have um you can also have more scripts. You’ve I’ve seen an uninstallation scripts are easy to audit. Some helper scripts for debugging or logging or error reporting that gets installed. And then you also have your normal native apps that can solve the by the actual application binary, the kernel modules, the libraries and if you want to go into it you can go and look at for native applications files through reverse engineering, fire a popper. So the types of issues I
• 10:00 - 10:30 was seeing when looking at these packages largely amount to time of check, time of use, except they weren’t doing any checks. There they’re operating within the temp directory which is world writable by anybody and uh their doing reads out of it that are untrusted. They’re doing writes into it that are untrusted, or they’re executing files in it without confirming that file is what they believe it should be. I’ve also seen the um some of these installers go
• 10:30 - 11:00 through and set 777 permissions on what gets installed or what gets written into different locations and that just allows everybody to mess with whatever you wrote there and it’s no longer a trusted install. So now we’re going to dig into the actual vulnerabilities I gotta see while looking at this for the past couple months. So I even found a number of privilege escalation issues um did some symbolic link abuse uh and got some arbitrary code execution which was fun. So the first one we have this installation we’re going to go through the payload
• 11:00 - 11:30 installs ah um and the installer util binary. That’s just a helper program for the installation to go through and then the post install script actually calls that with sudo with superuser powers and um and executes it. This is written to the temp directory. Temp directory is world writable. This is actually um the payload is installing as a current user um the way this installation is working and then the postinstall is calling that user owned uh
• 11:30 - 12:00 file with superuser powers. So in this instance I’m possibly an unprivileged user asking my IT administrator to install video conferencing software so I can join a meeting later that afternoon. So I would have audited this program, looked at at this, seen this vulnerability and then written up a little script to run in the background. A while loop say while this file doesn’t exist, do nothing and then when it when it does exist remove that file and put it in
• 12:00 - 12:30 my payload um in it’s place and then the post install is going to come around and execute that with root privileges and I’ve just escalated from my unprivileged user to my IT administrative’s group powers over my laptop. Another package I saw um during the pre-installation tries to do some cleanup in case it previously ru run the installer. It deletes this um install installation file in the temp directory and then later on it
• 12:30 - 13:00 writes to that and wants to make sure further installations unassociated with this install can also write to it so it sets 777 permissions uh using sudo and then also makes the owner of it um the current console user. So in this attack, any user on the system, any process that can write to temp the temp directory should be all of them can attack the system administrator or whoever’s inst installing the software. So you go ahead and you you touch that file ahead of
• 13:00 - 13:30 time so it exists so then you’re while loop can say while this file exists wait and do nothing and then once that file has been deleted during the pre-installation go through and create a symbolic link to a directory that you want to gain write access to such as slash applications and link that to that file’s name. Now when they’re going through the post-instillation it will try to write to this, it’ll fail. Things fail silently unless you’re doing an explicit checking of fail receipts during these scripts. And then when you
• 13:30 - 14:00 to get to this sudo change permissions to 777 that’s going to follow that symbolic link and make slash applications world writable. And then it’ll also go through and have the the happenstance of change in the ownership of applications to the current user. At this point we don’t really care about that because it’s world writable. We can drop whatever applications we want onto this system now. Another package was privilege escalation. This is not to um
• 14:00 - 14:30 current user to root, this is any user to the current installing user’s privileges. So they go through, they um during the preinstallation, in case it had run before, it deletes the 7 zip file um 7 zip arc uh binary in the temp directory and then it goes through and tries to extract the 7 zip um file that came with the pu payload and then executes that 7 zip file.
• 14:30 - 15:00 This is all happening within slash temp. So pretty straightforward. Before this installer is ever run I just put my payload as that name. You notice none of this is sudo. This isn’t running with root privileges so they can’t delete my file that’s sitting there so the RM fails. The overwrite from the unzip fails. But the execution happens because like I said, these fail silently inside the scripts. So I just went from just put putting a a file there on the system. The installer happily goes through and executes it as a current
• 15:00 - 15:30 installing user and I’ve gained privilege as them. Another uh example we have here is another symbolic link attack uh helper script outside of the payload so once you’re running the application this was for some debug reporting back to the um the developer. It tries to clean up on some of the logging it was doing in the temp directory for to capture that debug log. And so it does um an RM dash RF of this temp directory slash star and then it does a a remove the
• 15:30 - 16:00 deck directory and notably with a slash at the end of the path. So the attack here is before the script’s ever run and any user can go and write to that um that temp directory. I have a typo in my slide. It does say slash var I realize instead of slash temp but in the payload it should be slash temp slash SDU. And the way the symbolic links work that RM dash RF with the slash star will follow the symbolic link and delete everything in the user’s home directory in this
• 16:00 - 16:30 example and then the the remove directory command with the slash at the end will follow that symbolic link and blow away their home directory also. So now here you’re here left with the symbolic link that points to nothing because everything’s been deleted. Next we have a vulnerability that um has in the package info it says we’re going extract a payload into slash temp, specifically this razer synapse place using root privileges for running as the root user. So you don’t even need sudo here, everything just runs as uh the super user.
• 16:30 - 17:00 During the post-installation we’re going to change into that directory and then we’re going to look for star dot PKGs and install them once again with root privileges. So this has been fixed by razer and so we’re going to use this as our demo today. Going through everything I’ve talked about here. We’re going to download the package, um extract the files, audit the package, find this um this vulnerability, develop an exploit for it and then drop the
• 17:00 - 17:30 payload and watch it take place. So here I go through and I download the package. I once it’s on my system I’m going to go through the hacker way to create the directory, extract the contents of that package into the directory, and then I’m going to go look at the files. So I’m looking at the distribution file first to see if there’s any installer texts. I don’t see any installer texts so I’m going to move on. I’m going to look at the package
• 17:30 - 18:00 info to see what’s going on. Here we have that it’s extracted into the temp directory, it’s installing as root and there’s an extra little tidbit there that’s going to ask to restart at the end. It also notes here that there’s a post-install script so let’s go see what’s happening in that post-install script. We’re going to create our our collection dir directory so we don’t clutter the current directory, extract the pay uh the scripts into it and then we have all these extra files in here but we’re interested in what it named the post install
• 18:00 - 18:30 script. So now this is a whole post-install script. We’re reading it, we’re really fast at finding vulnerabilities. Here’s a vulnerability that that we just looked at. So we’re going to go through, we’re going to and and now we’re going to take advantage of this. Now that we know about this vulnerability, we can become the malicious user. So mallory is going to take over and she’s going to go through and develop the an a malicious payload, a package that will be installed um as part of this exploit. So we create a scripts directory. We
• 18:30 - 19:00 create our pre-installation script. So we put in the shebang. We tack we just attach a temp file and echo the current running user into it so we know what privilege this exploit runs at and then every good proof of concept pocs calc and so we’re also poc calc as part of our proof of concept. Now we have to make that executable or else it doesn’t run. And now we use package build to make up our package. We can give it an identifier that isn’t really
• 19:00 - 19:30 necessary but it just shows another aspect that you can label and call what these are. Here I specify that there’s no payload here. There’s no files being extracted and so it it doesn’t try to look to create that payload archive. It’s a script only package. We’ll create the package. I create that directory because it it um razer hasn’t been installed yet and I move the payload into that directory. And now I’m done. Now I wait for Bob to come around and run the installer. Bob’s going to do it right now. Bob’s not actually an administrator on
• 19:30 - 20:00 here so Alice is going to have to come and type in her admin password. It’s going to continue through. Poc calc. And then we go and look at the temp directory file to see that we just ran the root user here. [applause] In my final minute I want to um make some notes about what we just observed, that there was um some unexpected things happen when you do this
• 20:00 - 20:30 no payload um package that I just created there. When you when you install anything with a payload the installer creates a receipt and you can look in your system and all the packages that have been installed by that identifier and then you can give the uh give the package util that identifier and look at all the files that were installed during that process. However if no files are installed because there’s no payload, there’s no receipt that that package installer ever ran. So there’s no um appropriate system record that you could look up and audit
• 20:30 - 21:00 to see that this this ran. It also if you get super fancy, for minimal clicks and user interaction, and you can actually have that installer check in the distribution XML file that javascript can call system dot run and execute any scripts that are inside that script file. So within the system check when it’s like “Do you want to check if your system’s compatible?” you it will actually execute script which can extract an um a zip file and copy those files around your system. And that’s a one click install instead of all the
• 21:00 - 21:30 multiple clicks you normally have to go through. And then for for extra fun you can then call kill all installer and the installer quits itself and the user is immediately um back to its desktop. Some of these uh tips and tricks have been used by the people over at Praetorian. They wrote an awesome blog post series, 2 parts, um about bypassing application whitelisting, specifically Google santa umm to uh using the installer um the
• 21:30 - 22:00 quick quick version of that is application whitelisting happens at the basically the process ex executing level and installer is whitelisted reasonably and all of this installer check javascript, all of the pre and post script scripts run as part of that installer process and so they’re all whitelisted also. I’ll be stepping off to the stage as I think I ran a minute long and so I don’t have time to take your questions right now but uh I’d be happy to talk to you here. [applause]