Betörtek az RSA rendszerébe és biztonsági termékekkel kapcsolatos információkat loptak

Az RSA ügyvezető elnöke, Arthur W. Coviello, Jr. nyílt levélben fordult az ügyfeleihez a vállalat weboldalán keresztül. A levélben az áll, hogy kifinomult cybertámadás célpontjává vált a vállalat. A támadást nagyrészt sikerült elhárítani, de az azt követő vizsgálat nyomán kiderült, hogy bizonyos információk a támadók kezébe kerültek. Ezek az információk az RSA SecurID kétfaktoros autentikációt biztosító termékcsaláddal kapcsolatosak. A vállalat biztos abban, hogy nem került illetéktelen kezekbe annyi információ, amivel sikeres közvetlen támadást lehetne indítani a meglevő RSA SecurID ügyfelek ellen, de a megszerzett információk elegendőek lehetnek ahhoz, hogy csökkentsék a jelenlegi kétfaktoros authentikációs implementáció hatékonyságát. A vállalat ígéretet tett arra, hogy folyamatosan tájékoztatja az ügyfeleit a kialakult helyzettel kapcsolatban. A levél elolvasható itt. A The Register cikke a témában itt.

Hozzászólások

Mi történt, hozzájutottak a backdoorhoz?

Ez így már rég rossz...

Úgy hitték, hogy betörni sem tudnak...
-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

Ha ezt hitték, akkor az nagyon nagy probléma. _Mindenhova_ be lehet törni. _Senki_ sincs biztonságban. A magukat kiváló szakembereknek tituláló celeb security expert-ek is sorra kerülnek fel azokra a listákra, aholis az ellenlábasaik által feltört szervereiken, rendszereiken tárolt adataikat - köztük bankkártyaszámukat, privát levelezésüket stb. - közlik a nagyvilággal. Pedig ők állítólag értenek ehhez. Most akkor van teljes biztonság?

--
trey @ gépház

ok.
Nemzetbiztonsági érdek?
Nacionalizmus?
Bosszúvágy?
Paranoid kényszerképzetek?

Az a szép, hogy ezek mindegyike irracionális. Nehéz felbecsülni mi az elfogadható védelmi szint ellenük.

Emiatt senkinek nem kell védelmet továbbfejleszteni, de nem is tanácsos azt hinni, hogy mivel van 2500Ft értékű adatom, és 250Ft befektetésével elértem hogy 54300Ft legyen elvinni, biztonságban van az említett adat. Azt már csak félve említem, hogy nagyon sok esetben nem tudjuk az említett három elem egyikét sem jól felmérni.

A világ egyszerűen nem így működik, hiába is szeretnénk mérnöki gondolkodásunk segítségével ide redukálni.

Szerintem.

- hé főnök, van egy icipici probléma!
- mond..?
- valaki egy kínai ip cím mögül lecserélte a motd filét valami pwned bitches szövegre
- főnök, ne hirdessünk ki ezentúl bounty-t a secbugokra, mint egy jó cég, ami megmutatja a világnak, h. annyira megbízható termékeket, szolgáltatásokat ad a népnek, h. még pénzt is fizet annak, aki talál bennük [v. a cég rendszerében] biztonsági hibát? tök jó lenne marketing és presztízs oldalról, és igazán hasznos lenne biztonsági oldalról!
- neeeeeeeeeeeeee, majd írunk valami szöveget, h. a betörés/aztsetudjuk mit loptak el csak a hatékonyságot csökkenti egy icipicit
- "oksi főnök"!
- módosítsd vissza a motd filét a régire, és az élet megy tovább!! :)

http://uptime.netcraft.com/up/graph?site=rsa.com - de gondolom csak sedelték az openbsd-s httpd nevét _iis6-ra_, amikor fordították azt :D

Gondolom ha a securid tokeneket gyártáskor ismeretlen mértékben elrontott órákkal szállították volna, akkor most nem lehetne semmiféle haszna semmilyen infónak, amit a tokenekről meg lehet szerezni.

Gondolom kb úgy működik a securid, mint a TOTP ( http://tools.ietf.org/html/draft-mraihi-totp-timebased-08 )

Van egy kulcs beégetve a tokenbe, ehhez hozzákavarják valahogy a token órája által mutatott perceket, és az így kiszámolt sok számjegyű értékből 6 számjegyet jelez ki a token.

Amikor egy cég vesz egy tokent, akkor azt regisztrálni kell a bejelentkeztetést ellenőrző szervernél. Az adminisztrátor begépeli a kulcsot, és ugyanekkor begépelheti a token által mutatott értéket is. A szerver ebből könnyen ki tudná számolni, hogy hány perc eltérés van a token órája és a pontos idő között.

Amikor a felhasználó újra és újra használja a tokent, akkor a szerver +/- 1 perc eltérésre számíthat az óra pontatlansága (sietése vagy késése) miatt, és ezekből az eltérésekből számon tarthatja, hogy az óra nagyjából mennyit fog sietni/késni a jövőben.

Ha valaki megszerzi a kulcsot (a gyártótól), akkor nem tudhatja hogy az óra mennyivel lett a gyártáskor elállítva, és hogy mennyire siet/késik. Ezért a tolvaj nem tudja az érvényes 6 jegyű számot kiszámolni és megadni a szervernek, hanem kísérleteznie kell.

Amikor a felhasználó újra és újra használja a tokent, akkor a szerver +/- 1 perc eltérésre számíthat az óra pontatlansága (sietése vagy késése) miatt, és ezekből az eltérésekből számon tarthatja, hogy az óra nagyjából mennyit fog sietni/késni a jövőben.

Na ez az, ami szerintem a gyakorlatban nem működhet. Nyilván induláskor kalibrálni kell a szervert a tokenhez. Ha ismeretlen a token pontossága, akkor a későbbi belépések sikeressége a kalibráció pontosságán fog múlni. Ha a felhasználó egyszer használja a tokent amikor megkapta, majd legközelebb 1 év múlva, akkor a token engedélyezése előtti kalibráció pontosságán fog múlni, hogy 1 év múlva a rendszer beengedi, vagy sem. Szerintem erre nem lehet alapozni nagyobb rendszerek működését.
Nyilván eleve van az óráknak valamilyen pontatlansága, de valószínűleg úgy van méretezve a rendszer, hogy az említett +/- 1 (vagy valahány) perces eltéréseket még elbírja.

pl.:

- backdoor van a tokenek crypto kódjában, aminek leírása olyan helyen volt őrízve, amihez hozzáférhettek a támadók (nem valószínű)
- lenyúlták a szerver-oldali authentikációs komponensek forráskódjait, amelyekben aztán biztonsági hibát kereshetnek és használhatnak ki máshol, függetlenül a crypto kód megbízhatóságától (előfordulhat)
- az rsa-nál megszerzett üzleti információkat arra használják fel, hogy egyes ügyfeleiknél sikeres social engineering támadást hajtsanak végre (elképzelhető)

Így van. Az átlag (vállalati) felhasználó biztonság-tudatossága valahol a bányászbéka szintjén van és ezen (mármint a social engineering ellen védő, biztonsággal kapcsolatos gondolkodáson) nem olyan egyszerű javítani, mint beilleszteni a hálózatba egy-két újabb biztonsági eszközt.

RSA: SecurID Attack Was Phishing Via an Excel Spreadsheet

"malicious Flash object embedded in an Excel file" - ez kész :D hol tart ez a világ biztonságilag? :D az emberek 99,9%-a nem használ "Flash object"-et EXCEL fájlokban:D ergo miért nem kérdez rá esetleg az adott program, h. biztos engedélyezi a "flash elemet"? mint a makróknál. omg. remélhetőleg kijönnek patch-ek ezzel kapcsolatban, minden irodai szoftverben. :\

az lehet, de ha az rsa-hoz betörtek ily módon, akkor kevesebb biztonsággal rendelkező helyre is betudnak törni, és legalább most már el lett vetve a mag a világ összes "rossz emberében", h. jéé, tök jól működik ez a módszer, azért kéne rá egy gyors/ideiglenes javítás, pl.: blokkolni a flash-t, amíg nem lesz megoldás

mi a jobb, h. ha a józsi nevű titkárnőnek [vicces célzás] nem olyan puccos az excel filéje, v. h. ha megint betörnek valami ordenáléan bazi nagy helyre, amitől emberek jó mennyisége függ.

láttam már esetet arra, h. egy levlistán valaki felvetett egy dolgot, másnap pedig már jött rá ki az exploit, pedig csak annyi köze volt a két dolognak egymáshoz, h. említették.

> azért kéne rá egy gyors/ideiglenes javítás, pl.: blokkolni a flash-t, amíg nem lesz megoldás

Manapság a dokumentumok végrehajtható állományoknak számítanak és a malware kergetők feladata az ezekben található kártevő kódrészletek levadászása. Az általad várt "gyors/ideiglenes javítás"-t ezek szerint nem a MS fogja szállítani, hanem a malware kergető cégek.

Az irodai programok készítői a funkcionalitás növelésében és a visszamenőleges kompatibilitás megőrzésében érdekeltek.

A megelőzés az lett volna, ha egyáltalán nem lehet flash-t beilleszteni, de ez ugye ellent mond a funkcionalitás növelésének. Az meg hogy tegnap be lehetett illeszteni flash-t a dokumentumokba, holnap meg már nem lehet; az a visszamenőleges kompatibilitást sérti.

pardon, h. ha nem voltam érthető:

pár hozzászólással korábban mondtam:
" kéne rá egy gyors/ideiglenes javítás, pl.: blokkolni a flash-t, amíg nem lesz megoldás"
"láttam már esetet arra, h. egy levlistán valaki felvetett egy dolgot, másnap pedig már jött rá ki az exploit, pedig csak annyi köze volt a két dolognak egymáshoz, h. említették."

most már láttam a 2 esetet életemben.

buhera:
"Lehetőleg ne kattintsatok semmilyen Office/PDF dokumentumra..."