Onderzoekers demonstreren hack Linux-pc via besmette usb-sticks

Duitse onderzoekers hebben op hackersconferentie Black Hat aangetoond hoe ze naast Windows-computers ook Linux-pc's kunnen overnemen met het manipuleren van de firmware van usb-sticks. Op Linux zijn wel sudo-rechten nodig, iets dat de onderzoekers verkrijgen via de screensaver.

De onderzoekers maakten onlangs al bekend de firmware van een bepaald merk usb-controllers te kunnen manipuleren. Via deze 'BadUSB'-hack kan een geïnfecteerde usb-stick andere usb-apparatuur die op dezelfde computer is aangesloten infecteren door zich voor te doen als usb-toetsenbord.

Die truc werkt niet alleen op Windows-pc's, maar ook op computers met Linux, zo claimen de onderzoekers, onder wie de bekende Duitse 'gsm-hacker' Karsten Nohl. De malware verkrijgt sudo-rechten door de screensaver naar voren te roepen en via een 'password-stealer' het wachtwoord dat de gebruiker intypt te onderscheppen. Met die sudo-rechten kan de usb-apparatuur andere usb-apparaten infecteren.

De onderzoekers zeggen dat computers usb-apparatuur moeten whitelisten om de gevolgen van BadUSB te beperken en dat virusscanners ook firmware van usb-apparatuur moeten gaan scannen op infecties. Een definitieve oplossing is het onmogelijk maken van firmware-updates van hardware, hoewel die methode ook als nadeel zou hebben dat bugs niet gepatcht kunnen worden.

Nohl wist eerder de software op simkaarten op afstand te kraken, waarna berichten konden worden onderschept en telefoongesprekken konden worden afgeluisterd. Ook hackte Nohl de ov-chipkaart en de encryptie die wordt gebruikt voor de beveiliging van gsm-gesprekken.

Reacties (169)

Op welke distro's is dit getest?

En wat als je geen screensaver gebruikt, ben je dan veilig? Ik heb namelijk geen screensaver!

Het is een proof of concept, gezien de potentiële mogelijkheden ben je nooit veilig. Het screensaver stuk is vooral een manier om de gebruiker het SU wachtwoord in te laten voeren. Hier zijn vast meer trucs voor te bedenken.

Daarnaast denk ik dat deze hack distro onafhankelijk, en grotendeels zelfs os onafhankelijk, werkt. Het simuleren van toetsenbord is levensgevaarlijk. Vervolgens moeten de commando's die dat toetsenborg geeft op maat worden gemaakt voor het os/distro.

Het sudo-password. Niet het superuser/root password wat bij SU gevraagd wordt. Geen linux-user zal als root zijn ingelogd, en dus ook niet de root-password hoeven in te voeren. Maar wel het user-password waarmee (afhankelijk hoe sudo is ingesteld) het sudo-commando kan worden uitgevoerd, en je dus root-toegang kunt hebben.

[Reactie gewijzigd door disheaver op 10 augustus 2014 11:23]

Het sudo-password. Niet het superuser/root password wat bij SU gevraagd wordt. Geen linux-user zal als root zijn ingelogd, en dus ook niet de root-password hoeven in te voeren. Maar wel het user-password waarmee (afhankelijk hoe sudo is ingesteld) het sudo-commando kan worden uitgevoerd, en je dus root-toegang kunt hebben.

Je kan als sudo'er ook gewoon een shell uitvoeren en daardoor het root-password veranderen in iets wat je zelf hebt verzonnen.

Ja, maar dat ga je juist niet doen om dat je sudo wil gebruiken of een veilige sandbox account, dat is juist het punt. Mensen gebruiken het niet voor de lol

sudo was niet voor niets uitgevonden om su voor de gemiddelde gebruiker te vervangen.

Met sudo kun je ook hele complexe toegangsregels maken; deze gebruiker mag alleen die executable aanroepen als su om daarmee specifiek die taak uit te kunnen voeren etc.
Als je ieman (of iets) volledig su geeft is dat vaak wel een vorm van onveilige overkill.

Dat gezegd hebbende, sudo su - is toch wel mijn persoonlijke favoriet.

Dat gezegd hebbende, sudo su - is toch wel mijn persoonlijke favoriet.

Wel, misschien is sudo -i dan wel iets voor jou

Anyway, het probleem met sudo is dat de meeste distro's de hoofdgebruiker van de PC (de gebruiker die aangemaakt werd tijdens de installatie) volledige sudo rechten geeft. Hoewel je dus met sudo heel specifieke rechten kan definieren, staat het by default voor die gebruiker dus bijna volledig open.

Ik moet toegeven dat ik de -i optie niet kende, maar mijn vingers zijn zo aan de combi gewend dat ik -i vast niet sneller kan typen.

Ik pas eigenlijk bij elke installatie die ik doe de sudoers (en group) file aan. Ik heb aardig wat scripts die ik met voldoende, maar niet meer dan dat, rechten wil laten lopen.

Maar waarom is su - je favoriet? Dat is nagenoeg hetzelfde als login root... niet heel safe.

Ik gebruik al 25 jaar *nix (en zo'n 20 jaar Linux). In die tijd had je nog geen sudo, en ook na die tijd was het niet beschikbaar op alle *nix varianten waar ik mee te maken heb gehad.

Ik heb mezelf aangeleerd om voorzichtig te zijn in een rootsessie en bij potentieel gevaarlijke commando's (rm, dd) eerst na te denken voor ik op enter druk.
Voor mij werkt dit prima.

sudo -s -u [user] is ook handig
switchen naar een andere user zonder zijn wachtwoord

Of je gebruikt sudo su <user> ;-)

Wat ik niet begrijp is het volgende,
om sudo te kunnen uitvoeren moet je wel eerst met je gebruikers account zijn ingelogt.
draait de usb driver dan reeds als de gebruiker om dan met sudo zijn rechten te verhogen?

Nee, het wachtwoord van de gebruiker wordt gecaptured en daarna met sudo ingelogd.

het (restricted) accountje waar ik vanaf werk heeft geen sudoer access

Wat als je toetsenbord niet op dezelfde bus zit als de boosaardigde USB-stick? Wat als je een PS/2-toetsenbord gebruikt? Kan die stick dan nog steeds je toetsenbordaanslagen verkrijgen?

Zo nee, dan is het enkel een beveiligingsprobleem van de hardware. Zo ja, dan is het ook een lek in Linux.

Het probleem is deels OS onafhankelijk omdat de firmware altijd wordt uitgevoerd.
Zie het als een stuk ROM dat in het geheugen van het systeem wordt gezet en wordt uitgevoerd.

In feite als er voldoende ruimte in het firmware zit dan zou je OS detectie in kunnen bouwen en op basis daarvan bepaalde functies kunnen aanroepen.

Het is overigens een probleem dat altijd al heeft bestaan, echter doordat het steeds makkelijker wordt gemaakt om firmware te updaten en die functionaliteit ook vrijwel altijd default aan staat en vaak zelfs niet fysiek meer kan worden uitgezet (zoals een jumper op een moederbord) wordt het steeds makkelijker om een dergelijke aanval uit te voeren.

De kern van het probleem zit hem in het ontwerp van de "pluggable" hardware, en met name in hoe de interfaced met het computer systeem.

Het is overigens een utopie om te denken dat dit probleem alleen USB omvat.
In principe is deze aanval uitvoerbaar met elk type hardware dat gebruik maakt van firmware die door de main CPU wordt uitgevoerd.

USB en met name een memory stick is alleen maar het meest voor de hand liggende, mede gelet op de manier hoe bijvoorbeeld Stuxnet de wereld in is geholpen.

[Reactie gewijzigd door Alfa1970 op 10 augustus 2014 18:04]

Het is overigens een utopie om te denken dat dit probleem alleen USB omvat.
In principe is deze aanval uitvoerbaar met elk type hardware dat gebruik maakt van firmware die door de main CPU wordt uitgevoerd.

Als je met de 'main CPU' de CPU in de PC bedoelt: die voert geen firmware uit natuurlijk.
Het is de interne CPU van de USB-stick die de firmware draait.
De PC ziet alleen een USB-keyboard, en installeert deze.
Vervolgens kan de USB-stick dus als 'keyboard' commando's gaan uitvoeren (maar je voert niet de firmware uit).

In theorie zou je nog wel een 'bootable' USB stick kunnen maken, die zelf custom-drivers aanlevert (bepaalde USB devices werken zo, ik heb oa een oude LG-telefoon die dat doet), en dan op die manier echt je eigen code door de CPU van de PC laten uitvoeren. Maar dat valt op.

Je x86 CPU heeft wel degelijk firmware, en kan zelfs updates ontvangen. Meestal gaat dit alleen via de BIOS.

http://nl.wikipedia.org/wiki/Microcode

Ik zeg niet dat een CPU geen 'firmware' heeft (eigenlijk is het BIOS de 'firmware', microcode is nog een stap lager).
Ik zeg alleen dat de CPU niet de firmware van de USB stick uitvoert.

Dat klopt, dat doet de CPU in de USB stick.

Dat zei ik hierboven al:

Het is de interne CPU van de USB-stick die de firmware draait.

[Reactie gewijzigd door Anoniem: 471038 op 11 augustus 2014 16:27]

De screensaver is een voorbeeld van privilege escalation. Elke wijze waarop je root kan verkrijgen, nu en in de toekomst, kan een vector zijn.

Voor dit voorbeeld ben je dus veilig, maar eventuele varianten niet.

Dit is volgens mij niet zo zeer privilege escalation (van iets uitvoeren vanaf een account met beperkte rechten volledige rechten krijgen) maar eerder keylogging, doordat de gebruiker wordt aangezet zijn wachtwoord in te vullen, die dan weer gebruikt kan worden om de sudo rechten van dat account te gebruiken.

Dat is mijns inziens implementatie. Het doel (uitvoeren als root/met rootrechten) wordt bereikt.

De stappen die gezet worden kunnen in tijd ver uit elkaar liggen. De expoit kan zich nestelen in het usb subsystem en periodiek op internet zoeken naar mogelijkheden tot escalatie. Zelfs als een bak nu veilig is daarvoor zal het in de toekomst best kwetsbare momenten kennen.

Precies, ik gebruik ook geen screensaver bij Linux. Sterker nog; ik heb ze niet eens geïnstalleerd. Ieder systeem is uiteindelijk wel te hacken; echter is de vraag of zo'n hack praktisch is en of je er ook schade mee toe kunt voegen.

Precies, ik gebruik ook geen screensaver bij Linux. Sterker nog; ik heb ze niet eens geïnstalleerd. Ieder systeem is uiteindelijk wel te hacken; echter is de vraag of zo'n hack praktisch is en of je er ook schade mee toe kunt voegen.

Jouw systeem staat dus altijd op de desktop te wachten tot jij, of een andere gebruiker, er iets mee doet?

Het is niet zo zeer de screensaver die het probleem is, wel het lock screen wat juist voor een veiligheidsreden is ingebouwd: Het beschermt namelijk tegen aanvallen van mensen die fysiek van jouw terminal gebruik willen maken.

Mijn HTPC zit op mijn TV aangesloten en bevat twee partities; eentje met OpenELEC en eentje met Ubuntu. Als ik in Ubuntu wat groots aan het downloaden ben (meestal torrents) en verder niks hoef te doen zet ik de TV uit. Met een screensaver blijf je energie aan het verstoken. Het scherm staat alleen aan als ik ook daadwerkelijk aan het werk ben.

Als ik echter met OpenELEC bezig ben (standaard boot partitie) ligt het er helemaal aan wat ik aan het doen ben. Bij films en series staat de TV uiteraard aan. Echter, als ik muziek aan het luisteren ben heb ik de TV nooit aan staan omdat ik OpenELEC (XBMC) bedien met een "remote" app op mijn iPad. Zo kan ik lekker muziek luisteren terwijl ik 50 watt per uur aan energiekosten bespaar.

Behalve mijzelf zit er niemand aan mijn computer(s). Ik zou dus niet weten waar ik een lock-screen voor nodig zou hebben. Er zijn lokaal sowieso geen belangrijke gegevens opgeslagen. Screensavers vind ik onzin; als je je "screen" wilt "saven" en bovendien lief wilt zijn voor je portemonnee zodra de volgende energierekening er aan komt zet je het ding toch gewoon uit ?

Volgens mij is het dan zelfs veiliger om juist geen lockscreen te hebben. Zo blijf je als gewone user ingelogd (zonder SUDO-rechten) en zou de hack d.m.v. deze USB stick simpelweg niet werken. Een hacker kan de kwetsbaarheid zo ook niet toevoegen omdat je daar extra softwarepakketten voor nodig hebt uit de standaard repositories die je zonder SUDO niet kunt installeren...

[Reactie gewijzigd door Titan_Fox op 11 augustus 2014 09:26]

Precies. Vind het ook wel grappig dat ze het linux systeem kunnen hacken mits ze sudo toegang hebben. Dat lijkt me nogal wiedes.

ze verkrijgen sudo via een truck ( de screensaver, maar alternatieven zijn denkbaar) dus je hebt er nog steeds geen erg in.

En wie zegt dat de inlog naam hetzelfde wachtwoord heeft als je su(do) wachtwoord?
Dat is namelijk bij mij niet het geval. Ze zouden van mij dus de "verkeerde" wachtwoord stelen.

[Reactie gewijzigd door Texamicz op 10 augustus 2014 19:17]

volgens mij, is dit een oude bug icm xorg/xscreensaver
daarom zijn diverse distros overgestapt op boinc

Het gaat niet eens om een bug in de screensaver maar gewoon dat deze op te roepen is, een andere screensaver veranderd daar niet veel aan. Zonder screensaver zou het ook waarschijnlijk mogelijk zijn om uit te loggen en zo via de login het wachtwoord te verkrijgen.

Wat heeft een bug in xorg/xscreensaver eigenlijk te maken met gridcomputing ?

Ik heb geen sudo geïnstalleerd.

Dan is su dus veiliger dan sudo.

Nee. Als jij een sudo commando uitvoert schakel je "even" over naar een superuser om dat commando uit te voeren, als je su gebruikt schakel je over naar een nieuwe sessie met een superuser.

Als je su gebruikt moet je het rootwachtwoord gebruiken, dat typ je minder vaak in dan je eigen wachtwoord. Als je sudo gebruikt is afvangen van je eigen wachtwoord voldoende om roottoegang te krijgen.

Hangt eraf of optie rootpw aan of uit staat in /etc/sudoers, heb je die aan staan dan heb je rootpw nodig bij sudo (standaard op OpenBSD geloof ik).

Rootrechten heb je ook niet altijd onbeperkt bij sudo, slechts tot wat in /etc/sudoers genoemd staat bok een gebruiker. Die kan je zeer ver beperken, ook al staat die bij veel distro's standaard vaak op 'all'

Niet helemaal, als je su aanroept zonder argumenten, of met '-' als argument ("su - " dus) dan roep je de root account aan, als jij dit doet: "su pietje - " dan log je in als pietje. Een aanroep naar su is dus niet meteen eentje om als root in te loggen, als dat logisch is.

Jullie zitten er allemaal naast :

User: Su - commando: het aanroepen en tijdelijk uitvoeren van super user rechten.
Sudo het per commando uitvoeren van super user rechten.
Super user: heeft meer rechten dan gewone user maar minder dan root user.

Root: het uitvoeren met root rechten: let wel: super user commando''s en meer. Theoretisch is een root user dus anders. In de praktijk komt het er op neer dat veel distro''s het bijna hetzelfde hebben afgesteld maar hoeft dus niet! (en ja dat maakt het nogal verwarrend )

Overigens je kan dit allemaal instellen: Wie welke rechten heeft en zelfs voor hoelang of op bepaalde tijdstippen. Dit is veel ingewikkelder, maar ook uitgebreider dan met Windows. (pas wel op dat je jezelf niet buitensluit, dat is mij een keer overkomen haha )

Overigens USB whitelisten is niet echt een optie, dan kun je er nog omheen werken: Ik zou eerder standaard een hash ofzo meegeven en die kijkt of de firmware een werkelijk duplicaat is.

@Sfranken hieronder:

Als dat zo staat in de Man su dan heb je gelijk, maar waarom wissel je van user?: eigenlijk bijna altijd om bepaalde rechten te verkrijgen die je niet had.

En waarom zou je van Kees naar Frank switchen (omdat frank nog altijd 3 rechten meer heeft dan Kees?)

Als Super user heb je zowiezo meer rechten dan Frank. In de p
(staat er in die man su niet toevallig su met de naam van de gebruiker erachter? (bijvoorbeeld su kees) Want normaal su werkt ook niet je moet su - doen eigenlijk bij meeste distro's.

De termen super user en root zijn idd tegenwoordig uitwisselbaar bij veel distro's, maar dat is dus eigenlijk van origine niet de bedoeling geweest!!

P.S.: discussies zijn er om van te leren in mijn ogen niet om te winnen! -->laten we niet te veel offtopic gaan

(moderatie hierin is weer wel grappig --> je reageert op mijn offtopic wordende gedeelte en krijgt +2 en ik krijg zelf 2x over 0 )

[Reactie gewijzigd door rob12424 op 10 augustus 2014 13:53]

Oh?

User: Su commando: het aanroepen en tijdelijk uitvoeren van super user rechten.

su is Switch User, daarmee log je in als een andere user, al kun je het ook gebruiken om "een commmando uit te voeren onder gebruiker X" (bron: man su). Hier haal je su door de war met sudo, wat dat inderdaad doet (tenzij je de timeout aangepast hebt).

Super user: heeft meer rechten dan gewone user maar minder dan root user.

Super user is hetzelfde als de root user, de termen zijn uitwisselbaar

su is Switch User, daarmee log je in als een andere user

Niet helemaal correct.
Het commando 'su -' doet een compleet nieuwe login, met alle bijbehorende scripts etc voor die user.
Het losse commando 'su' verandert alleen het user-id en group-id van de huidige sessie, maar behoudt verder de instellingen van die sessie (dus geen nieuwe login).

Juist. En een gevaar van su (naar root) is dat $PATH nog het pad van de gebruiker is en je root dus een gekraakte ls of ps kan voorschotelen. Met su - kan dat niet omdat $PATH opnieuw gezet wordt.

User: Su - commando: het aanroepen en tijdelijk uitvoeren van super user rechten.

Je kan su ook tijdelijk gebruiken voor een enkel commando bv: su -c 'ls /root' .

Klopt ja, maar waar Alex3 denk ik op doelde was su om over te schakelen naar root (vanwege de vergelijking met sudo).

Dat denk ik ook, maar ik wilde het toch even aanhalen, dan is het voor andere ook duidelijk dat su niet meteen evil omg l33t is zeg maar.

Niet zo'n rare vraag. Als het gaat om domheid van de gebruiker is sudo veiliger: het voorkomt dat je niet onnodig als sudo commando's uitvoert, en als het ware verplicht bent om na te denken wat je uitvoert als welke gebruiker (verwijderen partitie etc)

Veiligheid tegen het kwade van buiten af: ik vraag me af of sudo veiliger is dan su. Zeker omdat sudo niet gebruikt wordt als eigenlijk bedoeld: enkele rechten aan specifieke beheerders geven. Een printer installeren != verwijderen van partitites.

Sudo (ingesteld zoals bij 90% van gebruikers):
alle commandos uitvoeren met het eigen password
Su:
Alle commandos uitvoeren met het root password.

Een tweede password lijkt met dan toch echt veiliger.

Klopt ja, ik hoor een hoop mensen ook altijd zeggen dat je nooit direct als root moet inloggen op bijvoorbeeld een server, en vervolgens dragen ze als alternatief aan om een normale user te maken die met sudo vervolgens alsnog alles kan doen
Dan kan je beter gewoon met su - root worden... of imo gewoon direct als root inloggen als je toch weet dat je als beheerder dingen gaat doen, want bij een compromise van het normale account kan dan niet meteen je root password afgekeken worden terwijl je bezig bent met switchen....
(uiteraard werk je met directe SSH logins gewoon met een keypair, maar dat even terzijde )

Praktisch aan sudo is dat je in de logging kunt zien wie wat gedaan heeft. Als alle beheerders inloggen als root, heeft "root" het altijd gedaan en ben je niet wijzer.

sudo -i, sudo -s, sudo bash, etc.
Geen log meer, en "root" doet alles.

Maar je ziet wel wie zoiets gestart heeft. Je kan ook sudo vim /etc/httpd/httpd.conf doen en escapen naar de shell met :!bash. Wat nog leper is sinds dit makkelijk als noise kan aanzien worden in de sudo logs. Beide kunnen bestreden worden door striktere configuratie van sudo: beperkte Cmd_Aliasen en de noexec/restrict optie.

[Reactie gewijzigd door goarilla op 10 augustus 2014 23:17]

Via deze 'BadUSB'-hack kan een geïnfecteerde usb-stick andere usb-apparatuur die op dezelfde computer is aangesloten infecteren door zich voor te doen als usb-toetsenbord.

Werkt keylogging alleen met USB toetsenborden? Dan is er weer een excuus om de PS/2 ramplank uit het stof te halen of toch maar van een laptop het interne toetsenbord te gebruiken.

Nee, hij logt de keys die je indrukt, en infecteerd andere USB apparaten. Om dit mogelijk te maken moet hij zich als USB toetsenbord voordoen.

Je mag je PS2 toetsenbord wel uit de kast halen, maar je schiet er toch niks mee op.

Wel als je voorkomt dat er een usb-keyboard gebruikt kan worden (module niet in kernel bakken, spelen met xinput).

Dit kan wel interessant zijn, alleen 'jou' type USB keyboard toestaan,

[Reactie gewijzigd door disheaver op 10 augustus 2014 11:42]

Op die manier moet het inderdaad kunnen, maar wie neemt die moeite?

Wel zuur als jouw toetsenbord defect raakt dan, dan kan je niet zomaar een vervanger ergens vandaan toveren

Welke stick is het? Het geheugen wordt door toshiba gemaakt, dat is te zien op de foto. Ik ben blij dat ze de moeite nemen om de serienummers weg te halen, maar het is ze niet overal goed gelukt.

Verder is dit beangstigend dat het allemaal maar zo kan. Je kan dus niet meer een USB van iemand lenen zou je zeggen.

Het probleem zit in de USB chip van elk USB apparaat. Het heeft niks met het geheugen te maken.

Elk USB apparaat heeft een processor(tje) en een beetje geheugen en daarin zit het probleem. Het geheugen kan je herprogrammeren om nare dingen te doen. Dit is dus niet het geheugen van je USB stick, maar van de USB chip zelf. Met een USB printer moet je precies het zelfde kunnen doen, of met een USB bluetooth/wifi dongel die nauwelijks uit je USB slot steekt. En Ik denk dat met SD kaarten hetzelfde speelt, daar zit een vergelijkbare processor in met een beetje eigen geheugen. Al zullen sommige OSsen niet geloven dat je een toetsenbord in een SD slot hebt zitten.

Je bent ook niet beperkt tot keyloggende fake toetsenborden. Je kan ook andere USB apparaten faken, b.v. dat je toetsenbord een muis is. Maar toetsenborden worden door OSsen, BIOSen, etc. blind vertrouwd, vandaar dat ze die faken.

Een oplossing zou zijn om het geheugen van het USB chipje read only te maken. Het lijkt me dat dat moet kunnen zonder de firmware van het apparaat zelf ook read only te maken. Fabrikanten schijnen daar echter weinig zin in te hebben, want dat maakt het moeilijk/onmogelijk om dingen op die USB chipjes te wijzigen aan het eind van het productie proces.

Read only maken of write once? Want read only zorgt ervoor dat er heel veel verschillende chips op de markt komen. Terwijl je hier gewoon 1 kan maken en in de massaproductie kan gooien voor noppes.

Read only voor jou als gebruiker. Ik wilde het niet ingewikkelder maken dan nodig.

Er zijn technisch veel meer opties dan bot read only of write once. En write once is ook niet zo handig voor de fabrikant, dan kun je niks herprogrammeren mocht dat nodig zijn en zal het voorkomen dat je een batch producten weg kan gooien. Als je, b.v. in de verpakkingsmachine, een zekering in de chip door brandt, dan kun je tot je het product verpakt, je product naar hartenlust herprogrammeren en is het daarna read only. Iets wat nu niet met die chipjes kan (of misschien wel en ze zijn een fractie duurder).

Het sudo deel is toch alleen nodig om rechten te krijgen over het hele systeem? Als de mallware op de stick voldoende heeft aan standaard rechten dan ben je nog steeds de klos. Bv mallware die alle files in je homedir en netwerkschijven encrypt, doorstuurt of wist.

Beetje strenge firewall zal het doorsturen blokkeren.
maar de boel encrypten zou kunnen ja. Dat zou rot zijn.

Ik denk dat er weinig werkstations zijn waarbij uitgaand verkeer via standaard protocollen als http(s), ssh en dergelijke geblokkeerd worden.

Klopt, maar het is zeker mogelijk om alle verkeer te blokkeren behalve van whitelisted applicaties.

In feite is de oplossing voor deze specifieke hack vrij simpel :
Tenzij in de config aangegeven, meerdere toetsenborden tegelijk blokkeren op kernel-niveau.

Niet helemaal...
Er wordt ook een exploit genoemd waarbij de USB stick zich als een ethernet-adapter voordoet.
Moet je dan ook meerdere ethernet-adapters blokkeren?
En zo zijn er vast nog wel meer USB-devices te verzinnen waar je hacks mee kunt uitvoeren.
Het blijft symptoombestrijding.

Daarom zei ik ook deze specifieke hack.
Een meer permanente oplossing zou zijn om dat pre-loaden van libs eruit te halen en onderdelen als de wachtwoord prompt sandboxes te maken waar buiten het OS niemand aan kan.

Als programma-makers perse hun eigen versie van de libs willen gebruiken doen ze maar static linken ipv dynamisch

[Reactie gewijzigd door hackerhater op 11 augustus 2014 10:16]

Daarom zei ik ook deze specifieke hack.

Dat is dus mijn punt: de 'hack' is het gebruiken van een USB-stick met aangepaste firmware.
Daar kun je het systeem op meerdere manieren mee hacken. Toetsenbord is slechts 1 van de voorbeelden die genoemd worden in de PDF.

In de gelinkte PDF staat dat de "screensaver" geladen wordt door de LD_PRELOAD environment variable te setten.

Deze environment variable kan gebruikt worden om de linker te forceren bepaalde libraries voorrang te geven op libraries die op standaard locaties staan. Zoals bijvoorbeeld dat je je library met je eigen implementatie van malloc wordt gebruikt i.p.v. de malloc in de C standard library. Het is een handige workaround, maar kan dus makkelijk misbruikt worden.

Als de screensaver en/of policykit gecompileerd zijn met dynamic linking. Dan maken ze gebruik van shared libraries en dan is het inderdaad mogelijk om ze met een password stealer op te roepen. Als die gecompileerd zijn static linking zit al het benodigde van de libraries in de gecompileerde binary zelf.

De *nix-gebruikers (Ja, in *BSD kan LD_PRELOAD ook worden gebruikt) die de moeite hebben genomen om zelf hun screensaver en/of policykit met hun dependencies met static linking te compileren kunnen dus veilig zijn.

Edit: typo

[Reactie gewijzigd door RoestVrijStaal op 10 augustus 2014 15:34]

De *nix-gebruikers (Ja, in *BSD kan LD_PRELOAD ook worden gebruikt) die de moeite hebben genomen om zelf hun screensaver en/of policykit met hun dependencies met static linking te compileren kunnen dus veilig zijn.

Edit: typo

Dat is misschien wel veiliger, maar het neemt gigantisch veel meer schijfruimte in beslag (elke binary moet immers alle functies die ie uit de library importeert, in de binary linken), en als je je dependencies een update geeft gaan er allerlei dingen stuk als geheugenlocaties niet meer op elkaar passen. Voordeel is, naast veiligheid, dat je binaries ook een heel stuk sneller draaien.

Voor een server-side OS waar je misschien alleen van distro-release naar distro-release migreert is dat uit veiligheidsoogpunt nuttig, maar voor een desktop die regelmatig over-the-air updates ontvangt is het heel erg hinderlijk.

Klopt, maar voor belangrijke onderdelen (zoals dus de wachtwoord-prompts) zou het handig zijn.
Voor extra veiligheid.

Is het nodig om je wachtwoord in te voeren voordat dit ding uberhaupt kwaad kan of is dat wachtwoord alleen om andere apparatuur te besmetten?

Dat er een wachtwoord nodig is geeft maar weinig rust, de meeste gebruikers zullen zonder nadenken hun wachtwoord invoeren. Verder komen lokale 'privilege escalations' zo vaak voor dat een serieuse aanvaller ook zonder wachtwoord wel root kan worden.

Ligt eraan hoe je het bekijkt.
De screensaver oproepen, en dan het password sniffen is een manier om volledige toegang tot het systeem te krijgen.
De USB stick kan sowieso als keyboard fungeren, dus ook zonder gebruik van sudo+password zou ie schade aan kunnen richten. Op z'n minst kan de USB stick alles wat je als gewone gebruiker kunt (dus jouw files deleten, spam versturen, etc). En met gebruik van een of andere exploit zou ie ook wel zonder het password root-rechten kunnen krijgen.

Het punt is hier eigenlijk dat er root verkregen wordt zonder dat er een exploit bij komt kijken. De keylogger draait gewoon zonder root-rechten, de screensaver wordt zonder root-rechten opgestart, en het keyboard wordt ook gewoon standaard door het systeem gedetecteerd.
Alles werkt dus 'zoals het moet', en toch is het onveilig.

Het is een bekend verhaal dat als iemand fysieke toegang heeft tot de computer, geen enkele beveiliging meer nuttig is. Dat geldt dus ook voor USB-toegang.

Het is een bekend verhaal dat als iemand fysieke toegang heeft tot de computer, geen enkele beveiliging meer nuttig is. Dat geldt dus ook voor USB-toegang.

Het grappige is natuurlijk dat de persoon die fysiek toegang heeft tot het systeem, nu niet per sé de kwaadwillende aanvaller hoeft te zijn. Een nietsvermoedende gebruiker kan ook een besmette USB-stick in zijn systeem stoppen en zo een aanvaller op afstand toegang geven tot dat systeem.

Dit is wel een grappig voorbeeld waar het gebruik van sudo mogelijk de veiligheid juist verkleint. Zonder sudo zou je gewoon een apart wachtwoord hebben voor root, waarmee een password stealer direct waardeloos wordt.