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 , , 62 reacties

Beveiligingsonderzoeker Patrick Wardle stelt dat de OS X-beveiligingssoftware Gatekeeper nog steeds lek is na een recente patch van Apple. Het zou nog steeds mogelijk zijn om kwaadaardige code uit te voeren. Apple zou werken aan een uitgebreide oplossing.

OS X 10.10 YosemiteWardle, die al eerder een vergelijkbaar lek in Gatekeeper heeft vastgesteld, laat aan Threatpost weten dat de problemen door de meest recente patch nog steeds niet zijn opgelost. In eerste instantie had hij vastgesteld dat Gatekeeper bij installatie van nieuwe programma's alleen het eerste uitvoerbare bestand op een geldig certificaat controleert. Dit zou echter eenvoudig te omzeilen zijn door het eerste bestand een tweede, kwaadaardig bestand te laten uitvoeren. Dit zou vervolgens niet door Gatekeeper opgemerkt worden.

Volgens Wardle heeft Apple zowel de eerste als nu de tweede kwetsbaarheid 'gerepareerd', door de uitvoerbare bestanden, die Wardle als bewijs naar het bedrijf stuurde, op een zwarte lijst te zetten. De beveiligingsonderzoeker zegt verder dat het hem elke keer 'ongeveer dertig seconden' kostte om de patch te omzeilen en dat het op een zwarte lijst zetten 'een zeer slecht idee' is. Het enige verschil met de vorige patch zou zijn dat Apple deze nu via het antimalwareprogramma XProtect had geïmplementeerd.

Op dit moment zouden OS X-gebruikers kwetsbaar blijven, voornamelijk wanneer zij apps van onveilige sites downloaden en wanneer een aanvaller al een man-in-the-middle-positie op het netwerk heeft. Apple liet aan Wardle weten dat de vorige patches allemaal 'zeer doelgericht' waren en dat er binnenkort een uitgebreidere oplossing aankomt. De onderzoeker zal komende zondag over het onderwerp spreken op de SchmooCon-conferentie.

Moderatie-faq Wijzig weergave

Reacties (62)

Het is een leuke quick fix, de bestanden zelf op een blacklist zetten. Als permanente oplossing is het waardeloos, het lek zelf moet gedicht worden.
Toch is 'bestanden op een blacklist zetten' wel de manier hoe virusscanners werken...
Daar dus ook waardeloos?
Met blacklist werken is een slecht idee omdat een simpele name change al er voor zorgt dat het niet meer werkt. En wat als er bestandsnamen op de blacklist komen welke gelijke namen hebben als belangrijke core componenten? Ga je die ook blacklisten.

Bovendien werken virusschanners niet zo. Deze werken met signatures, zoeken een bestand af naar 1 of meerdere bekende signatures en als die voorkomen dan maakt het niet uit hoe het bestand heet. Daarnaast kan je ook nog eens de geldigheid van de digitale handtekening controleren welke mee gecompileerd is (certficaat) en natuurlijk de heuristics scan met sandbox (executable wordt geladen en uitgevoerd in een sandboxing emulator welke kan zien of het kwaadwillige code is).

Kortom blacklisten is gewoon een slechte oplossing. Is een plakbandje.
Is een signatures list niet gewoon een vorm van blacklisting ?
Dat klopt maar daar gaat het niet om.

Als ik een blacklist heb die op basis van filenamen werkt (bv. doom.exe) dan zolang de naam correct is (dus doom.exe) start het programma (dit kan dus van alles zijn, bv. het spel Doom of Skype of een virus).

Als ik een blacklist heb die dmv signatures of hashes werkt dan is het omgekeerd (alhoewel soms de naam deel vd hash is en dan is "anders" correcter), de naam maakt niet uit het gaat om wat 'binnen' de applicatie zit (bv. De Sims), het kan dan maar 1 ding zijn en is dus veiliger (tenzij je ofc een virus blacklist maar dat is ook hier moeilijker dan in de eerste optie).

Tl;Dr: Altijd de hash checken om te kijken of je programma legit is, naam heeft geen validiteit.
Tl;Dr: Altijd de hash checken om te kijken of je programma legit is, naam heeft geen validiteit.
Uiteraard maar Ik weet bijna zeker dat ze met blacklist vandaag de dag altijd minstens een signature db bedoelen. Want zelfs "per ongeluk" zijn naam collisions overal ('New Document.txt'). En dat was vroeger zelfs nog erger met 8.3 filenames in MS DOS/FAT. Mij moet je echt niet uitleggen wat crc32, md4, md5, sha1, sha256 zijn hoor ;)
...het kan dan maar 1 ding zijn en is dus veiliger (tenzij je ofc een virus blacklist maar dat is ook hier moeilijker dan in de eerste optie).

Tl;Dr: Altijd de hash checken om te kijken of je programma legit is, naam heeft geen validiteit.
Maar wat je beschrijft is een whitelist en daar gaat het hier niet om. Een blacklist kun je alleen gebruiken om te kijken of jouw programma erop staat. Zo ja, dan is het "niet legit", zo nee, dan weet je het niet. Een whitelist werkt precies andersom: alles wat erop staat is "legit", de rest mogelijk niet. En dat is precies het probleem van de blacklist: je hoeft maar een klein stukje te veranderen en je staat er niet meer op :)

En als zo'n blacklist gebruikt wordt als "als je er niet op staat, ben je een legitiem programma" is dat als beveiligingsmaatregel zo lek als een zeef.
Ik neem aan dat blacklisting via hashes of sugnatures werken en niet echt alleen het uitvoerbaar bestand naam.
in artikel staat dat het gaat om de bestanden op blacklist zetten.
Correct, er wordt vermeld dat bestanden op de blacklist worden gezet. Hoe wordt buiten beschouwing gelaten. Je kan er vanuit gaan dat het in dit inderdaad werkt met hashes of signatures.
Correct, er wordt vermeld dat bestanden op de blacklist worden gezet. Hoe wordt buiten beschouwing gelaten. Je kan er vanuit gaan dat het in dit inderdaad werkt met hashes of signatures.
Of met bestandsnamen.... Wordt nergens duidelijk.
Dus dan kunnen we beter nergens vanuit gaan, omdat we simpelweg geen idee hebben waar we het over hebben en dan kunnen we niet zeggen dat het een slecht idee is om met een blacklist te werken. Kortom te weinig informatie om conclusies te trekken over de praktijk, we kunnen wel fantaseren over theoretische situaties.
Het Xprotect.plist bestand bevat sha1sums (Identity key) en vermoedelijk substring matches (Pattern key) voor het detecteren van gekende malware. Zo kwam ik op deze pagina als ik de sha1sum van Item 19 op virustotal.com zoekte (https://www.virustotal.co...fa28956f1ef1008/analysis/).
Dat leek me al logisch, maar goed.
Maar een hash veranderen is niet bijster moeilijk toch? Stukje code veranderen en klaar is Kees. Dus feitelijk is die beveiliging net zo makkelijk te omzeilen als met alleen de bestandsnaam ;)
Wel als je toevallig weet hoe dat systeem werkt, en dat is niet met filenames.
Er is een wezenlijk verschil tussen een bestand en een bestandsnaam.
Met blacklist werken is een slecht idee omdat een simpele name change al er voor zorgt dat het niet meer werkt.
O werkt het zo?!?! 8)7 |:(

Het gaat om signature blacklists, waar alle malwarescanners mee werken.
Kortom blacklisten is gewoon een slechte oplossing. Is een plakbandje.
Ik vind malwarescanners in principe ook geen goede oplossing, een fix waardoor misbruik helemaal uitgesloten is, is wel een oplossing. Maar het is een prima noodverbandje. Niets meer, niets minder.
Met blacklist werken is een slecht idee omdat een simpele name change al er voor zorgt dat het niet meer werkt.
Ik mag hopen dat hashes voor blacklists gemaakt worden van de fileontents pv de filenames. Anders is het te makkelijk te omzeilen. ;)
Nee, blacklisting gebeurt pas wanneer andere zaken falen. Helemaal achterin het rijtje. En dus 'waardeloos'. De eerste zaken die gebeuren zijn bijvoorbeeld "check op signature applicatie/tool waarmee de virus gemaakt is" en heuristic scanning.
Probleem is dat de scanner het tweede bestand in een reeks negeert. Dan kan je blacklist nog zo goed zijn, als een bestand genegeerd wordt heb je er niets aan.
Maar is het dan niet heel raar dat het tweede bestand in een reeks genegeerd wordt? Ja, dat is heel raar. Altijd slecht als een bedrijf niet snel en adequaat reageert. Ditmaal is dat Apple en ook die krijgt gewoon de wind van voren. En terecht.
Dit is niet eens een quickfix. Het is helemaal geen fix om precies te zijn; een hacker lacht zich helmaal rot om dit soort reacties. Aangezien de onderzoeker binnen 30 seconden al weer een nieuwe set aan bestanden heeft klaar staan ( zoals het artikel vermeld) is het gewoon niets waard en ronduit prutswerk.
Prutswerk?

Het is een manier om te voorkomen dat het op grote schaal wordt gebruikt. Het is een korte termijn oplossing maar meer wordt ook niet beweerd.
Het lost echter niets op. Ook niet op korte termijn. Net zoiets als een spammer blokkeren op IP... Die heeft binnen een minuut weer een ander te pakken. Werkt niet, hooguit dus voor 30s-1m
Natuurlijk wel! Vergeet niet dat er een gatekeeper check aan vooraf gaat. Dit is puur damage control; zodra bekend is dat er een kwaadaardig programma piggypack rijdt wordt het geblacklist. De impact is dan beperkt.
Zoals in het artikel staat is Apple bezig met een uitgebreide/permanente oplossing. Ze hadden ook niks kunnen doen tot die oplossing klaar is, mij lijkt dit wenselijker.
Als je dat degelijke beveiliging noemt ;)
Voor beveiliging is het gewoon prutsen, een halve oplossing voor een probleem wat er niet mee opgelost wordt en net zo makkelijk kan worden misbruikt met of zonder patch.
Mij lijkt het wenselijker om het gelijk goed te doen, beter 1 keer goed opgelost dan een of meerdere nutteloze oplossingen die een gevoel van (onterechte) veiligheid geven. "Ze hebben het al gefixt dus ik maak me geen zorgen want het zal wel goed zitten nu" en ondertussen staat de deur nog steeds gewoon open...
@Hieronder: Normaal zou dat inderdaad het geval zijn, beter iets dan niets maar dit helpt alsnog niets, gat is nog even groot, wordt nog net zo makkelijk misbruikt en er is dus niks verbeterd, de tijd van Apple is verbruikt om een nutteloze '(tussen)oplossing' te maken, als die patch 99% van het lek had opgelost en er een zeer zeldzaam lek over bleef wat alleen te misbruiken is als dit en dat exact zo staat ingesteld was het nuttig, nu helpt het niks en hadden ze het dus beter in 1 keer goed kunnen doen dan 1 keer fout en dan pas (hopelijk) goed.

[Reactie gewijzigd door RGAT op 15 januari 2016 23:53]

Mij lijkt het wenselijker om het gelijk goed te doen, beter 1 keer goed opgelost dan een of meerdere nutteloze oplossingen die een gevoel van (onterechte) veiligheid geven. "Ze hebben het al gefixt dus ik maak me geen zorgen want het zal wel goed zitten nu" en ondertussen staat de deur nog steeds gewoon open...
Joh.. Echt? gelukkig gaan dit soort dingen binnen een dag. oh wacht.... Niet dus. Dit is slechts een tijdelijke (30 seconden kennelijk) oplossing en is puur in afwachting van de grote fix.
Ja, maar er is bij apple vast en zeker meer dan 30 seconden gestopt in deze maatregel die niets oplevert (want is 30 na release van de patch gekraakt). Zelfs het uitrollen van de update duurt dermate veel langer dan het kraken dat het echt BS is een oplossing te noemen. Het is gewoon bedrog om dit een oplossing te noemen
Nee het is broddelwerk, gewoon en lachwekkende oplossing waar een 4 jarige hacker op het kinderdagverbijf al om moet lachen.
Yep, prutswerk...

Een onderzoeker / white hat hacker die voorbeeldjes opstuurt naar Apple vergezeld van naam & toenaam zal hooguit een geintje erin stoppen maar geen echte malware.

Door het op een blacklist te zetten creëer je de situatie dat het geintje / proof of concept niet meer werkt, maar alle malware die erop gebaseerd is werkt nog wel 100%
Dus? Alleen als je kansloos op een zolderkamertje zit kun je 'white hat' zijn? Hij constateert en meldt een gevonden beveiligingslek prompt zodat het opgelost kan worden. Hij maakt et geen misbruik van, haalt er geen geintjes mee uit; wat is je probleem hier precies?
hij maakt het commercieel te gelde. Niets altruïstisch aan maar pure commercie.
Ik begrijp nog steeds niet helemaal waar precies de urgentie ligt. Een ontwikkelaar signeert zijn programma en biedt het als download aan. Een gebruiker downloadt het programma, voert het uit en Gatekeeper controleert of het certificaat van de ontwikkelaar geldig is en vraagt om toestemming om het uit te voeren. Deze kernfunctie werkt naar behoren, althans ik lees nergens dat dit niet fatsoenlijk zou werken.

Nu wordt het probleem geschetst dat een gesigneerde binary als een soort Trojaans paard code kan binnensmokkelen zonder dat Gatekeeper afzonderlijk naar deze bestanden kijkt. Ik herken inderdaad dat dit onder omstandigheden een probleem is, maar eigenlijk veronderstelt dit al dat (a) de ontwikkelaar niet heeft opgelet en zijn programma zodanig laat hijacken of (b) doelbewust daarin voorziet. In beide gevallen heb je daar als gebruiker niks aan en het lijkt mij ook niet het geval dat Gatekeeper bedoeld was om dat vertrouwen te garanderen. De binary zelf is namelijk nog steeds gesigneerd en daar worden verder geen eisen aan gesteld. Uiteindelijk zul je als gebruiker toch altijd moeten stilstaan bij de vraag waar je software vandaan haalt en of de ontwikkelaar wel competent is.

Als iemand een goede uitleg heeft, hoor ik dat graag. :)
Zonder de verdere details precies te weten, kan ik me de volgende situatie voorstellen:
Je downloadt een (legitiem, gesigneerd) bestand A dat op zijn beurt programma B (in dezelfde directory) aanroept. De aanvaller vervangt dan B met zijn eigen programma B dat dan door A wordt aangeroepen. Omdat Gatekeeper, zoals ik het hier en op Threatpost intepreteer, niet controleert of B ook gesigneerd is zit daar de fout.

Toevoeging:
Uit het vorige nieuwsbericht op T.net een stukje dat mijn verhaal bevestigt:
Volgens Wardle wordt er echter niet gekeken naar 'extra' content die in die apps wordt meegeleverd. Als een kwaadwillende er bijvoorbeeld in slaagt om een geverifieerde app te 'injecteren' met malware, dan wordt dat door Gatekeeper niet opgepikt.
Toevoeging 2:
Uit het gelinkte Threatpost bericht:
He reported that Gatekeeper checks only the initial executable that a user double-clicks on at app install. Wardle said that if the initial file then executes another file in the same directory that Gatekeeper would not verify the second one.

[Reactie gewijzigd door itcrowd op 15 januari 2016 20:24]

Nu wordt het probleem geschetst dat een gesigneerde binary als een soort Trojaans paard code kan binnensmokkelen zonder dat Gatekeeper afzonderlijk naar deze bestanden kijkt. Ik herken inderdaad dat dit onder omstandigheden een probleem is, maar eigenlijk veronderstelt dit al dat (a) de ontwikkelaar niet heeft opgelet en zijn programma zodanig laat hijacken of (b) doelbewust daarin voorziet.
(c) De ontwikkelaar biedt een mogelijkheid voor plugins...
In beide gevallen heb je daar als gebruiker niks aan en het lijkt mij ook niet het geval dat Gatekeeper bedoeld was om dat vertrouwen te garanderen.
Hmmm, laten we de naam eens gaan bekijken. Gatekeeper, grof vertaald poortwachter...
Dus jij vindt een poortwachter goed werk verrichten als bij een groepje mensen enkel de 1e persoon gecontroleerd wordt en iedereen die daarna komt mag gewoon doorlopen?
Dat gebeurd in clubs ook heel vaak. Bekenden die vouchen voor een ander. "jo ik ken hem, hij is chill en gaat met mij mee." Gebeurt zo vaak.
Ik ben het met je eens, het lijkt een grotendeels theoretisch probleem, dat veronderstelt dat je een programma downloadt dat een geldig certificaat heeft, dat dan programma's dowloadt die geen geldig certificaat hebben en die malware kunnen zijn. Wat mij betreft betekent dat gewoon dat in de eerste plaats dat het eerste programma reeds malware is. Maw als je malware installeert met een geldig certificaat kan die malware "door een lek in Gatekeeper" ook malware zonder certificaat installeren.
I'm not impressed...
Is het niet zo dat programma's die van de Mac App store komen in een sandbox omgeving draaien? Dit was volgens mij de reden dat diverse programma's uit de App Store gingen, omdat de programmeurs niet met de beperkingen die door deze beveiligingsmaatregelen veroorzaakt werden konden leven. Ik vraag me af of deze kwetsbaarheid ook werkt bij deze programma's.
Ik zie hierin mogelijke risico's bij hybrid apps, waarbij de schil alleen de look & feel uitdeelt, maar de content en features op een webserver draaien ipv in de native app.
Wat is dat toch tegenwoordig, kwetsbaarheden fixen door de specifieke exploit aan te pakken in plaats van de kwetsbaarheid zelf?

Het is ook zo kortzichtig: ze willen laten zien hoe snel ze de boel patchen maar doen dat op zo'n knullige manier dat de schrijver van de exploit bijna meteen er omheen kan en ze een nog slechtere beurt maken...

Zie ook Trend Micro: https://code.google.com/p...arch/issues/detail?id=693
Beter een (niet zo goede) tijdelijke fix totdat ze de goede fix hebben geschreven dan niks doen totdat ze de fix hebben geschreven.
Nou er valt niet echt te spreken van een tijdelijke fix. Meer een poging om net te doen alsof ze het gefixed hebben; door de exacte test van de programmeur te blokkeren. (Zie artikel/bronartikel.) Het enige dat ie hoefde te doen was een nieuwe te schrijven en voila: het werkte weer.

Dat is dus geen fix, maar meer een (slechte) poging tot security by obscurity; which isn't security.
Zoiets als nieuwe sloten op de deuren zetten maar ze niet op slot doen als je weggaat?
Is het niet zo dat het toevoegen van 1 regel code reeds een andere hash genereert, waardoor de signature verandert, waardoor blacklisting faalt, waardoor de blacklist weer dient te worden bijgewerkt, nadat de nieuwe variant van de malware o.i.d. is aangetroffen?
Is het niet zo dat het toevoegen van 1 regel code reeds een andere hash genereert, waardoor de signature verandert, waardoor blacklisting faalt, waardoor de blacklist weer dient te worden bijgewerkt, nadat de nieuwe variant van de malware o.i.d. is aangetroffen?
Als de hash functie voor de signatures goed is en ook goed wordt toegepast is zelfs het veranderen van 1 bit meer dan genoeg om een totaal ander resultaat te hebben.
Daarmee is het toepassen van blacklisting in deze kwestie dus een voor eeuwig durend onderhoudsfeestje geworden
Daarmee is het toepassen van blacklisting in deze kwestie dus een voor eeuwig durend onderhoudsfeestje geworden
Inderdaad. Een daarmee... dus geen oplossing. In ieder geval geen structurele danwel houdbare oplossing.
Alhoewel de werkelijke oplossing natuurlijk iets ingewikkelder is dan even snel wat ongewenste signatures te blacklisten vind het uberhaupt wel schandalig dat er een dergelijke kwetsbaarheid in zit. Het starten van processen is een nogal fundamentele functionaliteit van software. Er zijn genoeg voorbeelden te vinden van software die uberhaupt niet eens werken met threads maar die kinder-exemplaren van zichzelf starten en daarmee communiceren.

Mijn punt -- Er had sowieso rekening mee gehouden moeten worden; dat een proces een ander proces op kan starten. Ja, bij installaties is dat een wat meer uitzonderlijke situatie maar alsnog, het lijkt mij zo voor de hand liggend om het in ieder geval wel in de gaten te houden wat een installer doet op dat vlak dat ik het echt heel vreemd vind, deze kwetsbaarheid.
Het is een kwetsbaarheid die alleen optreedt als je al malware binnengehaald hebt op je computer: deze kan dan namelijk additionele bestanden binnenhalen zonder dat die geverifieerd worden. Het is dus een secundair beveiligingsprobleem (een bijkomend probleem dat optreedt nadat er reeds elders een probleem was).
Het is een kwetsbaarheid die alleen optreedt als je al malware binnengehaald hebt op je computer: deze kan dan namelijk additionele bestanden binnenhalen zonder dat die geverifieerd worden. Het is dus een secundair beveiligingsprobleem (een bijkomend probleem dat optreedt nadat er reeds elders een probleem was).
Ik begrijp de kwetsbaarheid volledig.

Voor een simpel voorbeeld van wat ik schreef -- zie de gemiddelde AV; die controleert ook gewoon ieder proces dat wordt opgestart. Merk je daar bijzonder veel van als eindgebruiker, waar het prestatieverlies betreft? Niet echt. Er is dus weinig reden om niet gewoon ieder proces te verifieren op een valide signature.
Tsja, als huidige oplossing een XProtect blacklist en lange termijn oplossing een Gatekeeper uitbreiding om een brede oplossing te bieden lijkt me toch geen vreemde strategie. Stel dat Apple nu al een Gatekeeper patch had voor een bredere oplossing was die al wel gepusht lijkt me.
Het systeem werkt wel, dankzij XProtect is een aantal jaar geleden een uitbraak van de Flashback malware gestopt, daarna werd het daadwerkelijke lek in Java gepatched dat door Flashback misbruikt werd.
Met de naam Gatekeeper (en zeker in combinatie met 'lek') denk ik nog steeds hieraan :)
π

[Reactie gewijzigd door Mappy op 15 januari 2016 19:28]

Ik had precies dezelfde gedacht (Pretorians waren het geloof ik)
En niet alleen Gatekeeper is lek, ook de Mac App Store. Kan al een aantal dagen niet meer inloggen in de App Store... mis op die manier belangrijke (systeem)updates dus hopelijk fixen ze dat lek ook...
Er is bij mijn weten geen probleem met de Mac App Store: aanleggen lukt perfect.
Waarom lukt het mij en een hoop anderen al dagen niet meer dan? Het begon met "De verbinding met de Mac App Store is mislukt" en een paar dagen later was ik ineens uitgelogd en nu krijg ik elke keer een foutmelding van een "untrusted certificate" als ik wil inloggen in de App Store en ik zie dat er onlangs meerdere mensen dit gemeld hebben. Vanwege die certificaat-melding én die meerdere mensen die het gerapporteerd hebben, doet het mij vermoeden dat er een lek is. Wellicht zit ik ernaast, maar je kunt toch moeilijk met me oneens zijn dat het er op zijn minst op *lijkt*...

[Reactie gewijzigd door Vistaus op 16 januari 2016 13:23]

Kan best dat jij een probleem hebt met de Mac App Store, maar ik heb nergens een veralgemeend probleem zien passeren, de voorbije dagen en al zeker niet een probleem dat uren laat staan dagen zou aanslepen.
Nou, dan heb jij op andere sites gekeken dan ik want ik heb toch echt meerdere reports gezien van anderen die er ook al dagen last van hebben...

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