"Súlyos kibertámadás érte a világ egyik legnagyobb elektronikai gyártóját, 10 milliárd a tét"

HUP cikkturkáló

https://m.hvg.hu/tudomany/20201208_kibertamadas_zsarolovirus_foxconn_me…

  • 1466 megtekintés

( martonmiklos v | 2020. 12. 08., k – 21:24 )

Bárcsak leakelnének némi kapcsrajzot meg boardvie-tw.

( Toma_ | 2020. 12. 09., sze – 02:24 )

"10-20 TB-nyi biztonsági mentést pedig már le is töröltek"

 

Ööööööö... Mit? :D

"Nem az SMB-vel van a gond, hanem a feleslegesen tág jogosultságokkal és a fájlműveletek naplózásának hiányával."  -> azert ez igaz mindenre ha szarul van beallitva. 

SMB-t is lehet szabalyozni, + NTFS permission-nal egeszen pontosan megmondani, hogy ki mit tehet. 

Naplozni is tud, csak gyozze valami a feldolgozast... 

Ha napi szinten több TB adatot mentesz, akkor általában valami adatbázis tárolja, hogy mi hova van mentve.

Ha bukod az adatbázist, vagy csak egy részét, akkor bukod a mentett adatokat. Sok sikert egy multiplexelt szalagos mentés adatbázis nélküli visszaállításához, ahol általában egyidejűleg több kliensről beérkező streamet terít szét a rendszer több drive-ra. Ha meg encryptelve is volt a mentés, akkor pláne. Mondjuk biztonsagi mentéseket mostanában inkább diszkre rakják ( VTL), jellemzően szalagra inkább archiválás megy, de backup adatbázis nélkül az is csak egy halom bit.

Nyilván a backup adatbázisról is van több mentés, esetleg georedundáns replikáció, de ha valaki tudja mire utazik, akkor egyszerűbb dolog a backup rendszert komprommitálni, mint ténylegesen bezűzni mondjuk az offsite tárolt szalagokat.

A mentegetőzést értem, de ha így van megvalósítva, akkor az nem jó. A rendszer akkor jó, ha az offline backup bizonyíthatóan helyes, és megvan a kidolgozott stratégia a visszaállásra abban az esetben is, ha az összes online gép kompromittálódik egyszerre.

A napi szinten több TB adatot szerintem úgy kell érteni, hogy ennek nagyrésze statikus, csak a diffet kell menteni. Az meg jóval kevesebb. A mentést pedig úgy kell megcsinálni, hogy vagy az adat önleíró legyen, és végigpörgetve újraépíthető legyen az adatbázis, vagy pedig az adatbázisnak is kell hogy legyen offline backupja. Ha csak online backup van, akkor nincs backup, hiszen egyetlen incidens letörölhet mindent, mielőtt észbe kapunk.

Na nem mondom, hogy ez egyszerű, de elvileg így kellene működnie, és ha nem így működik, akkor valami nem jó.

Nem mentegetek senkit, csak láttam már jó pár nagy méretű  (értsd ezres nagyságrendű node-ra méretezett) mentési rendszert.

Ha admin userrel hozzáférnek egy mentési rendszerhez, akkor baxhatod. Ha elég idő van rá, végleg törölni lehet bizonyos adatokat.

Egy foxxconn méretű gyárban a változó adat is több tucat TB lehet naponta.  Gyártói rendszerekben mérési, minőségbiztosítási stb adatok irdatlan mennyiségben tudnak keletkezni.

Szép is jó az önleíró mentés elmélete, csak a gyakorlatban nem állja meg a helyét egy enterprise kategóriás mentési rendszerben.
Nem véletlen, hogy a backup adatbázist nagyon védeni kell - de ha megfelelő jogosultsággal szándékosan komprommitálja valaki, akkor az ellen nincs védelem.

Egy ilyen rendszerbe folyamatosan jönnek be a mentési adatok. Napi 1-2 vaultba  kirakott adatbázis mentés esetén is bukod legalább az utolsó vaultba rakás óta befolyt adatállományt.

Értem én, hogy én az elmélet oldaláról közelítettem meg, te padig a gyakorlat oldaláról. De akkor is fenntartom, hogy elvben létezik jó megoldás, és el is lehet érni. Ha a mai szabvány rendszerek nem ilyenek, akkor még van hová fejleszteni ezeket.

Azt azért elismerem, hogy én a partról kiabálok be, mert nem ez a szakterületem :-). De azért valamennyit kell foglalkoznom a kérdéskörrel mint felhasználó. Szerintem az ideális az volna, ha az egész munkafolyamat a biztonsági mentés szempontjából is meg volna tervezve. Például simán lehet ésszerűsíteni, hogy egyáltalán mennyi adatot kell tárolni, vagy azt is hogy eleve diff-ekben jöjjön ki a mentendő adat. Ha mondjuk diffelhető formátumban tároljuk a dokumentumokat, akkor sokkal olcsóbb lesz a backup is. De ezek a szempontok már tényleg messzre vezetnek...

egy nagyobb gyárban, a gyártási folyamat összetettségének függvényében automatikusan keletkeznek brutál mennyiségben adatok a gyártás folyamatán. Különféle, a gyártási láncba beépített mérési pontok által generált adatok. A gyártást, sori automatikát vezérlő rendszerek által generált működési adatok, adaítbázisok tranzakciós logjai, a kapcsolódó üzleti rendszerek analitikai adatai, stb.

Csak a "diff" napi szinten több TB egy ilyen helyen.

Sőt, továbbmegyek, ha megáll a mentés, leállhat a gyártás:  mondjuk egy vezérlési rendszer adatbázis tranzakciós logjait az éles szerver korlátozott ideig tudja tárolni. Logrotate nem értelmezett ilyen esetekben. A tranzakciós logok  folyamatosan keletkeznek. Ha ezt a mentő rendszer nem menti és nem törli folyamatosan a tranzakciós logokat, akkor X idő után megáll az adatbázis. Sok ilyen rendszer van egy nagyobb környezetben.

Ha leáll a mentési rendszered, nincs idő végig olvasni a petabyte nagyságerndű tárolt adatot- vagy visszaálltíasz belőle annyit amennyit tudsz baromi gyorsan és bevállalod, hogy buktál pár órányi adatot, vagy áll a gyár napokig, ami  sokkal többe kerül.

Admin joggal 3 perc alatt törölni lehet az online db mentéseket, utána db drop.

Ha nincs vaultolt db mentésed, akkor kuka az összes mentett adatod, mert db. nélkül pusztán, az adatot tároló szalagok alapján nem lehet viszaállítani semmit a legtöbb enterprise mentési rendszerben.

Erről volt szó, nem arról, hogy db mentést hogy állítasz vissza. Nyilván van header minden szalagon, sőt, sok esetben a db mentés a tape library fix slotjában van tárolva - már amennyiben tape lib van, és nem diskpool, vagy VTL.

"A rendszer akkor jó, ha az offline backup bizonyíthatóan helyes, "
 

Szépen lassan lock-olja a virus a fájlokat, nem változtat a fájlnéven, sem a kiterjesztésen.

Van 1 TB-nyi, sok apró fájlból álló napi mentésed.

Mond meg, hogy mikori az utolsó használható változata X fájlnak és ezt csináld meg egymillió fájl esetén.

Az ember elkezdi az utolsó snapshottól visszafele egyesével leellenőrizni a fájlokat; ameddig a vizsgált fájl az aktuális snapshotban nem kinyitható (nem plaintext, nem valid PNG, DOC, whatever), addig megy visszafelé.
Nyilván ez baromi sok idő lesz.

Oldschool Computer - http://oscomp.hu

Izgi... Tényleg megoldhatatlannak tűnik.

Azért utólag lehet okoskodni:

Ha valamennyire szemantikus a mentés például tudhatom hogy ha valami log, akkor az nem változhat meg utólag. Tehát ha mentésről mentésre változás van, akkor az jelezheti a hibát. Illetve logokat eleve lehet úgy menteni, hogy mindig csak az újakat tesszük fel a polcra. Azon persze nem segít, ha hónapokon keresztül betitkosított fájlokat teszünk el.

Ha géppel elemezhető formátumú a mentés - azaz nem titkosított eleve, akkor algoritmus meg tudja mondani utólag is, hogy mikortól van betitkosítva. Mondjuk hogy txt fájlokban krix-krax van, vagy többnyire ASCII karakterek.

Jon a rohadtsok adat a kliensekrol, ezt a backup szerver szepen kiirja a szalagra (VTL aztan szalag mert igy gyorsabb) majd szepen rogziti a sajat adatbazisaban, hogy melyik kliens mikori savesetje mit tartalmazott, es hogy melyik szalagra kerult.

Aztan ez a gep is kitolja sajat magat szalagra, nyilvan lezart adatbazissal, igy az adatbazis is rajta lesz a szalagon.

Ha beut a crach, akkor bosz karomkodasok kozott lehet a libraryban keresgelni, hogy melyiken van a mento gep utolso mentese, ez nem 5 perc, de nem problema, hiszen oraberben fizetnek. :-)

Ha megvan a mento gep mentese, akkor onnan vissza lehet allitani, es maris minden megvan. 

( dotnetlinux | 2020. 12. 09., sze – 07:08 )

Eddig országok (királyai) haboruztak egymás ellen olajert, tengerert. Most a háború is magánkézbe került (mint az urhajozas) és gerillacsapatok lőnek egymásra zsarolovirussal. A haboru struktúrája más, nem is biztos hogy az állami védelmi szervezetek ilyenkor kötelesek bevatkozni. 

( bacsa81 | 2020. 12. 10., cs – 13:33 )

Vajon ők is kiszerveztek az IT-t Indiába? Azok a 3rd party service providerek szoktak ludasak lenni.

( Raynes v | 2020. 12. 10., cs – 18:22 )

Nem, ahogy olvasom, semmilyen kibertámadás nem volt, csak a szokásos forgatókönyv játszódott le, titkársági vagy háeres mancikáéknak betákolták az SMB v1-es megosztást, mert az kell, mint a falat kenyér, és beszoptak egy sztenderd ransomware-t, amiért most szívnak. Nagyon helyes, tanulnak belőle, következőleg karbantartják az IT struktúrát, hogy ne legyenek a rendszereik átjáróház.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A gyártósorokat nem kell online SMB megosztásra tenni. Szóval valószínűbb, hogy mégis HR-es mancikáknak kellett, esetleg valami öltönyös-nyakkendős mánágernek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( answ | 2020. 12. 11., p – 16:13 )

Szerkesztve: 2020. 12. 11., p – 16:19

Ha ilyen idióták voltak, akkor fizessék meg a tanulópénzt! Mondjuk részletekben fizetve még kockázat sincsen nagyon.
SMB1 nem magyarázat erre, mert simán lehet tűzfalazni úgy, hogy zárt rendszer legyen. Ráadásul mindegyik rendszernek teljesen külön megosztást is lehet csinálni (amelyek akár külön virtualizált OS-ekben is futhatnak) és onnan is azonnal ki lehet venni a feltöltött fájlt így mindig üres gyakorlatilag a megosztás (ez utóbbit én magam is alkalmaztam, amikor egy legacy alkalmazás oda mentett). Nem beszélve arról, hogy nem próbálták időnként visszaállítani a mentést? Vagy nem volt sentinel fájl, amelynek írása (jobb esetben már olvasása is) csinált volna egy lock down-t vagy legalább egy nyomorult warning-ot? Én is csak azt tudom elképzelni, hogy kiszervezték IT-t valahova Indiába, mint ahogy USA-ban is szokás.