A bejelentés szerint a Microsoft egy, a Win32k TrueType font parsing engine-ben található hibát vizsgál. A támadó a hiba sikeres kihasználása révén kódot futtathat kernel módban. A Server Core verziók kivételével gyakorlatilag az összes támogatott Windows termék megtalálható az érintett szoftverek listáján.
A figyelmeztető mellett a redmondi cég workaround-ot, ún. FixIT-et tett közzé. Hogy a javítás mikor érkezik, arról egyelőre nincs információ. A Sophos blogbejegyzése szerint nem valószínű, hogy a következő "patch kedden" (ált. a hónap második keddje) megérkezik a javítás.
Laborunk, a CrySyS Adat- és Rendszerbiztonság Laboratórium tovább folytatta a Duqu trójai elemzését, és a kutatás eredményeként azonosítottunk egy dropper fájlt, mely egy MS 0-day kernel hibát használ fel. A szükséges információkat azonnal továbbítottuk az illetékes szakmai szervezeteknek, akik gondoskodni tudnak a felhasználók megfelelő védelméről.
Ha beesik konkrétabb infó, frissítem a posztot!
Friss1:A ZDNet értesülése szerint a trójait egy .doc fájlba csomagolták. Ha ez így igaz, kell lennie még egy kódfuttatást lehetővé tevő lépcsőnek a Word és a kernel exploit között.
Friss2:Itt olvasható a Symantec kommentárja, sajnos a frissített whitepaper még nem látszik azon a szerveren, amit elérek. A célbajuttatáshoz használt dokumentum a biztonsági cég szerint kifejezetten a konkrét célpont számára készült. Egyesek arra tippelnek, hogy a kihasznált sebezhetőség közvetlenül rendszer szintű kódfuttatást eredményezhet a Wordből, a win32k.sys beágyazott betűkészlet feldolgozó alrendszerének hibáját kihasználva (egy régebbi ilyen jellegű sebezhetőségre van példa itt). De ez csak egy tipp. A legújabb eredmények szerint a trójai SMB megosztásokon keresztül is terjedhetett belső hálózatokon, és ezt a protokollt arra is felhasználta, hogy az interneteléréssel nem rendelkező gépek is kapcsolatot tudjanak tartani a C&C-vel a szomszédos, netes gépeken keresztül. Az indiai C&C szervert idő közben lefoglalták, de most egy újabb irányító hosztra bukkantak Belgiumban.
Friss3:Innen letölthetők a DuQu első mintái (jminet7.sys, cmi4432.sys, nfred965.sys)
A www.otdt.hu kezdőlapján már szembetűnik egy deface, viszont kb fél 2 mp próbálkozással sikerült megtalálni a www.otdt.hu/admin felületet, ahol egy hihetetlen egyszerű sql injection hibával be lehet lépni. Gondoltam szólok.
Német kutatók súlyos hibákat fedeztek fel az Amazon Web Services-ben és az Ubuntu cloudjában is használt Eucalyptus platformban. A legkritikusabb - azóta már javított - sebezhetőségek ún. XML Signature Wrapping támadásokra adtak lehetőséget. Ezek a szolgáltatások SOAP interfészeit érintették, melyeken keresztül a felhasználók aláírt XML üzenetket használva adhattak parancsokat.
Ilyen esetben a SOAP fejléc tartalmazza az aláírást, egy időbélyeget és egy hivatkozást a hitelesített üzenettörzsre. A kutatók az utóbbi két komponens többszörözésével illetve az XML fán belüli átmozgatásával kezdtek el játszani, sikerrel. Mint kiderült, dupla üzenettörzs esetén az Amazon szolgáltatása az egyik példányt használta az aláírás ellenőrzéséhez, míg a másikat értelmezte és hajtotta végre. Így egy aláírt üzenet birtokában, az aláíró felhasználó nevében tetszőleges parancs végrehajtható volt. Azaz majdnem, ugyanis az időbélyeg (ami szintén hitelesítésre kerül) öt percet hagy a cselekvésre, ami nem mindig elegendő: az aláírt üzenetek beszerzésének egyik legegyszerűbb módja a fejlesztői fórumok túrása, ahol túlnyomó részt csak rég lejárt üzeneteket találunk.
De semmi gond, az időbélyeg mezővel is el lehet játszani ugyanezt: ha két ilyen adat szerepel a fejlécben, az aláírás ellenőrzése az egyik figyelembevételével történik meg, míg a lejárat ellenőrzése a másikkal. Mikor a kutatók először jelezték a problémát az Amazonnak, az élelmes programozók úgy módosították a webszolgáltatást, hogy dobjon vissza minden üzenetet, amiben dupla időbélyeg fejléc szerepel. A gond az volt, hogy a második időbélyeg mezőt a duplikált üzenettörzsbe helyezve, vagy magát a fejlécet duplikálva újra meg lehetett kerülni az ellenőrzést.
De ezzel nincs vége a problémáknak: amennyiben ugyanis a SOAP üzenet nem került aláírásra, a felhasználó azonosítása és autentikációja pusztán az üzenetbe ágyazott (nyilvános!!!) X.509 tanúsítvány alapján történt meg. Erre már nincsenek szavak.
Az Eucalyptus esetében kicsit bonyolultabb volt a helyzet: itt az eredeti időbélyeget és üzenettörzset a SOAP séma betartása érdekében egy <wsse:Security> elem alá kellett helyezni, a valódi törzset ez után tetszőlegesen lehetett módosítani.
Az elemzésben még szó esik néhány XSS problémáról is, ezeket is javították, bár érdekes kérdés az Eucalyptus esetében, hogy vajon az ezen a platformon működő privát felhőket mikor fogják frissíteni?
Kis adalék a fentiekhez, hogy az AWS egys terheléselosztó hibája miatt nem rég 2 millió, Netflixnek szánt kérést egy másik felhasználóhoz irányított - kíváncsi vagyok mennyi bizalmas infót tartalmazott az adatofolyam!
Két amerikai műhold vezérléséhez férhettek hozzá rövid időre számítógépes kalózok, feltehetően a kínai hadsereg megbízásából - áll a washingtoni kongresszus elé terjesztendő jelentéstervezetben, amelyet csütörtökön szivárogtatott ki az amerikai sajtó.
20:04 -!- Spaceboy [~c6749031@huwico.hu] has joined #huwico 20:04 < ircnet_gw> Hex2IP: c6749031 --> 198.116.144.49 --> nasans3.nasa.gov. 20:04 < Spaceboy> hi 20:05 < Spaceboy> is this the channel of hungarian wireless community? 20:05 < Z0l> yes 20:06 < szaboat> hi 20:07 < Spaceboy> i'm working at NASA, one of our sattelites picked up a transmission originated from Budapest, HUNGARY 20:07 < vili> :D 20:08 < Z0l> :) 20:08 < vili> our goal is world domination 20:08 < Spaceboy> if that is the case, i have to report this to international authorities 20:09 < Spaceboy> and by the way, your message 'Niggerek vagytok mind' never reach mars i'm sorry 20:09 < mosquito> :) 20:09 < szaboat> :D 20:09 < Z0l> :DDD 20:10 < vili> :D
Akit érdekel a téma, annak ezt a prezentációt tudom ajánlom, néhány ezer dollárból bárki beszállhat Jim-ék égkémlelős projektjébe ;)
Az Electronic Frontier Foundation jelentése szerint június óta legalább négy CA-nál észleltek jogosulatlan tanúsítvány-kibocsátást - ehhez képest a nagyérdemű egy ilyen esetről, a DigiNotar-éról hallhatott (volt még egy Comodo is, de az június előtti eset). Az eredmények az SSL Observatory adataira alapulnak, melyben egyszerűen azt vizsgálták, hogy az X.509-es Tanúsítvány Visszavonási Listákban (CRL) hol szerepel a visszavonás indokaként a "Kompromittált CA" megjegyzés.
A webes tranzakciók védelme csak annyira erős, mint a leggyengébb CA, CA-ból pedig nagyon sok van. A DigiNotar-t annak idején főként azért érte éles kritika, mert - bízva saját incidenskezelésük hatékonyságában - nem hozták nyilvánosságra az őket ért támadás tényét, ezzel védhetetlen helyzetbe hozva elsősorban a közvetlen célpontokat, de elméletileg az összes internetfelhasználót is. A mostani eredmény azt mutatja, hogy a DigiNotar esete egyáltalán nem volt kivételes sőt, a statisztika szerint havonta elesik egy tanúsító, minderről a széles közvélemény pedig mit sem tud. És bár a statisztika néha rosszabb a hazugságnál, vegyük számításba azt is, hogy ezek azok az esetek, amelyek kiderültek, és ahol a tanúsító legalább a CRL-en elismerte az incidenst!
Az EFF szerint a nyilvános-kulcsú instrastruktúra sürgős beavatkozást igényel, a probléma azonban nem megoldhatatlan. Megoldási javaslataikat egy későbbi cikkben fogják megjelentetni.
Offtopic: Érdekes lenne megnézni, hogy augusztus óta melyik magyar CA vont vissza tanúsítványokat...
Az utóbbi napokban beesett több, a Facebook biztonságával kapcsolatos hír, melyek egyrészt remek poszttémaként szolgálnak, másrészt viszont előhozzák belőlem a Vágó Istvánt :)
Elsőnek ott van Nathan Power által felfedezett hiba, melynek segítségével nem megengedett kiterjesztésű fájlokat lehet küldözgetni - pl. EXE-ket - a felhasználóknak, mindössze egy space hozzácsapásával a fájlnév (kiterjesztés) végéhez a multipart POST kérésben. Az eset egyrészt jó példa arra, hogy még a Facebook programozóinak sem triviális a biztonságos fájlfeltöltés-kezelés, másrészt viszont azt is látnunk kell, hogy manapság már szinte bármilyen típusú fájlba csempészhető futtatható kód, ha bugos az olvasó program. Éppen ezért a Facebooknál minden csatolmányt vírusellenőrzés alá vetnek. Ebből a cikkből kiderül, hogy a Facebook Immune System naponta 25 milliárd kérést ellenőriz, ami egy elég szép szám.
Persze a leggyengébb láncszem - egy közösségi portál esetében főleg - az ember, ezért a hozzáférésvezérlés terén is folyamatosak a fejlesztések. Egy valóban hasznosnak ígérkező, elegáns megoldásnak tűnik a Megbízható Ismerősök rendszere. Ennek alapja, hogy minden felhasználó meghatározhat 3-5 cimbit, akikre számíthat, ha esetleg egy rosszindulatú támadás, vagy netán feledékenység miatt kizárul a saját fiókjából. Ebben a kellemetlen esetben a FB egy-egy kóddarabot küld ezeknek a Megbízható Ismerősöknek, melyeket összegyűjtve újra vissza lehet jelentkezni az oldalra.
A másik újdonság az alkalmazásjelszavak bevezetése: az alkalmazások eléréséhez egyedi jelszavakat rendelhetünk. Az első gondolatom az volt, hogy ez talán akkor lehet hasznos, ha egy gonosz támadó nem elégszik meg a fiók elbitorlásával, de még a Farmville gazdaságunkat is tönkre akarja tenni. A valóság azonban ennél egy fokkal bonyolultabb, a probléma egy másik biztonsági funkció, a Login Approvals környékén keresendő. A Login Approvals annyit tud, hogy a rendszer SMS-es autentikációt is kikényszerít, ha ismeretlen eszközről (ahol nincs meg a FB ránk szabott sütije) próbálunk bejelentkezni. A probléma az, hogy néhány alkalmazás (pl.: Spotify) nem jól kezeli ezt a funkciót, így ismeretlen eszközről ezeket használni nem tudjuk. Az alkalmazásjelszó ezt a problémát hidalja át, tehát (ha jól értem) egy funkcionális javításról van szó, amit mellesleg jól el lehet adni biztonsági funkcióként, mert szerepel a nevében a "Password" szó...
És a végére még egy kis kötözködés: a Login Approvals nem működik túl jól privát böngészés közben, mivel ilyen esetben a böngésző nem tartja meg a sütiket. A Súgó persze segít, a furcsa csak az, hogy míg a funkció bekapcsolását három egyszerű mondatban írja le az oldal, addig a privát böngészés / automata sütitörlés kikapcsolását ugyanabban a pontban három böngészőre, öt képernyőképpel illusztrálva mutatják be. A nyomon követett felhasználók nyilván értékesebbek ;)
Megjelent a Tor legújabb változata, amely több anonimitást érintő biztonsági problémát orvosol, ezért mindenkinek javasolt a frissítés. A most javított problémáknak nincs köze a francia ESIEA kutatói által bejelentett, felhype-olt támadáshoz, a veszély ebben az esetben viszont sokkal valóságosabbnak tűnik.
A most javított hibák közül a legfontosabb négy körülmény együttállásából adódott:
A kliensek újrahasznosították a relay-ekhez történő kapcsolódáshoz használt TLS tanúsítványaikat
Egy kliens tanúsítvány alapján egy támadó lekérdezhette egy guard relay-től, hogy a tanúsítvány tulajdonosa éppen kapcsolódik-e hozzá
Számos olyan módszer ismert, mellyel egy támadó weboldal megtudhatja, hogy egy látogatója mely guard relay-eket használja
A kliensek tipikusan három véletlen guard relay-t választanak, a választás a felhasználó egyedi jellemzőjének tekinthető.
A javítással az első két pontot kihúzták a listáról. A javítás ezen túl bridge-enumerációt gátló módosításokat is tartalmaz.
Aki ismer, az tudja, hogy egy jó ír sörrel mindig mosolyt lehet csalni az arcomra, így a szokásosnál is fájóbb szívvel kell tudomásul vennem, hogy az Irish Cat Pub már egy hete nem válaszol a megkeresésemre. Attilla hívta fel a figyelmemet erre a nem kifejezetten szívderítő felületre, melynek viselkedését a felhasználó sajnos közvetlenül befolyásolhatja:
Ha a környéken jártok, dobjatok be egy sört, és szóljatok a csaposnak!
A The Hackers Choice nyilvánosságra hozta SSL DoS eszközét (TLS-el is működik), amely a titkosított kapcsolatok létrehozásakor a csatlakozó kliens és a szerver között fellépő számításigénybeli aránytalanságokra épül. A THC szerint egy átlagos kiszolgáló nagyjából 300 kézfogást képes lebonyolítani másodpercenként, kliens oldalon ennyi kapcsolat kezelésére ugyanakkor a CPU teljesítményének 10-15%-a is elég lehet.
A probléma 2003 óta ismert, az eszköz kiadása leginkább a figyelemfelkeltés miatt említésre méltó: akár egy "./configure;make" varázskombinációt kiadni képes script kiddie is le tud dönteni nagy cégeket, megoldást pedig egyelőre nem látunk a problémára a plusz hardver bevezetésén túl.
Érdemes elolvasni Eric Rescorla értekezését, ami egyszerűen levezeti, hogy a támadó szemszögéből érdemesebb mindig új TCP kapcsolatot (és új TLS kapcsolatot) nyitni, mint egy meglévő adatfolyamban újraegyeztetést kérni, mivel utóbbi esetben nem használhatók előre gyártott válaszcsomagok, hanem a támadónak is számításigényes műveleteket kell végeznie az áldozat szerver emgteheléséhez.
Kaptam a témában pár keresési találatot, szóval adjunk a SEO-nak :)
Feross Aboukhadijeh egy trükkös clickjacking támadást eszelt ki az Adobe Settings Managere ellen, melnyek segítségével a felhasználó rávehető, hogy bekapcsolja a webkameráját, anélkül, hogy tudna erről. A Settings Manager egy sima SWF alkalmazás, melyet általában az adobe.com-ba ágyazva érünk el. Egy JavaScript megakadályozza a beágyazó oldal IFRAME-be töltését (ami a támadás alapja lehetne), de ha közvetlenül az SWF fájlra hivatkozunk, ez a védelmi mechanizmus már nem szól bele a játékba.
Innentől pedig prezentálhatunk a kedves áldozatnak valamilyen "találd el a meztelen Jessica Albát" jellegű játékot, és kis szerencsével (no meg jó időzítések beállításával) máris aktiváltuk virtuális poloskánkat:
Reméltem, hogy nem jut el a magyar médiába a hír, mielőtt megjelennek a részletek...
A ESIEA francia kutatói felfedeztek és sikeresen kihasználtak néhány súlyos sérülékenységet a TOR hálózatban. A sérülékenységeket kihasználva készítettek egy listát a hálózatról benne 6000 géppel, melyek közül volta IPk amelyek publikusan elérhetőek voltak a rendszer forrásjódjával. A kutatók azt is bemutatták, hogyan lehetséges átvenni az irányítást a hálózat felett és elolvasni minden üzenetet, ami azon keresztül folyik.
Léteznek a rendszerben rejtett node-ok is, a Tor hidak (Tor Bridges), amelyeket bizonyos esetekben a rendszer biztosít. A kutatók arra is kidolgoztak egy módszert, hogy miként lehet ezeket a node-okat azonosítani. Összesen 181 ilyen rejtett node-ot találtak, feltérképezve ezzel a Tor teljes topológiáját.
A Tor Project blogposztban reagált a hírre. Ebben kiemelik, hogy részletek hiányában ők sem tudják pontosan megítélni a kutatás jelentőségét, de az már most látszik, hogy a francia kollegák téves feltevésekből kiindulva téves következtetésekre jutottak:
Először is a Tor hálózatban lévő relék száma nyilvános, általában 2500 körül mozog, ehhez nem kell semmilyen kutatás. Nem tudni, hogy az említett 6000 csomópont hogyan jött ki. A bridge-ek számát viszont sikerült jócskán alábecsülni: kb. 600 ilyen kiszolgáló van nyilvántartva jelenleg, így ha a felfedezett 181 állomás mindegyike valóban bridge, még akkor is messze van a teljes hálózat feltérképezése.
Az üzenetek elolvasását a kutatók egy demó hálózatban tesztelték. A kiinduló feltevés az volt, hogy a csomópontok egyharmada sebezhető, ezért ezek felett átvehető az irányítás (ezt minden bizonnyal nem ellenőrizték élesben). Amennyiben egy TOR útvonal összes gépét a támadó birtokolja, az átfolyó forgalom lehallgatható. Ehhez azonban meg kell oldani, hogy a forgalom a nem kompromittált hosztokról a kompromittáltak felé haladjon. Erre ugyan léteznek módszerek, mivel azonban a terheléselosztás a hálózatban kapacitás alapján történik, a támadó esélye a sikerre nem attól függ, hogy hány csomópontot, hanem hogy mekkora sávszélességet birtokol - a Tor Project közleménye szerint utóbbira szert tenni jóval nehezebb (logikus: kizárólag ritka, nagy kapacsitású relékből kell minél több diszjunkt utat kiépíteni).
A projekt a fentiektől függetlenül kíváncsian várja a részleteket, melyeket a Hackers to Hackers konferencián fognak prezentálni.
Jótanács: a thehackernews.com-ot ne tekintsétek megbízható hírforrásnak, általában fogalmatlan kiddie-k publikálnak rajta!
Frissítés:Itt megtekinthetők a lefotózott diák. Eddig nem fedeztem fel bennük újdonságot.
Tibor Jager és Somorovsky Juraj olyan problémát demontráltak a World Wide Web Consortium által szabványosított XML titkosítási eljárásával kapcsolatban, amely lehetővé teszi a titkosított üzenetek kulcs nélkül történő megfejtését. Ugyan a kutatási anyag egyelőre nem érhető el nyilvánosan (najó, 15$-ért letölthető), de a rendelkezésre álló információk alapján ismét egy padding oracle támadásról van szó. Az XML Encryption-t több nagy gyártó (MS, IBM, Apache, stb.) termékeiben is implementálták, a tesztelt termékek mindegyike sebezhetőnek bizonyult. A kutatás eredményeként valószínűleg frissíteni kell a W3C szabványát, az implementációkat pedig az új változatnak megfelelően javítani kell.
Az utóbbi napok elég izgalmasan teltek: mint kiderült, a világon elsőként a BME-n működő CrySys labor munkatársai észlelték és elemezték ki a Stuxnet utódjának tekintett DuQu trójait - nem kell kontógyárosnak lenni ahhoz, hogy feltételezzük, a kötvetkező virtuális ütközethez kis hazánkban keresett valaki információt, lenyúlható titkos kulcsot, rejtőzködésre alkalmas proxy-t, vagy ki tudja mi mást.
Idő közben sikerült részletesebben átnéztem a Symantec által publikált elemzést (amely mellékletként az itthoni kollegák eredményeit is tartalmazza). Sajnos ez sem segített kikergetni a fülemből az Alexander Sotirov által oda helyezett bolhát: ha a biztonsági szoftverek gyártói - kompetenciájukról méltó tanúságot téve - ilyen szép elemzéseket képesek publikálni, miért nem kapták el a termékeik a kártevőt már településkor? Nézzük hát meg, milyen módszereket használ a DuQu a felismerés elkerüléséhez!
Nyilvánvaló megoldás lehetne a HTTP proxy felfedezésére a webszerver OPTIONS metódusa, azonban sok esetben - és ebben a példában is - a kiszolgáló bizony hazudik saját képességeit illetően.
A localhoston figyelő FTP szervert leginkább egy egyszerű szkripttel lehet felfedezni, ami sorban próbál CONNECT-elni a lehetséges portokra, "Connection Established" válasznál örülünk. Edit: Az is előnyös, ha az agyunk nem ignorálja automatikusan a filtered státuszú portokat az nmap kimenetén :)
Hali! Minap nézelődtem a CBA weboldalán és elég egyszerűen sikerült bejutnom, a webáruházuk admin felületére. (Egyszerű sql injection, amit bárki meg tud csinálni..) A jelszavak md5 ben vannak tárolva, körülbelül 30 "admin" felhasználó van. Egy felhasználó van aki mindent tud szerkeszteni. Minden sql ismeret nélkül is ki lehet találni, mivel a felhasználónév és jelszó: iXXXXXXXXXa/cXXXXX4
A CBA-nak október 14-én jeleztem a problémát, válasz nem jött :(
Szóval a Symantec-nél kielemeztek egy trójait, melynek komponensei nagyfokú hasonlóságot, néhány esetben pedig teljes bináris egyezést mutatnak a Stuxnettel. A kártevőt DuQu-nak nevezték el, az általa létrehozott, ~DQ kezdetű fájlok miatt. A nagyfokú hasonlóság arra utal, hogy a DuQu készítői legalábbis hozzáfértek a Stuxnet forráskódjához (eddigi ismereteink szerint nyilvánosan csak a binárisok elérhetők). Funkcionalitásban azonban alig van köze a két szoftvernek egymáshoz: a DuQu egy távoli hozzáférést biztosító trójai, ami nem terjed, nem használ exploitokat mozgásterének kiszélesítéséhez, és egyáltalán nem piszkál semmilyen ipari vezérlőrendszert, egyszerűen információt szivárogtat a megtámadott rendszerről.
Friss: A Kaspersky egy újabb remek összefoglalót készített a történetről, melyben tisztáznak néhány fontos részletet. A DuQu - mint ahogy a Stuxnet is - két részből áll: a közös főmodul végzi a rejtőzködést, kommunikál a C&C-vel és ez tölt le más-más "tölteteket" a fertőzött gépre. Egy ilyen "töltet" a DuQu nevét adó kémprogram, ami funkcionalitását tekintve független a fő résztől, de kód szinten kimutatható a kapcsolat.
Az első észleléskor egyetlen antivírus sem ismerte fel a malware-t, persze azóta a helyzet változott, de csak az elmúlt 48 órában három új variánst fedeztek fel, a szoftver fejlesztése bevetése tehát minden bizonnyal ebben a pillanatban is folyamatban van. A helyzet tehát elég izgalmas, hát még ha azt vesszük, hogy úgy tűnik, kishazánk is kulcs szerepet játszik a történetben. Ne kapcsoljatok el! ;)
Funkcionalitása lényegében megegyezik a hasonló szoftverekével: billentyűzetfigyelés, képernyőképek gyűjtése, processz információ, hálózati felderítés. A kártevő a számítógép indításakor kernel driverként töltődik be, a services.exe után a Firefox, az Internet Explorer, egy Trend Micro-s biztonsági szoftver és az explorer.exe folyamatába igyekszik beinjektálni magát, ügyelve arra, hogy ne csapja ki a biztosítékot a népszerű víruskergetőknél (melyek egyébként igen jó hatásfokkal felismerik a binárisokat). A hálózati kommunikáció egy már lekapcsolt indiai irányító szerverrel HTTPS kapcsolaton keresztül történik, egy Taipei-i szolgáltató (azóta már visszavont) tanúsítványát használva. A vezérlő utasítások gyengén titkosítva, JPEG fájlokba (illetve ezek mellé) rejtve közlekednek.
Szakértők szerint már a Stuxnet felépítésén is látszott, hogy a szoftvert modulárisra tervezték, a kód újrahasznosításában gondolkodtak - ezt látszanak igazolni a most újra felfedezett komponensek, melyeken alig látszanak változások a Stuxnet kódjához képest.
A szép emlékű (bár én nem sokra emlékszem...) Zöld Pardon egykori weboldalával kapcsolatban nem is egy hibajelentést kaptam, és küldtem, és bár az üzemeltetők válaszra se méltattak, valahogy soha nem jutottam el a posztolásig - a pofátlan csúszásért ezúton kérnék elnézést!
Most, hogy már úgyis mindegy, igyekszem köszörülni a csorbát:
MakeSKA írta ezt réges-régen:
A kiindulási pont a zp.hu, amikor beírtam feltűnt, hogy egyből átdob egy http://ns10.cpanel.hu/~zalantXX/zp URL-re. Gondoltam megnézem ki ez a zalantXX user a cpanel szerverén (http://ns10.cpanel.hu/~zalantXX), és lám bejött a teljes könyvtárlistája, kb minden könyvtár egy weboldalt takar... De találtam köztük egy "mailer" könyvtárat, amire kattintva egy egyszerű login felületre jutottam. Gondoltam ha már itt vagyok megpróbálom a jó öreg admin:admin user-jelszó párost, és természetesen működött.
Belépve elém tárult több weboldal hírlevél feliratkozottak listája, többek között a zp teljes listája is, és még csak copy-paste sem kell, mert lehet exportálni:) ...
Aztán pt|Zool mutatott egy SQL injection hibát a gelériában:
http://www.zp.hu/kepek/?galeria=755'
Végül keptentől jött az infó, hogy bizony a ZP adatbázisa nem csak a napi menüt, meg a sör árát tartalmazza:
És még a táblanevek lekérdezésével sem kell bajlódni, ugyanis itt van nekünk ez a gyöngyszem:
http://ns10.cpanel.hu/~zalantXX/zp/backup/
Természetesen nem nagyon turkáltam bele, de ami biztos, hogy több ezer 18 éven aluli "Zöldkártya" tulajdonos adatait tárolja a rendszer, ami illetéktelenek kezébe korántsem való...
A fent említett belépési pontok egy része sajnos még most, a zp.hu bezárása után is működik.
Hogy a jövőben ne vétsek hasonló hibát (két évig porosodik egy hiba a postaládában :( ), fejlesztettem a folyamataimon, és most már nyilvántartást vezetek a beküldött problémákról, az üzemeltető felé történt jelzés, és az esetleges visszajelzés/javítás időpontjáról, amiből remélhetőleg majd szép statisztikákat is fogok tudni gyártani.
Ez a műfaj alapvetően a kreativitásról szól, de azért néha nem árt, ha észben tartod, mi mindenről olvastál az elmúlt években ;)
Az SSH szerver azért olyan dög lassú, mert több száz (ezer?) publikus kulcs volt megadva szegény SSH felhasználó Róbertnek, hogy biztosan időben beletrafáljatok egy megfelelőbe. A könyvtárlistázó parancsok ugyanis általában nem ABC sorrendben, hanem az aktuális fájlrendszer inode(?) kiosztása alapján listáznak, így nem lehet megjósolni, ki milyen sorrendben fog próbálgatni.
A kulcspróbálgató szkript ékes példája annak, hogy az ember ne ész nélkül használja a netről bányászott eszközöket. Az elérhető 4-5 szkript közül nekünk alapból nem működött egyik sem azonnal, ki kellett iktatni az openssh-blacklistet a támadó hosztról, idő közben pedig a $? viselkedése is megváltozott Ruby-ban...
A végén nem találom a proof.txt-t, mivel a sudo alapból nem állítja az environmentet - bocs a bénázásért :)
Az Apple tegnap és ma számos frissítést tett közzé különböző termékeihez, köztük az OS X-hez, a Safarihoz és az iOS-hez. A több száz hibajavítás között találunk foltott két éves BIND hibára, de olyan újdonságnak számító változtatások is bekerültek a csomagba, mint a TLS v1.2 támogatás. A javítások jelentős persze most is a különböző médiafeldolgozó rutinokat érinti, illetve szintén nagy számban vannak jelen az XSS, vagy azzal rokon webes sebezhetőségek.
Teljes listáért a fent linkelt hivatalos Apple oldalakat tudom ajánlani (bár a hibaleírások szokás szerint elég szűkszavúak), én most egyetlen hibát emelnék ki a sok közül (via @sghctoma) - az alábbi egyszerű HTML/JS oldal azt demonstrálja, hogyan lehetett tetszőleges helyi alkalmazást távolról futtatni a Safarin keresztül:
Az bizonyos, hogy 2011. október 12. nem fog bekerülni a Sony aranykönyvébe, ugyanis a cég két súlyos incidenst volt kénytelen elismerni: egyrészt bejelentették, hogy 1,6 millió, 2007 óta Európában eladott Bravia LCD-televíziót kénytelenek visszahívni, ugyanis a készülékek tűzveszélyesek, másrészt pedig a vállalat közölte, hogy újra támadás érte a játékok számára fenntartott PlayStation Networköt, illetve két másik hálózatot, és összesen közel százezer játékos felhasználói fiókja kompromittálódott.
[...] bejelentették, hogy ismét feltörtek, vagy legalábbis megkíséreltek feltörni felhasználói fiókokat. A cég hivatalos közleményei szerint, most egész más módszerű behatolási kísérletről van szó, mint tavasszal, amikor több mint 100 millió felhasználó adataihoz fértek hozzá: most nem közvetlenül a három nagy szolgáltatást (PlayStation Network, Sony Entertainment Network, Sony Online Entertainment) működtető szerverekre törtek be, hanem más oldalakon megszerzett azonosítási adatokkal próbálkoztak a támadók.
93000 játékos használta ugyazt a jelszót több helyen - erre most ráfáztak. A Sony jelszó resetet kényszerít ki az érintett fiókokra, bár feltételezve, hogy ezek tulajdonosai nem csak két helyen használták ugyanazt a jelszót, a támadók valószínűleg az e-mail fiókokban is ott vannak.
Beköszöntött a hideg, de a Microsoft egy nagy adag frissítéssel gondoskodik róla, hogy égjen a kezünk alatt a munka. A szokásos javítócsomagok mellett megjelent a Microsoft Security Intelligence Report legfrissebb kiadása is, melynek tanúsága szerint a támadások 99%-a még mindig olyan sebezhetőségeken keresztül érkezik, melyekre már létezik javítás.
"I refuse to be a victim!" :)
MS11-078: Egy .NET keretrendszert és a Silverlightot érintő sebezhetőség javítása. Ahogy ez az ilyen hibák esetében lenni szokott, most két három támadási vektor képzelhető el: egyrészt XBAP-t támogatő böngészőkön, másrészt ASP.NET oldalak feltöltését támogató (pl. shared hosting) webszervereken, vagy megbízhatatlan forrásból származó .NET alkalmazásokat futtató hosztokon keresztüli távoli kódfuttatás - utóbbi két esetben megkerülhető a Code Access Security. A leírás alapján a probléma oka az osztályok származtatásának korlátozával kapcsolatos, valószínűleg tervezési hibáról van szó.
MS11-079: Öt hibajavítás a Forefront Unified Gatewayhez. Négy ezek közül "egyszerű" Response Splitting illetve XSS hibákat orvosol, az ötödik pedig egy valamivel érekesebb, az UAG által kliensekre telepített Java appletet érintő sebezhetőség. Ezt kihasználva távoli kódfuttatás érhető el a kliens rendszereken. A hiba részletei nem ismertek, de érdemes lehet ráküldeni egy decompilert a .jar két változatára... Friss: itt vannak a részletek az utolsó hibáról.
MS11-080: Jogosultságkiterjesztésre alkalmas probléma az Ancillary Funcion Driverben. Az AFD a Winsock TCP/IP kapcsolatok kezeléséért felelős Windows XP és 2003 rendszereken - ezek a Windows változatok érintettek.
MS11-081: Nyolc hibajavítás az Internet Explorerhez - a javítócsomag telepítésével távoli kódfuttatásra alkalmaz sebezhetőségek foltozhatók be. A böngésző összes változata (6-9) számára kritikus besorolást kapott a csomag, szervereken a szigorúbb alapértelmezett beállítások csökkentik a kockázatot.
MS11-082: A Host Integration Server 2000-nél későbbi változatai távolról lelőhetők. Leírás illetve PoC exploit található itt és itt.
Ismeretlen támadók hozzáfértek a WineHQ, a népszerű nyílt-forrású Windows emulátor adatbázisaihoz. Jeremy White levele szerint a támadás a phpMyAdmin alkalmazáson keresztül érkezett, egy kompromittált felhasználói hozzáférésen, vagy egy eddig ismeretlen phpMyAdmin hibán keresztül. A támadók nem próbáltak meg kárt tenni a bugzilla és az appdb adataiban, amelyekhez hozzáfértek, de letölthették egyebek mellett a felhasználói adatokat, ide értve a hashelt jelszavakat is.
A Chaos Computer Club megszerezte és kielemezte a német kormány által fejlesztett, Quellen-TKÜ névre keresztelt "lehallgató eszközt".
A CCC már 2008 óta figyelemmel kíséri a szoftver fejlesztését. A német alkotmánybíróság három éve kimondta, hogy az állampolgárok magánszférájának léteznek olyan részei, melyek semmilyen körülmények között sem figyelhetők meg - ilyen például egy napló vagy a házastársak hálószobai beszélgetései. Ezzel összhangban kikötötték, hogy a Quellen-TKÜ csak a megfigyelt személy számítógépén zajlő telekommunikáció megfigyelésére lehet alkalmas. Már a rendelkezés megszületése előtt született egy "light" változat a szoftverből, amely a remények szerint eleget kellett volna tegyen az alkotmánybíróság igényeinek.
A CCC elemzése ezzel szemben azt állapítja meg, hogy a szoftver teljes kontrollt biztosít a megfigyelt számítógépek felett, segítségével tetszőleges más program telepíthető azokra, a mikrofon és kamera bekapcsolásával pedig a fizikai környezet lehallgatására is alkalmat ad. Emellett a vezérlő szoftverrel történő kommunikációnak csak egy része titkosított (ECB módú AES-128 :P), de egyáltalán nem autentikált, az átmenő adatok integritása nem ellenőrzött. Ez lehetőséget ad bizonyítékként letöltött adatok meghamisítására, vagy hamis bizonyítékok eljuttatására a célgépre - a gépet használó vagy akár a hálózati kapcsolatba beékelődő támadó számára is. A trójai ezen felül úgy fedi el az őt vezérlő szerver címét, hogy egy amerikai szerveren keresztül irányítja a forgalmat, ezzel akár nemzetbiztonsági kockázatnak kitéve Németországot.
A teljes elemzés német nyelven elolvasható itt. A CCC a szoftver további elemzésére bátorítja a hacker közösséget.
Frissítés:Az F-Secure szerint nem bizonyított, hogy kormányzati szoftverről lenne szó, ezért felvettek egy mintát az adatbázisaikba, amely Backdoor:W32/R2D2.A néven ismeri fel a szoftvert. A név a bedrótozott "C3PO-r2d2-POE" sztringből ered, melyet a a trójai bannerként használ a kommunikáció megkezdésekor.
A Context csapata olyan hibát fedezett fel az Apache webszerver mod_rewrite moduljában, amely bizonyos konfigurációk esetén hozzáférést enged Internet felől egyébként elérhetetlen belső hálózati hosztokhoz.
A probléma tipikusan akkor jelentkezik, amikor egy Apache reverse proxy irányítja a forgalmat, pl. terhelésmegosztás céljából statikus illetve dinamikus tartalmakat kiszolgáló belső hosztok között. Az alábbi módon megadott szabály esetén a @ karaktert használva tetszőleges belső hosztra irányítható a forgalom:
RewriteRule ^(.*) http://belsohoszt:80$1
Egy hibát kihasználó kérés részlet:
GET @kivulrolnemelerhetohoszt:80 HTTP/1.1
A szabály alkalmazása után nyilvánvalóan a http://belsohoszt:80@kivulrolnemelerhetohoszt:80 URL töltődik be, melyben a belsohoszt string nem hosztnevet, hanem felhasználónevet (az első 80 pedig jelszót) jelöl, a ténylegesen megszólított hoszt pedig a kivulrolnemelerhetohoszt lesz.
Az ASF patch-et készített a probléma orvoslására a kiszolgáló 2.2.21-es változatához.
