LastPass kildekodebrud – hændelsesresponsrapport udgivet

Hvis den store historie i denne måned ser ud til at være Ubers databrud, hvor en hacker angiveligt var i stand til at roame bredt gennem samkørselsfirmaets netværk...

..den store historie fra sidste måned var LastPass brud, hvor en angriber tilsyneladende fik adgang til kun én del af LastPass-netværket, men var i stand til at klare sig med virksomhedens proprietære kildekode.

Heldigvis for Uber virkede deres angriber fast besluttet på at lave et stort, hurtigt PR-splash ved at snuppe skærmbilleder, sprede dem bredt online og håne virksomheden med råbende beskeder som f.eks. UBER ER BLEVET HACKET, lige i sine egne Slack og bug bounty-fora:

Angriberen eller angriberne hos LastPass ser dog ud til at have opereret mere snigende og tilsyneladende narret en LastPass-udvikler til at installere malware, som cyberkriminelle derefter brugte til at køre ind i virksomhedens kildekodelager:

LastPass har nu udgivet en officiel opfølgningsrapport på hændelsen ud fra, hvad den har kunnet finde ud af om angrebet og angriberne i kølvandet på indtrængen.

Vi synes, at LastPass-artiklen er værd at læse, selvom du ikke er LastPass-bruger, fordi vi synes, det er en påmindelse om, at en god hændelsesrapport er lige så nyttig for det, den indrømmer, at du ikke var i stand til at finde ud af, som for, hvad du var.

Hvad vi nu ved

De fed sætninger nedenfor giver en oversigt over, hvad LastPass siger:

• Angriberen "fået adgang til udviklingsmiljøet ved hjælp af en udviklers kompromitterede slutpunkt." Vi antager, at dette skyldtes, at angriberen implanterede system-snooping malware på en programmørs computer.
• Tricket, der blev brugt til at implantere malwaren, kunne ikke bestemmes. Det er skuffende, for at vide, hvordan dit sidste angreb rent faktisk blev udført, gør det nemmere at forsikre kunderne om, at dine reviderede forebyggelses-, detektions- og reaktionsprocedurer sandsynligvis blokerer det næste gang. Mange potentielle angrebsvektorer dukker op, herunder: upatchet lokal software, "skygge-IT", der fører til en usikker lokal konfiguration, en phishing-klik-bommert, usikre downloadvaner, forræderi i kildekodens forsyningskæde, som den pågældende koder stoler på, eller en vedhæftet fil i en e-mail, der er blevet åbnet ved en fejl. Hatten af ​​for LastPass for at indrømme, hvad der svarer til en "kendt ukendt".
• Angriberen "brugte deres vedvarende adgang til at efterligne udvikleren, når udvikleren havde succesfuldt autentificeret ved hjælp af multifaktorgodkendelse." Vi antager, at dette betyder, at hackeren aldrig behøvede at erhverve ofrets adgangskode eller 2FA-kode, men blot brugte en cookie-stjælende angreb, eller udtrak udviklerens godkendelsestoken fra ægte netværkstrafik (eller fra RAM'en på ofrets computer) for at piggy-back på programmørens sædvanlige adgang:

• LastPass bemærkede ikke indtrængen med det samme, men opdagede og udviste angriberen inden for fire dage. Som vi bemærkede i en nylig artikel om risiciene ved tidsstempel tvetydighed i systemlogfiler er det en vital del af hændelsens reaktion at være i stand til at bestemme den præcise rækkefølge, som hændelser fandt sted under et angreb:

• LastPass holder sit udviklings- og produktionsnetværk fysisk adskilt. Dette er en god cybersikkerhedspraksis, fordi den forhindrer et angreb på udviklingsnetværket (hvor tingene uundgåeligt er i en løbende tilstand af forandring og eksperimentering) i at blive til et øjeblikkeligt kompromittering af den officielle software, der er direkte tilgængelig for kunder og resten af ​​virksomheden. .
• LastPass opbevarer ingen kundedata i sit udviklingsmiljø. Igen er dette god praksis i betragtning af, at udviklere, som jobnavnet antyder, generelt arbejder på software, der endnu ikke har gennemgået en fuldstændig sikkerhedsgennemgang og kvalitetssikringsproces. Denne adskillelse gør det også troværdigt for LastPass at hævde, at ingen adgangskodehvælvingsdata (som alligevel ville være blevet krypteret med brugernes private nøgler) kunne være blevet afsløret, hvilket er en stærkere påstand end blot at sige "vi kunne ikke finde beviser for, at det blev afsløret." Ved at holde data fra den virkelige verden ude af dit udviklingsnetværk forhindrer du også velmenende kodere i utilsigtet at få fat i data, der er beregnet til at være under regulatorisk beskyttelse, og bruge dem til uofficielle testformål.
• Selvom kildekoden blev stjålet, blev ingen uautoriserede kodeændringer efterladt af angriberen. Vi har selvfølgelig kun LastPass's eget krav om at fortsætte, men givet stilen og tonen i resten af ​​hændelsesrapporten, kan vi ikke se nogen grund til ikke at tage virksomheden på ordet.
• Kildekode, der flytter fra udviklingsnetværket til produktion "kan kun ske efter afslutningen af ​​streng kodegennemgang, testning og valideringsprocesser". Dette gør det troværdigt for LastPass at hævde, at ingen ændret eller forgiftet kildekode ville have nået kunder eller resten af ​​virksomheden, også selvom angriberen havde formået at implantere useriøs kode i versionskontrolsystemet..
• LastPass gemmer eller kender aldrig sine brugeres private dekrypteringsnøgler. Med andre ord, selvom angriberen var kommet af sted med adgangskodedata, ville det være endt som bare så meget strimlet digitalkål. (LastPass giver også en offentlig forklaring af, hvordan det sikrer adgangskodehvælvingsdata mod offline-cracking, herunder at bruge klientsiden PBKDF2-HMAC-SHA256 til at salte-hashing-og-strække din offline adgangskode med 100,100 iterationer, hvilket gør forsøg på at knække adgangskoden meget sværere, selvom angribere slipper med lokalt gemte kopier af din adgangskodeboks.)

Hvad skal jeg gøre?

Vi synes, det er rimeligt at sige, at vores tidlige antagelser var korrekte, og at selvom dette er en pinlig hændelse for LastPass, og kan afsløre forretningshemmeligheder, som virksomheden betragtede som en del af dets aktionærværdi...

…dette hack kan opfattes som LastPass' eget problem at håndtere, fordi ingen kundeadgangskoder blev nået, endsige knækket, i dette angreb:

Dette angreb og LastPass egen hændelsesrapport er også en god påmindelse om, at "del og hersk", også kendt under jargonbegrebet Nul tillid, er en vigtig del af nutidigt cyberforsvar.

Som Sophos-ekspert Chester Wisniewski forklarer i sin analyse af seneste Uber-hack, der er meget mere på spil, hvis skurke, der får adgang til nogle af dit netværk kan roame rundt, hvor end de vil i håbet om at få adgang til alle af det: