Fórumok
Azért ez nem egy egyszerű hacker akció...
https://index.hu/techtud/2020/12/15/peldatlan_kibertamadas_erte_az_egyesult_allamok_intezmenyeit/
Azért ez nem egy egyszerű hacker akció...
https://index.hu/techtud/2020/12/15/peldatlan_kibertamadas_erte_az_egyesult_allamok_intezmenyeit/
Hozzászólások
Mindenük érintett: https://www.solarwinds.com/securityadvisory
Viszont ha valaki egy ilyen rendszert üzemeltet akkor érdemes minimum egy zárt hálózatba helyezni ahová csak az illetékesek léphetnek, esetleg egy PAM mögé tenni.
De ennek a rendszernek pont az a lényege, hogy védjen, nem? Milyen álságos lenne eladni úgy, hogy véd, aztán meg otthon nem használni és betenni plusz védelmeket? :)
https://iotguru.cloud
Johet a klasszikus kerdes?
Ki orzi az orzoket?
:-)
"Kiemelték továbbá, hogy Oroszország aktívan támogatja a kétoldalú nemzetközi kiberbűnözés elleni egyezmények létrejöttét."
Meg is van a kulcsmondat!
A támadók célpontválasztása tökéletesen érthető. Ha egy internetes biztonsággal foglalkozó céghez törnek be, akkor annak összes ügyfelét is megkapják bónuszként. Saccra katonai hírszerzés lehetett az elsődleges cél.
Hasonló történt már egy pár éve. Ha jól rémlik, akkor egy nagyon bonyolult betörés sorozat első lépése volt, hogy bejutottak az RSA-hoz, az utolsó pedig az, hogy tévvezérléssel letettek egy amerikai robotrepülőt Irán területén.
Persze, írják is. Feltörve a biztonsági rendszert, kiskaput telepítettek az ügyfelekhez, és így a hivatalok belső levelezését meg tudták figyelni.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Nem ertem. Ha nem hasznaltak Huawei 5G eszkozoket, hogy nemzetbiztonsagilag biztonsagban legyenek, akkor most hogyhogy bajban vannak? Nem kene biztonsagban lenniuk? :-)
Experts are reviewing their notes to find old examples of substandard security at the company. Security researcher Vinoth Kumar told Reuters that, last year, he alerted the company that anyone could access SolarWinds’ update server by using the password “solarwinds123”
https://www.reuters.com/article/global-cyber-solarwinds/hackers-at-center-of-sprawling-spy-campaign-turned-solarwinds-dominance-against-it-idUKL1N2IV1UQ
Én meg admin/adminnal próbálkoztam akkor ezért nem ment....
"12345678" rulez.
HUP te Zsiga !
... azért aki dll-eken alapuló szoftvert használ hálózatvédelemre az meg is érdemli, szerintem.
Gábriel Ákos
Csak 425 cég a Fortune 500ból... https://www.theverge.com/2020/12/15/22176053/solarwinds-hack-client-lis…
Érdekes írás az USA felkészületlenségéről: https://www.theverge.com/2020/12/14/22174429/solarwinds-hack-russia-cis…
Asztakurva.
https://iotguru.cloud
Azertb..meg engem felnegyelnenek egy ilyenert, utana meg ledaralnanak kutyaeledelnek. Jogosan. Mondjuk en nem is vagyok szekurittyekszpert, meg mindenben-is-expert.
Ehhez nem kellett volna az oroszhekker vonalat eloszedni, egy altalanos iskolas is bejut ezen ket ppt prezentacio kozott.
Error: nmcli terminated by signal Félbeszakítás (2)
Valahogy nehéz elhinnem. A legóvatlanabb helyeken sem fogadnak el ilyen jelszót.
óóó, hát én a leg patinásabb(nak tűnő) helyeken is láttam már ilyen szintű "default" admin jelszavakat.
amit persze csak install/teszt/ideiglenes használatra szántak... csak aztán úgymaradt.
zrubi.hu
Ja, én is léptem már be véletlenül bankban root:root123 névvel jelszóval DEV helyett PRD-re. Aztán meg én voltam a köcsög, hogy szóltam, meg hogy észrevettem.
https://iotguru.cloud
Látod, megtanulhattad, hogy máskor ne szólj érte ;) Jóvanazúgy!
Tudod, az volt a félelmetes, hogy tudták, sőt. És azért voltam köcsög, mert ezek után minden szerverre generált jelszót kellett használniuk.
Mondjuk abból a szempontból érthető volt, hogy például a /etc/hosts fájlok változása úgy ment le, hogy a humán droid belépett root felhasználóval, kézzel átírta, elmentette és kilépett. Onnan tudtam meg a folyamatot, hogy a build szerverünk egyszer csak nem működött, megnéztem mi történt és hát el volt gépelve a hosts fájlban az IP cím meg volt egy root login abban az időben. Nyilván jóval nehezebb és lassabb ez a folyamat százvalamennyi gépnél, ha minden szerveren más a root jelszó... az meg gyenge próbálkozás, hogy szeparált hálózatban vannak, ha a amúgy teljes IT rálát arra a hálózatra... mondjuk több mint 10 éve volt.
https://iotguru.cloud
Mondjuk én több, mint 10 éve se engedtem jelszavas root belépést a céges szerverekre, hanem ssh kulccsal lépett be mindenki a saját felhasználójaként, aztán sudo-val futtatott azt, ami engedélyezve volt (és persze voltak olyanok, akik számára minden engedélyezve volt).
Persze az is igaz, hogy ez nem bank volt, szóval...
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
"és persze voltak olyanok, akik számára minden engedélyezve volt"
Elmagyaráznád, hogy ha egy user hozzáférése ALL, mégis miben különbözik attól, ha root felhasználó jelentkezik be?
Erre valaki mindjart ugy fog valaszolni, hogy "jaj, de az audit-szempontok igy, meg az audit-szempontok ugy", amit en is tobbszor megkpatam hasonlo esetben, es ami szempontok a leheto legkevesbe erdekelnek.
Pedig általában ennyi: tudod ki volt.
https://iotguru.cloud
Igen, pontosan erre a tartalmu valaszra utaltam.
Ha nem tudod a root user login nevét, akkor nehezebb dolga van annak, aki szótár alapon próbálkozik.
Ha egyszerű a root jelszó és nincs monitoring arra, hogy valaki próbálkozik, akkor teljesen mindegy, ott amúgy is a szitán csak egy lyuk.
https://iotguru.cloud
Leginkább abban, hogy az sshd konfigurációban a permitrootlogin az false.
Az sshd logokból látszott, hogy ki mikor lépett be (ez jóval több információ, mint azt látni, hogy root lépett be 42 alkalommal).
Emellett a sudo úgy volt beállítva, hogy logolta a kiadott parancsokat, így ha valami megváltozott, vissza lehetett nézni, hogy mikor és ki változtatta meg, és meg lehetett kérdezni, hogy miért.
Mielőtt beleköttök, hogy ez nem biztonságos, meg aki mindent tud az a logokat is törölni tudja, ez mind igaz, de ezek az emberek azért kaptak sudo jogot mert megbízott bennük a cég. Nem tőlük próbálta a cég megvédeni saját magát, hanem azoktól, akik ssh-n keresztül brute forece módon próbálták a root jelszót kitalálni.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Jelszóházirend. Igy sikerult. :)
Error: nmcli terminated by signal Félbeszakítás (2)
Transzparens, atjarhato kozigazgatas, LVL999
Error: nmcli terminated by signal Félbeszakítás (2)
Ha én mondjuk egy Debian csomagot telepítek, vagy letöltök valami weboldalról egy bináris csomagot, akkor a telepítés előtt történik egy automatikus vagy kézi hash ellenőrzés.
Egy ilyen cégnél meg csak kicserélték a binárisokat és ez sehol nem bukott ki?
Nem gyenge.
Vagy nem tudom, a fejlesztői gépeket és a build szervereket törték meg és az eredeti forrást változtatták és abból készítettek egy hivatalos build-et a hackerek?
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
és abból készítettek egy hivatalos build-et
mivel az update serverrol szedtek le a binarist oda meg normalis helyen nem kezzel masolgatnak file-okat, igy eleg valoszinu..bar a jelszohazirendbol kiindulva barmi is elkepzelheto :)
És a hash ellenőrzése gondolod, hogy megvéd téged bármitől is, ami nem pistike-szintű?
Itt, ebben a történetben sem a solarwinds123 jelszón van a hangsúly, hanem a központi elosztón keresztüli támadáson.
Gondolod, hogy egy igazán szofisztikált támadás a linuxok esetében nem erre épülne? Hogy nem átlátszó módon a binárisokat fogják megváltoztatni, hanem már a fejlesztés folyamatában teljesen legitim kódot gyártanak le mondjuk egy beépített/megvásárolt fejlesztővel?
Nyilván itt nem a 13 éves moszkvai hülyegyerek próbálkozásaira kell gondolni, hanem mondjuk egy-egy nagyhataloméra.
Egy ilyen manőver mindenképp megéri a befektetést, elég csak azt számításba venni, hogy hányan töltik le az adott “teljesen” “biztonságos” szoftvert csak például egy free, hivatalos debian repón keresztül.
Igen, úgy gondolom, hogy sokmindentől megvéd.
Úgy tudom, hogy nem könnyű hash ütközést találni. Ezért alapul kb. minden digitális aláírás hash készítésen.
Ha annyira egyszerű lenne bárki nem pistike-szintűnek egyező hash-t találnia, akkor senki se használna online bankot vagy bármi online vásárlást például.
Természetesen nem mindentől, de ha egy akármilyen támadó felnyomja az ftp szervert és kicseréli a binárisokat, akkor az kibukik.
A védelem mindig arról szól (kellene szóljon), hogy a támadó dolgát tegyük nehezebbé.
Egyszerű jelszó, régi ismerten kihasználható szoftver használata, az ügyfeleknek megosztott binárisok nem ellenőrzése az mind olyan dolog, ami könnyűvé teszi a támadó dolgát. Ha mindenhol mindent megnehezítenek, akkor sem lesz lehetetlen, de amikor már titkosszolgálati eszközöket kell a helyszínen alkalmazni, az már egy teljesen más kategóriájú dolog. (És ha már ott tartunk, hogy a KGB jön és elrabolja a release build engineer gyerekét, az már nem az a szint, ami ellen céges szinten szoktak védekezni).
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
A hash-t a bináris mellől szeded amúgy? Ha változik a kulcs, akkor utánanézel, hogy miért változott?
https://iotguru.cloud
Attól függ, miről beszélünk.
A Debian telepítésnél ugye az apt ellenőrzi a csomagok digitális aláírását, az aláíráshoz használt kulcsok pedig a laptopomra telepítve vannak. Időnként van keyring update, de elég ritka. Nem szoktam utánanézni, hogy miért változott.
Ha letöltök valahonnan egy programot / csomagot, akkor jellemzően a weboldalukon van kint a hash, és valami fájl szerverről töltöm le a csomagot. Ha a weboldalon valaki esetleg átírja a hash-t, akkor erről nem fogok tudni.
De persze most légyszi ne gyertek azzal, hogy hát ez így nem biztonságos, mert én magánemberként a magán laptopomra nem követelem meg azt a biztonságot, amit mondjuk egy államtitkokat kezelő cég egy kritikus hálózati infrastrúktúra védelmi megoldástól meg kell, hogy követeljen.
Szerintem kb. a Debian megoldása lehetne esetleg a követendő példa, csak egy kicsit biztonságosabban: legyen egy aláíró kulcs, amit mondjuk több jelszóval lehet aláírásra rávenni a fejlesztő cégnél, az összes kliensnek adják oda pendrive-on, az aláíró kulcs publikus részét, és mellé papíron a kulcs ujjlenyomatát. A kliensnél lévő kulcsot ne frissítse automatikusan a rendszer, ne kerüljenek a keyringre új kulcsok, stb.
Telepítéskor vagy csomag letöltéskor meg legyen automatikus ellenőrzés, plusz ha valahol olyan az igény, akkor legyen lehetőség kézi ellenőrzésre is telepítés előtt.
Ez viszonylag könnyen megoldható. Ha meg a KGB már a fejlesztő cég 3 kulcs pozícióban lévő emberét megzsarolta / megvette, és azok együttműködnek velük, akkor már úgyis mindegy, ott már nem a hekkerek fogják beletenni a hátsó bejáratot a kódba :-)
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
A keyring update honnan jön?
https://iotguru.cloud
A keyring csomagként a disztribúció része. Ugyanúgy alá van írva digitálisan, mint a többi csomag. Ha változott, akkor az új verziót a már korábban feltett régi keyringen lévő valamelyik kulccsal valaki aláírta.
Jellemzően nagy verzióváltáskor szokott változni a tartalma.
Pl, az én gépemen most ezek a verziók érhetőek el:
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Tehát, ha a Debian szervereket törik fel - mint a mellékelt ábra mutatja, akkor semmit nem véd a hash.
https://iotguru.cloud
OK, nem tudom követni a gondolatmenetet, túl késő van.
Szóval feltörted a Debian szervereit. Az összeset (bizonyára nem kell az összes, de a példa kedvéért miért ne). Beletetted a saját kulcsodat a keyring fájlba, készítettél a hivatalos build szerveren ezzel egy új csomagot, adtál neki egy új verziószámot, feltöltötted az új keyringet, a release fájlban átírtad, hogy a keyring aktuális verziója 2020-12-31, ennek az érvényes hash-e X.
OK. Most alá kellene írnod a release fájlt az x darab érvényes kulcs egyikével. Ezt hogyan csinálod meg?
Vagy ha valami teljesen másra gondoltál, akkor légyszi írd le szájbarágósan, mert már nem fog az agyam.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Aludj többet. :D
Nem kell az összeset, elég azt, ahol a csomagok és az aláírások készülnek. A többi innen át fogja venni a preparált csomagokat.
Onnan indultunk ugye, hogy bejutottak a SolarWinds rendszereibe és preparált update csomagok mentek ki a nagyvilágba:
https://iotguru.cloud
OK, de most még mindig nem látom, hogy a rendszerbe bejutás és a preparált update csomagok elkészítése után hogyan tudod digitálisan aláírni, hogy az apt elfogadja a te általad feltett verziókat. (Persze itt most feltételezésekkel élek, mert valójában nem tudom, hogy a Debian rendszerében pl. hogyan történik egy csomag frissítéskor az új verzió aláírása).
Ez ugye a Debian része, amiről az utolsó fél tucat hozzászólásban beszélgettünk.
A SolarWinds nem tudom, hogy jön ide, ők nem a Debian rendszerét használják, hanem úgy tűnik, valami rendes ellenőrzés nélküli modellt, amiben nincs manuális aláírási lépés.
Ha arról akarsz gondolatkísérletet folytatni, hogy hogyan lehetne a SolarWinds rendszerét (vagy egy hasonló cég rendszerét) biztonságosabban megoldani, akkor én pont azt írtam, hogy a Debian rendszeréhez hasonló rendszerből ki lehetne indulni, de direkt biztonságosabbra kellene elkészíteni, mert ugye a Debian esetében nem a biztonságra mentek rá. Nem mondom, hogy a fent megálmodott megoldásom tökéletes lenne, szívesen dumálok arról is, csak most épp nem tiszta, hogy te a háromból melyikről próbálsz beszélgetni.
Ez a hozzászólásod: https://hup.hu/comment/2568216#comment-2568216 akkor a Debianról szólt, vagy az általam megálmodott rendszerről? Mert én úgy válaszoltam végig, hogy a Debianról beszéltem.
A megálmodott rendszerben nincs normális keyring update, nem jön sehonnan. A szerződéskötéskor megkapott kulcsok vannak. Ha valamiért új kulcsot akar a cég elkezdeni használni, akkor azt majd kitalálják, hogy lehet biztonságosan megoldani. Most csak bedobok ide egy hasraütéses első ötletet: ha a régi kulcs korrumpálódott, akár azért mert a KGB elrabolta az egyik aláíró gyerekét, akár azért, mert kiderült, hogy az X titkosítás vagy hash képzés mégsem annyira jó, mint gondoltuk, esetleg az új gépek már túl hamar végeznének vele, akkor a régi kulcsot visszavonják, ezt minden kliens automatán megtudja. Ezután új kulcs készül, és az account manager majd felhívja egyesével az ügyfeleket, és egyeztetnek, hogy hogyan lehetne átadni nekik bizonságosan. Pl. elmegy érte a felelős a szoftver cég központjába és személyesen átveszi, aztán ellenőrzik, hogy tényleg azt kapta-e, amit kellett kapnia.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Az egész téma a SolarWinds-ről szól, hogy bejuttak a rendszereikbe, ahol preparált update csomagokat készítettek és ezek jutottak el már a SolarWinds klienseihez.
A Debian rendszere pont ilyen sérülékeny, ha a csomagkészítés és aláírás folyamatához hozzáférnek illetéktelenek, tehát hiába ellenőrzöd a hash-t, az stimmelni fog... ha kapsz új kulcsot, az is stimmelni fog.
https://iotguru.cloud
Igen, de te a Debian-ra kérdeztél rá. Az, hogy a Debian hogyan csinálja a disztribúciójában az miért fontos? Vagy a SolarWinds Debian-t használ és a Debian szerverek feltörésével jutottak be hozzájuk?
Ezért is mondtam, hogy ha én javasolnék egy rendszert, akkor az nem úgy működne, mint ahogy a Debian működik.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
A Debian-t te hoztad be, gondoltam, vélhetően azért hoztad be a SolarWinds build és update szerverét érintő feltöréssel kapcsolatban - amiről a téma szól, mert úgy gondoltad, hogy ha a SolarWinds úgy oldotta volna meg, ahogy a Debian, akkor nem lett volna probléma... én csak leírtam, hogy semmit se segített volna, mert hiába nézel össze hash-t, ha a build és update szerver kompromittálódott.
De ezt már többen és többször is leírtuk.
https://iotguru.cloud
Közben a NISZ-nél reCaptcha integrátort keresnek.. Valahol mélyen vicces ez az ország. Gondolom egy egész osztály volt a tesztelésre. :D
Kanada is elesett...