Feltörték a Fedora és a Red Hat egyes szervereit

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

A múlt heti figyelmeztető és helyzetjelentés után a Fedora projekt ismét jelentést adott ki az infrastruktúráját érintő "problémáról". A mai helyzetjelentésből kiderül, hogy illetéktelenek fértek hozzá a Fedora projekt egyes szervereihez - beleértve a Fedora csomagok aláírására használt gépet is. A projekt megtette a szükséges lépéseket (leállították a szolgáltatásokat, újratelepítették a gépeket, megváltoztatták az aláíró kulcsokat) a probléma elhárításához. A Fedora szerverei mellett egyes Red Hat gépek is érintettek, ezért a Red Hat egy figyelmeztetőt adott ki a Red Hat Enterprise Linux rendszereket futtató ügyfelei részére. A bejelentés elolvasható itt.

( gyorsrizs | 2008. 08. 22., p – 16:23 )

Tankérem neménvótam.
_______________________________________________________________
"Good news everyone! Those asinine morons who canceled us were themselves fired for incompotence!" Hubert J. Farnsworth

( Frantique v | 2008. 08. 22., p – 17:02 )

Ki is kapcsoltam a frissítéseket, amint jelezték, hogy a szerverek körül gond van. Azóta szorgalmasan figyelem a szerverek kimenő forgalmát, de nincs kompromittálásra vonatkozó jel. Ajánlom mindenkinek, hogy újratelepítés előtt figyelje kívülről a forgalmat, ha gyanús mozgást érzékel, húzza újra a rendszert.
--
Coding for fun. ;)

Es szerinted mi az, hogy "manualisan szignoz"? Parker tollal, vagy mi? Nem, erre szamitogepet hasznalnak, a folyamat inputja az alairatlan csomag, es az alairo titkos kulcsa, utobbihoz kell meg egy jelszo is, az output az alairt csomag. A kulcsot valahol tarolni kell, egy szamitogepen taroljak. A kulcsot a tamadok megszereztek, Fedoraek szerint a jelszot nem.

Jah, az MS-nél, ahol van pénz 3 milliárd dollárt költeni a források auditálására, lehet van arra is egy kevés, hogy megfelelő tanúsítvány-alapú hitelesítő rendszert alakítsanak ki, ahol az aláíró céleszközök nem az internetről elérhető Binux Optikai Rendszereket jelenti.

Mondhatnám azt, hogy egy teljesen más elveket valló rétegnél, ahol a forráskódnak effektíve nincs értéke és az adott elvek atyja régebben szabad bejárást adott a saját rendszereibe bárki számára, ott nyilván nehezebb egy ilyen biztonsági intézkedésnek a jelentőségét elfogadtatni... de inkább nem mondok ilyet, csak azt, hogy remélhetőleg tanulnak az esetből. ;P

De akkor mar nem trusted a dolog (abbol csinalod a hasht, amibol akarod, es igy eleg a gep kompromittalasa egy backdoorozott sshd-hez), egyebkent a frissitesek afaik nem diff-ek, hanem az egesz package-bol uj verzio jon (meghat release-kor amugyis ala kell irni az osszeset).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ha csak az egyiket cseréli le, az nem kevés???
Nem azért "kell" módosítanom a hasht, mert módosítottam a csomagot (mármint, ha gonosz vagyok és nem akarok lebukni, viszont a backdoort telepíteni akarom csillió+1 gépre)???
Ha nem stimmel a hash, nem fog települni a stuff, akkor viszont nincs meg a backdoor...
Szerintem...

Ez annyibol jobb, hogy igy tudsz akarmire signature-t szerezni, es nem kell kivarni valami jol backdoorozhato dolog frissiteset (persze azt ugyesen meg kell oldani, hogy attol meg az eredetileg alairando stuffra is jusson, de szvsz ez nem lehetetlen).

szerk: ez egy szinttel feljebb ment volna

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Kérdés, hogy van-e erre szükség? Mi van, ha egyszerűen csak egy backdoor csomagot átnevez a támadó az aláírandó frissítésre? Nem feltétlenül kell neki, hogy egy valódi OpenSSH legyen az RPM-ben, elég csak egy saját bináris és a hozzá való információ, hogy a "frissítés" annyiból áll, hogy azt a binárist le kell futtatnia az updaternek... ;)

Kis olvasnivaló:

http://www.awe.com/mark/blog/200701300906.html

There was no off-the-shelf solution available for hardware-based RPM key management, so we developed one internally ourselves. We used nCipher nShield hardware security modules (FIPS 140-2 validated) for the key protection along with custom patches I developed to interface RPM/GNUpg to the unit. At the same time we also introduced an extra layer of abstraction to the signing software, so we can authorize signers using their existing internal kerberos credentials.

--
SELinux, Xen, RHEL, Fedora: http://sys-admin.hu

nem kell winupdate servereket haxolni ahoz, hogy megfertozd a win gepeket, eleg csak a msn-en terjedo trojanokra gondolni, legalabb 10 ismerosom van most blokkolva emiatt contact listben. naiv emberek (szandekosan nem linkreugro hulyet irtam!) mindig lesznek.
linuxos boxokat eleg nehez ilyen mod megfertozni, ugyanis ismeretlen eredetu scripteket (foleg rootkent) nemhinnem, hogy barki is lefuttatna.

Ebből a szempontból a Linux se jobb. Windowsnál is meg lehet oldani, hogy ne írja már be magát mindenhova, akkor maximum csak ott tud matatni, amit a felhasználó is elér. Azt meg Linux alatt is ki lehet vitelezni, könnyen.

Gondolod, hogy az összes linuxos gépen blokkolva van minden nem szükséges kimenő forgalom? Simán lehetne linuxos zombi gépek hadát létrehozni. Elég, ha mondjuk beírja magát a ~/.bash_profile -be, ~/.xinitrc-be, vagy akármibe.

Sőt, akár azt se bonyolult megcsinálni, hogy csinál egy ~/.akarmi -t, oda kipakol egy teljesen saját /bin-t és átírja a PATH -t, hogy onnan szedegesse a dolgokat.

"Simán lehetne linuxos zombi gépek hadát létrehozni."

Sot, nem csak hogy lehetne, de aktivan teszik is, csak nem igy, hanem (jellemzoen linuxot futtato) webszervereken talalhato mindenfele php-s izek bugjait kihasznalva.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( Hunger | 2008. 08. 22., p – 18:16 )

Érdemes elolvasni Dave utalását arra, hogy mennyire hülyének nézés esete forog fenn már megint...

* Szar söprése * szőnyeg alá * magasfokon * Red Hat módra *

Öröm olvasni, hogy az infrastruktúrát messziről sem ismerők milyen "értékes" hozzászólásokkal színezik a hírt. Néhány észrevétel:

1. Egyelőre külsősök nem tudják, pontosan mi történt. Kár kombinálni.
2. A Fedora és a Red Hat rendszere merőben más, teljesen függetlenek egymástól - igaz, van arra példa, hogy egy fc csomag egy az egyben bekerül a RHEL-be (nyilván más alárással).
3. Csúnya eset, nem vitás. Ez van, legközelebb jobban kell figyelni.
4. Nagyon komoly release process van a Red Hatnél, nem úgy van, hogy a bal oldalon bedobott forrás automatikusan jobb oldalon kijön az RHN-en. Ezért sem sikerült a rossz RPM-et a Red Hat Networkre kitolni.
5. A Fedora rendszere nyitott, viszonylag könnyen lehet accountot szerezni, ráadásul most módosítottak a policyn is.

Nem látok sehol semmilyen hülyének nézést.

--
SELinux, Xen, RHEL, Fedora: http://sys-admin.hu

Akkor olvasd el mégegyszer, hogy mit írt Dave... Nem kell ismerni az infrastruktúrát ahhoz, hogy az ember észrevegye az ellentmondást a leírt mondatok között.

A történetet egyébként tovább szinesíti, hogy közben kiderítettem, 2007 óta már (az általam is felvetett) külön céleszközzel hitelesítenek, RHEL5-nek ezért is más a keyid, mint RHEL4-nek.

Hogy akkor miért kell kulcsot cserélniük? Na az továbbra is jó kérdés... Sajnos a technikai információkat nélkülöző maszatolásukból nem lehet kideríteni.

Szerk.: közben látom Mark J Cox 2007-es blog posztjában is benne van.

Nem látom az összefüggést...

1. Hogyan jutottak át a Fedora hálozatából a Red Hat rendszerébe, ha annyira el van szeparálva a kettő?

2. Ha HW crypto eszközzel vannak aláírva Red Hat-nél az RPM-ek, akkor hogyan tudtak aláírni backdooros OpenSSH csomagokat? (Nem egyet-kettőt, hanem kiba* sokat... minimum 43-at, ugye)

3. Ha a privát kulcsot egy olyan céleszköz tárolja, amelyből nem lehet kiolvasni azt könnyedén, akkor miért van szükség a kulcscserére?

4. Hogyan tudják megoldani biztonságosan a kulcscserét az ügyfelek gépein, ha azok még a régi kompromitáltnak vélt kulcsokat tartalmazzák?

5. Miért nem publikálják, hogy milyen hibát kihasználva jutottak be a rendszerükbe, hogyan szereztek privilégiumot és milyen rootkitet telepítettek a támadók, hogy az ügyfelek és más disztribúció készítők is ellenőrízni tudják a saját szervereiket?

nem lehet, hogy egyszerűen csak arról van szó, hogy egy felgöngyölítés alatt levő ügyet nem igen értelmes dolog "felesleges" kockázatnak kitenni azáltal, hogy olyan részleteket is kiadnak, amik a nyomozgatást hátráltatják? gyilkosságok nyomozásánál se sokkal többet mondanak arról, hogy jutott be pl. a trónterembe a gyilkos. ott a tény. az emberek meg úgy is gyártják a legendáikat arról, amit nem ismernek. ld. a téma hozzászólásait is itt... miért kell kulcsokat cserélni? miért ne? baj, ha inkább óvatosak? baj, ha esetleg csak félre akarják vezetni azt/azokat, akik komprommitálták a rendszereiket? stb. stb... nem kell egyből rettentő nagy hülyeséget feltételezni azért a rh-ról se ;)

--
xterm

olyan részleteket is kiadnak, amik a nyomozgatást hátráltatják

jah, nehogy megtudják a brekkerek, hogy hogyan is brekkeltek ők be ;)

hogy jutott be pl. a trónterembe a gyilkos

OMG :)

miért kell kulcsokat cserélni? miért ne? baj, ha inkább óvatosak?

Gondolom a remek hasonlatok után, akkor ez azt is jelenti, hogy ha ellopják a sörödet a kocsmában, akkor kulcsot és zárat is cserélsz otthon, mert miért ne, óvatos vagy. ;)

Mellesleg, ha valaki kiolvassa a privát kulcsot távolról egy FIPS 140-2 eszközből akkor elég durva a helyzet, szóval én még direkt hagynám is a régit, mert ha egy ilyen eset bebizonyosodik, akkor a Red Hat/Fedora kis csomagjai azok, amelyek miatt a legkevésbé kell aggódni...

baj, ha esetleg csak félre akarják vezetni azt/azokat, akik komprommitálták a rendszereiket? stb. stb... nem kell egyből rettentő nagy hülyeséget feltételezni azért a rh-ról se ;)

Persze persze, sőt, valójában nem is történt semmiféle feltörés, csak kiváncsiak, hogy milyen ötletekkel jönnek elő az emberek egy ilyen hír hallatán!

szerinted a cinizmusod mire jó? ha csak kötekedni akarsz, akkor rajta, van erre elég poszt. mivel nehezedre eshet belegondolni, hogy nem csak összeesküvéseket lehet gyártani a rh (nálad) mindenképpen nyilván hülyébb és a legfőképpen a biztonságról lényegesen kevesebbet tudó (már ez is abszurd, a legjobb indulat mellett is), ezért maradj csak annál, hogy nyilván mindent tudsz a szituról (pusztán csak erre akartam utalni. bocs, hogy nem sértegetni akartalak ;)

--
xterm

Te nem reagaltal erdemben.

Gondolom mert fogalmad sincs a hws hitelesitesrol... vagy ha van, nem ertem miert teszed az agyad.

Nem tud mindent, csak leszuri a kiszivargott reakciokbol/blogpostokbol az infokat, es levonja a kovetkezteteseket.. Tudom, tudom, binugzfanboylanden ez luxus, dehat nem mind ott elunk.

"Nem tud mindent, csak leszuri a kiszivargott reakciokbol/blogpostokbol az infokat, es levonja a kovetkezteteseket."

Ez a kulcsmondatod. És ebben tökéletesen benne van, hogy _lehet_, hogy nem tud mindent és _lehet_, hogy a hiányos információk birtokában _téves_ következtetést von le. Ahogy az is _lehet_, hogy _nem_.

nem csak összeesküvéseket lehet gyártani

Én nem gyártok összeesküvéseket, hanem kérdéseket tettem fel, miközben figyelem a fejleményeket a témában mindenfele és levonom az olvasottakból a következtetést (ellenben veled). Persze valószínűleg az érintettek is ilyen összeesküvéseket gyártanak. Mint pl. ez is, itt.

Külön javaslom a "The most annoying thing is that Red Hat remains silent on the main problem" és a "Red Hat says the packages were not distributed over RHN, so I wonder how I got them" bekezdéseket.

Persze lehet, hogy csak hazudik ez is.

Sőt, lehet hogy én írtam be, hogy alátámasszam azt, amit nem is mondtam, csak kérdeztem.

Na, ezt nevezik összeesküvés elmélet gyártásnak...

a rh (nálad) mindenképpen nyilván hülyébb és a legfőképpen a biztonságról lényegesen kevesebbet tudó (már ez is abszurd, a legjobb indulat mellett is)

Bocs, de nem az RH infráját törték meg egész véletlenül? Nem véletlenül pont azt, amelyiknek aztán főleg kiemelt biztonságúnak kellene, hogy legyen? Ember, gondolkozzál már... Nehogy már elkezdjem őket én is sztárolni, hogy mennyire ott vannak Security téren. Jól ismerem az RH-t és a biztonsági megoldásaikat az évekig sebezhető ExecShield-től a jelenleg is katasztrófálisan implementált FORTIFY_SOURCE-ig.

ezért maradj csak annál, hogy nyilván mindent tudsz a szituról

Hihetetlen. Csak tudnám hol írtam én ilyet.

Részben igazad van, de baromi nehéz a helyzet, hiszen bizonyos információk a cég bizalmas tulajdonának tekintendők. Soha, egyetlen cég sem fogja teljes körűen megírni, hogy "a bejáratnál balra volt egy open terminál, amely véletlenül a signature szerverekkel egy hálóban volt, Kovács János meg próbálgatta". Nem összekeverendő az open source és az open company.

--
SELinux, Xen, RHEL, Fedora: http://sys-admin.hu

Megmondom mi a furcsa az egész történetben...

Ha azt feltételezem, hogy a Red Hat aláíró rendszere jól van kialakítva (és ugye miért ne feltételezném első körben ezt), akkor nyilván vagy profik voltak akik még ennek ellenére is be tudtak jutni, vagy eleve belsős ember csinálta a műsort.

Ha azt a gondolatmenetet viszem tovább, hogy belsős ember volt, akkor nem értem hogyan feltételezik azt, hogy a passphrase-hez nem jutott hozzá (ezt mondjuk külsősnél is megkérdezném, mert szerintem akkor se lehet biztosra tudni, de belsősnél aztán pláne). Ráadásul a megfogalmazások sem olyanok, hogy belső ember volt, de ezt nyilván tudatosan is írhatták máshogy.

Ha viszont arra gondolok, hogy profik voltak, akkor méginkább visszás az egész történet... Egy olyan arc, aki be tud jutni egy jól megtervezett és kialakított aláíró rendszerbe nem fog OpenSSH csomagok backdoorozásával és aláírásával bénázni. Eleve az egész OpenSSH mizéria bűzlik... Minden normális helyen tűzfalazzák, szűrik, elrejtik az SSH-t, nem érdemes abba backdoort rakni, mert hiába is sikerül letolni frissítésként rengeteg helyre, nem lehet majd kihasználni (hacsak nem valami nagyon trükkösen kifele kommunikáló backdoor van benne, de akkor már megint kérdéses, hogy miért az OpenSSH-ba, hisz ezesetben lehetne bármi másba, amelyiket kevésbé figyelik, ellenőrzik). Szóval OpenSSH-ba backdoort rakni bukás. Egy profi inkább a kernelbe fog backdoort rakni, ahol módosítja az egész hálózati alrendszert úgy, hogy userland-ből ne is látszódjon az egészből semmi és ha csak egyetlen protokoll is van engedélyezve, azon is be lehessen jutni. Minden normális rootkit-nek van kernel-oldali komponense, amelyik eltünteti a nyomokat (hálózati kommunikáció ne látszódjon, a titokban futtatott programokat ne lehessen látni, feltöltött fileok rejtve maradjanak, stb.). A userland-only rootkit hosszútávon bukás.

Szóval, aki egy ilyen komoly helyre való bejutás után az OpenSSH-t próbálja backdoorozni, na az szerintem nem profi.

Ha viszont nem az, akkor az egész Red Hat aláíró rendszere gyanús, hogy nincs jól kialakítva, hisz egy kiddie is be tud jutni a legkritikusabb szervereikbe.

De majd lassan úgyis csordogálni fognak az infók, amelyekből majd többet lehet tudni...

Én csak a Red Hat és Fedora usereket sajnálom, mert ezzel a nagy semmivel, amit most az RH publikált senki sem lett okosabb és retteghetnek az emberek, hogy nem került-e ki más backdoorozott csomag is, amelyet nem vettek észre, mert az aki 43 RPM-et módosítani és aláírni tudott, az nem két perce volt benn...

( pinyo_villany | 2008. 08. 22., p – 21:57 )

tippem van is, hogy kik estek neki a linuxnak és miért ...
___
info

Arra gondolt, hogy a antivírus cégek egy ideje be akarják építtetni a kernelbe az a hook rendszert, amivel a antivírus és antimalware termékeik együttműködve hatékonyabban futnának Linux-on. Gondolom p_v arra gondolt, hogy ők állnak a dolog mögött, mintegy bebiztosítva, hogy "látjátok, szükség van erre". Ugyanis a fejlesztők egy része nem nagyon akarná ezt a malware hook rendszert.

--
trey @ gépház

a talpa egy kernel modul, amit a sophos és a többi vírusírtó cég be akar tolni a linux kernelbe, ennek eddig igen erősen ellenálltak a kernel fejlesztők. Ha ezek a cégek írnak egy PoC-ot linux-ra vagy netán egy kártékony kódot, akkor bebizonyítják, hogy szükség lehet arra a modulra.
___
info

( wladek1 | 2008. 08. 23., szo – 00:05 )

CentOS nem érintett?

kötöjelkötöjel
irreverzibilis perverzkonzerv

( pinyo_villany | 2008. 08. 23., szo – 17:03 )

akkor melyik is lehet a súlyosabb, ez vagy a debianos SSL baki? ;)
___
info