ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Betörtek az RSA rendszerébe és biztonsági termékekkel kapcsolatos információkat loptakAz 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.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 8% Összes szavazat: 560
Új felhasználók
InformációKövess minket!Partnerünk |
Hát ez szopás...
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
Most akkor van teljes biztonság?
akkor sose halnank meg...
Csiiiz! avagy a "gonosz" mibenlete - politika, flame és offtopic huppereknek szabadon!
Van.
Amikor a feltöréshez szükséges errőforrások (munkaerő, pénz, idő) értéke meghaladja a megszerezni kívánt információ értékét.
--
[Random Topical Haiku] (Slashdot.org) I've Got A Cool Site. What The Fuck? So Much Traffic! Now My Server's Down
+1
Egy BGF hallgató haverommal vitatkoztam ezen nemrég. Hajtogatta, hogy minden feltörhető, ami így is van, de ettől függetlenül biztonságos egy renszer, ha, ahogy te is írtad, többe kerül feltörni, mint az ellopandó adat értéke.
Ez az elképzelés feltételezi, hogy haszonszerzés a betörés célja.
Sokszor nem ez a helyzet. Emberek brahiból, becsvágyból is csinálnak dolgokat amik egyébként veszélyesek, nehezek, sokszor unalmasak.
Ezekkel szemben semmi nincs biztonságban.
+1, es tegyuk a lista vegere a "csak azert is kicsinallak, kerul, amibe kerul" dolgot is...
Csiiiz! avagy a "gonosz" mibenlete - politika, flame és offtopic huppereknek szabadon!
"Ez az elképzelés feltételezi, hogy haszonszerzés a betörés célja."
Nem feltételezi. Az, hogy "többe kerül" értelmezhető a becsvágyó egyén szintjén is. Pl.: 20 évet vinne el az életéből. Már nem éri meg.
vagy a becsvagyo szemely kiokoskodja, hogyan csokkentse toredekere az idot. jo kis brainstorming, de volt mar ra pelda.
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.
A bibi ott kezdodik, amikor a vedeni kivant informacio becsult erteke vegtelen...
- 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
Alternativ lehetosegkent ennel egy picit arnyaltabb a kep, nem?
tompos
gbor meg az arnyaltabb kep?
"Uj lehetsz errefele."
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
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.
Ööö, ezt nem vágom. Ismeretlen mértékben elrontott órákkal valószínűleg beléptetésre sem lehetett volna használni a token-eket.
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.
Jó, akkor az óra ne legyen sietésre/késére beállítva, csak pld +/- 1 héten belüli eltérésre. Az eredmény ugyanaz, a gyártótól lopott kulcs nem használható.
Nekem ebből se derült ki, hogy miféle kockázatot jelentenek az ellopott infók:
Open letter from Arthur W. Coviello, Jr., Executive Chairman, RSA, the Security Division of EMC, to RSA customers dated March 17, 2011 ( http://secwatch.com/emc/8k/events-or-changes-between-quar/2011/3/17/7684013 )
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ő)
- 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ő)
Ez jó tipp. Az RSA ügyfelei bizonyára nem a sarki kisbótot üzemeltető vállalkozók köréből kerülnek ki.
Í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. :\
> miért nem kérdez rá esetleg az adott program, h. biztos engedélyezi a "flash elemet"?
Ez nem megoldás, hanem csak a felelősség egyszerű áthárítása.
amire úgy is igen-nel válaszol a delikvens :\ akkor ne legyenek flash elemek excel filékben, mert a flash tud gonosz is lenni. esetleg ha domain-be vannak léptetve a gépek, akkor legyen egy policy arra, h. lehessen flash elemeket engedélyezni office doc-okban v. ne.
Én nem hiszem, hogy itt pár sorban megoldhatnánk azt a problémát, amit a MS sem tudott sok év alatt.
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ért remélem, h. az összes irodai csomagban találnak megoldást, jobb a megelőzés, mint h. utólag megnyitáskor a vírusirtó azt mondja, h. ejha, miezitt
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.
..lám-lám: miről is beszéltem?
http://buhera.blog.hu/2011/04/11/adobe_flash_player_reader_es_acrobat_0day_igen_megint
> ..lám-lám: miről is beszéltem?
Ha van mondanivalód, írd le közérthetően, ne kelljen már találgatni ... Irgumburgum.
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..."