{"@attributes":{"version":"2.0"},"channel":{"title":"theevilbit blog","link":"https:\/\/theevilbit.github.io\/","description":"Recent content on theevilbit blog","generator":"Hugo","language":"en","lastBuildDate":"Thu, 21 May 2026 00:00:00 +0000","item":[{"title":"Talks and Workshops","link":"https:\/\/theevilbit.github.io\/talks\/","pubDate":"Thu, 21 May 2026 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/talks\/","description":"

\n 2026\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

macOS Exploit Mixtape \u2013 Hack Like it’s the 80s \/CA: Gergely Kalman\/<\/strong> (Zer0Con)<\/em><\/p>\n

\n 2025\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

Finding Vulnerabilities in Apple Packages at Scale<\/strong> (SecurityFest, MacDevOpsYVR)<\/em><\/p>\n

Presentation<\/a><\/p>\n

Video - SecurityFest 2025<\/a><\/p>\n

Video - MacDevOpsYVR 2025<\/a><\/p>\n

The Evolution of macOS Security from the Desert to the Lake<\/strong> (MacSysAdmin, IT Defense 2026, University of Utah MacAdmins meeting)<\/em><\/p>"},{"title":"macOS LPE via the .localized directory","link":"https:\/\/theevilbit.github.io\/posts\/localized\/","pubDate":"Fri, 05 Dec 2025 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/localized\/","description":"

This blog is about a vulnerability on macOS which impacts every<\/em> third party installer if they try to run a privileged command from within the application bundle.<\/p>\n

This vulnerability has a very long history, and Apple never managed to properly fix it, and I never got a CVE only a note in the \u201cAdditional Recognition\u201d section.<\/p>\n

\n A Little History\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

There is a very long history of this specific bug that I kept reporting to Apple since 2018 (7 years!!). This bug can be exploited when we install third party software on the system. Actually this was my very first vulnerability I submitted to Apple, and my very first macOS talk back in 2019, called macOS - Getting root with benign AppStore apps<\/a>.<\/p>"},{"title":"The diskarbitrationd and storagekitd Audit Story Part 2","link":"https:\/\/theevilbit.github.io\/posts\/macos-audit-story-part2\/","pubDate":"Thu, 12 Dec 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/macos-audit-story-part2\/","description":"

\n Intro\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

Kandji’s Threat Research team recently performed an audit on the macOS diskarbitrationd and storagekitd system daemons, uncovering several vulnerabilities. Our team reported all of them to Apple through their responsible disclosure program, and as these are fixed now, we are releasing the details in this blog series - this is part two.<\/p>\n

In part one we covered a vulnerability which impacted the diskarbitrationd system daemon and allowed attacks to either escape the sandbox or escalate our privileges through user file systems.<\/p>"},{"title":"The diskarbitrationd and storagekitd Audit Story Part 1","link":"https:\/\/theevilbit.github.io\/posts\/macos-audit-story-part1\/","pubDate":"Fri, 08 Nov 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/macos-audit-story-part1\/","description":"

\n Intro\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

The Kandji team is always looking out for how to help keep your devices secure. In line with that, our Threat Research team performed an audit on the macOS diskarbitrationd and storagekitd system daemons, uncovering several vulnerabilities such as sandbox escapes, local privilege escalations, and TCC bypasses. Our team reported all of them to Apple through their responsible disclosure program, and as these are fixed now, we are releasing the details.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 35 - Persist through the NVRAM - The 'apple-trusted-trampoline'","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0035\/","pubDate":"Tue, 15 Oct 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0035\/","description":"

\n

This is part 35 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n

TL;DR - This is a practically completely useless persistence, as this can be only set and enabled when SIP is actually disabled. On the other hand I still find it a pretty amazing way to persist, as we can do that by putting a binary into NVRAM and get that executed. Here follows the details of the discovery.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 34 - launchd boot tasks","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0034\/","pubDate":"Thu, 10 Oct 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0034\/","description":"

\n

This is part 34 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n

The all mighty launchd<\/code>, contains an embedded plist file in its __TEXT __config<\/code> section, which contains various settings, BootStrap file locations (like LaunchDaemons<\/code> and LaunchAgents<\/code>) and it has also a Boot<\/code> key, which defines various services, which will be run upon boot. They are called boot tasks. Although this is documented in Jonathan Levin’s *OS Internals Vol I. book, I think this is a not well known, and in fact I also totally forgot about it until Matt<\/a> brought them to my attention recently.<\/p>"},{"title":"Dock Tile Plugins Could Be Used to Escalate Privileges","link":"https:\/\/theevilbit.github.io\/posts\/dock-tile-plugins-persistence\/","pubDate":"Fri, 19 Jul 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/dock-tile-plugins-persistence\/","description":"

\n Intro\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

I recently came across a persistence feature in macOS that’s tied to Dock tile plugins.<\/p>\n

Dock tiles are the small icons that appear on your Dock when an application runs. Plugins for these Dock tiles have been available since macOS Snow Leopard (10.6). In its developer documentation, Apple says about them:<\/p>\n

\n

A set of methods implemented by plug-ins…allow an app\u2019s Dock tile to be customized while the app is not running.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 33 - Widgets","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0033\/","pubDate":"Wed, 12 Jun 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0033\/","description":"

\n

This is part 33 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n

Widgets are application extensions you can place on your desktop to display some key information from your main app. Although Apple says developers shouldn’t implement any functionality there and just use them as a display, they are still apps that run on their own and we can run code inside them. We will explore how we can create them, use them as persistence and also investigate what widgets will automatically run on our system.<\/p>"},{"title":"CVE-2023-40424 - How Malware Can Bypass Transparency Consent and Control","link":"https:\/\/theevilbit.github.io\/posts\/cve-2023-40424\/","pubDate":"Fri, 24 May 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/cve-2023-40424\/","description":"

\n Intro\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

CVE-2023-40424 is a vulnerability that allows a root-level user to create a new user with a custom Transparency Consent and Control (TCC) database in macOS, which can then be used to access other users\u2019 private data.<\/p>\n

First discovered back in 2022, the vulnerability was fixed by Apple in 2023 in macOS Sonoma\u2019s initial release. But it was not fixed in earlier versions of macOS\u2014one more reason users and admins should update their Mac computers to Sonoma.<\/p>"},{"title":"How Apple Mitigates Vulnerabilities in Installer Scripts","link":"https:\/\/theevilbit.github.io\/posts\/apple-mitigates-vulnerabilities-installer-scripts\/","pubDate":"Fri, 15 Mar 2024 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/apple-mitigates-vulnerabilities-installer-scripts\/","description":"

\n Intro\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

Vulnerabilities are hot topics inside the world of security research and\u2014because of their potentially dramatic impacts\u2014outside as well. Unfortunately, the strategies and tactics that companies like Apple take to prevent specific vulnerabilities\u2014or even entire families of exploits\u2014typically attract less attention. But the fact is that engineering high-impact mitigations is typically more challenging than finding a single vulnerability.<\/p>\n

In this post, we\u2019ll look at Apple’s recent efforts to mitigate an entire class of installer-script vulnerabilities. We will cover:<\/p>"},{"title":"Launch and Environment Constraints Deep Dive","link":"https:\/\/theevilbit.github.io\/posts\/launch_constraints_deep_dive\/","pubDate":"Mon, 09 Oct 2023 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/launch_constraints_deep_dive\/","description":"

\n

UPDATE 2023.10.10.: After chatting with Thijs Alkemade, @xnyhps<\/a>, updated the XPC part of the post as I originally misunderstood Apple’s intent.<\/p>\n<\/blockquote>\n

Apple introduced Launch Constraints in macOS Ventura (13) as a response to some common attack scenarios. LC was probably the most impactful mitigation against various type of vulnerabilities. Before we dwell into LC let’s review a couple of old vulnerabilities, which would have been not exploitable if LC was present.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 32 - Dock Tile Plugins","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0032\/","pubDate":"Fri, 29 Sep 2023 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0032\/","description":"

\n

This is part 32 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n

When you write a series about something, there are some episodes which are less interesting, many boring stuff, but sometimes there are some true gems. While doing some research yesterday, I run into the Dock Tile Plugin feature in macOS, which turned out to be truly amazing from persistence point of view.<\/p>"},{"title":"macOS Service Management - The SMAppService API - Quick Notes","link":"https:\/\/theevilbit.github.io\/posts\/smappservice\/","pubDate":"Thu, 28 Sep 2023 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/smappservice\/","description":"

This is just a super quick post and some notes, about my experiences with SMAppService.<\/p>\n

Apple introduced the SMAppService API in macOS Ventura (13) to replace the older SMJobBless and SMLoginItemSetEnabled APIs. SMAppService should be used now to register any new Login Item, Launch Agent or Daemon.<\/p>\n

The API is super easy to use, even I could learn it from the developer docs, which is a big thing, and it means that it is indeed really easy as I suck as a developer.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 31 - BSM audit framework","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0031\/","pubDate":"Fri, 26 May 2023 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0031\/","description":"

\n

This is part 31 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n

macOS implements the OpenBSM audit framework created by McAfee, which allows someone to audit system events, like login, file access, etc\u2026 This has been part of the system for very long time. Auditing has several components, the main one being the kernel, which handles all the events. The main user mode process is auditd<\/code>, which is mainly responsible for logging. It\u2019s a huge framework, detailed very well by Jonathan Levin in his *OS Internal Part 3<\/code> book. I suggest reading that part, but you can also find some information here:<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 30 - The man config file - man.conf","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0030\/","pubDate":"Wed, 10 May 2023 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0030\/","description":"

\n

This is part 30 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n

I was watching an old BSidesLuxemburg 2019 talk by Aaron Jewitt, called “Threat Hunting On Linux And Mac With Auditbeat System Module”, it’s up on YouTube<\/a>. Aaron mentioned in one of the slides that you can persist using man.conf<\/code> files. It looked really odd, I tried to quickly Google it, but haven\u2019t found anything about it. So I took a look at the configuration file, and indeed, it turns out you can persist via man\u2019s configuration file, man.conf<\/code>, which can be found at \/private\/etc\/man.conf<\/code>.<\/p>"},{"title":"CVE-2022-22655 - TCC - Location Services Bypass","link":"https:\/\/theevilbit.github.io\/posts\/cve-2022-22655\/","pubDate":"Mon, 13 Feb 2023 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/cve-2022-22655\/","description":"

This is a quick blogpost about a vulnerability I covered in our Black Hat Europe 2022 talk<\/a> with Wojciech Regula<\/a>.<\/p>\n

In contrary to what people would expect, clients which can access location services are not maintained in one of the TCC databased, but in a separate location, and it’s maintained by locationd. This has been also recently covered by Howard Oakley, in his Privacy: what TCC does and doesn\u2019t<\/a> blogpost.<\/p>\n

TCC’s location services allowed client list is located inside \/var\/db\/locationd\/clients.plist<\/code>. This file is protected by the Sandbox\/TCC, thus we can’t modify it, and add new client, even if we have root privileges.<\/p>"},{"title":"CVE-2022-32929 - Bypass iOS backup's TCC protection","link":"https:\/\/theevilbit.github.io\/posts\/cve-2022-32929\/","pubDate":"Mon, 14 Nov 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/cve-2022-32929\/","description":"

\n Intro\n \n <\/i>\n Link to heading<\/span>\n <\/a>\n<\/h2>\n

Normally, when a users backup their iOS device, the backup is saved into ~\/Library\/Application Support\/MobileSync\/Backup<\/code> directory. The MobileSync<\/code> directory is properly protected by TCC, as the backup can contain photos, contact information, everything from the iOS device, and it might be unencrypted, so this is a whole lot of private information. It’s only accessible with Full Disk Access rights.<\/p>\n

The issue is that an attacker can invoke the AppleMobileBackup<\/code> utility and make a backup to a custom location. Thus completely bypassing the protected backup location.<\/p>"},{"title":"Prologue - The Lord of The Rules","link":"https:\/\/theevilbit.github.io\/posts\/prologue\/","pubDate":"Mon, 24 Oct 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/prologue\/","description":"

The world is changed:\nI feel it in the Sandbox,\nI feel it in the entitlements,\nI smell it in the kernel...\n\nMuch that once was is lost,\nonly a few live now who remember it.\n\nLord of the Rules\n\nIt began with the forging of the\nGreat Privacy Rules.\n          \nThree were given to the root user,\nimmortal, wisest...fairest of all beings.\n\nSeven to the users, great people\nand clients of the Apple spaceship.\n\nAnd Nine...nine rules were gifted\nto Apple processes which,\nabove all else, desire power.\n\nFor within these rules was bound\nthe strength and will to govern\nprivacy.\n\nBut they were all of them deceived.\n\n...for another rule was made.\n\nIn the land of Cupertino, in the fires of\nIntel CPUs, the Dark Lord Privacy forged\nin secret a Master Rule to control all\nothers.\n\n...and into this Rule he poured his\nwill to dominate all processes.\n\nOne Rule to rule them all...\n\nOne by one the Free lands of macOS\nfell to the power of the rule.\n\nBut there were some...who resisted.\n\nA last alliance of\nlegacy software,\ndisabled library validation\nand bounty hunters\nmarched against the armies of TCC.\n\nOn the slopes of El Capitan they fought\nfor the freedom of macOS.\n<\/code><\/pre>"},{"title":"CVE-2017-2533 - The details behind","link":"https:\/\/theevilbit.github.io\/posts\/cve-2017-2533\/","pubDate":"Mon, 29 Aug 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/cve-2017-2533\/","description":"
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
CVE-2017-2533<\/a>  was part of a chain of vulnerabilities, used at pwn2own 2017 found by the phoenhex team. They wrote a blogpost about it here<\/a>. This vulnerability led me to find CVE-2022-32780, which I detailed at Black Hat Asia 2022<\/a>. Although the nature of CVE-2017-2533 was discussed by the authors, but the actual code part was never truly revealed, and I always wondered about the full details. Now I took the time to dig up the details, including how it was fixed, and why the fix solves the problem.<\/p>"},{"title":"AMFI Launch Constraints - First Quick Look","link":"https:\/\/theevilbit.github.io\/posts\/amfi_launch_constraints\/","pubDate":"Tue, 14 Jun 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/amfi_launch_constraints\/","description":"
Dropping some initial quick notes for a new security feature I ran into on macOS Ventura. It’s called “Launch Constraints” and lives inside AMFI.<\/p>\n
Do the following experiment: Copy Terminal.app<\/code> to your HOME folder and try to run it on Monterey and Ventura. On the former it will work without any issues, on the other it will fail, and we will get the following error:<\/p>\n
2022-06-14 05:59:55.254678+0200 0x5481     Default     0x0                  0      0\nkernel: (AppleMobileFileIntegrity) AMFI: Launch Constraint Violation (enforcing), error\ninfo: c[1]p[1]m[1]e[2], (Constraint not matched) launching proc[vc: 1 pid: 1112]:\n\/Users\/ace\/Terminal.app\/Contents\/MacOS\/Terminal, launch type 0, failure proc [vc: 1 pid:\n1112]: \/Users\/ace\/Terminal.app\/Contents\/MacOS\/Terminal\n<\/code><\/pre>
This is interesting. If we copy it to other locations, it will fail as well. The reason looks to be something called “Launch Constraint”. So it seems that it will disallow the execution of system apps outside their location. This is pretty nice, as this has been abused plenty of times in the past, as moving them out of their place usually allowed someone inject code into them. Remember these TCC bypasses?<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 29 - amstoold","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0029\/","pubDate":"Tue, 08 Mar 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0029\/","description":"
\n
This is part 29 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
When doing some research on macOS I came across the following LaunchAgent: \/System\/Library\/LaunchAgents\/com.apple.amstoold.plist<\/code>. Its content is the following.<\/p>\n
<?xml version="1.0" encoding="UTF-8"?><\/span>\n<\/span><\/span><!DOCTYPE plist PUBLIC "-\/\/Apple\/\/DTD PLIST 1.0\/\/EN" "http:\/\/www.apple.com\/DTDs\/PropertyList-1.0.dtd"><\/span>\n<\/span><\/span><plist<\/span> version=<\/span>"1.0"<\/span>><\/span>\n<\/span><\/span><dict><\/span>\n<\/span><\/span>\t<key><\/span>EnablePressuredExit<\/key><\/span>\n<\/span><\/span>\t<true\/><\/span>\n<\/span><\/span>\t<key><\/span>EnableTransactions<\/key><\/span>\n<\/span><\/span>\t<true\/><\/span>\n<\/span><\/span>\t<key><\/span>Label<\/key><\/span>\n<\/span><\/span>\t<string><\/span>com.apple.amstoold<\/string><\/span>\n<\/span><\/span>\t<key><\/span>LaunchEvents<\/key><\/span>\n<\/span><\/span>\t<dict><\/span>\n<\/span><\/span>\t\t<key><\/span>com.apple.distnoted.matching<\/key><\/span>\n<\/span><\/span>\t\t<dict><\/span>\n<\/span><\/span>\t\t\t<key><\/span>com.apple.nfcd.ams.accessory<\/key><\/span>\n<\/span><\/span>\t\t\t<dict><\/span>\n<\/span><\/span>\t\t\t\t<key><\/span>Name<\/key><\/span>\n<\/span><\/span>\t\t\t\t<string><\/span>com.apple.nfcd.ams.accessory<\/string><\/span>\n<\/span><\/span>\t\t\t<\/dict><\/span>\n<\/span><\/span>\t\t<\/dict><\/span>\n<\/span><\/span>\t\t<key><\/span>com.apple.notifyd.matching<\/key><\/span>\n<\/span><\/span>\t\t<dict><\/span>\n<\/span><\/span>\t\t\t<key><\/span>com.apple.ams.privateListeningChanged<\/key><\/span>\n<\/span><\/span>\t\t\t<dict><\/span>\n<\/span><\/span>\t\t\t\t<key><\/span>Notification<\/key><\/span>\n<\/span><\/span>\t\t\t\t<string><\/span>com.apple.ams.privateListeningChanged<\/string><\/span>\n<\/span><\/span>\t\t\t<\/dict><\/span>\n<\/span><\/span>\t\t<\/dict><\/span>\n<\/span><\/span>\t<\/dict><\/span>\n<\/span><\/span>\t<key><\/span>MachServices<\/key><\/span>\n<\/span><\/span>\t<dict><\/span>\n<\/span><\/span>\t\t<key><\/span>com.apple.xpc.amstoold<\/key><\/span>\n<\/span><\/span>\t\t<true\/><\/span>\n<\/span><\/span>\t<\/dict><\/span>\n<\/span><\/span>\t<key><\/span>ProcessType<\/key><\/span>\n<\/span><\/span>\t<string><\/span>Background<\/string><\/span>\n<\/span><\/span>\t<key><\/span>ProgramArguments<\/key><\/span>\n<\/span><\/span>\t<array><\/span>\n<\/span><\/span>\t\t<string><\/span>\/usr\/local\/bin\/amstoold<\/string><\/span>\n<\/span><\/span>\t<\/array><\/span>\n<\/span><\/span>\t<key><\/span>RunAtLoad<\/key><\/span>\n<\/span><\/span>\t<true\/><\/span>\n<\/span><\/span><\/dict><\/span>\n<\/span><\/span><\/plist><\/span>\n<\/span><\/span><\/code><\/pre><\/div>
If we examine it closely we can notice that the related binary is \/usr\/local\/bin\/amstoold<\/code>. This is very interesting as this file doesn’t exists on default macOS installations. This means that if we create it, it will be started as the user upon login. As the launchd file is SIP protected, we can’t even remove it, and even if we would, it likely would come back at the next OS update.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 28 - Authorization Plugins","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0028\/","pubDate":"Wed, 09 Feb 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0028\/","description":"
\n
This is part 28 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This persistence mechanism was described in very detail by Chris Ross<\/a> in his blogpost: Persistent Credential Theft with Authorization Plugins<\/a>. He also developed sample code, which can be found on his GitHub<\/a>. Thus this blog will only focus on the high level summary, and some changes that happened since he wrote that post.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 27 - Dock shortcuts","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0027\/","pubDate":"Tue, 08 Feb 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0027\/","description":"
\n
This is part 27 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This persistence is another gem I found in Leo Pitt<\/a>’s Modern macOS Persistence<\/a> talk.<\/p>\n
macOS Dock stores shortcuts for applications, that we would like to access through the, well… Dock. It stores all settings in ~\/Library\/Preferences\/com.apple.dock.plist<\/code>. Although we can edit this PLIST directly, we can also use the defaults<\/code> utility to change it. For example adding a new entry:<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 26 - Finder Sync Plugins","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0026\/","pubDate":"Sat, 05 Feb 2022 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0026\/","description":"
\n
This is part 26 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This method was documented very detailed by Patrick Wardle in his blogpost<\/a> back in 2016. It was also covered by Leo Pitt<\/a> in his Modern macOS Persistence<\/a> talk, and he also made a POC, which can be found at his GitHub<\/a>. With there is really nothing to add here, so this post will be only a high level summary, for everything else refer to the above resources.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 25 - Apache2 modules","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0025\/","pubDate":"Wed, 15 Dec 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0025\/","description":"
\n
This is part 25 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
Possibly a less known feature that macOS has a built-in Apache2 web server, which can be enabled anytime. Just as other Apache2 servers, it also supports the load of custom modules, and this is what we will explore here briefly for persistence. For a detailed web server setup, I recommend the following articles:\nSetting up a local web server on a Mac - Apple Community<\/a>\nSetting up a local web server on macOS 12\u2026 - Apple Community<\/a><\/p>"},{"title":"Beyond the good ol' LaunchAgents - 24 - Folder Actions","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0024\/","pubDate":"Thu, 02 Dec 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0024\/","description":"
\n
This is part 24 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
Folder action persistence has been documented by Cody Thomas<\/a> back in 2019 in his blog<\/a>. I think he did an awesome job, and everything he wrote still applies today. I wanted to take it a bit further and see if I can persist without any user prompts, and it turned out it is possible. I will also talk about its TCC implications.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 23 - emond, The Event Monitor Daemon","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0023\/","pubDate":"Sat, 27 Nov 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0023\/","description":"
\n
This is part 23 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This post will be about emond<\/code>, Apple’s Event Monitor daemon.<\/p>\n
I think almost everything has been already told about this method and emond<\/code> in general by James Reynolds here<\/a> and xorrior<\/a> here<\/a> so really not much left for me. There is no point for me replicating their awesome posts, so please just read them. That’s it! Thank you for reading! \u00af\\(\u30c4)<\/em>\/\u00af\n.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 22 - LoginHook and LogoutHook","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0022\/","pubDate":"Wed, 24 Nov 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0022\/","description":"
\n
This is part 22 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This method is considered deprecated by Apple, yet it still works.<\/p>\n
LoginHooks and LogoutHooks have been widely documented by many people, so this post is mostly for completeness. The official, Apple documentation can be found here: Customizing Login and Logout<\/a><\/p>\n
LoginHooks and LogoutHooks are executed, well… at logins and logouts just as the name suggest, and they are run as root. They are set in the preferences of the  com.apple.loginwindow<\/code> process, and so it’s stored in the file \/var\/root\/Library\/Preferences\/com.apple.loginwindow.plist<\/code>.<\/p>"},{"title":"CVE-2021-30808 - CVE-2021-1784 strikes back - TCC bypass via mounting","link":"https:\/\/theevilbit.github.io\/posts\/cve-2021-30808\/","pubDate":"Fri, 29 Oct 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/cve-2021-30808\/","description":"
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
CVE-2021-1784 was a vulnerability that allowed an attacker to bypass TCC by mounting over the  ~\/Library\/Application Support\/com.apple.TCC<\/code> directory and providing a new TCC database. We covered this with Wojciech Regula<\/a> in or 20+ ways to bypass your mac os privacy mechanisms<\/a> BlackHat USA talk. This was properly fixed in Big Sur.<\/p>\n
\n  The Vulnerability\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
I don’t know why but I started to experiment with it again in the very first version of Monterey beta, and found that although the exploit doesn’t work, we can mount over the ~\/Library<\/code> directory. Interestingly this wasn’t possible in Big Sur, thus this bug is a regression.<\/p>"},{"title":"About","link":"https:\/\/theevilbit.github.io\/about\/","pubDate":"Fri, 22 Oct 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/about\/","description":"
My name is Csaba Fitzl or also known as “theevilbit”, which comes from RFC 3514<\/a>. I graduated in 2006 as a computer engineer. I have worked for 6 years as a network engineer, troubleshooting and designing big networks. After that, I have worked for 8 years as a blue and red teamer focusing on network forensics, malware analysis, adversary simulation, and defense bypasses. Then I was working for OffSec and developed the EXP-312: Advanced macOS Control Bypasses<\/a> course. Currently I’m working for Kandji<\/a> as a Principal macOS Security Researcher.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 21 - Re-opened Applications","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0021\/","pubDate":"Tue, 12 Oct 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0021\/","description":"
\n
This is part 21 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This method was also documented by Patrick Wardle, in his original Methods of Malware Persistence<\/a> white paper and also at MITRE ATT&CK\u00ae<\/a>.<\/p>\n
When we restart macOS, we are presented with the following window:<\/p>\n
\"Re-open<\/p>\n
I guess, most users keep it selected, and then macOS will reopen all apps.<\/p>"},{"title":"Getting started in macOS security","link":"https:\/\/theevilbit.github.io\/posts\/getting_started_in_macos_security\/","pubDate":"Mon, 27 Sep 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/getting_started_in_macos_security\/","description":"
Many people used to ask me where to start learning about macOS security or exploitation, what are the trainings or books out there that can help with this topic. Nowadays there are a few trainings, which can get you started. Other great resources for macOS security are blog posts and conference talks.<\/p>\n
I thought I will try to collect some resources that can help people to get started in this field.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 20 - Terminal Preferences","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0020\/","pubDate":"Wed, 22 Sep 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0020\/","description":"
\n
This is part 20 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This is another application specific persistence method, related to the Terminal application.<\/p>\n
In the Terminal Preferences, under the Profiles tab, we can set a command that will be executed upon Terminal’s startup. This is shown in the screen below.<\/p>\n
\"Terminal<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 19 - Periodic Scripts","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0019\/","pubDate":"Fri, 06 Aug 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0019\/","description":"
\n
This is part 19 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This post has been long due, as it’s one of my favorite persistence tricks. Up until Big Sur 11.5 you could also exploit it for privilege escalation if Homebrew was installed on the system.<\/p>\n
Periodic scripts have a FreeBSD origin. These scripts are doing some maintenance tasks on the system, and scheduled to be run on a daily, weekly and monthly basis.<\/p>"},{"title":"GateKeeper - Not a Bypass (Again)","link":"https:\/\/theevilbit.github.io\/posts\/gatekeeper_not_a_bypass\/","pubDate":"Tue, 29 Jun 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/gatekeeper_not_a_bypass\/","description":"
This post is about two techniques that can be useful for someone to evade GateKeeper in a red team engagement or pentest. According to Apple these are not considered bypasses, and everything works as expected.<\/p>\n
\n  mmap\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
Part of GateKeeper is implemented on macOS in the Quarantine.kext<\/code>  kernel extension. It uses the MAC policy framework to insert hooks on the system on various points. These functions are named as hook*. Let’s take a look on what is implemented.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 18 - X11 and XQuartz","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0018\/","pubDate":"Mon, 28 Jun 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0018\/","description":"
\n
This is part 18 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
I learned about XQuartz<\/a> while reading Armin Briegel’s \u200emacOS Terminal and shell<\/a> book. It’s one of the alternative third party terminals we can install on macOS. As most terminals, this one also offers unique options to persist on the system.<\/p>\n
X11 used to be part of OS X, till 10.7, and it was open source, which we can find here<\/a>.<\/p>"},{"title":"macOS Monterey Shortcuts - First look","link":"https:\/\/theevilbit.github.io\/posts\/monterey_shortcuts\/","pubDate":"Thu, 10 Jun 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/monterey_shortcuts\/","description":"
Apple announced macOS Monterey (macOS 12) this week at WWDC, and one of its new features that caught my eye is Shortcuts<\/strong>. It’s already available on iOS, but it made its way to macOS. My security focused brain immediately thought about how cool this feature could be for red teamers or pentesters to persist on macOS :) So I decided to take a quick look on the new functionality, focusing on how it works. All of the below information is based on macOS Monterey Developer Beta 1.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 17 - Color Pickers","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0017\/","pubDate":"Mon, 31 May 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0017\/","description":"
\n
This is part 17 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
Color pickers??? It’s this menu, where we can select a color:<\/p>\n
\"\"<\/p>\n
To my surprise we can install our own color pickers on the system, and add custom ones. There are quite a few of these, some are even open source, like this: GitHub - viktorstrate\/color-picker-plus: An Improved Color Picker for macOS<\/a>. Github is full of color picker codes, mostly written in Swift. We don’t really need those, unless we want to be stealthy and hide our code inside a legitimate picker.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 16 - Screen Saver","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0016\/","pubDate":"Sun, 30 May 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0016\/","description":"
\n
This is part 16 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
Screen savers have been detailed recently by Leo Pitt<\/a>on his blog post: “Saving Your Access”<\/a>. Considering that he already wrote most of the interesting stuff, I will try to show some new information, but there will be some overlap.<\/p>\n
Screen savers are macOS bundles with the bundle extension of .saver<\/code>. Their Info.plist<\/code> file doesn’t contain anything screen saver specific, so we can really use any bundle with the right extension.<\/p>"},{"title":"NOCVE - TeamViewer Local Privilege Escalation Vulnerability","link":"https:\/\/theevilbit.github.io\/posts\/teamviewer_lpe\/","pubDate":"Wed, 26 May 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/teamviewer_lpe\/","description":"
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
This is a rather old vulnerability I found in TeamViewer back in 2020, and reported it through VCP\/iDefense. TeamViewer fixed the vulnerability last November, but somehow I missed it, and became aware of it only recently. Their advisory can be found here:\nNovember updates - Security patches \u2014 TeamViewer Support<\/a><\/p>\n
The TeamViewer macOS client used a PrivilegedHelperTool named com.teamviewer.Helper<\/code> to perform specific tasks that require root<\/code>\npermissions. Back in 2020 it used a deprecate model to perform IPC communication, called Distributed Objects. It was wide open, and any client could invoke the remote object’s functions, and some of those lead to direct privilege escalation.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 15 - xsanctl","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0015\/","pubDate":"Wed, 12 May 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0015\/","description":"
\n
This is part 15 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
I run into this not so exciting persistent method when I was investigating xsanctl<\/code> for… other… reasons… xsanctl<\/code> is a “Xsan file system control utility”, which allows us to mount and manage Xsans.<\/p>\n
The xsanctl<\/code> binary can be found at \/System\/Library\/Filesystems\/acfs.fs\/Contents\/bin\/xsanctl<\/code>, however when we simply run the command it is run from \/usr\/sbin\/xsanctl<\/code>. If we check, this is a symbolic link.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 14 - atrun","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0014\/","pubDate":"Tue, 27 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0014\/","description":"
\n
This is part 14 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
The at<\/code> command set is a heritage *nix job scheduler on macOS. Although it’s slowly being deprecated, it’s still available on Big Sur, although disabled by default.<\/p>\n
\n  Enabling atrun\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
As described by atrun<\/code>’s man page, the scheduler can be enabled using the following command:<\/p>"},{"title":"Experiences with Apple Security Bounty","link":"https:\/\/theevilbit.github.io\/posts\/experiences_with_asb\/","pubDate":"Fri, 23 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/experiences_with_asb\/","description":"
Since Apple started their Apple Security Bounty<\/a> program I have submitted around 50 cases to their product security team. I thought I will share my experiences working with Apple in the past 2 years. This will be useful to anyone thinking about participating in the program, and will help setting up expectations.<\/p>\n
Beyond Apple I do bug bounties also in other programs, like HackerOne, BugCrowd, VCP, ZDI or sometimes just working directly with vendors, so I have a good pool of other cases I can  compare to.<\/p>"},{"title":"CVE-2020-9900 & CVE-2021-1786 - Abusing macOS Crash Reporter","link":"https:\/\/theevilbit.github.io\/posts\/macos_crashreporter\/","pubDate":"Tue, 20 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/macos_crashreporter\/","description":"
I plan to discuss two symlink attacks in this blog post. The first, more severe one, CVE-2020-9900 was reported by Zhongcheng Li (CK01<\/a>) of Zero-dayits Team of Legendsec at Qi’anxin Group, and fixed in Catalina 10.15.6<\/a>. Apple’s advisory said that with a symlink attack it was possible to elevate privileges. I never saw a public document about this bug, so I only assume that I will describe the actual issue here.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 13 - Audio Plugins","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0013\/","pubDate":"Mon, 19 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0013\/","description":"
\n
This is part 13 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This is another one of my favorites for some reason. macOS being a popular audio editing device, supports external audio drivers and plugins. @xorrior<\/a> wrote a very extensive blog post about these at his website, here: Audio Unit Plug-ins. Legitimate Un-signed Code Execution | by Christopher Ross | Posts By SpecterOps Team Members<\/a><\/p>"},{"title":"Beyond the good ol' LaunchAgents - 12 - QuickLook Plugins","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0012\/","pubDate":"Mon, 05 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0012\/","description":"
\n
This is part 12 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
This technique is very similarly to Spotlight Importers, but heavily sandboxed. It\u2019s even more limited as the user need to specifically want to preview the file.<\/p>\n
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
This will be a short post and it goes hand in hand with my previous one<\/a> that detailed the use of Spotlight Importers for persistence. Jonathan\u2019s book also details QuickLook plugins and fG! (@osxreverser) on Twitter<\/a> also said that he used to play with this, so I decided to take a look as well.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 11 - Spotlight Importers","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0011\/","pubDate":"Sat, 03 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0011\/","description":"
\n
This is part 11 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
It works, but very limited due to heavy sandboxing, you can only read and copy files to your sandbox folder or consume some CPU power. If you have a way to escape sandbox then go for it, or could be used as part of a multi-part malware.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 10 - Application script files","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0010\/","pubDate":"Fri, 02 Apr 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0010\/","description":"
\n
This is part 10 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
I started to explore to possibility of persisting on macOS through script files contained in an application. The basic idea is that if we find a script file, which is being executed by a given application, we can edit that script file, put our code inside, and wait for an execution. Such technique is highly dependent on the applications the user has installed, so I looked through first how rare \/ frequent is having such scripts inside applications. I started with the below searches:<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 9 - Preference Pane","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0009\/","pubDate":"Thu, 25 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0009\/","description":"
\n
This is part 9 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
Preference panes on macOS are plugins to the System Preferences.app<\/code>. These panes can extend the functionality of the app, and typically allow you to modify configuration settings for your app. These admins are loaded when the user selects them, so they are not perfect from persistence point of view, as it requires user interaction, but can still be a thing.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 8 - Hammerspoon","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0008\/","pubDate":"Tue, 23 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0008\/","description":"
\n
This is part 8 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This idea came from my colleague @dejandayoff<\/a>. It’s another application specific persistence option, related to Hammerspoon<\/a>. The app is an automation tool, that allows macOS scripting through LUA scripting language. We can even embed full AppleScript code as well as run shell scripts.<\/p>\n
The app looks for a single file, ~\/.hammerspoon\/init.lua<\/code>, and when started the script will be executed. They have plenty of examples on their Getting Started<\/a> page, and an extensive API documentation<\/a>.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 7 - xbar plugins","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0007\/","pubDate":"Mon, 22 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0007\/","description":"
\n
This is part 7 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
This technique came from @bradleyjkemp<\/a> in one of his Twitter posts<\/a>.<\/p>\n
xbar<\/a> is an application that can put the output of a script into the menubar. The scripts should be placed in ~\/Library\/Application\\ Support\/xbar\/plugins\/<\/code>. Standard shell scripts are supported, and so I tried the one listed on their GitHub page as an example.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 6 - SSHRC","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0006\/","pubDate":"Sun, 21 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0006\/","description":"
\n
This is part 6 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
I learned about this trick from @0xdade<\/a> when he posted<\/a> it on Twitter.<\/p>\n
If we create a file in the user’s HOME directory at ~\/.ssh\/rc<\/code> it will be executed prior to the user’s login shell becomes available. The man page of sshd<\/code> describes this in more detail.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 5 - Pluggable Authentication Modules (PAM)","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0005\/","pubDate":"Sat, 20 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0005\/","description":"
\n
This is part 5 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
PAM<\/a> originated from Red Hat Linux, but made its way to most *nix based system, including macOS. It’s a modular system, that allows third party additions to various authentication related operations. I highly recommend checking out the FreeBSD documentation<\/a> to get a full picture.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 4 - cron jobs","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0004\/","pubDate":"Thu, 18 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0004\/","description":"
\n
This is part 4 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
cron<\/a> is probably one of the most well known persistence mechanisms for macOS and basically any *nix operating system. It was originally developed for Unix back in 1975, and made its way to most platforms, which has Unix origins, like Linux, FreeBSD and thus macOS.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 3 - Login Items","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0003\/","pubDate":"Wed, 17 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0003\/","description":"
\n
This is part 3 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
To clear up some expectations. The below tweet is not about this method, that is deferred for now. :)<\/p>\n
\"Twitter\"<\/p>\n
Login items are probably one of the most well documented methods to persist on macOS. It’s widely used by various application to launch themselves upon user login. These applications show up in the menubar most of the time.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 2 - iTerm2 startup","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0002\/","pubDate":"Tue, 16 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0002\/","description":"
\n
This is part 2 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
If the first part was about Terminal<\/code> and shell profiles, it’s worth to mention iTerm2<\/a>, which is a popular Terminal alternative on macOS. It’s being used by many people, especially power users.<\/p>\n
When we start iTerm2<\/code> it starts the same shell environment as Terminal<\/code>,  and thus the same startup files apply here as well. However this application has an additional way to execute code.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - 1 - shell startup files","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_0001\/","pubDate":"Sun, 14 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_0001\/","description":"
\n
This is part 1 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction<\/a>.<\/p>\n<\/blockquote>\n
Shell startup files are executed when our shell environment like zsh<\/code> or bash<\/code> is starting up. macOS defaults to \/bin\/zsh<\/code>  these days, and whenever we open Terminal<\/code> or SSH into the device, this is the shell environment we are placed into. bash<\/code> and sh<\/code> are still available, however they have to be specifically started.<\/p>"},{"title":"Beyond the good ol' LaunchAgents - Introduction","link":"https:\/\/theevilbit.github.io\/beyond\/beyond_intro\/","pubDate":"Sun, 14 Mar 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/beyond\/beyond_intro\/","description":"
I was always amazed by @Hexacorn<\/a>’s Beyond good ol’ Run key<\/a> blog post series, which collects various persistence<\/a> methods on Windows. It’s an awesome series, which has 133 parts at the time of this writing. I find them pretty cool, and if you are doing either offensive or defensive work on Windows, this is  a must read and follow blog.<\/p>\n
In the past years as my interest in macOS grew, and now that I’m mostly doing only macOS related research and studies I started to came across many - many tricks, which allows someone to do persistence on macOS beyond just the LaunchDaemons<\/code> or LaunchAgents<\/code> directories, which is used to store the launchd<\/code> startup files. This location is probably as classic on macOS as the Run<\/code> registry key on Windows. I did write about two different techniques in my regular posts (here<\/a> and here<\/a>), but it never became a full series. So I started to think about writing posts for each idea I came across, just like Adam does for Windows, but I would do for macOS. With almost the same name, just swapping Run key<\/code> with LaunchAgents<\/code> and name it Beyond the good ol' LaunchAgents<\/code>.<\/p>"},{"title":"About com.apple.private.security.clear-library-validation","link":"https:\/\/theevilbit.github.io\/posts\/com.apple.private.security.clear-library-validation\/","pubDate":"Tue, 19 Jan 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/com.apple.private.security.clear-library-validation\/","description":"
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
On macOS 10.15.2 Apple introduced the com.apple.private.security.clear-library-validation<\/code> entitlement, which is slowly replacing the previously used com.apple.security.cs.disable-library-validation<\/code> entitlement on system binaries. Although their impact is the about the same, the way they work is different. While library validation is automatically disabled using com.apple.security.cs.disable-library-validation<\/code>, with com.apple.private.security.clear-library-validation<\/code>, the application has to disable it for itself through a csops<\/code> system call.<\/p>\n
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
With the release of Big Sur, I noticed that many of the system binaries have a new entitlement, which I didn’t see before, and that is com.apple.private.security.clear-library-validation<\/code> (later it turned out that it was introduced earlier, but I didn’t know about it that time). These applications possessed the com.apple.security.cs.disable-library-validation<\/code> before, so it seemed that this is being replaced with a new one. The name suggest similarity, and testing it also confirmed, that these binaries can still load third party plugins signed by non Apple developers. This means that these entitlements have the same impact.<\/p>"},{"title":"Divide and Conquer - A technique to bypass NextGen AV","link":"https:\/\/theevilbit.github.io\/posts\/divide_and_conquer\/","pubDate":"Sun, 17 Jan 2021 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/divide_and_conquer\/","description":"
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
This blog post describes a generic technique I called internally on our red team assessment “Divide and Conquer”, which can be used to bypass behavioral based NextGen AV detection. It works by splitting malicious actions and API calls into distinct processes.<\/p>\n
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
Back in 2019 I was part of a red team, where our daily activity was to bypass a specific NextGen AV. I had this idea I called “divide and conquer”. I was so excited about it, that I had to name it :) That time I didn’t want to publicly write about it, and I also haven’t found any sources on the Internet that describes this idea (which describes my poor searching skills). Time passed, and by the time I could have write about it, I forgot. Then a few days ago Adam (@Hexacorn)<\/a> posts this<\/a>:<\/p>"},{"title":"CVE-2020-9771 - Reversing Engineering the Fix","link":"https:\/\/theevilbit.github.io\/posts\/reversing_cve_2020_9771\/","pubDate":"Sun, 13 Dec 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/reversing_cve_2020_9771\/","description":"
When I originally found the mount_apfs<\/code> bug back in December, 2019, I honestly had no idea what was the root cause of it, nor had a clue how to even start looking into it. The only thing I knew for sure that the answer is within kernel. My macOS knowledge was still quite fresh that time (and even today), and was busy with so many other stuff that I never had the time to start looking into it.<\/p>"},{"title":"NOCVE - Microsoft Teams for macOS Local Privilege Escalation","link":"https:\/\/theevilbit.github.io\/posts\/microsoft_teams_lpe\/","pubDate":"Tue, 17 Nov 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/microsoft_teams_lpe\/","description":"
This blog post shares the details of a vulnerability Offensive Security discovered in the XPC service of Microsoft Teams. Although Microsoft secured these services reasonably well, we will see how small code mistakes can have serious impacts.<\/p>\n
We reported the issue to MSRC, but unfortunately Microsoft decided that  \u201cthe finding is valid but does not meet our bar for immediate servicing.\u201d While they have since hardened the XPC service, it remains exploitable.<\/p>"},{"title":"Let's talk macOS Authorization","link":"https:\/\/theevilbit.github.io\/posts\/macos_authorization\/","pubDate":"Thu, 22 Oct 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/macos_authorization\/","description":"
This is a blog post I wanted to write for a while now, but somehow never got the time for it, and I also knew that it will require lots of time, so I kept delaying it. I finally kicked my ass, sat down, and wrote it.<\/p>\n
The goal of the post is to cover many aspects of authorization, which I found interesting from security perspective. Honestly, partially for selfish reasons so I will have a goto summary when I need to lookup something later instead of browsing through 8-10 different articles. All of these information I try catch here in one post, are known, but spread all over the place in various blog posts and articles, and I never found a good, central location with all the details. Also some of the items are very confusing and it took me some time to clear things in my head as not everything is obvious or intuitive.<\/p>"},{"title":"CVE-2020-9771 - mount_apfs TCC bypass and privilege escalation","link":"https:\/\/theevilbit.github.io\/posts\/cve_2020_9771\/","pubDate":"Fri, 03 Jul 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/cve_2020_9771\/","description":"
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
We could mount the entire file system through APFS snapshots as read-only, with the noowners<\/code> flag, which enables us accessing (almost) every file in the file system, including data (documents, files, etc…) of every user on the system, including those protected by Apple’s privacy framework (TCC). Even with the Guest account we could read files of admin accounts as Guest! \ud83d\ude31<\/p>\n
This could be achieved with a single command, for example:\nmount_apfs -o noowners -s com.apple.TimeMachine.2019-11-17-141812.local \/System\/Volumes\/Data \/tmp\/snap<\/code><\/p>"},{"title":"CVE-2020-14977 - Secure coding XPC Services - Part 5 - PID reuse attacks","link":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part5\/","pubDate":"Tue, 16 Jun 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part5\/","description":"
In the last post of the series we will see another typical issue, where XPC services using the connecting process’s ID (PID) to verify the client instead of the audit token. We will use F-Secure SAFE again for our case study, the vulnerability was fixed in 17.8 and it was assigned CVE-2020-14977.<\/p>\n
\n  The root cause\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
The XPC services of F-Secure SAFE use the process ID (PID) to verify the client’s signature, as can be seen in the code below.<\/p>"},{"title":"CVE-2020-14978 - Secure coding XPC Services - Part 4 - Improved client authorization","link":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part4\/","pubDate":"Fri, 12 Jun 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part4\/","description":"
\n  F-Secure SAFE XPC service exploitation (CVE-2020-14978)\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h1>\n
\n  Intro\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
In this post we will look into an other case study which will show us (again) why XPC client verification is crucial in XPC security, and how added authorization checks can slightly improve (but not fix) the problem. The F-Secure SAFE XPC services installed on macOS were not sufficiently hardened, and a malicious actor had the ability to interact with them. The vulnerability was fixed in version 17.8, it allowed an attacker to query specific settings, or if authorization used, it could prompt a user for password on behalf of F-Secure and ask for permissions to change settings.<\/p>"},{"title":"The AMFI MACF policy system call","link":"https:\/\/theevilbit.github.io\/posts\/amfi_syscall\/","pubDate":"Tue, 09 Jun 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/amfi_syscall\/","description":"
On macOS, one popular technique to inject code into other applications is leveraging the DYLD_INSERT_LIBRARIES<\/code> environment variable, which I wrote about in 2019 DYLD_INSERT_LIBRARIES DYLIB injection in macOS \/ OSX<\/a>. This variable can store a colon-separated list of dynamic libraries to load before the ones specified in the target process.<\/p>\n
Several limitations apply to when this injection technique can be used and when it cannot, which I also discussed. I revisited this topic, not only because things might have changed since then but also to ensure that I didn\u2019t miss anything. It turned out to be a wise move and a useful exercise.<\/p>"},{"title":"CVE-2020-0984 - Secure coding XPC Services - Part 3 - Incorrect client verification","link":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part3\/","pubDate":"Fri, 29 May 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part3\/","description":"
\n  Microsoft AutoUpdate macOS privilege escalation vulnerability (CVE-2020-0984)\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h1>\n
\n  Introduction\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
This is the third post in my series which is trying to help Apple developers to avoid typical insecure coding practices. This one will highlight why XPC client hardening and proper verification is extremely important when we use XPC messaging on macOS between clients that run as a normal user and services that run as root. If this validation is not right, it opens up the possibility for an attacker to run privileged commands or worse case, achieve full privilege escalation on the system.<\/p>"},{"title":"Kernel Debugging macOS with SIP","link":"https:\/\/theevilbit.github.io\/posts\/kernel_debugging_with_sip\/","pubDate":"Tue, 12 May 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/kernel_debugging_with_sip\/","description":"
As security researchers, we often find ourselves needing to look deep into various kernels to fully understand our target and accomplish our goals. Doing so on the Windows platform is no mystery, as there have been countless well-written posts about kernel debugging setups. For macOS, however, the situation is slightly different.<\/p>\n
There are many great posts describing how to set up kernel debugging between two machines, but all of them suggest that SIP (System Integrity Protection) should be disabled for kernel debugging. This creates a problem if we want to investigate the inner workings of macOS\u2019s security mechanisms, since turning off SIP will also turn off most of the foundational security features of the operating system.<\/p>"},{"title":"Secure coding XPC Services - Part 2 - Checking CS (CodeSigning) flags of the client","link":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part2\/","pubDate":"Sun, 22 Mar 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part2\/","description":"
I’m still waiting for some bug fixes to release the previously planned posts, and in the meantime I continue to poke at other PrivilegedHelperTools. This post born because I actually failed to exploit an XPC service, and I learned something new in regards, of how to securely write such a service. One application that came to my sight is Viscosity<\/a>. This tool was already in Tyler Bohan’s list, where his team looked on exploiting such services: GitHub - blankwall\/Offensive-Con: Talk and materials for Offensive Con presentation - Privileged Helper Tools<\/a>. I still thought that I will give it a try, because many times, fixes are not properly done, and you can reexploit the bugs.<\/p>"},{"title":"TALK - Exploiting directory permissions on macOS","link":"https:\/\/theevilbit.github.io\/posts\/exploiting_directory_permissions_on_macos\/","pubDate":"Wed, 18 Mar 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/exploiting_directory_permissions_on_macos\/","description":"
This research started around summer time in 2019, when everything settled down after my talk in 2019, where I detailed how did I gained root privileges via a benign App Store application, that I developed. That exploit used a symlink to achieve this, so I though I will make a more general approach and see if this type of vulnerability exists in other places as well on macOS systems. As it turns out it does exists, and not just on macOS directly but also on other apps, it appears to be a very fruitful of issue, without too much effort I found 5 exploitable bugs on macOS, 3 in Adobe installers. In the following post I will first go over the permission model of the macOS filesystem, with focus on the POSIX part, discuss some of the non trivial cases it can produce, and also give a brief overview how it is extended. I won’t cover every single detail of the permission model, as it would be a topic in itself, but rather what I found interesting from the exploitation perspective.\nThen I will cover how to find these bugs, and finally I will go through in detail all of the bugs I found. Some of these are very interesting as we will see, as exploitation of them involves “writing” to files owned by root, while we are not root, which is not trivial, and can be very tricky.<\/p>"},{"title":"CVE-2019-20057 - Secure coding XPC services - Part 1 - Why EvenBetterAuthorization is not enough?","link":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part1\/","pubDate":"Sun, 12 Jan 2020 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/secure_coding_xpc_part1\/","description":"
This is the first part of a blog post series I plan about PrivilegedHelperTools that exists on macOS systems. I recently took a look on a couple of these tools, and found that it’s very easy to make the code insecure, as there are many small pieces to it, and if one is done wrong, the helper tool will be open to abuse by anyone having a foothold on the system. Depending on the application this might be limited to certain privileged actions (setting system configurations, mounting, etc…), and in some cases it’s more broad, and thus a full privilege escalation can be performed. Ideally only the real client application should be able to talk to the helper tool, and all other connections should be refused.<\/p>"},{"title":"GateKeeper - Bypass or not bypass?","link":"https:\/\/theevilbit.github.io\/posts\/gatekeeper_bypass_or_not_bypass\/","pubDate":"Fri, 25 Oct 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/gatekeeper_bypass_or_not_bypass\/","description":"
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
On macOS Mojave Gatekeeper only verifies executables, which are run with the open<\/code> command or the user double clicks. It won\u2019t verify files, that are executed through other means like, directly executing a binary .\/myapp<\/code> regardless of the quarantine attribute. If you can place a plist file inside LaunchAgents\/LaunchDaemons, the command inside will also be executed. Prior to Catalina there is a way to trick users to drag & drop files in the LaunchAgents folder.\nOn macOS Catalina lot has changed, the most notable one regarding gatekeeper is that it will verify files when executed via classic \u2018exec\u2019 methods.<\/p>"},{"title":"CVE-2020-14974 & CVE-2020-14975 - IOBit Unlocker 1.1.2 - Local Privilege Escalation","link":"https:\/\/theevilbit.github.io\/posts\/iobit_unlocker_lpe\/","pubDate":"Sat, 12 Oct 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/iobit_unlocker_lpe\/","description":"
IOBit\u2019s Unlocker program is advertised to solve the following issues:<\/p>\n
\n
IObit Unlocker performs well in solving \u201ccannot delete files\u201d, \u201caccess is denied\u201d, \u201cThe file is in use by another program or user\u201d, or \u201cThere has been a sharing violation\u201d problems. With IObit Unlocker, you can manage all your files the way you want.<\/p>\n<\/blockquote>\n
and even:<\/p>\n
\n
With \u201cUnlock & Delete\u201d, \u201cUnlock & Rename\u201d, \u201cUnlock & Move\u201d, and \u201cUnlock & Copy\u201d, IObit Unlocker offers easier ways to unlock and manage the files and folders to keep them safe and available.<\/p>"},{"title":"NOCVE - Few click RCE via GitHub Desktop macOS client with Gatekeeper bypass and custom URL handlers","link":"https:\/\/theevilbit.github.io\/posts\/few_click_rce_via_github_desktop_macos_client_with_gatekeeper_bypass_and_custom_url_handlers\/","pubDate":"Sat, 05 Oct 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/few_click_rce_via_github_desktop_macos_client_with_gatekeeper_bypass_and_custom_url_handlers\/","description":"
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
The GitHub Desktop app doesn\u2019t add the quarantine extended attribute to files downloaded from the web, and this along with macOS\u2019s URL handler auto-registration feature allows an attacker to execute arbitrary, even unsigned code on a macOS system. If we don\u2019t count the clicks required to open the GitHub App, and cloning an external repository, then this is a 2 click RCE.<\/p>"},{"title":"Shield - An app to protect against process injection on macOS","link":"https:\/\/theevilbit.github.io\/shield\/","pubDate":"Sun, 22 Sep 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/shield\/","description":"
\n  Shield - An app to protect against process injection on macOS\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h1>\n
In this post I would like to tell the story of the Shield.app development and also introduce its features. It’s been a ride over the past year, and I wasn’t sure always that it will happen.<\/p>\n
\n  Motivation for limiting process injections\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
In the past 2 years I started to dig into macOS security research, and along the way it became pretty clear that beyond memory corruption issues the alpha and omega of macOS exploits is to run code in the context of other applications. The reason for this lies within the security model of macOS (and in fact *OS as well). Each application has a list of entitlements that grants the application various rights. If we take only 3rd party applications it’s mostly around what it can do if it’s sandboxed (e.g.: access the network) or if not sandboxed, which privacy (TCC) protected areas can it access, like camera, microphone, messages, etc… In case of TCC, if we don’t hold these entitlements, we can’t access those resources or location even if we run as root.<\/p>"},{"title":"UninstallString - a possible LPE via Social Engineering","link":"https:\/\/theevilbit.github.io\/posts\/uninstallstring_a_possible_lpe_via_social_engineering\/","pubDate":"Fri, 09 Aug 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/uninstallstring_a_possible_lpe_via_social_engineering\/","description":"
Whenever you install an application on Windows, typically through MSI, there is a registry key created, with plenty of information for uninstallation, like the uninstaller location, install date, publisher, etc\u2026 you can find all of the options here:\nAdd uninstall information to Add\/Remove Programs - NSIS<\/a><\/p>\n
In case an application is installed for the current user and not for all user, the Installation\/Uninstallation details will go to the Computer\\HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\<\/code> registry key instead of the HKLM<\/code> hive. For example OneDrive has all the information under the following registry key: Computer\\HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OneDriveSetup.exe<\/code><\/p>"},{"title":"A simple protection against HMValidateHandle technique","link":"https:\/\/theevilbit.github.io\/posts\/a_simple_protection_against_hmvalidatehandle_technique\/","pubDate":"Wed, 31 Jul 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/a_simple_protection_against_hmvalidatehandle_technique\/","description":"
In the recent days I was reading technical analysis of win32k exploits from recent years, and it caught my eyes, that the HMValidateHandle technique is very heavily used almost everywhere. Then I had an idea how to protect against this family of exploits, which I think is very simple. This post will be about that.<\/p>\n
\n  What is HMValidateHandle?\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
HMValidateHandle is an internal, unexported function of user32.dll<\/code>. It takes a handle and a handle type as arguments, and by looking up the handle table, if the handle is matching with the type it will copy the object to user memory. If the object contains a pointer to itself, like tagWND<\/code> it can be used to leak memory addresses from the kernel. This has been a known technique for very long time, I think the first mention of this was in Tarjei Mandt\u2019s 2011 BlackHat US talk, you can find the PDF here: https:\/\/media.blackhat.com\/bh-us-11\/Mandt\/BH_US_11_Mandt_win32k_WP.pdf<\/a>\nThere are awful lot of documentation about this, and it was widely abused in many-many Windows kernel exploits, as you could reliably leak kernel object addresses, especially useful for kernel pool spraying. Thus Microsoft decided to finally close this, and so this technique doesn\u2019t work beyond Windows 10 RS4.<\/p>"},{"title":"DYLD_INSERT_LIBRARIES DYLIB injection in macOS \/ OSX","link":"https:\/\/theevilbit.github.io\/posts\/dyld_insert_libraries_dylib_injection_in_macos_osx_deep_dive\/","pubDate":"Tue, 09 Jul 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/dyld_insert_libraries_dylib_injection_in_macos_osx_deep_dive\/","description":"
After my recent blog post, my old mate @_Dark_Knight_<\/a> reached out to me and he asked me a question:<\/p>\n
\n
\u201cDo you typically callout user apps that allow dyld_insert_libraries?\u201d<\/p>\n<\/blockquote>\n
And a few similar ones, and I will be honest, I had no idea what is he talking about, if only I understood the question :D Despite the fact that my recent blog posts and talks are about macOS, I deal much more with Windows on a daily basis, probably like 95%, and macOS is still a whole new territory for me. So I decided to dig into the question and learn a bit more about this.<\/p>"},{"title":"TALK - macOS - Getting root with benign AppStore apps","link":"https:\/\/theevilbit.github.io\/posts\/getting_root_with_benign_appstore_apps\/","pubDate":"Sat, 01 Jun 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/getting_root_with_benign_appstore_apps\/","description":"
This writeup is intended to be a bit of storytelling. I would like to show how I went down the rabbit hole in a quick \u2019research\u2019 I wanted to do, and eventually found a local privilege escalation vulnerability in macOS. I also want to show, tell about all the obstacles and failures I run into, stuff that people don\u2019t talk about usually, but I feel it\u2019s part of the process all of us go through, when we try to create something.<\/p>"},{"title":"CVE-2020-14976 - GNS3 ubridge SETUID bit - arbitrary file read","link":"https:\/\/theevilbit.github.io\/posts\/gns3_ubridge_setuid_bit_arbitrary_file_read\/","pubDate":"Tue, 28 May 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/gns3_ubridge_setuid_bit_arbitrary_file_read\/","description":"
A couple of weeks ago, I had the idea of scanning my Mac for files that has the SUID bit set, I wanted to see if there is anything interesting showing up. You can do it this way:<\/p>\n
\/usr\/bin\/sudo find \/ -perm -4000 -exec \/bin\/ls -ldb {}<\/span> \\;<\/span> > suidfilelist\n<\/span><\/span><\/code><\/pre><\/div>
There was one item that caught my attention, and that was a file called ubridge<\/code> inside GNS3. I used to be a network guy, and GNS3 is a great tool to emulate real network gear, practice configuration, etc.. I highly recommend for anyone who learns networking. This was the file:<\/p>"},{"title":"CVE-2019-5514 - VMware Fusion 11 - Guest VM RCE","link":"https:\/\/theevilbit.github.io\/posts\/vmware_fusion_11_guest_vm_rce_cve-2019-5514\/","pubDate":"Sun, 31 Mar 2019 00:00:00 +0000","guid":"https:\/\/theevilbit.github.io\/posts\/vmware_fusion_11_guest_vm_rce_cve-2019-5514\/","description":"
\n  TL;DR\n  \n    <\/i>\n    Link to heading<\/span>\n  <\/a>\n<\/h2>\n
You can run an arbitrary command on a VMware Fusion guest VM through a website without any priory knowledge. Basically VMware Fusion is starting up a websocket listening only on the localhost. You can fully control all the VMs (also create\/delete snapshots, whatever you want) through this websocket interface, including launching apps. You need to have VMware Tools installed on the guest for launching apps, but honestly who doesn\u2019t have it installed. So with creating a javascript on a website, you can interact with the undocumented API, and yes it\u2019s all unauthenticated.<\/p>"}]}}