A LastPass szerint az egyik DevOps mérnökük ottoni számítógépén keresztül fértek hozzá a rendszerükhöz

Titkosítás, biztonság, privát szféra
[...]

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.

The threat actor then exported the native corporate vault entries and content of shared folders, which contained encrypted secure notes with access and decryption keys needed to access the AWS S3 LastPass production backups, other cloud-based storage resources, and some related critical database backups.

As we progress through incident response and as part of our on-going containment, eradication, and recovery activities related to the second incident, we have performed the following actions, with additional work currently being accomplished in scoping and planning:

[...]

Részletek itt.

( STP | 2023. 02. 28., k – 07:32 )

Ezek után a Dev csak annyit tudott mondani, hogy Ops.

( trey | 2023. 02. 28., k – 07:51 )

Arról, hogy az önmagában az MFA sem varázsszer.

trey @ gépház

( gabrielakos v | 2023. 02. 28., k – 08:15 )

Számoljuk meg a mondatokból kikövetkeztető "halálos bűn"-öket egyenként. 
Nem kevés van.

Gábriel Ákos

Jelen esetben az lett volna a - technikai - megoldás, ha az Ops-nak otthon két gépe van, külön VLAN-okban, átjárás nélkül, megfelelő routerrel/tűzfallal elválasztva és pornót csak a privát rendszeren néz.
Az audit jellemzően papírgyártás, én inkább belső teszteket csináltatnék.

Nyilván ezt ők is tudták, csak leszarták.

A külső audit nyilvános a cég vezetősége felé, az biztosan nem csak papír, mert azok alapján a vezetők is számon kérhetőek egy ilyen esetben. Érdekelté teszik őket hogy a finding-okat javítsák, ellenkező esetben a saját vagyonukkal felelnek egy károkozás esetén.

Nem ez a legjobban hianyzo lancszem a jogszabalyokban.

Leginkabb bizonyos bizalmi munkakoroknel (penzugy, devops, etc.) azt kene kotelezove tenni, hogy bele kelljen irni, hogy a munkavallalo egy evben az eltoltott munkaorainak pl. min 5%-at es max 10%-at auditorok kerdeseinek megvalaszolasaval es kereseinek teljesitesevel kell toltenie.

Ez vedene minden oldalt. Ha a munkaltato kerne olyat, ami kotelezo audit rovasara megy, lehetne erre mutogatni. Ha auditor ker irrealisan disruptive dolgot minimalis elmeleti elonyert, az ellen is vedene. Raadasul vegre hivatalosan is azok lennenek a felelosek az auditon valo megfelelesert, akiket amugy is bele szoktak rangtani.

Egyebkent szerintem volt security audit. Az otthoni gepevel megbuko devops member elkepzelesem szerint meg is mutatta azt a gepet, amit az irodaban szokott hasznalni (amin minden rendben is volt), es ki is pipalta, hogy semmit nem tarol masik eszkozon talan. "Elfelejtette", hogy otthon egy masik szemelyes gepen van egy masolat.

Fura egy kenyszer az audit, van hogy azokat tanitja meg hazudni, akik elotte oszintek akartak lenni...

Egy ideig dolgozatam a Logmeinnél, másik terméken. Akkoriban a Lastpass is náluk volt (igen, az első reakcióm nekem is az volt, hogy az általam ismert Lastpass devops-osok közül melyikük nyalhatta be... de aztán kiderült, hogy akiket ismertem már elmentek onnan).

Volt külső-céges audit minden évben, az egész cég összes termékére. Néha volt pentest is (azért volt vicces, mert nem szóltak nekünk róla, mi meg lecsaptuk őket :D). Sokmindenkinek vannak itt tévképzetei arról, hogy az auditor megnézi a fejlesztők laptopját meg hasonlók. Az auditnak a kliens-oldali részét értelemszerűen a céges IT csoport kapta. Kb meg kell mutatniuk, hogy vannak policy-k, amiket a munkavállalók aláírnak, van éves kötelező security meg compliance training amit minden munkavállaló elvégez, a céges gépekre policy-ből lenyomnak anti-malware/antivírus megoldást, full disk encryption meg managed anti-theft be van kapcsolva stb. Nyilván változhattak dolgok az IT-oldalon, hogy a Lastpass-t kiárusították a Logmeinből, erről már nem tudok semmit. De annyi biztos, hogy a LMI-s időkben az ilyen-fajta auditban elvárt dolgok teljesítve voltak.

Régóta vágyok én, az androidok mezonkincsére már!

hogy a LMI-s időkben az ilyen-fajta auditban elvárt dolgok teljesítve voltak.

Mit sem ér az egész, ha közben vlaaki az otthoni játszós gépről is hozzáfér a legérzékenyebb adatokhoz.

 

Az emberi oldala, hogy ha még technikailag lehetséges is, akkor sem kellene... ugye most láthatjuk miért.

A technikai oldala, hogy egyátalán nem szabadna bárhonnan (ilyen szinten) hozzáférni egy ilyen rendszerhez.

 

szerintem.

zrubi.hu

Tudnék mesélni, hogy nagy telco provider core call routing eszközeit a belső kör 3-4 ops-os embere otthon, szigorúan csak magán laptopról menedzseli azúrban, mert a corp laptopokon a powershell modulokat (is) tiltja az IT a windows 10 applocker-en keresztül, amivel ez a csapat meg napi szinten dolgoz(na).

Ha tudják h. aznap ilyen jellegű meló van, nem mennek be az irodába, hanem otthonról dolgoznak a privát laptopjukról a céges azúr instance-ban.

És ez így megy évek óta. Mert csak így lehet. Mikor egymásnak feszül a belső IT szekuriti, meg a pénzt hozó engineering.......

A cikkben a szóhasználat azt sugallja, hogy valóban a saját gépe volt, de nekem nem ennyire egyértelmű. Az LMI-s időkben érvényes policynek ez világos és megkérdőjelezhetetlen megsértése lett volna. Nem hiszem, hogy időközben lazítottak volna ezen. Ha ez lenne a helyzet, akkor én legalábbis azt várnám, hogy a Lastpass hivatalos közlemény szövege ezt nagyon alaposan kihangsúlyozná és az egyszemélyi felelősségrevonási lépésekre koncentrálna.

Nekem erős a gyanúm - bár semmi bizonyítékom nincs rá - hogy ez mégiscsak a céges laptop lehetett, csak otthonról. A szóhasználatba akár ez az értelmezés is beleférhet. Az LMI-s időkben a hivatalos policy valóban nem tiltotta teljes drákói szigorral a custom alkalmazások telepítését, bár nyilván szerepelt olyan kitétel ("gumiszabály"), hogy munkához nem kötődő privát cuccok telepítése kerülendő. (Amúgy elég szar is lett volna, ha minden brew install-hoz meg pip install-hoz IT-ticketet kellett volna nyitni... így is az anti-malware tool folyamatos szöszmötölése gyakorlatilag használhatatlan szintre belassította a brew-t).

Az arstechnica-s cikkben valamilyen belső forrásra alapozva arról beszélnek, hogy Plex volt a 3rd party media alkalmazás, amiről a közleményben szó van. A Plex-et 12 nappal a Lastpass incidens előtt nyomták fel.

Az a baj, hogy itt eléggé úgy néz ki, hogy egy nagyon is célzott támadás volt. Nyilván rá lehet húzni a devops-os illetőre a vizeslepedőt, hogy miért telepített bármilyen 3rd party alkalmazást a céges gépre. De a helyzet az, hogy ilyen jellegű támadást be lehetett volna szopni bármilyen más - céges IT-által approvolt, elvileg "trusted" vendortól származó - alkalmazáson keresztül is. (hirtelen eszembejut a Solarwinds esete...)

Régóta vágyok én, az androidok mezonkincsére már!

Amúgy elég szar is lett volna, ha minden brew install-hoz meg pip install-hoz IT-ticketet kellett volna nyitni..

Ennél sokkal szofisztikáltabb a Windows binárisfuttatás-engedélyezése: meg lehet adni, hogy milyen aláíró vagy hash esetén engedélyezed.
Feltételes elevációra is vannak eszközök (Avecto).

PIP esetén is simán lehet korlátozni hogy csak a belső remote repo érhető el, az pedig scannelve van.

De a helyzet az, hogy ilyen jellegű támadást be lehetett volna szopni bármilyen más - céges IT-által approvolt, elvileg "trusted" vendortól származó - alkalmazáson keresztül is. 

Nyilván nincs tökéletes biztonság, de itt a döntéshozók szeme előtt kellett volna lebegnie 0 - 24, hogy az egész cég IT biztonságból él és kulcsfontosságú adatokat tárol.
Ez pedig pénzbe kerül, tehát szerintem ne szolgáltassanak ingyen vagy pár dollárért, ha a profit margin nem elég ahhoz, hogy megfelelő legyen az adatok védelme.

Kérdés, mit csinálsz olyan dolgokkal, mint terraform provider-ek? ansible pluginek? Jetbrains-es IDE-k pluginjei? Ezen már mind runtime szednek le dolgokat a saját külső repojukból. A céges IT-nak _eléggé_ topon kell lennie, ha ezt mind tudja úgy támogatni, ahogy írod. Nem állítom, hogy teljesen lehetetlen, de még nem láttam ilyet. Olyat láttam, hogy a fejlesztőeszközök és technológiák reménytelenül lemaradtak a világhoz képest, a szigorú, de lépést tartani nem képes IT miatt. Meg olyat is, hogy kicsit megengedőek voltak, ezzel valamekkora risk-et bevállaltak.

A másik, hogy "alá van írva" - ha igaz az arstechnica értesülése és a Plex kliens volt az alkamazás amin keresztül bejutottak, akkor az minden bizonnyal kiváló érvényes hiteles aláírással rendelkezett.

A "scannelve van", dettó. Ha a céges gépre policy-ből lerakott anti-malware scanneren átjutottak, akkor milyen scannert képzelünk oda, ami elvileg megfogná?

Régóta vágyok én, az androidok mezonkincsére már!

Ezeket jó eséllyel csak a proxy-n és már a kliensre jutva tudod scennelni (*), de ez semmiképpen nem azt jelenti, hogy hagyni kell a francba az egészet IT biztonságot, bízva abban hogy a történet főszereplője rendelkezik belátással.

Plex-et biztosan nem olyan kibocsátó írta alá, akiben megbíznék - ez pedig talán már a Windows XP-ben lévő Software Restriction Policy-vel korlátozható volt. Sem ez, sem az Avecto nem önmagában az aláírás hitelességét ellenőrzi.

* Update: nem igaz, TerraForm Providerek is különböző minősítésű aláírássokkal vannak ellátva 

Azért vannak fokozatok a "hagyni a francba" és a teljes lezárás között.

A másik, hogy itt alapvetően két probléma van. Az egyik, hogy a konkrét alkalmazásnak nem volt indoka a gépen lennie. A másik, hogy az adott alkalmazásban volt sebezhetőség (és/vagy a vendort feltörték és valahogy ezt tudták használni ugródeszkának).

Zárhatod a szöget a gépre telepíthető alkalmazásoknál, de a munkához használt, indokoltan gépen levő dolgokkal az ugyanígy megtörténhet. Azt nem tudod az aláírásokkal kizárni.

Max. valamelyest csökkenteni tudod a klienseken levő támadási felületet, de teljesen megszüntetni nem tudod.

 

Én egyébként a másik végén fognám meg a problémát, hogy a prod környezetbe manuális belépést kellene nagyon minimumra csökkenteni. Ami csak lehet, IaC valamilyen központi CI/CD rendszerből befuttatva, a troubleshooting-ra pedig remote tracing/logging megoldások. Akkor a kliensgépre nem kerülnek le a prod secret-ek, a prod-ra "belépés" egy olyan event, ami mindenképpen indoklást igényel. Így a kliens biztonsági problémái sokkal kevésbé tudnak ilyen szintre eszkalálódni. Csak ezt megvalósítani még akkor is nehéz, ha az alkalmazásodat kezdettől fogva ezzel a szemlélettel fejleszted (a mostani melóhelyemen pl ez a felfogás, de borzasztó sok nehézség van vele).

Régóta vágyok én, az androidok mezonkincsére már!

Egy ceges laptop eseten feltetelezheto, hogy telepitve vannak ra mindenfele endpoint security cuccok. Ezek keptelenek felismerni egy keylogger jelenletet?

Inkabb magan gep lesz az.

Az ArsTechnicas forumban emliti vki, hogy a LastPassnak nincs kulon vaultja business es personal vaultra. Lehet hogy a devopsos emberunk egy kozos vaultban tarolta a ceges es magan jelszavait is, ezert hasznalta a magan geprol is...

Igen, az én verziómnak valóban ez a gyenge pontja, hogy az endpoint security toolon is át kell jutni úgy, hogy ne jelezzen be.

Bár amiket én anno olvastam (asszem Travis Ormandy-től) a víruskeresők belső működéséről... némelyik megoldás több lyukat nyitott a rendszeren, mint amennyit bezárt.

Régóta vágyok én, az androidok mezonkincsére már!

Az auditnak a kliens-oldali részét értelemszerűen a céges IT csoport kapta.

De ennek baromira nem így kellene kinéznie.
Hanem úgy hogy megkérdezi az auditor az IT csapat vezetőjét, hogyasszondja a kollégák milyen eszközökön dolgoznak?
Ha megemlíti hogy BYOD akkor rákérdeznek hogy van-e bármilyen védelem a kockázatok minimalizálására.
Ezek bekerülnek az audit report-ba, mellétéve hogy milyen kockázatot jelentenek.
Ezek után az érintett terület vezetője pedig saját fellelőségre elfogadhatja a kockázatot (jó eséllyel nem fogja), vagy tesz ellene.

Az LMI időkben a budapestiek anno nem BYOD eszközön dolgoztak (az érintett illetőről nem tudom itteni volt-e és időközben változott-e a helyzet, egy párszor gazdát cserélt a lastpass azóta). Max. a telefon lehetett BYOD, a laptop nem. De a devops-osoknak, akik vállaltak oncall-t, járt a céges telefon. Mások meg nem kaptak hozzáférést a prod rendszerhez.

Két eset lehet. Vagy az illető devops-os eléggé megsértette a szabályokat és saját eszközt használt - ha így lenne, a közlemény szerintem ezt nagyon hangsúlyosan kiemelné. Vagy valójában a céges laptopra rakott privát használatú 3rd party alkalmazást (ami az én időmben nem volt szigorúan tiltva, de azért ellenjavallt volt), amit remote felnyomtak és valahogy átjutottak a gépre telepített anti-malware scanneren is.

Régóta vágyok én, az androidok mezonkincsére már!

Vagy az illető devops-os eléggé megsértette a szabályokat és saját eszközt használt - ha így lenne, a közlemény szerintem ezt nagyon hangsúlyosan kiemelné

Nem lehet így kommunikálni, mert ebben is vezetőség felelőssége van.

( asm v | 2023. 02. 28., k – 09:40 )

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.

Ez nekem nem tiszta. Vmi nem kerek az MFA auth korul.

Az egy dolog, hogy egy keylogger megszerezte a master passwordot, de utana hogy tudta a vaultot unlockolni mas illeto, anelkul hogy ujra kellett volna MFA-zni? Vagy a LastPass letarolja a vault unlockolt masolatat a filerendszeren? Megis hogy tud egy process hozza ferni az unlockolt vaulthoz?

Egyébként hogyan férjen hozzá mondjuk egy REST API a secret-hez?

Pont arra való a - cikk szerint nem használt - conditional policy hogy meg lehessen szabni milyen bejelentkezési kísérletek esetén kötelező az MFA, hol pedig nincs kikényszerítve.

Nem azt mondom, hogy nincs ilyenre szükség, hanem csak azt, hogy akkor valójában nincs MFA. - csak a marketing slide-okon.

De mivel nem kaptunk architektúra diagramot, csak újságírói részleteket, így mélyebben ebbe belemenni nem érdemes.

 

de összességében - saját véleményem szerint - nem az említett devops vétette a legnagyobb hibát.

Várhatóan architekturális hiányosságokkal és/vagy problémákkal van teli az egész.

 

És nem, nem a LastPass az egyetlen, látom ezt én mindenhol...

 

kedvencem az az fajta szuper MFA, amben a két auth-ot ugyan az az eszköz (telefon) - vagy akár ugyan az az applikáció válaszolja meg :D

zrubi.hu

A posztmodern MFA az elso "Trust this browser"-ig tart. :)

Ja meg az alkalmazott szemelyes tulajdonaban levo okostelefonra tett authenticatorok is szerves resze, a lenyeg, hogy senki nem tud tobbet Fizika MSc-vel SMS-bol hatjegyu kodot kiolvasni a levegoben. :)

Nem így működik. Ha az MFA policy-ből be van kapcsolva, akkor be van kapcsolva. A lastpass CLI-ből is kéri, desktop appból, telefonos appból is. Nem tudok róla, hogy meg lehetne kerülni.

Szerintem itt arról van szó, hogy az MFA belépés után a kliens eszköz egy ideig "trusted" lesz, gondolom lerak valami tokent, aminek van egy szerver-oldalon enforce-olt lejárata. Ez gondolom account admin szinten konfigolható. Viszont abban biztos vagyok, hogy ebben volt bug. Egy ideig volt, amikor a lastpass CLI nagyon hosszú ideig nem kérte újra az MFA-t, ha egyszer trust-oltad. El tudom képzelni, hogy ezt a bugot éppen a mostani incidens miatt fedezték fel és javították ki.

Nyilván az MFA alapvetően arra lett kitalálva, hogy a támadó random helyről ne tudjon belépni még lopott jelszóval sem. Ha a támadó magán a kliens eszközön már benn van, akkor elég nagy kaka van. Akár van trusted token, akár nincs. Legfeljebb az utóbbi esetben a támadónak többet kell dolgoznia, hogy on the fly elkapja az MFA-val engedélyezett request-et.

Régóta vágyok én, az androidok mezonkincsére már!

Nem így működik. Ha az MFA policy-ből be van kapcsolva, akkor be van kapcsolva

Ezt én néztem be, LastPass olyan szinten nem "enterprise-grade" hogy fel sem merült bennem,
hogy ezt és nem valami normálisabb Vault szolgáltatást használnak a fejlesztési - üzemeltetési folyamatokban.

( asm v | 2023. 02. 28., k – 09:48 )

Szerkesztve: 2023. 02. 28., k – 10:56

Az is erdekes, hogy a LastPass production infra uzemeltetesehez a secreteket LastPassban taroljak. Ez egy deadlock gyanus szituacio. Vagy a LastPass client mindig tart offline masolatot a teljes vaultrol?

( zrubi v | 2023. 02. 28., k – 10:22 )

Megtalálták a "felelőst", majd valamit javítanak nagy csinnadrattával, esetleg rituálisan kivégeznek egy kecskét, és minden megy tovább.

1 hónap múlva már a kutya sem emlékszik a bakira, csak a nevükre.

Ez a tipikus forgatókönyv.

 

szerintem.

zrubi.hu

( Elbandi v | 2023. 02. 28., k – 11:17 )

 vulnerable third-party media software package, which enabled remote code execution

vajon melyik sw volt ez? vlc? mediaplayer klonok?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ha a nyomozas eredmenyeben ezt allitjak, akkor igen nagy valoszinuseggel egy ismert vulnerabilityrol van szo (talaltak jeleket arra nezve, hogy mikent tortek a gepet). Egyebkent fogalmuk se lenne arrol, hogyan kerult a keylogger oda. Vagy most sincs fogalmuk rola, csak kitalaltak ezt, hogy legyen vmi tartalma a jelentesnek. :)

( persicsb | 2023. 02. 28., k – 11:31 )

Nincs itt semmi látnivaló, mindig a leggyengébb láncszem az ember.

( ggallo | 2023. 02. 28., k – 11:44 )

Szerkesztve: 2023. 02. 28., k – 11:49

Nekem az a fura, hogy a cég által használt felhős tárolókhoz akárhonnan hozzá lehet férni ezek szerint (mert ugye nem elég az account ellopása, ott még elérés is kell, hogy legyen hol használni az ellopott accot.).

Miért nem csak a cég érintett szerverei, rendszerei férhetnek hozzá az említett felhős tárolókhoz, és akkor plusz egy faktor, hogy azokra a rendszerekre IS be kell törni a sikeres adatlopáshoz? Vagy ezt nem lehet/nem ilyen egyszerű megoldani pl. az említett AWS esetében?

Meg azt sem értem, hogy egy nem igazán olcsó, biztonsági rendszer szolgáltató cégnél miért kell a felhőt erőltetni? Miért  incsenek a kritikus adatok saját, jól védett infrán, ami nem hozzáférhető a publikus netről?

DevOpsosoknak szokott lenni "admin szintu" AWS Web Console hozzaferesuk az altaluk managelt cloudhoz, hogy tudjon troubleshootolni. Ezzel az IAM userrel hozza kell hogy ferjen az S3-ra keszitett backupokhoz, hogy tudjon restore-olni, ha kell.

VPN-en beluli source IP-re le lehet korlatozni az AWS hozzaferest. Akkor +1 VPN auth van a folyamatban...

Értem, meg persze, nyilvánvaló, hogy kell a DevOps-nak hozzáférés adminisztrációs okból. De otthonról is hozzá kell férjen? Nem lehet olyan, hogy csak a cégtől? És akkor ha VPN-en megy be, akkor még ugyan úgy be kell jutnia a céges hálóba a támadónak is, hogy onnan tovább mehessen az S3 admin felületre a lopott adatokkal. Vagy VPN-en megy be a céghez és ott is csak távoli asztalt használ. Vagy lehet biztosan még ezt fokozni úgy, hogy az effektív biztonság is növekedjen ne csak komplikáltabb legyen a hozzáférés. Bár ilyen biztonsági adatoknál én a túl komplikált hozzáférést is jobbnak tartom a kényelmes de nem biztonságos hozzáférésnél.

Meg gyakorlatilag bárhonnan hozzáfértek ezek szerint, ugyanis ha keylogger-rel loptak account adatokat, és hozzáfértek a tárolókhoz ezen adatokkal, az nekem azt jelenti, hogy nem a cég - remélhetőleg védett - infráján keresztül fértek hozzá, hanem az account adatokkal onnan, ahonnan a bűnözőknek a legkényelmesebb volt.

Feltehetoleg a csoka usere csak addig kellett, amig hozzafertek a vaultjahoz, ahol olyan AWS access keyt tarolt, amivel (MFA nelkul) barhonnan elertek az S3-at.

Egyebkent a keyloggerek a clipboard tartalmat is el tudjak lopni? Siman lehet hogy magahoz a vaulthoz se fertek hozza, csak kivartak a pillanatot, amikor a DevOpsos emberunk a vaultbol ki copy-pastezte vhova az AWS access keyt es secretet.