macOS Big Sur | 9 grote verrassingen voor beveiliging van enterprises

Wat later in juni dan gebruikelijk ging Apple’s WorldWide Developer Conference (WWDC) 2020 deze week van start onder – en dat zal geen verbazing wekken – meer dan ongebruikelijke omstandigheden. Op het moment dat de coronapandemie ook midden in het jaar nog steeds alom aanwezig was, ging dit belangrijke Apple-evenement volledig virtueel, waardoor we allemaal vooraan zaten bij al het nieuws, alle aankondigingen en aanstaande ontwikkelingen op de verschillende Apple-platforms. Daarvan is de bètarelease van de volgende versie van macOS van groot belang voor bedrijven en beveiligingsteams. In deze blog vatten we de belangrijkste veranderingen samen die tot nu toe zijn aangekondigd en van invloed zijn op de beveiliging van macOS. Laten we eens gaan kijken.

1. Gaat uw hardware macOS 11.0 Big Sur ondersteunen?

U kunt uiteraard alleen profiteren van de wijzigingen aan macOS Big Sur als u de daarvoor geschikte Apple-hardware heeft. Er zijn zeven ondersteunde productlijnen voor macOS Big Sur, waarvan de vroegste ondersteunde modellen teruggaan tot 2013:

Wat betekent dat voor bedrijven?

Uw ouder wordende Mac-hardware merkt waarschijnlijk al de hitte van het resource-intensieve Mojave en Catalina. De enige vraag die er echt toe doet, is hoeveel u van uw macOS-hardware nu wilt bijwerken voordat de ARM-chip eind 2020 en in de loop van 2021 beschikbaar komt.

2. Big Sur-versienummer: is het nu macOS 10.16 of 11.0?

De eerste release van macOS Big Sur bèta bracht flink wat schokken teweeg, die geen van allen expliciet werden vermeld in de keynote van Apple op maandag. De eerste daarvan, opgemerkt door enkele oplettende gebruikers, was dat macOS 10.15 niet wordt opgevolgd door macOS 10.16! In plaats daarvan heeft Apple eindelijk het doodvonnis geveld over het al 20 jaar bestaande Mac OS X, en deze keer niet alleen qua naam, maar ook wat het versienummer betreft: Big Sur wordt het eerste macOS 11.0!

Wat betekent dat voor bedrijven?

Zo’n kleine verandering, maar wel met de nodige gevolgen voor heel wat bedrijven, zoals Apple zelf al ondervindt. Zoveel workflows zijn afhankelijk van scripts die controleren op versienummers in de 10.x-reeks, dat veel ervan onmiddellijk onderbroken worden.

if [[ ${osvers_major} -ne 10 ]]; then

Zelfs Apple’s eigen controle van software-updates telt waarschijnlijk in de 10.x-reeks, en de eerste bètaversie werd geleverd als 10.16 (en mogelijk de rest ook; er blijkt namelijk heel wat interne documentatie te bestaan die verwijst naar “10.16”).

3. Kernelextensies voorlopig nog in de ijskast

Nog zo’n grote verrassing was dat het door velen verwachte afscheid van kernelextensies (kexts) niet is doorgegaan.Ook al heeft Apple zeker de nodige hindernissen ingebouwd waardoor zowel ontwikkelaars als gebruikers daar zo snel mogelijk vanaf wilden om in plaats daarvan gebruik te maken van systeemextensies en DriverKit.

Niettemin blijven kexts een bestaande mogelijkheid voor organisaties die te maken hebben met cruciale afhankelijkheden. Bovendien is er een nieuwe tool, kmutil, om kexts en “kext-verzamelingen” te laden, te verwijderen en te diagnosticeren in Big Sur.

Wat betekent dat voor bedrijven?

Organisaties kunnen naar macOS Big Sur upgraden zonder bang te hoeven zijn dat functionaliteit verloren gaat van software die afhankelijk is van kernelextensies. Wel moet worden opgemerkt dat kextutil en kextload nu vervangen zijn door kmutil en dat er wijzigingen en beperkingen zijn in de werking ervan (zie de instructiepagina voor details).

Apple heeft duidelijk gemaakt dat ontwikkelaars nog steeds het beste afscheid kunnen nemen van kexts en geeft daarover het volgende advies:

“IT-beheerders die werken met apparaatstuurprogramma’s, oplossingen voor cloudopslag, networking en beveiligingsapps die kernelextensies nodig hebben, worden aangemoedigd over te stappen op nieuwere versies – zelfs als dat betekent dat er naar andere leveranciers moet worden gezocht – die gebaseerd zijn op Systeemextensies.”

SentinelOne-klanten kunnen er zeker van zijn dat onze aanstaande macOS 4.4 Agent geen gebruikmaakt van kexts en compatibel is met zowel macOS 10.15 Catalina als macOS Big Sur.

4. Compatibiliteit met Rosetta 2, Apple silicon en universele binaire indelingen

Uiteraard was een van de grote veranderingen die aan het eind van de keynote ter sprake kwam, de verandering die al overal in de media verwacht werd: de overstap van Apple naar een op ARM gebaseerde chipset voor macOS, die tijdens WWDC 2020 werd aangeduid als “Apple silicon”. Hoewel er momenteel geen ARM-hardware verkrijgbaar is, komt er een Developer Transition Kit beschikbaar. Apple heeft gemeld dat naar verwachting eind 2020 ARM Macs geleverd gaan worden.

Om die overgang te vergemakkelijken, heeft Apple een oude vriend tot leven gewekt die degenen die zich nog de overstap van de PowerPC naar Intel herinneren, bekend zal voorkomen: Rosetta. Omgedoopt tot Rosetta 2 kan deze op software gebaseerde technologie bepaalde klassen software die is gecompileerd op de Intel-architectuur laten draaien op ARM-apparaten.

Rosetta 2 kent echter wel enkele maren. In de eerste plaats is het onvermijdelijk dat de vertaling tijd in beslag neemt en geen enkele slimme optimalisatiemethode kan iets veranderen aan het feit dat sommige applicaties die van Rosetta 2 afhankelijk zijn, trager zullen starten of draaien dan het geval is op de Intel-architectuur waarvoor ze zijn gecompileerd. Om dit probleem te vermijden, komt Apple ook met een nieuwe multi-architectuur, in een universele binaire indeling (ook wel “Fat” genoemd). Daarmee kunnen ontwikkelaars ervoor zorgen dat bestaande macOS-apps gewoon op Apple silicon kunnen worden uitgevoerd. Met Xcode 12 of later kunnen ontwikkelaars een “fat” binaire structuur bouwen met architecturen voor beide computers: er is geen ARM Mac nodig om deze universele binaire indelingen te compileren.

Het tweede probleem met Rosetta 2 is dat niet alle software die op Intel-architectuur gecompileerd is, kan worden vertaald in iets dat ook op Apple silicon draait. Met name virtualisatie-software en kernelextensies van Windows worden niet ondersteund. Degenen die hopen dat Rosetta 2 een vrijgeleide betekent voor hun kernelextensies, moeten daar nog maar eens over nadenken. Het blijft onduidelijk wat de toekomst zal zijn voor virtuele Windows-machines op macOS, hoewel er met VMware tenminste nog een beetje de hoop kan worden gekoesterd dat niet alles verloren is.

Wat betekent dat voor bedrijven?

De alom verwachte overgang naar ARM, waarvan Apple denkt dat die over 2 jaar gestalte krijgt, heeft geen onmiddellijke gevolgen voor bedrijven. Maar op de middellange termijn zullen IT-teams moeten bepalen welke apps native kunnen worden uitgevoerd met een universele binaire indeling, welke ervan werken na vertaling naar Rosetta 2 en welke gewoonweg niet compatibel zijn.

Zoals eerder vermeld in deze post, is de belangrijkste beslissing voor organisaties wellicht de keuze wanneer hardware moet worden geüpgraded en of het in het belang van het bedrijf is om met de aanschaf van nieuwe apparatuur te wachten totdat ARM Macs beschikbaar zijn.

5. Blijf weg! Een cryptografisch ondertekend systeemvolume

Los van de grote veranderingen die we al hebben besproken, zijn er ook enkele veranderingen die minder aandacht hebben getrokken. Een van die veranderingen is dat macOS 11 cryptografische ondertekening voor het systeemvolume gebruikt. In Catalina voerde Apple al een wijziging in de architectuur door met het in tweeën opsplitsen van het rootvolume: een alleen-lezen systeemvolume en een datavolume voor al het andere.

Het systeemvolume krijgt nu extra beveiliging doordat het cryptografisch wordt gevalideerd om offline aanvallen en kwaadwillige manipulatie te voorkomen.

Wat betekent dat voor bedrijven?

Omdat het alweer een hele tijd geleden is, namelijk sinds de introductie van System Integrity Protection in macOS El Capitan 10.11, dat Apple het onmogelijk heeft gemaakt om te rommelen met het systeem, zou die extra beveiliging van het systeemvolume niet al te problematisch moeten zijn voor IT- en beveiligingsteams.

Dat heeft echter wel enkele gevolgen. Een daarvan is dat FileVault het systeemvolume bij inactiviteit in macOS 11 niet meer hoeft te versleutelen. Het datavolume blijft gewoon met FileVault-versleuteling beveiligd als het systeem is ingeschakeld.

En in de tweede plaats lukt het niet meer om een “live” versie van het OS (dat wil zeggen een schrijfbaar bestandssysteem) op te starten door Bescherming van systeemintegriteit uit te schakelen. Het is nog wel mogelijk om de beveiligingen uit te schakelen en wijzigingen aan te brengen zolang het systeem niet is opgestart, maar “live” wijzigingen kunnen in macOS 11 niet meer worden uitgevoerd.

6. De ins en outs van netwerken

Er zijn een paar kleinere veranderingen in het gebruik van het netwerk en internet die van invloed kunnen zijn op uw beveiliging of workflows. We zullen die hier in het kort bespreken.

De eerste, openbaar gemeld door macrumors, is dat de oude vertrouwde Network Utility-app “verouderd” is. Maar voor zover we kunnen zien is het zo dat de app nu in het geheel niet meer werkt.

De Network Utility bevat heel wat handige tools, zoals Netstat, Ping, Traceroute en Port Scanning.

Apple heeft daar een handige Privacy Tracker en blocker voor Safari aan toegevoegd, waarmee gebruikers kunnen zien welke trackingcookies een site gebruikt en door Safari zijn geblokkeerd. De knop van de Privacy-werkbalk, die hier openbaar werd gemeld, biedt meer informatie via een pop-up die een aantal extra pop-outs bevat.

Gezien het omvangrijke en schadelijke gebruik van extensies in alle populaire browsers, zullen beveiligingsteams zeker geïnteresseerd zijn in de nieuwe Web Extensions-functie van macOS Big Sur. Hiermee kunnen bestaande Chrome- en Firefox-extensies eenvoudig worden geconverteerd voor gebruik met Safari 14 in combinatie met de xcrun-tool. Apple hoopt iets te kunnen doen aan de daarmee samenhangende beveiligingskwesties door erop te blijven hameren dat browserextensies via de eigen App Store moeten worden gedistribueerd. Er zijn ook nieuwe opties voor de gebruiker om extensies in de browser te beheren.

Er is bovendien gemeld dat voor Safari 14 HTTP/3 standaard is ingeschakeld. Volgens de release notes van Apple schakelt Big Sur experimentele ondersteuning voor HTTP/3 in Safari in via experimentele functies in het Developer-menu. De functie kan voor het hele systeem worden ingeschakeld met de volgende Terminal-opdracht:

defaults write -g CFNetworkHTTP3Override -int 3

En nu we het toch over de opdrachtregel hebben, er is nog een netwerkwijziging in macOS 11 die te maken heeft met de networksetup-tool, /usr/sbin/networksetup. Met ingang van Big Sur kunnen standaardgebruikers geen netwerkinstellingen meer wijzigen met deze tool. Standaardgebruikers kunnen wel Wifi aan- en uitzetten en de netwerkinstellingen bekijken, maar voor het aanbrengen van wijzigingen zijn de gebruikersnaam en het wachtwoord van een beheerder vereist.

Wat betekent dat voor bedrijven?

Al deze wijzigingen moeten helpen de netwerkbeveiliging te verbeteren. De wijziging van de networksetup-opdrachtregel sluit aan bij de toestemmingen waarover standaardgebruikers beschikken in de Systeemvoorkeuren en het is mooi om te zien dat Apple steeds consistenter wordt met zijn tools.

We verwachten ook niet veel meer aanvalsmogelijkheden vanwege een toename van browserextensies zolang de App Store van Apple die blijft controleren en op tijd effectief verwijdert wanneer ze schadelijk of oneigenlijk gedrag blijken te vertonen. De bewijslast ligt uiteraard bij Apple, en beveiligingsteams van bedrijven zouden het blokkeren van de installatie van browserextensies via MDM of soortgelijke configuratietools zeker de moeite van het overwegen waard kunnen vinden gezien de geschiedenis van schadelijke extensies en de hoeveelheid gevoelige en privégegevens die via browserapplicaties worden verzonden. De nieuwe tool voor privacymeldingen is dan ook een welkome toevoeging aan Safari 14 in Big Sur.

Nog een laatste woord over netwerken. Het verwijderen van de Network Utility-app zou voor IT-teams niet zo’n probleem moeten zijn. Waarschijnlijk gebruikt u al de opdrachtregelequivalenten van de tools waarvoor de app een GUI-wrapper bood, en daarom denken we dat de app niet door al te veel gebruikers gemist zal worden.

7. Certificaatvertrouwen: alleen de root is niet genoeg

In macOS Catalina en eerdere versies kan de opdrachtregeltool voor beveiliging worden gebruikt om Certificate Trust-instellingen te wijzigen als de feitelijke gebruiker wordt uitgevoerd als root via de add-trusted-cert-vlag, zoals te zien is op de instructiepagina van de tool bij installatie op Catalina:

Het volstaat in macOS Big Sur niet meer om alleen maar UID 0 te gebruiken om die wijziging door te voeren: er is een bevestiging nodig in de vorm van een beheerderswachtwoord.

Gelukkig kan in beheerde bedrijfsomgevingen die wijziging zonder enige bevestiging worden doorgevoerd als de certificaat-payload samen met het hoofdcertificaat wordt geïmplementeerd met behulp van een configuratieprofiel.

Wat betekent dat voor bedrijven?

Deze welkome versterking voor de instellingen voor certificaatvertrouwen kan gevolgen hebben voor uw workflow als u de opdrachtregeltool voor beveiliging gebruikt om vertrouwensinstellingen of een gemachtigd proces dat de SecTrustSettingsSetTrustSettings-functie aanroept, te wijzigen.

8. Configuratieprofielen krijgen een voorkeursbehandeling

Configuratieprofielen, die worden beheerd via de opdrachtregeltool voor profielen of het deelvenster Profielen van Systeemvoorkeuren, hebben al enige tijd last van macOS-malware. Tot de grootste boosdoeners behoren adware-infecties die de homepage en zoekinstellingen van browsers willen manipuleren, maar er zijn er ook die schadelijke DNS-instellingen configureren. Profielen zijn een geliefd doelwit voor adware geworden nadat Apple stappen ondernam om Safari-browservoorkeuren in eerdere OS-releases te vergrendelen.

In macOS Big Sur heeft Apple dit misbruik van profielen erkend en heeft nu de lat hoger gelegd om ze te kunnen installeren. Tenzij het apparaat deel uitmaakt van een MDM-programma, moet de gebruiker, om een profiel te kunnen installeren, de profielinstallatie in de Systeemvoorkeuren handmatig voltooien, waar bovendien in een venster het feitelijke gedrag van het profiel wordt beschreven.

Het is wel wat vreemd dat er voor deze actie een tijdslimiet van 8 minuten geldt: als de gebruiker de installatie niet binnen die tijd voltooit, wordt het profiel door macOS Big Sur uit de Systeemvoorkeuren verwijderd.

Wat betekent dat voor bedrijven?

Uw bedrijf gebruikt waarschijnlijk alleen profielen via een MDM-oplossing, zodat deze wijziging geen gevolgen voor u heeft. Als u om wat voor reden dan ook de profielen via handmatige scripting installeert, zult u uw medewerkers moeten leren hoe ze de stappen moeten uitvoeren (in minder dan 8 minuten!).

Hoewel er ongetwijfeld kwaadwillig gebruik van profielen zal blijven plaatsvinden door adware en andere macOS-malware, betekent deze wijziging een welkome aanpak van de ergste overtreders.

eBook: macOS Threat Hunting & Incident Response
Deze handleiding voorziet u van de nodige kennis om de macOS-machines van uw organisatie te beschermen.

9. Verrassend genoeg geen verrassingen in app-beveiliging

Hoewel WWDC 2020 nog lang niet voorbij is, hebben we nog geen enkele aankondiging of aanwijzing gezien dat Apple zijn aanpak voor app-beveiliging in macOS 11 gaat veranderen. Met al die onderliggende veranderingen rondom beveiliging hoopten teams voor bedrijfsbeveiliging wellicht op enkele belangrijke ontwikkelingen, maar dat staat nog maar te bezien.

Het lijkt erop dat Apple in macOS 11 blijft vertrouwen op het model dat zich langzaam maar zeker ontwikkeld heeft in de jaren van macOS 10.x, maar dat wel wat achterblijft bij de rest van de sector wat betreft het vertrouwen op statische handtekeningen voor blokkering en detectie. Het model voor app-beveiliging blijft er ongeveer zo uitzien:

  • Beveiligen: code signing, Notarization en controle van het systeembeleid via Gatekeeper
  • Detecteren: malware blokkeren via statische Yara-regels in XProtect
  • Verwijderen: verwijdering van bekende malware via statische detectiehandtekeningen in MRT.app

Wat betekent dat voor bedrijven?

Het is bewonderenswaardig hoeveel aandacht Apple besteedt aan beveiliging – en sommige veranderingen in Big Sur zijn meer dan welkom – maar toch lijkt het bedrijf in sommige opzichten niet helemaal bij de tijd te zijn. Zelfs Windows beschikt nu over een rudimentaire gedragsdetectie, en het vertrouwen van Apple op het driemanschap Gatekeeper, XProtect en MRT.app begint er gedateerd uit te zien.

Gatekeeper en Notarization zijn verzwakt door eenvoudige trucs met social engineering die aanvallers begonnen te gebruiken vanaf 10.14 en de aanvallen zijn sindsdien alleen maar effectiever geworden. De statische YARA-regels van XProtect zijn berekend op malware die al bekend is bij Apple, wat wil zeggen dat een gebruiker of organisatie eerst geïnfecteerd moet worden voordat Apple de handtekeningen kan updaten. Daar komt bij dat MRT.app alleen wordt uitgevoerd wanneer het wordt bijgewerkt, de gebruiker inlogt of de Mac opnieuw opstart, wat betekent dat de tool machteloos is gedurende de meeste tijd dat de Mac daadwerkelijk in gebruik is.

Bovendien hebben beveiligingsteams geen enkel beeld van wat deze tools aan het doen zijn of wat ze hebben gedaan. Zelfs met deze laatste introductie van een macOS, met zijn nieuwe naam, nieuwe versienummer en vele nieuwe functies, blijft het nog altijd net zo noodzakelijk om uw Macs te beveiligen met een platform voor gedragsgerichte beveiliging dat bekende en onbekende schadelijke activiteiten kan detecteren, daar melding van kan maken en er bescherming tegen kan bieden.

Conclusie

Van wat we tot nu toe hebben gezien, bevalt macOS 11 ons wel en we zijn blij met de wijzigingen die er gemeld zijn. Met de meeste daarvan kan eenbeveiligingsteam de beveiliging van macOS-computers verbeteren met slechts een paar wijzigingen voor de meeste workflows.