Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 65 reacties
Submitter: tie-rip

Er zitten enkele lekken in OS X, waardoor aanvallers kwaadaardige code kunnen uitvoeren in legitieme applicaties als Xcode, iCloud, iMovie, Microsoft Office en Dropbox. De ontdekker adviseert gebruikers om voorlopig geen programma's buiten de Mac App Store om te installeren.

Er zitten twee lekken in de manier waarop de programma's onder OS X omgaan met het zoeken van de externe library's, blijkt uit de omschrijving van de lekken op Virus Bulletin en een presentatie op beveiligingsconferentie CanSecWest 2015. Sommige programma's blijven zoeken naar dergelijke library's, ook als het programma het niet op de juiste plek vindt. Daardoor is het mogelijk voor een aanvaller om zo'n library, dylib, op die plek te zetten.

De tweede manier loopt via OS X Helper, waar programma's kunnen vragen waar de juiste dylib-bestanden staan. Door die voor de gek te houden, wijst die naar kwaadaardige library's, die de programma's vervolgens vertrouwen en gebruiken. Gatekeeper kan niets doen tegen deze aanvallen, omdat de kwaadaardige code pas in applicaties wordt geladen na installatie. Nadat de kwaadaardige bestanden zijn geladen, kan een aanvaller commando's uitvoeren op de computer.

Naast eigen programma's van Apple als Xcode, iMovie en iCloud Photos kunnen ook programma's van derden worden getroffen als de installers van Spotify en VLC.

De ontdekker van de lekken, Patrick Wardle van beveiligingsbedrijf Synack, heeft een tool online gezet om kwetsbare Mac-apps op de eigen desktop of laptop op te sporen. Omdat het gaat om een functie van het besturingssysteem, is het lastig om de lekken helemaal te fixen, maar in elk geval zou Apple Gatekeeper kunnen updaten. Wanneer Apple de dylib-lekken gaat dichten en dit soort aanvallen onmogelijk maakt, is onbekend. Apple is twee keer op de hoogte gesteld van de lekken. Wardle raadt gebruikers van OS X aan om applicaties alleen via beveiligde verbindingen te downloaden of alleen uit de Mac App Store te halen.

Moderatie-faq Wijzig weergave

Reacties (65)

Dit is niet echt een "lek" te noemen. Libraries inladen is iets wat alle besturingssystemen die met shared libraries kunnen werken sinds het bestaan van libraries doen. Wat hier gebeurt is libraries plaatsen op plekken waar ze verwacht worden. Je moet dus libraries plaatsen of overschrijven. Dat is weinig anders dan complete binaries overschrijven. Standaard kan je onder OS X niet zomaar de plekken waar libraries en binaries opgeslagen zijn beschrijven, dus moet je admin rechten hebben. En als je die hebt, tja, dan kan je net zo goed rechtstreeks kwaadaardige code uitvoeren.
Ik werk sinds een tijdje als standaard user op mijn Mac omdat het veiliger zou zijn. Voor bepaalde acties moet ik dan admin-credentials invoeren. Het gevaarlijke is dat het verplaatsen van een application package naar de global applications-folder een van die acties is.

Uiteraard download ik applicaties alleen van betrouwbare bronnen, maar mijn computer is tijdens de kopieeractie wel even kwetsbaar door de elevated permissions. De applicatie open ik na de installatie wel met mijn beperkte account, het kwaad is dan als ik het goed begrijp al geschied.
Als je de presentatie doorleest is alles wat nodig is toegang tot de applications folder. Daarnaast laat hij ook nog zien hoe je een .dmg bestand bouwt en gatekeeper omzeild.

https://support.apple.com/en-us/HT202491
For apps that are downloaded from places other than the Mac App Store, developers can get a unique Developer ID from Apple and use it to digitally sign their apps.
Ook voor ondertekende applicaties werkt zijn methode omdat hij de applicatie zelf niet hoeft aan te passen.

https://s3.amazonaws.com/s3.synack.com/canSecW.pdf
affects apple & 3rd party apps
abuses legitimate functionality
no binary / OS file modifications
Eigenlijk kan je dus geen dmg bestand meer vertrouwen en zit je vast aan de Apple store. Dat klinkt in eerste instantie precies hetzelfde als exe bestanden onder windows maar daar word de hele installer exe/ondertekend. Bij osx is dat blijkbaar alleen de binary in de dmg die ondertekend word. Gezien veel en ook veel officiele dmg bestanden over http geserveerd worden is een mitm attack waar je dmg verwisseld met een verbouwde dmg vrij simpel. Bij windows installers heeft MITM attack geen zin omdat dan dus het ondertekende deel gemodificeerd word.

Dit is toch wel wat anders dan 'als je root bent kan je kwaad doen verhaal' - het hele ondertekenen van applicaties icm dmg is gewoon stuk.

Bijvoorbeeld vlc: http://www.videolan.org/vlc/download-macosx.html -> http://mirror.nl.leaseweb....2.0/macosx/vlc-2.2.0.dmg
nu weet ik niet of die gebruik maakt van rpath en of die niet gewoon in de apple store zit en dus is mogelijk een slecht voorbeeld. Geen idee want ik ben verder geen mac gebruiker.

[Reactie gewijzigd door Mr_Light op 21 maart 2015 05:48]

Interessant. Een package (installer) kan je wel signen. En dat verdient toch de voorkeur boven een dmg. Een dmg is zoiets als een zip. De dmg zet je niet in de applicatie folder, alleen de applicatie die wel signed is.
Los daarvan lijkt dit een redelijk ernstig lek. Hoewel elk stukje malware al op zich gevaarlijk is als het al onder gewone user rights draait.

[Reactie gewijzigd door SoloH op 21 maart 2015 14:32]

In de praktijk zal dit niets uitmaken. Met een admin account op OSX moet je alsnog, altijd, je credentials invoeren als iets de root rechten wilt gebruiken, dit is niet anders dan bij een gebruikers account.
Goeie rule of thumb is sowieso om altijd even aan je hoofd te krabben als OSX om je admin wachtwoord vraagt en je zit veilig :)
En waarom heb je een mac gekocht als ik vragen mag?
Met de prijs van het RAM van tegenwoordig weerhoudt niemand je ervan je code statisch te linken. Wordt je applicatie wel één groot bestand en gaat een update inhouden dat je dat gehele bestand dient te vervangen.
Wanneer is het concept van dynamisch linken bedacht? Welke motieven lagen daaraan ten grondslag?
Diverse redenen:

- Opslagruimte
- RAM
- management (een library update voor alle afhankelijke programma's)
- Plug-in opties zodat een derde partij functionaliteit kan toevoegen

en zo zijn er vast nog wel meer.

Natuurlijk kan je static linken, je kan ook alles een grote binary maken en geen filesystem gebruiken. Hell, een ROM in je CPU stoppen die naar ingebouwd RAM gekopieerd wordt en het hele BIOS/bus/chipset verhaal skippen. Maar dat gaat altijd ten koste van flexibiliteit en compatibiliteit.
Dat waren ook inderdaad de argumenten die ik had bedacht. Echter kun je je afvragen of die wel zo valide zijn c.q. waren:

- RAM is nu goedkoop te verkrijgen;
- Opslagruimte idem;
- library update is niet relevant wanneer je statisch linkt (frappant is hoe Windows omspringt met de DLL's binnen WinSxS door voor elk applicatie een kopie van DLL's in de folder van betreffende applicatie in die WinSxS te plaatsen. In mijn ogen wordt daarmee de DLL-hell wel op weliswaar op een werkzame manier opgelost maar is het dan ook niet verwonderlijk dat die WinSxS-folder zo groot wordt.).
- plug-in opties kun je ondervangen met een pipeline binnen je shell. Was toch het idee achter Unix.

Misschien is het concept van dylib wel een anachronisme? Microsoft heeft het opgelost zij het wel quick and dirty.
Standaard kan je onder OS X niet zomaar de plekken waar libraries en binaries opgeslagen zijn beschrijven, dus moet je admin rechten hebben.
Dat gebeurd dus ook niet, in het artikel gaat het 2 maal over het inladen van library's die op niet-standaard locaties staan, oftewel, niet beveiligde locaties.

In het ene geval zoekt een programma zelf buiten de bedoelde (en beveiligde) directories, in het andere geval past een aanvaller een onderdeel van het OS aan waardoor er standaard al in (specifieke) niet beveiligde directories word gekeken.

Het lek zit hem dus juist in dat het mogelijk is die beveiligde directories te omzeilen, dus dit is wel degelijk een (behoorlijk) "lek" te noemen.
Nog niet helemaal:

- Niet-standaard locaties kan je inderdaad als admin zelf aanzetten (als admin dus)

- Locaties waar standaard geen libraries staan maar wel gezocht wordt vallen onder standaard locaties

Op z'n best kan een programma dus een library inladen en dus code uitvoeren met de rechten van de user. Dat is weinig anders dan een programma rechtstreeks met de rechten van een user uitvoeren.
Oow in libraries nog wel. En op een keynote van een aantal jaren terug waren ze nog bezig over "dll-hell"

Achja, zo is het weer zichtbaar dat het sprookje over dat Mac OS X zo veilig is niet klopt... Dat weten wij hier op Tweakers gelukkig allemaal, vind het alleen zo jammer dat ik dit hoor van de 'onwetende consument' en dan met mij de discussie in gaat... "Want Kees die heeft er een en die zei dat"
Het is over het algemeen wel nog altijd veiliger dan Windows lijkt me, en dat is uit ervaring.

Uiteindelijk is geen enkel systeem 100% veilig en moet men altijd voorzichtig zijn.
De veiligheid ligt voornamelijk bij de gebruiker. Als je onder Windows als een normale user gaat werken en niet onder Administrator ben je al een stukje verder. Dat is hetzelfde als dat je onder OS X het root account ontgrendeld en daarmee gaat werken, dan ben je ineens een stuk kwetsbaarder.

Om de term maar eens te gebruiken: PEBCAC

[Reactie gewijzigd door sfranken op 20 maart 2015 19:36]

Onder OS X kan je niet direct onder het ROOT account gaan werken.

Als je eigen account "ADMIN" Maakt log je nog steeds in met user rechten. Wil je iets installeren wat aanpassingen maakt op je systeem zal je altijd je eigen ADMIN wachtwoord moeten opgeven.. Dat dan ook weer gelijk is aan ROOT..

Zonder dat wachtwoord kom je niet verder.. Sterker nog.. je kan niet eens zonder je in het systeem gaat klooien als ADMIN direct inloggen.. Zoals dat wel met Windows mogelijk is.. en dan ook nog eens UAC uitzet.
Voor Ubuntu (en andere Linux-distributies) geldt hetzelfde; standaard als gewone gebruiker en "root" zodra je systeemwijzigingen wilt doorvoeren. Zo kun je eigenlijk niks fout doen.

De fout die Microsoft maakte was om UAC irritant te maken. Vaak was de harde schijf een hele tijd aan het ratelen waarop het scherm donker werd en die UAC-melding op je scherm kwam. Heb me daar altijd aan zitten ergeren, dus verbaas ik me er ook niet om dat men deze functie massaal uitschakelt. Feitelijk heeft dit soort beveiliging in Windows weinig zin, omdat je het venster gemakkelijk weg kunt klikken zonder een wachtwoord in te hoeven voeren.

Daarnaast ben ik genoeg mensen tegen gekomen die ondanks UAC toch "ransomware" o.i.d. op hun systeem hadden gekregen. Dit zal denk ik meer te maken hebben met de manier waarop Windows in elkaar is gezet.

[Reactie gewijzigd door Titan_Fox op 21 maart 2015 08:51]

XP heeft nooit UAC gehad.. Nu stappen mensen over op Windows Vista/7 en hoppa UAC.. Zonder dat er duidelijk door MS is gecomuniceerd naar de normale gebruiker wat het inhield..

Dat is denk ik de fout geweest van UAC.. Ik zie nog steeds her en der beheerders die nog steeds UAC uitzetten.. Wat ik gewoon weg dom vind...

het is er juist voor zodat niet elke EXEcutable in je systeem gaat rommelen.. Als het niet onder user kan draaien dan is het rommel.. al met al komen er steeds meer apps die onder user kunnen draaien. en ook nog steeds rottigheid uithaald.
*PEBCAK

Heb nog nooit gehoord van een Ceabord.

Maar je hebt verder wel gelijk. Nu ben ik echter wel van mening dat Apple hier iets aan moet doen. Nu is het met de standaard instelling al lastiger om iets uit onbetrouwbare bron te installeren (hoewel het mij geen **** uitmaakt aangezien ik mijn mbo toch alleen voor niet persoonlijke spullen gebruik), toch is het nog steeds een "probleem".

Edit: *kuch http://en.m.wikipedia.org/wiki/User_error kuch*

[Reactie gewijzigd door supersnathan94 op 21 maart 2015 21:50]

Problem Existing Between Computer And Chair, ergo PEBCAC
Bij de meeste Windows-installaties ben je standaard administrator. Op dat vlak doen MacOS en Linux het toch een stuk beter. Heeft er natuurlijk ook voor een deel mee te maken dat Windows het dominante systeem is.

Op zich vind ik dat prima; vanwege het grote marktaandeel zie ik Windows al een soort van magneet voor malware. Op die manier hoef ik me minder snel zorgen te maken om infecties bij mijn Ubuntu-installaties.
Bij de meeste Windows-installaties ben je standaard administrator.
Dat is bij de instalaltie/eerste configuratie anders in te stellen, maarja, dan moet een beheerder een klikje meer doen..
Ik denk dat op gebied van veiligheid er niet veel verschil meer is tussen de verschillende grote besturingssystemen. De meeste kwaadaardige software komt binnen door lekken in third party applications (bijv. java of adobe reader) en door mensen die bijlages openen die ze nooit hadden mogen openen.
Bij osx is het probleem meestal via Java. Daarom word die niet meer standaard geïnstalleerd in osx. Zelf installeren als je het nodig hebt, eigen risico.
Elk systeem heeft hier last van. Bij windows zijn het DLL files, bij Unix en Linux zijn het .so files en bij OS X ook (gok ik) i.c.m. dylib files.

Echter zijn de meeste verise van .so files symlinks naar andere versies, voorbeeldje:

- libedit.so.1
- libedit.so.1.2 -> libedit.so.1
- libedit.so.1.5 -> libedit.so.1

Dat is ook redelijk kwetsbaar. Verwijder libedit.so.5 (symlink) en plaats hier een file die overeen komt maar ook nasty code uitvoert en je gaat nat.
Dat zal normaliter niet gaan zonder "root"-toegang. Deze bestanden staan in mappen die niet zonder meer gewijzigd kunnen worden. Om de pakketten van "libedit" (uit jouw voorbeeld) bij te werken moet je overal je "root"-wachtwoord opgegeven, ongeacht of je dit doet via het Software Center, de Update Manager of APT-GET in een terminalvenster.

Omdat je standaard als user bent ingelogd kun je dus niet zomaar wijzigingen aan systeembestanden doorvoeren. Hetzelfde geldt voor geïnstalleerde software; die hebben daar standaard geen rechten voor, tenzij jij ze dat geeft.

Zolang jij je browser niet als "root" gaat draaien en je systeem up-to-date is, is de kans op een malwareinfectie bij Ubuntu heel erg klein. Dit in tegenstelling tot Windows, waar veel browser-malware in de "Temporary Internet Files" wordt opgeslagen en uitgevoerd.

[Reactie gewijzigd door Titan_Fox op 21 maart 2015 09:47]

Dat zal normaliter niet gaan zonder "root"-toegang. Deze bestanden staan in mappen die niet zonder meer gewijzigd kunnen worden. Om de pakketten van "libedit" (uit jouw voorbeeld) bij te werken moet je overal je "root"-wachtwoord opgegeven, ongeacht of je dit doet via het Software Center, de Update Manager of APT-GET in een terminalvenster.
Niet helemaal. Het is je user password voor een sudo sessie. Root staat als het goed is 100% dicht.
... is de kans op een malwareinfectie bij Ubuntu heel erg klein ...
Leuk en aardig maar ik had het niet over Ubuntu, maar over OS X. Waarom sleep jij overal Ubuntu mee naar binnen? Ik heb iets meer vertrouwen in Debian en Canonical om gaten te fixen dan Apple. Het is een onderbuikgevoel en er zal vast geen hol van kloppen maar bij Apple is het lastig zien wat ze precies fixen, en welke OSS libraries ze gebruiken.

Ja, ik weet dat ze een overzicht van OSS software in OS X hebben maar dat zegt nooit alles natuurlijk. Je hebt ook nog dependancies, en die hebben weer dependancies.. je snapt 'm wel denk ik,
Ik heb iemand ooit horen zeggen: 'een apple werkt met een processor dus daar kan geen virus op komen zoals dat op een windows computer wel kan.'

Nouja dat hoef ik verder niet toe te lichten.

Vervelend is wel dat deze lek mij vrij lastig te dichten lijkt. Misschien het zoek overal uitzetten als de files niet te vinden zijn. Maar dat via de help file lijkt me gewoon onoverkomenlijk? Als de originele files op de een of andere manier gedelete kunnen worden dan zal die helpfile dus altijd naar de verkeerde bestanden kunnen verwijzen.
Vertel die "iemand" dan alsjeblieft het volgende: iets met klok en klepel, stop met reproduceren, iedere computer werkt met een processor.

Het stomme is dat je voor het vervangen van dergelijke bestanden rootrechten nodig hebt. Geeft een gebruiker deze dus aan het proces, dan kan dit proces net zo goed zelf gewoon code uitvoeren om dingen te doen. Dit is dus een kwetsbaarheid die feitelijk gezien te ver gaat om ooit gebruikt te worden, want waarom zou je dan niet gewoon direct dergelijke code uitvoeren? Het volledige herschrijven van libraries zodat de functie ervan wel behouden blijft, terwijl je ook andere zooi er mee kan uitvoeren is nogal ingewikkeld.
Volgens mij snap je net als veel tweakers hier die 'allemaal' van alles weten helemaal niks van wat hier nou precies 'gevonden' is.

Het 'probleem' hier is niet anders dan binaries plaatsen of vervangen. De infectie heeft vooralsnog rechten nodig om geplaatst te kunnen worden, en met diezelfde rechten kan je net zo goed rechtstreeks kwaadaardige code uitvoeren.
Ja dat leek mij ook al. Ik vind het nogal vreemd nieuws.

Uit de bron "attackers need only to ‘plant’ specially crafted dynamic libraries to have malicious code automatically loaded into vulnerable applications."

Dus een aanvaller hoeft alleen maar een speciaal gecodeerde dylib te plaatsen op een plek waar de user alleen bij kan als root.

Ik begrijp wel dat het een lek is, welke gebruikt kan worden zodra er passwords zijn buitgemaakt - het is een manier die steevast werkt, maar echt kritisch lijkt me dit dan weer niet.

Omdat, zols johnkeates zegt, als je al root admin bent, dan kun je die code ook direct uitvoeren.
Er is wel een verschil in objectieve veiligheid en relatieve veiligheid. Of zo iets :-). Of te wel. Met osx ben je gewoon veiliger omdat je gewoon veeeel minder bloot wordt gesteld aan aanvallen en malware. Voor de leken zeker. Die klikken vaak toch maar raak.
Maar als je de installers gewoon van legitieme websites af haalt en daarna de SHA256 controleert is het toch goed? Hoe wil een aanvaller daar precies tussen komen dan? De precieze werking is mij nog niet helemaal duidelijk...
De incorrecte bestanden kunnen ook via andere malware worden aangeleverd (zoals een virus). Je moet geen tainted installers hebben.

Bijkomend: hoeveel mensen kijken de hash waarde van een image na?
Ik download genoeg legitieme software buiten de store om, en controleer geen hashes.
Vanavond dat tooltje maar eens draaien.
De installer hoeft niet geïnfecteerd te zijn. Wanneer een bepaald dylib-bestand niet gevonden kan worden op de juiste plek gaat de applicatie opzoek naar andere locaties. Je zou bijvoorbeeld dylib-bestanden kunnen toevoegen aan torrentfiles etc. om zo foutieve code in te laden in een legitieme applicatie. Je moet er dan wel eerst voor zorgen dat de orginele dylib-bestanden verdwijnen.

Uit een eerste scan komt ook naar voren dat Bittorent Sync, iExplorer, Microsoft Office (2011), JVM en verschillende steam games ook vatbaar zijn.

[Reactie gewijzigd door nanoChip op 20 maart 2015 18:37]

Dit lijkt me een generiek probleem dat je altijd hebt met zgn. dynamic libraries? Zou me niks verbazen als je dezelfde issues hebt in Windows en andere unix-en dan Mac OS X.
Klopt. Je kunt ook statisch linken. Wat wel de omvang van je programma vergroot. Of dat met de prijzen voor RAM nu nog steeds zo'n groot issue is als toen RAM nog veel duurder was is nog maar de vraag.
Het hele concept van dynamic linked libraries werd ontwikkeld met dat RAM veel duurder was.
Voor een library die echt specifiek voor jouw applicatie is kan dat nog wel maar met libraries die met het OS meegeleverd worden kan dat natuurlijk niet. Dan zou nagenoeg iedere applicatie met zijn eigen (halve) OS komen en krijg je helemaal een hel van verschillende versies.
Oef....
Dit zijn behoorlijk grote beveiligings risico's. Hoop dat Apple ze snel dicht
Daar zijn ze al te laat mee, ze zijn al tweemaal op de hoogte gesteld van het lek. Goed dat Google ze niet gevonden heeft anders lag het al op straat.
Google geeft bedrijven voldoende tijd om lekken te dichten. Het is niet zo dat als zij vandaag een lek vinden dit morgen wereldkundig maken.
Het is maar natuurlijk wat jij voldoende tijd noemt, niet alles is zo 1-2-3 te fixen zonder rekening te moeten houden met reeds bestaande software die ook gewoon nog zonder problemen moet kunnen blijven draaien..
http://www.nu.nl/apps/401...ivirusapps-app-store.html |:(

Of helpt een anti-virus inderdaad niet in zulke gevallen omdat (uit het artikel) : Dit soort programma's zijn op iOS wat minder zinvol dan op bijvoorbeeld Android omdat delen van het systeem niet toegankelijk zijn voor dergelijke scanners.
Een virusscanner zou kunnen helpen maar dan moet wel bekend zijn dat 'naam.dylib' (of andere library) met signature X een virus is want anders heeft het nog weinig zin.

Tevens denk ik dat het artikel wat je daar aanhaalt meer gaat om de iOS App Store en niet de Mac App Store. In de MAS zijn er nog wel Virusscanners te vinden.
Ik weet (ook onderstaand voor biteMark) dat IOS =! OS X maar ook weer uit het artikel: "maar gaat het om een brede campagne van Apple tegen antivirusapps." dus ik bedoel maar...
Ik draai zelf geen antivirus op OSX, maar updaten die niet buiten de App store om? Dan kan ik me voorstellen dat Apple ze (tijdelijk) heeft verwijdert i.v.m. deze dylib lekken.
Dat artikel gaat om iOS. Compleet verschillend.
iOS en OS X zijn twee verschillende dingen |:(
Op iOS, dus de iPhone/iPod/iPad's werken scanners niet omdat alles in een sandbox zit.
Werkt dat ook nog na de Security Updates van vandaag?
Hoe ironisch is het dat Synack het scantooltje niet via de App Store, maar als een rechtstreekse download van haar web site aanbiedt?

Update:

"isn't it ironic that Apple wouldn't allow this in the app store because it needs scan/access the process list/file system? Oh, and Apple Apps are downloaded over HTTP? (while this tool is downloaded over HTTPS) "
mailt Patrick Wardle mij.

[Reactie gewijzigd door Sjakelien op 22 maart 2015 09:02]

Is al gefikst met Security Update 2015-003, oud nieuws.
LoL, Matlab staat in de lijst van hijacked applications.
Het zal wel een false positive zijn. Mijn brakke matlab code voor mijn schooltaken mogen ze van mij part hebben :p

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True