Update: The english counterpart of this post by synapse can be found here.

Az utóbbi napokban több ismerős is belefutott a MySecureZone nevű, katonai szintű e-mail titkosítást ígérő IndieGoGo kampányba, ami nem érdemelne külön posztot, ha nem honfitársaink (akik 10 másodperc alatt törik az SSL-t) állnának a kezdeményezés mögött, és nem pislognék tátott szájjal 10 perce a kampány oldal előtt - hiába, ez a példa is alátámasztja, hogy sírva vigad a magyar...

Egy katonai szintű megoldás bemutatásánál eleve többre vágynék néhány marketinges bekezdésnél meg pár csilivili látványtervnél, de dolgozzunk abból, ami van:

• "we’ve worked hard to create the BEST PRIVACY POLICY in the world" - Egy nagyon körültekintően megfogalmazott betűhalom nyilvánvaló garanciákat nyújt.
• "Switzerland is famous for its privacy and personal data protection, so this is why we choose to host our servers there" - Svájcnak nincs titkosszolgálata, a külföldi hírszerzők nem kíváncsiak rájuk, a hackerek pedig amúgy is unalmasnak tartják az országot úgy ahogy van.
• "We’ve implemented open source solutions in creating MySecureZone because we want to achieve greater transparency and therefore greater security" - Juhé, nyílt forrás! Persze az átláthatóság jegyében semmit nem árulnak el a reménybeli befektetőknek a szolgáltatás lelkét biztosító módszerekről... vagy mégis?
• "Our encryption algorithm is second-to-none and will protect your..." - vá-vá-vá-vááárjunk csak!
  • "Our encryption algorithm"
  • "OUR ENCRYPTION ALGORITHM" - kész, erre tényleg nem tudok mit írni (szerencsére páran megtették helyettem) 

Ezek után döbbenetes, hogy már több mint 6000 dollár összegyűlt a kampányra (ezt a kiírók akkor is megkapják, ha nem jön össze a célul kitűzött 50 lepedő!), minden esetre a sokk kiheverése után érdemes tovább olvasni:

• "Your connection to our server will be totally secured" - A kapcsolat titkosított, remek, ezt a GMail is tudja. A szerveren tárolt adatokról egy szó sem esik.
• "We designed a unique encryption framework called MSEP" - Persze az egésznek már van egy 4 betűs neve (33%-kal jobb az AES-nél, a DES-nél vagy az RC4-nél) \o/
• "Our email system is web-based, so there’s no need for program installation" - Miért is ne? A web alapú kriptográfiai megvalósításokból még soha nem volt baj.
• "With our NO LOG policy, you use our system ANONYMOUSLY" - A "privacy expert" készítők a jelek szerint nincsenek tisztában az anonimitás fogalmával (sem)

És még nincs vége, van egy másik videó is - nettó 15mp (biztos drágán adja a tárat a TeCső...), de azért ki lehet kockázni pár érdekes részletet:

• Startupos zongorakísérettel júzerünk beír egy szuperbiztonságos, 6 karakteres jelszót, amivel az e-mailjét el fogja titkosítani.
• Megérkezik a "titkosított" üzenet, melynek tárgya nyíltan olvasható.
• Az anonimitás jegyében láthatjuk, hogy az üzenetet danny küldte.
• Végül a könnyű kezelhetőség érdekében a fogadó félnek döntenie kell, hogy megbízik-e a szerver SHA-256-ot használó TLS tanúsítványában, melyet az X CA hitelesített. Segítségnek a levéltörzsben szerepelnek a vonatkozó tanúsítvány fingerprintek hexa-kódolt értékei.
• Bónuszként két különböző "el szeretném olvasni" link is szerepel a levélben, ne kérdezzétek miért.
• A slusszpoén pedig, hogy ez a figyelmeztető üzenet titkosítás illetve digitális aláírás nélkül érkezik.

Kedves MySecureZone! Kérlek ne hozzatok szégyent a magyar IT-biztonsági szakmára!

A Microsoft egy első sorban közel-keleti ileltve dél-ázsiai célpontokra vadászó támadássorozatra figyelmeztet, melyben az Office 2003-2007 verzióit illetve a Lync kommunikációs szoftvert érintő, a rendszer TIFF feldolgozójának hibáját kihasználó 0-day exploitot vetettek be. 

A sérülékenység nem érinti az újabb Office változatokat illetve a Windows Vistánál illetve Server 2008-nál újabb operációsrendszer verziókat.

A végleges javítás megérkezéséig a gyártó a TIFF codec letiltását illetve az EMET használatát javasolja. Érdekesség, hogy a vadon megfigyelt exploit a megszokott, alkalmazás szkriptelésen alapulú heap-spray technikaák helyett ActiveX vezérlőt használ, ami egyúttal azt is jelenti, hogy az ezeket letiltó  Protected View megakadályozza a kódfuttatást.

Friss: Úgy tűnik, a sérülékenységet szélesebb körben is kihasználják: a FireEye illetve a Symantec jelentései szerint a sérülékenységet az Operation Hangover keretében illetve a Citadel trójai terjesztésére is felhasználják. Mindkét kampányban ActiveX-es heap sprayt alkalmaznak, de eltérő módokon, ezen kívül a ROP láncok és a shellkódok is mások. A következő frissítőkedden még nem várható javítás a problémára 

Rendezvényünket a “Hekkelésen túl is van alkalmazás-biztonság” sorozat második eseményének szánjuk. Ha az OWASP projektek szokásos hármas tagolásában gondolkodunk (break, build, defense), akkor ez a rendezvényünk újfent a builder-eket, a gyártás képviselőit szólítja meg. (Hosszabb leírást lásd lentebb a 'Publicitás' részben.)

Előadók és előadások

• Bősze Tibor (IBM) - "Gondolatébresztő a CI és a sérülékenység tesztelés összeházasításáról"
• Jeges Ernő (SEARCH-LAB) - "A9 - 'kiskapu' a Top 10-en; esettanulmányok Java-ban"
• Jeges Ernő (SEARCH-LAB) - "SQL injekció az állatorvosi lóba - live hacking fun"
• Golda Bence (Bit and Pixel) - "A rendszergazda visszavág"
• Varga-Perke Bálint (Silent Signal) - "A túlértékelt OWASP Top10"
• Kiss Róbert (Prezi) - "A JSONP használatának tanulságai"

Az előadások 20 percesek. Ha egy előadásban elhangzottak iránt érdeklődőknek 5 percen túl is vannak kérdéseik, akkor a 15 lépéssel arrébb lévő büfében lesz lehetőségük az előadóval tovább beszélni a témát.

• Hivatalos wikioldal
• Időpont: november 12. (kedd), 18:00-21:00 (előadások 19:00-tól)
• Helyszín: a Prezi.com meetup helyszíne (1065 Budapest, Nagymező utca 54-56.)
• A rendezvény nyílt és ingyenes, de a szervezők munkáját segíted, ha regisztrálsz.

Első sorban kódelemzések alkalmával előforduló tipikus probléma, hogy különböző kriptográfiai funkciók - legyen szó akár egyszer használatos jelszavakról, munkamenet-azonosítókról vagy ne adj' isten kulcsgenerálásról - ellátására a programozók nem kriptográfiailag biztonságos álvéletlen-generátort használnak. 

Állítólag Neumann apánk mondta, hogy aki algoritmikus módszerekkel kíván valódi véletlenszámot előállítani, az a bűn állapotában leledzik, ennek ellenére szép módszerek léteznek nagyon is véletlennek látszó, különböző megkívánt eloszlásokat produkáló álvéletlenek generálására (bár ha jól emlékszem az egyenletesből bármilyen más is előállítható, de javítsatok ki ha tévedek).

Ezekkel az egyszerű PRNG-nek (Pseudo-Random Number Generator) nevezett állatokkal azonban biztonsági szempontból sok probléma felmerülhet, tipikusan pl. nem szeretjük, ha a generátor néhány ismert értéke alapján megjósolhatók a jövőbeni értékek - ez nyilván elég komoly problémákat okoz minden fent felsorolt példa alkalmazásnál.

Ennek kiküszöbölésére a kriptográfiailag biztonságos álvéletlen-generátorok (Cryptographically Secure PRNG) igyekeznek a futtatókörnyezetük nehezen megjósolható paramétereit (pl. hálózati stack vagy process fa állapota) belekeverni a kimenetbe illetve belső állapotukba, ilyen módon a támadónak túl sok bizonytalansági tényezővel kell számolnia a generátor belső állapotára történő következtetéshez.

És bár a nem megfelelő PRNG használatából következő kockázatok magátólértetődőnek tűnhetnek, a gyakorlatban általában igen nehéz a problémát egy laikus (döntéshozó) számára demonstrálni, az utóbbi hónapokban azonban született néhány remek kutatás a helyzet javítására:

Először is a Cylance BlackHate-es előadása jó alapozót ad a PRNG-k iránt érdeklődőknek, az emellé kiadott Prangster nevű eszköz pedig hasznos segítséget nyújthat az eddig elméleti síkon létező támadási vektorok gyakrolatba történő átültetésére, legyen szó javás, natív windowsos, BSD-s környezetről vagy a V8 motoron futó alkalmazásokról. 

Másodszor ma az Openwall csapata megmutatta, hogy a PHP Mersenne-twisteren alapuló (nem CSPRNG) mt_rand() függvényének kiinduló (seed) értéke pofátlanul kevés kimeneti érték alapján könnyedén megjósolható, így a szép számban (és helyeken ;) futó PHP-s alkalmazások sem érezhetik magukat túlzott biztonságban.

Nézzétek át a kódjaitokat és használjatok rendes CSPRNG-t, ahol szükséges - segítséget általában kedvenc programnyelvetek dokumentációja nyújt, de kommentben is ér okosakat kérdezni!

Az inspirációért köszönet @tomzorz_-nak!

Bónuszként - a kriptóhoz kapcsolódóan - tudom ajánlani a mai XKCD-t:

Részletek itt.

HC olvasóimtól előre is elnézést kérek, de szükségét láttam egy újságíró-kompatibilis poszt összedobásának, mielőtt a legújabb Snowden-folyást szétkenik a magyar sajtóban. 

Mint kiderült, az NSA már egy ideje rácuppant minimum a Google és a Yahoo! adatközpontjait összekötő, sokszor titkosítatlan optikákra [az MTI hírrel ellentétben nem a két cég közötti kommunikáció, hanem a cégek saját infrastrukturáin belül zajló kommunikáció figyelése a cél, ahogy az a kiszivárgott skiccről is leolvasható], és onnan a titkosítástól háborítatlanul szipkáznak ki minden adatot. Ez érthető okokból az érintett cégeknek nagyon nem tetszik - sokak szerint a helyzet analóg az Aurora Projekttel, csak az Új Világból nem olyan egyszerű kivonulni - de mi a helyzet a végfelhasználók szemszögéből?

Végtelenül leegyszerűsítve a dolgokat, így néz ki egy "felhős" szolgáltatás minden fajta védelem nélkül:

A Nagy Testvér megnézheti az adataimat az én gépemen, lehallgathatja út közben, vagy oda mehet a felhő szolgáltatóhoz, és elkérheti tőle.

Ha okosan TLS-re váltunk, a kommunikációnkat megvédhetjük, de az adaink felhőben történő kezeléséről továbbra sem rendelkezünk:

Ezt a képet úgy tudjuk zöldíteni, hogy még mi magunk titkosítjuk az adatainkat, mielőtt kilőjük őket Bárhová. Ilyenkor még egy nagyon együttműködő szolgáltató sem tud sokat segíteni a Tesónak, mivel a nyílt adat soha nem érintette az ő hálózatát:

És kb. ennyi: mivel a nyílt adatokat valahol létre kell hozni, a saját területünk megfigyelésével (bepoloskázásával) a Nagy Testvér még mindig beleláthat a mocskos kis ügyeinkbe.

Hogy mi változott a mostani leak fényében? Az ég világon semmi: a felhőt definició szerint (kis túlzással) azért hívjuk így, mert nem tudjuk, és nem is érdekel minket, mi történik benne az adatokkal - ez a probléma és a  rá adott megoldások évek óta változatlanok.

Aki nem homokba dugott fejjel vészelte át az elmúlt néhány napot, az biztosan értesült róla, hogy a Google feketelistázta a PHP.net-et, a figyelmeztetésről pedig hamar kiderült, hogy nem hamis pozitív: jelenleg annyit lehet tudni, hogy a támadók komprommitálták a www.php.net, static.php.net és git.php.net kiszolgálókat, valamint a projekt bugtrackerét, de az üzemeltetők egyelőre nem tudták megmondani, hogy milyen módon kerülhetett sor minderre. 

Tekintettel arra, hogy a támadók hozzáférhettek a PHP Git tárolójához illetve a weboldalról letölthető kiadásokhoz is, a károk viszonyleg mérsékeltek: úgy tűnik a szoftverbe nem telepítettek hátsó kaput (bár az MD5 hash-ek ellenőrzése 2013-ben nem éppen bombabiztos megoldás [thx Áron]), "csak" malware-t hosztoltak a webkiszolgálón, illetve hozzáférhettek a php.net privát SSL kulcsához, így a tanúsítványt vissza kellett vonni. 

A malware-el kapcsolatban bitvadászoknak érdemes elkérniük a Barracuda által rögzített PCAP-t, a többieknek a releváns infó annyi, hogy néhány rosszindulatú JavaScript először megnézte, hogy a látogató futtat-e valamilyen sérülékeny böngésző plugint (Java, Adobe Reader, Flash, VLC, Silverlight), majd a megfelelő exploit segítségével teleszórta az áldozat gépét bankos trójaiakkal meg ransomware-el. Ha a célpont nem volt sérülékeny, a szkript a következő YouTube videót tartalmazó oldalt töltötte be:

(Egy másik jóféle elemzés az AlienVaultnál olvasható.)

A jelek szerint tehát egy "sima" malware kampánnyal van dolgunk, de nem jó belegondolni, hogy egy célzottabb támadó mekkora károkat lett volna képes okozni, ha nem teszi meg azt a szívességet, hogy beletolja a Zeust a Google robotok arcába. 

A kárfelmérés, és az infrastruktúra helyreállítása még tart, de amíg nem derül fény arra, hogy hogyan is sikerült a támadóknak átvennie az irányítást a PHP.net kiszolgálói felett, a magam részéről fenntartásokkal kezelem a domaint.

Mivel a következő frissítőkedd még messze van, az Apple-nél meg elég sok minden történt, úgy gondoltam írok egy gyors összefoglalót a nagy keynote apropóján.

Bár az Apple továbbra sem informálja túl a felhasználókat a biztonsági frissítések tartalmáról, próbáljuk meg sorba venni az érdekesebb Mavericks biztonsági újdonságokat:

• A socketfilterfw tűzfal alkalmazásblokkolója nem minden esetben működött a bejövő kapcsolatokra
• Az App Sandox a LaunchServices API hívásakor nem korlátozta az elindított szolgáltatás argumentumainak megadását, ezzel sandbox-kitörési lehetőséget adott.
• Engedélyezésre került a TLS 1.2 
• A CoreGraphics hibái miatt lezárt képrenyőn (a takaró ablak felett) is megjelenhettek a háttérben futó alkalmazások ablakai, illetve egy alkalmazás megfigyelhette a más alkalmazásoknak küldött billentyűzet-elütéseket a Secure  Event Input opció ellenében is 
• Szintén a CoreGraphics hibája a ludas egy PDF fájlok megjelenítésében keletkező, kódfuttatásra alkalmas sérülékenységért.
• Javításra került egy rakás helyi DoS illetve jogosultságkiterjesztésre alkalmas hiba.
• A libc véletlenszámai bizonyos esetekben megjósolhatók voltak.
• Az OS X mostantól nem támogatja az MD5-öt használó X.509 tanúsítványokat
• Backportolásra került egy rakás OSS patch (pl. curl, python, syslog, stb...)
• A hibernálásból felkeltett oprendszer bizonyos esetekben nem kért jelszót ébredéskor
• Végül, de nem utolsó sorban javításra került a Depth által bejelentett, autentikáció előtti, távoli kódfuttatást lehetővé tevő hiba a Screen Sharing Serverben :)

Az iOS 7.0.3-ban javították a passcode bypass bugokat, jailbreakereknek egyelőre nem ajánlott a frissítés.

Ezen kívül üdvözlendő újdonság, hogy az Adobe sandboxolta a Safari Flash lejátszóját, így a Mac-eket célzó támadók dolga egy nagyságrenddel nehezebb lesz a jövőben. 

A Hacktivity előadásom témája röviden összefoglalva a különböző antivírus termékekhez kapcsolódó állítások és a valóság ütköztetése volt - nem feltétlenül kellett ott lenni a MOM-ban ahhoz, hogy az ember kitalálja a konklúziót. Az előadás előtt és után is alkalmam volt beszélni néhány emberrel mind az offenzív, mind a defenzív oldalról, és elmondhatom, hogy a szakmán belül a tényeket illetően végül is nagy az egyetértés, a tények értelmezésekor viszont sokszor külön dimenziókban mozgunk.

Mivel amúgy is hiányolom a blogról a régről megszokott, konstruktív hozzászólásokat, az alábbiakban a Hacktivity előadásom followup-ját vegyítettem egy kis flamebait-tel, hátha kaput tudunk nyitni a Vendor Világba!

0. Aranypecsét, tízcsillag, 100%

Ahogy azt az előadásomban is említettem, a kártevőkkel vívott küzdelem szélmalomharc, erre hozhatunk utazó ügynökös, megállási problémás, és egyéb matematikai analógiákat, de a legjobb, ha elkezdünk malware elemzéssel foglalkozni, hogy belássuk: rendkívül nehéz megállapítani tetszőleges adatállomány célját vagy előrejelezni a viselkedését egy adott rendszerben. 

Ennek ellenére minden egyes antivírus termékhez jár egy plecsni, amivel X "független" "szakértő" tanúsítja, hogy az adott termék tökéletes védelmet nyújt az ismert kártevőkkel szemben, és manapság már az sem ritka, hogy az ismeretlen támadásokkal szemben is szinte 100%-os védelmet ígérnek. 

Ezen állítások abszurditásának belátásához elég becsomagolnunk tetszőleges őskövületet valamilyen egyedi packerrel (vagy még ennyire sincs szükség), vagy vetni egy pillantást a Matousec eredményeire (akik - mint utólag kiderült - pár évvel megelőztek az általam bemutatott kutatással...).

Amíg az ilyen félrevezető eredményeket produkáló tesztlaborok általános elismertségnek örvendenek, esély sincs arra, hogy érdemi változás történjen ezen a fronton. 

1. "Security"

Ma már nem "Antivirus"-okkal (meg "vírusölőkkel") dolgozunk, hanem minden féle "Internet Security", "Client Security", "Endpoint Security" és még ki tudja milyen csomagokkal, melyek nevükben és sales kommunikációjukban is teljeskörű védelmet ígérnek, miközben számtalan alkalommal megmutatták, hogy nem csak, hogy nem teljeskörű ez a védelem, de adott esetben éppen a tartományban korlátlan hatalommal felruházott biztonsági szoftver jelentheti a támadók legvonzóbb belépési pontját.

2. "Telepíted, működik"

Nincs pofám ezerháromszázharminchetedszerre is idézni ezt az esszét, de felhívnám a figyelmet, hogy a biztonságot nem csak makro, de mikro szinten sem szabad önjáró termékként kezelni. Az elmúlt hónapokban kezem közé akadt több tucat termék jelentős részben ugyanakkor nagyjából akkora mozgásteret adott az adminisztrátornak, mint egy egybillentyűs írógép - nehogy szegény júzer összezavarodjon. Ez egy otthoni felhasználásra szánt terméknél még csak-csak elfogadható lehet (bár a gondolkodásról lenevelést soha sem tartottam jó stratégiának), de vállalati kategóriában ez a megközelítés szerény véleményem szerint elfogadhatatlan.

3. "Nekünk arra kell koncentrálni, hogy a kártevő be se jusson a rendszerbe, ha bent van, már úgyis mindegy"

A fenti érvet, amit egy vodkagőzös estén szegezett nekem egy vírusipari munkás, mint a termékpolicyjük sarokkövét sokszor szoktam emlegetni a szemellenzős gondolkodás ékes példájaként. Az elmút évek számtalan példát hoztak arra, hogy mindig lesznek olyan fenyegetések, melyekre nem vagyunk felkészülve, és amelyek a legnagyobb igyekezet mellett is át fognak hatolni az elsődleges védelmi vonalainkon. Ha nem cselekszünk proaktívan, csak a szerencsén fog múlni, hogy átvészeljük-e a következő támadási hullámot. 

4. "Az AV még mindig jobb mint a semmi"

Ezzel az állítással nagyon nehéz vitatkozni, és általában ez a konklúzió szokott a nyugvó pontja lenni az éjszakába nyúló vitáknak is. Valójában azonban ez a kijelentés éppen hogy a probléma lényegéről tereli el a figyelmet: 

A piacon lévő megoldásokat kritizálóknak általában nem az a baja, hogy a rendelkezésre álló termékek nem nyújtanak tökéletes védelmet, hiszen tudjuk, hogy ilyen védelem nem létezik, és jelen állás szerint nem is létezhet. A kritikusok problémája az, hogy úgy tűnik, az AV ipar meg sem próbál tenni azért, hogy ez a helyzet változzon. Ahogy többen megfogalmazták: amíg el lehet adni a havi szignatúra feliratkozást, mi a francért kéne többet költeni az alapvető újításokra? 

A lehallgatási botrány árnyékában kisebb pánikot okozott, mikor kiderült, hogy az Android fejlesztőknek szánt API-ja a 2.3-as verziótól kezdve a hírhetden gyenge RC4-MD5 algoritmus-kombinációt részesíti előnyben SSL kapcsolatok kiépítésekor. Ez azt jelenti, hogy az API-t naívan használó fejlesztő alkalmazásai már halandó emberek számára is hozzáférhető támadásoknak teszik ki felhasználóikat, amennyiben a támadó aktívan hallgatózhat a hálózaton, ami mobil készülékek esetén egyáltalán nem irreális. 

Az op-co.de bloggerei utánajártak a dolognak, és némi commit log túrás után kiderítették, hogy a Google lelkes kóderei a referenciának tekintett Java 6 SDK által meghatározott algoritmus preferenciákat igyekeztek átültetni az Android platformra, ez pedig tényleg a fenti cipher suite-t preferálja.

Az mindenkinek a saját belátására bízom, hogy mindez egy ügyes NSA akció, vagy egy megszokott programozói baklövés volt-e. 

És mielőtt az Apple fanatikusok lelkes naugyéban törnének ki, megosztanám azt is, hogy a HackInTheBox héten Malajziában rendezett kiadásán pod2g és gg megmutatta, hogy hogyan hallgathatja le egy kellően erős titkosszolgálat az állítólag Snowden által is előszeretettel használt iMessage üzeneteket. A prezentációból kiderül, hogy bár a szoftver valóban naprakész algoritmusokkal megvalósított end-to-end kriptográfiát használ, a certificate pinning hiánya miatt egy hamisított tanúsítvány birtokában, vagy pl. Mobile Configuration-ön keresztül a célpont telefonjára telepített plusz CA gyökérrel a forgalom lehallgatható lehet, a gyártó állításaival ellentétben akár az Apple (vagy az őt presszionáló ügynökség) által is. Az előadók egyúttal kiadtak egy Cyda alkalmazást is, ami figyelmeztet a MitM támadásokra és nagyobb kontrollt enged a készülék tanúsítvány tárolójához. 

A HITB-n egyébként rengeteg érdekes témát prezentáltak, a témánkba vág például még az iCloud és más mobil-felhő protokollok visszafejtését bemutató diasor, de a konferencia oldaláról bárki kedvére csemegézhet.

A Google a nem várt sikert arató Vulnerability Reward Program mellett új kísérletbe kezd a sérülékenység-felderítés frontján. A cég most saját fejlesztésű szoftverei mellett a széles körben alkalmazott nyílt-forrású kódokat is szeretné megerősíttetni, ehhez pedig a már jól bevált ösztönzőt, a pénzt alkalmazza. 

Az új programban bárki 500-3133,7 dollár közötti javadalmazásban részesülhet, aki sikeresen betol valamilyen proaktív biztonsági megoldást az olyan alapkomponensek valamelyikébe, mint például az OpenSSH, a BIND, a zlib vagy éppen a Linux kernel. Fontos kiemelni, hogy a Google olyan fejlesztéseket vár, melyek az érintett szoftver általános biztonsági szintjére is pozitív hatással vannak, valamint a hivatalos karbantartó is beemeli egy kiadásba az újítást. Ennek fényében tehát egy egyszerű hibajavítás, vagy a végfelhasználók számára általában bevezethetetlen hardening nem játszik, a komplett hibaosztályokra koncentráló, mondjuk egy-egy veszélyes API használatát elimináló vagy sandboxingot megvalósító törekvés viszont jó eséllyel pályázhat a támogatásra.

Emellett elindult az első hazai céghez kötődő, éles szolgáltatásra fókuszáló hibavadász program is, méghozzá a Prezi jóvoltából. A kotta itt nagyon hasonló a már jól működő külföldi programokéhoz: alapjáraton 500 dollárban részesül minden olyan hacker, aki kihasználható hibát - pl. SQLi, autentikáció megkerülés vagy akár XSS - fedez fel a Prezi infrastruktúrájában, és a problémát a privát csatornán a szolgáltató tudomására hozza. A programba itt lehet belépni, olvassátok el a feltételeket, és ne felejtsetek el regisztráció után az "I want to hack"-re kattintani!

Október második felében ismét megrendezésre kerül az immár hagyományos CrySyS Sec Challenge hacker verseny, melyet műegyetemistáknak szervez a BME Hálózati Rendszerek és Szolgáltatások Tanszékén működő CrySyS Adat- és Rendszerbiztonság Laboratórium (CrySyS Lab).

Az oldalhoz tartozó blogon adunk majd hírt a verseny indulásának pontos dátumáról és minden más fontos információról. Hogy biztos ne maradj le egy hírről sem, érdemes minden nap felkeresni az oldalt, vagy RSS olvasóval követni a blogposztok megjelenését (RSS feed).

Kezdésként a verseny előtti két hétben egy bevezető cikksorozatot teszünk közzé, aminek a célja a versenyfeladatok fő témaköreinek rövid bemutatása. A blogposztok végigolvasása és a kapcsolódó témakör önálló feldolgozás ugyan nem jelent garanciát a versenyen elért jó helyezésre, mindenképpen előnyben lesz az, aki ezekből a témakörökből előre felkészül.

Sok sikert a felkészüléshez és a versenyhez!

Az élménybeszámolókat pedig az e-mail fiókomba küldhetitek ;)

Microsoft

MS13-080: A frissítés orvosolja a nem rég aktív támadásokban felfedezett Internet Explorer 0-day-t (Metasploit modul és leírás itt), valamint egy feltehetően szeptember közepe óta aktív, szintén célzott, japán és koreai felhasználókra lövő támadások során használt use-after-free problémát is. A csomagban ezen kívül még 8 sérülékenységet javítanak. 

Kapcsolódó hír, hogy a Microsoft a BlueHat Prize pályázat keretében 100.000 dollárt ítélt oda James Forshaw-nak egy, az IE11 bétáját érintő tervezési problma felfedezéséért, bejelentéséért, valamint a javításban történő aktív közreműködésért. Emellett a cég kisebb részletekben további 28.000 dollárt osztott ki különböző kutatók között a Windows és az IE megerősítésére tett erőfeszítéseikért. Sajnos a feltárt hibák részletei egyelőre nem nyilvánosak, minden esetre jó látni a MS elköteleződését a független biztonsági kutatók megfizetésére.

MS13-081: Ez a javítócsoag összesen hét darab, a Windows OpenType illetve TrueType betűkészletek kezelésében vétett hibát orvosol, melyek kihasználása rendszer szintű kódfuttatáshoz vezethet megbízhatatlan tartalmak betöltésekor.

MS13-082: Ez a csomag a .NET keretrendszerhez jár, és pár DoS-t okozó probléma megszűntetése mellett megakadályozza, hogy ugyancsak OpenType betűkészletek segítségével egy támadó tetszőleges kódfuttatáshoz jusson XBAP alkalmazásokon keresztül.

MS13-083: A COMCTL32 hibája lehetővé teszi, hogy egy hitelesítetlen támadó egy speciális kérés elküldésével tetszőleges kódfuttatást nyerjen ASP.NET webalkalmazásokat futtató kiszolgálókon. Az integer túlcsordulás probléma csak 64-bites rendszereket érint, de ettől még ez egy elég fincsi sérülékenységnek tűnik!

MS13-084: Ez a javítás az Office szerver komponenseihez érkezett. A javított sérülékenységek az alkalmazásokon belüli privilégiumemeléshez, illetve memóriakorrupciós hibákon keresztül tetszőleges kódfutattáshoz vezethetnek.

MS13-085: A Google fuzz farmjáról erre a hónapra két Office sérülékenység jutott, melyek speciális Excel dokumentumok feldolgozáskor eredményezhetnek kódfuttatást az áldozat felhasználója nevében.

MS13-086: Még mindig Office, de ezúttal a Word komponensben javítanak 2 memóriakorrupciós sérülékenységet.

MS13-087: Egy Silverlight információszivárgás javítása - egy másik sérülékenységgel kombinálva jól jöhet, egyébként nem érdemes nagyobb figyelmet.

Adobe

Az Adobe ebben a hónapban visszafogta magát (lehet, hogy mostanában inkább az incidenskezeléssel voltak elfoglalva), a Reader illetve az Acrobat egy, a JavaScript motor biztonsági kontrolljait érintő javítást kapott, ami megakadályozza JS-ben definiált erőforrások megnyílását PDF dokumentumokban.

Ezen kívül javításra került egy RoboHelp-et érintő memóriakorrupciós probléma, amelyre még csak rendes frissítő szoftvert sem adtak ki, hanem az üzemeltetőknek kézzel kell lecserélniük az alkalmazás egyik DLL-jét...

A most megjelent Flash frissítés nem tartalmaz biztonságot érintő újdonságokat.

Snowden legutóbbi szivárogtatása most egy nagyon érdekes témába ad betekintést, nevezetesen, hogy mit is képes kezdeni a világ egyik legnagyobb hatalmú titkosszolgálata a Tor hálózattal (érdemes fejben tartani, hogy hasonló dolgokra lehetnek képesek más nagyhatalmak is)? A válasz tulajdonképpen beleillik abba a tendenciába, ami az elmúlt hírekből is körvonalazódni látszott: Az NSA aktívan használja azokat a módszereket, amiket a nyilvánosság nagyrészt elméleti lehetőségként kezelt, valamint ezeknél egy kicsit tovább is megy, de komoly áttörésről itt sem beszélhetünk. 

A témában a legjobb összefoglalót talán Tom Ritter adja, én itt most csak a főbb megállapításokat emelném ki.

Az NSA képességeiről a legjobban talán az árulkodik, hogy a Tor kicselezésére legalkalmasabbnak látszó módszerek jórészt az emberi hibára épülnek. A nyilvánosságra került diasorokban szignifikáns szerepet tulajdonítanak annak, hogy a szolgáltatás minőségének rontásával egész egyszerűen eltereljék a felhasználókat a Tor használatától, és szintén beszédes, hogy az ügynökségen belül saját kódneve (EPICFAIL :) van annak az esetnek, amikor a felelőtlen felhasználó véletlenül deanonimizálja saját magát. 

A dokumentumok több olyan technikaibb támadást is említenek, melyekhez ugyan közvetlen felhasználói interakció nem szükséges, de a bevált megerősítő védelmek-  mint pl. az SSL tanúsítványok körültekintő ellenőrzése, vagy a NoScript - hatékony védelmet nyújthatnak egy tudatos felhasználónak. A sok helyen emlegetett Quantum rendszer is csak akkor működhet, ha az ember nem figyel oda kellőképpen a kommunikáció anonimitása mellett annak biztonságára (bizalmasságára, integritására) is. 

Mindezen túl természetesen ott vannak az általam is sokat emlegetett CNE, vagyis Computer Network Exploitation, ami a szoftversérülékenységeket kihasználó módszerek összefoglaló neve. Ahogy azt sejteni lehetett, az NSA naprakész exploit gyűjteménnyel rendelkezik, melyeket az ún. FOXACID motor segítségével juttatnak célba. Az exploitok érték szerinti rangsorolással rendelkeznek, és a FOXACID gondoskodik arról, hogy a nagyértékű támadások áldozatai csak nagy jelentőségű felhasználók legyenek. Itt is megjegyzendő, hogy ezek az exploitok jó eséllyel nem fognak elmenni JS/Flash/stb nélkül, illetve hogy egy, a Tor Project által osztogatottól eltérő, akár jól sandboxolt böngésző feltehetően sok fejtörést okozna a CNE csapatnak. Érdekesség, hogy a FOXACID szereverek interneten elérhetőek, így a megfelelő kérés paraméter birtokában elméletileg bárki kaphat egy kis ízelítőt az NSA exploit gyűjteményéből :) 

Végül (és talán utolsó sorban?) az NSA természetesen igen jó pozícióban van ahhoz, hogy szinte a Föld teljes telekommunikációját figyelve ügyes statisztikai módszerekkel próbálja deanonimizálni a célszemélyeket. A paranoid hajlamúak számára megnyugtató lehet, hogy úgy tűnik, az NSA a dokumentumok keletkezésekor nem kontrollálta a Tor csomópontok szignifikáns részét. Részben ennek is köszönhető, hogy a bemutatott támadási lehetőségek a diákon még erősen kísérleti jellegűként kerültek bemutatásra - ahogy Ritter szépen rávilágít: a Tor-t éppen az ilyen típusú támadókra készülve hozták létre.

Összefoglalva tehát a Tor köszöni, jól van, de a felhasználói gondatlanságon nehéz segíteni, és a Tor Projectnek is akad még tennivalója az általuk kiadott szoftverek megerősítése, és legfőképpen a frissítések propagálása terén. 

Reménykedtem abban, hogy a Silk Road mellett már nem lesz több sokk a héten, de tévedtem. Az MTI 90-es éveket idéző híre már ugyan a legtöbb hírportálra kiment, azért próbáljuk meg a kor igényeinek megfelelően összefolglalni a történteket:

• A támadók megszerezték 2.9 millió Adobe ügyfél rekordjait, köztük titkosított (ezt remélem úgy kell érteni, hogy hash-elt) jelszavait illetve titkosított kártyaadatait. Az Adobe az érintett fiókok tulajdonosait értesíti, jelszavukat automatikusan lecserélte. A cég ezen kívül együttműködik a pénzintézetekkel is annak érdekében, hogy az esetlegesen megfejtett kreditkártya adatokat ne lehessen illetéktelenül felhasználni. 
• Legalább 40 GB Adobe forráskód kötött ki egy internetes bűncsoport által használt szerveren - ennek a csomagnak a felfedezése vezetett az incidens feltárásához. A lenyúlt kódok között minimum ott van a Cold Fusion a Clod Fusion Builder és az Acrobat forrása is. Ezek közül a legkellemetlenebb feltehetően a ColdFusion kódjának kiszivárgása, melyben eddig is elég csúnya hibákat találtak, ezek kihasználását pedig általában nem gátolják az olyan hoszt-oldali megerősítő intézkedések, melyeket például az Acrobat élvezhet. 

Az incidens valószínűleg kapcsolatban van azzal a betöréssorozattal, mely során identitáslopásra szakosodott bűnözői csoportok sikereres támadássorozatot intéztek több nagy adatbróker szolgáltató, illetve egy, a internetes bűnycselekményekkel szembeni fellépésre felkészítő non-profit szervezet rendszere ellen. Utóbbi incidensthez feltehetően egy Adobe ColdFusion sérülékenység vezetett. 

Tegnap este bombaként robbant az arcomba a hír: elkapák a SilkRoad feltételezett üzemeltetőjét, akit a világ eddig csak Dread Pirate Robertsként ismert. Az FBI egy bizonyos Ross William Ulbricht-ot gyanít a név mögött, aki most rácsok mögött várja, hogy ítélkezzenek fölötte kábítószerkerekedelem, pénzmosás, és számos más bűntény ügyében. 

A laikusok számára az ügy legérdekesebb része minden bizonnyal az, hogy a SilkRoad egyáltalán ennyi ideig működhetett, a mostani hatósági akciót pedig sokan valószínűleg az n+1. drograzziának tekintik, azonban az értő szemlélő számára az ügy sokkal érdekesebb:

Mindenek előtt érdemes elolvasni a Forbes interjúját DPR-el. Ebben az akkor még teljes anonimitást élvező üzemeltető elmondja, hogy a SilkRoad elsősorban egy kísérlet, melynek célja demonstrálni, hogy milyen új társadalmi-gazdasági modellek jöhetnek létre a technológia segítségével. A mostani rajtaütés után mindenképpen el kell gondolkoznunk azon, hogy ezt a kísérletet hogyan értékeljük a történtek fényében.

Másrészt természetesen ott van a technológiai vetület: valójában mennyire biztos maga a technológia amire ez az újszerű rendszer épült, illetve mennyire lehetséges a technológiát úgy használni a gyakorlatban, hogy az általa nyújtott előnyöket ne erodáljuk?

Az FBI nyilvánosságra hozott dokumentumaiból kiderül, hogy Ulbricht (feltételezve, hogy valóban ő (egyedül) DRP) számos hibát elkövetett működése során: különböző fórumokon használt online személyiségeit több ízben összekötötte, beszennyezte, magáról az idő közben megtalált és lefoglalt SilkRoad szerverről is számos terhelő bizonyíték került elő, de talán a legarcpirítóbb, hogy a férfi saját címére rendelt hamis papírokat, melyeket a határőrség lefülelt (itt olvasható egy érdekes fejtegetés arről, hogy a hasonló "rutin vizsgálatok" általában az illegális információgyűjtés kozmetikázását szolgálják). 

Jó kérdés ugyanakkor, hogy ez a fiaskó illetve a bérgyilkosságokkal kapcsolatos információk (melyek remek eszközei lehetnek egy karaktergyilkosságnak is) napvilágra kerülése okai vagy követkeményei a SilkRoad bukásának? Az minden esetre nagyon valószínű, hogy Ulbricht letartóztatásához jelentős részben a hagyományos (bár a webes világra szabott) nyomozati módszerek vezettek. Ennek ellenére érdemes feljegyezni néhány apró érdekességet az utóbbi időkből:

• A Tor hálózat augusztus közepétől kiugró növekedést mutatott, a megnövekedett forgalom pedig túlnyomó részben rejtett szolgáltatásokra irányult. Amennyiben valaki a hálózat kellően nagy részét kontrollálja, jó eséllyel képes lehet az azon forgalmazó felek azonosítására. 
• A Tor hálózat jelentős része még mindig 1024 bites DH kulcsokkal működik, és egyre közkeletűbb az az álláspont, hogy az NSA már rendelkezik az ezek megtöréséhez szükséges kapacitással.
• Mai hír, hogy megtörték a BitcoinTalk fórumát, ahol Ulbricht is regisztrálva volt. A Tor a szolgáltatások sérülékenységeitől sajnos nem tud megvédeni. A SilkRoad kapcsán egyelőre nem tudunk sérülékenységről, de ez is egy lehetőség lehetett a hatóságok számára.

A Tor Projectnél minden esetre hangsúlyozzák, hogy a történtek nem utalnak eddig ismeretlen implementációt vagy tervezést érintő problémára a Torban. 

Akár hogy is, biztosak lehetünk benne, hogy a Silk Road konkurensei és egy sereg új versenyző ebben a pillanatban is bitet heggeszt valahol, hogy a régi uralkodó helyére új szereplő léphessen. 

Örömmel jelentem be a félév IT-biztonsági szakdolgotának nyertesét, Pintér Olivért, aki "Memóriavédelmi megoldások vizsgálata és megvalósítása FreeBSD-n" (blog.hu CDN) című szakdolgozatával felállította a mércét a következő évek ifjú hackerei számára.

A beérkezett munkák értékelésében Szappanos Gábor és Hunger voltak a segítségemre, akiknek ezúton is nagyon köszönöm a közreműködést! Hunger így írt - kicsit elfogultan :) - a dolgozatról:

Nem tudom milyen szakdolgozatok vannak még [...], de messze komolyabb munka van mögötte, mint amiket láttam az utóbbi 10 évben itthon.

Gábor visszafogottabban nyilatkozott, de az ő választása is egyértelmű volt:

A [dolgozat] kevesbe latvanyos, de alaposabb es fontosabb témat dolgoz fel, több önálló eredménnyel.

Az alábbiakban inspiráció gyanánt egy rövid interjút olvashattok Olivérrel, a mihamarabb megejtendő díjátadásról pedig még beszámolok! :)

+++

Mióta foglalkozol foglalkozol a FreeBSD kernellel? Foglalkoztál korábban más rendszerekkel is?

Sokáig linuxot használtam azok közül is a debian-t. Ebben az időszakban is a kernellel foglalkoztam leginkább és a 2.6.22.y-op kernel-patcheket csináltam, melyekben security patcheket backportoltam mainline linuxból. FreeBSD-vel első körbe 6.1-es időszak alatt talalkoztam talan 2006 környékén, de egy hónap után visszatértem debian-ra. Ez akkor valtozott amikor új hw miatt váltanom kellett másik rendszerre, és ekkor jött újra képbe a FreeBSD. Ez 2008 közepe fele volt, és ezzel egyidőben elkezdtem a FreeBSD kernel iránt is érdeklődni.

Bemutatnád néhány mondatban a szakdolgozatodat?

Első körben arra fókuszáltam, hogy felmérjem, hogy jelenleg milyen helyzetben van a FreeBSD security téren (borzalmas...) és amennyire az időm engegedte, annyira foglalkozni vele és jobbá tenni. Az időmbe az SMAP implementálása és egy alap szintű ASLR fért bele.

Mi volt a legkomolyabb kihívás a dolgozat elkészítése során?

SMAP esetén a hardware hiánya és a kezdeti szakaszban a Qemu-val való küzdelem, hogy tesztelni tudjam az SMAP-ot. A másik kihívás pedig, hogy kicsit későn kezdtem el vele foglalkozni és nem jutott elég idő a magamban eltervezett dolgok megvalósítására.

Mit csinálnál másképp?

Mindenképp korábban kezdeném el és még jobban beleásnám magam a FreeBSD VM-jébe.

Az új Haswell architektúrájú CPU-kból "kimaradt" az SMAP támogatás, amire munkád egy részében támaszkodtál. Van ötleted arra, hogy miért alakulhatott így a dolog, illetve van információd arról, hogy mikor lesz ez a technológia elérhető az egyszerű vásárlók számára?

Az SMAP egy haténkony védelmi eszköz lenne a védelem oldalán. A kernel exploitok jelentős hányadát képes lenne megfogni. Két dolog történhetett:

• az SMAP technológia nem készült el vagy hibásan készült el, és ez miatt az Intel jobbnak látta nem engedélyezni,
• vagy az összeesküvés leméleteket jobban kedvelő embereknek megfelelő tényező pedig az lehet, hogy szándékosan hagyták ki belőle, mert a technológia nagyban megnehezíteni a kernel exploitok készítését.

Hogy látod, be fognak kerülni a fejlesztéseid a hivatalos FreeBSD kiadás(ok)ba?

Az év vége fele megjelenő 10-STABLE / 10-RELEASE kiadásba már biztos nem, mivel az elmúlt hetekben volt a code freeze, későbbi kiadásokra látok lehetőséget arra, hogy az ASLR bekerüljön, SMAP-ra jelen esetben nem, mivel meg hw sincs hozza.

Meglátásod szerint hogyan érintik a mostanában napvilágot látott állami backdoor projektek a FreeBSD-t (figyelembe véve pl. a TrustedBSD-DARPA kapcsolatot)?

Ez egy érdekes kérdés. Ha van benne backdoor, akkor valószínűleg nem a szemmel "látható" és nyilvánvaló helyeken található, hanem valamerre a hálózati stack környékén. Másik oldalról a DARPA nem csak a TrustedBSD projectet támogatja, hanem más FreeBSD-s fejlesztéseket is. Ezek a fejlesztések többségében Robert Watson laborjának a vonzásköréből kerülnek ki.

Van kedvenc FreeBSD biztonsági hibád?

http://www.freebsd.org/security/advisories/FreeBSD-SA-12:04.sysret.asc

[Nálam itt volt szó erről]

Hogyan értékeled az egyetemi képzést úgy általában?

A képzés sok olyan témába belekap, amik egyszer hasznosak lehetnek valamikor, viszont olyan embereknek akik célirányosan szeretnének foglalkozni valamivel nem a legmegfelelőbb. Ha nekem kellene kitalálni, hogy milyen legyen a képzés akkor azt mondanam, hogy első félévtől kezdve az emberek csoportokban dolgoznának egy-egy jól definiált projekten és mentorok / tanárok segítségével saját maguknak kellene felkutatni és elsajátítani a projecthez szükséges tudást. Ebben az esetben mindenki nagyobb mérétkben tudna azzal foglalkozni ami érdekli, és egy adott területen versenyképesebb tudást szerezhet. Amikor kialakult már egy ilyen fix tudás utána pedig fokozatosan lehetne bevezetni az egyéb ismereteket is, pl ami a gazdasági élethez elengedhetettlen. A BME-n ezek egy része megvalósítható, köszönhetően a CrySyS labornak, akik lehetőséget biztosítanak az embereknek, hogy olyan dolgokkal foglalkozzanak, amit szeretnek és az ott levő emberek rendkívűl segítőkészek.

Mik a további terveid? Tanulsz tovább, mész az iparba, gyártod tovább a kernel patch-eket?

Jelenleg MSc-n vagyok a CrySyS labornál és egy IT-Sec cégnél vagyok részmunkaidőben fejlesztő. A FreeBSD kernel patch-ekkel amennyire időm engedi foglalkozok, egy idő múlva valószínűleg termék is fog belőle készülni.

Hányast kaptál a dolgozatra? :)

5-öst. :)

Bármi más, amiről szívesen megosztanád a gondolataidat az olvasókkal?

Aki érdeklődik a téma iránt az vágjon bele, mert sokat lehet egy-egy ilyen téma kidolgozása közben tanulni és hasznos tudást kap. Ha valami segítségre lenne szüksége akkor megtalál minket a CrySyS laborban vagy IRC-n sokunkat.

Köszönet Hungernek, PaX Team-nek és Boldinak az észrevételekért és a konzultációkért.

+++

A pályázatra egyébként összesen két munka érkezett, és elmondhatom, hogy a másik versenyző, Katus Gábor is olyan munkát adott be, ami megérdemli a szélesebb figyelmet: Gábor munkája a Zeus malware-t és az erre épülő botnetet mutatja be, a dolgozat itt érhető el. 

Ismét igazolást nyert a mondás, miszerint minden csoda három napig tart: nagyjából ennyi idő telt egy az #istouchidhackedyet ("megtörték-e már a touch id-t?") kiírása óta, a Chaos Computer Club biometrikai tagozata pedig már közzé is tett egy közleményt valamint egy videót az új iPhone ujlenyomatolvasójának átveréséről.

A közlemény szerint az új leolvasó egyszerűen jobb felbontással rendelkezik a korábbiaknál és már jól ismert technikákkal kijátszható. A CCC ismételten kiemeli, hogy nagyon rossz ötlet egy olyan azonosítási technológiára építkezni, melynek kulcsát az ember mindenhol otthagyja, és nem tudja megváltoztatni, a ujjlenyomat alapú biomertikus azonosítást semmilyen felhasználásra - ide értve az új típusú útleveleket is - nem ajánlják.

Bár a közzétett videó nem mutatja be a teljes folyamatot, a CCC-sek nem szoktak a levegőbe beszélni, a szöveges leírás alapján a módszer elvileg bárki számára reprodukálható - a kitűzött nyeremény tehát várhatóan jó helyre fog kerülni (a CCC-nek a teljes folyamatot bemutató felvételt kell készítenie a kiírás szerint, ennek elkészítése folyamatban van).

Ha ez nem lenne elég, egy palesztín srác egy olyan bugot talált, melynek kihasználásával a lezárt telefon segélyhívás funkcióján keresztül tetszőleges (akár nemzetközi vagy emeltdíjas) szám is tárcsázható. A "módszer" lényege, hogy ember, miután bepötyögte a hívni kívánt számot a segélyhívó képernyőn, mint az őrült elkezdi nyomogatni a hívás gombot. Bár a technika elég butának tűnik, a Forbes újságírója szerint reprodukálhatóan működik. 

Valahogy úgy érzem, hogy az okostelefonok megjelenésével a phreaking új jelentést kapott :)

Az utóbbi napok-hetek eseményeinek fényében kissé komikus, hogy a nemzetközi IT-sec szakma jelentős része azzal van elfoglalva, hogy hogyan lehet kikerülni az újonnan megjelent iOS 7 képernyőzárát és megnézni az ismerősök homevideóit:

Jócskán 15000 dollár fölötti összeget, egy rakat piát, egy mocskos szexkönyvet illetve (Steve Jobs tiszteletére) egy ív kiváló minőségű LSD-t is felajánlott a közösség annak, aki először veri át a Touch ID-t a telefonról vagy más hétköznapi használati tárgyról vett ujjlenyomat felhasználásával. 

Jose Rodriguez nagy bánatára a sima passcode-os zár átugrásáért nem jár ekkora nyeremény, pedig a többszörös lock-hacker - aki katonai sofőrként általában a főnökre várva szórakozik a telefonja szétnyúzásával - már demonstrált is egy pofonegyszerű trükköt:

A telefont megkaparintó támadónak nincs más dolga, mint elgörgetni a zárképernyőt a telefon "vezérlő közponjáig", ahol megnyitható az ébresztőóra. Ekkor a telefont beijesztjük azzal, hogy ki akarjuk kapcsolni, de végül a "Mégsem" opciót választjuk, miközben a Main gomb dupla megnyomásával előhozzuk a multitasking menüt, ahol kedvünkre nézelődhetünk a tulajdonos fényképei között, melyeket a közösségi médiába felküldve további betekintést nyerhetünk az illető magánéletébe. 

A Microsoft figyelmeztetést adott ki egy célzott támadások során kihasznált IE9 0-day exploittal kapcsolatban. A támadók az mshtml.dll egy usa-after-free hibáját használják ki tisztán JavaScript-ből, igénybe véve egy ASLR-t nem támogató Office DLL-t, melyet az alábbi egysorossal töltetnek be: 

try { location.href = 'ms-help://' } catch (e) { }

A gyártó FixIt-et adott ki a problémára, valamint javaslatokat tesz az EMET-tel történő védekezésre. Utóbbiakkal kapcsolatban érdemes megjegyezni, hogy a Heap Spray védelem alapértelmezetten nem figyel az heap spray által használt 0x12121212 cím környékére, ezért a teljes mélyreható védelem érdekében Registry matatásra van szükség.  

A posztot frissítem ha további infók látnak napvilágot

Pár napja kérdezte egy kedves ismerősöm, hogy mégis mennyire kell komolyan venni ezt az NSA-s telefonfeltörős parát, én pedig természetesen próbáltam csillapítani a kedélyeket, mondván, nem eszik olyan forrón a kását. Aztán nem sokkal később végre volt alkalmam megnézni a Security Research Labs SMS hackelős előadását, és sajnos be kell ismernem, hogy tévedtem. 

A fenti előadás egyrészt bemutatja egy, a THC által már 2011-ben körvonalazott kriptográfiai támadás gyakorlati megvalósítáhatóságát, másrészt szépen körbejárja, hogy kellő háttértudás hiányában milyen könnyű rossz megoldásokat gyártani viszonylag egyszerű kriptográfiai sérülékenységekre.

A probléma azonban nem ez: bár Karsten Nohl megjegyzése arról, hogy senki nem tudott választ adni arra, miért is került be a szabványba a DES a '90-es évek végén jól illeszkedik az NSA hátsókapu-projektjébe, a problémát maguk az OTA (Over-The-Air) szoftverfirssítések jelentik.

Ez a sokszor figyelmen kívül hagyott lehetőség lehetővé teszi, hogy speciális SMS-ek formájában a szolgáltató lényegében Java szoftvereket telepítsen az ügyfelek készülékeire. Az SMS-ről a felhasználó az esetek túlnyomó részében (Nohl kivételként említ néhány régi Nokiát) nem tájékoztatja a felhasználót, hanem - amennyiben az SMS a megfelelő szolgáltatói kulccsal hitelesített - azonnal telepíti azt. Innentől kezdve egy titkosszolgálat lehetőségei szélesek:

• A szolgálat egyszerűen elkérheti a hitelesítő kulcsot a szolgáltatóktól
• A szolgálat "alternatív utakon" megszerezheti a kulcsokat a nem baráti szolgáltatóktól. 

A SIM-hez tartozó kulcs birtokában a támadó lényegében távolról bepoloskázhatja a telefont (pl. felhív egy számot, amíg a zsebedben van a készülék), de a SIM->OS támadások nagyrészt még kutatásra szoluló területnek számítanak, legalábbis a civil nyilvánosság számára. 

Hogy néhány szót ejtsünk a Security Research Labs munkájáról is: a csapat rájött, hogy egyes SIM kártyák a helyes kulccsal aláírt/titkosított hibaüzenettel válaszolnak érvénytelen OTA SMS-ekre. Mivel a titkosítás sok esetben (akár kikényszeríthető módon) DES-el történik, egy ~50.000 dolláros GPU cluster, vagy egy néhány hónap alatt néhány ezer dollárból összeállított szivárványtábla birtokában egy támadó ismert-nyílt szövegen alapuló támadással megszerezheti a kulcsot. A kutatócsoport ezen kívül azt is feltárta, hogy a SIM kártya Java virtuális gépének sandboxa könnyen kijátszható. A poén az, hogy több szolgáltató éppen ezt a biztonsági problémát kihasználva frissíti a forgalomban lévő kártyákat frissebb kriptográfiai eljárások (3DES vagy AES)  használatára: mivel a szabvány eredetileg nem teszi lehetővé a biztonsági konfiguráció módosítását, ez csak egy biztonsági hiba kihasználásával lehetséges.

A legújabb hírek az NSA-el kapcsolatban sajnos még mindig nagyon kevés konkrétumot tartalmaznak (ideje lenne, hogy valaki végre tényleg kiszivárogtassa a kiszivárgott dokumentumokat...), de talán egy lépéssel közelebb visznek a megfejtéshez NSA és a TLS viszonyában.

A legutóbbi, a témát fejtegető posztból valahogy kimaradt egy nagyon is kézenfekvő forgatókönyv, mégpedig a most napvilágott látott közbeékelődéses támadásoké.

Az újságírók témában kevéssé jártasak kedvéért: Az SSL/TLS által nyújtott titkosítás nem sokat ér ha nem tudom kinek küldöm el az adataimat. A titkosítás a dróton közlekedő adatokat védi, melyeket a kommunikáló felek (mondjuk a Google és én) a drót két végén megfejtenek. Amennyiben egy támadó (az NSA) elhiteti velem, hogy ő a Google, akkor a hálózati titkosítás mit sem ér, mert a kriptográfiai hókuszpókusz végén a Google helyett támadóval egyezek meg a titkosításhoz használt kulcsban, így számára minden üzenetem megfejthető lesz. Ez ellen védenek a digitális tanúsítványok, melyek ellenőrzésével a felek meggyőződhetnek arról, hogy jó partnerrel egyeztetnek (jó) kulcsot. A tanúsítványokat biztosító infrastruktúra (nem a titkosítás!) azonban az elmúlt években többszök kudarcott vallott.

A most megjelent anyagok tanúsága szerint routereket tört fel, és rajtuk keresztülmenő forgalom egy részét saját kiszolgálóira irányította, ahol hamis digitális tanúsítványokat használva megszemélyesítette a célszolgáltatásokat, példul a Google-t is. A megfigyelések célja a hírek szerint egy brazil olajipari vállalat, a Pertobras titkainak kikémlelése lehetett.

A történetbe jól illeszkedik az a néhány hetes leak, melyből kiderül, hogy az NSA különös figyelmet fordít a hálózati eszközök - tűzfalak, routerek és switchek - biztonságára, a Wired cikke szerint az elmúlt években világszerte több tízezer ilyen csomópont felett vette át az irányítást a hivatal. A stratégia sok szempontból előnyös: az eszközök nagy részének biztonsági szintje riasztóan gyenge, a szoftvereket a legritkább esetben frissítik, natív biztonsági szoftverek gyakorlatilag nem léteznek, teljes hálózati tartományok figyelhetők meg, és a sort még valószínűleg sokáig lehetne folytatni.

6:23 ;)

Az persze jó kérdés, hogy hogyan jutott hozzá az ügynökség a megfelelő tanúsítványokhoz? Kormányhivatalról lévén szó, simán elképzelhető, hogy egyszerűen készíttettek egyet valamelyik baráti CA-val - ez tűnik talán a legköltséghatékonyabb megoldásnak. Az is elképzelhető ugyanakkor, hogy a CA-k infrastruktúráját azok tudta nélkül használták fel - erre utal, hogy az egyik kiszivárgott slide a DigiNotart emlegeti, bár nem vagyok róla meggyőződve, hogy nem csak példaként hozták fel a holland szolgáltató fiaskóját a prezentációban.

Aztán persze még mindig ott van a kriptó: tudjuk, hogy "bizonyos titkosszolgálatok" elég jól állnak az MD5-ütközés problémával, így egy, a Flame-hez hasonló trükkel SSL tanúsítványokat is hamisíthattak. Erre azonban szvsz. viszonylag csekély az esély: Először is, tisztességes CA nem használ MD5-öt, éppen a fenti okok miatt. Másodszor a Flame esetében is a csillagok speciális együttállására volt szükség, hogy a támadás megvalósítható legyen. Harmadszor pedig a tisztességes megfigyeléshez valószínűleg tucatnyi tanúsítványra lehetett szükség, melyeket mind egysével, a körülményekhez igazodva (szolgáltató algoritmusai, kulcshosszai, tanúsítványformátum, stb.) kellett volna értő műgonddal legyártani, ami egyszerűen szívás ahhoz képest, hogy a megfelelő ember orra alá dörgölöm a megfelelő papírt.

A jó hír, hogy az effajta támadásokat könnyen észlelhetjük: a Chromiumban elérhető, EMET-tel tetszőleges alkalmazásba "beoltható" certificate pinning biztosítja, hogy kedvenc szolgáltatóinkhoz csak akkor kapcsolódjunk, ha azok már ismert tanúsítványt villantanak, a Firefox Certificate Patrol kiegészítője pedig minden, a tanúsítványokat érintő változásról részletes tájékoztatást ad.

Bónusz: 3 éves Linux SCTP IPv6 IPsec biztonsági hiba: NSA kedveli ezt

Webes projektek során egyre gyakrabban fordul elő, hogy bár a tesztelt alkalmazás megvalósít valamiféle bemeneti szűrést, az adatbázis segít kikerülni számunkra ezeket a megkötéseket. 

SQL Smugglingról korábban már írtam (bár ideje lenne frissíteni azt a posztot...), mostanában a leggyakoribb példa az XSS-ek keresztülverése például az ASP.NET ValidateRequest filterén vagy reguláris kifejezéseken:

Bár a filter kivételt dob a legtöbb értelmes <-el kezdődő bemenetre, a %uff1c unicode karaktert a MSSQL szerver éppen erre az ASCII jelre alakítja, ha unicode tartalmat akarunk CHAR vagy VARCHAR  típusú mezőbe tölteni (NCHAR illetve NVARCHAR helyett), így a szűrés szépen megkerülhető. 

Nem olyan régen kisebb gondba kerültem, ugyanis egy gonosz karakter-feketelistába botlottam, ami egy csomó, JavaScriptben hasznos karaktert (pl. zárójeleket) nem engedett át, így szükségem lett volna egy megfeleltetési táblázatra a háttérben ülő MSSQL szerver Unicode->ASCII konverzióiról. Miután a kézi próbálatás nem vezetett eredményre, fellőttem egy SQL Server példányt az Azure-ban (tanulság: a Microsoft szoftverek telepítése még a felhőben is lassú), és írtam egy rövid T-SQL szkriptet, ami egy táblába töltötte az összes 2-byte-os karakter értékét egész számként, Unicode illetve ASCII karakterként. 

Az eredmény megtalálható a GitHub-on, a további adatbázis motorokkal illetve konfigurációkkal kapcsolatban várom a hozzájárulásokat!

A tanulság a fejlesztőknek és üzemeltetőknek egyrészt annyi, hogy készüljetek fel adatbázis szinten a spéci karakterek fogadására, másrészt próbáljatok a naív karakterszűrések helyett valami robosztusabb megoldásban (pl. DOM-alapú validáció) gondolkodni!

Microsoft

MS13-067: Ebben a csomagban a Microsoft több Office sérülékenységet orvosol. Egyrészt úgy tűnik, a Google-nél elkezdtek Word-t fuzzolni, amiből kiesett öt sérülékenység, a bulletin fő attrakciója azonban a SharePoint, amiben több XSS mellett távoli kódfuttatásra alkalmas sérülékenységeket is javítottak. Ezek egyike speciális Office fájlok megnyitásakor eredményez rendszer szintű kódfuttatást, a másik pedig feltehetően a VIEWSTATE manipulációjával biztosít lehetőséget a W3WP rendszerfiók jogkörével történő parancsvégrehajtásra.

MS13-068: Egymásba ágyazott S/MIME formátumú levelek előnézetének megjelenítésekor az Outlook double-free szituációba keveredhet. A Microsot kritikus besorolással látta el a javítást, ennek ellenére az SRD blog hangsúlyozza, hogy a hiba sikeres kihasználása igen valószínűtlen - ennek ellenére pesze erősen ajánlott a folt telepítése.

Friss: @alech azt írja, hogy véletlenül sikerült kódfuttatást elérnie.

MS13-069: Az ehavi IE javítócsomag tíz hibát orvosol. A problémák nagy részét a HP ZDI programjának keretében jelentették be, ami ismét jól mutatja a hasonló bugvadász programok fontosságát. 

MS13-070: Tetszőleges, OLE objektumot tartalmazó fájlon keresztül triggerelhető hiba javítása az XP-2003 pároshoz. A probléma kihasználása az áldozatéval megegyező jogokat biztosít a támadónak.

MS13-071: Ez egy elég fura darab. Bizonyos Windows rendszereken (pl. XP-n, 2003-on, Vistán és 2008 SP2-n, de SP0-n és 7-esen nem) egy támadó kódot futtathat, amennyiben képes rávenni a felhasználót, hogy telepítsen egy spéci Windows téma fájlt. Ezek után a támadó felhasználó jogaira tesz szert, de ettől függetlenül akár új, teljes jogú fiókokat is létrehozhat. Ezt rakjátok össze!

MS13-072: Ez a javítás egyrészt az első folytatása, még egy rakás (szám szerint 12), a Google Security Team által felfedezett Office sérülékenységgel. A folt ezen kívül javít egy szinte triviálisnak látszó információ szivárgás problémát: az office által kezelt XML dokumentumokba ágyazott külső entitásokon keresztül egy támadó fájlokat olvashat az áldozat rendszeréről - szinte látom magam előtt az ehhez szükséges kódot, csak azt tudnám, ez miért nem jutott eddig az eszembe?

Friss: Az XML sérülékenységeket a BlackHat-en demózták, az előadás anyagok itt elérhetők.

MS13-073: Még két Office memória korrupció javítása, illetve az előző XML external entity probléma átültetése más termékkomponensekre/verziókra.

MS13-074: Még három memória korrupció, ezúttal az Accessben (használja még valaki ezt az Isten-csapását?)

MS13-075: Egy kínai beviteli módokat támogató Office változatokat érintő memóriakorrupciós probléma javítása. Friss: Az utóbbi hetek információi alapján nem tűnik alaptalan feltételezésnek, hogy hátsó ajtóról lehet szó...

MS13-076: A Google-nél a Windows kernel drivereinek fuzzolásával sem álltak le, ez ebben a hónapban összesen hét hibajavítást eredményezett a win32k.sys-ben, a problémák privilégiumemeléshez vezethetnek.

MS13-077: Egy double-free hiba a Windows 7-2008 Service Control Managerében jogosultságkiterjesztést tesz lehetővé.

MS13-078: Információszivárgás a FrontPage-ben, ennél több szót azt hiszem ez a darab nem érdemel.

Adobe

Az Adobe frissítette a Flash és Shackwave lejátszókat, valamint a Reader és Acrobat termékeket is, összesen 14 sérülékenységet javítva. A lejátszók foltjainak telepítését a gyártó a lehető leghamarabb javasolja, a PDF kezelő termékeknél - feltehetően az érintett verziókban megtalálható megerősítő védelmeknek köszönhetően - a foltozás közepes prioritású.

Az IE10 és a Chrome Flash lejátszói természetesen maguktól frissülnek. A lejátszó Windows 8-on elérhető biztonsági megoldásairól itt olvasható egy érdekes bejegyzés.

A WebSense friss felmérése szerint egyébként a felhasználók 40 százalékánál elavult Flash fut.

Cisco

A Cisco elsősorban DoS illetve alacsonyabb kockázatú információszivárgást okozó hibákat javított, az ASA, UCS és WLC termékcsaládokban valamint az IOS rendszerben.

VMware

A VMware kliens szoftverei  ingyen root-ot adtak Debian-alapú rendszerekre, javítás erre. ESX és ESXi hypervisor DoS javítások meg erre. 

Oracle (Friss)

Kijött a Java 7u40, ami kifejezett biztonsági foltokat nem kapott, de néhány biztonsági funkció fejlesztésre került 

Apple (új iPhone!!4!)

Itt csak gyorsan annyit jegyeznék meg, hogy az ujjlenyomat-olvasótól az iPhone nem lesz biztonságosabb: ha a szoftver sérülékenységektől (lásd még: jailbreak) most eltekintünk, elmondhatjuk, hogy az ujjlenyomat alapú azonosítással gyakorlatilag mindenhová kiírod a jelszavad, amit nem tudsz (fájdalommentesen) megváltoztatni, a leolvasók pontosságába pedig ne is menjünk bele. A témában Schneier bácsi Wired-en megjelent cikkét tudom ajánlani, a kedvenc idézetem:

"A legjobb [biometrikus azonosítási] rendszert egy magas biztonsági szintű kormányhivatalban láttam. Lehet, hogy át lehetett volna verni egy hamis ujjal, de a mellette álló tengerészgyalogos egy nagy fegyverrel az oldalán gondoskodott róla, hogy ezt ne próbáld meg."

+++

• Egyéb iránt tudta-e Ön, hogy az OS X-ben fél éve nem képesek kijavítani a sudo egy ismert, jogosultságkiterjesztésre alkalmat adó sérülékenységét?
• ... és hogy a Dropboxszal sutba dobhatjuk az ASLR-t?
• Érdekes egybeesés, hogy az első dokumentált, szó szerinti bugot hatvanöt évvel ezelőtt (majdnem?) pontosan ezen a napon fedezték fel.

Szép álmokat! / Jó reggelt!

Az NSA-féle lehallgatási botrány még mindig pörög, a média (nagyon helyesen) nem hajlandó ejteni a témát, és Snowden anyagai még bőven tartogatnak izgalmakat az egyszeri nethasználó számára. A kiszivárgott dokumentumok azonban koránt sem tartalmaznak minden részletet az NSA vagy más titkosszolgálat működésével kapcsolatban, így a híradásokban sok a spekuláció és gyakori a tények hatásvadász félreértelmezése is (ami helytelen). Mivel én sem látok bele jobban egy amerikai titkosszolgálat működésébe, mint bárki más, aki eddig beleolvasott a Snowdentől származó anyagoka, eddig nem is nagyon erőltettem a témába történő belefolyást, de az utóbbi időben annyian annyifélét írtak a témában itthon és külföldön, hogy úgy gondolom, most már ideje néhány dolgot (ismételten) helyretenni.

(via)

Először is, hihetetlen naivitás kellett ahhoz, hogy valaki azt gondolja, hogy az USA titkosszolgálatai nem tudnak belenézni a helyi cégeknél tárolt adatainkba. Erre a mi törvényeink is felhatalmazzák a mi titkosszolgáinkat, a különbség "mindössze" annyi, hogy mi nem vagyunk szuperhatalom és nem megy keresztül rajtunk a világ netforgalmának jelentős része. A PRISM nem azért okozott akkora botrányt, mert az NSA a dolgát végezte, hanem azért, mert a szervezet a képességeit amerikai állampolgárokkal szemben is alkalmazta, erre pedig nem volt alkotmányos felhatalmazása (majd megpróbálták letagadni az egészet), amire arrafelé elég háklisak az emberek.

Ettől persze szabadságharcos szempontból nagyon is pozitívan értékelhető, hogy ma már az átlagfelhasználó agyán is átfut, hogy kinek adja a titkait.

Az emberek persze megpróbálnak megoldást találni a problémára, a megoldás pedig kézenfekvő: használjunk kriptográfiát! Aztán jön a nyakleves: az NSA évente nagyjából 100 milliárd (!) forintnak megfelelő összeget költ alapkutatásra, le képesek hallgatni minden titkosított internetes forgalmat, és bele tudnak hallgatni bármilyen telefonbeszélgetésbe - azt gondolhatnánk, hogy itt vége a játéknak.

Ez azonban még mindig nem jelenti azt, hogy "feltörték az SSL-t", hatékonyan faktorizálnak egész számokat, vagy polinom időben oldják (bármelyik) diszkrét-logaritmus problémát. Az ugyan gyakorlatilag biztos, hogy az amerikai (illetve más nagyhatalmakhoz tartozó) hírszerzők hatalmas számítási kapacitással rendelkeznek, és azt is tényként kezelhetjük, hogy előrébb járnak a matekban, mint amiről a nyilvánosság tudhat (az NSA-nek minden nyilvános kutatás rendelkezésére áll, ők viszont nem osztanak meg semmit), de ez mégsem jelenti a meglévő algoritmusaink bukását:

A titkosítási algoritmusokkal szembeni támadások hatékonyságát a tisztán nyers erőt alkalmazó, a teljes lehetséges kulcstér bejárására játszó naív támadáshoz mérjük. A modern kriptográfia történetében ugyan gyönyörű eredmények születtek, melyek akár sok nagyságrenddel rontottak egy-egy titkosítás jóságán, de a mai algoritmusok és kulcshosszak mellett még a legjobb kriptanalízis módszereknél is milliárdszor jobbak kellenének, hogy a világ legjobb szuperszámítógépei elboldoguljanak velük - és akkor még nem beszéltünk az ezekhez tartozó támadói modellekről, melyek sokszor elképzelhetetlen mennyiségű összefüggő kriptoszöveget, vagy nagy mértékben ismert nyílt szövegeket feltételezhetnek. Ha pedig mindez mégis megvalósíthatónak látszana, akkor növelhetünk a kulcshosszakon (az NSA feltehetően képes 1024 bites számok faktorizálására, a Google a nyáron áll át 2048 bites tanúsítványokra).

Gond akkor van, ha a tengeren túlon (vagy akár valahol Ázsiában) sikerült valamilyen forradalmi matematikai áttörést elérni, vagy építettek egy kellően nagy kvantumszámítógépet, de még így is csak a rendelkezésre álló algoritmusok egy részét lennének képesek legyűrni, méghozzá igen drágán.

A kriptográfia valószínűleg még mindig a legerősebb láncszem a biztonsági gépezetben. Ez azonban azt is jelenti, hogy vannak nála gyengébbek, a kegyetlen közgazdaságtan pedig minden bizonnyal itt is érvényesül:

Míg Dr. Günter Janekhez hasonló kvalitásokból nem sok szaladgál az utcán, egy fuzzing farm egészen jól skálázható, de még tehetséges biztonsági szakértőkből is elég jó az ellátmány, ha odafigyelünk a képzésre és nevelésre. Ha pedig az embernek van évi 250 millió dollár a zsebében, könnyen rávehet bizonyos egyéneket illetve cégeket, hogy az algoritmusaikat a Terror Ellenes Harcnak megfelelően alakítsák.

Szoftver sérülékenységekre vonatkozó információk birtokában nincs szükség korszakalkotó elméletekre, a TLS forgalmad már azelőtt kiszivárgott a munkaállomásodról, hogy titkosításra került volna. Nem fognak a telefonodra varázssugarakat küldeni a HAARP-ról, elég egy trójai, ami figyel, mikor használod a laptopod USB-jét töltésre, vagy néhány spéci SMS (Szerk: friss poszt itt) a rosszul implementált kriptográfia kijátszásához. Ha pedig valaki megtalálná az egyik hátsó kapudat, hivatkozhatsz egyszerű fejlesztői hibára, a patch után használsz egy másik bejáratot. (Persze, ha a célpont odafigyel ilyen apróságokra egyáltalán: a Tor hálózat jelentős részén még mindig olyan elavult szoftverváltozatok futnak, melyek 1024 bites DHE kulcsokat használnak, melyeket a hárombetűs feltehetően meg képes fejteni)

Összefoglalásként tehát a jó hír az, hogy egyrészt egyelőre jó eséllyel nem kell kidobni a TLS-t, az RSA-t, az AES-t meg a többi kedvencünket (a kulcshosszakra viszont érdemes odafigyelni), továbbá szintén jó észben tartani, hogy egyik fenti módszer sem működik globális méretekben, a hírszerzésnek célzottan kell dolgoznia, ha kriptó jön szembe.

A rossz hír az, hogy a szoftver infrastruktúránk ugyanolyan sérülékeny mint eddig is volt, minden, az eszközeinkre kerülő kódot pedig lehetetlen leellenőrizni (a Tor Project erőfeszítései a témában - thx stef!). A kérdés innentől az, hogy kiben hajlandó megbízni az ember: van, aki a nyílt-forrásban hisz, mások jobb híján maradnak a nagy gyártóknál, és sajnos olyanok is lesznek, akik bedőlnek a hisztéria hullámain feltörekvő kuruzslóknak. Ahogy azonban a poszt elején is írtam, a első és legfontosabb az, hogy az ember tudatában legyen a potenciális fenyegetésnek, és ennek tudatában válasszon a rendelkezésre álló lehetőségek közül. Mindehez persze nem ártana, ha nem a média által gyártott démonokkal állnánk le küzdeni az orrunk előtt vicsorgó ragadozók helyett.

Idén ősszel is beindul a szokásos konferenciaszezon - én is épp prezentációheggesztés közben allokáltam egy kis időt ennek a posztnak a megírására - szépen lassan körvonalazódnak az IT biztonsági rendezvények programjai, időrendben haladva:

ITBN 2013

Szeptember 25-26-án kerül megrendezésre az egyik legnagyobb múltú hazai szakmai rendezvény, az ITBN, melyen hagyományosan felülnézetből tekinthetjük át az ipar elmúlt egy évének eseményeit, újdonságait. A témák között természetesen kiemelt figyelmet fog kapni a még mindig nem csillapodó Snowden-PRISM-NSA ügy (erről a napokban tőlem is várhattok posztot), de ismét szó lesz a magyar infromációbiztonsági törvényről, a SANS által legfrissebben definiált biztonsági kontrollokról és persze sok-sok biztonsági termékről, szolgáltatásról is. Jómagam  a sérülékenységvizsgálati ajánlatkérések tapasztalatairól fogok elmondani néhány, a megrendelői oldal számára hasznos gondolatot. A rendezvény szokásosan ingyenes, de regisztrációhoz kötött.

CampZer0

Közvetlenül az ITBN után, szeptember 27-29 között kerül megrendezésre a H.A.C.K. kísérleti rendezvénye, a CampZer0, amely bár nem kizárólag a biztonsági terület képviselőit célozza, az eddig elfogadott programpontok között azonban markánsan szerepel ez a terület, így az általánosabb értelemben hackelni vágyók mellett a kifejezetten security-fókuszó közönség számára is méltán vonzó programról van szó. A szervező csapat természetesen garantálja a bitillatot, regisztrálni itt lehet (az árak még alakulóban). 

Hacktivity 2013

Végül, de nem utolsó sorban végre megjelent (nagyrészt) az idei Hacktivity programja is. A két keynote speaker - Charlie Miller és Mikko Hypponen remek választás volt a szervezők részéről, már csak a velük való személyes eszmecsere lehetősége is jó ok lehet a részvételre. A program többi pontja mind a "szakmával" most ismerkedők számára, mind a keményvonalas bitbűvészek számára érdekesnek ígérkezik: az alapvető koncepciókat bemutató Hello Workshopok és a néhány esetben egészen a fizikai rétegig lenyúló kutatási eredmények bemutatói között azt hiszem, mindenki találni fog magának kedvére valót - én a hoszt-oldali biztonsági szoftverek viselkedés alapú detekciós képességeit fogom górcső alá venni. Regisztrálni holnapig még kedvezményesen lehet.