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

Hackers hebben op de eerste dag van hackbijeenkomst Pwn2Own Googles browser Chrome en Apples evenknie Safari gekraakt via tot nu toe onbekende kwetsbaarheden. In beide gevallen ging het over een use-after-free-kwetsbaarheid.

Hacker JungHoon Lee gebruikte een reeks van vier kwetsbaarheden om Safari's beveiliging te kraken, zegt Threatpost. Naast een use-after-free-kwetsbaarheid gebruikte hij ook een heap overflow-bug om de beveiliging te kraken en code te kunnen uitvoeren op de computer. Bij use-after-free-bugs is de reallocatie van vrijgemaakt geheugen te misbruiken, door bijvoorbeeld een buffer overflow te genereren.

Een groep onder de naam Tencent Security Team Shield kraakte de beveiliging van Chrome, waardoor ze op een systeem root-rechten konden krijgen. De grootste kraak van de dag kwam op naam van 360Vulcan Team, die 80.000 dollar verdiende door een kwetsbaarheid aan te tonen in Flash en de Windows-kernel, waardoor de Adobe-toepassing systeemrechten kreeg en de hackers willekeurige code konden uitvoeren.

Pwn2Own is een competitie waarbij hackers proberen elkaar de loef af te steken door zo snel mogelijk de beveiliging van met name browsers te kraken. Dat doen ze door middel van niet eerder bekende lekken.

Moderatie-faq Wijzig weergave

Reacties (89)

Hele domme vraag wellicht maar hoe vind men deze kwetsbaarheden?
Veelal door simpel weg de beschikbare code te bekijken en daar in stukjes te ontdekken die misschien wel een probleem kunnen op leveren, deze vervolgens bestoken met verzoeken/data/opdrachten die de kwetsbaarheid die je vermoed ook kunnen triggeren. Het kan heel goed zijn dat je een bepaalde kwetsbaarheid vermoed maar dat ergens anders in de code de data die je verstuurd al gefilterd wordt om te voorkomen dat de achterliggende componenten eventueel "foute" data ontvangen.

Andere methodes zijn door simpel weg een hele zooi meuk naar bepaalde systemen te sturen en te kijken hoe ze reageren als je geluk hebt zie je dan dat er dingen gedaan worden die eigenlijk niet zouden moeten gebeuren zo als meer geheugen uitlezen dan de bedoeling is dan wel bepaalde data als code behandelen terwijl dat niet als zo danig behandeld zou moeten worden.

Veel al is het een groep mensen die samen allerlei expertises inzetten om te proberen een gat te vinden in de beveiliging van bepaalde software. In dit soort competities is de beschikbare tijd zo relatief kort dat je als enkeling veel al weinig kans maakt om niet alleen een bug te vinden maar ook een exploit te schrijven om te bewijzen dat het geen je gevonden hebt ook echt misbruikt kan worden.
Zelf denk ik dat sommige deelnemers al enkele kwetsbaarheden ontdekt hebben en wachten op dit event omdat ze er toch geld mee kunnen verdienen.

Natuurlijk kan je ook kwetsbaarheden ontdekken als je een boel mensen bij elkaar zet maar mensen werken buiten de events ook samen. Geld speelt dus zeker een rol en voorbereiding ook.
En publiciteit is belangrijk. De "concurrentie" tussen hackers(groepen) is best groot. Elkaar de loef afsteken op een groot evenement levert meer naamsbekendheid op dan stilletjes melden aan een Google of andere partij.
Uiteraard speelt geld een rol. Had je iets anders verwacht dan?

Echt ethisch hacken doen er niet veel meer 'those days'. ;)
Ik had niets anders verwacht alleen gaat het mij dat men in het artikel brengt alsof het werkt dat je een paar dagen een paar mensen bij elkaar zet en hup de ene na de andere kwetsbaarheid komt boven tafel. Dat is het idee dat gewekt wordt en dat is natuurlijk een pure schijnvertoning.

Natuurlijk draait het bij zeg 95% op de poen, bij een klein deel om de eer wie de beste is.
Reverse engineering van programma's en aanverwante zaken (bijvoorbeeld drivers / OS / hardware).
Dat is niet eens altijd nodig, veel delen van Google Chrome (en andere browsers) zijn namelijk open source.
nee, maar wel interessanter, want dat wil zeggen dat de source vaak niet publiek beschikbaar is en er dus potentieel veel minder mensen de kwetsbaarheid kunnen vinden (en dus ook pas veel later gepatched wordt)
Ik denk dat de meeste gevonden worden door nieuwsgierigheid 'hoe zou dat in elkaar zitten'
Ook kun je als je een beetje bekend bent met een codeer taal de elementen inspecteren en zien wat ze hebben geschreven. Zo kun je best wat vinden :)
Om in zulk doorontwikkelde software nog gaten te vinden moet je wel meer dan "een beetje bekend met codeer taal" zijn. Deze jongens begrijpen de taal door en door. Beter dan dat alle programmeurs het begrepen, die inmiddels al meer dan 45 versies hebben geschreven en nog steeds gaten achterlaten :P
Het zijn slimme jongens, mee eens. Maar bedenk wel dat het een stuk makkelijker is ergens een gaatje in te schieten dan ettelijke miljoenen regels code helemaal foutvrij te houden. Moderne browsers zijn tegenwoordig erg complex, en veranderen ook nog eens aan de lopende band. Heb liever dat het zo gevonden wordt dan misbruikt, dus ze doen prima werk wat mij betreft.
Prima werk is het zeker! Liever een witte dan een zwarte hoed ;)
Heel veel kloten met de programma's.
kraakte de beveiliging van Chrome, waardoor ze op een systeem root-rechten konden krijgen
Hoe kan dit eigenlijk?
- Heeft Chrome root rechten? Als Chrome ze al niet heeft, zit de bug dan niet elders dan in Chrome, maar meer in de laag tussen Chrome en het besturingssysteem? En als Chrome wel root rechten heeft, waar heeft die die voor nodig?
- Op welk besturingssysteem hebben ze het lek eigenlijk gevonden, of is dit universeel?

Iemand die er dieper in zit en wat toelichting kan geven? Buiten het marketing praatje zie ik niet echt de details.
Is het niet zo dat Chrome dezelfde rechten kan krijgen als de user die Chrome op dat moment open heeft staan? Veel mensen zijn helaas localadmin...
Op Unix gebaseerde systemen normaal gesproken niet. Daar ben je een gebruiker die onder water 'sudo' doet om 1 commando als root uit te voeren, waar ook het root wachtwoord voor vereist is.
Maar onder Windows inderdaad wel, tot op een zekere hoogte kan je zonder bemoeienis van ACL acties uitvoeren op de computer
Dat is niet anders op de Mac of onder Linux natuurlijk. En onder Windows ben je normaal gesproken ook geen ´root´ of local admin. UAC en gewoonweg een useraccount gebruiken zijn ook in Windows land al een tijd best practise.
Vandaar ook dat deze aanval waarschijnlijk 2+ lagen kent. Uit Chrome's sandbox komen, en dan een elevation of privilege om systeem-rechten te krijgen (ipv user of zelfs admin rechten).

Op de bijeenkomst van vorig jaar bereikte men toevallig hetzelfde en had toen 3 exploits in samenspraak nodig. Eentje in een Windows driver om inderdaad systeem-rechten te krijgen.

Nu zal dat ook iets soortgelijks zijn.
Uhm, nee, voor sudo heb je niet het root wachtwoord nodig, maar het wachtwoord van de user die sudo uitvoert.
Dat hoeft overigens niet, het is tegenwoordig slechts de standaard onder veel distro's.
Defaults rootpw
in je sudoers file is genoeg.

zie:
http://superuser.com/ques...ask-for-the-root-password
Niet het root wachtwoord, maar het wachtwoord van de eigen gebruiker.
En zelfs dit is vaak uitgeschakeld, zodat je gewoon 'sudo' kunt uitvoeren.

Tot... een gebruiker "sudo su" doet natuurlijk.
tenzij je een su all=nopasswd:all toevoegt ;)

Dodelijk maar oh zo handig. Als je zelf de enige user op je werkstation bent dan.
Dat telt niet. Als de hack root rechten weet te bemachtigen, dan moet dat ook werken als je de rechten beperkt hebt voor de gebruiker.
Dat klopt, en Chrome zal als root zelfs niet zomaar opstarten, dan moet je nog een home directory specifieren want deze weigert /root te gebruiken uit zichzelf.
Extensies (Of apps hoe chrome ze noemt) kunnen soms extra rechten krijgen. Hier kunnen waarschijnlijk fouten in zitten en zo hebben ze uiteindelijk toegang gekregen tot de root laag. Dit kunnen hackers gebruiken om in iemands systeem te komen door namen als "FREE YOUTUBE DOWNLOADER FREE NO COST FAST QUICK SAFE" waardoor consumenten denken "Goh, dat heeft veel functies". Na het geven van extra rechten kan de extensie een exploit gebruiken om in het systeem te komen (Root rechten) en dan kan het doen wat het maar wil doen.

Ik ben hier geen expert van, maar dit is het meest waarschijnlijke waar ik aan kan denken.
Op unix in ieder geval niet: programma draait onder de rechten van de gebruiker. Nooit meer tenzij je een eikel bent en met sudo je programma's gaat starten. Vreemd bericht dus. Chrome gebruiken en dan een lokaal root-exploit gebruiken zou ik wel snappen. Plugins hebben in ieder geval maximaal net zoveel rechten als een browser (en in Linux eventueel minder als er privileges gedropped worden).
Chrome Remote Desktop zou niet kunnen functioneren zonder meer rechten te hebben dan een 'browser'. Het moet de muis kunnen besturen en het toetsenbord laten typen. Ik ben geen expert, maar dat is een gevaarlijke combinatie sinds je dan het systeem kan besturen als hackers een exploit vinden om dit te doen.
Op unix in ieder geval niet: programma draait onder de rechten van de gebruiker. Nooit meer tenzij je een eikel bent en met sudo je programma's gaat starten.
Het zou nog moeten kunnen met een brute force attack, hoewel dat vrijwel voor eeuwig zou kunnen duren als je een complex wachtwoord heb ingesteld. Ik denk zelf niet dat dat de methode is die ze hebben gebruikt.
Laatste keer dat ik chrome remote desktop gebruikte moest ik toch echt een apart programma/driver installeren op het te besturen systeem.
Ja, precies dat. Hoewel dit niet is gebruikt door de hackers van Pwn2Own, ze kunnen mensen er in luizen om zoiets te installeren. Natuurlijk erg dom van de gebruiker zelf, maar er zijn computer analfabeten. Die denken "Zal wel goed zijn, er staat nergens iets slechts"
Wel, Chrome omzeild al een hoop beveiligingen in Windows, zoals het User Account Control enzovoorts, ... dus...
Heb je daar een bron van? Afaik is het niet mogelijk om (zonder exploits in te zetten) UAC te omzeilen. Daarnaast zou het ontzettend asociaal zijn, want een gebruiker stelt niet voor niets UAC in.
Allerlei software zoals teamviewer of splashtop kunnen het. Je kan vanaf de remote machine netjes op toestaan klikken in de uac prompt. En daar hebben ze echt niet mijn muisklik voor nodig.
Pas op. Je kunt alleen UAC prompts activeren als teamviewer als administratie runt. Anders lukt het niet.
Onjuist. Als ik op mijn werk Teamviewer gebruik (en dan werk ik dus met de door onze systeembeheerder correct geïnstalleerde clients), moet de gebruiker aan de andere kant UAC toestemming geven om het programma zelfs maar te starten. Ontzettend irritant, maar wel veilig.
Er is een verschil tussen het faciliteren van interactie tussen een remote verbonden gebruiker en een UAC-prompt, en het omzeilen van UAC-prompts.

Het eerste is wat software als TeamViewer en SplashTop doen, omdat anders de UAC-prompt wordt getoond op de zogeheten 'secure desktop', waar alleen een lokaal verbonden gebruiker interactie mee kan hebben.

Om dit te kunnen doen, moet je een digitaal ondertekende executable hebben, en in het manifest van je executable moet expliciet staan dat je gebruik wilt maken van de feature 'UIAccess'. Het is makkelijk te controleren of dit het geval is bij Chrome (hint: nee) en of het dus een risico is.
Tof, dank voor het uitleggen, wist niet dat je hier met de juiste toegang omheen kan programmeren. Is het nu die uac relatief goed werkt, nog nodig om standaard onder een user (non-admin) account te werken? Sinds windows 7 heb ik in de door mij beheerde systemen geen infecties meer gezien.
Als het goed is ben je, als lid van de Administrators-groep, normaal gesproken een 'normale' gebruiker. Alleen wanneer een programma daar om vraagt kunnen er in een aparte context dingen worden uitgevoerd met 'elevated' (Administrator) rechten. Als je UAC uit zet, is dit nog steeds het geval, alleen wordt er dan niet gevraagd of je het er mee eens bent (dus ben je je er niet meer van bewust dat het gebeurt).
Kan je dat onderbouwen? Bij mij draait chrome onder mijn eigen user en heeft geen admin rechten en wordt dus tegengehouden door UAC

http://i67.tinypic.com/2qnpdv8.png
Chrome 'omzeilt' dat door de applicatie in een user applicatiemap te plaatsen waardoor er geen extra rechten nodig zijn.C:\Users\<USER>\AppData\Local\Google
Ben wel benieuwd hoe ze die bugs nu precies vinden, en waarom bedrijven als Apple en Google daar zelf niet de tools/middelen voor hebben om dat geautomatiseerd te checken en dus voor te zijn.
Het testen van software is moeilijk, en vaak overgeslagen om deadlines te halen. Dus laat je het testen over aan hackers, en geef je ze een beloning zodat ze het niet aan de verkeerde mensen verkopen. Heb je ineens heel veel goedkope test engineers.

Er is een video van een hacker die omschrijft hoe hij een rootkit installeert via de thunderbolt poort op een mac. Dit via een oud protocol via hardware initialisatie op ROM in een pci device wat al jaren niet meer in gebruik is. Volgens mij was dit op een black hat bijeenkomst.
Het testen van software is moeilijk, en vaak overgeslagen om deadlines te halen. Dus laat je het testen over aan hackers, en geef je ze een beloning zodat ze het niet aan de verkeerde mensen verkopen. Heb je ineens heel veel goedkope test engineers.

Er is een video van een hacker die omschrijft hoe hij een rootkit installeert via de thunderbolt poort op een mac. Dit via een oud protocol via hardware initialisatie op ROM in een pci device wat al jaren niet meer in gebruik is. Volgens mij was dit op een black hat bijeenkomst.
Het testen van software is niet perse moeilijk maar het vinden van deze bugs wel. Tests zijn meestal gericht op functioneel en gebruikers gedrag en ik weet 100% zeker dat Google of Microsoft (of de bedrijven die op Pwn2Own staan) deze niet testen echt niet overslaan. Dit zijn bedrijven die gewoon een proces hiervoor ingericht hebben waar allerlei test scenario's worden afgevuurd. Echter dit zijn exploits en je kunt pas op een exploit testen als je weet waar een zwakheid kan zitten en dat is wel moeilijk.
Waarschijnlijk de broncode bekijken in geval van oss, proberen, proberen en nog eens proberen. Kan best zijn dat bugs uit browser A ook even getest worden in B al dan niet dan aangepast. Natuurlijk weten dit soort mensen ook precies hoe alles verwerkt word door het programma en wat het OS verder doet. Als je weet dat iets als admin word uitgeprobeerd hoef je "alleen" maar na te gaan hoe de execution chain van site naar admin stuk gaat.

En waarom niet getest? Ze komen telkens met nieuwe dingen. Als ze bij Google of Apple of *** wisten dat een bug kon ontstaan was de code waarschijnlijk nooit zo geschreven of de test waren er al.
Blind spots.
Als je met 100 man diep in de code zit, is het vrij eenvoudig om een eventuele exploit over het hoofd te zien. Dan is het aan de testers om die te vinden, maar ook daar zitten blind spots, zowel qua kennis als qua menselijkheid. Dus ja, zo kunnen exploits door de testfase heen glippen.
Omdat veel van die software heel erg ingewikkeld is.

Waar het op neer komt is dat alle delen van de code een interactie hebben met andere code.
Elke geschreven regel kan potentieel via vele tussenliggende verwijzingen voor een specifieke situatie een ongewenste reactie geven.
Er zal zeker getest worden en er wordt constant aan de hier genoemde software gewerkt maar het aantal mogelijke interacties is gigantisch. En dan moet je niet vergeten dat de verschillende inputs die de software te verwerken krijgt en al de verschillende gebruiksomgevingen ook weer voor heel veel verschillende situaties zorgen.

Er bestaan heel interessante theorieën en methoden om de complexiteit van software code te berekenen.
De simpelste (in ieder geval om software te vergelijken) is om het aantal regels code te tellen.
Zo schijnt de Chromium browser zonder commentaar uit al meer dan 4.5 MILJOEN regels te bestaan. De source is dan ook een download van 1.5 GB ...
En daar komt dagelijks meer bij.

Bron: https://www.quora.com/How...-of-code-is-Google-Chrome
Ook leuk: http://www.informationisb...ns/million-lines-of-code/
Google heeft continu Fuzzers draaien om vroegtijdig fouten zoals use-after-free te vinden. Dit zie je in elke nieuw major versie van Chrome terug in de opmerking "Various fixes from internal audits, fuzzing and other initiatives."

Fuzzers werken meestal met templates die steeds een klein beetje worden aangepast. Als zo'n pagina de browser doet crashen, dan weet je dat er een potentieel probleem is. Met ASan of SyzyASan kunnen zulke geheugenfouten eenvoudig worden gedetecteerd, waardoor het makkelijker is om de oorzaak van de crash te achterhalen (i.c.m. kijken naar de broncode).

Maar er zijn ontelbaar veel manieren om iets verkeerd te doen, dus ondanks al deze (automatische) hulpmiddelen dan zal er nog voldoende ruimte zijn voor beveiligingslekken.
"Zo snel mogelijk" - heeft dat alleen betrekking op de uitvoering? of ook het ontdekken? Ik kan me zo voorstellen dat je je voorbereid op zo'n dag en de hack dus eigenlijk al geoefend hebt, of in elk geval al weet waar de bug zit, ook al is die nog niet publiek bekend.
Voor zover ik dit goed gelezen heb uit de regels van de wedstrijd , worden de kandidaten per categorie één voor één willekeurig opgeroepen en mogen ze drie pogingen wagen binnen 15 minuten en mogen ze enkel de aanvalsvector openen, maar verder niets doen.
De sponsor van Pwn2Own is niet meer HP maar Zero Day Initiative en Trend Micro als ik het goed heb. Hier is een artikel dat ik had gevonden: http://arstechnica.com/te...cyberweapon-restrictions/
This year, Hewlett Packard Enterprise, Trend Micro, and the Zero Day Initiative partner to bring the annual Pwn2Own to Vancouver with a new twist to the rules to keep things interesting.
bron: http://blog.trendmicro.co...e-announces-pwn2own-2016/
Half correct :).
Haha, bedankt! Jij kijkt nauwkeurig!
Daar bedoelen ze de uitvoering mee voor zo ver ik weet. Ze hebben 3 pogingen om het te laten werken. Op deze link vind je een beetje informatie over hoe het zou werken (maar dan gaat het over Pwn2Own 2015): http://www.zdnet.com/arti...-every-browser-went-down/
Het is "use-after-free kwetsbaarheid" in plaats van "free-after-use kwetsbaarheid". Het is juist de bedoeling dat je het gealloceerde geheugen gebruikt, voordat je het weer vrijgeeft.
Je hebt gelijk behalve dat je het juist gebruikt na het vrijgeven niet voordat...
Zie ook onderstaande link

https://cwe.mitre.org/data/definitions/416.html
Klopt, dat maakt het juist een kwetsbaarheid (het zou niet gebruikt moeten worden nadat het vrijgegeven is). Het stond eerst andersom in het artikel.

[Reactie gewijzigd door Barth42 op 17 maart 2016 16:46]

Dit is eigenlijk wel zorgelijk. Als hackers white-hat hackers het bij zo'n evenement kunnen, kunnen andere hackers(/overheden) dat ook. Als ik dit zo lees zijn het best wel serieuze bugs.
Als je dit al zorgelijk vind dan kun je beter stoppen met het gebruik van alle software. Er bestaat haast geen stukje software dat bug vrij is. Daarnaast heeft hier waarschijnlijk maanden aan voorbereiding ingezeten. Het is dus niet zo dat ze even in 15 minuten een hack verzinnen.
Is het niet zo dat je bij Pwn2Own datgene wint wat je 'pwnt'? (vandaar de naam) Wat winnen deze mensen eigenlijk? Een gratis browser?
Ze winnen 80.000 dollar, dat staat letterlijk in het artikel. Je neemt ook het woord own te letterlijk. Het is een afkorting van "owning" wat veelal in games,geek/nerd context betekent: To win of triumph over.
Dat is dus "pwning", het eerste deel van de naam. Ik had het over "owning" in de context van de tweede helft. De wedstrijd heet letterlijk "pwn to own": winnen/triompheren om te bezitten. De opzet van de wedstrijd was dan ook oorspronkelijk dat je de laptop/telefoon/etc die je wist te kraken mee naar huis mocht nemen.
80.000 dollar cashen en waarschijnlijk ook meteen een baan aanbod met een niet misselijk salaris als ze deze nog niet hebben.
Heb echt totaal geen verstand van hacken of programmeren maar vind het wel heel knap hoe mensen toch altijd weer iets weten te bedenken/vinden om ergens doorheen en/of in weten te komen.
Het artikel had wel wat informatiever gemogen. Welke besturingssystemen zijn vatbaar voor deze kwetsbaarheden? Moet ik me zorgen maken over Safari op m'n iPhone? Chrome op een Chromebook?
Toch wel mooi dat je 80k kan verdienen door het aan te tonen van iets dat iedereen al jaren weet; Flash is zo lek als een pan zonder bodem.

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