Onderzoeker onderschept onversleuteld internetverkeer van vergrendelde pc

Beveiligingsonderzoeker Samy Kamkar heeft een tool met de naam 'PoisonTap' ontwikkeld, waarmee hij onversleuteld webverkeer van een vergrendelde computer kan stelen. Dit is mogelijk door een Raspberry Pi die zich voordoet als ethernet-netwerk, aan de pc te hangen.

Op die manier is een aanvaller in staat om bijvoorbeeld authenticatiecookies te stelen, schrijft Kamkar op zijn website. Daarmee kan een kwaadwillende vervolgens inloggen op accounts van het slachtoffer. Kamkar ontwikkelde PoisonTap voor een Raspberry Pi Zero, maar deze werkt ook met een LAN Turtle of USB Armory. De software zorgt ervoor dat het apparaat zich voordoet als een ethernet-netwerk zodra het op een computer wordt aangesloten. Dit werkt ook bij computers die vergrendeld zijn.

Via een dhcp-antwoord laat het apparaat vervolgens aan de computer weten dat de gehele ipv4-ruimte deel uitmaakt van zijn netwerk. Daardoor verkrijgt het kwaadaardige netwerk prioriteit boven andere netwerkverbindingen. Zolang er op de vergrendelde computer een webbrowser draait met een geopend venster dat een http-verzoek verstuurt, kan het PoisonTap-apparaat het verzoek omleiden naar zijn eigen node.js-webserver. Door gebruik te maken van verborgen iframes maakt PoisonTap verbinding met de miljoen populairste pagina's uit de Alexa-lijst.

Daarbij kan de kwaadaardige webserver zelf kiezen welke headers hij meestuurt, aldus Kamkar. Het apparaat is in staat om zo alle cookies te stelen die over een http-verbinding verstuurd worden. Het is ook mogelijk om cookies bij een https-verbinding te onderscheppen, zolang deze geen veilige flag gebruiken. Daar komt bij dat de iframes fungeren als html- en javascript-backdoors die zonder tijdlimiet in de cache worden opgeslagen. Daardoor blijven deze in het geheugen, ook al wordt het PoisonTap-apparaat losgekoppeld.

Doordat hiermee een WebSocket wordt aangemaakt, kan de aanvaller op een later tijdstip opnieuw met de computer van het slachtoffer verbinding maken en andere aanvallen uitvoeren. Door de backdoors is het eveneens mogelijk om op afstand toegang tot de router van het slachtoffer te verkrijgen. Op die manier is het mogelijk om bij de beheerdersinstellingen te komen, bijvoorbeeld doordat het slachtoffer gebruikmaakt van standaardlogins.

Het staat voorop dat een aanvaller fysieke toegang tot een computer moet hebben om deze aanval uit te voeren. Kamkar meldt dat het mogelijk is om zich tegen deze aanval te beschermen door alleen versleutelde https-verbindingen te gebruiken in combinatie met veilige cookies. Het telkens afsluiten van de browser bij het verlaten van de computer en het uitschakelen van usb- en thunderbolt-poorten behoort ook tot de mogelijkheden.

In een vergelijkbare aanval demonstreerde beveiligingsonderzoeker Rob Fuller onlangs hoe hij met een usb-ethernetadapter de inloggegevens van een vergrendelde Mac of Windows-computer kon stelen. Kamkar ontwikkelde eerder andere aanvallen, waaronder een apparaat dat toetsaanslagen afluistert en kinderspeelgoed waarmee hij garagedeuren kon openen.

Demonstratie van de aanval

Reacties (81)

[MadEgg]

Mja, dit is dus HTTP verkeer onderscheppen. We wisten al lang dat dat niet al te complex was. Op zich een redelijke aanval, maar je komt verder door HTTP-verkeer te onderscheppen op onbeveiligde WiFi-netwerken. Gelukkig gaan steeds meer sites over naar HTTPS, tegenwoordig zelfs Tweakers al

Met fysieke toegang kun je veel meer nare dingen doen. Je zou in diezelfde USB-poort ook een keylogger kunnen steken, om maar eens wat te noemen. Kun je ook wachtwoorden en creditcard-gegevens mee onderscheppen.

Geen HTTP gebruiken, is de boodschap. Dat was gelukkig al bekend.

[tweaknico]

https-everywhere is een zeer bruikbare plugin. NU nog alle servers op https....
(LetsEncrypt ...)

[Reactie gewijzigd door tweaknico op 23 juli 2024 18:28]

[Hieronymuski]

LetsEncrypt is leuk, maar die verifieerd de aanvrager van het certificaat ook niet.
Ja, je verkeer is versleuteld maar 100% garantie dat je alsnog met de juiste server verbindt heb je niet.

[MadEgg]

Die validatie slaat bij nagenoeg geen enkele CA ergens op. Ze controleren of je zeggenschap over het domein hebt, eenmalig. Tenzij je bakken met geld uitgeeft aan EV. Voornamelijk om de CA's te spekken. Daarmee is het hele HTTPS certificaat-gebeuren wat mij betreft ook redelijk een wassen neus.

De boel zou zo snel mogelijk overmoeten op DANE, in combinatie met DNSSEC is dat zo veilig als je het krijgen kunt, en dan zonder de lachende derde, de CA's die er een lieve duit aan verdienen.

[tweaknico]

DANE zegt meer over zeggenschap over de DNS server waar je namen geserveerd worden.
HTTPS zegt nog iets over de server en de ondertekenaar van een certificaat.

Let ook eens op "standaard certificaten...." De staat de nerderlanden CA certificaten staan Code ondertekening toe, dwz. dat door De staat der Nederlanden vertrouwde executables blind vertrouwd worden...
En dat terwijl terug hacken nu juridisch acceptabel verklaard wordt door 2e kamer?

Feitelijk is "Terughacken" icm "Vertrouwd certificaat" speelgoed van een kind jatten niveau..., maar ja beter kan in Den Haag blijkbaar niet verzonnen worden.

[MadEgg]

Ja, maar daar gaat het toch om? Een Let's Encrypt certificaat, en eigenlijk alle DV certificaten, zeggen alleen maar dat Comodo, Let's Encrypt of weet ik wat voor partij verklaart dat ze gecontroleerd hebben dat de webserver in je beheer is.

Hoe toon je dat aan? Door een mailtje van ze te ontvangen op een e-mailadres van dat domein, doorgaans. Hoe zorg je dat je die mails krijgt? Juist, door de MX records van die domeinnaam in DNS juist in te stellen. DV valt of staat dus ook met het beheer van de DNS records. DANE net zo goed, maar haalt daar een schakel tussenuit, de CA, en bovendien werkt DANE continue; als ik morgen mijn domein overdraag aan jou kan jij daar direct je nieuwe keys opzetten en zal mijn certificaat niet meer vertrouwd worden omdat die niet matcht met DNS. Terwijl als ik nu een CA-signed certificaat heb, wordt die vertrouwd tot het einde van de looptijd van dat certificaat. Tenzij die met halfbakken pleistersystemen als CRLs of OCSP ingetrokken wordt, wat ook onbetrouwbaar is, en bijvoorbeeld bij gratis certificaten van StartSSL zelfs geld kost. Ellende op ellende op ellende dus.

DANE lost dit allemaal in een soepele elegante manier op. DNS moet je toch al hebben, middels DNSSEC wordt de integriteit van de DNS records bewezen en daarmee wordt de identiteit van de webserver waar diezelfde DNS records naar wijzen ook weer controleerbaar. Geen speld tussen te krijgen.

Let ook eens op "standaard certificaten...." De staat de nerderlanden CA certificaten staan Code ondertekening toe, dwz. dat door De staat der Nederlanden vertrouwde executables blind vertrouwd worden...
En dat terwijl terug hacken nu juridisch acceptabel verklaard wordt door 2e kamer?

Ik weet niet wat je hiermee bedoeld in reactie op mijn bericht. Ik vind het CA-systeem een brak systeem, JUIST om die reden. De Nederlandse staat kan om het even welke website vervalsen omdat ze zelf certificaten kunnen uitgeven die door elke browser vertrouwt zullen worden. Doffe ellende.

[Reactie gewijzigd door MadEgg op 23 juli 2024 18:28]

[tweaknico]

Nee meestal niet alleen door een mailtje, maar een mailtje voor de DNS check + een bestandje op de root van een Webservice. of een Cookie etc.
Dus ook een Webserver maakt deel uit van de check.

Certificaten die eigendom van een SITE waarborgen hebben niets van doen met certificaten die bron van een executable waarborgen.
(Waarbij een OS wel code van vertrouwde bron certificaten start maar niet code die van elders komt...)

Met de opmerkingen over de Staat Der Nederlanden-CA certificaten geef ik alleen een onderbouwing voor je claim van het falen van certificaten in een zeker opzicht.
Dus de vraag is waarom zou "de staat der nederlanden" CA certificaten hebben die ook "Deze code is betrouwbaar" aangeven, en waarom is dat hetzelde CA certificaat voor WWW access.
Volgens mij staat in het mandaad van de overheid helemaal niet dat ze mij van software moeten voorzien.., of het moet zijn in het kader van "terughacken".. maar ook dat kan ik missen :-)

Overigens bij mij zijn de Staat der Nederlanden certificaten overal gewist. Juist om die reden.

[Reactie gewijzigd door tweaknico op 23 juli 2024 18:28]

[MadEgg]

Dat heb ik bij StartSSL nog nooit hoeven te doen. Ik geef een domeinnaam op, selecteer een van de in de WHOIS-database geregistreerde e-mailadressen om een verificatiecode op te ontvangen en wacht op dat mailtje. Die code plak in vervolgens weer in en daarna kan ik certificaten voor dat domein en subdomeinen aanmaken.

Ook voor mijn Comodo-certificaten heb ik nog nooit een bestand op een webserver hoeven te plaatsen. Dat hoefde eigenlijk alleen voor de verificatie van een website in Google Tools for Webmasters, nooit voor certificaten. Misschien dat sommige andere certificaat-boeren dat wel doen, maar het is geen vereiste. Als je dus geen toegang hebt tot de webserver maar wel de DNS kun je simpelweg een andere certificaatboer uitkiezen als je huidige wel een bestand op de server vereist.

[tweaknico]

YMMV... Inderdaad andere certificaat boeren.

STARTSSL staat bij mijn weten nu op een zwarte lijst.
START.COM in ieder geval wel

[MadEgg]

Klopt, maar dat gaat alleen om nieuw uitgegeven certificaten (vanaf 1 oktober 2016 dacht ik). Ik heb er nog meerdere die het gewoon nog goed doen.

Let's Encrypt doet het ook:

For example, the CA might give the agent a choice of either:

Provisioning a DNS record under example.com, or
Provisioning an HTTP resource under a well-known URI on https://example.com/

Daar kan de automatische client dus kiezen. Overigens is het natuurlijk sowieso een loos verschil; als je DNS controleert kun je de A-records ook aanpassen om naar een willekeurige webserver te wijzen waar je netjes de gevraagde documenten opzet. Het valt of staat dus allemaal bij de controle over de DNS-records; heb je die dan kun je op elke manier valideren die voor DV nodig is. Op zich ook logisch, wat een domeinnaam is niet meer dan dat: een setje records in een DNS-server.

[tweaknico]

Natuurlijk ook DNS, maar ook de server zelf.
Overigens wie controleert de .nl sleutel?
of de .org / .net etc? want je bent afhankelijk van de data over die sleutels in de root servers, voor verwijzing naar de juiste servers....
Dus dan komt het neer op wie is de beheerder/eigenaar van de root servers.....

[MadEgg]

De DNS-server natuurlijk. DNSSEC is een recursief proces tot aan de rootservers. Wie die beheert kan de boel flessen, dat is zeker waar. Maar dan moet die wel de hele chain van DNS-servers beheren, en dat is ook lastig aangezien DNS hierarchisch van aard is, je zult waarschijnlijk bij het opzoeken van een domeinnaam te maken krijgen met ofwel een gecachte response, ofwel met meerdere DNS-servers. Alleen de root-servers hacken helpt niet want dan komende de responses van de lagere servers niet overheen. Dat zul je dus allemaal over moeten nemen. En door de cache krijg je dan een vlaag van allerhande obscure foutmeldingen over het land. Zie ook mijn reactie hieronder: MadEgg in 'nieuws: Onderzoeker onderschept onversleuteld internetverkeer van ...

[Verwijderd]

Laten ze eerst DNSSEC keys signen met een 2048 bit root. En de ondersteuning voor DANE is nog zo mager, duurt nog jaren voordat dat voet aan de grond krijgt. Tegen die tijd is er al weer iets anders bedacht. DV is mijns inziens dood sinds de komst van gratis ssl en OV is altijd al zinloos geweest maar EV is zeker nog betrouwbaar en het geld waard.

[Blokker_1999]

Zolang je het over domain validated certificaten heb, bewijs je nooit wie je bent, alleen maar dat je toegang hebt tot het domein. Met DANE doe je eigenlijk net hetzelfde, ook daar bewijs je niet wie je bent, maar alleen dat je toegang hebt tot de DNS servers van het betreffende domein.

HTTPS heeft als primair doel de verbinding tussen server en client verifiëren. Wie er eigenaar is van de server maakt voor dat protocol niet uit. EV certificaten op domeinen zijn dan ook onzinnig. Ze zijn wel handig voor andere doelen waar je net wel de identiteit van de eigenaar wenst vast te stellen zoals bij Code Signing of het plaatsen van een digitale handtekening op een document of e-mail.

[latka]

Voor deze hack niet relevant dus goed genoeg. Niet 100% maar dat krijg je nooit voor elkaar in securityland.

[Blokker_1999]

Maar daar is SSL ook niet noodzakelijk voor bedoeld. In de eerste plaats dient een HTTPS verbinding om aan te geven dat de communicatie tussen server en client beveiligd is om elke vorm van man-in-the-middle onmogelijk te maken. Een domain validated certificaat is niet bedoeld om de identiteit van de eigenaar na te gaan. En voor mij hoeft dat ook niet.

Want zelfs met DV certificaten is vandaag al fraude mogelijk. De private key kan gestolen worden of erger nog: de keys van een vertrouwde SSL ondertekenaar kunnen gestolen worden (zijn we bijv. Diginotar alweer vergeten?). Kan je ooit 100% garanderen dat je met de juiste tegenpartij spreekt? Neen dat kan je niet.

En laat ons nu even stellen dat het wel zo is. Ben jij zeker dat je PC virus vrij is of niet gehacked is? Kan je hetzelfde zeggen van de tegenpartij? Ook dat kan je niet.

SSL is leuk, maar je moet altijd voor ogen houden welk probleem men er mee wenst op te lossen, en in het geval van HTTPS is dat zeker NIET het vaststellen van de identificatie van de tegenpartij.

[servicedb]

Ik denk dat je Let's encrypt niet helemaal begrijpt en SSL certificaten ook niet helemaal. SSL certificaten hebben als doel de verbinding te versleutelen tussen de server en de client. Hierbij kan je een zelf gemaakt certificaat gebruiken wat een foutmelding zal geven of een geldig certificaat van bijvoorbeeld Let's Encrypt, Comodo of Geotrust. Met een EV (groene balk) certificaat kan je nog wel adres gegevens er in plaatsen, daarom hebben banken dit ook. Daarbij is de verificatie van de EV certificaat vaak uitvoeriger dan een niet EV certificaat.

Let's encrypt voert wel verificatie uit of de server bij de domeinnaam van de aanvrager hoort. Komt een certificaat op een andere server terecht, dan heeft de aanvrager deze zelf op een andere server geplaatst of er is iets geks gebeurd (bijv een hack of gestolen).

Je kan er van uit gaan dat een Let's encrypt certificaat voor een veilige verbinding staat wat net zo veilig is als andere certificaten. Andere certificaten kunnen immers ook op meerdere servers geïnstalleerd worden of gestolen worden.

[tweaknico]

LetsEncrypt doet alleen een uitspraak over de aanvrager van het certificaat....
Die aanvrager is NIET de persoon achter een site, maar de SITE zelf.
En dat is aantoonbaar door het aanroepen van een bepaalde query op die site.

Het zegt dus de URL: met http://sitex/xxx is aantoonbaar van site 'sitex'
niet meer en niet minder. Overigens doen andere certificaten niets meer of minder.
En claimen dat ook niet..... De te kort door de bocht uitleg lijkt vaak meer gewicht aan een certificaat te geven.
Een certificaat verteld helemaal niet over de history van de eigenaar van de site-naam, oid, doet geen antecedenten onderzoek.. zegt ook niets over de kennis ver betrokken personen.

Als je de Subject en Chain van een certificaat vergelijkt dan moet het pad kloppen...
En ook zou een leverancier moeten vertellen waar z'n certificaten vandaan komen.
ie. Ergens moet op een goede eenduidige wijze te vinden zijn Wie de certificaat uitgever is van een bepaalde organisatie. bv. xxxxx.com = GoDaddy
dan zijn alle certificaten voor xxxxx.com die niet afkomstig zijn van GoDaddy verdacht... en fout hoe vertrouwd ze ook mogen zijn.

Dat is waarom START.COM (en co) nu in de ban is gedaan, er zijn aantoonbaar certificaten uitgegeven die niet uitgegeven hadden mogen worden. Dus nu zijn ze niet meer vertrouwd, er is nog een behoorlijke tijd voor uitleg geweest wat mij betreft had de stekker er eerder uit gemogen.

En de NL Faal Diginotar...., dat die certificaten een week na dato nog vertrouwd moesten worden was echt mis.

En een groen slotje is niets meer of minder dan er is encryptie toegepast. En zegt ook helemaal niets over welke encryptie, (DES of AES..., en er is een verschil tussen die twee ;-), en of PFS van toepassing is of niet.

[Aaargh!]

Mja, dit is dus HTTP verkeer onderscheppen

Inderdaad. Hier wordt iets 'gekraakt' wat helemaal niet beveiligd is. Dat het via een wat omslachtige manier gaat doet er niet zo heel veel toe. Dit valt een beetje in de categorie 'no shit, sherlock'.

[OddesE]

HTTP verkeer onderscheppen is inderdaad niet zo ingewikkeld. Zeker niet als je al fysieke toegang hebt tot het apparaat. De meeste software (e.g. Linux, Windows) neemt het standpunt in dat fysieke toegang = all bets are off.

Verder wat aanvullingen bij het bericht:

Op die manier is een aanvaller in staat om bijvoorbeeld authenticatiecookies te stelen

authentication cookies zouden alleen gezet moeten worden na inloggen, dus dan ben je dus ingelogd op een http site. Kan (Tweakers deed dat ook) maar is niet zo interessant omdat belangrijke diensten toch wel allemaal op HTTPS zitten en ook de minder kritieke diensten en masse over aan het gaan zijn.

Door gebruik te maken van verborgen iframes maakt PoisonTap verbinding met de miljoen populairste pagina's uit de Alexa-lijst.

Ik neem aan dat dit iframe wordt geinjecteerd op een pagina... een die de gebruiker toevallig net bezocht heeft... Ik vermoed dat dit werkt door de response te onderscheppen en er een iframe aan toe te voegen voordat hij naar de browser wordt doorgegeven.

Daarbij kan de kwaadaardige webserver zelf kiezen welke headers hij meestuurt, aldus Kamkar.

Tja ook goedaardige kunnen dat. Net zoals ze zelf kunnen kiezen welke query parameters ze in de URL toevoegen... Dit is een beetje stoere praat met terminologie volgens mij.

Het apparaat is in staat om zo alle cookies te stelen die over een http-verbinding verstuurd worden.

...en alle headers... en alle content... dit is een beetje een open deur natuurlijk. Als je er tussen zit kun je gewoon alle http verkeer onderscheppen... cookies horen daar ook bij dus waarom ze apart noemen?

Het is ook mogelijk om cookies bij een https-verbinding te onderscheppen, zolang deze geen veilige flag gebruiken.

En ook hier geldt: session cookies horen met de httpOnly flag gezet te worden. Als websites zich daar niet aan houden dan levert dat 'gevaar' op voor de accounts op die sites. Maar dat zal niet de bank zijn.

Daar komt bij dat de iframes fungeren als html- en javascript-backdoors die zonder tijdlimiet in de cache worden opgeslagen. Daardoor blijven deze in het geheugen

Dit is echt onzin. De browser cache staat passief op disk, niet in het geheugen.

Wat hier denk ik bedoeld wordt is dat als de pagina later opnieuw wordt opgevraagd dat de browser dan de pagina uit de cache gebruikt, waardoor de iframes weer geladen worden en de backdoor weer actief wordt.

Doordat hiermee een WebSocket wordt aangemaakt, kan de aanvaller op een later tijdstip opnieuw met de computer van het slachtoffer verbinding maken en andere aanvallen uitvoeren.

WebSockets worden opgeruimd zodra de webpagina gesloten wordt... dus ik neem dan aan dat die pagina open moet blijven staan.

Als ik het dus goed lees dan kan hij terwijl het apparaat aangesloten is en er tegelijkertijd een pagina ingeladen wordt, een 'backdoor' in die pagina meesmokkelen, die dan gedurende de tijd dat de browser de cache als geldig beschouwt in de pagina blijft zitten en elke keer dat die pagina weer geopend wordt weer opnieuw actief wordt.

Dat is best impressive.

Maar je moet dus wel actief surfen op de PC om het te activeren en de eerste keer moet dat terwijl het apparaat ingeplugged is.

[Verwijderd]

HTTPS is (helaas) ook niet foolproof, je kunt je vast nog wel de problemen met certificaat autoriteiten van een paar maanden/jaar geleden herinneren?

Daarmee kan 'een hacker' dan gewoon HTTPS verkeer ontsleutelen, hij heeft immers de sleutels, en we weten niet of er nog meer van dat soort bedrijven 'over genomen' zijn zonder dat ze het zelf beseffen.

[MadEgg]

De sleutels worden niet gecompromitteerd als de CA faalt. Wat er wél gebeurt is dat het certificaat van de server vervalst kan worden. Je moet dan niet alleen het verkeer door je RPi laten lopen maar ook nog daadwerkelijk als webserver optreden en daarbij ook nog de juiste certificaten voor de juiste domeinnaam vervalsen, middels een vervalste CA. En daarbij er ook nog vanuit gaan dat er momenteel de signing key van een vertrouwde CA is uitgelekt waarvan het vertrouwen nog niet in ingetrokken, want dan vertrouwt de clientbrowser je certificaat alsnog niet natuurlijk. Dat is wel een extreem ongelukkige samenloop van omstandigheden; dat is een veel realistischer scenario in de context van phishing waarbij je veel mensen via internet naar je vervalste domein lokt.

HTTPS zelf faalt niet in die context, het is het halfbakken systeem van CA's dat dan faalt. Het is gewoon onverstandig om te vertrouwen op de integriteit van een derde partij, en het is ook onverstandig om te vertrouwen op die lijst 'vertrouwde CAs' die standaard met je browser of OS mee komen.

[OddesE]

Het is gewoon onverstandig om te vertrouwen op de integriteit van een derde partij

Tja maar wat is het alternatief?

Bijvoorbeeld in het (fiscaal) recht wordt regelmatig vertrouwd op een derde partij. Denk aan notaris of accountant. Of in grote zakelijke transacties wordt er een derde partij tussen gezet (clearing house) die de fondsen pas vrijgeeft nadat van twee kanten bevestigd is dat alles klopt.

Het grote probleem is, als jij naar https://mijnsite.nl gaat, hoe weet je dan dat je naar de *echte* mijnsite.nl gaat en niet naar een nepperd? Doordat de site waar je op zit zegt 'ik ben het, echt waar!'?? Wat het CA systeem doet is als het ware borg staan voor de site die je bezoekt: de eigenaar van het certificaat heeft de derde partij laten valideren dat hij inderdaad de beheerder van dat domein is... Wat is daarvoor het alternatief?

Je kunt natuurlijk zeggen: DNSSec... maar hoe weet ik dat ik wel verbonden ben met de *echte* DNS servers? Dit blijft toch een kip/ei probleem?

[MadEgg]

Je kunt natuurlijk zeggen: DNSSec... maar hoe weet ik dat ik wel verbonden ben met de *echte* DNS servers? Dit blijft toch een kip/ei probleem?

Via DNSSEC kan je elke DNS-server valideren, tot aan de root. De sleutels van de root-servers dienen in je OS opgenomen te zijn, en een verschil daarin valt dus door de mand. Nu kun je in principe stellen dat daarmee het systeem staat of valt bij die certificaten, en als je die weet te spoofen, het hele systeem onderuit gaat.

Echter, door de gedistribueerde opstelling van DNS is het wel veel minder foutgevoelig. Als de overheid der Nederlanden google.com wil spoofen zorgen ze voor een herroutering om AMS-IX oid en geven ze een valide certificaat uit middels hun eigen CA. Done.

Via DNSSEC / DANE moet je dan:
* Google's IP-adressen omleiden naar hun eigen server
* de DNSSEC-records spoofen middels een bij hun onbekende key (want die is bij Google)
* daarom: de DNSSEC-records van het .com domein spoofen omdat ze anders door de mand vallen met google.com
* daarom: de DNSSEC-records van de root servers spoofen om dat ze anders door de mand vallen met .com
* daarom: IANA omkopen ofwel je PC infecteren met foutieve root server records.
* een certificaat uitgeven middels hun gespoofde DNSSEC records en die op hun server installeren

En dan nog is het niet feilloos - ik gebruik bijvoorbeeld mijn eigen DNS-server die rechtstreeks met de root servers communiceert, en daarbij ook vastgekoppeld is aan juiste signatures. Mijn DNS-server zal dus direct alarm slaan als de NL Overheid zo'n tructje probeert uit te halen. Daarnaast cachen alle DNS-servers requests wat dus een gevolg van alarmen tot gevolg zal hebben tijdens het overgaan op de foutieve records.

Het is niet onfeilbaar maar wel zo veel veiliger en zo veel lastiger om te omzeilen dat het praktisch gewoon niet haalbaar meer is.

[OddesE]

De sleutels van de root-servers dienen in je OS opgenomen te zijn

En wie vertrouw je dan? Juist, een third party.

Don't get me wrong, DNSsec is wel beter, maar de stelling dat je nooit op een third party moet vertrouwen is niet vol te houden want uiteindelijk kun je niet anders; of je vertrouwt dat de partij waarmee je praat inderdaad is wie hij zegt dat hij is, of je vertrouwt op het oordeel van een derde partij.

[MadEgg]

Dat is toch exact wat ik zeg in de zin twee zinnen na de zin die je quote?

Nu kun je in principe stellen dat daarmee het systeem staat of valt bij die certificaten, en als je die weet te spoofen, het hele systeem onderuit gaat.

Het kán maar is dermate onwaarschijnlijk en bewerkelijk dat het in de praktijk niet haalbaar is. Zoals ik al als voorbeeld geeft zal misschien mijn laptop gespoofd kunnen worden, maar aangezien die voor zijn DNS vertrouwt op mijn eigen DNS server elders, zal die ook gehackt en bijgewerkt moeten zijn voordat dat gaat werken. Daarnaast wordt de boel gecached door elke DNS server waardoor het een vlaag van fouten gaat opleveren.

Er zijn zeker wel aanvalsvectoren, ook met DNSSEC / DANE, maar het is enorm veel lastiger.

[Frankyy]

Oftewel, Man in the Middle?

[Paul C]

Nee, niet echt. Hij emuleert een USB netwerk controller en forceert al het verkeer naar die USB controller door een extreem ruime Netmask terug te geven via DHCP. Hierdoor gaan alle HTTP-requests naar de USB netwerk controller en niet meer naar de bestaande netwerkverbinding (door het Netmask denkt de aangevallen computer dat hij via die route nu alles direct kan bereiken ipv helemaal via het internet). Die USB Controller heeft helemaal geen internet, maar geeft gewoon bij iedere web-request een Javascript terug. De browser weet niet beter dan dat dit Javascript is van de website waar hij zojuist iets heeft opgevraagd en omdat de meeste mensen wel een paar websites open hebben staan die zo nu en dan op de achtergrond een request sturen om te kijken of er nog nieuwtjes zijn, kun je wachten tot de gelockte PC het Javascriptje download. Het is dus geen MITM omdat hij helemaal niet in het midden zit, maar de PC voor de gek houdt dat er daar heel veel internet is waardoor hij alle requests ontvangt.

Vervolgens wordt dit Javascript gerunt door de browser (in de veronderstelling dat deze van de legitieme server komt). Dat Javascript opent allemaal Iframes die top 1.000.000 grootste websites op het internet opent om te kijken of de browser daar Cookies voor heeft opgeslagen. Zo ja, dan stuurt hij deze door naar een server op het internet van de aanvaller.

Tevens wordt het script opgeslagen in de Cache van de browser met de opmerking dat dit script altijd goed blijft en noooit opnieuw geladen hoeft te worden. Als de aanvaller dus 1 van de Top 1.000.000 websites op het internet opent in de toekomst, dan heeft de aanvaller weer toegang, omdat het script op de achtergrond een verbinding met een server van de aanvaller maakt.

[Reactie gewijzigd door Paul C op 23 juli 2024 18:28]

[iTeV]

Een gerelateerde talk op DEF CON

[Reactie gewijzigd door iTeV op 23 juli 2024 18:28]

[Armin]

Ja, dat was mijn eerste gedachte. Dit is niet nieuw, maar een reeds bekend én reeds deels gepatchde aanval.

Het is dus een klassieke MITM (dat je niks doorgeeft maakt het nog steeds een MITM) aanval, waar HTTPS je tegen beschermt. Het unieke hiervan was dat Windows automatisch de USB netwerk adapter als prioriteit installerde en je dan ook Windows authenicatie tokens kon vangen.

Dat laatste lek is echter recent gedicht, en zoals ik begrepen had wordt de USB netwerk adapter ook niet langer als default ingesteld. Echter als dat waar is, zou deze aanval geheel niet meer mogelijk zijn, dus daar moeten ik even achteraan gaan.

UPDATE: Ik heb de fix gevonden: CVE-2016-3302. Echter als je kijkt naar de fix, zie je dat die niet overeenstemt met de CVE kwestie. Men lijkt een subset gefixt te hebben (loads van het Lock Screen) - en daarmee zoals ik aangaf authenticatie tokens, doch niet de USB kwestie. De Rob Fuller aanval is dus hoe dan ook afgeslagen op Windows.

Uiteraard is de aanval daarmee niet zo erg meer als het was. Immers enkel niet-versleutelde content en niet-versleutelde cookies kunnen onderschept worden. (OK technisch gezien de rest ook, maar is dus versleuteld.)

Alleen wel vreemd dat Microsoft nog steeds een USB netwerk adapter die ingestoken wordt, automatisch default maakt. Daarmee zou deze PoisonTap wel nog mogelijk zijn.

Het antwoord ligt wellicht in het feit dat Microsoft dat inderdaad niet meer doet, maar de onderzoeker in Sillicon Valley woont, en we even Sillicon Valley speak moeten vertalen naar meer generiek Tweakers taal. En wel

Sillicon Valley - Rest van de wereld:
computer = Mac
windows computer = computer

Zijn aanval zoals hier beschreven werkt enkel op Mac's!

[Reactie gewijzigd door Armin op 23 juli 2024 18:28]

[84hannes]

Dus er gebeurt niets dat je niet zou kunnen bereiken als man-in-the-middle met wat meer geduld? Nu worden er naar jou zeggen 1.000.000 websites achter elkaar (of tegelijkertijd) bezocht, maar de websites waar iemand ingelogd is zal hij of zij binnen een paar weken toch wel bezoeken. En volgens mij waren we het allemaal al met elkaar eens dat een man-in-the-middle-aanval niet denkbeeldig is, dus ik zie hier geen nieuwe bedreigingen (het kan hiermee alleen iets sneller).

[OddesE]

Sterker nog dit is veel minder een bedreiging, want in tegenstelling tot de klassieke MitM is hiervoor fysieke access vereist.

[PuzzleSolver]

Mooie correcte uitleg (beter dan het artikel), maar hij zit tussen de browser en de server en dat maakt het en Man in the middle attack.

Alles wat er verder gedaan wordt kan ook met een man in the middle attack, b.v. door ergens anders in het netwerk verkeer om te leiden (Vervang de router in de meterkast of hack de router of doe je voor als router op het netwerk en hoop dat je eerst gekozen wordt etc etc).

Overigens had ik al eerder berichten gehoord dat dit met hergeprogrammeerde usb sticks kan

https://www.hackread.com/...eal-login-data-locked-pc/

[Frankyy]

Bedankt voor de toelichting!

[bArAbAtsbB]

Fysieke toegang nodig tot het systeem.....dan is er zo goed als geen risico voor consumenten!?

[magnifor]

Maar wellicht wel een risico op de werkvloer. Daar heeft meestal iedereen fysieke toegang tot de workstations en is het makkelijk om tijdens iemands pauze een raspberry PI aan te sluiten onder het mom van het maken van Backups (vooral als je van IT bent). De normale user zal dat slikken als zoete koek en inmiddels heb jij al haar/zijn cookies onderschept.

[Reactie gewijzigd door magnifor op 23 juli 2024 18:28]

[Armin]

De normale user zal dat slikken als zoete koek en inmiddels heb jij al haar/zijn cookies onderschept.

Maar die cookies zijn doorgaans encrypted. Deze truc werkt alleen:

- op een Mac (Ja dat is niet duidelijk uit het verhaal, want de onderzoeker spreekt over 'computer'. Echter zijn hele demo is op een Mac. Enkel minder dramatische varianten zijn mogelijk op Windows aangezien daar in september een fix is uitgekomen voor expliciet onderdelen van deze aanval.)
- als de website geen HTTPS gebruikt
- als de cookies niet versleuteld zijn

[OddesE]

Punt is dat je ook zijn hdd kan kopieren (of zelfs gewoon de hele laptop meejatten) als je fysieke toegang hebt.

Fysieke toegang = controle over het systeem. Punt. Er is vrijwel niemand die gaat proberen om (via software) te beveiligen tegen fysieke toegang. Daar zijn kluizen en gewapende deuren en tralies en zo voor bedacht.

[DukeBox]

Ja en nee, op zich zou je de software ook op een gehackte consumenten router kunnen zetten en op een zelfde manier te werk gaan.

[bArAbAtsbB]

en dan nog heb je toegang nodig tot de router! toch!?

[DukeBox]

Ja, maar daarvoor heb je dus geen fysieke toegang nodig.

[GrooV]

Nee hoor, er zijn ook zat remote exploits voor routers. Helemaal als je control panel of telnet/ssh ook benaderbaar is vanaf het internet.

Verder kan je natuurlijk ook denken aan studenten of flex werkplekken die hier kwetsbaar voor kunnen zijn

edit: was een reactie op barabatsdb

[Reactie gewijzigd door GrooV op 23 juli 2024 18:28]

[OddesE]

En als je een remote exploit voor Windows hebt kun je wellicht ook zonder die Raspberry Pi dezelfde trucjes uithalen.

Een exploit heeft als doel macht/controle over een systeem te krijgen. Als je al fysieke toegang hebt, dan heb je die macht feitelijk al. Dus een exploit die een andere exploit of fysieke toegang vereist is in feite geen exploit... maar een app.

Knapste stukje werk hier is wat mij betreft de backdoor via iframes... alleen omdat die binnen de browser sandbox draait kan die niet zo veel kwaad. Hoogstens wat tracking cookies jatten, want de belangrijke cookies zijn gewoon beschermd.

[Quilt]

Denk dat het risico fel toe gaat nemen door opladen via USB Type-C aansluitingen.
Denk aan laadpalen in luchthavens en zo...

[OddesE]

Wacht even.

Stap 1: Inbreken bij de luchthaven (zorgen dat die anti terreur mannen met hun machinegeweren je niet snappen)
Stap 2: Hacken van de oplaadpaal
Stap 3: Geduldig wachten tot het slachtoffer (die werknemer van de concurrent met de nieuwste ontwerpen op zijn laptop) zijn laptop precies in de door jou gehackte laadpaal inplugged (of, alle laadpalen hacken...)
Stap 4: Zijn cookies jatten. Niet die van zijn bank, zijn Facebook/Twitter/Gmail, of zelfs niet zijn tweakers.net cookie, want die zitten allemaal veilig achter https/httpOnly flag, maar *een* cookie. Any cookie!!
Stap 5: Ok mannen we zijn binnen. We kunnen nu inloggen met de RedTube account van werknemer X... Ehm... wat nu??

Oftewel een nogal overkill 'mission impossible' scenario om een paar lullige cookies te jatten... niet echt realistisch denk ik zo.

[Quilt]

Elke luchthavenuitbater laat je een laadpaal plaatsen als je huurgeld betaalt.

[OddesE]

Tja en dan laatje een 'paper trail' achter... Anyway het lijkt mij gewoon een onrealistisch scenario buiten Hollywood.

[Qwerty-273]

mwa, niet bepaald. Hoeveel mensen sluiten hun computer / laptop daadwerkelijk af? Meestal staan deze in een slaapstand met apps open. Denk aan een schoonmaakster die over de vloer komt, even uit slaapstand halen (login niet nodig) en je usb device er in, en gaan met die banaan. Of tijdens een verjaardagsfeestje of andere drukte in je huis.. Loodgieter die wat komt doen, en jij even naar de wc gaat. Het is inderdaad niet iets dat je op afstand doet, maar als "consument" gelijk 100% veilig zijn is het niet.

[Verwijderd]

Denk dat er nog genoeg mensen in een type social engineering zou trappen. "Hoi mevrouw ik ben van de woningbouw/KPN en kom de telefoon/internetaansluitingen controleren, zou ik even 5 min mogen kijken?"

[sjettepetJR.]

Maar dit is geen probleem exclusief aan computers. Inbreken door middel van social engineering is een ander probleem.

[Verwijderd]

Natuurlijk wel. Wat je nu zegt is gelijk aan zeggen dat een kluis niet goed hoeft te werken, want het probleem is niet de kluis, maar dat een vreemdeling überhaupt fysiek toegang tot die kluis had.

Normaal als je PC/laptop locked staat en encrypted is, zou het vergaren van informatie heel erg moeilijk moeten zijn, ookal neemt iemand deze mee of booten ze er een ander OS naast om de disk uit te lezen. Dit neemt dat dus weg. Er zijn genoeg plekken waar een laptop/tablet/PC een tijd onbeheerd locked kan staan terwijl andere mensen toegang hebben. Er zijn gebouwen waar meerdere startups/bedrijven in een grote verdieping of ruimte zitten, uberhaupt collega's die bij elkaar's PC kunnen etc.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:28]

[OddesE]

Normaal als je PC/laptop locked staat en encrypted is, zou het vergaren van informatie heel erg moeilijk moeten zijn

Toch niet. Bij de meeste apparaten is het een kwestie van opnieuw booten van een startschijf. Ja daar kan wat tegen gedaan worden maar uiteindelijk, als de aanvaller naast je systeem staat, dan pakt hij het gewoon op en neemt het mee. Beschermen ertegen is niet echt mogelijk dus men gaat niet verder dan de 'gelegenheidsdief' wat hinderen.

Wat je nu zegt is gelijk aan zeggen dat een kluis niet goed hoeft te werken, want het probleem is niet de kluis, maar dat een vreemdeling überhaupt fysiek toegang tot die kluis had.

Maar dit is het juist. Fysieke toegang voorkomen los je op met *hardware*, zoals een kluis, en niet met software. Vandaar dat hosting centra als soort van bunkers ingericht zijn. Daar loop je niet zomaar naar binnen.

[Verwijderd]

Opnieuw booten van een startschijf heeft geen enkel nut als je laptop disk encrypted is met iets als BitLocker en een sterke key of two step auth. Zonder dat is de data op de disk gewoon onzin die zeker door een willekeurige dief niet zomaar wordt gekraakt.

[OddesE]

Ik hoef toch alleen maar een key loggertje te installeren...

In het extreemste geval; ik hoef je PC niet eens aan te raken. Ik heb fysieke access... ben dus in jouw kamer... ik hoef dus alleen een spy cam verdekt op te stellen zodat die je toetsaanslagen kan zien. Even wachten totdat je je wachtwoord invoert en klaar.

Als ze fysieke access hebben ben je lost. Jij kunt zware maatregelen nemen, maar met relatief eenvoudige middelen kunnen ze die omzeilen omdat je niet langer in een vertrouwde omgeving bent. Als je het toetsenbord waarop je je wachtwoord invoert niet kunt vertrouwen ben je lost.

[Verwijderd]

Het hele punt is dat deze methode een keylogger overbodig maakt.

1) Keylogger installeren op een encrypted systeem. Hoe dan? Snap je wel hoe encryptie werkt?
2) Je kunt dit device plaatsen, die kaapt actieve verbindingen en vervolgens haal je deze weer weg
3) Keyloggers en cameras loggen geen automatische sessies. Ik ben al ingelogd op veel services die een 2step auth nodig hebben. Je kunt mn password keyloggen, maar knap als je ook mijn telefoon dan nog jat en decrypt om de 2step app of SMS te pakken te krijgen.
4) Knappe vent die via een camera mijn duizenden toetsaanslagen weet te ontleden als wachtwoorden en deze dan ook aan een service weet te matchen

[OddesE]

1) Keylogger installeren op een encrypted systeem. Hoe dan? Snap je wel hoe encryptie werkt?

Snap je zelf wel hoe het werkt? Je toetsaanslagen zijn toch niet encrypted of wel?? Als je gewoon het toetsenbord unplugged en er een klein (hardware) keyloggertje tussen zet dan helpt de encryptie van de data op de harddisk echt niet hoor. Dat keyloggertje bevat gewoon een sim kaartje en stuurt om de zoveel tijd een logje op.

[Verwijderd]

Zie bovenstaande comment voor meer potentiële situaties waarbij iemand bij je ethernetkabel kan komen.

[Aaargh!]

Niet alleen dat, het onderschept alleen onversleuteld verkeer. Daarvan moet je sowieso al uitgaan dat de hele wereld meeleest dus dit veranderd helemaal niets.

[Wim-Bart]

Los dat thuis op doormiddel van IPSec op basis van Certificaten. Alleen heeft niet iedereen hier de mogelijkheid toe.

Mensen die bij mij thuis van WiFi gebruik willen maken zitten op een publiek VLAN welke alleen Internet op routeert. Mijn eigen systemen communiceren intern en met de router op IPSec, van PC tot Telefoon, Tablets, Servers, Laptops en PCs.

Nadeel is wel dat even een andere router niet makkelijk te plaatsen is.

[proatjeboksem]

Toen ik de kop las, dacht ik: Wie zit er nou te surfen op een vergrendelde pc?
*opent alle bookmarks, Ctrl-D

Hoe dan ook, middels de PI maak je dus een nieuwe netwerkverbinding en op die PI draai je een soort sniffer? Want dat kan met wireshark ook, zou je zeggen. Of kan 'ie ook iets meer, zoals het artikel suggereert?

[OddesE]

Hij kan als 'web server' optreden en javascript code injecteren in de webpagina's die je opvraagt. En hij heeft een soort remote command and control daaraan gekoppeld dus als je die JS code hebt draaien in je browser dan kan hij er contact mee opnemen en commando's geven. Bijvoorbeeld om je aan een DDOS mee te laten doen. Hij zou theoretisch zelfs een (in JS gescheven) bitcoin miner in je browser kunnen laten draaien en evt. gevonden coins op laten sturen naar een door de hacker gecontroleerde account.

De hacker zou ook je PC kunnen oppakken en mee naar huis nemen aangezien hi fysieke access nodig heeft voor zijn hack.

[proatjeboksem]

Dat laatste zou wellicht op kunnen vallen bij de gebruiker

maar die JS injectie is wel een dingetje natuurlijk. Des te meer reden om geen JS te gebruiken als je webservice niet versleuteld is.

dank voor de uitleg!

[OddesE]

Probleem is dat de JS draait op de client, dus je kunt als server niet zomaar kiezen het niet te gebruiken... de pi injecteert dat script namelijk gewoon en de client gaat het dan gewoon uitvoeren. De server heeft daar geen invloed op.

[proatjeboksem]

Klopt, maar als het versleuteld is, kan die PI niet zien of het JS of een kattenfilmpje is.

[OddesE]

Klopt. Vandaar ook dat ze het hebben over onversleuteld HTTP verkeer, HTTPS kan hij idd niet bij.

[Stinow]

Prachtig. Hoe iemand toch zoiets bedenkt!

Ook het stuk: "laat het apparaat vervolgens aan de computer weten dat de gehele ipv4-ruimte deel uitmaakt van zijn netwerk. Daardoor verkrijgt het kwaadaardige netwerk prioriteit boven andere netwerkverbindingen." zou ik nooit zijn opgekomen. Weer wat geleerd .

[Reactie gewijzigd door Stinow op 23 juli 2024 18:28]

[darkfader]

Ik dacht gelijk aan de standaardtruc die bij VPNs gebruikt wordt, 0.0.0.0/1 en 128.0.0.0/1 routering.

[P1nGu1n]

De broncode staat op GitHub!

https://github.com/samyk/poisontap

[MMaster23]

Meeste bedrijven die echt serieus omgaan met endpoint security, blokkeren 90% van alle usb types. De overige 10% moet of gewhitelist of encrypted zijn.

Leuk als concept maar ik denk niet dat meeste mensen zich heel druk moeten maken. Wel zou een optie in Windows fijn zijn waarmee je alle apparaat installaties kunt weigeren indien gelocked.

[Syndroom]

dus 1% van de bedrijven blokkeren 90% van alle USB types.
Dat geeft nog wel marge voor het gebruik..
Ik


Al lijkt het me niet zozeer een hebbeding voor corporate spionage.

even ding in de PC van die knappe blonde collega/medeleerling/buurvrouw stoppen en je bladert door haar dropbox en mail; misschien nog even checken hoe ze op reddit en tweakers heet en wat ze daar post.

[batjes]

Wat is het doel hiervan? Dat artikel wat aangehaald wordt voor het "stelen van inlog gegevens" kunnen beide al .... jaren. "Netwerk adapter" bouwen die verkeer omleid, tja. Op een bedrijfs PC staat plug en play doorgaans netjes uit natuurlijk. En voor thuis computers zijn er wel makkelijkere manieren om een systeem en zijn internet verbinding over te nemen.

Zodra je lokaal toegang hebt tot een systeem kun je op een default Windows installatie wel 100derden geintjes uithalen om controle over dat systeem te krijgen. Plug & Play is een zwakte die al enige tijd bekend is.

[ultimasnake]

Ik snap niet helemaal wat dit te maken heeft met gelockte pc's en dit zo ongeveer de reden is dat wij HTTPS hebben geintroduceerd (man in the middle attacks).... Een PC blijft communiceren zolang applicaties actief zijn en dit is dus niets meer dan een HTTP sniffer... Sterker nog dit vereist een pi die zich geheel voordoet als een netwerk-device...

Onderstaande packet capturing project op basis van een raspberry pi gaat een stuk verder door gewoon over dezelfde draadjes het verkeer op te pikken. Ik kan me voorstellen dat bovenstaande alsnog te herkennen valt omdat het netwerk zich anders 'gedraagt' dan verwacht maar onderstaande is echt gewoon lijntjes aftappen (man on the sideline ipv man in the middle?)

https://www.youtube.com/watch?v=qwDfTnTnai8

[Reactie gewijzigd door ultimasnake op 23 juli 2024 18:28]

[nullbyte]

Het staat voorop dat een aanvaller fysieke toegang tot een computer moet hebben om deze aanval uit te voeren.

Nauwelijks iets om me druk over te maken dus.