Încălcarea codului sursă LastPass – a fost lansat raportul de răspuns la incident

Dacă marea poveste a acestei luni pare să fie Încălcarea datelor Uber, unde un hacker ar fi putut să circule pe scară largă prin rețeaua companiei de transport în comun...

..mare poveste de luna trecută a fost Încălcarea LastPass, în care un atacator se pare că a avut acces la doar o parte a rețelei LastPass, dar a reușit să scape cu codul sursă proprietar al companiei.

Din fericire pentru Uber, atacatorul lor părea hotărât să facă o mare explozie de PR prin capturi de ecran, răspândindu-le în mod generos online și batjocorind compania cu mesaje strigăte precum UBER a fost piratat, chiar în propriile forumuri Slack și bug bounty:

Atacatorul sau atacatorii de la LastPass, totuși, par să fi funcționat mai ascuns, aparent păcălind un dezvoltator LastPass să instaleze programe malware pe care infractorii cibernetici l-au folosit apoi pentru a ajunge la depozitul de cod sursă al companiei:

LastPass a publicat acum un raport oficial de urmărire asupra incidentului, pe baza a ceea ce a reușit să-și dea seama despre atac și atacatori în urma intruziunii.

Credem că articolul LastPass merită citit chiar dacă nu sunteți utilizator LastPass, deoarece credem că este un memento că un raport bun de răspuns la incident este la fel de util pentru ceea ce admite că nu ați putut să vă dați seama, precum și pentru ceea ce ați fost.

Ceea ce știm acum

Propozițiile cu caractere aldine de mai jos oferă o schiță a ceea ce spune LastPass:

• Atacatorul „a obținut acces la mediul de dezvoltare folosind punctul final compromis al unui dezvoltator.” Presupunem că acest lucru s-a datorat atacatorului care a implantat programe malware care furnizează sistem pe computerul unui programator.
• Trucul folosit pentru a implanta malware-ul nu a putut fi determinat. Este dezamăgitor, deoarece cunoașterea modului în care a fost efectuat de fapt ultimul tău atac facilitează asigurarea clienților că procedurile revizuite de prevenire, detectare și răspuns probabil îl vor bloca data viitoare. Îmi vin în minte mulți vectori potențiali de atac, inclusiv: software local nepatchat, „umbră IT” care duce la o configurație locală nesigură, o gafă de phishing prin clicuri, obiceiuri de descărcare nesigure, trădare în lanțul de aprovizionare a codului sursă pe care se bazează codificatorul în cauză, sau un atașament de e-mail cu capcană deschisă din greșeală. Jos pălăria pentru LastPass pentru că a recunoscut ceea ce înseamnă un „cunoscut necunoscut”.
• Atacatorul „și-au folosit accesul persistent pentru a uzurpa identitatea dezvoltatorului odată ce dezvoltatorul s-a autentificat cu succes folosind autentificarea cu mai mulți factori.” Presupunem că acest lucru înseamnă că hackerul nu a avut niciodată nevoie să obțină parola victimei sau codul 2FA, ci pur și simplu a folosit a atac de furt de cookie-uri, sau a extras jetonul de autentificare al dezvoltatorului din traficul de rețea autentic (sau din memoria RAM a computerului victimei) pentru a-și asigura accesul obișnuit al programatorului:

• LastPass nu a observat imediat intruziunea, dar a detectat și a expulzat atacatorul în patru zile. După cum am observat într-un articol recent despre riscurile ambiguitatea marcajului de timp în jurnalele de sistem, posibilitatea de a determina ordinea precisă în care au avut loc evenimentele în timpul unui atac este o parte vitală a răspunsului la incident:

• LastPass își păstrează rețelele de dezvoltare și producție separate fizic. Aceasta este o practică bună de securitate cibernetică, deoarece împiedică un atac asupra rețelei de dezvoltare (unde lucrurile sunt inevitabil într-o stare continuă de schimbare și experimentare) să se transforme într-un compromis imediat al software-ului oficial care este direct disponibil clienților și restului afacerii. .
• LastPass nu păstrează date despre clienți în mediul său de dezvoltare. Din nou, aceasta este o bună practică, având în vedere că dezvoltatorii, după cum sugerează și numele postului, lucrează în general la software care nu a trecut încă printr-un proces complet de revizuire a securității și de asigurare a calității. Această separare face, de asemenea, credibil pentru LastPass să susțină că nu ar fi putut fi expuse nicio dată din seiful parolelor (care oricum ar fi fost criptate cu cheile private ale utilizatorilor), ceea ce este o afirmație mai puternică decât a spune pur și simplu „nu am putut găsi nicio dovadă că a fost expus.” Păstrarea datelor din lumea reală în afara rețelei dvs. de dezvoltare împiedică, de asemenea, codificatorii bine intenționați să preia din greșeală date care sunt menite să fie protejate de reglementare și să le folosească în scopuri de testare neoficială.
• Deși codul sursă a fost furat, atacatorul nu a lăsat nicio modificare neautorizată a codului. Desigur, avem doar pretenția LastPass de a continua, dar având în vedere stilul și tonul restului raportului de incident, nu vedem niciun motiv să nu credem compania pe cuvânt.
• Codul sursă trece de la rețeaua de dezvoltare în producție „se poate întâmpla numai după finalizarea proceselor riguroase de revizuire, testare și validare a codului”. Acest lucru face credibil pentru LastPass să susțină că niciun cod sursă modificat sau otrăvit nu ar fi ajuns la clienți sau la restul companiei, chiar dacă atacatorul reușise să implanteze cod necinstiți in sistemul de control al versiunilor...
• LastPass nu stochează și nici măcar nu cunoaște cheile private de decriptare ale utilizatorilor săi. Cu alte cuvinte, chiar dacă atacatorul ar fi fugit cu datele parolei, ar fi ajuns să fie doar atât de mult varză digitală mărunțită. (LastPass oferă, de asemenea, un explicație publică despre modul în care protejează datele seifului de parole împotriva spargerii offline, inclusiv prin utilizarea PBKDF2-HMAC-SHA256 la nivel de client pentru sărare-hashing-și extinderea parolei offline cu 100,100 de iterații, făcând astfel încercări de spargere a parolei mult mai greu chiar dacă atacatorii reușesc cu copii stocate local ale seifului de parole.)

Ce să fac?

Credem că este rezonabil să spunem că nostru ipotezele timpurii au fost corecte, și că, deși acesta este un incident jenant pentru LastPass și ar putea dezvălui secrete comerciale pe care compania le-a considerat parte din valoarea sa pentru acționari...

… acest hack poate fi considerat ca fiind problema proprie a LastPass de rezolvat, deoarece nu au fost atinse parole de client, darămite sparte, în acest atac:

Acest atac și propriul raport al incidentului LastPass sunt, de asemenea, un bun memento că „împărțiți și cuceriți”, cunoscut și sub termenul jargon. Încredere zero, este o parte importantă a apărării cibernetice contemporane.

După cum explică expertul Sophos Chester Wisniewski în analiza sa asupra Hack recent Uber, este mult mai mult în joc dacă escrocii care au acces la unele rețelei dvs. pot circula oriunde doresc, în speranța de a avea acces toate din aceasta: