XZ backdoor mélyelemzés: Kinai? Izraeli? Magyar titkosszolgalat?
Vložit
- čas přidán 11. 07. 2024
- Külön kértétek, hogy legyen erről a témáról videó - s bár nem friss, de igyekszek annyira mélyen menni bele, amennyire lehetséges, így talán sok embernek tudok újat mondani akkor is, ha ez a téma esetleg már eljutott hozzá.
Ez egy nagyon komoly hátsókapu beépítési kísérlet volt és nagyon valószínű, hogy valamely titkosszolgálat munkájának eredményeként - de egyben azt is nagyon jól mutatja, hogy még egy ilyen rejtett és ennyire felépített hátsó kaput is viszonylag hamar megtalált az open source közeg.
#xz
#linux
#backdoor
#titkosszolgálat
#kémek
#hacker
#magyar
#exploit
00:00:00 Intro
00:00:45 Miről lesz szó
00:01:28 Rövid áttekintés
00:02:40 Hogyan derült ki?
00:06:27 A nyílt és zárt forrás
00:13:03 Mélyen is belemegyünk?
00:14:05 Eseménysor
00:21:44 Meddig volt titokban?
00:25:12 Hogyan érint téged?
00:26:24 Hogyan sérül az SSH vele?
00:29:23 Elrejtés oka és mikéntje
00:35:23 Működés (áttekintés)
00:50:10 Kiderülés technikai részletei
00:53:07 Mély technikai részletek
01:24:20 Hackerek valgrind javítása :-)
01:27:21 Kik állnak mögötte?
01:46:15 Collin visszatér
01:49:46 xzbot
01:53:07 Összegzés
01:54:19 Rust-Windows 10/10 sérülékenység
01:56:10 Outro - Věda a technologie
Ez olyan mintha megcéloztak volna valakit vagy valamilyen szervezetet akiről tudták, hogy használja ezt az xz-t a projektjeihez. Van egy kis stuxnet fílingje.
Azért megcéloztak ezzel mindenkit aki futtat SSH szervert, mert arra is ki volt találva külön + minden helyre, ahol a payload-ot az XZ-n átvitte valami.
De az SSH-s történet miatt ez a "célzás" kb. "sörétes gépágyú" szélességben tett nekik törhetővé mindent.
Szuper téma...na ezért sem akarom a tiszta arch-ot lecserélni... Szerintem hasznos lenne egy tűzfalas (pl.: IPfire, stb.)/ port beállítgatós tutorial video is mert sokan túlbecsülik az alapbeállításokat és magyar nyelvű content erről se nagyon van.
Szép ötlet, csak ott fenn áll az a veszély, hogy ahhoz épp nem biztos, hogy kellő mélységben értek - azért én sem értek ám mindenhez
Viszont ha már "tűzfal", akkor én sokáig (és most is, csak nem aktívan) rajongója voltam a "leválasztócsatornák" ötletének. Ez kicsit több mint tűzfal, mert hardverbe öntése a protokollnak ami átmehet - és két hálózat közt csak ez mehet át.
Anno voltak ezzel komoly tervek, de hobbiból is meg lehetne építeni és videózni például. Külön nehézség viszont mondjuk ilyenen stream-et átvinni, vagy hát ennek is vannak szintjei, hogy mennyire működne a történet.
Komoly történet. Ehhez képest fejlesztőcégek 100-asával húzzák be az openszósz csomagokat a rendszerbe mindenféle ellenőrzés nélkül. Nehogy írjon bárki saját kódot, majd lehúzzuk hozzá a csomagokat. Ha nem is hátsó kapu, de mindenféle memory leak, meg egyéb gondok jönnek be plusszban a lustaság miatt.
Hát a 100-asával behúzott történetek ennél tényleg sokkalta károsabbak - mert oké egy xz tömörítő libet tényleg ne írjon meg már mindenki, de ugye ott van a left-pad, meg isodd meg hasonló npm csomagok és az már tragikomédikus.
Továbbá amikor kellett nekem TS-hez binary heap, az npm-ből én sikeresen húztam le egy olyat.... ami nettó bugos volt... szóval inkább megírtam én magam tényleg azt is 🙂
A rendszerprogramok, kernel meg a hasonló mélyebb csomagok terén azért a kókányolás nem jellemző, ott tényleg ilyen bonyolultan lehet csak a supply chain-t támadni. Egy ilyen webes projekten viszont ehhez képest azért fényévekkel egyszerűbb a támadás is - meg hát sajnos a minőség is egy általános kókányság npm-nél is meg az egész weben. Továbbá baj az is, hogy "meddig fog majd élni a függőségem?" mert pont egy ügyfélnél direkt nem építettünk egy bugos libre - de nem csak bugos volt és akkor annyi erővel írok sajátot, de így fél év után nettó deprecated halott projekt lett - szóval vehettem volna át a rosszul szervezett kódbázisuk valami saját fork lélegeztető gépen tartásával ha esetleg használtam volna...
Én konkrétan pont ezek miatt nem is szeretem, ha van modern programnyelvekhez "csomagkezelés" - ne legyen. Ha kell egy lib dobjad be, mert így legalább kevesebb lesz a nettó felesleges projekt függőség!
@@u9vata Igen, egy legacy project azzal kezdődik, hogy a csomagokat át kell nézni, mi elavult, mit lehet újítani, ilyesmi. Zöldmezősnél is megkaptam már, hogy miért írok MVVM-re, IOC-re, egyebekre saját megoldást miért nem töltök le csomagokat. Ugyanaz a tapasztalat, hogy ezeket megtnulni, managelni pont annyi munka, ha nem több, mint megírni azt az 1% kódot ami a projecthez kell és azt legalább ismerjük és könnyen módosítjuk is. Azért lettem szoftverfejelsztő, hogy fejlesszek és nem gyári összeszerelő, aki csak bedobál mindenfélét és összerakja. Sajnos az ipar a csomagolás irányába megy, még az ilyen extrahype nyelvek is, mint a Rust erre mennek, ez van. :(
@@robertoze A JAI nem erre megy - de az én proginyelvem se akarom, hogy "csomagkezelős" legyen.
Egyébként normális operációs rendszeren a szoftverkönyvtárakra s programokra van csomagkezelő - eleve hülyeség még programon belül lényegében source-szintű copy-pastre ilyet csinálni....
A go is elég jó középút, mert a git-el egybe van vonva a történet.... Jobb ha egyszerűen nincs és nem is szoksz feleslegesen rá...
A rust-ban ez is egy negatívum számomra: mert igen.. jó pár cargo-zás és web szolgáltatásod van "valakiknek valamijétől", de ezeket szerintem jó ha nem ilyen szinten automatizáljuk, mert feleslegesen sok függősége lesz mindennek....
C++ esetén se szeretem pl. a boost-ot behúzni: az a baj, hogy sokan behúznak valamit úgy is, hogy az egészből egy 10%-nyi ha kell nekik...
Megnéztem mégegyszer ezt a videót annyira jó. És arra lettem, hogy figyelmes, hogy folyamatosan a kik csinálhatták kérdés merül fel benne, ami nyilván lényeges info, viszont annál kevesebb az info, hogy miért. Talán a targetálásból kéne kiindulni. Mi van a Fedorának és a Debiannak, ami a többinél nincs vagy annyira nem hangsúlyos?
Igen, ez egy érdekes kutatási irány és tényleg ezzel pl. szintén nem hallom, hogy foglalkoznak (magam se - mint a mellékelt ábra mutatja), pedig információt rejt minden ilyen részlet.
public static bool CompareBooleans(bool orig, bool val)
{
return AreBooleansEqual(orig, val);
}
internal static bool AreBooleansEqual(bool left, bool right)
{
if(left == right)
return false;
return true;
}
^^A mai világban kb. ilyeneket látsz production-ben az ilyen npm-szerű dolgok miatt 🙂
Vajon miért akarok menekülni windows-ról és androidról?!
Abszolút nem hozzáértőként eddig azt hittem, hogy a build az kb. annyi, hogy a megadott fájlokat töltsd le és rakd fel ebbe és ebbe a könyvtárba, DONE. Ehhez képest annyira bonyolult, hogy ilyen trezéseket is el lehet benne simán rejteni, mert annyira bonyolult...
Egyébként ez egy jogos mentalitás, hogy kívülről ilyen egyszerű dolgot feltételezel. Ez a történet, hogy a build egy ennyire bonyolult dolog legyen, mint manapság, egy rossz irány - így alakult. Most általánosságban a szoftverfejlesztésről beszélek, nem csak az XZ projektről persze - sőt! Az XZ build még sokkal egyszerűbb és lean-ebb, mint a legtöbb "üzleti" fejlesztés build lépése, ha hozzá adjuk, hogy azoknál mennyi olyan dolgot pakolnak bele, amiről azt se tudják mi az és csak valami random helyről letöltődik és valami random infra összegyúrja.
A JonBlow részben ezért is csinálta a nyelvét úgy, hogy véletlenül se ilyen makefile-os, autoconf-os, meg hasonlós történetekkel menjen a build - hanem magával a programnyelvvel legyen megírva. Továbbá a suckless-es emberek (meg jómagam is) ezért használnak mindenféle cmake, autoconf és sok-sok mágia helyettt minél minimálisabb build-eket, sima make-fájlokkal például és nagyon egyszerű projekt kialakítással.
De dolgoztam olyan projekten, ahol a build lépés 37 percig tartott - és az egy elég minimális build volt. Ennél rosszabbakat is hallani, de az 5-6 perc kb. "átlagosan gyakori" sajnos, szóval a kirívó példákon túl olyannal nagyon sokkal találkozol... A legviccesebbek azok a projektek, ahol gyávaszkript van (tehát eleve egy dinamikusan típusos nyelv) ellenben mégis 10-percekig tart a build 🙂- sikeresen összeegyeztették a két világ HÁTRÁNYAIT olyankor, mert minden hibád fele futási idejű lesz, cserébe mégis van build is 🙂
@@u9vata Csak innentől kezdve dosztmindegy mit töltenek fel pullrequestbe a fejlesztők, és bárki nézegetheti a módosításokat, ha a build után kb. teljesen más lesz a progi. Feltöltöd a githubra a kis progidat az alapján úgy néz ki mintha egy ócska tömörítő progi lenne, aztán mikor buildeled kiderül, hogy ezzel a progival lehet indítani az atombombát. Mint az orosz IKEA: tök mindegy milyen bútort veszel, miután otthon összeszerelted biztos T-34-est kapsz. :D Ez alapján ez a rendszer eléggé felülvizsgálatra szorul.
Szia. A valgrind megfelelője windows-on egy gdb nevezetű dolog. Alapból benne van a minGW toolchainben.
A gdb nem a valgrind megfelelője. Linuxon is van gdb és sokat használom - sőt szerintem külön lesz "GDB: 5 dolog amit nem tudsz róla de hasznos debuggoláshoz" jellegű videó a közeljövőben.
A valgrind egy ettől független dolog - tényleg memória problémák (pl. leak) keresgélésére van kifejezetten. Egy hasonló tool van a clang-ban is, de ott pedig a build részeként és address sanitizer-nek nevezik és még ez a kettő is csak kiegészíti egymást.
Lehet hogy egy nagyvállalat műve.
Igen, jogos felvetés. Manapság ez egyáltalán nem elképzelhetetlen, sem mondjuk, hogy egy NGO vagy hasonló ilyeneket csinálgasson. Vannak rá példák amikor mindenféle random dolgok technikailag kb. "magántitkosszolgálat"-ként működnek és az ipari kémkedésre is rá lehet menni akár ennyire is - például az egyik a másik alól kilopná a cloud-ból a marketingre használt user adatait stb.
Valahogy mégsem ilyennek tűnik most ez a történet, de nyilván nem zárható ki teljesen. Mondjuk a timestamp-ek alapján úgy néz ki legalábbis, hogy az adott figurák akik érintettnek tűntek egy időzónából játszották ezt nem ilyen globális "ki itt van ki meg ott" téren. De ugye ilyenkor még elvileg lehet hogy nagyvállalat ezzel foglalkozó szűkebb kört mondjuk csak egy adott székhelyén tart fenn és nem globálisan, de valahogy kevéssé valószínű szerintem azért.
De a felvetés jogosnak mondható ;-)