LastPass kildekodebrudd – hendelsesresponsrapport utgitt

Hvis den store historien denne måneden ser ut til å bli Ubers datainnbrudd, der en hacker angivelig var i stand til å streife vidt gjennom samkjøringsselskapets nettverk ...

..den store historien fra forrige måned var LastPass-brudd, der en angriper tilsynelatende fikk tilgang til bare én del av LastPass-nettverket, men klarte å klare seg med selskapets proprietære kildekode.

Heldigvis for Uber virket angriperen deres fast bestemt på å gjøre en stor, rask PR-sprut ved å ta skjermbilder, spre dem rikelig på nettet og håne selskapet med ropende meldinger som f.eks. UBER HAR BLITT HACKET, rett i sine egne Slack and bug bounty-fora:

Angriperen eller angriperne hos LastPass ser imidlertid ut til å ha operert mer snikende, og tilsynelatende lurt en LastPass-utvikler til å installere skadelig programvare som cyberkriminelle deretter brukte for å ta en tur inn i selskapets kildekodelager:

LastPass har nå publisert en offisiell oppfølgingsrapport på hendelsen, basert på hva den har klart å finne ut om angrepet og angriperne i etterkant av innbruddet.

Vi synes at LastPass-artikkelen er verdt å lese selv om du ikke er LastPass-bruker, fordi vi tror den er en påminnelse om at en god hendelsesresponsrapport er like nyttig for det den innrømmer at du ikke klarte å finne ut som for hva du var.

Det vi nå vet

Setningene med fet skrift nedenfor gir en oversikt over hva LastPass sier:

• Angriperen "fikk tilgang til utviklingsmiljøet ved å bruke en utvikleres kompromitterte endepunkt." Vi antar at dette skyldtes angriperen som implanterte system-snooping malware på en programmerers datamaskin.
• Trikset som ble brukt for å implantere skadelig programvare kunne ikke bestemmes. Det er skuffende, fordi å vite hvordan det siste angrepet ditt faktisk ble utført, gjør det lettere å forsikre kundene om at de reviderte prosedyrene for forebygging, deteksjon og respons sannsynligvis vil blokkere det neste gang. Mange potensielle angrepsvektorer dukker opp i tankene, inkludert: uoppdatert lokal programvare, "skygge-IT" som fører til en usikker lokal konfigurasjon, en phishing-klikkfeil, utrygge nedlastingsvaner, forræderi i kildekodens forsyningskjede som den aktuelle koderen bruker, eller et e-postvedlegg som er fanget ved en feil åpnet. Hatten av for LastPass for å innrømme det som tilsvarer en "kjent ukjent".
• Angriperen "utnyttet deres vedvarende tilgang til å etterligne utvikleren når utvikleren hadde autentisert seg med multifaktorautentisering." Vi antar at dette betyr at hackeren aldri trengte å skaffe offerets passord eller 2FA-kode, men bare brukte en angrep som stjeler informasjonskapsler, eller hentet ut utviklerens autentiseringstoken fra ekte nettverkstrafikk (eller fra RAM-en til offerets datamaskin) for å piggy-back på programmererens vanlige tilgang:

• LastPass la ikke merke til innbruddet umiddelbart, men oppdaget og utviste angriperen innen fire dager. Som vi bemerket i en nylig artikkel om risikoen ved tidsstempel-tvetydighet i systemlogger er det å kunne bestemme den nøyaktige rekkefølgen hendelser skjedde under et angrep en viktig del av hendelsesresponsen:

• LastPass holder sine utviklings- og produksjonsnettverk fysisk atskilt. Dette er en god nettsikkerhetspraksis fordi den forhindrer at et angrep på utviklingsnettverket (hvor ting uunngåelig er i en pågående tilstand av endring og eksperimentering) blir til et umiddelbart kompromiss med den offisielle programvaren som er direkte tilgjengelig for kunder og resten av virksomheten. .
• LastPass beholder ingen kundedata i utviklingsmiljøet. Igjen, dette er god praksis gitt at utviklere, som jobbnavnet antyder, generelt jobber med programvare som ennå ikke har gått gjennom en fullstendig sikkerhetsgjennomgang og kvalitetssikringsprosess. Denne separasjonen gjør det også troverdig for LastPass å hevde at ingen passordhvelvdata (som uansett ville blitt kryptert med brukernes private nøkler) kunne ha blitt avslørt, noe som er en sterkere påstand enn bare å si "vi kunne ikke finne noen bevis for at den ble avslørt." Ved å holde data fra den virkelige verden utenfor utviklingsnettverket ditt forhindrer du også at velmenende kodere utilsiktet griper data som er ment å være under regulatorisk beskyttelse og bruker dem til uoffisielle testformål.
• Selv om kildekoden ble stjålet, ble ingen uautoriserte kodeendringer etterlatt av angriperen. Vi har selvfølgelig bare LastPass sitt eget krav om å fortsette, men gitt stilen og tonen i resten av hendelsesrapporten, kan vi ikke se noen grunn til ikke å ta selskapet på ordet.
• Kildekode som flyttes fra utviklingsnettverket til produksjon "kan bare skje etter fullføring av streng kodegjennomgang, testing og valideringsprosesser". Dette gjør det troverdig for LastPass å hevde at ingen modifisert eller forgiftet kildekode ville ha nådd kunder eller resten av virksomheten, selv om angriperen hadde klart å implantere falsk kode i versjonskontrollsystemet..
• LastPass lagrer eller kjenner aldri brukernes private dekrypteringsnøkler. Med andre ord, selv om angriperen hadde sluppet unna med passorddata, ville det ha endt opp som bare så mye strimlet digitalkål. (LastPass gir også en offentlig forklaring av hvordan det sikrer passordhvelvdata mot frakoblet brudd, inkludert bruk av klientsiden PBKDF2-HMAC-SHA256 for salting-hashing-og-strekking av ditt offline-passord med 100,100 XNUMX iterasjoner, og dermed forsøk på å knekke passord veldig mye vanskeligere selv om angripere slipper unna med lokalt lagrede kopier av passordhvelvet ditt.)

Hva gjør jeg?

Vi synes det er rimelig å si at vår tidlige antakelser var riktige, og at selv om dette er en pinlig hendelse for LastPass, og kan avsløre forretningshemmeligheter som selskapet anså som en del av aksjonærverdien ...

…dette hacket kan betraktes som LastPass sitt eget problem å håndtere, fordi ingen kundepassord ble nådd, enn si knekt, i dette angrepet:

Dette angrepet, og LastPass sin egen hendelsesrapport, er også en god påminnelse om at "del og hersk", også kjent under sjargongbegrepet Null tillit, er en viktig del av moderne cyberforsvar.

Som Sophos-ekspert Chester Wisniewski forklarer i sin analyse av siste Uber-hack, det er mye mer på spill hvis kjeltringer som får tilgang til noen av nettverket ditt kan streife rundt hvor de vil i håp om å få tilgang til alle av det: