A legalább november vége óta aktívan kihasznált 0-day Abode Reader és Acrobat sebezhetőséget a gyártó csak a január 12-én esedékes rendszeres negyedévi fogja javítani. Egy ComputerWorld-nek adott interjúban Brad Arkin, az Adobe termékbiztonságért felelős igazgatója elmondta, hogy egy cikluson kívüli patch kiadásával veszélyeztetnék a negyedéves foltcsomag elkészültét, ráadásul a nagyvállalatoknak is többletköltséget jelentene a többszöri frissítés. Elkerülő megoldásként továbbra is a JavaScript kikapcsolása ajánlott, valamint az októberi frissítést telepítők számára már elérhető a JavaScript Blacklist Framework is, melynek segítségével feketelistára tehetők az érintett API funkciók a JavaScript feldolgozás teljes letiltása nélkül. Az persze továbbra is érdekelne, hogy ki, mire és miért használ PDF-be ágazott JavaScriptet...

Miután nyilvánosságra került a Microsoft igazságügyi szakértői munkát segítő szoftvere, a COFEE, várható volt valamiféle válaszreakció a túloldalról. Ez a DECAF nevű eszközben öltött testet, amely képes érzékelni, ha COFEE-val felvértezett adathordozót csatlakoztatnak az általa őrzött számítógépre, majd előre definiált műveleteket képes végrehajtani. Ezek között szerepel az USB és lemezmeghajtók letiltása, a számítógép kikapcsolása (titkosított partíciók esetében ez különösen hasznos lehet), a hálózati interfészcímek meghamisítása, futó folyamatok kilövése vagy fájlok törlése. A fejlesztők külön figyelmet fordítottak a BitTorrent kliensek eltüntetésére is.

Egyik kedves régi olvasóm a múltkori BKV-s poszton felbuzdulva elkezdte nézegetni az elméletileg mostanában élesedő új BKV weboldal háza táját. Már többször megállapíthattuk (és ezt jól jegyezze meg mindenki!), kár túlkombinálni a dolgokat - ezesetben pl. ott figyelt egy ostoba módon beállított phpMyAdmin a webszerveren:

Az persze egy dolog, hogy egy tesztoldalról van szó, node

• phpMyAdmin-t publikus felületen nem hagyunk kint! Főleg nem úgy hogy még egy átlagosnál hülyébb neandervölgyi is be tudjon rá lépni rootként...
• Könyörgöm, hash-eljük már le azokat a rohadt jelszavakat! Így is annyi személyes adat van ezen a fotón, hogy alig győztem feketíteni... Másik kérdés hogy ki az a hülye önkéntes tesztelő, aki még a mobilszámát is megadja?
• Csak a szépségérzetem miatt: 400+ adattáblát biztos hogy egy adatbázisba kell szervezni? További remek adatbázisszervezési ismeretekről árulkodik a következő kis részlet:

• Ínyenceknek ajánlom a forráskódok böngészését is, van külön antihekker modul is! Szép kis káosz uralkodik amúgy a kódban, nyakatekert megoldások triviális problémákra, a kommentárok gyakorlatilag ismeretlenek, csak úgy mint az előkészített lekérdezések... mondjuk azokhoz már kéne némi objektumorientált szemlélet is :P Legszívesebben elküldeném az egészet a dailyWTF-ra.

És hogy ki végezte ezt a remek munkát? A szemfülesek ezt is leolvashatják az első képről :) A korrupt döntéshozóknak pedig gratulálok az újabb remek választásért!

Azt mondja az Index:

A katonai szintű titkosító technológiákat fejlesztő izraeli cég provokálja a hackereket, és aranyrudakat ajánl annak, aki feltöri az algoritmusát. Az előző versenyükön nem volt győztes.

A hírt kb. két hete olvastam valahol, és már akkor is azt gondoltam, hogy ez egyszerű marketingfogás, ami nem érdemel sok szót. Most viszont, hogy magyarul is megjelent, na meg mivel kaptam egy tippet, hogy Schneier bácsi már megmondta a tutit a hasonló nagyotmondásokkal kapcsolatban, úgy gondoltam osztok egy kis észt: 

Először is, pusztán egy tízperces mintából megfejteni akármit csak a letriviálisabb algoritmusok esetén esélyes. A helyzet hasonló ahhoz, mint amikor az önjelölt jövőbelátók megfejtik valamelyik szent írásba rejtett "előrejelzéseket":  tetszőleges két bithalmaz között (az információelmélet határain belül) található egy megfelelő "titkosító algoritmus", amely az egyiket a másikba viszi át.

A Gold Lock esetében kicsit jobb a helyzet, ugyanis legalább a titkosító szoftverek elérhetőek, így az algoritmus (minden bizonnyal keserves munka árán) visszafejthető, plusz a cég azt is elárulja, hogy az AES szimmetrikus algoritmust, elliptikus görbéket és Diffie-Hellman kulccserét alkalmaz. Na itt álljunk meg egy-két szóra:

• Az elliptikus görbéken alapuló eljárások nyilvános kulcsúak, akkor minek a kulccsere? 
• A sajtóanyagban az szerepel, hogy folyamatosan változnak a kulcsok. Köztudott, hogy kulcspárokat generálni nem kis számításigényű művelet, főleg egy telefon hardverén, szóval szerintem inkább maradjunk a Diffie-Hellmannál
• Ha rágugliztok a Gold Lockra, olyan hírdetést is láttok, hogy konkrétan az AES 256 bites változatát alkalmazza a cég. A sok bit az jó, csak nem ebben az esetben: nem olyan régen írtam az AES 256 kulcsidőzítőjét érintő problémáról, ami főleg ilyen, gyakori kulcsváltásokkal operáló alkalmazásoknál lehet kritikus.

Ez persze nem azt jelenti, hogy az algoritmus/protokoll rossz, de jó kicsit végiggondolni a hasonló dolgokat, mikor egy ilyen hírt hallunk. De nézzük végig Schneier úr vezényletével, hogy miért is értelmetlenek az ilyen versenyek:

Az bizonytalanságon alapuló biztonság (security through obscurity) nem működik, különösen a kriptográfia területén nem. Amennyiben meg akarjuk vizsgálni egy algoritmus jóságát, fel kell tételeznünk, hogy a támadó mindenhez hozzáfér az algoritmus "titkán" (ez általában a titkosítási kulcs) kívül. Gondoljunk bele: egy háborús szituációban az ellenség simán megszerezheti a titkosító algoritmus specifikációját (ahogy az Enigma esetében történt), hozzáférhet bizonyos nyílt-titkos szöveg párokhoz, vagy akár a titkosító kulcsok bizonyos részeihez vagy transzformáltjaihoz is! Mindez igen komoly segítséget adhat egy ismeretlen kriptoszöveg megfejtéséhez, a versenyeztetők azonban általában nem adják meg mindezeket az információkat.

Ezek mellet nem szabad elfeledkeznünk arról sem, hogy kik és hogyan végzik a vizsgálatokat? Egyáltalán nem biztos, hogy egyáltalán van olyan kompetens szakértő, aki hozzálát a megoldáshoz. A próbálkozók munkáját senki sem koordinálja, lehet hogy mindenki ugyanazokat a vakvágányokat futja végig. A fődíj megnyerésére pályázók pedig valójában jobban tennék, ha lottóznak: a szerencsejátékok befektetésigénye jóval kevesebb, mint amennyi időt és energiát egy ilyen bizonytalan kimenetelű munka igényel.  

Ha tehát a versenynek nem lesz nyertese, az nem jelent semmit az algoritmus minőségével vagy a szakértők képességeivel kapcsolatban. Különben is: Nagyon jó, sokat vizsgált kriptográfiai algoritmusokat ismerünk és alkalmazunk nap mint nap, amelyek bár elméletileg feltörhetők, ehhez jelenlegi ismereteink szerint több idő és energia lenne szükséges, mint amennyit akár csak el tudnánk képzelni.

Szóval ne dőljünk be az olcsó marketingfogásoknak, inkább higyjünk a matematikának és a józan észnek!

Javítatlan Adobe Reader sebezhetőséget kihasználó exploittal garázdálkodnak újabban a rosszemberek. A hivatalos blog szerint a Reader és Acrobat termékeket egyaránt érinti a probléma. A sebezhetőség részletei nem kerültek nyilvánosságra ezidáig, de CVE már nyílt, érdemes azt monitorozni a további információkért.

Még egyszer felhívnám a figyelmet, hogy (bár egyes híradások az ellenkezőjét sugallhatják) a sebezhetőségekre jelenleg nincs hivatalos javítás, az egyetlen megoldást (a váltáson kívül) a JavaScript letiltása jelenti, valahogy így:

Szerkesztés->Tulajdonságok->JavaScript-> vedd ki a pipát az engedélyezés mellől

Frissítés: A sebezhetőség kihasználására használható Metasploit modul elérhető itt. Demonstrációs videó erre.

Most szombaton a Független Magyar Tudásközpont (H.A.C.K.) workshopot rendez a Fogasházban (Budapest VII. Akácfa utca 51), ahová szeretettel várjuk a lelkes-szomjas érdeklődőket! A programpontok között szerepel a 3D nyomtató hackelése, meg lehet ismerkedni a hackerspace tagjaival valamint magával a kezdeményezéssel, a kocka/m2 arány pedig garantálja a buherasörözéseken már megszokott jó hangulatot. 

A workshop 15:00-tól kezdődik és nagyjából 20:00-ig tart, de ez után is természetesen lehet maradni dumálni, sörözni, vagy hajtani a virtuális gyöngyfűző lányokat :) Egyébként Lollipop Factory buli lesz aznap a helyen.

Ezt az alkalmat tekinthetitek pót-BuheraSörözésnek [sic], sajnos hagyományos formátumú összejövetelt idén már nem tudok leszervezni.

Elmaradt az esti előrehozott sörözés, szóval lett egy kis időm összerántani az elmúlt frissítőkedd érdekességeit, voilá:

MS09-069: Távoli, DoS előidézésére alkalmas sebezhetőség a Windows 2000, 2003 és XP LSASS szolgáltatásában. A problémát speciális IPSec csomagok segítségével lehet kihasználni, autentikáció nem szükséges.

MS09-070: Autentikált felhasználók speciális HTTP kérések segítségével távolról kódot futtathatnak olyan webkiszolgálókon, melyeken engedélyezve van az Active Directory Federation Services szolgáltatás. A javítócsomagban orvosolt másik sebezhetőség felhasználók megszemélyesítését teszi lehetővé, amennyiben egy támadó hozzáférést szerez egy munkaállomáshoz, ahonnan előzőleg sikeres hitelesítést hajtottak végre. 

MS09-071: Távoli kódfuttatásra valamint privilégiumszint-emelésre alkalmas problémák az Internet Authentication Service illetve Network Policy Server szolgáltatásokban a PEAP és MS-CHAP v2 protokollok alkalmazásakor. A problémák a RADIUS szerver funkciót ellátó  kiszolgálókat érinti, ezek közül pedig a 32 és 64 bites Windows 2008 Serverek vannak a legnagyobb veszélyben, mivel míg a régebbi változatokban ugyan megtalálhatók a hibás kódrészletek, ezek nem kerülnek felhasználásra a szolgáltatások implementációiban. 

MS09-072: Az utóbbi időben elmaradhatatlanok a különböző, ATL-el összefüggő problémák, most egy ilyet kapunk egybecsomagolva három másik Internet Explorer sebezhetőséggel - utóbbiak inicializálatlan, vagy már felszabadított memóriaterületek használatából adódnak. A sebezhetőségek kritkus besorolást kaptak a böngésző gyakorlatilag összes (értsd: 5-ös vagy újabb!) változatára nézve, mivel kódfuttatást tesznek lehetővé közvetlenül egy speciális weboldal megtekintésén keresztül. A CVE-2009-3672 jelű hibához elvileg publikusan elérhető exploit, nekem ezt nem sikerült megtalálnom, részben mivel az OSVDB HTTP500-at dobál.

MS09-073: Kódfuttatásra alkalamas sebezhetőségek a WordPad-ben és az Office Text Converter komponenseiben. Windows 2000, 2003 és XP.

MS09-074: Az előzőhöz hasonló, MS Project-et érintő hibák javítása. 

Aki telepíti a frissítéseket gazdagabb lesz az Extended Protection for Authentication nevű csodával, ami megerősített autentikációt biztosít megfelelően konfigurált windowsos HTTP kliensek és szerverek között. A módszer lényegében a Kerberos és NTLM hitelesítési protokollok ellen elkövetett közbeékelődéses támadásokat hárítja el azáltal, hogy megakadályozza a megszerzeti hitelesítő adatok újrafelhasználását. Bővebb leírás itt található. Búcsúzóul kaptok egy kis chiptune-t, ez tartott ébren idáig:

Először is szeretném a figyelmetekbe ajánlani a címben szereplő remek oldalt (nye, adok pageranket is :), melyen a BME különböző (általában "nagy látogatottságú" :) előadásait tekinthetitek meg ingyen, otthoról, akkor is ha nem vagytok hallgatók (legalábbis egyelőre). Éljen a szabad információáramlás!

Másrészt viszont stef hívta fel rá a figyelmemet még múlt hét szerdán, hogy az oldal fórumában nem, csak az oldal forrásában jelenik meg kacsacsőr jel, ami ugyebár nem utal sok jóra. Nem kellett sokat keresgélni ahhoz, hogy kiderüljön, hogy a oldal SQL injectionnel is sebezhető. Mindez nem jelent túl sok jót az oldal méltán gyarapodó felhasználói táborára nézve, mert bár a jelszavak titkosítva vannak, azért egy bot bármikor teleszórhatja a fórumot egy csomó jópofa kóddal, amit aztán el lehet küldeni a víruskergetőkenek analízisre - hogy csak a legalapabb dolgot említsem.

Persze a problémákról küldtem levelet a megadott kapcsolattartói e-mail címre is, de nem jött válasz, remélem ebben a formában hatásosabb lesz a bejelentés!

Ezek mellett van a szájtnak egy kis szabadszoftveres vonatkozása is, amit nem tudok nem megosztani: Valamelyik helyi erő nyilatkozta azt az egyetemi lapnak, hogy "amikor a formátumokról döntöttek [a] fő indok az volt, hogy a kodekekkel senkinek se kelljen szöszmötölnie, és még a legrégebbi vágású embereknek se állítson akadályt az útjába" - ezért lett a formátum WMV, no comment :P

Információim szerint egyébként az oldalt nem infósok fejlesztik.

Helyesbítés: a poszt készültekor még nem voltam Facebook felhasználó, így tévesen azt feltételeztem, hogy az apps.facebook.com domainen elérhető szolgáltatások is a közösségi oldal infrastruktúrájához tartoznak, miközben ezeken a helyeken valójában mindig külső szervereket látunk.

Úgy tűnik m1key legutóbb jó helyen tapogatózott, a Security-Shell bloggerei ugyanis már legalább szeptember óta piszkálják a Facebook adatbázisait az alkalmazások számára fenntartott aldomainen keresztül. Ma is több SQL injectionre és reflektív XSS-re alkalmas hibát tettek közzé. Azt persze nem tudni, hogy ezúttal is csak egy honeypot figyelt-e a túloldalon, minden esetre felhívtam a kollegák figyelmét a csapdákra.

 Kingkope egy FreeBSD újabb verzióit érintő, helyi root jogosultság megszerzésére felhasználható exploitot tett közzé a Full-Disclosure listán. A problémát az okozza, hogy a dinamikus linker (Run-Time Link Editor - rtld) rávehető, hogy setugid-es programok (pl. ping) futtatásához mindenek előtt betöltse az LD_PRELOAD környezeti változóban meghatározott dinamikus könyvtárakat, így a setugid állomány csoportjának jogosultságával egy dinamikus könyvtár parancsokat hajthat végre. Jelenleg a FreeBSD 8.0, 7.1 és 7.0 verzióiról bizonyosodott be, hogy sebezhetőek (illetve a 7.0-val kapcsolatban jött ellenkező vélemény is, de volt ahol működött...).

Elemzés olvasható xorl blogján, ha lesz egy kis időm (kizárt dolog :P), csinálok bitvadászatot.

Frissítés: Colin Percival egy gyorsfoltot publikált, nincs kitesztelve, csak saját felelősségre használjátok!

Helyesbítés: a poszt készültekor még nem voltam Facebook felhasználó, így tévesen azt feltételeztem, hogy az apps.facebook.com domainen elérhető szolgáltatások is a közösségi oldal infrastruktúrájához tartoznak, miközben ezeken a helyeken valójában mindig külső szervereket látunk.

m1key küldött egy igen érdekes naplót egy Facebookon(!) talált SQL injection sebezhetőségről. A történetet bonyolítja, hogy mire eljutottam a probléma teszteléséig, a varázsparancs már nem működött, viszont idő közben belebotlotam egy másik érdekes dologba is...

Kaptam egy szép képet:

Mivel a H.A.C.K. wikioldalait láthatóan nem sokan szerkesztgetik szívesen,   csináltam egy egyszerű szavazást annak felmérésére, hogy hánymennyien vennének részt a budapesti közvetítésen. Részletek itt és itt, szavazni oldalt lehet.

• Buksikutya küldte az infót, hogy a Roxy rádió és a VEKE oldala sem fest túl jól:

http://veke.hu/index.php?fc=cikk&par=-1'

A Roxyt azóta úgy látom javították, kár, hogy a felhasználói adatbázis már szét lett kürtölve a nagyvilágba - ezt onnan tudom, hogy ide is ki lett kommentelve a megfelelő link.

• Unu a Symantecnél nézett körül
• Rozmy pedig megmutatta, hogy a százkilencvennégy száznegyvenkilenc hatvan negyvenvalahányon elérhető a BKV vadiúj weboldala, ami nem lett kifejezetten korszakalkotó, ellenben dobál jópofa hibákat. Kihasználható rést az elmúlt 5 percben nem találtam rajta.

A szoftverek szűrőmechanizmusainak megkerülése miatt néha szükséges, hogy egy sebezhetőségen kersztül bejuttatandó shellkód ne tartalmazzon bizonyos karaktereket. Láttunk már olyan shellkódot, ami túléli az Unicode transzformációt, és csak egyszerű alfanumerikus karaktereket tartalmazóról is lehetett hallani. 

Négy kutató azonban a perverzió tudomány egy magasasabb szintjére lépett, és kitalálták, hogyan lehet angol nyelvű shellkódot generálni. Igen, jól olvastátok!  Bár nem jutottam a doksi végére, a módszer lényege a következő:

Először is megnézik, hogy minek felelnek meg az angol ABC betűinek ASCII értékei az adott platformon (esetünkben sima IA32). Ezek az utasítások egy incializációs utasítássor alapját fogják képezni. Elékszítenek egy kiindulási példányt az inicializációs utasítássorból, majd egy nagymáretű angol szövegtörzsből részleteket választanak, melyeknek annál nagyobb pontszámot adnak, minél hosszabb részletet fednek le az előállítandó utasítássorból. Így az inicializációs rész egy értelmes szöveghalmaz kisebb részeiből fog felépülni. Ez az inicializációs rész aztán kibontja az ún. dekódert, ami hasonló módon "becsomagolva" pihen a memóriába. A kibontás azt jelenti, hogy a dekódert reprezentáló byte-ok értékeit futásidőben megváltoztatják, így elérhetővé téve olyan instrukciókat, melyeket nem fedett le az angol ABC.  A dekóder ezután a szintén egy értelmes szövegekből előállított byte-sorozatot dekódol a fentiekhez hasonlóan, ez pedig már maga a "hasznos teher" lesz.

A módszer lényege természetesen nem a különböző szűréseken és transzformációkon történő átjutás megkönnyítése, hanem a minta vagy akár spektrumfelbontás alapú shellkód-detektálási módszerek kijátszása. Egy ilyen módon felépített utasítássort egy számítógép nagy valószínűséggel nem fog tudni megkülönböztetni egy egyszerű szövegtől, pl. egy e-mail tartalmától.

Egy eddig foltozatlan, Internet Explorer 6 és 7 típusú böngészőket érintő sebezhetőség látott napvilágot tegnap a Bugtraq listán. A probléma speciális STYLE tagek getElementsByTagName() segítségével történő feldolgozásakor jelentkezik.  A hiba böngészőn keresztüli távoli kódfuttatásra ad lehetőséget, ezért érdemes legalább a hivatalos folt megjelenéséig más böngészőre váltani.

Ja, és majdnem elfelejtettem a legviccesebbet: Az IE8 XSS szűrője a hírek szerint alkalmas arra, hogy XSS-t idézzen elő, akár egyébként rendes szűréssel megáldott webalkalmazásokban is. A probléma ott van, hogy a szűrő veszélyes tartalom érzékelésekor megváltoztatja megjelenítendő HTML kódot, ez a transzformáció pedig lehetővé teszi olyan tartalmak összeállítását, melyet maga a böngésző fog veszélyes, kliens oldali szkriptté alakítani. A NoScript ezzel szemben nem a HTTP választ, hanem a kérést módosítja, így ezt a plugint nem fenyegeti ilyen veszély.  

A tavalyi balszerencse-sorozat ellenére idén úgy tervezzük, hogy ismét nekivágunk Európa egyik legnagyobb és minden bizonnyal legrégibb múltra visszatekintő hackerösszejövetelének, a 26. Chaos Communication Congress-nek, méghozzá a H.A.C.K. zászlaja alatt vonulva! 

A rendezvényre december 27-30 között kerül sor Berlinben, de mi igyekszünk lejutni már 26-án, hogy maradjon jegy (ami egyébként 80 EUR-t kóstál). Vonattal mennénk (avagy Hackers on a Train), melyre szépen lassan felszivárognának az útbaeső hackerspace-ek tagjai is, így már maga az utazás is kiváló közösségi élménynek ígérkezik!  Várjuk tehát azoknak a jelentkezését, akik úgy érzik, hogy kaphatóak lennének egy ilyen küldetésre, de akik valamilyen oknál fogva nem tudnak részt venni a nagy utazásban, azoknak sem kell feltétlenül elkeseredniük:

A 26C3 - melynek mottója egyébként idén Here be Dragons - szervezői szeretnék, ha a konferencia minél több helyre eljutna, ezért nagyfelbontású elő videó streameket biztosítanak a távoli éreklődők számára, és mindenkit buzdítanak arra, hogy szervezzenek helyi rendezvényeket, ahol a közvetítést kivetítőn teszik elérhetővé a közösség számára. Mi is szeretnénk egy ilyet szervezni, valószínűleg a Fogasházban, ahová szeretnénk elcsábítani az érdeklődőket az ország minden tájáról, vagy akár külföldről is - ha netán valakinek Budapest lenne közelebb.

Mindez persze jelenleg a kezdeti, tervezési fázisban tart, de jó lenne lenne tudni, hogy mire számíthatunk mind érdeklődés, mind támogatás szintjén:

• Ki jönne Berlinbe (Hackers on a Train ), és hány emberre számíthatunk a Budapesti összejövetelen? Mindkét témára feliratkozás itt!
• Kinek van kéznél projektor, hangfal, erősítő, sörcsap, vagy bármi, amivel komfortosabbá lehetne tenni a Fogasházat erre a négy napra?

Felejthetetlen 4 nap lesz, terjesszétek az igét!

Megérkezett a Metasploit Framework 3.3-as, stabil változata, rengeteg izgalmas újdonsággal úgymint: Windows 7 támogatás futtató és célpont oldalon, továbbfejlesztett Oracle és MSSQL támadási módszerek, a playloadok bágyazásának lehetősége tetszőleges .exe-be vagy VBA makróként akár Word dokumentumokba,  64 bites célplatfomrok támogatása, titkosított Meterpreter kapcsolatok és új szkriptek pl. sniffelésre, billentyűzet-lehallgatásra vagy VNC kapcsolat nyitására, és még sok más!

Már csak egy valami hiányzik: a nagy, piros "HACK" gomb :)

Az újdonságokról szóló részletes bejelentés elolvasható itt, az MSF 3.3 pedig letölthető innen. 

Továbbított levél alant:

Idén decemberben immár 3. alkalommal kerül megrendezésre az ELTE és a

kancellar.hu közös 24 órás IT biztonsági programozó versenye = IT

Security Coding Contest :)

A versenyen különböző IT biztonsággal kapcsolatos PROGRAMOZÓI

feladatokat kell megoldani. Nem véletlen hangsúlyozom, hogy programozó

versenyről van szó, nem kell majd feltörni a NASA/FBI/CIA szerverei, no

para :)

 

Részletes információkat (mikor/hol/miért/hogyan/stb.) találhattok a

http://hackerverseny.hu

weboldalon. Jó, jó tudom, azt mondtam programozó verseny, az is, a webcím

csak az ellenség megtévesztését szolgálja :)

 

Távirati stílusban a lényeg:

- 2 fős csapatok (hallgatói jogviszony kell, részleteket lásd az oldalon)

- 24 óra (non-stop :) )

- IT biztonsággal kapcsolatos feladatok (kb 3 feladat)

- 1.000.000Ft-os fődíj (nem elírás, tényleg ennyi!!)

 

Ha felkeltette az érdeklődéseteket, irány a weboldal:

http://hackerverseny.hu

Minden további infót ott találtok, illetve ha kérdésetek van, szintén a

weboldalon látható kontaktra lehet írni (kiss_adam kukac ikhok elte hu).

Bár a napokban nyilvánosságra került TLS probléma súlyosságát senki sem vonta kétségbe, többen szkeptikusak voltak azzal kapcsolatban, hogy a sebezhetőséget éles rendszeren, széles körben ki tudnák használni. Anil Kurmus most megmutatta, hogy a protokollújraegyeztetésen alapuló támadás akár olyan nagy forgalmú oldalakon is kihasználható lehet, mint a Twitter. 

Kurmus először is megmutatta, hogy az a feltételezés, miszerint HTTPS protokoll használata esetén csak GET lekérdezéseket lehet manipulálni, nem igaz: a MitM támadás során ugyanis a beszúrható adat úgy prefixálhatja a valódi lekérdezést, hogy utóbbi végül az összefűzött POST lekérés body-jává válik, valahogy így:

POST /tamado_altal_hivott/script HTTP/1.0\r\n
tamado_altal_elnevezett_parameter=POST /eretedi/lekerdezes ....

Ez pedig pont kapóra jön a Twitter esetében, ahol minden egyes csirippel a HTTP protokoll Authaorization fejlécében átvitelre kerül a küldő felhasználó  felhasználóneve és jelszava, ez pedig pont belefér 140 karakterbe, így gyakorlatilag a felhasználóval kiposztoltathatjuk a saját jelszavát. Mocskos kis trükk :)

Élesítették Offensive-Security online exploit adatbázisát, melyet az utóbbi időben halódó milw0rm utódjának szánnak. Az adatbázisba átmentették a milw0rm-on tárolt adatokat, valamint a teljes tartalmat is egyben letölthetővé tették. A keresőfelület is finomodott, bár a CVE azonosító alapján történő keresést kissé hiányolom. Emellet a felület a már megszokott, egyszerű, átlátható sémát követi, így könnyű lesz hozzászokni :) A frissítésekről az @exploitdb Twitter felhasználót követve lehet értesülni. 

Ja igen, az oldalt (gondolom okulva a Metasploit kurzus körüli fiaskóból) a Jesys webes IPS védi, ami blokkolja  a potenciális támadók IP-jét, valamint közzéteszi azokat itt :)

Frissítés: Enyhe öniróniával Kikerült az az exploit, amivel megtörték a Metasploit wikit

Kivételesen korrekt cikket jelentetett meg az Index a Mike Murray által felfedezett, ActonScripteken keresztül kihasználható problémáról. Azért néhány pontosítást közölnék én is:

Az ActionScriptek működése a JavaScript-ekéhez hasonlóan korlátozott: csak ahhoz a domain-hoz tartozó erőforrásokhoz képesek hozzáférni, amelyen futtatásra kerültek, viszont tetszőleges domain felé intézhetnek kéréseket. A Flash objektumokba ágyazott ActionScriptek viszont a JavaScript-ekkel ellentétben mindig lefutnak mikor megjelenítik őket, nincs szükség direkt beágyazásra a HTML kódba. Így egy rosszul megírt fájlfeltöltő szkripten keresztül például feltolhatunk a szerverre egy .jpg kiterjesztésű fájlt, amiben valójában egy olyan ActionScript rejtőzik, amely a fájl megnyitásakor lelopja pl. az aktuális felhasználó munkamenet-azonosítóját - mivel ugyebár a feltöltött szkript már azon a domainen fut, ahová a felhasználó bejelentkezett. 

De ha feltesszük, hogy az okos programozó nem csak kiterjesztés-, hanem formátumellenőrzést is végez a feltöltött fájlokon, még mindig nem vagyunk biztonságban: a ZIP alapú fájlformátumokhoz (pl. ZIP, MS Open XML, XPI, JAR) ugyanis gond nélkül hozzá lehet csapni más típusú adatokat, ezzel nem sértjük meg a formátumspecifikációt.  

A problémára nyilvánvaló elkerülő megoldás az lehet, ha a feltöltött állományokat külön domainről szolgáljuk ki, másrészt megfelelő (erőforrásigényes) formátumellenőrzéssel megtilthatjuk a Flash tartalom feltöltését is. Kliens oldalon a Flash tartalmak fehérlistás szűrése lehet megoldás, de ez a megközelítés eddig sem volt túl népszerű. Az Adobe ugyan elismerte a problémát, de mivel a megoldás a teljes same-origin policy újratervezését igényelné, a változtatások pedig a már elkészült, legitim megoldásokat is veszélyeztetnék, nem valószínű, hogy univerzális orvoslat születik a közeljövőben.

MS09-063: Távoli kódfuttatásra alkalmas sebezhetőség a Web Services for Devices API-ban. A hiba helyi hálózaton keresztül használható ki, és Windows Vista és 2008 rendszereket érint.

MS09-064: A Windows 2000 Licence Logging Service-ét érintő, távoli kódfuttatásra alkalmas sebezhetőség.

MS09-065: Az ehavi jelentés csúcspontja, Windows 2000, 2003 és XP rendszereken távolról, akár egy weboldalon keresztül kihasználható probléma, amely kernel módú kódfuttatást tesz lehetővé.  Az MSRD vonatkozó bejegyzése szerint valószínáleg egy integer túllövés a ludas, a probléma pedig előjön minden alkalommal, mikor Internet Explorerrel vagy Office alkalmazásokkal speciális .eot betűkészleteket tartalmazó (web)dokumentumokat kívánunk megjeleníteni. A csomagba még befér két, Vistát és 2008-at érintő helyi jogosultságemelésre használható probléma (javítása) is.

MS09-066: Active Directory szolgáltatásokat érintő, szolgáltatásmegtagadáshoz vezető problémák. Windows 2008-ig bezárólag le lehet rogyasztani a kedves domainvezérlőket speciális LDAP üzenetek segítségével.

MS09-067: De jó is volt ugyanez 2008-ban... Most csak laza Excel hibákat kaptunk, bár helyből távolugrani ezekkel is lehet

MS09-068: Lásd az egyel előbbit, csak most Worddel

Továbbá mindent az olvasókért, közvéleménykutatok - kérlek titeket, hogy (ne csaljatok, és) a frissítőkeddekről szóló posztokat úgy együtt értékeljétek, mert a hibák minősége, és az én energiaszintem is hullámzik egyik hónapról a másikra:

 Laurent Gaffié egy olyan exploitot publikált, melynek segítségével helyből vagy távolról, autentikáció nélkül végtelen ciklusba kergethető tetszőleges, SMBv1-t vagy SMBv2-t használó Windows 2008R2 vagy Windows 7 rendszer.  A Microsoft elismerte a hibát, javítás egyelőre nincs.

Először is a támadáról, kicsit pontosabban (bocs, az előző bejegyzést elég sietve kellett összedobnom):

A támadás aktív man-in-the-middle forgatókönyvet feltételez, és egy parancs/lekérdezés beszúrására ad lehetőséget a támadó számára egy hitelesített kliens nevében. A probléma kihasználásához a támadónak magán keresztül kell irányítania a hálózati forgalmat, kiépítenie egy SSL csatornát önmaga és az SSL szerver között, beszúrni a kívánt üzenetetet, majd a valódi kliens Client Hello üzenetének visszajátszásával és az ezt követő kliens-szerver üzenetek áteresztésével újraegyeztetni a kapcsolatot a kliens és a szerver között.

A támadásnak több variánsa is elképzelhető, de a legszélesebb felhasználói kört érintő probléma úgy alakul ki, hogy a sebezhető SSL kiszolgáló hozzáfűzi a támadó által küldött üzenethez a valódi kliens üzenetét, így pl. egy lezáratlan HTTP GET kéréssel a támadó el tudja fedni a valódi kliens kérését, de meg tudja tartani a kérés fejlécének többi részét, pl. a sütiket, így a támadó kérései a kliens munkamenet-azonosítójával fog lefutni:

GET /tamado/lekerdezese HTTP/1.0\r\n
Valami-fejlec:GET /kliens/lekerdezese HTTP/1.0\r\n
Cookie: [a kliens sütijei, ill. további fejlécek]\r\n\r\n

A módszer segítségével nem olvasható ki adat a titkosított csatornából, ezért a beszúrt lekérdezés/parancs eredményét a támadó nem látja, így a CSRF ellen védett HTTP weboldalak pl. nincsenek veszélyben.

Sokat tudnak segíteni a megértésben az eredeti felfedező, Marsh Ray folyamatábrái.

A G-Sec folyamatosan frissülő információs weboldalt tart karban a nem rég bemutatott TLS sebezhetőséggel kapcsolatban, ennek leglényegesebb pontjai a következők (némi kiegészítéssel):

• A sebezhetőséget a legnagyobb gyártók megerősítették. Az Apache, az OpenSSL és a GnuTLS implementációkhoz már rendelkezésre áll javítás, a Cisco biztonsági tanácslatot adott ki.
• A Leviathan Security jóvoltából megjelent egy tesztalkalmazás, mellyel ellenőrizhető, hogy egy kiszolgáló támogatja-e a kliens által kezdeményezett kapcsolat-újraegyeztetést, ami potenciálisan sebezhetővé teszi a protokollmegvalósításokat a támadással szemben. A legtöbb fontos külföldi és magyar webhely jelenleg sebezhetőnek tűnik...

Érdemes ezeken kívül követni Thierry Zollert a Twitteren, ő valós időben csiripeli a fejleményeket.