A görög FORTH (Foundation for Research and Technology Hellas) intézet kutatói egy kísérlet során azt vizsgálták, hogy milyen hatásfokkal lehet egy közösségi hálózatot támadásra alkalmas, DDoS puppetneteket létrehozni. A puppetnetek lényege, hogy velük a web lehetőségeivel élve, egy weboldal népszerűségét kihasználva lehet túlterheléses támadást intézni különböző célpontok ellen. Az elv lényegében hasonló a Slashdot-hatáséhoz, aminek lényege, hogy a Slashdoton linkelt oldalak sokszor akkora forgalmat kénytelenek hirtelen elszenvedni, amit már nem képesek kiszolgálni.

A FORTH kutatói egy kísérleti Facebook alkalmazást (Picture of the Day, vagy más néven a FaceBot) kreáltak, amely amellett, hogy képeket töltött le a National Geographic weboldaláról, észrevétlenül kéréseket intézett egy direkt erre a célra felállított géphez is, ami az áldozat szerepét töltötte be. A kutatók mindevégig tartották magukat a "legkisebb erőfeszítés" elvéhez, azaz a lehető legegyszerűbben igyekeztek megoldani a feladatot. Ennek alapján alkalmazásuk mindössze megjelenítésenként 4 kérést intézett a célponthoz, összesen 600kb forgalmat generálva (képletöltések), valamint a terjesztést is a lehető legegyszerűbb módon odlaották meg: szóltak a kollégáknak, hogy installálják az alkalmazást, és alánlják azt ismerőseiknek is.

Ilyen módszerrel összesen 400-500 felhasználóhoz jutott el a FaceBot, a puppetnet maximális teljesítménye pedig 300 kérés/óra illetve 6 Mbit/s volt. Ez persze nem túlzottan sok, főleg ha egy rendes botnet lehetőségeihez viszonyítunk, azonban a kísérlet célja nem a kimeneti sávszélesség maximalizálása volt. Számos módszer rendelkezésre állhat egy ilyen jellegű rendszer felhízlalására:

A Facebook pl. lehetőséget kínál az alkalmazásfejlesztőknek, hogy kiegészítéseiket csak úgy lehessen telepíteni, ha előtte néhány ismerősünknek ajánljuk azt. Némi JavaScripttel könnyen megoldható, hogy a konstans 4 helyett annyi kérdést intézzünk a célponthoz, amennyi belefér abba az időbe, ameddig a felhasználó nyitva tartja a FaceBot-ot.

A legnépszerűbb Facebook alkalmazások jelenleg több (tíz)milliós felhasználói táborral büszkélkedhetnek, ami napi 1-2 millió aktív felhasználót jelent. Amennyiben egy ilyen kiegészítést vérteznénk fel DoS képességgel, az akár 248 Gbyte* napi adatfogalmat is eredményezhetne a célpont hálókártyáján, ami főleg akkor fájdalmas, ha az áldozat forgalomarányosan fizet a vonalért.

A védekezés alapvetően a közösségi oldalakon kellene hogy megtörténjen: a feltöltött kiegészítőket folyamatosan ellenőrizni kell, a fejlesztőknek pedig olyan API-t kell biztosítani, ami nem ad lehetőséget az ilyen jellegű visszaélésekre (ennek persze vannak megvalósítási problémái).

Az áldozat oldalán a beérkező kéréseket a legegyszerűbben a referer alapján szűrhetjük, de ez is egyrészt egy viszonylag számításigényes feladat (az alkalmazási rétegben kell elemezni a csomagokat), másrészt egy támadó szerver beiktatásával a bábok rávehetők, hogy ne küldjenek referer információt.

* A forgalom börsztössége miatt nem számolhatunk álladndó csúcsérték környéki tűzerővel, mindazonáltal én még így is kissé keveslem ezt a számot, de a papírban ez szerepel.

Az utóbbi napokban jó nagy viharokat kavartak a Google Chrome-mal kapcsolatos biztonsági kérdések. Ma végre volt időm egy kicsit utánajárni a dolgoknak, amihez nagy segítséget nyújtott ez a doksi, amit sghctoma linkelt be egy kommentben. A másik forrás a Chrome alapján képező Chromium motor fejlesztői dokumentácója volt, amit itt találhattok meg.

Biztonsági szempontból a legfontosabb kérdés a Google böngészőjével kapcsolatban az, hogy van-e benne valami fajta sandbox eljárás megvalósítva? A válasz természetesen attól függ, hogy mit tekintünk (teljes értékű) sandboxnak. A Wikipedia azt írja:

"A számítógépes biztonság területén a sandbox egy programok biztonságos futtására használt eljárás. [...] A sandbox tipikusan az erőforrások, mint pl. a lemezen és a memóriában lévő munkaterület egy szűkre szabott halmazához enged hozzáférést a vendég folyamatok számára. A hálózati hozzáférés és a kiszolgáló fájlrendszerről illetve bemeneti eszközökrő való olvasás lehetősége általában erősen korlátozott."

Szigorú értelemben véve ezek a kritériumok a Chrome esetében nem teljesülnek maradéktalanul, mégis azt mondhatjuk, hogy a Google törekvése ezeknek az elveknek a megvalósítására igencsak figyelemre méltó a böngészők piacán.

A Chrome elveti az általánosan elterjedt, monolitikus szemléletmódot, és modulárisan épül fel. A megbízhatatlan forrásból érkező, potenciálisan veszélyes adatokat a külön folyamatként futó renderelő modulok dolgozzák fel, ezeket pedig a böngésző kernel fogja össze, amely kapcsolatot biztosít a renderelő folyamatok és az operációs rendszer által kezelt ablakkezelő és fájlrendszer között. Míg a kernel az alkalmazást indító felhasználó jogaival működik, addig a veszélyes renderelő modulok operációs rendszer szinten szigorúan korlátozott folyamatokként futnak, és ez az, ami (jó esetben) megakadályozza azt, hogy ezek a processek a böngésző kernel biztonsági mechanizmusait kikerülve működhessenek. Konkrétan a renderelő folyamatok:

• Korlátozott biztonsági tokennel
• Windows Job objektumként
• Külön asztalon (ez néhány hiányosan megírt API fv. miatt)
• Vistán pedig külön integritási szinten

futnak (Ennél a pontnál érthetővé válik, hogy miért csak Windowsra érhető el a program). Ezekkel a privilégiumokkal a megbízhatatlan kódokat futtató folyamatok gyakorlatilag semmihez nem férhetnek hozzá közvetlenül. Ugyan a Windows biztonsági mechanizmusaiban lehetnek hibák, de ez már nem a Chrome problémája :)  Azt viszont nem szabad elfelejteni, magában a böngésző kernelben is lehetnek  hibák. Ezen kívül a hivatalos dokumentáció fehívja a figyelmet néhány területre, ahol a fenti eljárások nem működnek:

• FAT fájlrendszeren nincs lehetőség ACL-ezésre, ezért az ilyen típusú köteteken (pl. pendrive) lévő fájlokat nem védik meg a korlátozott tokenek.
• Elméletileg lehetséges TCP/IP socketeket nyitni Windows 2000-en és XP-n, mivel az ehhez tartozó alacsony szintű rendszerhívások nem igényelnek megfelelő azonosítást, ám ezt a lehetőséget a Stanford kutatóinak nem sikerül kihasználniuk.
• a különböző anti-malware megoldások esetleg beszúrhatnak olyan DLL-eket a renderelő modulok folyamataiba, amelyek nem várt működést okozhatnak.

A Chrome sandboxing rendszere tehát korántsem tökéletes, ezt az elmélet és a gyakorlat is jól mutatja. Azt viszont kifejezetten szívderítő látni, hogy végre van egy böngésző, ami túl tud lépni a phishing figyelmeztetések dobálásán, és az architektúra alapjainál igekszik kezelni a biztonsági kérdéseket. Én drukkolok, hogy ez minél jobban sikerüljön!

A Discovery csatorna népszerű, Mythbusters (Állítólag) műsorának készítői úgy gondolták, érdemes lenne górcső alá venni az egyre népszerűbb RFID technológiát. A technikai részletek tisztázása végett a stáb felvette a kapcsolatot a Texas Instrumentsszel, akik értesítették a technológiában szintén érintett bankokat (Visa, American Express... szóval a nagyobb nevek), akik - legalábbis a műsor egyik házigazdájának, Adam Savagenek elmondása alapján - ügyvédeik útján adtak hangot a téma feldolgozásával kapcsolatos nemtetszésüknek.

 A Texas Instruments persze egészen másként emlékszik a történtekre: szerintük a Discovery gondolta meg magát, kérdés azonban, hogy milyen okból tették volna ezt?

A lényeg az, hogy az epizód végül nem fog adásba kerülni, ez pedig - legalábbis számomra - megingatja a bizalmat a banki környezetben használt RFID megoldások biztonságával kapcsolatban...

Adam HOPE-os előadása alant:

 Miután a Google helyesbítette a Chrome EULA-ját, most rajtam a sor, hogy felülbíráljam az új böngészőről szóló első posztomat:

Egy igen terjedelmes, ugyanakkor meglepően tartalmas vita alakult ki egy webjúzer nevet viselő olvasó kommentje nyomán, melyben arról volt szó, hogy a Chrome folyamatszétválasztási mechanizmusai - a nálam is megjelent állítással ellentétben - nem védenek meg a rosszindulatú kódfuttatástól illetve (mint ahogy a belinkelt exploit is mutatja) DoS támadásoktól.  Több helyen olvasható volt ugyanis olyan állítás, mi szerint a Chrome virtuális környezetben futtatja a megnyitott webalkalmazásokat, így azoknak esélyük sincs hozzáférni a fizikai memóriához.

Webjúzer ezzel szemben azt állítja, hogy megnézte a Chrome forráskódját, és ilyen jellegű szeparációval nem találkozott. Én hajlok arra, hogy a Google marketingjével szemben inkább neki higyjek, személyesen erről az állításról eddig nem volt alkalmam meggyőződni (ezt a posztot is sebtében dobálom össze éppen). 

A lényeg azonban az, hogy végül olyan vita alakult ki, melyből a néha elszabaduló indulatok ellenére sokan, sokat tanulhatnak, már ha van ereje az embernek végignyálazni 50+ hozzászólást. 

Tegnap jelent meg a Google böngszője, a Chrome, amit a szorgos hackerek azonnal elkezdtek darabokra szedni.

Meg is jelent DoS exploit, valamint egy minimális felhasználói közreműködést igénylő, kódfuttatást lehetővé tevő PoC - ez egy már foltozott Safari sebezhetőség és egy BlackHaten bemutatott Java bug kombinációja, ami arra utal, hogy a böngésző az Apple WebKit-jére épül, azaz a "from scratch" nem teljesen stimmel.

Az viszont határozottan pozitív hír a böngészővel kapcsolatban, hogy minden általa futtatott webalkalmazás szeparált memóriaterületen, egyfajta virtuális gépen fut, így a különböző túlcsordításos támadások kihasználása - elméletben - jóval nehezebbé válik.

A Chrome a közeli jövőben mindne bizonnyal a böngésző hackerek kedvelt célpontja lesz, így nem hiszem, hogy szűkölködni fogunk a vele kapcsolatos, biztonsági témájú hírekben.

Zughekker írt egy jó kis összefoglalót az adatmegsemisítéssel kapcsolatos általános tudnivalókról. Az anyag érthető és összeszedett, de nekem azért lenne egy kis kiegészítésem a témához:

A merevlemezek ugyan digitális adathordozók, az infomrációtárolás rajtuk mágnesjelekkel történik, melyek terének erőssége analóg jelnek tekinthető, bár ezt a vincseszter elektronikája megfelelő kvantálással elfedi előlünk. Íráskor ezek az analóg értékek az ideális  szint környékére kerülnek, de soha nem lesznek teljesen pontosak, ráadásul az eltérés mértéke függ a felülíró bit értékétől és az író jel frekvenciájától is. Ezek alapján az eltérések alapján akár a többszörösen felülírt adatok is visszaállíthatók. Peter Gutman és Colin Plumb kidolgoztak egy módszert, amely 35 felülírással - melyek közül 8 véletlen, a többi pedig véletlenül választott speiális adatokkal történik - eléri, hogy a törölt infomráció valóban visszaállíthatatlanná váljon*. Emiatt természetesen az eljárás igen lassúvá válik.  Az algoritmust egy sor szoftverben implementálták, érdeklődőknek ajánlom a Wikis szócikk idevágó passzusát.

* A pontos algoritmus régi kódolású merevlemezekhez készült. A kódolás változásával a válaszott adatokat is meg kellene változtatni, de mivel nincs mindenkinek otthon tisztaszobája, Guttman azt ajánlja, hogy néhányszor írjuk felül az adatainkat véletlen bitsorozatokkal, és ez is majdnem olyan jól fog működni. Persze kérdés, hogy  véletlenszám generátorunk mennyire volt megjósolható;) Szóval téme elég messzire nyúlik...

Tomot, a MySpace alapítóját azt hiszem senkinek nem kell bemutatni: 240 millió ismerőssel az embert talán joggal mondhatjuk népszerűnek. Azt azonban eddig csak néhányan sejthették, hogy a milliárdos értékű cég fejének múltja nem teljesen makulátlan:

A TechCrunch az online digitális archívumokba újabban bekerült újságcikkek nyomán egy kis nyomozást végzett a MySpace arca után, melyek során olyan információk kerültek napvilágra, melyek szerint tizenéves korában Tom Anderson egy feketekalapos californiai hacker banda vezetőjeként az állam történetének egyik legnagyobb szabású FBI akciójának egyik célpontjává vált.

A dokumentumok tanúsága szerint Anderson telefonszám-tartományok automatikus végigtárcsázásával élő modemkapcsolatokkal rendelkező szervereket keresett (ezt nevezik úgy, hogy war dialing), melyeket gyakran csak az alapértelmezett jelszó védett, vagy még az sem. Az egykori vád szerint Tomnak sikerült bejutnia a Chase Manhattan Bank rendszerébe, ahol fiktív számlákat kreált, két jelszó megváltoztatásával kizárta a jogosult operátorokat a rendszerből, és Lord Flathead néven hagyott egy üzenetett, melyben szabad hozzáférést kért a rendszerhez, ennek nem teljesülése esetén pedig az adatok megsemmisítésével fenyegetőzött. Ezt elkerülendő, az FBI csapdát állított a banda tagjainak, majd egy összehangolt akció keretében 23 emberen ütöttek rajta.

Mindez 1986-ban történt, Tom ekkor 14 éves volt, azaz kiskorú, így az egész balhét megúszta azzal,  hogy ígéretet tett rá: soha többé nem fog betörni számítógép rendszerekbe :) A társaival kapcsolatos eljárásokról nem maradtak dokumentumok, mintahogy arra sincsen bizonyíték, hogy Lord Flathead megpróbált volna kárt tenni a CMB rendszerében tárolt adatokban. A szabad rendszerhozzáférésre való igény valószínűleg azért merült fel, mert annak idején személyi számítógépeken nem lehetett hozzáférni pl. C fordítókhoz, ezért a hackereknek nagygépekre kellett bejutniuk, ha programozni akartak.

Tom és a MySpace egyelőre nem kívánta kommentálni a hírt, ami megerősíteni látszik a történetet, bár a netes közösség szemében ez úgy tűnik egy igazi, hőskori, tökös hacker story, ami még jól is mutathatna a vállalatigazgató életrajzában :)

Megjelent a Wired BGP-s lehallgatásról szóló cikkének második része, amely körüljárja a BGP-vel kapcsolatos eddigi biztonságot érintő kérdések múltját és jövőjét. A cikk egy sor érdekes hivatkozást tartalmaz, melyeket most csak sebtében kigyűjtök ide, hogy annak, aki a hétvégét jól megérdemelt kikapcsolódás helyett szakirodalom olvasgatásával kívánja tölteni, ne legyen oka az unalomra:

• A DefCon-os előadás slide-jai itt vannak
• A Cornell Egyetemen részletes dolgozat készült a támadás kivitelezhetőségéről, melyben az Internetre gyakorolt hatást is elemzik.
• Az MIT-n is készült egy hasonló tanulmány
• A NIST laza 61 oldalas anyaga a BGP-vel kapcsolatos biztonsági kérdésekről
• Steve Bellovin már '89-ben (!) írt a problémáról
• Szintén ő és Steve Kent '99-ben az útválasztó és DNS protokollokat nevezték az Internetet érintő legnagyobb problémának

Durva mi?

Ez a videó már a hírhedt Pakisztáni YouTube blokád lefolyását mutatja, 2 órát sűrítve kb. 3 percbe. Bár egyesek információk szerint az egésznek semmi köze sem volt a BGP-hez...

Alex Pislov, az egyik DefCon-os előadó ígéretett tett, hogy figyelni fogja a Wired-en megjelenő kommenteket, és válaszol rájuk, így ha kérdésetek van, azt feltehetitek közvetlenül neki is!

A strasburgi emberjogi bíróság elutasította a "világ legveszélyesebb hackerének" titulált Gary 'Solo' McKinnon kiadatás elleni kérelmét.  Az "UFO hackerként" is ismert férfi azért fordult a legfelsőbb európai bizottsághoz, mert úgy gondolja, hogy nem számíthat tisztességes eljárásra a kiadatását kérő Egyesült Államokban. Solo kiadatása két héten belül várható. Most már talán tényleg lesz értelme a Free Gary mozgalomnak...

Beteg. Egy synapse szintetizátort nem akar csinálni valaki? :)

Egy szövetségi határozat szerint 2009-től kezdődően minden .gov végződésű domain a DNSSEC protokollt fogja használni a névfeloldáshoz. A lépés válasz az utóbbi időben megjelent DNS cache poisoning támadásokra. A DNSSEC protokollt használva meggyőződhetünk róla, hogy a névfeloldáshoz használt üzenetek valóban attól a névszervertől származnak, amelyiktől várjuk őket, ez pedig védelmet nyújt ezzel a támadási formával szemben. Ez a lépés remélhetőleg elindít egy folyamatot, mely során egyre többen állnak át erre a biztonságos protokollra, és az internetszolgáltatók, valamint a hardver- és szoftvergyártók is rákényszerülnek az együttműködésre.

Az ASVA.info adta le a drótot, hogy deface-elték a képtár.net-t. A célok egyike minden bizonnyal ismét Norbertka lejáratása volt.

Anton "Tony" Kapela és Alex Pilosov az idei DefConon először demonstrált a nagy nyilvánosság számára egy eddig csak elméletben létező támadási formát, melynek segítségével elvileg az internet (pontosabban egy-egy internetszolgáltató) bármely felhasználójának forgalmazása lehallgatható. A módszer nem használ ki semmilyen szoftver vagy protokollhibát, egyszerűen a Border Gateway Protocol, az internet alapvető útválaztó protokolljának jóhiszeműségére épít.

A BGP segítségével határozható meg, hogy két autonóm rendszer (AS - tipikusan egy internetszolgáltató által kezelt címtartomány) között melyik a leghatékonyabb útvonal. Az AS-ek meghírdethetnek bizonyos címtartományokat, amelyekre képesek továbbítani a kéréseket. Egy kérés afelé az AS felé fog továbbítódni, amelyik a legszűkebb, a cél címét tartalmazó tartományt hírdette meg. Logikusan, egy kellően szűk tartomány meghírdetése esetén a választott címek felé irányuló kérések mind a mi hálózatunkon fognak keresztülmenni, ahol könnyedén bele tudunk avatkozni a forgalomba.

Ez a módszer már hosszú ideje ismert volt, Mudge, az egykori L0pht hackercsapat jeles képviselője már '98-ban egy hasonló elméleti támadásra alapozva kijelentette, hogy 30 perc alatt működésképtelenné tudná tenni az Internetet. Az ilyen jellegű támadási kísérletekre azonban eddig mindig hamar fény derült, mivel a módosult útvonalon közlekedő kérések egyszerűen elvesztek (legutóbb Pakisztán véletlenül maga felé irányította az összes YouTube-ra irányuló forgalmat, aminek persze nem lett jó vége).

Az újdonság most abban rejlik, hogy a kutatók módszerével az egész támadás észrevétlenül kivitelezető: a páros sikeresen eltérítette a las vegasi DefCon hálózatában közlekedő információkat saját, New York-ban található hálózatukba, majd vissza vegasba anélkül, hogy ezt bárki is észrevette volna. Az újítás lényege, hogy néhány BGP routert ráveszünk, hogy utasítsa el az eltérülést okozó címtartomány-bejelentéseket, majd az ezen routerek által képviselt AS-eken keresztül továbbítjuk a lehallgatott adatokat mintha mi sem történt volna.

A támadás kivitelezéséhez szükség van egy megfelelő hálózati központban elhelyezett BGP routerre, így a potenciális támadók köréből kiszorulnak az egyszeri hackerek, és inkább az ISP-k, kormányügynökségek és nagyobb vállalatok maradnak a palettán, az egyszerű felhasználók forgalmának lehallgatása helyett ipedig nkább az (ipari)kémkedés illetve szabotázs kerül előtérbe.

A védekezéshez az internetszolgáltatóknak egymással szorosan együttműködve szigorú szűrőfeltételeket kellene életbe léptetniük, hogy ne tudjon akárki tetszőleges BGP üzeneteket küldeni, vagy át kellene térni a nyilványos kulcsú tanúsításon alapuló SBGP protokollra, ami viszont a BGP routerek gyártóitól kívánna meg további fejlesztéseket.

A Wired cikke alapján.

EQ készített egy jó kis fordítást az SQL csonkolásos támadásfajtáról, érdemes elolvasni!

A témáról itt is volt szó régebben.

Eldőlt a sörözés időpontja: a szavazatok alapján szeptember 12. nyert. Csalásnak nyomát nem észleltem, de ez persze nem jelent semmit: amint azt láthattuk, a blogpolling elég jól hakkolható :) Szóval várok mindenkit szeretettel a Hacktivity előtti hét péntekén 19:00 órakor a szokott helyen!

Na ez szívás:

A sors iróniája, hogy “feltörték” a bithumen.de tulajdonosainak (?) Joker.com-os és a  freemail-es fiókját, és defacelték az oldalt. Ahogy azt korábban megírtuk, a bithumen.de-n egy fake bH regisztrációs felület volt, az egész az emberek lehúzására ment ki. Erre persze hamar rájöttek az emberek (hm, talán a mi és a fikablog hathatós közreműködésével) és az oldal hamisított webhely státuszt kapott.

 

A tanulság: ha már kisstílű adathalász-spammer-DDoS majom vagy, legalább a jelszavaidat válaszd meg normálisan!

A PopularMechanics interjút készített Zack Andersonnal, a bostoni metró biztonsági rendszerében hibákat találó MIT-s fiatalok egyikével.

A magyar változat alant:

Ki korán kel, aranyat lel: ébredés után friss Hacktivity hírlevél várt a postaládámban, amely új előadások emleget. Íme tehát az új lista, nyomtam egy diffet is azok kedvéért, akik csak a változásokra kíváncsiak:

1. Buherátor: Mindent az SQL Injection-rõl
2. Sütõ János: Statisztikai spamszûrõk - elmélet és gyakorlat
3. Szakály Tamás: MD5 hash törés videokártyán
4. Bucsay Balázs: XSS féreg, vírus
5. Baki Gábor: Haladó WiFi törés - amirõl eddig még nem beszéltünk
6. Veres-Szentkirályi András: Jelszavak és titkosítások visszafejtése 
célhardverrel - ahogy a titkosszolgálatok csinálják
7. Csiszér Béla: Mobil vírusok
8. Berta István Zsolt: PKI az adathalászat (phishing) ellen?
9. Sík Zoltán Nándor: Információs hadviselés
10. Pánczél Zoltán: Web service-ek hackelése
11. Spala Ferenc: Oracle hacking
12. Illési Zsolt: Open Source Forensics
13. Barta Csaba, Major Marcell: Fuzzing (automatizált sérülékenység felderítés)
+14. Fóti Marcell: Szivárványtáblák
15. Muha Lajos: Szabad-e oktatni biztonsági kérdéseket, avagy képezzünk hackereket?
+16. Bokor László: A privátszféra védelme a jövõ kriptográfiai alapokon nyugvó mobilinternet-architektúrájában [wow]
+17. Gyöngyösi László: Valóban feltörhetetlen? A kvantumkriptográfia biztonsági analízise [én <szív> kriptó :)]
18. Hova tovább magyar hackerek?
Kerekasztal-beszélgetés Buherátor, Andrei és Krasznay Csaba részvételével

Sikerrel használták ki a Kaminsky-féle DNS hibát Kína egyik legnagyobb internetszolgáltatójának, a Netcomnak az elsődleges DNS szerverén - jelentette a Websense. A szolgáltató a szokásos hibaüzenet helyett különböző hírdetésekkel telezsúfolt oldalakat jelenített meg felhasználói számítógépén, amennyiben azok hibás domain-lekérdezéssel fordultak a névszerverhez (pl. elírtak egy címet). A támadóknak ezeket a hírdetőoldalakat sikerült eltéríteniük. Az újonnan beállított címeken aztán különböző ismert exploitok segítségével igyekeztek kártékony kódokat futtatni a látogatók számítógépein.

Azt nem tudni, hogy a támadás honnan eredt, de azért van egy tippem, hogy a helyi hatóságoknak nem kellene útlevelet váltaniuk a nyomozáshoz...

Most esett be a postaládámba egy levél, egy volt osztálytársamtól. Az illetőt már kb. egy éve nem láttam, de az előtt sem beszéltünk túl sokat. Most meg jön egy levél, két .doc fájl van benne "Segítség!" címmel.

Persze nem nyitottam ki őket, nem mintha olyan szívtelen gazember lennék, meg úgyis Linux van meg OpenOffice, de valahogy sejtettem, hogy nem szalasztok el semmilyen lehetőséget a világmegváltásra: pont ma írta meg a ZDnet, hogy a TippingPoint a legutóbbi MS patchel egy időben egy sor súlyos, foltozatlan Office hibát jelentett be, melyek rosszindulatú kódfuttatást tesznek lehetővé, ha a kedves felhasználó speciális Office dokumentumokat nyit meg. A cégnek ezek mellett még két Office-hoz kapcsolódó adóssága van, az egyik májusból, a másik júlisusból.

Mi remegve várjuk a következő frissítő keddet, addig is mindenkinek azt ajánlom: messze kerüljétek el a kétes forrásból származó Office dokumentumokat!

A Crypto-2008 konferencián osztrák és lengyel kutatók két figyelemre méltó támadást mutattak be az SHA-0 és SHA-1 hash függvények bizonyos változatai, valamint az orosz állam hivatalos algoritmusa, a GOST ellen.

Ezek közül az egyik egy "jól megszokott" ütközéskereső módszer (vigyázz, magas matek!), amely jellegéből adódóan főleg a digitális aláírások világában okozhat fejtörést a GOST-t használóknak, bár egyelőre nem túl sokat: a támadás 2^29-ed részére csökkenti az ütközés megtalálásához szükséges elméleti maximális számításigényt, de még így is 2^105 marad a feladat komplexitása.

A másik támadás ennél sokkal komolyabb, bár csak az SHA algoritmus csökkentett lépésszámú, legfeljebb 45 körös változataira használható, és egyelőre nincs remény a módszer kiterjesztésére. A kutatóknak sikerült lényegében visszafordítaniuk az algoritmust, ami már csak a hash algoritmusukra jellemző információveszteség miatt is figyelemre méltó, és nagyban érinti a számtalan helyen használt jelszó hashelési mechanizmusokat. A támadás két új elemet tartalmaz: egyik elemében egy választott üzenet módosításával fokozatosan halad a kívánt lenyomat felé, másrészt véletlen gráfokkal operál. Vajon hány implementációban spórolták meg a 45. utáni köröket?

Az idő úgy tűnik, hogy az üzenetpecsét algoritmusok ellen dolgozik, és az ilyen jellegű eredmények sok fejtörést fognak okozni az új algoritmusok tervezésekor. Az SHA-3 2012-re várható.

Christian Rechsberger cikke alapján.

A ZDNet blog összeszedte a 16. Defcon-on bemutatott, nyilvánosan elérhető szoftverek  listáját. A felhozatal igen színes, a közösségi reverse engineeringtől kezdve az IDS-eken és letapogatókon át a TOR protokoll továbbfejlesztéséig sok féle újdonságot megismerhetünk.

További jó hír, hogy a bíroság feloldotta azt a három metróhackerre - Zack Andersonra, Russell Ryanre és Alessandro Chiesara - vonatkozó rendeletet, amely megtiltotta, hogy a diákok közzétegyék kutatási eredményeiket. Ez egyrészt egy pozitív irányba mutató előrelépés az ügyben, másrészt viszont a bostoni metrótársaság még mindig nem hagyott fel pereskedési szándékával, a letiltott anyagok pedig már egyébként is kikerültek a nyilvánosság elé.

Pedig, ahogy a SecurityFocus cikkéből is kiderül, az ilyen jellegű elhallgattatási próbálkozások általában többet ártanak, mint használnak a felháborodott cégnek. Az MBTA-nek szerencsétlen flótások jogi macerálása helyett talán jobb lenne a biztonsági infrastruktúrájukat újragondolni...

Mivel egy közepes méretű falu szavazataival torony magasan győzött a "Még Hacktivity előtt" opció, kitettem oldalra egy új szavazást, melyben az időpontról mondhatjátok el a véleményeteket. Túl sok opciónk nincsen, szavazni hétfőig tudtok. Az helyszín valószínűleg nem fog változni. A szavazógép biztosításához nincs sok kedvem, úgyhogy józan (muhaha...) belátást feltételezve kérem az illetékeseket, hogy ezalkalomból szkriptjeiket küldjék el nyaralni, köszönöm :)

Meghírdetésre kerültek az idei Hacktivity játékai. A legnagyobb újdonság az előző évekhez képest a külföldi eseményekről már ismerős Capture the Flag, melynek keretében a versenyzők egy-egy nyilvánvalóan hibás szoftvermodul helyett komplett rendszerekkel szemben vethetik be tudásukat, de előtérbe kerülnek a védekezési képességek is. A játékon 3 fős csapatok indulhatnak, a nevezéseket szeptember 15-ig kell leadni. A két wargame idén is előzetes regisztráció nélkül játszható.

Roger blogján jelent meg egy összefoglaló a nem rég itt is bemutatott támadássorozatról, melyben rosszindulatú támadók veszélyes oldalakra mutató linkeket helyeztek el bizonyos oldalak látogatóinak vágólapján. Mint kiderült, a kártékony kódot egyszerű flash hírdetések útján terjesztettek, tehát az azt hordozó oldalak nem lettek "feltörve". A közzétett PoC  szemlélteti, hogy a böngésző biztonsági beállításai ebben az esetben nem szabnak gátat a vágólaphoz történő hozzáférésnek, valamint hogy a támadás nagyjából operációs rendszer és böngésző független (eddig IE-s és Firefoxos tesztekről tudok Windowson, OS X-en, Linuxon).