Bij Root3 richten we ons altijd op het bieden van de beste Apple-gebruikerservaring en zorgen we er tegelijkertijd voor dat gebruikers en gegevens veilig blijven. Ook dragen we bij aan de Mac Admins-gemeenschap, bijvoorbeeld met onze Support App voor macOS om IT en eindgebruikers dichter bij elkaar te brengen. De Support App is een open source-project, dus we zijn volledig transparant over hoe de tool is gebouwd en wat deze doet. Vorige maand ontvingen we een rapport van een beveiligingsonderzoeker waarin we op de hoogte werden gebracht van een probleem in de Z-shell-scripts die worden gebruikt in het post-installatiescript van de Support App installatie. In dit blog vertellen we je graag meer over wat dit betekent, hoe we dit hebben opgelost voor onze producten/diensten en onze aanbevelingen voor collega-ontwikkelaars en Mac-beheerders.

Sinds we de Support App hebben geüpdatet naar versie 2.5.2 en het beveiligingsrapport op GitHub hebben gepubliceerd, werd het snel opgepikt in de gemeenschap en heeft dit veel mensen aan het denken gezet waar ze dit ‘probleem’ moesten plaatsen. Moeten ontwikkelaars en Mac-beheerders hier iets aan doen? Of moet Apple hier een patch voor uitbrengen?

Tijdens onze ontwikkelingscycli gaan we uit van de principes ‘secure by design’ en ‘privacy by design’, maar uiteraard kunnen er altijd kwetsbaarheden in een softwareproduct zitten waar we nog niets van weten. Het bestaat in elk afzonderlijk softwareproduct en we moeten accepteren dat dit soms kan gebeuren. Toen we het rapport voor het eerst lazen, dachten we niet dat dit zou leiden tot de aandacht die we kregen nadat we de update hadden gepubliceerd.

Het probleem

Dus wat is het probleem? Een korte samenvatting van de kwetsbaarheid zoals aan ons gerapporteerd door Carlos Polop, een Spaanse senior beveiligingsonderzoeker:

“It’s possible to abuse a vulnerability inside the postinstall installer script to make the installer execute arbitrary code as root. The cause of the vulnerability is the fact that the shebang #!/bin/zsh is being used. When the installer is executed it asks for the users password to be executed as root. However, it’ll still be using the $HOME of the user and therefore loading the file $HOME/.zshenv when the postinstall script is executed. An attacker could add malicious code to $HOME/.zshenv and it will be executed when the app is installed.”

Allereerst: waarom zouden we Z-shell gebruiken in ons post-installatiescript, of Z-shell in het algemeen gebruiken? Nou, vooral omdat dit de standaard login-shell op macOS is sinds macOS Catalina in 2019 werd uitgebracht en bash verving. Z-shell biedt ook extra functies die we soms in onze scripts gebruiken, zoals de functie is-at-least als een heel eenvoudig voorbeeld om macOS-versies te vergelijken en er voorwaarden omheen te creëren. Bash is nog steeds aanwezig in macOS en we hadden Bash ook als post-install-script kunnen gebruiken. Maar jaren geleden, na deze verandering, hebben we besloten om standaard Z-shell-scripts te gebruiken en de functies ervan te benutten wanneer dat nodig is. Apple heeft zelfs een artikel over de wijziging en hoe je de compatibiliteit van scripts kunt verifiëren: https://support.apple.com/en-us/102360

Natuurlijk wilden we de Proof of Concept verifiëren voordat we er iets aan deden, maar al snel kwamen we erachter dat dit gemakkelijk reproduceerbaar was. We realiseerden ons ook dat dit niet specifiek met onze Support-app te maken heeft. Maar omdat het installatiepakket een Z-shell postinstall-script gebruikt, was onze app kwetsbaar voor dit probleem. Dit betekent ook dat ieder ander installatiepakket dat een Z-shell-script gebruikt, kwetsbaar is. Vervolgens wisselden we wat informatie uit met Carlos en toen we hem vertelden dat dit een algemeen probleem is voor alle installatiepakketten met Z-shellscripts, bevestigde hij dat. We waren nieuwsgierig en controleerden enkele andere open source-projecten om te zien of deze misschien ook getroffen waren, wat het geval was. Blijkbaar had Carlos al contact opgenomen met een aantal andere projecteigenaren en hen gevraagd een oplossing te implementeren om middels praktijkvoorbeelden Apple ervan te overtuigen deze logica in de macOS package installer te verbeteren.

Omdat het probleem werd gemeld met behulp van de GitHub-functie om een beveiligingsprobleem privé te melden, konden we hiervoor een CVE-nummer aanvragen en GitHub heeft ons deze toegekend. Omdat de oplossing hiervoor (hier komen we later op terug) relatief eenvoudig is en Carlos ons vroeg om het beveiligingsadvies te publiceren, hebben we dit geïmplementeerd en versie 2.5.2 uitgebracht samen met de vermelding van de oplossing van CVE-2024-27301.

Blijkbaar was Root3 de eerste die een openbare oplossing uitbracht en het probleem vermeldde, wat leidde tot enkele meningen in de gemeenschap om hier openlijk over te praten. We denken dat een belangrijke vraag is: wie moet dit oplossen of is dit gewoon ‘by design’ binnen Z-shell (zelfs niet door Appl) en moeten we collega-ontwikkelaars en Mac-beheerders hiervan bewust maken en best practices verbeteren?

De gevolgen

Ook al klinkt escalatie van privileges naar root eng, de algemene mening is dat als een aanvaller hier misbruik van kan maken, er al een vorm van aanwezigheid op het apparaat is en dat de aanvaller moet wachten tot er een gebeurtenis plaatsvindt en met beheerdersrechten wordt uitgevoerd. Maar naast installatiepakketten hebben we ook ontdekt dat het uitvoeren van Z-shell-scripts met MDM-oplossingen ook beïnvloed wordt, maar alleen in bepaalde scenario’s. Een heel eenvoudig voorbeeld stelde ons in staat een ‘slechte’ gebruiker te zijn met standaardrechten en code in het .zshenv-bestand te plaatsen om het gebruikersaccount naar een beheerder te verheffen door simpelweg een op Z-shell gebaseerd hulpprogramma uit de Jamf Pro Self Service-applicatie uit te voeren zonder dat daarvoor een administratieve toestemming nodig was. Daarom denken wij dat dit vraagstuk vooral ‘interessanter’ is voor slimme eindgebruikers met standaardrechten om IT te omzeilen en allerlei lokale administratieve taken uit te voeren. In onze tests konden we dit niet reproduceren met een policy in Jamf Pro dat bij het inchecken werd geactiveerd, dus het lijkt erop dat er altijd een door de gebruiker geïnitieerde actie moet zijn, wat overeenkomt met de Z shell theorie. Maar nogmaals, sommige MDM scenario’s lijken te kunnen worden misbruikt en de gebruiker heeft alleen een item nodig met een Z-shell-script erachter. Op dit moment hebben we nog niet alle MDM-oplossingen getest, maar mogelijk zien we daar vergelijkbare resultaten.

Hoe op te lossen?

De eenvoudigste oplossing die we hebben gevonden, is feitelijk het veranderen van de shebang in het Z-shell-script van:

#!/bin/zsh

Naar:

#!/bin/zsh --no-rcs

Dit zorgt ervoor dat het script wordt verteld dat er geen gebruikersconfiguratie en code uit het .zshenv-bestand in de thuismap van de gebruiker moeten worden geladen. Om volledig te voorkomen dat het probleem zich voordoet, moeten alle Z-shell-scripts en -pakketten die worden uitgevoerd de shebang uiteraard wijzigen naar de bijgewerkte versie of naar Bash- of Bourne-shell.

Een technisch gedetailleerder en uitstekend artikel werd vorige week ook gepubliceerd op Scripting OS X: https://scriptingosx.com/2024/03/zsh-scripts-and-root-escalations/

Hoe gaat Root3 hiermee om?

Zonder met de vinger te wijzen waar en hoe andere partijen een permanente oplossing zouden moeten brengen, denken we dat het goed is dat zoveel ontwikkelaars en Mac-beheerders zich hiervan bewust zijn en de eerder genoemde oplossing implementeren. En als we Z-shell-scripts blijven gebruiken, zouden we de bijgewerkte shebang overnemen als de nieuwe best practice in de branche.

Dat is precies wat we hebben gedaan en we hebben al onze scripts bijgewerkt die voor onze klanten worden gebruikt in MDM-oplossingen en -applicaties om ervoor te zorgen dat onze oplossingen het probleem niet veroorzaken. Ook onze geautomatiseerde patch oplossing voor applicaties, App Catalog, heeft een update gekregen naar versie 1.3.1 waarin deze oplossing is geïmplementeerd.

Wilt je meer weten of de mogelijke impact voor jouw organisatie bespreken, neem dan contact met ons op via [email protected] of +31 85 400 30 30.