LastPass-hack vond plaats door hooggeplaatste werknemer te hacken

De aanvallers die data van LastPass hebben gestolen, hebben daarbij ook cloudback-ups gestolen. Dat gebeurde bij een tweede aanval die kort na de eerste plaatsvond, waarbij een seniorprogrammeur van het bedrijf werd aangevallen.

Dat schrijft LastPass in een nieuw supportdocument. Het gaat om een tweede incident dat vorig jaar plaatsvond, kort nadat LastPass in augustus melding maakte van een hack. Het bedrijf meldde toen dat het gehackt was maar dat er alleen broncode en technische informatie werd buitgemaakt, maar weken erna moest LastPass toegeven dat er ook versleutelde wachtwoorden waren gestolen. Nu zegt het bedrijf dat er ook, via een werknemer, toegang is verkregen tot cloudback-ups.

Na de eerste aanval zou de aanvaller informatie hebben gebruikt die werd buitgemaakt tijdens de eerste hack. Welke informatie dat was, is niet bekend, maar tussen 12 augustus en 26 oktober zou de aanvaller de systemen hebben verkend en interne data hebben geëxfiltreerd. Hoewel LastPass activiteiten logde, viel de aanvaller niet op.

De aanvaller zou inloggegevens hebben gestolen van de thuiscomputer van een senior devops-programmeur. Saillant detail is dat de aanvaller binnen wist te komen door het masterwachtwoord van de devops-programmeur te downloaden, maar die heeft vervolgens zelf ook de multifactorauthenticatieaanvraag goedgekeurd. Die programmeur was een van de vier personen binnen LastPass die toegang had tot een LastPass-kluis waarin AWS Access Keys stonden. Daarmee kunnen back-ups worden gestolen van klantgegevens en kluizen die in AWS S3-buckets stonden.

In de back-ups op AWS stond veel informatie; LastPass heeft een ander document online gezet waarin een lijst staat met gestolen gegevens. Het gaat onder andere om mfa-seeds en identificeerbare info, maar het bedrijf schrijft ook dat er vijf blobs zijn gedownload van back-ups van klanten die tussen 20 augustus en 8 september een account hadden. In die blobs zaten ook versleutelde velden voor de wachtwoorden en onversleutelde velden voor bijvoorbeeld url-namen. Een ander opvallend detail is dat LastPass de nieuwe blogposts met een metatag heeft verborgen voor zoekmachines, ontdekte BleepingComputer.

LastPass zegt dat het verschillende acties heeft ondernomen. Zo heeft het bedrijf extra beveiliging op mfa-apps gezet en zijn er credentials gereset van interne werknemers. Ook is de AWS-omgeving geanalyseerd en zijn er nieuwe beveiligingsmaatregelen toegevoegd.

Reacties (113)

[biteMark]

Dus ze zijn een half jaar geleden gehackt en nú pas brengen ze naar buiten dat de hackers toegang hadden tot hun cloud back-ups?

En dan dit:

Een ander opvallend detail is dat LastPass de nieuwe blogposts heeft opgenomen in zijn robots.txt zodat die niet door zoekmachines worden opgepikt.

… wat? Ze hopen zo weinig mogelijk mensen te bereiken en ze geven dus letterlijk geen ene steek om openheid en eerlijkheid richting hun slachtoffers!

Dit artikel zegt genoeg over het bedrijf, het zou beter zijn als ze ophouden te bestaan.

[_Peter2_]

Dus ze zijn een half jaar geleden gehackt en nú pas brengen ze naar buiten dat de hackers toegang hadden tot hun cloud back-ups?

Zij hadden dit al veel eerder gemeld zie bijvoorbeeld:

• nieuws: LastPass maakt melding van hack, maar wachtwoordresets zijn niet nodig
• nieuws: LastPass: hackers hadden toegang tot 'bepaalde klantgegevens' bij nie...

Klanten zijn daarbij ook geïnformeerd.

Dit is nu weer nieuwe/aanvullende informatie.

[i-chat]

het hele punt wat bitemark vermoedelijk heeft is dat die berichten nogal tegenstrijding zijn.

geen toegang, wel toegang, maar een beetje toegang, en ik heb sterk het idee dat men zo lang heeft gewacht om economische redenen.

als password-kluis-bedrijf verkoop wat mij betreft ook niet een app om wachtwoorden automatisch in te vullen (dat kan elke kleuter wel in elkaar flansen)...wat je alt lastpass, endpass etc werkelijk verkoopt is het vertrouwen ... dat je een veilige dienst hebt, dat je netjes omgaat met data, en dat je mensen de juiste informatie geeft bij een hack.

wie zegt dat dus nu wél de waarheid is als ze al 2 (of was het al 3) keer eerder in de media kwamen met
'dit was er gebeurd'-berichten, die steeds weer niet leken te kloppen.

[Tjidde]

Voor mij is het belangrijkste wat een password-kluis-bedrijf moet verkopen is vertrouwen.

Want het blijft altijd een zwarte doos. Echter is mijn vertrouwen nu zo laag in LastPass dat ik aan het onderzoeken ben naar welke van de 100 alternatieven wil ik gaan gebruiken. Zodra ik een keuze gemaakt heb ben ik weg.

[BezurK]

Ik voel je. Maar het probleem wat ik hier een beetje bij heb is dat je nooit zeker weet of je gekozen alternatief niet ook dezelfde fouten maakt. LastPass werd tot dit incident toch ook gezien als een betrouwbare partij en een goede keus. Ik heb moeten lullen als brugman om mijn hele gezin over te krijgen op LastPass (de betaalde dienst). Ik kijk er tegenop om mijn gezin te moeten uitleggen dat we moeten verhuizen om vervolgens een jaar later weer in hetzelfde schuitje te zitten met wederom een breach.

Ik vind het lastig. In technische en morele zin snap ik helemaal dat we LastPass moeten verlaten maar het plaatje is wel groter dan dat alleen.

[Tjidde]

Ik denk als ik overga naar een selfhosted iets, mijn vriendin bijvoorbeeld makkelijker meekrijg dan als ik lul als brugman voor lastpass.

Maar het is lastig, veel gebruikers hebben nog niet eens door dat dit een probleem is. Die zijn ooit omgepraat om LP te gebruiken en denken er niet meer over na want het werkt. Deze gebruikers ineens te gaan verkondigen wat er allemaal gebeurd is en ze vertrouwen nooit meer een password manager en gaan naar terug naar hun standaard wachtwoord met een toevoeging per site.

[Triblade_8472]

Want jouw self-hosted pakket heeft 24/7 beveiliging en SOC?

Uiteraard ben jij als los persoon over het algemeen minder interessant voor hackers dus dat is winst. Maar als meer mensen dit gaan doen, kunnen hackers zonder dat het opvalt gewoon databases van miljoenen mensen binnenhalen toch?

Het voordeel van bedrijven als lastpass is dat zij altijd 24/7 beveiliging hebben. Natuurlijk gaat er altijd wel iets mis, maar de kans is groter dat het goed gaat toch?

[Recklezz]

Die laatste regel haalt je hele argument omver.

[Triblade_8472]

Klopt, maar ik kan niet iets goedpraten als dat het niet is toch?

Er is niks sluitend en 100% veilig dus ik ga dan ook niet doen alsof.

[batteries4ever]

"Natuurlijk gaat er akltijd wel iets mis": precies! Dus, ook al is het comfortable dingen in de cloud te zetten, toch liever lokaal hosten. Je passwords op een stukje papier in de keukenla schrijven is wellicht veiliger dan Lastpass! Je passwords in de cloud zetten is natuurlijk handig, dan kun je er altijd bij... en eventuele hackers ook als er iets fout gaat! Ik gebruik KeePass: lokale database met password. Vast ook niet 100% zeker, maar de kans dat iemand mijn laptop hackt, de database krijgt en het password ervan kraakt is veel kleiner dan dat iemand zo'n organisatie te lijf gaat en dan de gegevens van duizenden mensen steelt.
Goed dat de passwords zelf kennelijk nog veilig zijn, maar als daar staat dat jij urls als "gaynederland.nl" hebt dan is dat ook al persoonlijke data.

[Tjidde]

Als ik mijn firewall goed regel en niet op elk platform loop te pronken van jongens mij self-hosted pakker is extreem veilig.

Zie ik oprecht een kleinere kans dat mijn data op straat komt dan bij LastPass.

LastPass heeft gewoon een extreem groot doel op hun rug. De gene die LastPass hackt en aan wachtwoorden (uit een kluis van een random gebruiker) komt zal legendaries zijn. Er zijn dus mensen constant bezig om dat te doen.

Omdat ik een kleine speller ben ik minder vatbaar voor veel hackers. Daarnaast is een beetje 24/7 logging met auto blocking bij x aantal requests per minuut niet zo lastig om te regelen. Zeker als ik mijn vault achter een VPN zet. Is de kans wel een stuk kleiner dat ik gepakt zal worden.

De kans is nooit nul, of je nu LastPass gebruikt iets self-hosted of een schrift in de la hebt, er is altijd een risico dat iemand erbij kan komen.

Het belangrijkste is denk ik toch om te zorgen dat je er altijd mee bezig bent. Zorgen dat alles up to date is en zodra er een CVE is over een product dat je gebruikt, risico bepalen en in het ergste geval het product niet gebruiken tot de CVE is opgelost. Ik snap dat, dat niet is weg gelegd voor de Henk en Ingrids onder ons. Maar wel voor iemand die actief in de ontwikkelwereld zit en daar ook graag tijd aan wilt besteden.

[Cyberpuppy]

Nou bij Lastpass is het wel duidelijk. Want als je het originele bericht van Lastpass leest dan staat er ergens heel goed verborgen dat bijv. URLs dus niet versleuteld zijn. Dan ben je dus niet bewust met je security bezig. Verder is nog steeds niet duidelijk welke gegevens van wie er nu gelekt zijn. Sommige mensen hebben al lang een bericht in hun email. Bij mij kwam het bericht pas na een paar weken binnen.

Kortom. Alles zakelijk gaat nu over naar Bitwarden (zijn voor zover ik de enige die een externe audit hebben laten uitvoeren -> https://bitwarden.com/help/is-bitwarden-audited/)

Alles prive gaat naar KeePass.

[LoCoZ]

1Password heeft ook externe audits, en bevindingen gepubliceerd:
https://support.1password.com/security-assessments/

[Matanza]

Zit je na z'n hack eigenlijk niet het beste bij LastPass ?
Als ze het op zn minst zelf serieus nemen: Hebben ze net tal van audits achter de rug. Is alle security terug aangescherpt. Zijn alle medewerkers op cursus geweest etc ...
Net op zn moment is LastPass de meest veilige keuze vermoed ik.

Hoe langer de 99 andere concurenten zonder breach zitten, Hoe sneller ze aan de beurt zijn.


Gewoon lekker bij LastPass blijven zou ik zeggen.

[Blizz]

Iedereen die LastPass de afgelopen 5 jaar (sinds voor ze niet meer onafhankelijk zijn) in de gaten houdt is er al weg of had allang grote vraagtekens. Het product is slechter en slechter geworden. De UX in de Safari-omgeving en de Mac en iOS apps waren voor mij het belangrijkst en voornamelijk de computeromgevingen waren gewoon crap. Ik gebruik zelf al anderhalf decennium zowel 1Password als LastPass en heb in al die tijd voornamelijk LastPass gebruikt, tot ik een paar jaar geleden de knoop doorhakte en bij LastPass ben vertrokken. Ik vond dat ze goed omgingen met de eerste paar breaches, de informatievoorziening was toen goed en het ingrijpen aardig en snel, maar dat is de afgelopen periode echt anders geweest. Het enige dat ik niet heb gedaan is mijn master password wijzigen, maar ik vertrouw zelfs dat niet meer nu.

[LaTiNo156]

Van een ander weet je het idd ook nooit zeker, en ze gaan allemaal ooit wel een fout maken. Maar Lastpass nu al een AANTAL keer.

[Aldy]

Doordat LastPass nu extra maatregelen heeft genomen is de nieuwe LastPass misschien juist het alternatief voor de oude LastPass. Ik gebruik geen LastPass, maar kan mij voorstellen dat je op dit moment het veiligste daar bent.

[swhnld]

Ik denk ook niet dat je hoeft te veranderen van partij, maar zou wel voor wat belangrijke websites de wachtwoorden wijzigen en je lastpass encryptie nalopen + 2FA aanzetten op de kluis. kraakt iemand dan het master wachtwoord klopt die niet meer, en uit de oude backup die ze gevonden hebben, kunnen ze niets meer mee want de wachtwoorden zijn gewijzigd.

[ro8in]

Ik ben 2 jaar geleden overgestapt op een self hosted bitwarden oplossing. Precies omdat dit mij toch niet helemaal lekker zat dat al mijn zo ongeveer belangrijkste informatie opgeslagen stond bij 1 partij waarvan ik geen enkele inzicht heb in hoe zij werken. Het enige wat ik mij wel afvraag is of lastpass ook echt mijn data heeft verwijderd, nadat ik mijn account bij hun verwijderd heb. Ik hoop het wel!

[Reactie gewijzigd door ro8in op 22 juli 2024 22:17]

[poktor]

Yep, hier ook nu al weer een paar jaar self-hosted Bitwarden. Bevalt uitstekend. https met een certificaat, gaatje geprikt in de Fortigate firewall zodat de app overal werkt, helemaal super. Draait in Debian in VMware op een windows server 2019 server hier thuis. 2 x per week maakt het systeem automatisch 3 backups: van de VM, de container en een kopie van de VM naar een andere pc. Langzamerhand maken steeds meer mensen hier gebruik van. Inmiddels zitten er al meer dan 1000 passwords in het systeem, dus ik kan het me niet veroorloven om iets kwijt te raken.

[ro8in]

Ja draai het zelf in een docker containertje op een Intel NUCje. Het is even wat meer gedoe, maar het is het zo waard om dit gewoon in eigen beheer te doen. Zal zelf niet meer zo snel al deze info nog bij een 3e partij stallen.

[dasiro]

Dit doet me een beetje denken aan het diginotar-verhaal. De impact is iets minder groot, maar de collateral damage voor personen kan dan weer groter zijn

[Raphire]

Ik ben zelf een tijdje terug van lastpass naar 1password overgestapt, en kan het echt aanbevelen. Ik ben vooral te spreken over de focus op veiligheid, de openheid en bereikbaarheid van zowel support als het privacy/security team en de verschillende developer features.

[Reactie gewijzigd door Raphire op 22 juli 2024 22:17]

[Nyarlathotep]

Deze hack is voornamelijk mogelijk gemaakt door een senior (!!) developer, die nota bene zelf het MFA verzoek goedkeurde toen de aanvaller ging inloggen.
Senior develoeprs heb je bij elk bedrijf, dus overstappen is een net zo grote gok als blijven.

[Cyberpuppy]

En waarom heeft een senior developer toegang tot de live dataset van klanten? Voor verreweg het meeste ontwikkelwerk kun je volstaan met een subset van de data of zelfs random gegenereerde data.

[ronald136813]

Ik had lastpass had ook een sterk wachtwoord op mijn kluis zitten.
ben over gestapt naar Bitwarden, de reden niet omdat ik bang was dat master password niet veilig zou zijn , maar de manier waarop ze zijn gehacked dat moet niet mogelijk kunnen zijn bij een bedrijf dat als core business beveiliging heeft en dat was de reden ik kon dat niet accepteren.

Wederom een sterke wachtwoordzin bedacht en aantal iteraties op 1234567 gezet, zelfs op een Android smartphone ontgrendelt de kluis snel genoeg.

Steve van GRC.COM geeft wel goede uitleg.
er zijn er 3 die worden genoemd, one password , bitwarden en dashlane als goede kluis programma's
Bron: https://www.youtube.com/watch?v=9XWHCF4pLmI&t=21s
op Twit staan zo en zo goede interviews met Steve Gibson staan meerdere video's over lastpass , de hack, de iteratieteller voor oudere klanten die nooit is geupdate stond zelfs eerst op 1, toen op 5000 en daarna op 100100
Ik heb het in Bitwarden op zijn advies op 1234567 gezet.


Bitwarden is opensource en word actief aan ontwikkelt ook.

[ep667]

Als je iets als bedrijf in deze sector moet uitdragen is het vertrouwen. En dat kan ook een goede disclosure zijn voor mij. Direct duidelijk communiceren wat er is gebeurd, wat de implicaties daarvan zijn en hoe ze dit in de toekomst voorkomen.

Nu ging het van: gehackt, maar je hoeft niets te doen via gehackt en misschien zijn er wel klantgegevens gestolen naar gehackt maar klantgegevens en backups gestolen.

Voor mij was deze halve disclosure wel reden om over te stappen naar een andere leverancier. Eentje die in ieder geval nog nooit gehackt is en vanwege de extra sleutel voor de wachtwoordkluis ook minder interessant is om te hacken. Ben ik dan 100% veilig? Nee, maar Lastpass maakt keer op keer dezelfde fouten. Want dit is niet de eerste keer.

[SunnieNL]

Nee, dat maken ze niet nu pas bekend. Kijk naar de links naar oude artikelen.
Het enige nieuws is dat we nu weten hoe ze bij de data gekomen zijn. De rest was al bekend.

[Dennisb1]

En dan dit:

Een ander opvallend detail is dat LastPass de nieuwe blogposts heeft opgenomen in zijn robots.txt zodat die niet door zoekmachines worden opgepikt.

… wat? Ze hopen zo weinig mogelijk mensen te bereiken en ze geven dus letterlijk geen ene steek om openheid en eerlijkheid richting hun slachtoffers!

Nee, ze doen het anders.

All of today's support bulletins are not easy to find, with none of them listed in search engines, as the company added <meta name="robots" content="noindex"> HTML tags to the document to prevent them from being indexed by search engines.

Komt op zelfde deels neer maar is wel andere wijze.

[Reactie gewijzigd door Dennisb1 op 22 juli 2024 22:17]

[eborn]

Ik kreeg als LastPass Business klant gisteren ook een email met daarin de melding dat er aanvullende informatie gedeeld ging worden, met de opmerking:

Given the sensitive nature of this information and to give you time to implement the Security Bulletin changes, we ask that you please treat this information as confidential until it becomes available to the public later this week.

Dat is natuurlijk kansloos, omdat je weet dat dit 3 uur later op Internet staat. Ik vermoed overigens dat dit de reden is dat de items nog op 'niet indexeren' staan.

[Reactie gewijzigd door eborn op 22 juli 2024 22:17]

[GrooV]

Gelukkig heeft Microsoft tegenwoordig in zijn Authenticator nog een extra factor ingebouwd. Je moet nu het getal intoetsen wat op het scherm staat. Hierdoor kan je dus niet meer ongezien een MFA verzoek goedkeuren. Helaas wel een extra stap wat het "irritant" maakt

[kodak]

In het nieuws staat niet hoe deze mfa-beveiliging goedkeuring moest krijgen van de medewerker. Multifactor met meer van dezelfde handelingen doen (tik ook dit getal in) bestaat al jaren, dat was hier dus niet zomaar de oplossing. Het probleem is hoe dan ook dat gebruikers zich bewust moeten zijn van wat de betekenis van hun handelingen als overtikken en terugzenden is. Een extra handeling zorgt daar helaas niet zomaar voor, zeker niet bij gebruikers die haast hebben of van irritatie af willen zijn of denken dat niemand ze zal foppen. Een belangrijk deel om van te leren en dus niet zomaar te stellen dat iets anders voor mfa beter was geweest ontbreekt: weten waarom de medewerker de mfa accepteerde.

[Reactie gewijzigd door kodak op 22 juli 2024 22:17]

[BramT]

Dat getal had hier zeker wel geholpen. Als een aanvaller de MFA triggered krijgt de aanvaller dat controle-getal te zien. Het slachtoffer ziet dat er een MFA goedgekeurd moet worden, maar weet het betreffende getal niet. Dus zelfs als hij het achteloos wil goedkeuren, dan kan dat simpelweg niet.

Voor mensen die hun (werk)pc aan laten staan, of met meerdere workstations werken, is het een bekend fenomeen. Af en toe herlaad een website/dienst zich en kan dat een MFA triggeren. Je krijgt dan te pas en te onpas van die meldingen op je telefoon. Als je dat te vaak hebt meegemaakt krijg je het gevaar dat je die automatisch gaat goedkeuren.

Dat extra controlegetal wat verifieerd dat degene die het triggered ook degene is die het goedkeurt helpt hier tegen.

[kodak]

Dan doe je kennelijk de aanname dat de medewerker voor hun mfa niets heeft moeten genereren op basis van invoer. Dat is een mogelijkheid, maar op basis van een aanname kan je niet hard stellen dat dit dus het geval was en de 'oplossing' gepast is.

[BramT]

Aanname? Wat bedoel je met "medewerker voor hun mfa niets heeft moeten genereren"?

Als we het nog steeds hebben over dat extra getal wat ingevoerd moet worden, dan nee, da's een conclusie gebaseerd op dit stukje:

De aanvaller zou inloggegevens hebben gestolen van de thuiscomputer van een senior devops-programmeur. Saillant detail is dat de aanvaller binnen wist te komen door het masterwachtwoord van de devops-programmeur te downloaden, maar die heeft vervolgens zelf ook de multifactorauthenticatieaanvraag goedgekeurd.

Simpelweg omdat de betreffende medewerker de mfa-request niet kan goedkeuren als hier om een extra getal gevraagd zou worden.

[kodak]

Dat goedkeuren kan prima als de crimineel dat getal doorgeeft zoals de gebruiker het denkt te verwachten om er iets mee te doen. Bij phishing komt het al jaren voor dat ook de mfa challange codes en patronen via de phisingsite worden doorgegeven en responsecodes/goedkeuring van slachtoffers live worden verkregen, om als crimineel dan snel zelf te gebruiken. Dat kan je dus zeker bij dit soort gerichte aanvallen niet uitsluiten op basis van de vage omschrijving in het nieuws.

[OkselFris]

Ik denk dat je niet helemaal begrijpt wat hij bedoelt hij heeft het over MS number matching. Het getal is in dit geval een random 2 cijferig getal wat de gebruiker in het sign-in scherm krijgt, deze moet je dan vervolgens invoeren in de MFA app. Dit maakt het onmogelijk om per abuis een MFA challenge goed te keuren.

[kodak]

Het is juist wel mogelijk: het probleem is dat je er niet vanuit kan gaan dat de medewerker precies gedaan heeft wat eigenlijk de bedoeling is. En dan kunnen we wel iets een oplossing vinden in de hoop dat een gebruiker wel doet wat de bedoeling is, maar dat is dan niet zomaar een oplossing voor deze situatie. Mfa gaat meestal stuk omdat gebruikers juist iets doen wat niet de bedoeling is en mfa dan niet meer tegen helpt. Jij meent bijvoorbeeld dat iemand verplicht een extra getal moet invullen wat op een inlogscherm staat. Een crimineel kiest bijvoorbeeld het juiste moment om een inlogscherm na te doen waarbij de medewerker denkt dat die aan het inloggen is, waarbij de crimineel live de challenge op die nepinlogpagina plaatst en de reactie van de gebruiker zelf gebruikt. Of de medewerker is er zo erg niet met de gedachten bij dat het hem/haar niet uit maakt waar dat extra getal vandaan komt om iets te genereren en terug te sturen. Dit komt al voor. Daarom is het belangrijk om eerst te weten wat die medewerker precies heeft gedaan en waarom.

[bwerg]

Multifactor met meer van dezelfde handelingen doen (tik ook dit getal in) bestaat al jaren, dat was hier dus niet zomaar de oplossing

Jawel, want een login met het intypen van een controlegetal lukt alleen als de laptop en de telefoon-met-app bij elkaar zijn. Als iemand op afstand toegang heeft tot de laptop maar niet tot de telefoon dan zal de authenticatieapp aan de medewerker vragen een getal over te typen, maar het veldje om dat in te doen staat op de laptop van de aanvaller.

[Skywalker27]

MFA is niet zalig makend legt alleen de drempel hoger sommige jatten gewoon je token. En dan ben je gewoon klaar. SOC's hebben hier hun handen vol aan omdat je zeker moet weten dat alle devices afgemeld zijn enz. enz. enz. Echter zijn de meeste cyber criminelen niet echte hackers en zullen gewoon je wachtwoord proberen te kraken en die hou je hiermee buiten de deur.

[bwerg]

Natuurlijk legt het alleen de drempel hoger, dat is wat alle beveiligingsmaatregelen doen...

De kans dat er iets misgaat neemt wel grofweg kwadratisch af met het aantal factoren en onafhankelijke beveiligingslagen.

[Reactie gewijzigd door bwerg op 22 juli 2024 22:17]

[Skywalker27]

zeker weten

[Oon]

Dit is toch gewoon TOTP? Dat had LastPass ook als optie ingebouwd, net als vrijwel iedere andere website.

Ik zie niet in hoe dit ze gaat redden, je hebt alleen een andere phishing tactiek nodig

[lenwar]

Microsoft Authenticator hoe ik het ken, maakt gebruik van een ander mechanisme.
Ik log ergens in met mijn gegevens en vervolgens krijg ik een pushbericht die ik al dan niet kan valideren. (dit is ook waar het gevaar rust). Zodra ik op de 'ok' knop druk gaat het systeem verder.

De Authenticator-installatie draait op een vertrouwd apparaat (een telefoon in dit geval) en de installatie zelf is daarmee dus ook vertrouwd. (het zal dus niet werken om bijvoorbeeld een dump te maken van de installatie en die op een andere telefoon op te starten, aangezien die telefoon een ander hardware-ID heeft.

Mogelijk dat er dus ook nog een optie is, die naast het pushbericht ook nog een PIN overgetypt moet worden (ala TOTP) als (nog een) extra factor. Dit ken ik zelf niet in de praktijk (de door mij gebruikte services vragen er niet om), maar ik zie wel de optie om het te doen.

[Oon]

MS Authenticator heeft inderdaad een push mechanisme voor MS diensten, maar daarnaast ook gewoon TOTP ondersteuning.
Het grote nadeel is dat voor het push mechanisme geen standaard is, deze dus alleen voor diensten die Microsoft's SSO gebruiken werkt, en er totaal niet wordt gecommuniceerd waar je nou goedkeuring voor geeft. Je krijgt dus een melding waarvan je maar moet gokken of je die zelf getriggered hebt, en aangezien bijv. Outlook en OneDrive ook zo'n melding veroorzaken bij sync word je ook nog eens constant aangeleerd om maar gewoon op 'ja' te klikken, want doe je dat niet dan mag je de volgende keer dat je Outlook weer aan klikt helemaal handmatig die flow doorlopen omdat het laatste verzoek mislukt was en je helemaal bent uitgelogd.

Maar als het over getallen overtypen gaat dan denk ik toch wel echt aan TOTP, niet aan de ingebouwde 'MS-only' authenticatie die erin zit.

[lenwar]

Klopt in de basis, maar als je bijvoorbeeld Azure AD gebruikt kan je je applicaties middels SASL laten authenticeren en daarmee het push-mechanisme laten verlopen.

Het ligt er net aan hoe je diep je als organisatie in het MS-ecosysteem zit

[Yoxt]

Doet Google dat ook niet bij de Gmail app? Je moet een van de 3 getallen aanklikken wat op het login scherm staat.

[GrooV]

Dat weet ik niet, gebruik geen Google namelijk. Maar ze zullen vast allemaal redelijk het zelfde doen.

Grootste nadeel er van is dat apps zoals Authy er niet mee werken

[Urk]

Dat hoeft volgens mij ook niet want Authy werkt nooit met push meldingen. Alleen met MFA codes, en die moet je dus toch altijd invullen en kun je dus nooit per ongeluk goedkeuren....

[Luchtbakker]

Zeker een stuk veiliger. Maar daarom zijn hackers tegenwoordig erg op zoek naar actieve tokens waarmee ze de authenticatie kunnen omzeilen.

[Raymond Deen]

Als dat nu nog steeds mogelijk is dan verdienen die makers van MFA billenkoek. Al jaren geleden kreeg ik eens de opdracht om een token te maken met daarin privacy gevoelige informatie dat niet werkend gekopieerd en ontsleuteld kon worden naar een andere browser. Met de standaard beschikbare encryptie frameworks was dat goed te doen, zonder zelf allemaal shady dingen te programmeren.

[bwerg]

Dat ligt niet aan Authenticator maar dat ligt aan de service waarop je probeert in te loggen. Ik gebruik ook MS authenticator voor verschillende zaken, en voor sommige daarvan moet ik een getal overtypen en voor andere moet ik alleen op "approve" klikken.

Extra voordeel van getallen overtypen: dat werkt ook als je geen netwerkverbinding op je telefoon hebt. Ik heb wifi en mobiel internet standaard uit staan om accu te besparen als ik het niet nodig heb, het duurde even voordat ik door had waarom een login steeds mislukte na twee minuten te blijven hangen - hij wachtte, zonder mij dat te melden, op de tweede factor die niet te bereiken was.

[GrooV]

De TOTP variant werkt helaas niet bij systemen die dat niet ondersteunen bijvoorbeeld Microsoft Remote Desktop en dan kan je toch MFA gebruiken

[Wachten...]

Het verhaal wordt er maar niet beter op bij LastPass. Ik ben trouwens benieuwd, waarom wordt niet alles versleuteld (zoals URLs e.d.)?

Het is zo voor hackers toch veel makkelijker achterhalen welke gegevens interessant zijn voor hun (als er bijvoorbeeld www.paypal.com staat). Ik snap dit nooit zo goed, maar er zal vast een goede reden achter zitten die een Tweaker hier wel weet

[Maestro.mosjuh]

Als je gegevens versleuteld in de database opslaat is het daarna lastiger doorzoekbaar - dat kan een afweging zijn tussen wel of niet versleuteld oplaan.

Specifiek voor URL's: LastPass moet bij het bezoeken van een site snel de bijbehorende kluisregel vinden. Als hij daarvoor alle kluisregels af moet - url decrypten - kijken of hij matched, dan kan dat een behoorlijke performance-impact hebben. (in verhouding met een "select record in database met url like...")

[Wachten...]

Maar zouden ze een url niet om kunnen zetten in een random andere url (een beetje zoals Simplelogin voor email).

Ik ben dan geen ontwikkelaar o.i.d. dus ik zal ongetwijfeld wel weer iets over het hoofd zijn. Maar een enorme rocket science lijkt het mij niet als je hierin thuis bent. Een URL openbaar maken maakt het voor hackers in ieder geval nog veel makkelijker om te scannen op belangrijke data.

[Maestro.mosjuh]

Als je in een database-tabel (dat is vergelijkbaar met 1 excel-sheet) kluisregels hebt staan met een URL veld, dan kan je tegen de database zeggen:
Geef mij alle kluisregels waar in het url veld "tweakers.net" voorkomt - dan krijg je alle kluisregels die met tweakers te maken hebben.

Ga je een andere random url er in opslaan, kan je die vraag dus niet meer stellen.

Daarnaast kan je een kluisregel hebben voor https://m.facebook.com (de mobiele website-versie van Facebook). Als je dan op https://www.facebook.com wil inloggen, wil je ook dat die kluisregel van https://m.facebook.com gebruikt wordt - je wil dus ook kunnen zoeken op een deel van de url: facebook.com - ook dit werkt niet/slechter als je andere random url's gaat opslaan.

[SenkZ]

Maar je kan toch wel de url versleutelen van de site die je bezoekt. En vervolgens met de versleutelde waarde zoeken in de database? Ervan uitgaande dat je dan ook alle urls versleuteld opgeslagen hebt.

[Reactie gewijzigd door SenkZ op 22 juli 2024 22:17]

[Wachten...]

Precies dit.... En ik snap eigenlijk niet dat ik een 0 score krijg. Is dit niet relevant dan? Er staat letterlijk in het artikel dat deze gegevens gestolen en zichtbaar zijn, en ik geef een response daarop waarom dit eigenlijk in plain text moet staan en er geen anderen oplossing voor is.

[air2]

Dat kan alleen als dezelfde url altijd dezelfde versleutelde waarde oplevert. Het zoeken naar versleutelde waardes is in een db niet echt goed mogelijk. Je kunt wel een hash wegschrijven, maar dan moet je wel eerst het record gevonden hebben. Als je niet hashed is de versleuteling makkelijk te breken en voegt niet zoveel toe. Beter is idd wat iemand anders al suggereerde, de db als een blob opslaan en client side ontsleutelen. Maar dat zal efficiëntie kosten aan de server kant en dus duurder zijn. Het is ook moeilijker te maken en dus ook daarom duurder

[i-chat]

op zich zou dat moeten kunnen, als je de url eerst versleutelt voordat je hem naar de server stuurt.
dat betekent echter wel dat je bij iederen querie (dus iedere keer dat je een password wilt opvragen) je die url strink eerst moet versleutelen. op een pc is dat nog wel te doen. maar op een mobiel?

en hoe zit het dan als je handmatig op zoek bent naar urls. of ga je symetrische versleuting toepassen?
zodat ze maar één keer je kluis hoeven te stelen en dan alle tijd van de wereld hebben

[Gamebuster]

Of je maakt het gewoon 1 blob aan encrypted data en doet de decryptie pas in de client, welke vervolgens client-side kan zoeken, in-memory.

[Maestro.mosjuh]

Klopt - er zijn meerdere manieren om dit probleem te tackelen (waarvan jij 1 voorbeeld geeft).

Ik geef alleen aan wat een overweging van LastPass zou kunnen zijn om het niet te doen (daarmee zeg ik dus niet dat het een goede keuze is of dat er geen andere oplossingen zijn).

[hackerhater]

Je kan ze nog steeds in de database hebben staan en dat de client ze dan decrypt voor snel zoeken.

[djwice]

Als je weet wat bytes x tot y aan waarde representeren maar ze versleuteld zijn, en je weet welke encryptie algoritmes gebruikt zijn. Heb je een goede basis voor een aanval op de sleutel.
Heb je geen idee welke data bytes x tot y moeten bevatten, dan is het vele malen lastiger om de sleutel te vinden.

[Gamebuster]

Dat is volgens mij alleen van toepassing op bepaalde vormen van encryptie, anders zou schijf-encryptie nutteloos zijn (want er staat altijd voorspelbare data op een schijf)

[Reactie gewijzigd door Gamebuster op 22 juli 2024 22:17]

[Niemand_Anders]

Bij de LassPass database was de informatie slechts gedeeltelijke versleuteld zoals het wachtwoord.
Andere informatie stond als plaintext in het bestand. Dit betekend dat je niet het volledige bestand hoeft te decrypten, maar slechts een enkel wachtwoord van bijvoorbeeld een mail provider. Ook was in het bestand security gevoelige informatie leesbaar (zoals salts, iv, etc).

Het is nog steeds geen kinderspel om zo'n wachtwoord te kraken, maar met alle hints kun je wel gerichter de aanval inzetten. Als je niet weet in welke plaats ik woon, woon ik ergens in Nederland. Als je echter weet in welke dorp ik woon, is het vele malen gemakkelijk om mijn adres te achterhalen...

Recent werd ook bekend dat Bitwarden standaard een vrije lage iteration count aan houd waardoor een aanval eenvoudiger is dan het zou moeten zijn. Inmiddels is dat verbeterd en is het aantal iterations naar 600.000 (was 100.000, advies was minimaal 300.000).

Wachtwoord managers zijn een mooie tool want dit maakt het veel eenvoudiger om sterke en unieke wachtwoorden te gebruiken. Een gevaarlijke trend is dat steeds meer password managers ook MFA codes kunnen genereren. Handig, maar niet veilig want kennis en bezit is nu niet meer gescheiden. Nadeel van password managers is dat je slechts 1 wachtwoord hoeft te kraken om bij de kluis te komen. ..

[Teaclo]

Ik denk dat dat misschien zal zijn om eventueel rapporten te kunnen maken om te kijken hoeveel keer een bepaalde url voorkomt bij alle abonnees.

[ETH0.1]

Wat mij opvalt bij de microsoft authenticator app is dat je nooit een idee hebt wat je moet goedkeuren, al zou er enkel en alleen maar bij staan welke app goedkeuring vraagt zou dat al een gigantische vooruitgang zijn.

Nu weet je vaak wel waar het verzoek voor is, omdat je op je beeldscherm ziet dat je XYZ moet goedkeuren, maar voor het zelfde geld krijg je een popup te zien omdat je outlook een MFA request doet terwijl er een 2de request loopt voor toegang tot je S3 bucket

[Ootje70]

Dan nog snap ik niet waarom je als je zelf niets hebt gedaan waarvoor MFA nodig is, je alsnog de aanvraag klakkeloos goedkeurt. Het hele idee van MFA is dat je zelf inlogt, dan de vraag krijgt om in een MFA applicatie goedkeuring te verlenen voor toegang. Deze persoon kreeg nu een willekeurig verzoek en heeft dat gewoonweg goedgekeurd 🫣.

En als je de toestemming niet verleent via je start- of inlogscherm maar vanuit de app kun je wel zien voor welke account je toestemming geeft....

[Pinkys Brain]

Waarschijnlijk omdat ze scripts schrijven die taken uitvoeren die verhoogde rechten nodig hebben. Maar in plaats van de verantwoordelijke admin om de rechten te vragen voor het script kan je het ook onder je eigen account laten draaien, maar ja dan moet het inloggen.

[Ootje70]

Maar dan ben je als het goed is heel bewust bezig met het inloggen. Het grootste beveiligingsrisico is nog steeds de mens, dat blijkt maar weer.

[Pinkys Brain]

Als jij de hele dag door van die requests krijgt weet je als mens dat je daar niet meer bewust mee bezig zal zijn.

Moet gewoon bedrijfsregel zijn, MFA is alleen voor interactief gebruik. Omzijl je dat, ontslag. Op het veiligheids niveau van LastPass is al dat snel snel webdev gedoe onaanvaardbaar.

[Ootje70]

Zeker, het is een van hun grootse bedrijfsrisico's en aangezien ze voor heel veel mensen wachtwoorden en accounts beheren ook een risico met een enorme impact. Hun dienstverlening is het veilig beheren van kritische systeemgegevens van hun klanten en dan is het niet mogelijk gebleken om zo iets cruciaals niet te beveiligen via een eenvoudig proces als MFA.

[TPar]

Als je net op dat moment voor iets anders een aanvraag moet goedkeuren. Toeval maar is zeker mogelijk

[Ootje70]

Dat is waar... maar wel heel toevallig. Dat je exact op hetzelfde moment zelf wilt inloggen en dan niet via de app goedkeurt maar direct via een notificatie. En dan valt het je ook nog niet op dat je meer dan 1 aanvraag moet goedkeuren.... Het kan natuurlijk.

[robjanss]

Gelukkig wordt op dit moment number-matching authentication binnen M365 uitgerold. Hier moet je een getal dat bij je aanmelding wordt weergegeven in de app invoeren. Dit voorkomt het zomaar goedkeuren van een mfa aanvraag.

[Shamalamadindon]

Laat Microsoft nou net bezig zijn met number matching, locations en app information in the Authenticator app.

[PolarBear]

Bestaat al een tijdje trouwens, het wordt nu alleen verplicht.

[Mathijs Kok]

Ben na de hack meteen overgestapt, maar laten we wel onthouden dat er nog geen enkel bewijs is dat de passwords inderdaad ontsleuteld zijn. Voor een firma als LastPass was de hack verbijsterend maar de gevolgen zijn nog altijd beperkt.

[Shamalamadindon]

Naar mijn idee is het probleem niet iets van nu maar over 5-10 jaar wanneer de encryptie makkelijker gebroken kan worden. Je gaat dan krijgen dat er er al 5-10 jaar een dump met vaults rondgaat waarin accounts zitten waarvan het ww nooit geweizigd is.

[Cyberpuppy]

En daarom ben ik nu pro-actief maar een kleine 1500 wachtwoorden aan het wijzigen.

[Klauwhamer]

Alleen is er nog veel meer data ontvreemd, die níet versleuteld bleek.

[NeFoRcE]

Er zijn cryptowallets gekraakt middels de kraak bij LP. De versleutelde backups zijn dus daadwerkelijk gekraakt. En of het nu om 1 kraak gaat, of alles, je moet er van uit gaan dus alles.

[mugenmarco]

Saillant detail is dat de aanvaller binnen wist te komen door het masterwachtwoord van de devops-programmeur te downloaden, maar die heeft vervolgens zelf ook de multifactorauthenticatieaanvraag goedgekeurd.

ja sorry hoor maar dat is gewoon mega dom

[Risce]

Dat kun je met een beetje handigheid natuurlijk wel social engineeren.

[bzuidgeest]

Het zijn ook mensen. Die man zal wellicht aan het werk zijn geweest en gedacht dat het een van de honderd gebruikelijke verzoeken was die hij zelf had geïnitieerd.
Ik heb bedrijfsmatig ook toegang tot wachtwoord kluizen. Ik moet vele keren mfa authenticeren. 1 meer of minder zou nauwelijks opvallen op een werkdag.

MFA lijkt een oplossing, maar social issues lost het niet op. En het meeste dat hackers doen is social engineering. Gebruik maken van menselijke zwakheden.

[Creesch]

Gelukkig al enige tijd geleden overgestapt naar keepass en na het vorige nieuws het merendeel van mijn wachtwoorden voor de zekerheid aangepast. Dat was wel even een rotklus, maar sowieso de moeite waard omdat ik ook wat hele oude en onveilige wachtwoorden tegenkwam die sowieso geupdate moesten worden.

[djwice]

Als dat vóór deze tijd is https://www.cvedetails.com/cve/CVE-2022-0725/ ff je logs killen.

[AOC]

Wat moet je precies doen om dit te fixen?

[Dylan_R]

Updaten en je logs verwijderen.

edit: Laat maar is nog niet gefixed.

[Reactie gewijzigd door Dylan_R op 22 juli 2024 22:17]

[Creesch]

Ik gebruik specifiek KeePassXC, daar lijkt deze niet van toepassing op te zijn.

[CaDje]

Is het eigenlijk nog MFA als je wachtwoord en je 2FA code uit dezelfde app komen? Ik heb zelf ook Lastpass en ben nu aan het overstappen naar Bitwarden, maar heb zelf nooit voor de 2FA optie van Lastpass gekozen.

[phosporus]

Ligt eraan wat je moet gebruiken om die 2fa te krijgen? Wil die alleen unlocken met een vingerafdruk of andere biometrische waarde bijvoorbeeld.

[kaas-schaaf]

De tweede factor is het device (een bezit) de eerste een geheim (het wachtwoord). De hacker hier gebruikte het gestolen geheim en daarna sluisde de medewerker hem door omdat die niet controleerde waar de tweede stap voor was.

Als je de zelf een app gebruikt en die goed gebruikt heb je alsnog een geheim maar is dat de toegangscode tot de app en is de tweede factor nog steeds het bezit van het apparaat (het in te voeren wachtwoord is dan niet langer het echte geheim maar een transactie). Als je biometrie gebruikt daarvoor vervang je een van de factoren (het unlock geheim van de app) door een vingerafdruk of equivalent.

Edit: een otp is simpelweg een betere validatie van het bezit van het apparaat in dit geval, ik laat even in het midden hoe dat bezit aangetoond moet worden.

[Reactie gewijzigd door kaas-schaaf op 22 juli 2024 22:17]

[Frank]

Een eventuele indringer heeft nog steeds 2 factors nodig om in je account te komen. Dat verandert niet omdat beide op dezelfde plek staan opgeslagen. Met een hardware key op je vault kan het prima.

Voor veel mensen is het een kwestie van gemak. Voorheen gebruikte ik weinig 2fa omdat ik geen zin had telkens mijn telefoon erbij te pakken. Nu met Bitwarden heb ik zoveel mogelijk 2fa aan staan. Met mijn pc en telefoon als trusted devices waar de vault elke 5min op slot gaat. Een indringer moet dus 1) mijn pc kapen in dat 5min window zonder dat ik het door heb of 2) mijn wachtwoord/pin weten én fysieke toegang tot mijn woning hebben én weten waar ik mijn hardware key bewaar. Dus dat zit wel goed.

Ik zou het alleen vermijden als ik om wat voor reden dan ook een HVT ben .

[Reactie gewijzigd door Frank op 22 juli 2024 22:17]

[lenwar]

Absoluut.

De meeste ‘mfa’ oplossingen die je in een wachtwoord-app ze komen neer op TOTP (‘Google Authenticator’ en dergelijke apps).
TOTP is in principe gewoon een ‘gedeeld geheim’ dat nooit over de lijn gaat. (Beide apparaten genereren dezelfde code op basis van een sleutel en ‘de huidige tijd’)

De MFA als je een app gebruikt is effectief gebaseerd op het feit dat het op jouw apparaat staat (je telefoon/vertrouwd apparaat) en de PIN (een vingerafdruk/gelaatsscan kan eventueel ook de PIN invullen voor je) om je telefoon te deblokkeren.
Vervolgens heeft je database nog een wachtwoord. Veel mensen zullen dat wachtwoord laten invullen door de vingerafdruk of gelaatsscan van de telefoon.

Het maakt dus effectief in de praktijk niet zo veel uit of je je TOTP sleutel in dezelfde app hebt of in een andere.

Hooguit wanneer je je database synchroniseert met een cloud-oplossing, maar dan moet iemand dus zowel bij je cloud-data komen als je wachtwoord database zien te bemachtigen.


Dus in het kort: de MFA zit hem primair in de toegang tot je apparaat.

[Sm0keZ]

Toch ben ik wel blij dat ik destijds bij LastPass een onwaarschijnlijk lang master password heb gekozen. Enerzijds geeft dat wat extra tijd als er weer eens te laat over een breach wordt gecommuniceerd, maar goed, ik moet bekennen dat ik een deel van mijn (minder kritische) wachtwoorden ondertussen nog steeds een keer moet wijzigen.

[anzaya]

ik moet bekennen dat ik een deel van mijn (minder kritische) wachtwoorden ondertussen nog steeds een keer moet wijzigen.

Heb ik laatst gedaan, dag mee bezig geweest.. pffff

[burnedhardware]

Verbazingwekkend: Gezien Lastpass interessant is voor inlichtingendiensten en ATP's moet daar de beveiliging op aangepast zijn: Ik zie niet hoe BYOD en thuiswerken daar in kunnen passen voor rollen met dit soort toegang. (edit2: high-secure netwerk voor uitsluitend development/security/maintenance werk met dedicated computers voor dat werk; AWS toegang beperken tot toegang vanuit die netwerken; etc. risico van RAT/man in browser/malware/manipulatie van internetverkeer wil je zoveel mogelijk uitsluiten)

This was accomplished by targeting the DevOps engineer’s home computer and exploiting a vulnerable third-party media software package, which enabled remote code execution capability and allowed the threat actor to implant keylogger malware. The threat actor was able to capture the employee’s master password as it was entered, after the employee authenticated with MFA, and gain access to the DevOps engineer’s LastPass corporate vault.

(edit: grammatica)

[Reactie gewijzigd door burnedhardware op 22 juli 2024 22:17]