LastPassi lähtekoodi rikkumine – intsidentidele reageerimise aruanne avaldati

Kui selle kuu suur lugu näib olevat Uberi andmetega seotud rikkumine, kus häkker sai väidetavalt läbi sõidujagamisettevõtte võrgu laialdaselt ringi rännata…

..eelmise kuu suur lugu oli LastPassi rikkumine, kus ründajal oli ilmselt juurdepääs ainult ühele LastPassi võrgu osale, kuid suutis ettevõtte varalise lähtekoodiga hakkama saada.

Uberi õnneks näis nende ründaja olevat otsustanud teha suure ja kiire suhtekorralduse, haarates ekraanipilte, levitades neid rohkelt veebis ja mõnitades ettevõtet karjuvate sõnumitega, nagu UBER ON HÄKITUD, otse oma Slacki ja bug bounty foorumites:

Kuid LastPassi ründaja või ründajad näivad olevat tegutsenud vargasemalt, pettes LastPassi arendajat ilmselt pahavara installima, mida küberkurjategijad seejärel ettevõtte lähtekoodihoidlasse püüdsid:

LastPass on nüüd avaldanud ametlik järelaruanne intsidendi kohta selle põhjal, mida ta on suutnud välja selgitada rünnaku ja ründajate kohta pärast sissetungi.

Arvame, et LastPassi artiklit tasub lugeda isegi siis, kui te ei ole LastPassi kasutaja, sest me arvame, et see on meeldetuletus, et hea intsidendi vastuse aruanne on sama kasulik selle jaoks, mis tunnistab, et te ei suutnud aru saada, kui ka selle jaoks, mida te olite.

Mida me nüüd teame

Allpool olevad paksus kirjas laused annavad ülevaate sellest, mida LastPass ütleb:

• Ründaja "sai juurdepääsu [d]arenduskeskkonnale, kasutades arendaja ohustatud lõpp-punkti." Eeldame, et selle põhjuseks oli ründaja, kes implanteeris programmeerija arvutisse süsteemi nuhkiva pahavara.
• Pahavara implanteerimiseks kasutatud nippi ei õnnestunud kindlaks teha. See on pettumus, sest teades, kuidas teie viimane rünnak tegelikult sooritati, on lihtsam kliente veenda, et teie muudetud ennetus-, avastamis- ja reageerimisprotseduurid tõenäoliselt blokeerivad selle järgmisel korral. Meenuvad paljud potentsiaalsed ründevektorid, sealhulgas: paigatamata kohalik tarkvara, ebaturvalise kohaliku konfiguratsioonini viiv "vari IT", andmepüügi klõpsamisviga, ebaturvalised allalaadimisharjumused, reetmine lähtekoodi tarneahelas, millele asjaomane kodeerija tugineb, või eksikombel avatud meilimanus. Müts maha LastPassi ees, et ta tunnistas, mis on „teada tundmatu”.
• Ründaja "kasutasid oma püsivat juurdepääsu arendaja esinemiseks, kui arendaja oli mitmefaktorilise autentimise abil edukalt autentinud." Eeldame, et see tähendab, et häkker ei pidanud kunagi hankima ohvri parooli või 2FA-koodi, vaid kasutas lihtsalt a küpsiste varastamise rünnakvõi ekstraheeris arendaja autentimisloa ehtsast võrguliiklusest (või ohvri arvuti RAM-ist), et programmeerija tavapärast juurdepääsu tagasi saada:

• LastPass ei märganud sissetungi kohe, kuid tuvastas ja saatis ründaja nelja päeva jooksul välja. Nagu märkisime hiljutises artiklis riskide kohta ajatempli mitmetähenduslikkus Süsteemilogides on intsidentidele reageerimise oluline osa võime määrata rünnaku ajal sündmuste täpne järjekord:

• LastPass hoiab oma arendus- ja tootmisvõrgud füüsiliselt lahus. See on hea küberturvalisuse tava, kuna see hoiab ära arendusvõrgu vastu suunatud rünnaku (kus asjad on paratamatult pidevas muutumises ja katsetamises) muutumast klientidele ja ülejäänud ettevõttele vahetult kättesaadava ametliku tarkvara koheseks kompromissiks. .
• LastPass ei säilita oma arenduskeskkonnas kliendiandmeid. Jällegi on see hea tava, arvestades, et arendajad töötavad, nagu ametinimetus viitab, üldiselt tarkvara kallal, mis peab veel läbima täieliku turbeülevaatuse ja kvaliteedi tagamise protsessi. See eraldamine muudab usutavaks ka LastPassi väite, et paroolihoidla andmeid (mis oleks nagunii kasutajate privaatvõtmetega krüptitud) poleks saanud paljastada, mis on tugevam väide kui lihtsalt öelda, et "me ei leidnud tõendeid selle kohta, et see paljastati." Reaalmaailma andmete oma arendusvõrgust eemal hoidmine takistab ka heade kavatsustega kodeerijatel kogemata haarata andmeid, mis on mõeldud regulatiivse kaitse alla kuuluma, ja kasutamast neid mitteametlikel testimistel.
• Kuigi lähtekood varastati, ei jätnud ründaja maha ühtegi volitamata koodimuudatust. Loomulikult on meil jätkata vaid LastPassi enda väitega, kuid ülejäänud juhtumiaruande stiili ja tooni arvestades ei näe me põhjust, miks ettevõtet oma sõna mitte pidada.
• Lähtekoodi liikumine arendusvõrgust tootmisse "saab juhtuda alles pärast range koodiülevaatuse, testimise ja valideerimise protsesside lõpetamist". See muudab usutavaks, et LastPass väidab, et muudetud või mürgitatud lähtekood poleks jõudnud klientideni ega ülejäänud ettevõtteni, isegi kui ründajal oleks õnnestunud petukoodi implanteerida versioonihaldussüsteemis..
• LastPass ei salvesta ega tea isegi kunagi oma kasutajate privaatseid dekrüpteerimisvõtmeid. Teisisõnu, isegi siis, kui ründaja on parooliandmetega eksinud, oleks see lõppenud lihtsalt nii palju hakitud digikapsast. (LastPass pakub ka a avalik selgitus kuidas see kaitseb paroolihoidla andmeid võrguühenduseta krakkimise eest, sealhulgas kliendipoolse PBKDF2-HMAC-SHA256 kasutamine võrguühenduseta parooli soolamiseks, räsimiseks ja venitamiseks 100,100 XNUMX iteratsiooniga, muutes seeläbi parooli murdmise katsed palju raskem isegi siis, kui ründajad kasutavad teie paroolihoidlast kohapeal talletatud koopiaid.)

Mida teha?

Arvame, et on mõistlik öelda, et meie esimesed oletused olid õigedja et kuigi see on LastPassi jaoks piinlik juhtum ja võib paljastada ärisaladusi, mida ettevõte pidas osaks oma aktsionäride väärtusest…

…seda häkkimist võib pidada LastPassi enda probleemiks, millega tuleb tegeleda, sest selle rünnaku käigus ei jõutud klientide paroolideni, rääkimata nende murdmisest:

See rünnak ja LastPassi enda juhtumiaruanne on ka hea meeldetuletus, et "jaga ja valluta", mida tuntakse ka žargooni terminina Null usaldus, on tänapäeva küberkaitse oluline osa.

Nagu Sophose ekspert Chester Wisniewski oma analüüsis selgitab hiljutine Uberi häkkimine, on palju rohkem kaalul, kui kelmid, kes pääsevad juurde mõned saavad teie võrgust juurdepääsu lootuses liikuda kõikjal, kus neile meeldib kõik sellest: