'Aanval steelt inloggegevens via wachtwoordmanager met behulp van gastaccount'

Twee onderzoekers van de Finse universiteit van Aalto hebben op Def Con aanvallen op wachtwoordmanagers en FIDO-sleutels laten zien door gebruik te maken van de communicatie tussen processen op een computer. De aanval is bijvoorbeeld mogelijk via een gastaccount.

De twee onderzoekers die hun bevindingen presenteerden, Sid Rao en Thanh Bui, zeggen dat die communicatie verloopt via inter-process communication. Met hun onderzoek tonen ze aan dat een aanvaller zonder rechten, bijvoorbeeld gebruikmakend van een gastaccount op een gedeelde computer of een remote desktop-verbinding, de communicatie tussen processen van een andere gebruiker kan afluisteren. In hun onderzoek richtten ze zich op communicatie via netwerksockets, usb en named pipes.

Die eerste manier illustreerden ze via een aanval op wachtwoordmanagers, waarvan 1Password de meest bekende is. Zo is er een versie van 1Password waarbij een browserextensie communiceert met een desktopapp, die fungeert als een lokale websocketserver. Er vindt een uitgebreide controle door de server, oftewel de app, plaats om te verifiëren dat hij inderdaad met een legitieme cliënt te maken heeft. Die controle vindt echter niet omgekeerd plaats, waardoor de onderzoekers zich konden voordoen als de server. Die ontvangt informatie die een gebruiker invult in formuliervelden op webpagina's via de browserextensie. Op deze manier konden de onderzoekers op macOS de ingevulde gegevens buitmaken, zoals ze toonden in een demo.

Volgens de onderzoekers heeft 1Password de kwetsbaarheid inmiddels gedicht. Ze toonden ook een aanval waarbij een aanvaller een bevestiging van een FIDO-beveiligingssleutel kan onderscheppen, die via usb is aangesloten. Daarbij gaan ze er wel van uit dat de aanvaller al beschikt over het wachtwoord van zijn doelwit. Dit vult de aanvaller in en wacht op het verzoek de sleutel in de usb-poort te steken en kort aan te raken voor bevestiging. Door het verzoek van de browser in een hoge frequentie door te sturen naar de sleutel, is de kans volgens de onderzoekers hoog dat ze de bevestiging onderscheppen zodra het doelwit daadwerkelijk op een willekeurige site inlogt met de sleutel. Deze methode werkt doordat op Windows usb hid-apparaten door elk gebruikersproces benaderd kunnen worden.

Als mogelijke tegenmaatregelen noemden de onderzoekers het beperken van het aantal gebruikers op één systeem en het uitschakelen van ssh en remote desktop-toepassingen. Ook zou het denkbaar zijn cryptografische bescherming toe te passen.

Kwetsbare apps. De lekken zijn aan de betreffende partijen gemeld

Reacties (47)

[LtMarx]

Is dit familie van de Spectre vulnerabilities aangezien dit werkt door communicatie tussen processen?

Er worden hier op Tweakers wel eens grappen gemaakt over "security through obscurity" maar het lijkt steeds meer of dat de enige manier is. Hoe handig en secure deze online password managers zijn wordt om zeep geholpen door hun populariteit en daardoor aantrekkelijkheid om te hacken.

Zelf gebruik ik overigens daarom keepass omdat ik de online oplossingen niet aandurf.

[Herko_ter_Horst]

Hoe zou security-through-obscurity hier (of waar dan ook) helpen? Je ziet dat hackers alles uitpluizen, dus denken dat je iets van de implementatie van je beveiliging kunt obcuren en dat het daardoor veiliger wordt, is waanzin.

Deze vulnerability heeft ook niks te maken met het al dan niet in de cloud opslaan van data, maar met het gebruik van twee lokale processen die secure met elkaar moeten communiceren. Dat kan potentieel elke passwordmanager met browserextensie zijn.

[Reactie gewijzigd door Herko_ter_Horst op 22 juli 2024 20:07]

[CEx]

In de IT heeft 'security through obscurity' een heel slechte naam. Terecht ook aangezien er vaak ook alles uitgepluisd kan worden en zowel de kans als de implicatie van het betrappen is kleiner dan bij fysiek inbreken.
Dat maakt het concept echter niet waardeloos, het heeft altijd een voordeel om gevoelige zaken (rondom beveiliging, maar ook het 'wat ligt er?' en wie weet wat) verborgen te houden voor hen die het niet aangaat.

Op zichzelf is het een van de slechtste maatregelen, als onderdeel van een gelaagde beveiliging kan het echt wel waarde toevoegen.

[LtMarx]

Ik snap dat het een slechte naam heeft. Maar hackers maken toch een 'kosten baten analyse'. Dus hoeveel tijd steek ik een bepaalde hack en wat levert het op?

Een grote organisatie of veel gebruikte hardware levert veel meer waarde op dan het kraken van mijn beveiligde persoonlijke lokaal opgelagen kooklessen.txt bestandje (zie voorbeeld hierboven).

[RiDo78]

Dat bestandje an-sich zal ze misschien een rotzorg zijn. Maar in dat bestandje staat je wachtwoord. Een complex wachtwoord waarschijnlijk, anders had je het al onthouden. Dus je opent het bestandje en kopieert misschien het wachtwoord naar je klembord. En daar heeft de hacker wat hij hebben wil. Ofwel, hij leest het klembord uit, ofwel hij neemt simpelweg een screenshot.

Het voordeel van een password-manager, die gebruiken vaak een combinatie van klembord en toetsenbordbuffer voor het invullen van je wachtwoord of passen technieken toe waardoor het uitlezen van het klembord lastiger wordt. Vaak hoeft het wachtwoord daarvoor nieteens zichtbaar te wezen. De gemaakte screenshots zijn dan ook waardeloos.

Security through obscurity kan inderdaad helpen, maar dan moet je wel andere methoden gebruiken dan gebruikelijk. Iemand die uit is op je wachtwoord, zal toch echt eerst kijken om het via je klembord of een screenshot te pakken te krijgen. Om maar even een analogie te trekken, als je niet weet of de deur op slot is, probeer je eerst de deurkruk.

[Verwijderd]

Het admin-path van een standaard Drupal of Wordpress installatie veranderen naar iets dat niet /admin of /wp-admin.php noemt, houdt 90% van de bots tegen.

90%

[LtMarx]

Alsnog is het dan waardevoller voor hackers om een populaire tool of extensie te kraken dan een exotische/eigen oplossing.

Beide oplossingen zijn waarschijnlijk te kraken alleen leveren voor de hacker niet allebei evenveel waarde op.

[polthemol]

depends toch wel. Als ik de errorlogs zie van mijn webservertje en hoeveel bruteforces daarop worden gedaan. Veel toolings mogen dan wel exotisch zijn of kunnen dat zijn: de gebruikte technologie is veelal gelijk

Security through obscurity is leuk voor erbij te doen, bovenop andere beveiliging, maar alleen security through obscurity gaat je echt niet redden. Het is te makkelijk om vanalles en nog wat te scannen (en mijn url scoort echt niet hoog op zoeken, hij is gewoon ergens automatisch opgepikt op het www).

[Zenomyscus]

Het verschil is denk ik dat je dan zelf specifiek het doelwit moet zijn. Wanneer er een lek zit en er miljoenen mensen slachtoffer kunnen worden, dan heeft een simpele 'kooklessen.txt' misschien minder risico (om vele redenen alsnog een slecht idee overigens). Je kunt een bekende password manager nemen die de meeste bedreigingen wel zal stoppen, maar als het lek blijkt (of je hardware), dan hebben gelijk veel mensen een probleem. Dat maakt het interessant voor hackers om het te proberen. Andersom ga ik er in elk geval vanuit dat de meeste mensen hier niet belangrijk genoeg zijn om persoonlijk doelwit te zijn. Waardoor andere oplossingen op een andere manier bescherming bieden. Beide met risico.

[Verwijderd]

Bij security moet je je ook afvragen hoe lang informatie secure moet blijven. Als informatie alleen waardevol is gedurende de, hooguit, paar seconden dat client en server met elkaar communiceren dan is security through obscurity een prima oplossing, mits het maar meer dan een paar seconden duurt om door die “obscurity” heen te komen.

Sterker nog. Je zou eigenlijk kunnen claimen dat het gebruiken van encryptie sowieso al “obscurity” is; alle informatie is immers “verborgen” in een stuk data dat iedereen kan zien, met als enige uitdaging het vinden van de juiste sleutel om die data te vertalen naar de oorspronkelijke informatie.

[Herko_ter_Horst]

Dan verdraai je de betekenis van security-through-obscurity. StO betekent dat de "veiligheid" van je systeem vooral bestaat uit het "verborgen" houden van hoe je implementatie werkt.

StO kan beperkt nut hebben bij het vertragen van de eerste aanval ooit op het systeem, maar je kunt er - zeker tegenwoordig - van uit gaan dat de details van de implementatie op een gegeven moment gevonden gaan worden.

In plaats daarvan hoort de veiligheid af te hangen van het geheimhouden van de sleutel en niks anders. De implementatie zou juist open (en dus door iedereen controleerbaar) moeten zijn.

[Reactie gewijzigd door Herko_ter_Horst op 22 juli 2024 20:07]

[Verwijderd]

Zo “giftig” als de gemiddelde it’er reageert op security-through-obscurity zou deze er goed aan doen te begrijpen dat het “geheimhouden van een sleutel” ook géén oplossing is als de houdbaarheid van die sleutel niet afdoende is om de gewenste periode van geheim blijven van de informatie af te dekken. Of als die sleutel misschien niet eens nodig is (SSL fingerprinting bv).

Is security-through-obscurity een oplossing? Nee, niet als het op zichzelf staat. Maar in combinatie met andere securitymaatregelen kan het wel degelijk een rol spelen. Obscurity is een prima tool om een hacker op het verkeerde been te zetten, om de analyse van je systeem ingewikkelder te maken, om onzekerheid te introduceren in de mogelijke attack vectors.

[JDVB]

Nee, dit is geen familie van elkaar.
Hierbij worden kwetsbaarheden van software en besturingssysteem gebruikt, geen kwetsbaarheden van hardware.

[Meekoh]

Nee dit heeft niets met spectre te maken. Spectre is op een nog lager niveau.

[Beta]

Blij met mijn Keepass

Niets mis met de cloud maar wachtwoorden zijn toch wel essentieel om zo veilig mogelijk te bewaren.

[lenwar]

Keepass zou hier even gevoelig voor kunnen zijn.

De 'aanvallen' zijn veelal tussen de lokale applicatie en de browser-plugin te zitten. Dus als je een Keepass plugin gebruikt om automagisch je wachtwoorden in te vullen zou dit ook mis kunnen gaan als dit niet goed is geïmplementeerd.

[jarrin]

Keepass heeft hier een plugin voor. Die werkt i.c.m. keepasshttp. Welke op zijn beurt een HTTP port op localhost opent. Lijkt me dat je met een gast account die port ook gewoon ingeladen kan worden. Ken de technische werking van de API niet, dus ik weet niet hoeveel je er mee kan.

[FreshMaker]

Dat is een plugin, ik denk dat het grootste deel van de gebruikers Keepass 'kaal' gebruikt.
Waarschijnlijk kennen ze de ingebouwde auto-fill niet eens, en doen ze rechtsklik - copy password -> paste in het veldje

Dat vind ik het mooie aan Keepass, er zijn 100'en mogelijkheden, maar je moet ze wel zelf eerst installeren

[Wailing_Banshee]

Dat is een plugin, ik denk dat het grootste deel van de gebruikers Keepass 'kaal' gebruikt.
Waarschijnlijk kennen ze de ingebouwde auto-fill niet eens, en doen ze rechtsklik - copy password -> paste in het veldje

Dat vind ik het mooie aan Keepass, er zijn 100'en mogelijkheden, maar je moet ze wel zelf eerst installeren

Kennen doe ik hem wel, gebruiken niet. Geef mij maar m'n copy/paste! (en niet door rechtsklik - copy password, maar door CTRL+C [CTRL+B voor username])

[stresstak]

, en doen ze rechtsklik - copy password -> paste in het veldje

Ik dubbelklik op het password, dat werkt hetzelfde. En gebruik Keepass kaal.

[.net]

Dat is ook discutabel, het wachtwoord wordt gewoon naar je clipboard gezet.
Genoeg voorbeelden van malware die enkel je clipboard uitlezen en zo wachtwoorden of zelfs je Bitcoin adressen stelen/aanpassen.

Weliswaar wist KeePass je clipboard na een X aantal seconden, maar dan nog.

[lenwar]

Dat kan 'juist wel' kan gezien het gewoon een netwerkverbinding is. De truc zit hem in de authenticatielaag niet in de netwerklaag. Dit is ook precies waar het bij 1password 'mis ging'. Het staat ook verder (wat summier) beschreven in de PDF

[Soldaatje]

Klopt, gebruik nu keepassxc, een fork van keepassx, wat weer komt van keepass2. Deze heeft een nieuwe browserextensie, zou veiliger zijn.

[CEx]

Zo veilig mogelijk strookt niet met een single point of failure

[The Zep Man]

Zo veilig mogelijk strookt niet met een single point of failure

Je kan natuurlijk (automatische) backups maken.

[WK100]

Dashlane geeft aan dat het deze kwetsbaarheid ook heeft gefikst:

To improve the robustness of the communication between these two components, we introduced a pairing mechanism into the backend of our native application and web extension communication. We now create a random “secret” and exchange it using a classic and proven cryptographic algorithm named Diffie Hellman.

Bron:
https://blog.dashlane.com...phy-and-security-updates/

[knakworst]

Lastpass staat er niet tussen. Dat is volgens mij de bekendste, dus blijkbaar heeft lastpass deze kwetsbaarheid niet.

[NeFoRcE]

Inderdaad, ik ben nou wel eens benieuwd hoe veilig lastpass is t.o.v. een offline variant zoals KeePass. Ik pleit nog steeds voor keepass hier, maar de gebruikersvriendelijke implementatie van LastPass staat dat in de weg nog.

[Martinspire]

Lastpass draait geen locale server om op te vangen maar werkt gewoon via Chrome extensie. Lijkt me dus ook niet dat ie hiervoor te pakken is omdat er geen communicatie te onderscheppen is op de machine zelf.

[supersnathan94]

Of, en die lijkt me waarschijnlijker, het is niet onderzocht als deel van de Proof of Concept.

[digitalb]

Zijn er nu veel mensen met een gast account op hun pc?

[Ruudvoijen]

Ik persoonlijk niet. Ik erger mij er wel kapot aan dat Mac Os na elke major update het gast account weer aanzet.

[PPie]

Apart? Bij mij heb ik daar geen last van?
(Misschien is dit omdat ik meerdere users heb, waarvan 1 admin en de rest gewone gebruikers?)

[NiGeLaToR]

Uitzetten van het gastaccount is een kleine moeite:
https://www.isumsoft.com/...ccount-in-windows-10.html

En, even los van dat het in dit geval handig kan zijn deze uit te zetten zijn er talloze andere redenen om het gastaccount uit te laten. In publieke ruimtes c.q. kantoren kunnen mensen middels het gastaccount gewoon op je pc aan de slag, toegang tot delen van je pc krijgen, internet toegang verkrijgen. Dus zelfs als je al een gast toegang wilt geven maak dan een nieuw gastaccount aan, zet hier wél een wachtwoord op en bescherm je systeem in ieder geval zo.

Het gastaccount hoort wat mij betreft niet meer thuis in een IT omgeving waarbij je default security wilt hebben.

[be3a18]

Nét gekeken, Gast account is standaard uitgeschakeld in Windows 10.

Waarom iets uitschakelen wat al uit staat?

[Reactie gewijzigd door be3a18 op 22 juli 2024 20:07]

[Eager]

Een gastaccount is in principe veilig, dat is het hele idee. Als beheerder bepaal je zelf wat een gast wel of niet kan doen, toegang tot programma's etc. Dat er al dan niet kwetsbaarheden in de toepassing ontdekt worden wil niet zeggen dat het hele concept niet deugt.

Alls macbooks hier in huis zijn beveiligd met "undercover" van orbicule. In geval van diefstal zal de dief met het gastaccount aan de slag kunnen. Wat mij voorziet van de locatie, ip adres, screenshots, toetsaanslagen en camerabeelden. Daarom wil ik graag wél een gastaccount erop hebben staan.

[rschwartnld]

Een gast account is gewoon erg handig en onmisbaar, dat de os makers en hardware fabrikanten er zo'n potje van hebben gemaakt kun je niet afschuiven op de klant.
Om even een voorbeeld te noemen een splinternieuwe HP office printer blijkt toch weer voorzien te zijn van de zeer oude en onveilige chips.
Uit onderzoek blijkt dat fabrikanten al jaren sterk verouderde chips in vrijwel alle hardware en randapparatuur plaatsen, simpelweg omdat het zo lekker goedkoop is.
De industrie kent maar 1 modus super winsten maken, dat de klant dan opgescheept zit met niet zo veilige apparatuur maakt deze bedrijven niets uit.
Er is blijkbaar geen enkele leverancier die wel goede en moderne chips bleek te gebruiken.

Overigens zou er niets mis mogen zijn met het gebruik van een gast account voor bezoekers welke zeer beperkte rechten krijgen. Je wil toch absoluut niet dat men voor elke gast in je pand een aparte gebruiker account aan gaat maken.
Tegenwoordig heeft M$ in windows 10 het gast account deels onbruikbaar gemaakt in de laatste versies.
Dit is deels te omzeilen maar blijkbaar wil M$ liever dat iedereen op de planeet een M$ account gaat gebruiken. dat zie ik toch echt niet zitten. Er is al genoeg spy gedrag van google en m$. Veel te veel naar mijn zin.

[MrMonkE]

Maar @rschwartnld .. ze wisten het nieeeeet!

Hetzelfde gaat op met de SoC in TV's denk ik.
Ze zijn als de dood dat je meer dan 5 jaar met je TV doet.

[rschwartnld]

LoL
Jaaaaaa natuuuurrrrrlijk wisten ze het niet.
Een half jaar na het melden van deze lekken en nog steeds is er niets veranderd.

[Ruudvoijen]

Dus als ik het goed begrijp heeft de websocket wel een geencrypte verbinding met de extension van de browser? en als de client nu wel een authenticatie en authorisatie met de server maakt was het probleem verholpen.

[HappyFace]

Ik zit zelf bij 1Password en ben blij dat ze het direct op hebben gepakt. Toch is zo’n kluis best riskant.

Ik ben nu aan het kijken naar http://www.masterpasswordapp.com/

Principe is belachelijk simpel: deze applicatie slaat geen wachtwoorden op maar genereert ze op basis van jouw master password + inlog account een uniek wachtwoord. Na gebruik verwijdert de applicatie het weer.

Dus geen kluis, backups of lokale opslag wat gehackt kan worden.

[m_a_rnix]

Dan kan je dus nooit je master password veranderen?

[Honbrifcl]

Correct, maar waarom zou je dat dan nog willen? Als dat uitlekt, kun je een nieuw opgeven maar zul je inderdaad op alles sites je wachtwoord moeten veranderen. Is een app, maar er bestaat ook een java versie voor op PC. Ik vind het fijn werken...

[HappyFace]

Dat is goed om te horen. En het Gitlab project is ook erg actief.

Maar je hebt gelijk.

Het is net als je wanneer je sleutels kwijtraakt. Dan moet je ook al je sloten veranderen.

[m_a_rnix]

Nou, niet helemaal. Je moet alle sloten vervangen waarvan de sleutel aan je bos zat. Als je je autosleutel niet bij je had is daarmee niets aan de hand. In deze situatie moet je alle sleutels die je ooit hebt gebruikt vervangen als je je sleutelhanger vervangt. Kijk maar eens hoeveel dat er zijn na een jaar.

En mensen kunnen meekijken als je je wachtwoord intypt, dus af en toe je master password veranderen lijkt mij niet verkeerd.

[Jerie]

Alles kan gehackt worden.

De lokale kluis moet je opslaan op een veilige omgeving, die versleuteld is, en alleen toegankelijk is wanneer men toegang kan verkrijgen tot die account. Toegegeven, je moet dan meer dan 1 wachtwoord onthouden. Ik moet ook het wachtwoord onthouden van m'n laptop, smartphone, enz.

Verder staat er behoorlijk wat FUD op die pagina. Als zo'n cloud lek is, dan is er veel meer aan het handje. Mijn password manager gebruikt bijvoorbeeld Azure, en die synced inderdaad. Maar ik zou ook zelf een sync server op kunnen zetten. Zelfs al zou men die password database verkrijgen. Dan nog moet men hem brute forcen. En gezien mijn master password behoorlijk lang is, wens ik de aanvaller veel plezier (en succes).

Verder is het behoorlijk kut als je je master password nooit kunt veranderen. Dat kan bij moderne FDE wel. Ook is het mogelijk dat je master password leaked. Dan heeft men nog steeds toegang tot alle accounts. Dmv correlatie aanvallen kan men bij leaked websites erachter komen wat je master password is. De counter is immers waarschijnlijk 0, de username en de site naam zijn bekend (full knowledge).

De voorbeelden die worden aangegeven hebben trouwens zeer lage entropy (14 characters?). Dan kun je beter wachtwoordzinnen gebruiken. Dat is overigens, mits goed toegepast, een goed master password.

Wat wel zou kunnen is dat je client compromised is. Maar daar heeft dit programma ook last van. Want "de kluis" is gewoon de wachtwoord manager in Safari/Chrome/Firefox. Die ik nu *niet* gebruik.

[thomas_24_7]

Oei, ik gebruik Keepass in combinatie met Kee (gebruikt KeePassRPC i.p.v. KeePassHttp). Ben benieuwd of ze die combinatie ook meenemen in het vervolgonderzoek, want dat is vermoedelijk net zo kwetsbaar.

Geen al te groot risico als je maar één gebruikersaccount hebt en geen remote toepassingen open hebt staan, maar toch...fijn dat er zoveel mensen zich inzetten om de boel veilig te houden.

[Reactie gewijzigd door thomas_24_7 op 22 juli 2024 20:07]