{"id":26003,"date":"2020-08-27T16:14:01","date_gmt":"2020-08-27T14:14:01","guid":{"rendered":"https:\/\/www.kaspersky.nl\/blog\/?p=26003"},"modified":"2020-10-19T16:20:34","modified_gmt":"2020-10-19T14:20:34","slug":"black-hat-macos-macros-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.nl\/blog\/black-hat-macos-macros-attack\/26003\/","title":{"rendered":"Hoe schadelijke macrovirussen ongemerkt op macOS kunnen worden gelanceerd"},"content":{"rendered":"

Veel macOS-gebruikers zijn er nog altijd van overtuigd dat hun apparaten geen bescherming nodig hebben. Sterker nog: systeembeheerders bij bedrijven waar werknemers op Apple-hardware werken hebben vaak van dezelfde mening.<\/p>\n

Tijdens de Black Hat USA 2020<\/a>-conferentie trachtte onderzoeker Patrick Wardle het publiek ervan te overtuigen dat dit toch echt een misvatting is door zijn analyse van malware voor macOS en door een exploit chain<\/em> te bouwen om de controle over een Apple-computer over te nemen.<\/p>\n

Microsoft, macrovirussen en Macs<\/h2>\n

Een van de meest voorkomende manieren om computers die op macOS draaien aan te vallen is via documenten met macrovirussen, oftewel via Microsoft Office-applicaties. Inderdaad: ondanks het feit dat Apple zijn eigen productiviteits-apps heeft, geven toch veel gebruikers de voorkeur aan Microsoft Office. Voor sommigen is dat uit gewoonte; voor anderen vanwege de compatibiliteit met de documenten die hun collega\u2019s aanmaken.<\/p>\n

Iedereen kent natuurlijk al lang de potenti\u00eble dreiging die documenten met macrovirussen kunnen vormen. Daarom hebben zowel Microsoft en Apple mechanismes om de gebruikers hiertegen te beschermen.<\/p>\n

Microsoft waarschuwt gebruikers als ze een document openen dat een macro bevat. Als de gebruiker toch besluit het bestand met macrovirus te openen, dan wordt de code uitgevoerd in een sandbox, die volgens Microsoft-ontwikkelaars voorkomt dat de code toegang heeft tot de bestanden van de gebruikers of anderszins schade aan het systeem kan aanrichten.<\/p>\n

Apple heeft verschillende nieuwe veiligheidsfuncties ge\u00efntroduceerd in de nieuwste versie van hun besturingssysteem, macOS Catalina. Deze omvatten in het bijzonder de bestandsquarantaine en \u201cnotarisatie\u201d, wat een technologie is die het opstarten van uitvoerbare bestanden van externe bronnen voorkomt.<\/p>\n

Deze technologie\u00ebn zouden samen genoeg moeten zijn om aanvallen door middel van macrovirussen te voorkomen. In theorie lijkt alles veilig te zijn.<\/p>\n\n

Een exploit chain<\/em> haalt het macrovirus uit de sandbox<\/h2>\n

In de praktijk zijn er tal van beveiligingsmechanismes op een nogal problematische wijze ge\u00efmplementeerd. Daarom kunnen onderzoekers (of aanvallers) mogelijk methodes vinden om ze te omzeilen. Wardle illustreerde zijn presentatie met een reeks exploits.<\/p>\n

1. Het omzeilen van het mechanisme dat macrovirussen uitschakelt<\/h3>\n

Neem bijvoorbeeld het systeem dat gebruikers waarschuwt als er een macrovirus in een document wordt gedetecteerd. In de meeste gevallen werkt dit zoals de ontwikkelaars het hadden bedoeld. Maar het is tegelijkertijd mogelijk om een document aan te maken waarin de macro automatisch opstart zonder enige gebruikersmelding, zelfs als macro\u2019s in de instellingen zijn uitgeschakeld.<\/p>\n

Dit kan worden gedaan met gebruik van het bestandsformaat Sylk<\/a> (SLK). Dit formaat, dat gebruikmaakt van de XLM-macrotaal, werd in de jaren 1980 ontwikkeld en in 1986 voor het laatst ge\u00fcpdatet. Maar sommige Microsoft-applicaties (zoals bijvoorbeeld Excel) ondersteunen Sylk nog altijd vanwege achterwaartse compatibiliteit. Deze kwetsbaarheid is niet nieuw en werd in 2019 al in detail beschreven<\/a>.<\/p>\n

2. Uit de sandbox ontsnappen<\/h3>\n

Zoals we nu hebben kunnen zien, kan een aanvaller op onzichtbare wijze een macro runnen. Maar de code wordt nog altijd uitgevoerd binnen de ge\u00efsoleerde sandbox van MS Office. Hoe kan een hacker de computer dan toch aanvallen? Het blijkt dat het helemaal niet zo lastig is om op een Mac aan Microsofts sandbox te ontsnappen.<\/p>\n

Het klopt dat u geen bestanden kunt wijzigen die al op uw computer staan opgeslagen van binnen de sandbox. Maar u kunt ze w\u00e9l <em>cre\u00ebren<\/em><\/em>. Deze exploit is al eerder gebruikt om aan de sandbox te ontsnappen, en Microsoft bracht destijds een update uit om iets aan deze kwetsbaarheid te doen. Het probleem werd echter nooit \u00e9cht opgelost, zoals een gedetailleerder onderzoek van de patch heeft aangetoond: de oplossing deed alleen iets tegen de symptomen en blokkeerde het aanmaken van bestanden binnen plekken die door sommige ontwikkelaars als onveilig werden beschouwd, zoals in de map LaunchAgents, wat de opslaglocatie is voor scripts die automatisch worden opgestart na het opnieuw opstarten van de computer.<\/p>\n

Maar wie besloot dat Microsoft rekening had gehouden met elke \u201cgevaarlijke locatie\u201d bij het cre\u00ebren van de patch? Het bleek dat een script dat in Python werd geschreven en vanuit een Office-document werd opgestart (en dus in een sandbox), kon worden gebruikt om een object met de naam \u201cLogin Item\u201d te cre\u00ebren. Een object met die naam start automatisch op als de gebruiker op het systeem inlogt. Het systeem start het object op, dus het wordt uitgevoerd buiten<\/em>\u00a0de Office-sandbox en omzeilt zo dus de beveiligingsmaatregelen van Microsoft.<\/p>\n

3. Het omzeilen van de beveiligingsmechanismes van Apple<\/h3>\n

Dus nu weten we hoe we stiekem een macro kunnen runnen en een Login Item-object kunnen aanmaken. Maar de beveiligingsmechanismes in macOS voorkomen nog altijd dat de backdoor, die onbetrouwbaar is omdat hij is gecre\u00eberd door een verdacht proces binnen de sandbox, opgestart kan worden. Toch?<\/p>\n

Aan de ene kant, ja: de beveiligingsmechanismes van Apple blokkeren inderdaad het uitvoeren van code die op zo\u2019n manier verkregen is. Aan de andere kant is hier iets aan te doen: als u een ZIP-archief als een Login Item naar binnen glipt, dan zal dit bestand bij de volgende login automatisch worden uitgepakt door het systeem.<\/p>\n

Vervolgens hoeft de aanvaller alleen nog maar de juiste locatie te kiezen om het bestand uit te pakken. Het archief kan bijvoorbeeld in dezelfde map worden geplaatst als de gebruikersbibliotheken, \u00e9\u00e9n stap boven de map waar objecten van het Launch Agent-type opgeslagen zouden moeten zijn (de objecten die Microsoft terecht als gevaarlijk beschouwt). Het archief kan zelf weer een map bevatten met de naam LaunchAgents die het LaunchAgent-script bevat.<\/p>\n

Eenmaal uitgepakt, wordt het script in de LaunchAgents-map geplaatst om bij het opnieuw opstarten van het systeem uitgevoerd te worden. Doordat het door een vertrouwd programma is gecre\u00eberd (de Archiver) en geen quarantaine-attributen heeft, kan het worden gebruikt om iets gevaarlijks op te starten. Beveiligingsmechanismes zullen niet voorkomen dat dit bestand wordt opgestart.<\/p>\n

Hierdoor kan een aanvaller een mechanisme lanceren via de Bash-command shell <\/em>om op afstand toegang te verkrijgen (en hierdoor zogenaamde reverse shell<\/em> te verkrijgen). Dit Bash-proces kan worden gebruikt om bestanden te downloaden, die ook niet over het quarantaine-attribuut beschikken, waardoor de aanvaller dus daadwerkelijk schadelijke code kan downloaden en deze zonder enige beperkingen kan uitvoeren.<\/p>\n

Samengevat:<\/p>\n