Egy érdekes elemzés jelent meg az IBM X-Force Frequency X Blogján, melyben a napokban az Andorid Marketen megjelent kártevők működését elemzik. A hajtás után olvashatjátok a cikk fordítását, amely néha kissé szájbarágós ugyan, de véleményem szerint jó rálátást ad mind az androidos alkalmazások, mind pedig az ezt futtató eszközket célzó kártevők működésébe: 

Úgy látszik ezen a hétvégén sokatoknak támadt kedve egy kis mozizásra, többen is beküldék ugyanis, hogy szaudi szkriptsuttyók deface-elték a Cinema City oldalát:

Az oldalon jelenleg karbantartási üzenet olvasható. Köszi mindenkinek, aki szólt!

Marcus Meissner, a Vendor-sec levelezőlista egyik moderátora egy OSS-secre küldött nyílt levélben közölte, hogy január 20-án betörtek a lista kiszolgálójára. A létrehozott hátsó kaput bezárták, de a behatolás pontos módjára eddig nem derült fény.

Az eset kapcsán a Vendor-sec üzemeltetői arra jutottak, hogy Solar Designernek (OpenWall) adnák át a lista karbantartását, aki nyitott is lett volna az átvételre, a lehetséges fejlesztési irányok számbavétele során azonban arra jutottak, hogy nem biztos, hogy a vendor-sec jelenlegi formájában megtéríti-e a bele fektetett energiát. A lista sorsáról így most a közösség dönthet.

Az utóbbi napokban kicsit elhanyagoltam a hírolvasómat, pedig történtek érdekes dolgok. Szerencsére ezek egy részét mások már megírták, én csak néhány kiegészítést fűznék az ő közleményeikhez:

trey@HUP:

Mondhatnák, hogy olyan, mint amikor valakit agyonvernek a saját falábával. A Microsoft saját biztonsági termékei ütnek rést a pajzson. A probléma a Malware Protection Engine (mpengine.dll) szoftverkomponenssel van, amely része a Microsoft Security Essentials (MSE), Windows Live OneCare, Microsoft Windows Defender, Microsoft Forefront Client Security, Microsoft Forefront Endpoint Protection 2010 és Microsoft Malicious Software Removal Tool termékeknek. A hibát egy speciálisan összeállított registry kulccsal kihasználva a helyi támadó LocalSystem fiók jogaival egyenértékű jogokhoz juthat. Részletek a biztonsági figyelmeztetőben.

Ne gondoljuk azt, hogy kuriózumról van szó: a ZDI hibalistáit végigpörgetve számtalan arcpirító hibával találkozhatunk, melyek neves biztonsági termékeket érintenek. Ne legyenek illúzióink!

TECH-CERT:

Számítógépes hackerek kínai szervereken keresztül betörtek hat európai és amerikai energiavállalat, többek között az Exxon Mobil Corp, a Royal Dutch Shell PIc vagy a BP PIc, rendszerébe és onnan bizalmas információkat loptak el, jelentette be az egyik vállalat nyomozó csapata.

A helyzet bizalmas jellege miatt megtámadott vállalatok listája nem egyértelmű, de a nyomozásokban résztvevő és a vállalatokat ismerő emberek szerint érintett a Marathon Oil Corp., a ConocoPhillips és a Baker Hughes Inc. is.

Bizonyos esetekben a hackereknek már több mint egy éve van felfedezetlen "bejáratuk" a vállalatokhoz, mondta el Greg Hoglund a HBGary vezérigazgatója. A HBGary az a kiberbiztonsági cég, amely az olajvállalatokat ért betörések egy részét kivizsgálta, de Holung elutasította a McAffe azon kérését, hogy pontosan megnevezze ügyfeleit.

[...]

A McAffee-nál ezek szerint még nem töltötték le Holung teljes levelezését.

Végül az Anonymous élő adásban deface-elte a Westboro Baptist Church weboldalát, erről csak a felvételt posztolom, hatalmas (ezért tuti a pokol tüzén fogok elkárhozni):

Chris Evans blogján jelent meg egy érdekes bejegyzés egy csendben javított glibc hibáról, melyre a Chromium böngésző hibakövető rendszerébe küldött egyik hibajegy terelte rá a figyelmet. 

A probléma a stack méretét állítgató alloca() függvényben volt, amelyet természeténél fogva leginkább a könyvtár és a gcc fordító belső eljárásaiban használnak. Az fnmatch() függvénynek kellően hosszú UTF-8 stringet átadva, a string hosszának négyszerese kerül átadásra az alloca()-nak, ami az előjelbit átfordulásával a stack méretének csökkenéséhez vezet. Mindez pedig kódfuttatásra is jó lehet akkor, ha sikerül úgy beállítanunk az új méretet, hogy a processzor az EIP tárolt értéke helyett valamilyen általunk beállított címet olvasson vissza, ráadásul ebben az esetben a stack sütik illetve az ASLR sem nyújtanak hatékony védelmet, bár a DEP segíthet.

A glibc reakciójából sajnos nem derül ki, hogy melyik verzióban került javításra ez a probléma, Maksymilian Arciemowicz azonban megjegyezte, hogy a ProFTPd 1.3.3d verziója a jelek szerint sebezhető változattal lett forgatva - és ezzel feltehetően nincs egyedül. A történet pozitív szála, hogy a hibát a Chromium csapatának jelentő bugvadász megkapta a súlyos biztonsági hibákért járó 1337$-t, bár a probléma nem a böngészővel volt. 

Szegény HBGary-ék nagyon padlótfogtak az Anonymous támadásától, a cég lemondta a napokban tartott RSA konferenciára szánt előadásait, stand helyett pedig csak egy rövid üzenetet helyeztek el, melyben kifejtik, hogy a személyüket ért fenyegetések miatt nem kívánnak megjelenni a rendezvényen.

De vajon milyen hibák vezettek odáig, hogy ezt, az Interpollal és NSA-el rendszeresen együtt dolgozó céget így megalázhatták? Az Ars Technika megírta, és a történet, ahogy az már csak lenni szokott prózaibb az (el)vártnál. A dolog úgy indult, hogy az HBGary honlapjai számára egyedileg fejlesztett CMS rendszerben az Anonymous tagjai kiszúrtak egy SQL injection hibát. Igen, ez fájdalmasan tipikus... A rendszerben tárolt jelszavak persze hash-elve voltak, MD5-tel, salt nélkül, így az Aaron Barr (CEO) és Ted Vera (COO) által használt 6 kisbetű + 2 számjegy bonyolultságú jelszavak megfejtése nem okozott gondott néhány giga szivárványtáblával.

Ez persze legfeljebb egy kiadós deface-hez vezethetett volna, ha a kedves vezetők nem használták volna ugyanezeket a jelszavakat az e-mailezésükhöz, az egyik céges szerver SSH hozzáféréséhez (bónuszként a gép üthető volt a szívemcsücske $ORIGIN kiterjesztés hibával), valamint a cég Google Apps fiókjának adminisztrációjához. Ez innentől már sakk-matt, az már csak hab a tortán, hogy az egyik e-mail postafiók és a levelezésben talált régi root jelszó segítségével a támadók rávették az egyik rendszergazdát, hogy nyisson root shellt számukra a cég webszerverén is.

Az előző poszt írása közben végig az járt a fejemben, hogy nehogy egyszer én is úgy járjak, mint az ott bemutatott szerencsétlenek. A helyzet azonban az, hogy az HBGary olyan alapvető hibákat vétett, hogy a sorsuk meg volt pecsételve, és ez az igazán ciki.

Nagy örömömre szolgál bejelenteni, hogy április 21-én újra lesz sörözés, amin tiszteletét teszi barátaival LockpickerSrác, aki egy nagyon ígéretesnek tűnő workshoppal igyekeszik majd rabul ejteni a figyelmünket (is). 

A helyszín ismét a HACK lesz, az időpont pedig sajnos viszonylag távoli (és csütörtökre esik), de a tér-idő korlátai sajnos nem sok mozgást engedtek, sajnálom. Minden esetre a rendelkezésre álló két hónap alatt bőven lesz időnk végiggondolni, hogy milyen érdekességeket tudnánk prezentálni egy-egy villámelőadás formájában újdonsült barátainknak, és persze a hagyományosan jelen lévő közönségnek!

Szóval véssétek be a naptárba a dátumot, ha pedig eszetekbe jut valamilyen előadástéma*, írjatok e-mailt!

Szerelmeslevél érkezett Valentin-napon a Microsoft biztonsági csapatának a Full Disclosure listára. Az üzenet - a Microsoft elemzése szerint - egy integer alulcsordulást tárgyal, amely alapesetben képes ledönteni a hálózat Master Browser-ét, aki legtöbb esetben az elsődleges tartományvezérlővel (PDC) egyezik meg.

A probléma akkor keletkezik, amikor a szolgáltatás egy fix méretű pufferbe próbál string tömböket pakolni. A program azonban igyekszik nyilvántartani a pufferben rendelkezésre álló helyet, és eszerint paraméterezni a memóriamásoló eljárást, ezért nem egy hagyományos puffer-túlcsordulás zajlik le. A baj ott van, hogy a program a bepakolt stringek effektív méretébe beszámító lezáró NULL byte helyét akkor is levonja a rendelkezésre álló területből, mikor az már 0 értékű, így egy hatalmas abszolútértékű (~4GB) másolásra ad utasítást. 

32-bites rendszer esetén ez mindenképpen fatális rendszerhibát okoz, mivel 2x4 GB egybefüggő memóratartomány sehogy sem fér el a kezelt virtuális memóriában. 64-bit esetén ez a probléma nem biztos hogy felmerül, viszont még így is valószínű, hogy egy idő után a szál a saját homokozóján kívül kezd el turkálni, amibe belehal. A csillagok megfelelő együttállása esetben előfordulhat, hogy egy párhuzamos szál hozzáfér a felülcsapott memóriaterülethez, de úgy tűnik, hogy a támadó nem tudja befolyásolni, hogy az eredetileg fenntartott pufferen túlra milyen adat kerüljön.

Összességében tehát a távoli kódfuttatás valamivel nehezebb feladatnak tűnik, mint sikeresen randevút kérni Lara Cro Angelina Jolie-tól. A helyi kihasználással kapcsolatban a gyártó nem adott tájékoztatást, de a hiba publikálója szerint "valószínűleg" meg lehet oldani a dolgot - végülis így az ember részben előre berendezheti a memóriát, de ehhez valószínűleg feng-shui mesternek kell lenni.

Állítólag a Stuxnet részleges, visszafejtett forráskódját tartalmazza egy, a GitHubon nem rég megosztott tároló. A kártevő természetéből fakadóan már rég óta elérhető bináris formában, így egyáltalán nem életszerűtlen, hogy valóban a sztárféreg kódját tették most közzé. A dolog szépséghibája azonban, hogy a projekt egyszerűen egy Boomeranggal generált forráskód-halom, ami nem értelmezhető sokkal hatékonyabban, mint egy sima disassembly. 

A publikáció ismét az Anonymoushoz köthető, akik feltehetően az HBGary rendszeréből jutottak hozzá a Stuxnet komponenseihez. Népes közösség lévén, már több mint egy tucat fork született a kezdeményezésből. Érdekes lesz látni, hogy a közösségi reverse engineering fel tud-e majd mutatni olyan eredményt, amivel újat mondhat a "hivatásosoknak".

(A linkért köszönet Dnetnek!)

Nos, a legutóbbi microsoftos hibaösszesítővel nem ért véget a foltozandó szoftverek sora, tegnap ugyanis egész frissítéscunami materializálódott a virtuális térben (ez vajon kellően cypberpunk volt?). 

Az Adobe például frissítést adott ki a Shockwave és Flash Playerekhez, a Reader 9-es és 10-es főverzióihoz, valamint a ColdFusion kiszolgálóhoz is. A hibák részleteibe most nem fogok belemenni, de felhívnám a figyelmet, hogy PDF olvasónban az .iif, .rgba, .bmp (!!!), .psd, és .fli formátumok feldolgozásában is volt kódfuttatást lehetővé tevő hiba, és akkor még csak a képformátumokról beszéltünk (a rémisztően bonyolult BMP-k feldolgozását egyébként két helyen is javítani kellett)!

És elkezdhetünk szörnyülködni azon, hogy az Adobe Reader hibáit lassan már számontartani sem lehet, vagy hogy két hónapot kell várni egy-egy aktívan kihasznált IE hiba javítására, de ezekben az esetekben legalább annyi elmondható, hogy a hibakezelő folyamatok, ha nem is kifogástalanul, de működnek!

A hibavadászok egyik platformjául szolgáló Zero Day Initiative tavaly augusztusban megváltoztatta felelős nyilvánosságrahozatalra épülő politikáját, és azóta a fél évnél hosszabb ideje javítatlan sebezhetőségek leírását nyilvánosságra hozzák.

A most közzétett hibalisákban a Microsoft, az IBM, a HP, az SCO, a CA, a Novell és az EMC termékei szerepelnek, olyan szoftverekkel, mint az MS Office Excel, az IBM Informix, vagy a HP Data Protector. A hibajelentések óta lezajlott események naplóját sajnos csak az IBM termékeihez mellékelték (ez vajon véletlen a HP által felvásárolt ZDI részéről? :). Ezek szerint a Nagy Kék a 2008-ban beérkezett proof-of-concept kódokkal 2 évig gyakorlatilag nem foglalkozott, majd újra kérte a kódokat, amiket nem tudott működésre bírni, végül vélhetően "nem reprodukálható" cimkével lezárta a hibajegyeket. 

Aztán itt van a Sun-t bekebelező Oracle, akitől most jött ki a javítás a már tárgyalt lebegőpontos-konverzió problémára. Ezzel egyidőben került nyilvánosságra egy két éve javítatlan probléma leírása, melyet a gyártó /*implements Sun, Oracle*/ úgy tűnik, nem is tekint biztonsági hibának:

A dolog lényege, hogy a Swing könyvtár createComponent() metódusával appletben is létre lehet hozni, egy egyébként nem engedélyezett JFileChooser objektumot, amely a jól ismert fájlválasztó ablakot jeleníti meg. Tapasztaltabb olvasóimnak bizonyára beugrik, hogy ezt az ablakot bizony rengeteg csúnyaságra lehet használni, például fájlok átnevezésére, vagy könyvtárak létrehozására. A baj az, hogy egy támadás során éppen az áldozat az, akinek feldobódik ez az ablak, tőle pedig nem várhatjuk el, hogy meghackelje a saját rendszerét. Sami Koviu, a hiba felfedezője azonban elegendő időt töltött JavaDoc olvasgatásával ahhoz, hogy rájöjjön, a Windows.getWindows() metódus visszaadja az összes, applet által elérhető ablak referenciáját, a JFileChooser Component ősosztálya pedig definiál egy getComponents() metódust, melyen keresztül a fájlválasztó ablakon belüli összes objetum hozzáférhetővé válik az applet készítője számára. Így gyakorlatilag bármilyen felhasználói viselkedés szimulálható, egy megfelelő helyre, megfelelő névvel elhelyezett fájl pedig végzetes lehet egy rendszer védelme szempontjából.

Ezek után azt hiszem csak a klasszikust idézhetem: Senkiháziak kezében van az IT szakma! 

Az elmúlt néhány napban két erős alázás is színesítette az online hétköznapokat, úgy tűnik még mindig működnek valamennyire az "ipar" önszabályozó folyamatai.

Először február 2-án jelent  meg a LIGATT Security feje, Gregory D. Evans Twitter falán néhány rejtélyes üzenet. Nem baj ha nem ismerős a név, az attrition.org archívuma vidám perceket fog szerezni! Röviden összefoglalva Evans egy sarlatán, aki megpróbálja magáról elhitetni, hogy ő a világ első számú hackere, internetes tutorialok szó szerinti másolataiból összeollózott könyveket ad ki, hamis kompetenciákat és referenciákat bevetve próbál üzeltet szerezni, és perrel fenyegeti azokat, akik mindezt szóvá teszik. Valakinél azonban betelt a pohár, ugyanis nyilvánosságra került Evans teljes levelezése, több webes fiókját kompommitálták, és külön weboldal alakult a céges és magánéleti szennyesének kiteregetésére. 

Legszebb öröm a söröm káröröm, de azért az eset kapcsán számomra mégis csak az volt a legmulattságosabb, hogy a LIGATT-os anyagokra kiéhezett "szakértők" egy jelentős részének nem sikerült kibontania a belsős anyagokra mutató, base64-kódolt torrent fájlt... Lehet hogy az a #1 pozíció nincs annyira távol a valóságtól, mint azt feltételeztük :)

A másik eset téridőben valamivel aktuálisabb, egyrészt mert frissebb, másrészt mert már magyar portálokon is megjelent a hír, miszerint a HBGary nevű biztonsági cég megszerezte az Anonymous néhány "vezetőjének" személyes adatait. Bár a hírek szerint a megszerzett információkat nem adták át a hatóságoknak, az elmúlt hetekben több Anonymoushoz köthető letartóztatásra is sor került, bár azt nem tudni, hogy az őrizetbe vett gyanúsítottak valóban részt vettek-e például a WikiLeaks számláit zároló cégek elleni támadásokban. Az Anonymous minden esetre úgy tűnik, hogy berágott, és egy szívélyes üzenet társaságában nyilvánosságra hozta az HBGary vezetőjének, Aaron Barrnak teljes levelezését. Az egyik kiemelt üzenet szerint Barr eszközként tekintett a csoportra, melyet marketing célra használhat, függetlenül a birtokában lévő információk hitelétől és értékétől. Az Anonymous leleplezésének mikéntjéről Barr egy San Francisco-i konferencián beszélt volna, de az előadást most lemondta, a nagy hírverés hatása pedig az lett, hogy az egész világ megtudta, ez a biztonsági cég még a saját adatait sem képes megvédeni.

Ma van a Biztonságos Internet Nap, de a Microsoft most megjelent frissítőcsomagja bizonyítja, hogy sajnos nem elég a webkamera-használatra odafigyelni, ha az ember netán az Internetre téved.

MS11-003: Mindjárt az első javítócsomagban ott találjuk az éppen 3 hónapja publikált, IE-t érintő CSS feldolgozós hiba javítását, amit már aktívan alkalmaznak online támadások során. Emellett még három problémát, köztük egy lazább DLL hijackinget (IEShims.dll) old meg a frissítés, ha jól nézem a Zalewski-féle hibákat még nem.

MS11-004: Az IIS FTP komponensének javítása, amely távoli kódfuttatástól óvja meg a szoftver felhasználóit. A hiba kihasználása autentikációt nem igényel, a sebezhető kódrészletet az ftpsvc.dll TELNET_STREAM_CONTEXT::OnSendData metódusában kell keresni, és még egy PoC exploit is rendelkezésre áll, bár ez csak DoS-ra képes Windows 7-en. Az SRD szokásos posztja szerint az FTP szolgáltatás (tehát nem az IIS!!) 7.0 és 7.5-ös verziói érintettek, melyek IIS 7.0-ra telepíthetőek (de alapértelmezetten a 6.0 fut, ami rendben van), az IIS 7.5 pedig alapértelmezetten sebezhető, ha fut a szolgáltatás.

MS11-005: A frissítés megakadályozza, hogy helyi adminisztrátori jogosultsággal rendelkező domain-felhasználókelérhetetlenné tegyék az Active Directory kiszolgálót egyes szolgáltatások számára. A hiba a Service Principal Name-ek helytelen ellenőrzéséből adódik, amely névütközéshez vezethet. A probléma csak a Windows 2003-at érinti.

MS11-006: A Graphics Rendering Engine hibájának javítása. A probléma távoli kódfuttatást tesz lehetővé több alkalmazáson keresztül, a bélyegkép-készítő eljárás egy hibáját kihasználva. A hiba kihasználására Metasploit modul is elérhető, szóval itt is igyekezni kell a foltozással.

MS11-007: Az OpenType Compact Font Format driverének javítása. A meghajtó hibája távoli kódfuttatást tesz lehetővé speciális betűkészleteket használó weboldalak meglátogatása esetén, de elméletileg más helyeken is felbukkanhatnak a gonosz betűkészletek. 

MS11-008: A hónap Office hibája címért ezúttal egyedül a Visio szállt harcba, két probléma javítása található a csomagban a szoftver 2003-as és 2007-es változataihoz.

MS11-009: A Windows újabb (>=7) változatait érintő, információszivárgást okozó sebezhetőség javítása. A problémát weblapokra elhelyezett JScript illetve VBScript kódokkal lehet kihasználni, de kódfuttatást, vagy privilégiumemelést nem lehet elérni a kihasználásával, legfeljebb más kibák hatékony kihasználásához segítheti hozzá a támadót ha nem foltozzuk be ezt a rést.

MS11-010: Egy helyi jogosultságkiterjesztésre alkalmas probléma javítása. A tanácslat szerint a CSRSS alrendszer nem megfelelően terminálja egy kilépő felhasználó folyamatait, így egy speciális program megfigyelheti a később bejelentkező felhasználók kommunikációját az operációs rendszerrel, így hozzájuthat pl. belépési adatokhoz is, de közvetlen kódfuttatásra nincs lehetőség.

MS11-011: Szintén egy privilégiumemelést akadályozó csomag, most két hiba javításával. Az egyik ezek közül a tavaly novemberben tárgyalt veremtúlcsordulás, a másik pedig egy integer truncation (szép magyar kifejezés erre?). Az előző ponttal ellentétben itt már kózvetlen, kernel módú kódfuttatással kell számolni.

MS11-012: Még mindig kernel módú kódfuttatás, ez a csomag összesen öt problémát javít különböző meghajtókban. Ezek és az előző pontban tárgyalt hibák is érintik a Windows összes támogatott verzióját.

MS11-013: Két Kerberost érintő probléma javítása. Az első hiba a kriptográfiailag gyenge CRC32 ellenőrzőösszeg használatából adódik, és rendszer szintű kódfuttatást tesz lehető bejelentkezet felhasználók számára. A másik probléma a Windows 7-et és a 2008-at érinti, mivel az ezeken az operációs rendszereken futó Kerberos szolgáltatások rávehetők, hogy visszatérjenek a DES használatára, melynek következtében az egyébként titkosított üzenetek viszonylag könnyen megfejthetővé válnak. 

MS11-014: A Windows XP és 2003 LSASS alrendszerét érintő probléma, amely rendszerszintű kódfuttatást tesz lehetővé bejelentkezett felhasználók számára. A leírás alapján a szolgáltatás rosszul ellenőriz valamiféle hosszt az autentikációs kérések feldolgozása során, ez okozza a bajt.

A fentieken kívül nem-biztonsági frissítésként Windows Update-en keresztül automatikusan telepíthetővé válik a Windows 7 Autorunnal kapcsolatos viselkedését backportoló csomag is.

 A hivatalos MSRC blogon még több segítséget kaphattok a frissítések prioritásával kapcsolatban.

A PS3 védelmének csúfondáros bukása után berágott Sony elérte, hogy elkobozzák George Hotz számítógépeit, azonban a bírói végzés megszületése előtt 24 órával már egy másik hacker,  KaKaRoToKS (Youness Alaoui) már publikálta a legújabb, 3.56-ös firmware-hez tartozó aláíró kulcsokat (melyeket azóta GitHubról és Gitoriousról is eltűntettek, kommentben jöhetnek az alternatív elérhetőségek!). 

Az új alapszoftver érezhetően egy elkeseredett próbálkozás a gyártó részéről, hogy valahogy megakadályozza a konzol számára nem tetsző használatát. Az új firmware nem engedi a downgrade-et, a PlayStation Online-ra pedig csak a legújabb változattal lehet csatlakozni, ráadásul egyes hírek szerint rootkitet telepítettek a konzol szoftverébe, hogy a Sony észrevétlenül ellenőrizhesse annak sértetlenségét, és adott esetben lekapcsolhassa a csalókat a hálózatáról. Mindez persze nagyjából addig okoz majd problémát, ameddig ki nem jön az első hackelt firmware, amiből kiszedték a fenti funkciót.

 ... mindkettő beledöglik a  2.2250738585072011e-308 számba.

(-1) küldte a hírt, hogy a január elején itt is szóba került PHP problémához kísértetiesen hasonlót fedeztek fel a legújabb java futtatókörnyezetben és a fordítóban is!

Az ExploringBinary cikke a következő két egyszerű forráskódot tette közzé a hiba demonstrálására, az első osztály a JRE-t, a másik a javac-t fekteti meg:

class runhang {
public static void main(String[] args) {
  System.out.println("Test:");
  double d = Double.parseDouble("2.2250738585072012e-308");
  System.out.println("Value: " + d);
 }
}

class compilehang {
public static void main(String[] args) {
  double d = 2.2250738585072012e-308;
  System.out.println("Value: " + d);
 }
}

Ráadásként a tizedesjel odéppakolásával és nullák beillesztésével további számok konstruálhatók, melyek mindegyike végtelen ciklusba kergeti az interpretert/fordítót.

 Chriss Russo, aki annak idején a Priate Bay biztonsági hibájának felfedezésével vált ismertté most azzal irányította magára a figyelmet, hogy egy hibaüzenet-alapú SQL injection hibát talált a világ legnagyobb társkereső oldala, a PlentyOfFish rendszerében. A hiba kihasználásával a közel 30 millió regisztrált felhasználó összes személyes adatához, nyílt szövegként tárolt jelszavához valamint PayPal illetve bankkártya információihoz is hozzá lehetett jutni.

A történetnek itt azonban nincs vége. Russo ugyanis felvette a kapcsolatot az oldal alapítójával és ügyvezetőjével, Markus Frinddel, hogy tájékoztassa a hibáról. Hogy ez után mi történt, az kétséges, ugyanis a két fél, valamint a sztoriba útközben bekapcsolódott, IT-biztonságra szakosodott újságíró, Brian Krebs, gyökeresen eltérően értékelték az eseményeket.

Frind egy, a POF blogján megjelent, de személyesnek szánt bejegyzésében kelt ki Russo ellen, aki szerinte azzal hívta fel a feleségét (akinek a számát az oldal adatbázisából szerezte meg), hogy feltörte a társkereső oldalt, aminek letöltötte az adatbázisát, de "az oroszok" az ő gépét is feltörték, és éppen töltik le az adatokat. Frind szerint Russo ez után több üzenetet hagyott neki, melyben találkozót kért tőle, és az életéért aggódott. Amikor viszont másodszorra beszéltek, Russo és partnere "üzletet" ajánlottak neki, melynek értelmében az adatbázisért, az oldal forráskódjaiért, valamint egy hosszútávú együttműködési megállapodásért cserébe garantálják, hogy nem fordul elő többé hasonló eset, és törlik az oroszok másolatát. Frind természetesen nem hagyja magát, perrel fenyegette meg Russot, valamint (Vigyázat, magas LOL-faktor!) küldött egy e-mailt is a hacker édesanyjának.

Jómagam - bár nyilvánvalóan elfogult vagyok a kérdésben - több hitelt adok Russo és Krebs beszámolójának. Azt ugyanis Frind is elismeri, hogy Russo a saját nevére regisztrált fiókkal hajtotta végre a támadást, személyazonosságát soha sem titkolta, ami nem jelent túlzottan előnyös pozíciót, ha az ember zsarolásra készül. 

 Russo leírása alapján tényleg kapcsolatba lépett Frind feleségével, aki hálás volt az információért, és a társaság mérnökeihez irányította őt. A hibát ezután javították, majd a POF felkérte Russo-t, hogy tegyen ajánlatot a társaság rendszereinek felülvizsgálatára. Az ajánlat elkészülte után Frind egy e-mailt küldött Russonak egy freelancers.com-on található hírdetés linkjével, melyben POF felhasználók személyes adatait kínálják eladásra. Frind a közzétett levél tanúsága szerint azt gondolja, hogy a hírdetés mögött Russo-ék állnak, az e-mail további részében pedig perrel, valamint azzal fenyegetőzik, hogy megírja az oldal összes felhasználójának, hogy Russo törte fel a fiókjukat. Russo állítása szerint ezután több telefonhívást kapott a társaság vezetőjétől, aki arra figyelmeztette, hogy az oldal mögött ott áll a szervezett bűnözés is. 

Jelenleg itt tartunk, de tuti lesz még folytatás! És mielőtt még valaki fellélegezne, hogy a PlentyPOfFish-sel kapcsolatos botrányok minket nem érintenek, elárulom, hogy a hazai társkereső oldalak sincsenek sokkal jobban bevédve :(  

A hosszú poszt végére jöjjön az utóbbi idők egyik legjobb videóklippje, többek között a PlentyOfFish reklámjával (4:26-4:37), amiről máig azt hittem, hogy csak egy vicc, mert ilyen névvel társkereső oldalt senki nem csinál:

Állítólag már hosszabb ideje kering a neten az a Kaspersky Internet Security forráskód, amely most a szélesebb nyilvánosság számára is elérhetővé vált BitTorrenten, illetve fájlmegosztó weboldalakon (A fájlok a Kaspersky szellemi tulajdonát tartalmazzák, letölteni, tárolni állítólag nem szabad!). A csomag a biztonsági programcsomag valószínűleg 2008-as béta változatának részeit tartalmazza.

A fájlokat egy belső munkatárs juttatta ki a cégtől 2008 elején. Az incidensre hamar fény derült, az illető most 3 éves szabadságvesztését tölti, melyet 3 évre szóló számítógépektől való eltiltással spékeltek meg. A kódok nagy részét azóta újra írták, de még így is érdekes lehet megnézni, hogy hogyan dolgoznak a nagy vírusírtó cégek programozói. 

Bandukol a királyfi az erdőben, mikor szembe jön vele a csúf, vén hegyi banya egy hollóval a vállán:

- Királyfi, ha megmondod milyen állat ül itt a vállamon, a tiéd vagyok egész éjszaka!
- Ööö...rozmár!
- Határeset, elfogadom ;)

Az Amazon régi felhasználóinak nem kell aggódniuk, ha nem emlékeznek pontosan az áruházban használt jelszavukra, ugyanis az oldal a régi fiókok jelszavainak ellenőrzésekor nem tesz különbséget a kis- és nagybetűk között, valamint figyelmen kívül hagyja a nyolcadik karakter utáni részt.

Utóbbi jelenség valószínűleg a régi crypt() eljárás használatából adódik, a jelszavak kis/nagybetűre történő konvertálása viszont nem tudom melyik univerzumban tűnhet jó ötletnek... 

A Microsoft figyelmeztetőt adott ki, melyben egy XSS-re lehetőséget adó hibára hívja fel a figyelmet. A probléma lényege, hogy az MHTML protokollkezelőn keresztül lekérdezett weboldalakba akkor is elhelyezhetők rosszindulatú szkriptek, ha a weboldal egyébként megfelelően szűri a felhasználóktól érkező bemeneteket, ráadásul a Content-Type HTTP fejléc beállítása sem befolyásolja, hogy lefut-e a visszakapott kód.

Például tegyük fel, hogy sikerül a celpont.hu-n tartósan vagy ideiglenesen base64 vagy Quoted-Printbale kódolt üzenetet elhelyeznünk megfelelő MIME határolók közé! Ekkor készíthetünk egy weboldalt, amely az

<iframe src="mhtml:http://celpont.hu/...

vagy hasonló kódrészlettel hivatkozik a célpontra. Ha egy Internet Explorer felhasználó meglátogatja ezt az oldalt, a celpont.hu kontextusában lefut az előzőleg oda pakolt, kódolt szkriptünk, amely például eljuttathatja hozzánk a felhasználó celpont.hu-n érvényes sütijeit. 

Érdekes mellékszál, hogy néhányan a Google biztonsági csapatánál jelentették a hibát, mert a GWT mobil böngészésre optimalizáló szkriptje is támadható volt ilyen módon.

Ideiglenes megoldásként az itt megtalálható FixIt csomag telepítésével kockázatosnak jelölhető az MHTML protokoll, így az ezen keresztül érkező tartalmak csak megerősítés után értelmeződnek. 

Ha szolgáltatás-üzemeltetőként kívánjuk megvédeni a felhasználóinkat, szűrhetjük az újsor karaktereket a felhasználói bemenetekben, újsor karaktert szúrhatunk a HTTP válaszok elejére, vagy lecserélhetjük a HTTP státusz kódokat. 

Kingcope postázott egy helyi FreeBSD exploitot a Full-Disclosure listára, amely a levél szövege szerint reboot-ot okoz az operációs rendszer 8.0-ás verziójában. Emellett xorl elcsiripelte, hogy a probléma 8.1-en is jelen van, valamint hogy ez nem csak egy sima DoS...

Jó szórakozást! :)

Le kellett állítani a a számos nyílt forrású projektnek otthont adó SourceForge portál több szolgáltatását, mivel a szolgáltató több szerverén is illetéktelen hozzáférést tapasztaltak az üzemeltetők. A támadás pontos kiterjedéséről és a behatolás mikéntjéről egyelőre nincsenek információk, a hivatalos SF blog szerint most is gőzerővel dolgoznak az adatok ellenőrzésén és a szolgáltatások visszaállításán, de a CVS, és az online kódböngészés nem működik, valamint megtiltották az új release-ek feltöltését és az interaktív shell hozzáférést.

A SourceForge.net egy igen vonzó célpont lehet, hiszen tetszőleges(en bugos) webalkalmazások futtathatók a projektek saját oldalain, ugyanakkor egy kellően csendes akció során számos népszerű szoftverbe csempészhető hátsó kapu, így a könnyű siker reménye mellé csábító haszon is társul. Ennek ellenére viszonylag ritkán hallani SF-t érintő incidensről, bár már jó néhány éve itthoni körökben is ismert volt egy veszélyesnek tűnő hiba (részletekre már nem emlékszem), de valahogy azt sem verte senki nagy dobra :)

A  Ruby kedvelt levelező gem-jének 2.2.15 kritikus biztonsági hibát javít, amely lehetővé teszi, hogy speciális e-mail paramétereket megadva parancsokat hajassunk végre az alkalmazást futtató számítógépen. A kiadott patch-ből jól látszik, hogy sendmail használata esetén a shell parancs összeállításakor a feladó meghatározásához használ -f kapcsoló után ellenőrzés nélkül kerül be a felhasználó által megadott adat, innentől kezdve pedig nem igényel túl nagy fantáziát a hiba kihasználása. A népszerű Ruby on Rails keretrendszer 3.0.x változatai is érintettek, azonban a probléma könnyen orvosolható, ha sendmail helyett más e-mail továbbítási megoldást konfigurálunk.

Az afrikai események reflektorfénybe  állították a közösségi oldalakat, és azok biztonságát, a Facebook pedig két újítással válaszolt (kösz a linket Meister!): 

Az egyik a az opt-in HTTPS kapcsolat bevezetése, ami emberi nyelven annyit tesz, hogy egy új mező került a biztonsági oldalra, amin beállíthatjuk, hogy ezen túl hitelesített és titkosított kapcsolaton keresztül kívánunk hozzáférni a szájthoz. A dolog szépséghibája, hogy ezt eddig is megtehettük, csak a http:// protokollazonosítót kellett https://-re cserélni a böngésző címsorában, vagy telepíthettük például a HTTPS Everywhere Firefox kiegészítést. A "fejlesztés" ugyanakkor nem védi meg azokat az átlagos felhasználókat, akiknek lövésük sincs arról, hogy miért kell egy HTTP kapcsolatot titkosítani.

A másik újítás az előző posztban már említett "Social Authentication" (csak előbb még nem tudtam, hogy ennek ilyen szép neve van). Ezzel akkor találkozhatunk, ha gyanús tevékenységet észlel a stáb a profilunkkal kapcsolatban - például rövid idő alatt a világ különböző pontjain jelentkezünk be. Ilyenkor az oldal feldobja egy ismerősünk néhány képét, és ki kell választani, hogy ki látható a fotókon, így bizonyítva, hogy valóban mi vagyunk a fiók tulajdonosai.

Apropó képek! @benjamin_hu-tól kaptam először a linket az új Facebook képnézegetős hackre, igaz a teljes leírást csak később találtam meg. A probléma valószínűleg még mindig az, hogy a közösségi szájt mögött zakatoló NoSQL adathegyek nem tesznek lehetővé megfelelő autorizációt, így a megfelelő URL kitalálásával bárki fényképalbumait böngészhetjük. Íme a módszer:

• Végy egy publikus képet szíved választottjának profiljából
• Nézd meg a kép URL-jét: nXXXXXXXXX_YYYYYYY_ZZZZ.jpg
• Töltsd be a facebook.com/photo.php?pid=YYYYYYY&id=XXXXXXXXX URL-t, és voilá, itt a privát album!

Szóval ennyit a biztonságról...

Tegnap Nicolas Sarkozy francia miniszterelnök Facebook profilján megjelent egy üzenet, mely szerint az államfő nem indul a következő parlamenti választásokon. Ma pedig a közösségi oldal alapítójának falán lehetett arról olvasni, hogy a Facebook-ot "szociális vállalkozássá" kellene alakítvani, melyben a befektetők nem kapnak hasznot a pénzükért cserébe, ehelyett az összes nyereséget egy előre meghatározott társadalmi cél elérésére fordítják. Utóbbi posztot 1800-an lájkolták, amíg látható volt. 

Nyilván ezer és egy mód van arra, hogy megszerezzük valaki Facebook jelszavát, minden esetre érdekes, hogy ez a két eset ilyen közel következett be egymáshoz.

Még tavaly kaptam a következő érdekességet, de egészen az elmúlt hétig el volt kavarva a postaládámban:

Az Óbudai Egyetem egyik gépén nyitva volt az internet felé egy LDAP port, amire névtelenül lehetett csatlakozni, odabent pedig szépen böngészhetők voltak a dolgozók (és tanulók?) adatai, valamint néhány esetben a Samba LM hash-ei is. 

A portot most már tűzfallal blokkolják, de azért megjegyezném, hogy az egyetem hivatalos oldalán semmilyen releváns kontaktot nem találtam, melyen keresztül kapcsolatba léphettem volna az illetékesekkel. Végül próba szerencse alapon az info@ és hasonló címek valamelyikére küldött e-mailem talált célba (+ köszönet mindenkinek, aki Twitteren segített), pozitívum, hogy nagyon gyorsan reagáltak a megkeresésre. 

A sebezhető hoszt egyébként feltehetően egy régebbi, elhanyagolt darab lehetett, a DNS rekordja még az intézmény régi domain-jére mutatott.

Tanulságként talán annyit lehet elmondani, hogy igen, vannak olyanok, akik azzal töltik a gépidejüket, hogy teljes tartományokat szkennelnek végig érdekes portok után kutatva - ha nyitva hagyjuk az ajtót, előbb-utóbb be fognak rajta jönni.

Egy igen izgalmas cikk jelent meg a The Atlantic hasábjain a Facebook tunéziai forradalommal kapcsolatos szerepéről. A beszámoló szerint a közösségi szájt érezhetően nagy hatással bírt az eseményekre: a tízmilliós országból regisztráltak száma több százezerrel nőtt szűk egy hónap alatt, az oldalon szinte valós időben jelentek meg a tüntetésekről készült sokkoló képek és videók, ami még több embert cselekvésre sarkallt és a szegényebb területekről induló megmozdulások hamar magukkal ragadták a középosztályt is. 

A Facebook szerepét pedig a mára már megbukott vezetés is felfogta, és nem habozott cselekedni. Az internetszolgáltatóknál olyan lehallgató berendezéseket helyeztek el, melyek rögzítették a közösségi oldalakra, blogokra bejelentkező felhasználók hozzáférési adatait, majd ezeket felhasználva törölték a fiókokat. A Facebook felhasználóira ez azért is különösen veszélyes volt, mert az oldal nem tolerálja az álnéven történő regisztrációt, így a jelszavakkal együtt a tüntetések résztvevőinek személyes adataihoz is hozzájuthattak a szolgáltatók, melyeket egy későbbi megtorlás során könnyen felhasználhattak volna.

A felhasználói panaszok természetesen folyamatosan érkeztek a Facebookhoz, és egy idő után világossá vált, hogy gyakorlatilag államilag szervezett, egy ország teljes lakosságát érintő akcióról van szó, ami a maga politikai vetületeivel együtt nehéz helyzetet teremt. A biztonsági csapat ezért úgy döntött, hogy tisztán műszaki problémaként tekintenek az esetre, és megpróbálják megakadályozni, hogy felhasználóik adatai illetéktelen kezekbe jussanak. Ehhez egyrészt a tunéziai IP-kről érkezőket HTTPS kapcsolatra kényszerítették, másrészt elvárták, hogy a tunéziaiak párosítsák össze néhány ismerőük nevét a fényképeikkel, csak így engedtek hozzáférést a profilokhoz. 

Láthatjuk, hogy egyáltalán nem életszerűtlen feltételezni azt, hogy az aktuális hatalom bizonyos helyzetekben akár sokmillió emberrel szemben is kihasználja a rendelkezésére álló technológiai lehetőségeket pozíciója megtartásához, így nem árt résen lenni. Másrészt érdekes ellentmondást hordoz, hogy bár a Facebook egyedülálló lehetőséget ad az önszerveződésre, pontosan ez az a platform, amely a legnagyobb veszélyt jelenti a szerveződők biztonságára, hiszen identitásunk darabjai mindig ott lesznek majd valahol Palo Altoban.