Néhány hete zajlott a 19. Defcon Capture the Flag játékának selejtezője, melyen a hazai IT-biztonsági színtér minden szegletéből toborzott csapattal indultunk el, Senkihaziak néven. Remélem a poszt végére mindenki kellően át fogja érezni a minket ért megrázkódtatásokat :)

Számomra a '90-es évek első naív e-kereskedelmi próbálkozásait idézi fel a WebGL megjelenése. "Milyen jó lenne, ha virtuális 3D-s bevásárlóközpontokat építhetnénk" - mondták (és mondják) néhányan, akikben még nem tudatosult, hogy jobb, ha a kedves ügyfél vásárlással tölti az idejét, nem azzal, hogy keresi a virtuális liftet.

Node elnézést, ez nem egy marketing blog :) Most azonban biztonsági oldalról is kapott néhány nagy pofont az eddig is sok kritikával illetett technológia. A Context nevű biztonsági cég két összefoglalót is közzétett a WebGL-el kapcsolatos kutatásaiból, melyek eredményeként egyrészt a Mozillának frissítenie kell a saját implementációját, a Microsoft pedig leszögezte, hogy biztonsági megfontolásokból ebben a formában nem tudja elfogadni a specifikációt. Nézzük mit tárt fel a Context elemzése:

A problémák gyökere az, hogy a WebGL az operációs rendszer driverein keresztül képes kódot futtatni a grafikus magokon, ennek pedig több kellemetlen következménye is lehet.

A legalacsonyabb szintről indulva elmondhatjuk, hogy a grafikus kártyák tervezőinek célja a teljesítmény növelése, ami többnyire szöges ellentétben áll bármilyen biztonsági intézkedéssel, hardver szintű hardeningre tehát nem számíthatunk. 

A különböző driverekről elmondható, hogy más szoftverekhez hasonlóan itt is számolnunk kell biztonsági hibákkal, egy driverhiba kihasználása pedig gyakorlatilag minden esetben kernelmódú kódfuttatáshoz vezet (ezzel szemben egy sima böngészőhibával ring3-ba kerülünk, általában korlátozott, esetleg sandboxolt felhasználói hozzáféréssel). Eddig az ilyen jellegű problémák legfeljebb egy helyi támadó által voltak kihasználhatóak, mostantól egy kártékony oldalt működtető fél is hozzáférést szerezhet ezekhez az alacsony szintű modulokhoz.

A WebGL kódokat elsőként kézhez kapó böngészők nem tudják ellenőrizni, hogy valójában mit is akar lefuttatni egy adott weboldal. Ennek tipikus megnyilvánulása lehet egy DoS támadás: A támadó kérheti egy bonyolult objektum renderelését, de a kérés erőforrásigényéről nem lehet meggyőződni anélkül, hogy renderelnénk az objetumot... Így nem csak a böngésző folyamatot lehet kinyírni (javascript:while(1){}), de a teljes rendszer grafikai teljesítménye is megfogható, vagy akár BSOD is lehet az eredmény. Az egészben a legszebb, hogy a problémáról már a WebGL specifikáció is ír sőt, még PoC kódot is szolgáltat!

A különböző tartalmak típus és számrazási hely szerint történő védelmét aláássa, hogy a GPU-nak fogalma sincs arról, hogy egy adathalmaz milyen forrásból került hozzá. Egy WebGL alkalmazás például a böngésző segítségével betölthet külső forrásból származó képeket. A kép tartalmát egy, a kezdeményező weboldalon található szkript elméletileg nem ismerhetné meg, azonban ha ezt a képet textúraként felhasználjuk egy WebGL alkalmazásban, a GPU-n futó kód a textúra pixeleinek megfelelő időzítéseket alkalmazva információt továbbíthat a kezdeményező weboldal felé a kép tartalmáról. 

De nem csak a böngésző által kezelt adatok kerülhetnek veszélybe: A Context bemutatott egy olyan támadást, amely kihasználva, hogy a Firefox 4 WebGL implementációja nem inicializálja megfelelően a grafikus kártya memóriáját, lehetséges képernyőképeket menteni a weboldalt böngésző felhasználó asztaláról. Ezt a Mozilla június 21-én készül javítani, és valószínűleg magát a WebGL specifikációt is módosítani fogják.

És ezek csak néhány az új technológia kutatásában elért első eredmények közül, a fentieken kívül még sok érdekes információt találtok a Context két blogposztjában. Ezektől garantáltan elmegy a kedvetek a böngészőben Quake-ezéstől! 

Ahogy az előző posztban már említettem, tegnap az Adobe is kiadott egy rakat frissítést. Mivel azonban a nyilvános tanácslatok nem túl bőbeszédűek, a ZDI-11-200 - 222 tanácslatokat érdemes átnézni, elég jó infók nyerhetők ki a konkrét hibákról (magyar összefoglalót nem írok, a leírások így is kellően lényegretörőek).

Közben megjöttek a DVLabs eredményei is: TPTI-11-07 - 11

Érdemes megemlíteni továbbá, hogy az Acrobat is kapott egy sandboxot - ezt valószínűleg ugyanolyan előnyöket és hiányosságokat tartalmaz, mint a Reader homokozója. Ezen túl mindkét szoftverben alapértelmezetten bekapcsolásra kerül az automatikus frissítés funkció, a linuxos változatok frissítései- igazodva a támadási mintákhoz - félévente fognak érkezni.

Izgalmas nap volt a tegnapi, a Microsoft és az Adobe is nagyot frissített, következzen először is az előbbi gyártó javítás-listája:

MS11-038: Az OLE Automation rosszul kezeli a WMF fájlokat, ami kódfuttatásra ad lehetőséget speciálisan összeállított weboldalakon keresztül. A probléma a Windows összes támogatott változatát érinti, bár a 2008 Server alapértelmezett beállításai megakadályozzák a hibakihasználást.

MS11-039: A .NET keretrendszer javítása. A javításra került hiba többféleképpen is kihasználható: Egyrészt a támadó elhelyezhet speciális XAML Browser Application-öket vagy Silverlight objektumokat egy weboldalon (ez lehet akár egy jóindulatú félnél elhelyezett hírdetés is), melyeken keresztül kódot futtathat a weboldalt látogató felhasználók számítógépén. Másrészt ugyanez a probléma lehetőséget ad osztott webhoszting, illetve más Code Access Security-re támaszkodó környezet esetében a keretrendszer memóriahozzáférési korlátozásainak megkerülésére is.

MS11-040: Mindig bizsergető érzés, ha biztonsági termékben találnak kódfuttatásra alkalmas hibát - most pontosan ez történt a Forefront TMG Client 2010 esetében. A hiba az NSPLookupServiceNext függvény helytelen határérték-ellenőrzéséből adódik (jóeséllyel egyszerű puffer-túlcsordulásról van szó). A probléma akkor jön elő, mikor a kliens speciális kérést indít, melyet a biztonsági szoftver ellenőriz. Mivel az ilyen programok általában SYSTEM-ként futnak, a jellemző kihasználási mód szvsz. a jogosultságkiterjesztés, de a tanácslat a távoli kódfuttatás lehetőségét sem zárja ki.

MS11-041: Egy jó kis OpenType betűkészlet-kezelési probléma, amivel már úgy is kódot lehet futtatni, ha az áldozat csak a speciálisan összeállított betűkészlet-fájlt tartalmazó könyvtárat nyitja meg, akár egy hálózati megosztáson keresztül. A probléma csak Itaniumon és x64-en használható ki.

MS11-042: Két hiba javítása a Distributed File Systemben. A rosszabbik ezek közül távoli kódfuttatásra ad lehetőséget speciális DFS válaszok segítségével. Az összes támogatott Windows verzió érintett.

MS11-043: Kellően gonosz SMB megosztás kódot futtathat a csatlakozók számítógépén. Az összes támogatott Windows változat érintett, és bár a tanácslat nem zárja ki a kódfuttatás lehetőségét, a leírás alapján valószínűleg nem triviális a probléma kihasználása.

MS11-044: Igen érdekes .NET probléma, ami az MS11-039-el megegyező támadási lehetőségeket engedhet meg. A probléma ebben az esetben abból adódik, hogy a JIT compiler kioptimalizálhat bizonyos ellenőrzéseket a kódból, azt feltételezve, hogy bizonyos változók értéke mindig (nem) NULL. 

MS11-045: Nyolc hibajavítás az Excel összes támogatott változatához, Mac-re is. 

MS11-046: Jogosultságkiterjesztésre alkalmas probléma az Ancillary Function Driverben. A probléma a Windows összes támogatott változatát érinti. PoC itt van.

MS11-047: Egy Hyper-V DoS sebezhetőség javítása. A problémát egy vendég rendszerre bejelentkezett adminsztrátori jogkörrel rendelkező felhasználó használhatja ki a VMBusra küldött speciális üzenet segítségével. Ennek eredményeként megállhat az összes virtuális gép összes alkalmazása, a gazda CPU-ja felpöröghet 100%-ra, illetve előfordulhat, hogy nem lehet újraindítani a gazdát. A probléma részletes leírása itt olvasható, PoC-al együtt. 

MS11-048: A Windows Vista és újabb változatait érintő sebezhetőség javítása. A probléma kihasználásával távolról, autentikáció nélkül lelőhető az SMB szerver.

MS11-049: Információszivárgást lehetővé tevő probléma javítása a Microsoft XML Editorban, a .disco fájlok kezelésében. Ezt a konponenst használják az InfoPath illetve SQL Server termékek, valamint a Visual Studio is. A hiba feltehetően egy kódfuttatásra alkalmas társának tudna segíteni az ASLR legyőzésében.

MS11-050: Tizenegy javítás az Internet Explorerhez. Ezek közül hét kapott kritikus besorolást, vagyis hét esetben merül fel a távoli kódfuttatás lehetősége. Az SRD blog kiemeli, hogy az IE9-ből kigyomlált elavult funkcióknak és fejlesztett fuzz teszteknek köszönhetően a böngésző legújabb változatát már "csak" 4 kritikus sebezhetőség sújtja.

További infóért érdemes megnézni az alábbi ZDI jelentéseket:

• ZDI-11-193
• ZDI-11-194
• ZDI-11-195
• ZDI-11-196
• ZDI-11-197
• ZDI-11-198

MS11-051: Cross-Site Scripting sebezhetőség javítása az Active Directory Certificate Services Web Enrollment komponensben. A probléma úgy használható ki, hogy rávesszük egy bejelentkezett felhasználót egy speciális link követésére, így átvehetjük az uralmat a böngésző-munkamenete felett. A Windows 2003 és a 2008 egyes konfigurációi érintettek.

MS11-052: Egy inicializálatlan objektumhoz történő hozzáférés kódfuttatáshoz vezethet Vector Markup Language tartalmak feldolgozásakor. A hiba Internet Exploreren keresztül használható ki. A böngésző összes változata érintett, bár szerver operációs rendszerek esetén a megemelt biztonsági szint védelmet nyújt a támadásokkal szemben.

Kicsit meg vagyok lepődve néhány kolléga* kiakadásán. Ugye az van, hogy a LulzSec a csúnya-gonosz multik rugdosása után most belengette azt a lehetőséget, hogy kiderülhet, ki néz pornót az Interneten**. Abba most nem mennék bele, hogy mondjuk az X-Factor játékosok, meg a Sony felhasználók személyes adataiért miért nem hullott ennyi könnycsepp, két dolgot viszont mindenképpen fontosnak tartok megjegyezni:

1) LulzSec-ék nem szabadságharcosok, vagy igazságosztó szuperhősök, hanem trollok, méghozzá a legvastagbőrűbb fajtából. Mindenki eldöntheti, hogy felháborodik, vagy a helyén kezeli a tevékenységüket, és betárazza a pattogatott kukoricát a műsorhoz.

2) Amit ez a banda csinál, az legfeljebb kommunikációjában újszerű, módszereit vagy eredményeit tekintve egyáltalán nem. Higgyétek el nekem, a megtámadott rendszerek csak annyira voltak bugosak, mint egy átlagos webalkalmazás, a behatoláshoz pedig nem kellett nehézfegyvereket bevetni, elég volt egy-egy jól irányzott SQL injection. Ez azt jelenti, hogy a nyájas olvasó kismillió webes regisztrációját kezelő adatbázisok ugyanilyen védtelenek a támadásokkal szemben, jelentős részükből pedig már valószínűleg évek óta szipkázzák ki az adatokat, csak azok a támadók nem használnak Twittert.

Ne legyenek illúzióink!

Ajánlott olvasmányok:

• Absolute Sownage
• Why we secretly love LulzSec

* No offense
** Mindenki.

ITCafé:

A The New York Times rendkívüli tudósításban elsőként számolt be arról, hogy „nagy méretű, kifinomult” támadás érte a Nemzetközi Valutaalap (International Monetary Fund – IMF) informatikai rendszerét. A forrásként megjelölt szakértő, aki mind az IMF-nél, mind a Világbanknál kiberbiztonsági munkát végez, arról számolt be a lapnak, hogy a behatolók célja egy olyan szoftver feltelepítése volt, mely egy állam „bennfentes digitális jelenlétét” biztosította volna az ENSZ által 1945-ben létrehozott, ma 187 tagországgal rendelkező nemzetközi pénzügyi szervezet hálózatában.

Ellopták 200.000 észak-amerikai ügyfél adatát a Citibanktól. Az elmúlt hetek-hónapok történései után ez már-már egy jelentéktelen kis ügynek tűnhet - csak a számlaszámok és a kontaktinfók kerültek ki, a CVV-k és a TB-számok nem - de azért mégis csak egy világméretű pénzintézetről van szó!

Közben a LulzSec nyilvánosságra hozta a Sony Computer Entertainment Developer Network forráskódját és a Sony BMG belső hálózati topológiáját, a Six Apart pedig lényegében elismerte, hogy az ő tartalomkezelő rendszerükben található 0-day hiba kihasználásával hatoltak be a PBS rendszereibe.

Mindezt teljesen rezignált arckifejezéssel írtam le.

Ja, és ha már posztolok, íme a Black & Berg Security weboldala, amelynek deface-eléséért 10.000$-t és munkalehetőséget ajánlott a cég:

Frissítés2: Komolyan nem lehet számontartani ezt a sok szerencsétlenkedést, a francia Cerniga CA kitette a webre a privát kulcsát...

Imi küldte az alábbiakat:

Tavaly május 23-án (22:52) a nagy index.hu követett el egy hatalmas hibát, és ki tudja, hogy meddig volt úgy. Az admin.index.hu oldalon ugyebár megjelent a felhasználónév és a jelszó mező, és ha a felhasználó névhez 1-30-ig bármilyen számot beírtam, jelszót nem, akkor simán be lehetett lépni a szerkesztőségi rendszerben. Természetesen nem tettem közzé a felfedezésemet, hanem a szerkesztőségi rendszerben megkerestem Uj Péter telefonszámát, és azonnal hívtam, a hibát nem sokkal később elhárították.

Tanulság: "Úgysem fog senki ilyennel próbálkozni" - De igen, fog.

Az Oracle kiadta rendszeres, júniusi Java frissítését. Bár a közlemény szokásosan szűkszavú, azt azért érdemes megjegyezni, hogy a 17 hibajavítás közül 9 még az általában optimistán számolgató Oracle-től is megkapta a maximális, 10.0-ás CVSS bázispontot. Ez nagyjából annyit jelent, hogy ezek a hibák távolról, autentikáció nélkül (mondjuk Java Web Starton keresztül) kihasználhatók kódfuttatásra, komplexitásuk pedig olyan alacsony, hogy a rosszfiúknál már valószínűleg be vannak tárazva az exploitok.

Ha további információ kiderül a hibákkal kapcsolatban, frissítem a posztot, addig frissítsetek!

Laza három hónappal az első bejelentés után az RSA elismerte, hogy a tőle megszerzett, SecurID technológiával kapcsolatos adatok veszélyt jelenthetnek az autentikációs megoldást használó rendszerek biztonságára, valamint hogy az incidens kapcsolatban áll a Lockheed Martinnál történtekkel.

A vállalat egyúttal felajánlotta "koncentrált felhasználói bázissal" rendelkező vásárlói számára a tokenek cseréjét, azokon a helyeken pedig, ahol ez nehézkes lenne (kapaszkodjatok!) "kockázatalapú autentikációs stratégiák" kidolgozását ígérik.

Maga a nyílt levél egyébként megérne egy részletes elemzést: kezdve onnan, hogy hogyan próbál összemosni a világ egyik vezető biztonsági cége egy teljes hadiipart érintő támadást a Sony szerencsétlenkedésével, a Nintendo botlásával, vagy a Google felhasználóit ért adathalász támadásokkal, egészen az utolsó "we will, we will, we will ..." bekezdésig. De ez már egy másik blogra tartozik.

Az Adobe frissítette a Flash Player 10-es vonalának Windowsra, Mac-re, Linuxra és Solarisra szánt változatait, így javítva egy aktívan kihasznált XSS hibát. Az androidos változat a héten frissül. A hiba kihasználásával a támadó a célpont felhasználó nevében hajthat végre akciókat tetszőleges weboldalon. A hírek szerint a problémát GMail felhasználókkal szemben igyekeznek kihasználni. Kíváncsi lennék, van-e összefüggés a legutóbbi GMail-es adathalász incidensekkel...

Nem rég jelent meg Tomcsányi Domonkos és Lukas Lueg, Pyrit fejlesztő közös írása a WPA2-PSK jelszavak törésének egy gyorsítási módszeréről. Az ötlet az, hogy egy feltételezett kulcsból generált Paiwise Master Key birtokában egy AES blokk kiszámításáért cserébe kevesebb SHA-1 függvényhívással ellenőrizhető a feltételezett kulcs érvényessége, vagyis hogy az adott PMK helyes volt-e.

Az ötletet a Pyrit fejlesztői ágában már implementálták is, a Pyrit blogján megjelent bechmark adatok szerint mintegy kétszeres gyorsulást lehet elérni, amennyiben a PMK-k előre számítottan rendelkezésre állnak.

A magam részéről elég szkeptikusan álltam az eredményekhez: Amellett, hogy az ötlet jó, a gyakorlatban a kriptográfiai primitívek számán kívül számos egyéb tényező befolyásolhatja egy program teljesítményét sőt, az átgondolatlan optimalizáció akár ronthatja is azt. Emellett a WPA2 biztonságában a nyers-erőn alapuló támadásoknak történő ellenállást éppen a számításigényes PMK generálás hivatott garantálni, ezzel pedig az új módszer nem foglalkozik - bár a megközelítést  alátámasztja az, hogy előre számított adatbázisokat széles körben alkalmaznak.

Így hát fogtam magam, és futtattam pár tesztet a régi és az új algoritmussal. Az első észrevételem az volt, hogy a neten elérhető szótárfájlok általában néhány százezer szót tartalmaznak, míg a régi kulcsellenőrzés is néhány milliót képes feldolgozni másodpercenként (ezzel szemben a PMK generálás néhány ezer szó/s-el futott). Végül egy saját, 3,2 millió szót tartalmazó szótárból építettem adatbázist Pyrittel.

Az algoritmus sebességét egyszerűen a time paranccsal illetve a Pyrit saját sebességmérőjével mértem - feltehetően utóbbit használta Lukas is a méréseihez. Az eredmények azonban értékelhetetlenek lettek, mivel néhány százezertől néhány százmillió szó/s-ig kaptam eredményt minkét algoritmus esetén, főleg attól függően, hogy milyen sorrendben kerültek bejárásra az adatbázis szavai.

Más méréseket még nem végeztem (bár Illés Márton optimalizációs előadása nagyon inspiráló volt :), és mástól sem láttam, így a módosított algoritmusra egyelőre inkább elméleti eredményként, lehetőségként tekintek.

+++

A másik WLAN-os érdekesség a héten a FaceNiff volt, amivel a környéken repkedő közösségiportál-bejelentkezéseket lehet elkapkodni Androidon. Erről először a LivingAndroid blog szerzőjétől hallottam, és szöget ütött a fejembe, hogy WPA2-PSK hálózatoból sima sniffeléssel hogyan lehet sütiket gyűjteni? A megoldás rövid és egyszerű: A FaceNiff nem passzív támadást alkalmaz, hanem ARP spoofingot alkalmazva egyszerűen megszemélyesíti az AP-t... hiába, a név nem minden :)

Egy ideje elég szórakoztató jelenséggé vált Twitteren a LulzSec "csoport", akik az X-Factor jelentkezőinek adatainak publikálása után most a Sony-t vették célba. El is esett (két másik kevésbé jelentős helyi oldal mellett) a sonypictures.com, ahonnan több mint 1 millió felhasználó személyes adataihoz (köztük titkosítatlan jelszavakhoz), valamint 3,5 millió zenekuponhoz, adminisztrátori jelszavakhoz és 75.000 "zenekódhoz" ("music code" - ez vajon mi?) fértek hozzá a támadók, akik maguk is elismerik, hogy mindehhez nem kellett más, mint egy darab jól irányzott SQL injection...

Az mintaanyagok innen érhetők el, a teljes adatbázis erőforrás okokra hivatkozva nem tették közzé, de a sebezhető URL megtalálható a letöltésekben.

A Google hivatalos blogján megjelentetett posztban értekezik a GMail fiókok biztonságossá tételéről, illetve érintetlenségük ellenőrzési lehetőségeiről, mindezt annak apropóján, hogy célzott adathalász támadásokkal átvették az irányítást néhány száz amerikai és dél-koreai kormányhivatalnok, valamint több politikai aktivista postafiókja felett. Nem fogjátok kitalálni, a rosszindulatú üzenetek forrása a Föld legnépesebb országa...

A történet számomra két szempontból is igen érdekes: egyrészt a legutóbbi hasonló esetre hivatkozva szüntette meg a Google a találati listák cenzúráját Kínában. Másrészt a contagio blog - amire a hivatalos Google közlemény is hivatkozik - remek betekintést ad az akció részleteibe:

Az adathalász e-mailek a szokásos módon, hamisított feladóval landoltak a célpontok postaládáiban, a tartalom pedig úgy volt felépítve, mintha a levelező kliens csatolmány ablaka is megjelenne az üzenet mellett. Ebben az álablakban elhelyezett linkek mutattak hamisított GMail belépő oldalakra.

Amennyiben a felhasználó bedőlt a trükknek, a megszerzett jelszóval a támadók okosan bántak: legagresszívebb esetben néhány szűrő, illetve hozzáférés beállítások megadásával "bepoloskázták" a fiókot, de sok esetben egyszerűen csak a közeli kollegákról, családtagokról, folyó ügyekről tájékozódtak, az így megszerzett információt pedig újabb adathalász e-mailekben használták fel. Az így előállított üzenetek már a személyekhez szorosan köthető információkat tartalmaztak, növelve a hitelesség látszatát.

Maga az adathalász weboldal sem tömegtermék volt: a célpont azonosítója bedrótozva szerepelt a számára egyedileg generált oldalon. Egy szkript ezen kívül arra is vette a fáradtságot, hogy sima JavaScript segítségével detektálja a látogató gépére telepített biztonsági szoftvereket és böngésző kiegészítőket. Arra sajnos nem tér ki az elemzés, hogy ezekre miért volt szükség.

Hölgyeim és Uraim, így néz ki ma egy politikailag motivált adathalász támadás! A módszer alapvetően a régi, de az ördög most is a részletekben rejtőzik!

A Wired birtokába került e-mail tanúsága szerint az L-3 Communications rendszerét is támadás érte, a támadók pedig az EMC-től zsákmányolt, SecurID technológiához kapcsolódó információkat használták. 

Néhány napja a szintén az USA védelmi minisztériumának szállító Lockheed Martinnal kapcsolatban jelentek meg hasonló hírek, és már akkor tudni lehetett, hogy több más azonos kategóriájú vállalatnál észleltek incidenseket.

Egyre valószínűbb tehát, hogy az EMC-től igenis kikerültek olyan információk, melyek közvetlen veszélyt jelentenek a SecurID rendszerek biztonságára. Biztonsági szakértők már az EMC incidens idején felhívták a figyelmet az ilyen rendszerek megerősítésére és kitüntetett monitorozására, most azonban már az sem tűnne túlzott reakciónak, ha valaki a teljes csere mellett döntene.

Athos hívta fel a figyelmem a pam_env és pam_mail modulok egy igen érdekes, információszivárgást okozó hibájára, amely bizonyos esetekben a DSA kulcsot privát változóit is kellemetlenül érintheti.

A probléma gyökere az, hogy az említett modulok nem dobják el a privilégiumaikat a bejelentkező felhasználók fájljainak olvasása előtt. Peter van Dijk erre alapozva egy igen ötletes támadással állt elő:

Az ssh-keygennel generált kulcsok általában base64 kódolással kerülnek tárolásra. A base64 karakterláncok bizonyos esetekben '==' -re végződhetnek. Amennyiben a ~/.pam_environment fájlt szimbolikus linkként hozzuk létre a rendszer egy másik felhasználójának privát DSA kulcsára, úgy a következő bejelentkezéskor a PAM modulok root szintű jogosultságának köszönhetően a titkos kulcsfájl tartalma olvasódik fel, a kulcs utolsó sora pedig mint környezeti változó kerül regisztrálásra a bejelentkező felhasználó kontextusában. 

Ez az utolsó sor általában a titkos paraméter jelentős részét, 160 bitből 128-at tartalmaz, a maradék a publikus kulcs felhasználásával, brute-force módszerrel hamar megkapható.

A módszert korlátozza, hogy csak az esetek mintegy 10%-ában áll elő olyan kulcs, melynek kódolt formája '=='-re végződik és nem számmal kezdődik, így elfogadható környezeti változóként, ezen kívül nyilvánvalóan nem megyünk sokra, ha a kulcs jelszóval védett.

A nagyobb disztribúciók javították a hibát, frissítsétek a pam_modules csomagot!

+++

Lazán kapcsolódó téma, hogy két finn kutató időzítésen alapuló támadást talált az OpenSSL ECDSA implementációjában. A papírt sajnos még nem sikerült elolvasnom, ezért hálás lennék, ha valaki felhomályosítana engem és a Nagyérdeműt a támadás részleteiről!

Torrenten terjednek az Allied Telesis különböző rendszereihez használható, hátó ajtóként szolgáló jelszavak, és az ezek (általában MAC címből történő) generálására használható szoftverek. Az információk még múlt héten jelentek meg a cég weboldalán, majd a Google cache-ben, valószínűleg véletlenül. A backdoor jelszavak elméletileg csak fizikai hozzáférés esetén használhatóak.

Kevésbé kapott nagy publicitást a talán egy fokkal veszélyesebb, Trustwave WebDefense-t érintő "probléma". Nathan Power elgondolkodott azon, hogy mégis milyen hitelesítő adatokat használnak a biztonsági termék MySQL adatbázis felé indított kapcsolatai, így körbenézett a binárisokban. Mint kiderült, majdnem két tucat állományban van jelen valamilyen bedrótozott adatbázis jelszó, melyeket egy, a MySQL-lel egy hálózaton lévő támadó könnyűszerrel felhasználhat. 

Zorg a Rettenetes hívta fel a figyelmem az alábbi Bombahíres hírre (Az Ozeki.hu közlényét itt olvashatjátok):

Szombat éjjel számos weboldalon megjelent a mobilkommunikációs szoftverek fejlesztésével foglalkozó Ozeki Informatikai Kft. valamennyi termékének forráskódja. A cég belső e-mail forgalma, köztük Pintér Sándor lányának, Pintér Csillának a levelei is a crackerek kezére kerültek.

Az 1,5 gigabyte méretű tömörített fájlban a debreceni cég által fejlesztett SMS gateway szerverszoftverének, VoIP telefonrendszerének, webes irodai programcsomagjának és számos más termékének forráskódjai találhatóak. A hackerek üzenete szerint ez csak az első része a kiszivárogtatásnak, a napokban egy 8 GB méretű további gyűjteményt tesznek közzé, amelyben a cég teljes levelezése lesz olvasható, köztük Pintér Csilláé is. Nyilvánvalóan akárcsak a mostanit, azt is olyan anonim oldalakon helyezik majd el, mint a ThePirateBay torrentoldal, a pastebin.com forráskód-közlő rendszer és mások.

A "közlemény" itt olvasható, a torrent meg itt van.

Van egy olyan érzésem, hogy ezúttal nem keleti szkriptsuttyók működéséről van szó, a támadókat jó eséllyel kishazánkban kell keresni...

Friss:

A torrentben lévő fájl tényleg nem tűnik kamunak

 Friss2:

Megjelent az Ozeki.hu hivatalos közleménye (kösz trt77):

[...]
Mi az Ozekiben nem is tudtuk, hogy a belügyminiszternek van lánya (vagy fia). Fogalmunk sincs, hogy került ebbe a históriába ez a bizonyos Pintér Csilla. Nincs és nem is volt soha ilyen nevű alkalmazottunk. Sajnálatos módon a Belügyminisztérium nem vásárolt tőlünk egyetlen licenszet sem eddig. Azt természetesen értjük, hogy ennek a históriának csak akkor van hírértéke, ha valami politikai botránnyal is meg lehet fűszerezni.
[...]

Frissítés (2011. június 9.):

A beígért levelezést eddig nem hozták nyilvánosságra, gyaníthatóan nem is fogják. A politikai vonal valószínűleg kacsa volt.

Nos, ez rendkívül érdekes: A Reuters értesülései szerint illetéktelenek hatoltak be a Lockheed Martin és más, az USA védelmi minisztrériumával szorosan együttműködő szervezethez, mégpedig az RSA/EMC indcidens során megszerzett SecurID adatokat felhasználva.

A történet nem csak azért hátborzongató, mert a LMT a világ egyik legnagyobb haditechnikai beszállítója (ballisztikus rakéták, radarok, műholdak, stb.), hanem azért is, mert - ha Reuters értesülései helytállóak - az EMC támadás során valóban kikerültek olyan adatok, melyek a nagy volumenű biztonsági rendszerek sarokköveinek számító azonosító megoldásokat kritikusan érintik. Az EMC részéről ezügyben eddig csak homályosan megfogalmazott közleményeket olvashattunk, a gyártó pedig eddig szerencsésen elkerülte a téma további feszegetését a Sony incidenseinek közönhetően.

Nyugodt szívvel kijelenthetjük: csapataink harcban állnak.

Tegnap elég nagy port kavart Twitteren az ÁNTSZ.hu XSS sebezhetősége, valamint hogy állítólag az admin felület sem valami jól védett (az alapértelmezett RedHat nyitóoldalról, és a hasonló apróságokról már nem beszélve), de azért az sem egyszerű, ahogy a yamm.hu átvette a hírt:

Rosario Valotta egy igen érdekes, javítatlan Internet Explorer sebezhetőséget, és egy hozzá kapcsolódó támadási láncot tett közzé, melynek lefutása után - némi felhasználói körzeműködéssel - megszerezhetők a böngészőben tárolt sütik.

Az IE sebezhetőség rém egyszerű: Egy Internet zónában működő IFRAME betölthet egy süti fájlt egy IFRAME-be.

A dolog innentől válik trükkössé, ugyanis egyrészt a sütik útvonala függ a bejelentkezett felhasználó nevétől, másrészt a same-origin policy megkerülésével valahogy ki kéne varázsolni a süti tartalmát a támadó oldal kontextusába.

A felhasználónév megszerzését Valotta egy független csatornán oldotta meg, kihasználva, hogy az IE NTLM autentikációra kényszeríthető, ha egy UNC útvonal (\\server\megosztás) betöltésére kérjük. Az autentikáció során pedig nyílt szövegként közlekedik a felhasználónév. Így egy támadó beágyazhat egy, a saját szerveréről fájlmegosztáson keresztül elérhető képre mutató hivakozást, majd a 445-ös porton figyelve elkapkodhatja azoknak a felhasználóneveit, akik megnézték a rosszindulatú weboldalt.

Innentől kezdve tudjuk az útvonalat (a User-Agentből kiolvasható az oprendszer, böngésző verzió), tehát be tudjuk tölteni a sütit egy IFRAME-be. Itt viszont a same-origin policy gátat szab a további automatizálásnak, a felhasználó segítségét kell kérni.  

Ehhez egy clickjackinghez hasonló módszer használható: ha a süti tartalmát eltüntetjük, alá pedig egy képet helyezünk, és rávesszük a felhasználót, hogy drag'n'drop módszerrel mozgassa arrébb azt, a felhasználó a szöveget ki fogja mozgatni az IFRAME-ből, és le fogja dobni a külső weboldalon, a támadó kontextusában.

A fent is látható egyszerű demo hatékonyságát mutatja, hogy Valotta 150 Facebook ismerőséből 80 bedőlt a trükknek.

Egy egyszerű, de nagyszerű hiba került javításra a PHP 5.4 és 5.3-as verzióiban. A nyers socket kapcsolatok nyitásához használt socket_connect() metódusban egy memcpy() által triggerelt stack túlcsordulás csücsült egy ideje, melyet Unix socketek esetén lehetett kihasználni egy kellően hosszú cím paraméter beállításával. A befoltozott rést itt lehet megtekinteni.

Ha van Open Academy regisztrációtok, ma este többek között azt is meghallgathatjátok, hogy miért lehet veszélyes egy ilyen, helyi jellegű hiba, illetve hogy hogyan erősíthetők meg a PHP installációk a hasonló hibákból eredő kockázatok csökkentése érdekében.

Tényleg nem lehet számon tartani a Sony incidenseket, a hétvégén lenyúltak kb. ezer dollár értékű kreditet a So-Netből, melynek következtében a cég felfüggesztette a virtuális pontok kereskedelmét. Emellett kikerült egy SQL injectionnel megszerzett adatbázis is a Sony BMG görög oldaláról. Úgy tűnik, a GeoHot-ügy után tényleg sokan berágtak a Sony-ra.

Hasonló módszerrel dumpolták ki a brazil Comodo honlapjának adatbázisát is. Aki nem emlékezne: ennek a vállalatnak az egyik RA-ján keresztül lehetett tanúsítványt gyártani tetszőleges névre.

Rendbe vágtam a jobb oldali dobozokat, ami a linkek radikális megnyirbálásával járt. Elég szigorúan (ha úgy tetszik, szívtelenül) jártam el, az érintettek remélem nem sértődnek meg, a bent maradóknak gratulálok :)

Megnyugtatásul közlöm, hogy a feedolvasómban mindenki benne maradt. Innen gyakran osztogatok meg elemeket, amik automatikusan mennek Twitterre, sok más hasznos infó mellett. Mivel az utóbbi időben legjobban a mikroblogger szcénában pörögnek a hírek, mindenkinek erősen ajánlom a feliratkozást. 

Breach blog:

Oké, a Sony visszaállította a PSN-t, erre most valaki kitalálta hogy az email cím és a születési dátum megadásával a jelszó resetnél lehet maszatolni. A Sony azt mondta hogy kötelező jelszó reset mindenkinek a fenti adatok megadásával és lehet használni a szolgáltatásokat. A probléma az hogy ezekkel adatokkal az előző breachek támadói is rendelkeznek. A Sony reakciója: lekapcsolta a szolgáltatást a hiba kivizsgálásának idejére.

Annyit hangsúlyoznék az esettel kapcsolatban, hogy a gond nem azzal van, hogy az alapértelmezett jelszavakat ki lehet találni, hanem hogy a sebezhetőség akkor is megengedi a jelszóváltoztatást, ha az áldozat korábban már beállított magának egy erős jelszót az alapértelmezett helyett.

Itt van az eredeti cikk, jól követhető frissítésekkel és egy FAQ-val az esetről.