A napokban már a Slashdotot is megjárta Derek Newton felfedezése, miszerint a Dropbox kliensek pusztán egy SQLite adatbázisban tárolt paramétert használnak autentikációra, amely egy fiókhoz tartozó összes kliensnél azonos. Tehát ha valaki hozzáfér a felhasználói könyvtáramban lévő config.db-hez, akkor tudtom és beleegyezésem nélkül turkálhat a fájljaim között. 

Persze ha jobban belegondolunk a dologba, ha egy rosszindulatú támadó hozzáfér a könyvtáram tartalmához, akkor valahogy nyilván hozzáfér a Dropbox-omhoz is, a privát SSH kulcsaimmal egyetemben, ezzel a szolgáltató nem nagyon tud mit kezdeni, ha nem szeretné jelszóablakokkal nyüstölni a felhasználóit. 

Ami viszont a kommentek közötti felvetések alapján aggasztó lehet (legalábbis az almapárti felhasználókra nézve), hogy az OS X-re írt kliens szoftver bárki számára olvashatóvá teszi a configurációs adatbázis fájlját, így egy érvényes OS X hozzáféréssel rendelkező támadó az összes többi felhasználó Dropbox-át lerabolhatja. 

A megoldás persze egyszerű: chmod, de azért jó ha mindezt észben tartjuk!

A támadóknak kint kell maradniuk: a Barracuda Web Application Firewall önállóan teljes védelmet nyújt weboldalainak és web alkalmazásainak. Behatolóknak nem ad esélyt, a lehetséges protokol vagy alkalmazási gyenge pontokon nem autorizált hozzáférés ellen, adatlopás ellen, Denial of Service támadások ellen illetve a weboldalak átírása ellen (Defacement) nyújt hatékony védelmet. A hagyományos hálózati tűzfalakkal vagy IDS-ekkel szemben, amelyek a HTTP, HTTPS vagy FTP forgalmat ellenőrizetlenül a web alkalmazások részére áteresztik, a Barracuda Web Application Firewall nagy előnye: a forgalmat egy proxyn vezeti át, így védve a weboldalát a közvetlen hacker támadások ellen.

[...]

Védi vállalatát minden közismert, web alkalmazások elleni támadással szemben, beleértve az SQL-Injections, Cross-Site Scripting (XSS) támadásokat, session hamisításokat és puffer túlcsordulást.

(A marketingszöveget innen nyúltam)

Nem találjátok ki hogyan szerezték meg a Barracuda ügyfeleinek adatait és alkalmazottainak hashelt jelszavait tartalmazó adatbázisait: SQL injectionnel.

Megjelent az idei Ethical Hacking konferencia előzetes programja, amely ismét izgalmas programot ígér májusra. Az előadások témái jófajta bitszagú prezentációkat vetítenek előre, a színvonalas produkciókra pedig az előadók névsora remélhetőleg mindenki számára garanciát jelent - a magunk részéről Pareto bácsi bölcsességet megszívlelve 80-20 arányú demó-prezi mixtúrával készülünk :)

Az időpont Május 12., csürtörtök - ezt jobb oldalt már remélhetőleg mindenki látja -  a helyszín pedig a Cinema City Arena lesz. A beugró sajnos egy kicsit borsos árú, de a NetAcademiát ismerve biztos lesz lehetőség behackelni magatokat a rendezvényre*.

* Itt természetesen a rendszeres nyereményjátékokra és nem mindenféle tisztességtelen módszerekre próbálok célozni...

KisPocok híva fel rá a figyelmem, hogy a mindig érdekes előadásokkal kecsegtető Simonyi Konferencia idei programjában szerepet kap az etikus hackelés. Papp Péter a behatolástesztelő szakma szépségeibe kalauzolja majd a nagyérdeműt, olyan esettanulmányokat felvonultatva, mint minden hazai wannabe Szent Grálja, az Index.hu.

A konferencián szereplő összes elcsépelt slágertéma (virtualizáció, mobil eszközök, cloud computing...) mellett a biztonság témájához többé-kevésbé kapcsolódik a PLC verifikációról, az információbiztonság gazdaságtanáról illetve a fizikai adatvisszaállításról szóló előadás is, szóval minden kedves olvasómnak érdemes ellátogatnia a BME I épületébe, április 19-én délután. A rendezvény ingyenes.

Antonia Spadaro jezsuita pap egy a Civilta Cattolica nevű vatikáni lapnak szánt cikkében arról értekezik, hogy az ESR-i értelemben vett hacker filozófiája mennyire illeszkedik a keresztény értékrendhez. Az atya megállapítja, hogy megosztás, kreativitás és idealizmus közös alapja a két eszmének, a munka fárasztó, repetitív felfogása helyett az alkotó kreativitás előtérbe helyezése pedig összhangban áll a teremtő ember koncepciójával.

Spadaro megjegyzi ugyanakkor, hogy az egyház hierarchikus szerkezete és a kinyilvánított igazságban való hit nehezen összeegyeztethető a hackerek decentralizáltságot és szkepticizmust támogató szemléletével. A cikket emellett számos ponton kritizálták a szintén vatikáni illetőségű L'Osservatore Romano újságban, így a fenti álláspont koránt sem tekinthető egységesnek vagy hivatalosnak, minden esetre érdekes megfigyelni, hogyan értékelhető ez szubkultúra teológiai szemszögből.

Helyi idő szerint tegnap este debütált az USA-ban a breaking_in című sorozat, amely egy behatolástesztelő cég mindennapjaiba igyekszik bepillantást nyújtani. A történet főszereplője Cameron, aki a főiskola rendszereinek megbuherálásának köszönhetően 27 évesen még mindig a felsőoktatás szűnni nem akaró gondoskodását élvezi. Egészen addig, amíg a Contra Security emberei felül nem vizsgálják a campus hálózatát, és a szokásos alku keretében le nem szerződtetik a tehetséges srácot. 

A történet vitathatatlanul az IT Crowd-Big Bang Theory vonalon építkezik, eszement geek-ekkel és folyamatos popkult utalásokkal, a "szakmai" vonalon pedig a Sneakersből is ismert Tiger Team koncepciót viszi, amivel sikeresen kimanőverezik a fekete-zöld konzolképernyők Bermuda-háromszögéből. A pilot epizódon a magam részéről nem röhögtem szét az agyamat, de azért volt pár jó poén, a konfliktushelyzet megteremtésében viszont nem jeleskedtek az alkotók: nem tudom létezik-e olyan huszonéves srác a bolygón, aki inkább a Nintendo mellett dönt, ha felajánlják neki, hogy a büntetés kockázata nélkül ellophat egy ezüst Lamborghinit. Egy próbát minden esetre megér a sorozat, már csak a dögös zárnyitó chix0r miatt is.

Az ISC biztonsági figyelmeztetőt adott ki, mivel a szervezet által karbantartott DHCP kliens (dhclient) nem szűri megfelelően a DHCP válaszokban érkező hosztnevet, így shell meta-karakterek beszúrásával parancsok hajthatók végre az érintett rendszereken. Mivel DHCP szervert játszani nem különösebben nehéz, helyi hálózaton lógó támadók könnyen kihasználhatják a problémát. 

Az eddigi hírek szerint a SUSE Linux érintett, a többi disztribúcióról egyelőre nincs hír. A problémát a szoftver 3.1-ESV-R1, 4.1-ESV-R2 és 4.2.1-P1 verziói orvosolják.

Gbor és a Slashdot hívta fel rá a figyelmem, hogy Uri Rivner, az EMC biztonsági főnöke egy hosszabb elemzést tett közzé a céget ért incidens részleteiről. Eddig ez az első elfogadható közlemény az EMC részéről, ami bár a legfontosabb kérdést, nevezetesen, hogy mihez fértek hozzá a támadók nem válaszolja meg, de néhány ponton azért világosabbá teszi a történetet. 

Mint kiderült, a támadók feltehetően közösségi oldalak adatai alapján választották ki a cég néhány, nem kifejezetten erős jogkörrel rendelkező munkatársát, akiknek célzott adathalász e-maileket küldtek, melyekhez az eset idején még 0-day Excelbe pakolt Flash exploitot mellékelték. Az egyik célpont sajnos vette a fáradtságot, hogy kikukázza a Levélszemét mappába sorolt üzenetet, és megnyissa a mellékletet. 

A fájl megnyitásakor egy távoli hozzáférést biztosító Poison Ivy variáns települt az áldozat gépére, ahol elkezdett más felhasználókhoz tartozó belépési információkat gyűjteni. A jogosultságkiterjesztés sikeres volt, a támadók hozzáférést szereztek helyi- és tartományadminisztrátori fiókokhoz is, így képesek voltak hozzáférni bizonyos "kulcs aggregációs" szerverekhez, majd az ezekről nyert adatokat jelszóvédett RAR archívumként feltöltötték, egy külső, előzőleg szintén kompromittált FTP kiszolgálóra.

Ennyi a történet, az okosok erre azt mondják, hogy ez egy tipikus APT támadás, én inkább kérdezek:

Túltéve magunkat azon, hogy az egységjúzerek biztonságtudatossága nagyjából a "pirítsunk kenyeret miközben hajat szárítunk a kádban" filozófiával lenne jellemezhető, miért annyira hatalmas elvárás egy antivírussal (ami nyilván ott figyel minden EMC alkalmazott gépén) szemben, hogy detektáljon egy bárki által letölthető trójait, amihez buzgó szkriptkölykök már tucatnyi használati utasítást is közzé tettek a YouTube-on?

Aztán hogy van az, hogy szegény Rivner úr 2011-ben még fontosnak tartja kiemelni, hogy bizony létezik olyan, hogy reverse connect payload? És mennyit ér a hozzáférésvédelem, ha egy alacsony szintű felhasználóból hirtelen domain adminisztrátort lehet gyártani?

Rivner hangsúlyozza, hogy szemléletváltásra lenne szükség az IT-biztonság területén. Nem tudom, hogy a változások szelét, vagy inkább a közelgő szélütést érzékeljük...

Csak egy rövid hír erejéig számolnék be arról, hogy eddig nagyjából 380.000 oldalt fertőzött be egy SQL injection féreg, amit a vonatkozott domain alapján LizaMoon névre kereszteltek. iTuneson is propagálják, vigyázzatok magatorkra!

Még mindig kétségek között hánykolódom az állítólagos Comodo hacker üzenetét illetően, pedig már egy hamisított Mozilla tanúsítványt és privát kulcsokat is prezentáltak a hitelességét alátámasztandó. Ha fogadnom kéne, most arra tennék, hogy az üzenet a valóságot írja le, és valóban egy 21 éves iráni srác kezdett magának tanúsítványokat gyártani a legnagyobb webes szolgáltatásokhoz, így viszont súlyos következtetéseket kell levonni.

Mert a világrengető PWN-ért járó összes kredit mellett sem szabadna komolyan venni valakit, aki az interneten hirdeti, hogy márpedig meg fogja törni az RSA-t, mikor jól láthatóan távolról sincs fogalma a probléma természetéről. Ha ilyesvalaki egyedül tanúsítványt tud generálni egy világméretű CA nevében, akkor k*rva nagy probléma van! És a leírás szerint valóban nem kellett vért izzadni: itt is volt valami webes hiba, a webszerveren meg egy DLL-be forgatott jelszó, amivel gyakorlatilag további korlátozás nélkül lehetett aláírogatni. Igen, úgy tűnik ennyit ér egy hétpecsétes CA védelme.

Persze nem ez az egyetlen magyarázat. Lehet, hogy valamelyik nagyhatalom kiberalakulata hónapok tervezése után hajtotta végre a sebészi pontosságú akciót, a mostani üzengetés pedig csak egyszerű elterelés. Persze ettől még a fent említett faék bonyolultságú támadási vektorok érvényben maradnak, és a professzionális kivitelezés ellen szól az is, hogy a támadók viszonylag hamar lebuktak.

Akárhogy is van, Z-nek igaza volt: senkiháziak kezében van az IT-biztonsági szakma.

Éppen a posztom végére értem, mikor megjelent egy interjú a sráccal az Errata Security blogján. 

Friss: Dr. Berta István Zsolt egy másik nézőpontját emeli ki a történetnek, érdemes elolvasni.

Itt a tavasz, és engem megnyugvással tölt el, hogy vannak még páran rajtam kívül, akik a napsütésben döglés helyett bitet forrasztanak. Ezen a lusta vasárnapon két meglepő és mulattságos szösszenet is érkezett.

Az egyik a McAffee-t érinti (emlékeztek, ők osztogattak Hacker Safe plecsniket egy időben mindenféle oldalaknak), akiknek sikerült úgy konfigurálni a webszeverüket, hogy kilátszódtak az .ASP szkriptek forrásai. Az alábbi ábra azt szemlélteti, hogyan kell karbantarthatatlan kódot gyártani bedrótozott konstansok segítségével:

A másik versenyző a MySQL.com, ahol is - dobpergés - blind SQL injection hibát szúrt ki egy bizonyos Jack. Az alkalmazás persze jó érzékkel DB rootként érte el az adatbázist, így a jelszó hash-ek is kikerültek, meg is fejtették őket hamar. Látható, hogy rendkívül tapasztalt támadókkal akadt össze az Oracle, hiszen elképesztő számítási kapacitást kellett bevetni a jelszavak megfejtéséhez:

A fenti konfigurációkat ellenőrzött vállalati környezetben követték el tapasztalt rendszer- és adatbázisadminisztrátorok. Semmiképpen se próbáljátok ki ugyanezt a rátok bízott hálózatokban!

Friss: Előkerült egy Sun.com dump is

Na jó, kettő híján... Luigi Auriemma 34 PoC exploit kódott tett közzé négy eltérő típusú ipari vezérlőrendszerhez. Meg kell mondanom, nem lepett meg túlzottan a dolog, de azért nem szeretnék szó nélkül sem elmenni amellett, hogy ugyanazok a stack overflow szintű problémák vannak jelen kritikus létesítményeinkben, amelyeken már azt hihetnénk, hogy kezdünk úrrá lenni a tengernyi biztonsági technológiának, módszertannak, szabályzatnak és ki tudja még minek köszönhetően. Csak reménykedni tudok benne, hogy az illetékes gyárók időben észbe kapnak.

Friss:

Ruben Santamarta is közzétett egy 0day-t, miután a gyártó nem reagált érdemben a megkeresésére.

Az alábbi eset valószínűleg be fog vonulni a tankönyvekbe, mint remek példa a hagyományos PKI gyengeségeire.

Az történt, hogy illetéktelenek valamilyen módon hozzájutottak kilenc, a Comodo CA által kibocsátott tanúsítvány kulcshoz, melyek segítségével megszemélyesíthető például az addons.mozilla.org is. 

Ilyen esetekre vannak ugyebár a CRL-ek (tanúsítván visszavonási listák), illetve az OCSP (Online Certificate Status Protokoll), csakhogy ha már a kedves támadónak amúgy is közbeékelődni van kedve, simán hazudhatja azt a gyanútlan felhasználónak, hogy a kért információk jelenleg nem elérhetők, a böngészők pedig folytatják a hamisított weboldal feldolgozását, mintha mi sem történt volna. 

Az egyik megoldás ebben az esetben az lehet, hogy szigorítunk a böngészőnk beállításain, hogy ne töltsenek le olyan oldalt, amely tanúsítványának érvényességét nem tudták ellenőrizni. Ezt Firefoxban a 

security.OCSP.require 

érték igazra állításával lehet elérni az about:config-ban, de ez problémát jelenthet olyan legitim szájtok esetében, ahol nincs meghatározva OCSP kiszolgáló (ha egyéb böngészőkkel kapcsolatban ismer valaki hasonló lehetőséget, azt várjuk a kommentek között).

Most azonban úgy tűnik, hogy a gyártók a saját kezükbe veszik a probléma megoldását: A Firefox 4, 3.6.16 és 3.5.18-as változatai, valamint a Chrome 10.0.648.151 már feketelistában tartalmazzák a kikerült tanúsítványok azonosítóit, és az Internet Explorerhez is készül a frissítés - a többi böngészőről egyelőre nincs hír, továbbá az incidens és a foltok publikálása között eltelt idő is felvet néhány érdekes kérdést. 

Jacob Applebaum blogposztjában részletesen bemutatja, hogy hogyan nyomozott a visszavont tanúsítványok eredete után már a böngészők forráskódjainak frissítésétől kezdve, ajánlott olvasmány!

Frissítés:

A Microsoft most megjelent figyelmeztetője szerint a következő nevekre szereztek tanúsítványt a támadók:

• login.live.com
• mail.google.com
• www.google.com
• login.yahoo.com (3 tanúsítvány)
• login.skype.com
• addons.mozilla.org
• "Global Trustee"

Nem rossz... 

 Frissítés2:

Megjelent a Comodo hivatalos közleménye is. Eszerint az egyik RA egy felhasználójának nevében a támadóknak sikerült egy új felhasználót gyártaniuk, mellyel létrehozták a fenti tanúsítványokat. A támadással több IP cím is összekapcsolható, de ezek nagy része iráni, és az egyik tanúsítványra is ebből az országból érkezett OCSP kérdés. A támadás a cég szerint jól célzott volt, hátterében állami érdeket sejtenek.

Nem rég jelent meg a Metasploit Framework legújabb, 3.6.0-ás változata, amely egy új modultípust vezet be, néhány napja pedig egy új unstable modulfejlesztői fa is megjelent az SVN-ben. Ezekről szeretnék néhány szóban megemlékezni, tekintettel arra, hogy a fentiek lényeges változásokhoz vezethetnek a keretrendszer használatában. 

Ennek a kínai nyelvű blogbejegyzésnek az írója úgy tűnik, hozzáférést szerzett a PHP.net forráskód tárolójához, de a szokásos hátsókapuk létrehozása helyett csak a "credits" listában hagyott egy apró bejegyzést

 Az információ hitelessége egyelőre bizonytalan, fenntartással kezeljétek, ha többet tudok, frissítek!

Nem rég jelent meg egyébként a népszerű interpreter legújabb, jónéhány biztonságiproblémát is javító változata, ezzel kapcsolatban reményeim szerint külön poszt készül majd.

Friss:

Benji hívja fel rá a figyelmet, hogy ennek a srácnak bizony egyszer már lenyúlták a hozzáférését - lehet hogy elfelejtette megváltoztatni a wikin használt jelszavát?

Friss2:

Ahogy Tyra3l a kommentekben felhívta rá a figyelmet, az eset valós csak éppen két hónappal ezelőtti - ma ennyit tudott a best effort kiszolgálás, bocs :)

Tyra3l:

a betores tenye tenyleg nagyon friss info.

eddig nem tudtak, hogy hogyan szereztek meg bjori accountjat decemberben.

ma kiderult, hogy legalabb a wiki-t hostolo gepen tetszoleges kodfuttatast tudott szerezni a tamado, es hogy ugyano kovette el a decemberi commitot

szemely szerint ugy gondolom, hogy nem ket kulon tamadas all a hatterben, hanem a wiki-ben levo sebezhetoseget kihasznalva kovette el a repo modositasat is, akar a user adatbazist elerve, akar valamilyen backdoort elhelyezve a wiki-ben, es bjori eseteben a wikihez hasznalt jelszoval elerte a repot, akar valami mas modon (a gepen elerheto local svn checkout, elmentett jelszoval, etc.)

 

Tegnap éjjel már nem volt erőm megírni, közben a nagy hírportálok is lehozták, a blogról pedig nem maradhat le:

Az RSA ügyvezető elnöke, Arthur W. Coviello, Jr. nyílt levélben fordult az ügyfeleihez a vállalat weboldalán keresztül. A levélben az áll, hogy kifinomult cybertámadás célpontjává vált a vállalat. A támadást nagyrészt sikerült elhárítani, de az azt követő vizsgálat nyomán kiderült, hogy bizonyos információk a támadók kezébe kerültek. Ezek az információk az RSA SecurID kétfaktoros autentikációt biztosító termékcsaláddal kapcsolatosak. A vállalat biztos abban, hogy nem került illetéktelen kezekbe annyi információ, amivel sikeres közvetlen támadást lehetne indítani a meglevő RSA SecurID ügyfelek ellen, de a megszerzett információk elegendőek lehetnek ahhoz, hogy csökkentsék a jelenlegi kétfaktoros authentikációs implementáció hatékonyságát. A vállalat ígéretet tett arra, hogy folyamatosan tájékoztatja az ügyfeleit a kialakult helyzettel kapcsolatban. A levél elolvasható itt. A The Register cikke a témában itt.

(by trey@HUP)

A sztorihoz addig nem fűznék további kommentárt, amíg nem kerülnek nyilvánosságra pontosabb részletek.

Az Adobe figyelmeztetést adott ki, melyben egy eddig javítatlan sebezhetőségre hívják fel a figyelmet a Flash Player, Reader és Acrobat termékek legtöbb támogatott változatában (az alternatív illetve mobil operációs rendszereken futó változatok is érintettek néhány kivételtől eltekintve). 

A hírek szerint az exploitokat Excel-be ágyazott Flash tartalmakkal (ezt ízlelgessétek kicsit!) terjesztik, és egyelőre csak célzott támadásokról van szó. Arról nincs információ, hogy ezek összefüggésben állnak-e a Google felhasználóit ért támadásokkal. 

Az Adobe nem tűzött ki konkrét időpontot a javítások kiadására, annyi biztos, hogy a Protected Mode-dal védett Adobe Reader X-et csak a következő negyedéves frissítéssel fogják javítani, június 14-én.

Frissítés:

A kártevő reszletes elemzése megtalálható itt.

Nir Goldshlager egy HTTP parameter pollution hibát fedezett fel a Google Blogger.com szolgáltatásában, mellyel tetszőleges blog felett át lehetett venni az irányítást. Ahogy arról már volt szó, HTTP parameter pollution esetén egy HTTP POST vagy GET kérésben többször adunk értéket ugyanazon változónak, a sebezhető alkalmazás pedig egyszer az egyik, később pedig a másik értéket használja fel a műveletei elvégzéséhez.

Ebben az esetben a szerkesztők meghívására szolgáló funkciónak a támadó saját blogjának azonosítója után az áldozat blogjának azonosítóját megadva a támadó meghívhatja magát másnak a blogjába, majd hasonló módon kiterjesztheti a jogosultságiait adminisztrátori szintig.

A hiba felfedezéséért Goldshlager bezsebelhette a Google híres $1337 díját.

 Január végén számoltam be róla, hogy a Windows MHTML protokollkezelőjének hibáját kihasználva olyan weboldalakon is elhelyezhető rosszindulatú kliens oldali szkript, amelyek egyébként megfelelően védettek az ilyen típusú támadásokkal szemben. A hibát azóta nem javították, csak egy FixIt csomagot adott ki a Microsoft. 

A Google közlése szerint - a hírt közben a MS is megerősítette - most célzott, politikai hátterű támadásokat indítottak bizonyos felhasználóikkal szemben, melyhez a fenti problémát igyekeznek hasznosítani a támadók. Bár a keresőcég igyekszik szerveroldali mechanizmusokkal gátat szabni a probléma kihasználásának, ezeknek a védelmeknek a hatékonysággáról nincsenek 100%-osan meggyőződve. A valódi megoldást a protokollkezelő frissítése jelentené, de erre még valószínűleg heteket kell várni.

A magyar médiában is rengeteg helyen lehetett olvasni a CanSecWest konferencián rendszeresen megrendezett Pwn2Own verseny részleteiről. Én most szeretnék egy átfogó bemutatást adni a versenyről, tisztázva néhány pontatlanul vagy félreérthetően megjelent részletet.

A Microsoft XBOX live rendszerében is léteznek "feltöltőkártyák", melyek segítségével (jó pénzért) mindenféle virtuális javakat vásárolhatnak maguknak a gémerek. Az IRL megvásárolható kártyákon kódok szerepelnek, melyeket a megfelelő helyre beírva értékes pontokkal lesz gazdagabb a felhasználó. Mikor olvastam, hogy sikerült visszafejteni a kódgenerálási algoritmust, nagyon megörültem, hiszen valami szaftos kriptós okoskodást sejtettem a háttérben - azonban mint kiderült, ismét csak egy elbénázott webalkalmazás áll a háttérben.

Itt található a leírás, hogy hogyan is generálj magadnak virtuális pénzt: cserélj ki két számot egy xbox.com-os URI-ban, és a cég maga állítja ki neked a Microsoft Pointokat. A kevésbé tehetségeseknek valaki még windowsos GUI-t is gyártott:

A Microsoft természetesen igyekszik visszavonni a kiadott krediteket, de a becslések szerint így is nagyjából 1 millió dolláros kárt okoztak a csalók. 

szerializáció (programozás): egy objektum soros formában (tipikusan karakterláncként) történő megjelenítése

Sami Koivu megint publikált egy sor kellemetlen módszert a Java  applet sandboxból történő kitörésre. Ezek közül kettő a vágólapon található adatokhoz enged hozzáférést viszonylag egyértelmű módon (egy java.swing.TransferHandler-t valamely GUI komponensre helyezve referenciát kapunk a vágólapra), a harmadik viszont az ún. "privilegizált deszerializáció" hibaosztály egy újabb példánya. Ezt a hibaosztályt mutatnám be most néhány mondatban, a cr0 blog vonatkozó bejegyzésére támaszkodva:

Az állítorvosi ló a szintén Koivu által felfedezett, CVE-2008-5353 névre keresztelt hiba lesz, amit az adott évben a legszebb kliens-oldali hibának járó Pwnie-ra is jelöltek. 

A probléma hátterében az áll, hogy az appletekben elérhető java.util.Calendar osztálynak néha deszerializálnia kell sun.util.calendar.ZoneInfo objektumokat. A sun csomag azonban nem hozzáférhető az applet homokozóból alapesetben, de szerencsére (?) a java.util egy megbízhatónak tekintett csomag, amely képes a homokozón kívül is játszani a doPrivileged() blokk használatával. A problémát okozó programrész valahogy így néz ki: 

/**
* Reconstitutes this object from a stream (i.e., deserialize it).
*/
private void readObject(ObjectInputStream stream) {

...

try{
    ZoneInfo zi = (ZoneInfo) AccessController.doPrivileged(
    new PrivilegedExceptionAction() {
        public Object run() throws Exception {
            return input.readObject();
        }
    });
    if (zi != null) {
        zone = zi;
    }
} catch (Exception e) {}

...

}

A gond az, hogy senki sem garantálja, hogy a deszerializálandó soros adatfolyam valóban egy ZoneInfo objektumot reprezentál! A hiba tipikus kihasználási módja az, hogy egy ClassLoader objektumot olvastatunk fel, ami az emelt jogosultságó kontextusban futva tetszőleges osztályt tetszőleges protectionDomain-nel (azaz jogosultsági szinttel) létrehozhat, ezzel pedig vége a játéknak. Az egyetlen bibi, hogy az explicit kasztolás miatt végül mégis történik egy típusellenőrzés, de ekkor már késő, mivel a bemenetként adott objektum readObject() metódusa hozzárendelheti saját magát egy statikus adattaghoz, így hozzáférhető marad, és a szemétgyűjtő sem takarítja el. 

Aki a fentieket elsőre megértette, azoknak ajánlom a család legújabb tagjának áttanulmányozását, ebben az esetben ugyanis még kiegészül néhány elegáns csavarral a történet!

Wietse Venema, a Postfix fejlesztője a napokban felfedezett egy sérülékenységet a saját STARTTLS implementációjában, amely több más szoftverben is előfordul. A probléma az, hogy a titksított és hitelesített kapcsolat létrehozására utasító STARTTLS parancs után sortöréssel beszúrható még egy, tetszőleges utasítás. Ez értelemszerűen még titkosítatlan és hitelesítetlen csatornán közlekedik, így egy útba eső támadó tetszőleges parancsot beszúrhat a kommunikációba, amely a TLS kapcsolat kiépülése után le is fut*. 

Venema szerint a probléma nem kifejezetten súlyos, tekintve, hogy sok kliens amúgy sem ellenőrzi a szerver tanúsítványát, így a közbeékelődés sok esetben a TLS ellenére is megvalósítható. 

Az érintett szoftverek listáját itt találjátok, a Postfix a 2.7.3, 2.6.9, 2.5.12 és 2.4.16 verziókkal javította a hibát.

* A parancsok természetesen nem az operációsrendszeren, hanem a TLS-t használó alkalmazásban értelmeződnek és hajtódnak végre.

Te jóságos ég, hogy repül az idő! Szerencsére a tavaszi zsongásba (a fagyos szélben állva csak arra gondolok, milyen jó meleg lehet a otthon, a monitor előtt) nem zavar be jelentősen az ehavi MS frissítés, a három hibából kettő ugyanis egy-egy szimpla DLL hijacking sebezhetőség (az egyik a Groove-ot, a másik az RDP klienst érinti).

A harmadik javítócsomag két hibát foltoz a DirectShow kodekben, valamint a Media Player/Centerben, előbbi komponensben szintén DLL betöltési problémát javítottak, míg a lejátszó esetén egy hagyományos puffer-túlcsordulásnak tűnő problémát alimináltak a .dvr-ms fájlok kezeléséből.

Ki adalék, hogy míg a Firefox és a Chrome is kiadott biztonsági frissítéseket a Pwn2Own előtt, az Internet Explorer úgy tűnik lazán áll a megmérettetéshez. Hogy ezt túlzott önbizalom, vagy az esélytelenek nyugalma okozza, az hamarosan kiderül!

Rendszergazdáknak ma engedélyezett egy kávészünet ;)

 Mire nem jó egy buta böngészőhiba! Jon Oberheide egy olyan XSS-t fedezett fel az Android Marketen, amit bármilyen script kiddie megirígyelne: ha beírsz egy tetszőleges szkriptet az alkalmazásod leírásába, az bizony lefut. 

A dolog azért különösen gyönyörű, mert a Market lehetőséget biztosít az alkalmazások weben keresztüli telepítésére, így egy elegáns AJAX hívással máris telepíthető a látogató androidos eszközére az app, erről pedig csak egy nem túl erélyes figyelmeztetést kap a júzer. 

És bár ilyenkor az alkalmazás még nem indul el, a telepítéskor beköthetők különöző eseménykezelők, amik automatikusan elindíthatják a potenciálisan rosszindulatú kódot. Ez egyik esemény amire rá lehet akaszkodni, az "új alkalmazás telepítése", ami éppen megfelelő lesz, hiszen az előző XSS-sel nem csak egy, hanem akár két appot is telepíthetünk, így a második alkalmazás lényegében beindíthatja az első futását. 

De történet epikus része ezzel még el sem kezdődött, tudni kell ugyanis, hogy Oberheide azonnal jelentette a problémát a Google-nek, ahol javították is azt. A felfedező azonban "túl gyorsan" cselekedett, mivel a feltárt hibával indulni lehetett volna a Pwn2Own versenyen, melynek győztese 15.000$-t vihet haza egy Android feltöréséért, márpedig Oberheide exploitja nagy megbízhatóságú és nagyjából verziófüggetlen volt, már ahogy az a webes hibáknál lenni szokott. Vígasztalásul a Google az általános hibavadász programja által meghatározott 1337$-t azért kiutalta a becsületes bejelentőnek...

a bejegyzés egy kis kísérletet tartalmaz, remélem magára veszi, akinek inge