Egy élelmes script-kiddie 500$-ért árul hozzáférést különböző .gov és .mil (valamint ezek lineáris kombinációi) weboldalakhoz. Az oldalakról lebányászott személyes adatokhoz ezresével lehet hozzájutni mindössze 20$-ért.  

A történetben a legfájdalmasabb az, hogy az accountárus minden jel szerint sima automatizált szkriptekkel jutott hozzá az információkhoz. Krebs azt hiszem joggal teszi fel ezek után a kérdést, hogy vajon tényleg időszerű-e a kiberháborúra történő felkészülés, mikor egy sima weboldalt nem képesek az illetékes erők megfelelően biztosítani?

 Az Európai Bizottság január 26-ig leállította a szén-dioxid kvóták kereskedelmét "a nemzeti regisztrátoroknál elmúlt két hónapban bekövetkezett biztonsági incidensek miatt". A hírek szerint egy cseh forgalmazótól 38 millió dollárnyi szén-dioxid kreditet zsákmányoltak ismeretlenek. 

Az EB honlapján megjelentetett közlemények szerint már 2010 elejétől kezdve vizsgáltak "biztonsági réseket", az azóta meghozott intézkedéseket igyekeznek folyamatosan foganatosítani a tagországokban. Ennek ellenére novemberben a feltehetően kibocsátási-kreditekre hajtó Nimkey féreg adott okot aggodalomra, decemberben pedig Romániából érkezett hír egy incidensről. Legújabb bejegyzésében a szervezet arról ír, hogy tekintettel az elmúlt hetek eseményeire - tehát valószínűleg további "balesetek" is történtek - a kereskedelem nem folytatódhat, amíg az összes közvetítő meg nem valósítja az újonnan előírt biztonsági intézkedéseket.

Erre szokás mondani, hogy eső után köpönyeg, kíváncsi vagyok milyen biztonsági előírások vonatkozhattak eredetileg a közvetítőkre, és hogy hány eset maradt titokban, vagy felderítetlenül...

Friss:

Ausztria, Görögország, Lenyeglország és Észtország is érintett, a támadásokat valószínáleg belső emberek segítették. Europai tisztviselők szerint a tagországok felében elégtelenek voltak a biztonsági intézkedések, például nem követeltek meg két faktoros autentikációt a felhasználóktól (ezt általában egy elektronikus mobiltelefon-feltöltéskor is elvárják :P). A komprommitált kreditek azonosítóit visszavonják - legalábbis azokat, amelyekről ezt be tudják bizonyítani.

friss2:

Decemberben állítólag 7 milliárd(!) dollárral károsították meg Dániát a szén-dioxid krediteken keresztül. Ez az üvegház-téma kezd egyre jobb üzletnek tűnni!

Kicsit csönd van mostanában az IT-biztonság offenzív oldalán, a BlackHat DC-ről még nem írtek ide a hírek (leszámítva talán a Stuxnettel kapcsolatos állításokat, melyekre ennél több szót nem kellene vesztegetni), védelmi fronton viszont akad néhány újdonság.

A Microsoft biztonságos fejlesztésért dolgozó csoportja kiadta az Attack Surface Analyzer nevű szoftver béta változatát, melynek segítségével a telepített alkamazások hatását vizsgálhatjuk a Windows operációs rendszer támadási felületére. Hogy mit értünk támadási felület alatt, azt ez a tanulmány definiálja: A lista számba veszi többek között a nyitott portokat, RPC végpontokat, az operációs rendszer beállításait, ACL-eket illetve a különböző tartalomtípus-alkalmazás összerendeléseket. A program pillanatképeket készít a rendszer állapotáról, a szakértő pedig a pillanatképek különbségeinek áttekintésével értékelheti, hogy mekkora kockázatot jelent egy adott alkalmazás (adott módon történő) telepítése, illetve hogy egy incidens bekövetkeztéhez mely legitim komponensek járulhattak hozzá. Ezt az eszközt használják a Microsoft belső terméktesztjeihez is, kár, hogy Windows 7-nél korábbi rendszerekre nem települ :(

Ha már itt tartunk, érdemes lenne megemlékezni az EMET-ről is, de az külön blogposztot érdemelne, melynek megírására kommentben lehet ösztökélni :)

A másik eszköz amit meg szeretnék említeni, egy hoszt monitorozó szoftver, az Immunity által készített El Jefe, melynek nem rég adták ki első nyilvános változatát. Meg kell jegyeznem, hogy nem vagyok naprakész a monitorozás területén, így nem tudom megmondani (de kommenteket szívesen fogadok), hogy hasonló megoldást készített-e már más, és hogy milyen minőségben. Amit tudok, az az, hogy az eszköz GPLv3 licensz alatt szabadon elérhető, és egy igen egyszerű, de frappáns ötleten alapszik, ami általában jót jelent.

Az El Jefe userspace-ben hookolja a CreateProcess() API-t, és továbbítja a folyamatok létrejöttével kapcsolatos információkat - lenyomat, szülőprocessz, argumentumok, stb. - egy központi SQL adatbázisnak. Nagy vonalakban ennyi. A feltevés az, hogy az új folyamatok létrejötte normál körülmények között viszonylag ritka, a jószándékú felhasználók szokásai pedig ebben a kontextusban általában könnyen modellezhetők, előrejelezhetők, így viszonylag releváns és jól szűrhető (bányászható) adatokat kapunk. A gyakorlatban természetesen előfordulhat (bár nem jellemző), hogy egy támadó nem indít új folyamatokat, a releváns adatok kinyerése ebben az esetben is nagy szakértelmet, a védendő szervezet részletes ismeretét, és gondos tervezést igényel, az események száma pedig még mindig magas maradhat - ma sem találták fel a csodaszert. De a puding próbája, mint tudjuk az evés, egy próbát szerintem megér a dolog, azoknak pedig, akik nem merülnének bele a tesztelésbe, még mindig ajánlanám a szoftver bétájának bejelentését követő levelezés végigolvasását, tanulságos megoldásokkal, és álláspontokkal lehet megismerkedni!

Megjelent az Oracle negyedéves frissítőcsomagja, amely összesen 66 javítást tartalmaz a cég termékeihez, beleértve az egykori Sun szoftvereit is. Az Oracle tanácslatai általában nem túl bőbeszédűek, ezért ritkán adok hírt róluk, de most megragadta a figyelmemet egy érdekesség:

A hivatalos blogposzttal és hibalistával együtt befutottak a ZDI figyelmeztetői is, melyekben azokat a hibákat részletezik, melyekről a sebezhetőség-kutatási programon keresztül szerzett tudomást az Oracle. Itt szóba kerül például a CVE-2010-3600 azonosítóval ellátott, az Enterprice Manager Grid Controlt érintő probléma, amely az Oracle szerint 7.5, a ZDI szerint viszont 10 CVSS ponttal rendelkezik (ez a skála használatos a hibák súlyosságának jellemzésére, a magasabb pontszám jelent durvább hibát). 

A különbséget az okozza, hogy míg a ZDI szerint a sebezhetőség az érintett rendszerek bizalmasságát, integritását és rendelkezésreállását is teljes mértékben befolyásolja (Complete besorolás), addig az Oracle ezen paraméterek meghatározásakor egy saját kategóriát, a Partial+-t alkalmazta. Az Oracle dokumentációja szerint

Partial - az exploit az erőforrások egy szűk rétegét, például egy adatbázis néhány tábláját érinti

Partial+ - az exploit a erőforrások széles rétegét, például az öszes adatbázistáblát, vagy egy teljes alrendszert érinti

A Complete kategóriába sorolt sebezhetőségek a NIST definiciói szerint a rendszer összes erőforrásához (összes rendszerfájl, teljes memória) hozzáférést engednek, a Partial hivatalos definiciója lényegében megegyezik az Oracle-ével. 

A cég ezen kívül leírja, hogy az üzemeltetőnek kell eldöntenie, hogy a Partial+ érintettségű csoportokat a saját rendszerében teljes (Complete) vagy részleges (Partial) érintettségűnek tekinti - kérdés, hogy hányan olvassák el ezt a tájékoztatót... 

A konkrét sebezhetőség leírása szerint tetszőleges fájl feltölthető a kiszolgálóra egy JSP szkripten keresztül, és mivel a HTTP kiszolgáló JSP feldolgozást is végez, a kódfuttatás triviálisan elérhető, így az a legfőbb kérdés, hogy milyen jogosultságokkal fut maga a kiszolgáló. A szoftver dokumentációja függelékben tér ki rá, hogy milyen *NIX-on felhasználókat és csoportokat kell létrehozni a telepítéshez, gyakorlati szempontból ugyanakkor kiváló alkalomnak tűnik a 2.5 órás telepítési idő levágására ennek a lépésnek az átugrása, Windowsra vonatkozó iránymutatást pedig egyáltalán nem találtam - innentől kezdve a magam részéről nem fűznék nagy reményeket hozzá, hogy a jól beállított privilégiumszintek fogják megállítani a támadót, és akkor még a különböző privilégiumemelési módszerekről nem is beszéltünk! (A telepítést nem csináltam meg, bármilyen első kézből származó infót szívesen veszek!)

Szóval aki Oracle termékeket üzemeltet, jó ha tisztában van vele, hogy a cég szereti "optimistán" megítélni a problémák súlyosságát, ami a biztonsági szakmában legtöbbször nem nyerő hozzáállás, általános szabályként pedig megfogalmazható, hogy a >=7.0 CVSS pontszámokra érdemes kiemelt figyelmet fordítani.

A Digital Millenium Copyright Actre és más jogszabályokra hivatkozva perelné a PS3 kódjainak aláírásához használt titkos kulcs megszerzésének módszerét feltáró fail0verflow csapatot, és a kulcsot közzétevő, korábban az azóta javított PS3 jailbreakről elhíresült George Hotz-t a Sony. Mint ismeretes, a konzol igen vonzó hardverrel büszkélkedhet, melynek képességeit eleinte a gyártó által támogatott módon, Linux telepítésével lehetett kihasználni. Az egyedi operációsrendszer telepítésének lehetőségét azonban a Sony megszüntette, így csak a rögös út maradt azok számára, akik a megszokottól eltérő játékokat igényelnek.

A hackerek ebben az esetben tehát gyakorlatilag egy egykor elérhető lehetőséget próbáltak visszaállítani, a Sony reakcióját talán azzal lehet magyarázni, hogy a fail0verflow tényleg csúnyán a földbe döngölte a céget a prezentációjával, a privát kulcs kiszivárgásából adódó problémákat pedig nem lehet egy egyszerű firmware-frissítéssel megoldani. 

De hát így jár az, aki nem tudja mi az a véletlenszám, a srácoknak pedig drukkoljunk, hogy ne legyen szükségük IRL jailbreakre! 

A CCC-n készült videón kb 000:25-nél kezdődik a lényeg, epic fail 00:35-nél, de érdemes megnézni az egészet, nagyon szórakoztató :)

 Az év első firssítőcsomagja kevés izgalmat tartogat, viszont annál többet hagy maga mögött: ezzel a csomaggal sem a Graphics Rendering Engine problémája, sem a cross_fuzz által feltárt IE sebezhetőség(ek) nem kerülnek javításra. A CSS stíluslapok feldolgozását érintő problémára a Microsoft most egy új elkerülő megoldással rukkolt elő egy gyorsjavítás formájában, amely "minden alkalommal belenyúl kicsit az mshtml.dll-be, mikor azt betölti az Internet Explorer". A javított hibák kurta listája alant:

MS11-001: A Vista Backup Manager komponensét érintő probléma amely kódfuttatást tesz lehetővé, ha a felhasználó megnyit egy speciális backup állományt. 

MS11-002: Két hiba javítása a Microsoft Data Access Componentsben. Az egyik ezek közül az ODBC adaforrás-hivatkozásainak, a másik az ActiveX Data Object-ek feldolgozásán javít. A problémák kódfuttatást tesznek lehetővé Internet Exploreren keresztül, az összes támogatott platformon.

Frissítés:

MS11-002 exploit erre

A Microsoft ma kiadott tanácslatában egy eddig javítatlan, a Windows XP, 2003 és 2008 !R2 változatainak Graphics Rendering Engine-jét érintő hibára figyelmeztet. A probléma oka egy, a CreateSizedDIBSECTION()-ben keletkező stack túlcsordulás, amely a bélyegképek biClrUsed értékének negatív állításával idézhető elő. A sebezhetőséget Moti és Xu Hao mutatták be a Power of Community 2010 konferencián. 

A probléma elsősorban Office dokumentumokon keresztül használható ki, erre a use-case-re már Metasploit modul is készült. 

Jó tudni, hogy ezzel párhuzamosan egy malware kampány is folyamatban van, melyben hamis Microsoft frissítések telepítésére próbálják rávenni a gyanútlan felhasználókat - bár remélem, hogy kedves olvasóim közül senki sem nyitna meg e-mail ben érkezett "javításokat".

 Syddd hívta fel a figyelmemet egy érdekes PHP problémára. A következő kódrészlet végtelen ciklusba kerget bizonyos interpreter változatokat:

<?php $d = 2.2250738585072011e-308; ?>

Ha például egy webalkalmazás valamilyen HTTP paraméterben paramétereket fogad a felhasználótól, majd számmá konvertálja a beérkező karakterláncot (akár explicit módon biztonsági okokból, akár mondjuk egy összehasonlítás miatt a háttérben), a processzor ész nélküli hajtásba kezd, melynek következtében a kiszolgáló előbb-utóbb összeesik.

A probléma a zend_strtod() függvényben jelentkezik, a PHP fejlesztők egyelőre azt gyanítják, hogy a GCC optimalizációja áll a probléma hátterében. A -O0 illetve -ffloat-store kapcsolókkal történő fordítás esetén, valamint a 64 bites rendszereken a probéma nem jelentkezik.

 Mihal Zalewski közzétette cross_fuzz nevű böngésző fuzzerét, mellyel állítása szerint eddig kürölbelül száz hibát talált az Internet Explorer, a Firefox, az Opera és gyakorlatilag az összes WebKit alapú böngészőkben. A szoftver működéséről a kutató a következő rövid összefoglalót adja:

• Nyissunk két, tetszőleges típusú dokumentummal töltött [böngésző]ablakot. Egyszerű HTML, XHTML, és SVG dokumentumokat választunk véletlenszerűen, de bármely más, akár plugin által feldolgozott tartalom is felhasználható.

• Járjuk be az első dokumentum DOM hierarchiáját, és gyűjtsük össze a meglátogatott objektumok referenciáit későbbi használatra. A meglátogatott objektumokat egy tulajdonság [property] beszúrásával jelöljük, a végtelen rekurzió elkerülése érdekében, egy másodlagos feketelista pedig a dokumentumból kifelé, vagy a leszármazottakból a gyökér felé történő vándorlást akadályozza. Végül véletlen ugrások és a rekurzió terjedésének szabályozása biztosítja a jó lefedettséget

• Ismételjük meg a bejárást, és váletlenszerűen átállítgatva az objektumok adattagjait a letárolt referenciák valamelyikére (vagy esetenként az előre definiált "érdekes" értékek egyikére)

• Ismételjük meg a bejárást, és hívogassuk a megismert metódusokat. A hívások paramétereit a tárolt referenciákból és az "érdekes" értékekből állítjuk össze. Ha egy hívás objektummal tér vissza, arra is elvégezzük ezt a műveletet

• A lehetséges módszerek egyikével töröljük az első dokumentumot, szemétgyűjtést indítva.

• Ismételjük meg a fenti bejárásokat a második dokumentumon, de az első dokumentum referenciáinak felhasználásával.

• Váletlenszerűen zárjuk be az ablakokat, és a gyűjtött referenciák egy bizonyos százalékát tartsuk meg a következő fuzz iterációra.

A történet azonban nem áll meg az agyafúrt eszköznél, Zalewskinek ugyanis sikerült összeakasztania a bajszát a Microsofttal, amit tovább tetéz, hogy a kutató egyébként a Google-nek dolgozik. Történt ugyanis, hogy a szakember júliusban felvette a kapcsolatot a Microsofttal, és eljuttatta hozzájuk a fuzzer akkori változatát. Válasz a cégtől ezután nem érkezett, ezért Zalewski december végén újra próbálkozott, ezúttal a cross_fuzz egy újabb változatával. A Microsoft ekkor már reagált, elismerve a hibák létezését, egyúttal megkérve a kutatót, hogy ne hozza nyilvánosságra a felfedezést lehetővé tevő eszközt - mint látjuk, ez a kívánság nem teljesült.

A Microsoft szerint a júliusban hozzájuk eljuttatott szoftver még nem produkált értékelhető eredményeket (azt Zalewski is elismeri, hogy a tesztesetek néha igen nehezen reprodukálhatóak), Zalewksi viszont egyrészt a lassú reakciót hozza fel indokként, másrészt pedig azt, hogy a jelek szerint az egyik 0day sebezhetőséget Kínában már ismerik. 

Egy WebKit fejlesztő ugyanis a hozzájuk bejelentett hibák kivizsgálásakor véletlenül kiszivárogtatta a fuzzer URL-jét (security by obscurity?), amelyet a Google keresője annak rendje és módja szerint beindexelt. Ettől a világ persze nem dőlt össze, de később Zalewski észrevette, hogy éppen egy kínai hosztról böngészik a szerverét, melyet pont azokra az IE függvényekre való kereséssel találtak meg, amelyekkel a 0day kapcsolatos - micsoda különös egybeesés!

Ezek után mindenki gondoljon amit szeretne, én csak Narancs híres mondátát tudom idézni: "Na, látjátok, így kell a szart megkavarni!"

Frissítés:

A VUPEN szerint a kiszivárgott probléma az mshtml.dll-ben jelentkezik, mikor az körbehivatkozó JScript és DOM objektumokat kezel. A probléma kihasználhatóságát megerősítették Internet Explorer 8 és XP SP3 használata esetén.

 Még mindig teljes időzavarban vagyok a hajnalig C-Base - 12 óra vonat - szilveszter kombó után, álmatlan óráim hasznos eltöltésének pedig mi lehetne megfelelőbb módja, mint hogy megírom, milyen is volt az idei Chaos Communication Congress? :)

Az előző poszt alapján már nem jelenthet újdonságot, hogy az idei kongresszus felhozatala igen jó volt, bár így utólag nehéz eldönteni, hogy nem csak a múlt év tapasztalatai segítettek-e hozzá, hogy jobban fókuszáljuk az energiáinkat. Az minden esetre biztos, hogy idén a fejem kapkodása helyett sikerült valóban arra koncentrálnom, amiért érdemes egy hacker-konferenciát videostream helyett élőben élvezni: ez pedig a hackelés és az inspirációgyűjtés. Az új projektek egyelőre nem publikusak, de előbb-utóbb biztosan azok lesznek, várjatok türelmesen :) Ami viszont nagyon is publikus, és mindenképpen említést érdemel, az a blackout4hungary, ami szintén a 27C3 gyümölcse, reméljük sokan csatlakoznak! *

 Az elmélyült kódolás egyetlen hátulütője az, hogy az ember lemarad a buliról, ahogy az velünk is történt, de nem is biztos, hogy jó vége lett volna, ha hagyjuk, hogy a húzós előadások mellett a Phenoelite is lezúzzon. Az előadások felvételei egyébként máris elérhetőek a rendezvény teljes online közvetítését biztosító FeM-Net jóvoltából. Az általam követett prezentációk közül az alábbiakat emelném ki, mint kötelező darabokat, de természetesen nincs kizárva, hogy elmulasztottam valami korszakalkotót, érdemes tehát nézegetni a Fahrplant is!

Első nap:

• SMS-o-Death
• Rootkits and Trojans on Your SAP Landscape

Második nap:

• Wideband GSM sniffing
• Building custom Disassemblers
• High-speed high-security cryptography - encrypting and authenticating the whole Internet

Harmadik nap:

• Reverse-engineering a real-world RFID payment system

Negyedik nap:

• OMG WTF PDF

A legközelebbi megmozdulásra pedig nem kell egy teljes évet várni, nyáron ugyanis ismét megtartják a 4 évente  jelentkező Chaos Communication Camp-et, ahol hasonlóan színvonalas programra számíthatunk, no meg arra, hogy nem fagy oda a kezünk a kebabhoz.

Remélem, ott találkozunk!

*Azt meg majdnem elfelejtettem, hogy dnet megnyerte a LoL Shield Contestet! Gratulálunk!

Harmadik napunkat töltjük a 27. Chaos Communication Congress-en, Berlinben, a poszokat hiányolók kedvéért most következzen egy szedett-vetett beszámoló az eddigi eseményekről:

A konferencia előadáskínálata még a tavalyinál is erősebb, a prezentációk pedig remekül kiegészítik egymást. Az ilyen előadás-csoportok közül a legjelentősebb talán a GSM-hackelés, amely már múlt évben is komoly figyelmet kapott. Míg azonban 2009-ben a hatóság letiltotta a programozható rádiókkal megvalósítani kívánt GSM-lehallgatás demóját, addig most már az első napon élőben láthattuk, hogy hogyan lehet bemérni majd lehallgatni mobiltelefonokat egy laptop, két másik, 2000 Ft-os telefon, valamint néhány terányi szivárványtábla segítségével! A támadás megvalósításához szükséges összes tartozék könnyen beszerezhető, így már senki sem ringathatja magát abban a reményben, hogy a hívásainak lehallgatásához nem éri meg adott mennyiségű erőforrást felhasználni, a HACK számára viszont legalább egy izgalmas projektlehetőség adódott.

A múltba tekintő témák nyilván itt is gyakran a Stuxnet köré csoportosulnak, az ezzel fogalalkozó előadások közül FX "Hogyan írjunk saját disassemblert?" című értekezését sikerült steamen megnéznem. Ebben amellett, hogy gépi-utasítás-szintű bepillantást nyerhettünk az állítólagos kiberfegyver kódjába, olyan új nézőpontból tekinthettünk az általa okozott problémára, amely tulajdonképpen a biztonsági szakértők szavahihetőségét illetve kompetenciáját kérdőjelezi meg: Miért hasraütéssel becsüljük a féreg keletkezésének idejét, mikor a fordító által elhelyezett mettaadatok tartalmazzák a fordítások idejét? Miért hívják egyáltalán Stuxnet-nek, ha a kódban nem található utalás ilyen karakterláncra?

És bár az ipari vezérlőrendszerek biztonságának fontosságát Berlinben sem vonja kétségbe senki, Ertunga Arsal és Tereknz Flotow SAP biztonságról szóló előadását is szeretném kiemelni, amit minden SAP üzemeltetőnek kötelező anyag kellene hogy legyen. Ezeken a rendszereken keresztül is igen komoly dolgok manipulálhatók, és mint kiderült, az üzleti folyamatokra fókuszáló architektúra kényelmes környezetet biztosít a támadóknak és rootkitjeiknek is, egyáltalán nem valószínűtlen tehát, hogy a "kiberkatonák" már rég megszállták a kritikus üzleti rendszereinket!

A fentiek mellett persze rengeteg izgalmas programon vehetünk részt a Dunkin Donuts humán DDoS-olásától kezdve az igazságügyi DNS-szakértés workshopokig, most viszont be kell fejeznem a poszt írását, hogy meghallgassam, hogyan fogok ingyen sörözni a következő fesztiválszezonban :)

Majdnem elfelejtettem: Élő streamek nézhetők a 27c3.fem-net.de címen, a felvételek pedig folyamatosan kerülnek fel a SecurityTube-ra

Megjelent az Owned and Exposed e-zine második száma, melyben terítékre kerülnek az Exploit-DB, a BackTrack, az Ettercap, a Carders.cc, a Free-Hack és az inj3ct0r.com féltve őrzött titkai. A dumpok sok vidámságot tartogatnak, de meglepő módon a kísérő szövegek alázás-faktora a megszokottnál alacsonyabb. A kommentárok tanúsága szerint az Ettercap projekthez a Sourceforge-on keresztül sikerült bejutni, ami egyáltalán nem meglepő, és a szerzők állítása szerint már 5 éve hátsó kapukat rejtettek a szoftverbe, ami viszont elég nyugtalanító. A Backtrack rendszereihez a logok szerint nem sikerült root hozzáférést szerezni, ezért ott feltehetőleg nem került sor ilyen csúnyaságokra.

Jó olvasgatást!

A legutóbbi frissítőkedd bemutatásánál említést tettem a Breaking Point Systems ezen írásáról, melyben egy Full-Doisclosure-re érkezett IE DoS probléma kódfuttatásra történő kiterjesztését mutatják be. Akkor a sablon leírások miatt még nem volt egyértelmű, hogy ez a probléma javításra került-e a rekord méretű frissítéssel, most azonban biztosnak látszik, hogy nem.

A probléma az mscorie.dll-ben keresendő és CSS stíluslapok importálásakor jelentkezik, érinti a böngésző összes változatát az összes támogatott Windows rendszeren. Az exploitból Metasploit modul is készült, amely a ROP-ot használva megkerüli a DEP védelmét. Az érintett DLL-t ASLR támogatás nélkül forgatták, de az EMET segítségével a betöltött könyvtárak pozíciói megkeverhetők, így megakadályozható a sikeres hibakihasználás.

Internet Explorer CSS 0day on Windows 7 from Offensive Security on Vimeo.

A ProFTPd csapata elkészítette a kiszolgáló 1.3.3d verzióját, melynek kiadási megjegyzései szerint javításra került a Phrack#67-ben* közölt mod_sql sebezhetőség. Bár a megjelent cikk alapján nem volt egyértelmű, hogy a sebezhetőség kihasználható maradt-e az 1.3.3c-ben, a mostani bejentés alapján több mint valószínű, hogy ez a probléma vezetett a kiszolgáló forráskódjának manipulálásához is. Mivel a probléma leírása majdnem egy hónapja elérhető, a ProFTPd-t üzemeltetők jól teszik, ha ellenőrzik a rendszereik épségét...

* Megjelent a CFP a 86. számra!

 A DDoS támadások forrása általában egy olyan botnet, melyet valamilyen szoftver sebezhetőség kihasználásával és nagyszabású spam-hadjáratokkal verbuváltak össze. Ben Schmidt egy olyan "URL-rövidítőt" rakott össze, amely megspórolhatja a sebzhetőségkeresésre, -kihasználásra,  valamint a védelmi szoftverek kijátszására fordított időt, és hagyományos kliens oldali szkriptek alkalmazázásával terhel túl webkiszolgálókat, így bárkiből lehet Médiahatóság.

A módszer lényegében semmilyen forradalmi ötletet nem tartalmaz, mégis igen hatékony lehet: a támadó a D0z.me URL-rövidítője számára megadhat egy linket valamilyen nagy érdeklődésre számott tartó (értsd: meztelen nős ill. kiscicás) weboldalra, valamint rögzíti a célpont címét is. A szolgáltatás által generált link ezután a hagyományos módokon, e-mail, Facebook vagy Twitter spamben terjeszthető. Amennyiben valaki a D0z.me linkjére kattint, a cicás oldal betöltődik egy IFRAME-be, a háttérben viszont két támadó folyamat is indul: az egyik hagyományos JavaScripttel véletlenszeű képeket kér le a valódi célponttól (ezt a módszert használják a 4chanesek is), a másik pedig HTML5-ös WebWorkerek segítségével indít lekérdezésáradatot. Utóbbi módszerről az Attack & Defense Labs munkatársai beszéltek a BlackHaten: a dolog lényege, hogy a WebWorkerek nagy teljesítménnyel (~10 000 kérés/másodperc) képesek lekérdezésekkel bombázni a célpontot, csak az eredmények visszaolvasása van korlátozva, de arra úgysem vagyunk kíváncsiak. 

A módszer hátránya, hogy a támadó kliensek viszonylag hamar kieshetnek (bezárják a böngészőablakot), de előnye, hogy platformfüggetlenül működik fullra patch-elt Windowsoktól kezdve a desktopon használt OpenBSD-kig bármilyen JS- illetve HTML5 képes böngészőből is. A szolgáltatás természetesen csak demonstrációs célokat szolgál, a forráskód letölthető innen.

Szombaton szép számú társaság gyűlt össze kishazánk eredményeinek javítására a HACK-ben. A világot most ugyan nem sikerült megváltani, de elegendő tapasztalatot gyűjtöttünk a legközelebbi, végzetes csapás kivitelezéséhez :)

Z statisztikái szerint az este folyamán összesen 22 469 pontot gyűtöttünk, ami nagyjából  5%-ot dobott az eredményünkön, a legerdményesebb versenyzők ők voltak:

1. sysfail 7360
2. ebdf2g  6426
3. Z       1574
4. ghost   1359
5. asciimoo 1340
6. dnet    832
7. CHItA   826
8. rsdy    641
9. Scolo   348
10. muszti8 287

Ez az eredmény azonban inkább csak hab a tortán, az első figyelemfelkeltő poszt megjelenése óta országunk pontszáma ugyanis 67%-kkal javult, ami 3 helyezésnyi előrelépést hozott az nemzetek közti ranglistában!

Ez a tendencia nem kifejezetten meglepő, hiszen a WeChall pontozási rendszere úgy van kialakítva, hogy az kapjon jelentősebb mennyiségű pontot, aki már sok pályát megoldot egy-egy wargame oldalon, nehéz tehát ugrásszerű változásokat előidézni rövid idő alatt. 

Mindazonáltal nem lett volna rossz, ha nem vágják le 5 percenként a Fogasház biztosítékát, erre legközelebb megoldást kell találni.

Nagyon köszönöm mindenkinek a részvételt, a Biztributornak pedig az életbentartó szendvicseket, 2011 a magyarok éve lesz a WeChall-on!

Sokan vagyunk, és már netet is sikerült varázolni. Mivel afogasház alsó szintjén karácsonyi őrület van, nem teljesen egyértelmű a bejutás, de nyugodtan ignorálátok a mécsesárusokat, és gyertek fel az emeletre!

Lett IRC csatornánk is: #wechall @ IRCNet

Ha van új infó, frissítem a posztot.

A héten nem csak a WikiLeaks csapjai csöpögtették az információt, több hatalmas felhasználói bázissal rendelkező cég adatbázisaira az alvilág tette rá a kezét:

Ott volt ugyebár a Gawker, mellyel kapcsolatban a forráskódokat és a feláhasználói adatbázist nyilvánosságra hozó hackerek azt állítják, hogy a cég a két kihasznált sebezhetőségből csak egyet javított, azért nincs kizárva egy újabb sikeres támadás.

Aztán a McDonalds egyik partnerétől nyúlták le a hamburgeresek website-jaira illetve promócióira feliratkozottak e-mail címeit és születési adataikat. Szintén egy külső, e-mailes kapcsolattartásért felelős cégtől került ki a DeviantArt e-mail adatbázisának egy része, felhasználónevekkel együtt. Nem tudjuk, hogy ezek az incidensek pontosan hány felhasználót érintenek, minden esetre nem kis cégekről van szó, jól célzott spam kampányokkal számolhatunk a következő időszakban.

És még csak péntek van, holnap meg sörözés! :)

A Microsoft rekordmennyiségű javítást hozott a fa alá, és elmondhatjuk, a javított sebezhetőségek minőségére sem lehet panasz:

• MS10-090: Hét Internet Explorert érintő hiba javítása, köztük a november eleje óta nyilvános exploittal "rendelkező" SetUserClip() problémájé is. Találtam ezen kívül egy ilyen szépséget is, melyet sajnos nem tudtam CVE azonosítóval párosítani, mivel a bejegyzések nagy része RESERVED státuszban van. A problémák egy kivételével kódfuttatást tehetnek lehetővé IE 6/7/8 alatt.
• MS10-091: Hálózati megosztásokra pakolt OpenType betűkészletekkel kódfuttatás érhető el bármely támogatott Windows verzión, ha a felhasználó a megosztásra navigál. A javítás három ilyen problémát orvosol.
• MS10-092: Az utolsó, Stuxnet által kihasznált sebezhetőség javítása. A privilégiumemelésre alkalmas hibáról itt már írtam.
• MS10-093 - MS10-097: Ez az öt bulletin több szoftver DLL injekciós hibáját javítja, erről a hibatípusról ebben a posztban emlékeztem meg. A javított termékek: Windows Movie Maker, Windows Media Encoder, Windows Live Mail/Writer, Windows Address Book és az Internet Connection Setup Wizard.
• MS10-098: Ebben a frissítésben kapott helyet ennek a Windows kernelt érintő, jogosultságkiterjesztésre alkalmas problémának a javítása, valamint öt másik rendszermagra szánt patch (ezek is jogosultságkiterjesztés tesznek lehetővé). A problémák az összes támogatott Windows változatot érintik.
• MS10-099: Szintén helyi jogosultságkiterjesztésre alkalmas hibát javít ez a csomag, ezúttal azonban csak az XP és a 2003 szerver érintett a Routing and Remote Access NDProxy hibájától.
• MS10-100: Az előző pepitában, helyi jogosultságkiterjesztésre alkalmas probléma javítása a Windows újabb változataiban (>=Vista). A probléma a Consent User Interface komponenst érintette, az alapértelmezett Server 2008 installációk nem sebezhetők.
• MS10-101: Windows Server 2003 és 2008 tartományvezérlők esetében kihasználható DoS probléma javítása. A Netlogon szolgáltatás speciális távolról érkező csomagok esetén NULL pointer dereferenciát hajt végre, ettől pedig szépen elhasal. A Microsoft közlése szerint a hiba nem alkalmas kódfuttatásra.
• MS10-102: A Windows Server 2008 Hyper-V-ket érintő probléma javítása. A sebezhetőség lehetővé tette a vendég rendszerek számára, hogy a VMBus-ra küldött speciális csomagokkal megfektessék a host rendszert.
• MS10-103: Kódfuttatásra alkalmas fájlfeldolgozási probléma javítása a Publisherben. Erre nem vesztegetnék több szót.
• MS10-104: Ez viszont egy jópofa darab, a Document Conversation Launcher Service-nek küldött spéci SOAP kérésekkel a Guest felhasználó kontextusában kód futtatható SharePoint kiszolgálókon. A szolgáltatás alapértelmezetten engedélyezett a standalone installációkon, farmon pedig alapértelmezetten ki van kapcsolva. A bulletin szerint ideiglene megoldás lehet a Document Conversations Load Balancer Service portjának tűzfalazása, azonban az MSRD vonatkozó posztja rávilágít, hogy a a Load Balancertől elkérendő üzenetek tartalma megjósolható, így a sebezhetőség utóbbi szolgáltatás elérése nélkül is kihasználható lehet.
• MS10-105: A Microsoft Office 2007 előtti változataiban használt Image Filter komponens javítása. Az Image Filter hibái kódfuttatást tettek lehetővé Office dokumentumokba ágyazott képeken keresztül. A hibajavítás az Office 2007 és 2010-hez hasonlóan az Image Filter helyett a GDI+ feldolgozót teszi alapértelmezetté a képek rendereléséhez, valamint visszavezeti az új változatokban használt filter és konverter tiltólistákat a régebbi szoftverekbe. Az MSRD témában írt posztja itt olvasható.
• MS10-106: Az Exchange Server végtelen ciklusba zavarható egy speciális RPC hívásos egítségével. A probléma a szoftver 2003-2010SP1 változatai között, autentikált felhasználók számára kihasználható.

Helyszín: H.A.C.K. - Fogasház - VII. ker. Akácfa utca 51. (4-6 villamos, Király utca, kocsival a Blaha felöl van behajtás)

Időpont: 2010.12.18., azaz most szombat 15:00, amíg el nem zavarnak

Hozzál: Számítógépet, amin tudsz dolgozni, ha van kéznél elosztó, azt is. 

Utánpótlás: Club Mate a HACK-ben, mindenféle ital a Fogasházban és éjjel-nappali is van a környéken, ezen kívül Biztributor által szponzorált szendvicsekre is számíthatunk.

A legutóbbi alkalmak óta történt annyi változás, hogy nem szabad kimenni a teraszra, erre, valamint az allatunk szórakozókra kérlek legyetek tekintettel!

Z FAQ-ja:

Kérdés: Szabad-e a megoldásokat egymás között megosztani?
Válasz: Nem érdemes, hiszen ez az egész nem arról szól. Ez egyszerű csalás.

Kérdés: Etikus-e úgy pontokat szerezni, hogy nem feladatokat oldok meg, hanem a szervert tolom meg (wechall v más)?
Válasz: Oldal függő, hogy melyik admin mit gondol erről ,de általában rendben van, mindaddig, amíg nem ütközik bármilyen törvénybe a dolog. Tehát nem célszerű egyúttal a felhasználói jelszavakat letölteni és törögetni ...

Kérdés: Hogyan lehet a leggyorsabban pontokhoz jutni?
Válasz: Érdemes a kisebb oldalakkal próbálkozni, mivel a pontozás exponenciális alapon megy, vagyis a 10% megoldás 1% pontot ér, a 90% megoldás 81%-nyi pontot.

Kérdés: Mi van, ha nem érdekelnek a pontok, csak a poén kedvéért csinálom?
Válasz: Szerintem ezzel mindenki így van :)

Kérdés: Vannak olyan oldalak, ahol valódi gépet kell hackolni?
Válasz: Igen, pl az astalavista.

Látjuk egymást szombaton!

Theo de Raadt, az OpenBSD projekt vezetője egy olyan levelet tett közzé az egyik levelezőlistán, melynek tanúsága szerint az FBI illetve az USA Igazságügyi Minisztáriuma 2000-2001 táján hátsó kapukat adott a szabad operációs rendszer IPSec megvalósításához egy NETSEC nevű cégen keresztül. Az információ Gregory Perrytől származik, aki annak idején a NETSEC műszaki igazgatója volt, de az FBI-jal kötött titoktartási nyilatkozata állítása szerint most lejárt, és fontosnak tartotta közölni ezt a tényt(?) Theo-val.

A hátsókapukat a levél szerint a site-to-site VPN megvalósításban helyezték el. Perry szerint ezek miatt vonhatta meg a DARPA a támogatását a projekttől, és ezért ajánlotta az FBI az OpenBSD-t a különböző VPN megoldások megvalósításához.

Az OpenBSD-jé volt az első nyílt IPSec megvalósítás, melynek kódjából több más projekt is merített, így Theo most arra bíztatja a hozzáértő szakembereket, hogy vizsgálják át a kódot, és ez alapján próbálják meg alátámasztani vagy cáfolni a hírt.

(köszönet Hungernek, hogy felhívta a figyelmem az esetre!)

Kibertámadás áldozata lett a Gawker Media, amely olyan nem elhanyagolható szájtokat üzemeltet, mint a Lifehacker vagy a Gizmodo. A támadók először csak ígéretet tettek az adatok nyilvánosságrahozatalára, majd nem sokkal később egy üzenetet helyeztek el a cég weboldalán, amely mely szerint a forráskódok elérhetőek BitTorrenten, és megkértek mindenkit, hogy ne töltse le őket (fordított pszihológia? :).

A 490 megás archívum tartalmazza mintegy 1.3 millió kommentelő adatait, beleértve a hashelt jelszavakat is.

A támadók hagsúlyozták, hogy nem tartoznak a 4chanhez, és hogy nem egy WikiLeaks-szimpatizáns akcióról van szó.

Frissítés:

Érdemes követni Mikko Hypponen twitterét, folyamatosan posztolja az érdkes cikkeket a témában. Itt egy e-mail interjú olvasható az elkövetőkkel, ez pedig egy részletesebb elemzés a nyilvánosságra került jelszavakról, kiábrándító eredményyel. A dump egyébként néhány magyar, Gawkernek dolgozó fejlesztő jelszavait is tartalmazza. Anarki pedig megint nem tudom melyik univerzum híreiből tájékozódik, de a 4channek jó eséllyel nincs köze az esethez. A megszerzett jelszavakat a Twitteren az "Acai Berry" fogyókúraspam terjesztésére használják.

Az Exim levelezőszerver fejlesztői listájára küldött levelében Sergey Kononenko azt írja, hogy az általa üzemeltetett hálózatba egy eddig ismeretlen Exim hibán keresztül sikerült bejutniuk ismeretleneknek. A levél tanúsága szerint a HeaderX fejlébe helyezett speciális stringekkel érhettek el kódfuttatást.

Egyelőre semmilyen hivatalos megerősítés nem látott napvilágot a bejelentéssel kapcsolatban, de jó, ha odafigyel a rendszereire az, aki exim-et üzemeltet! Sergey egyébként Debian Lenny-n tapasztalta a jelenséget, amelyet állítása szerint Squeezen is reprodukálni tudott.

Frissítés: 

A probléma valós, a string_format() függvény bugja okozza a bajt, de az Exim csapata már a 4.70-es verzióban javította a hibát. Mivel azonban a kiadás nem jelölték meg biztonsági frissítésként, a Debian csapata még nem emelte be a patch-et. Az érintett felhasználók a backports tárolóból installálhatják a javított, 4.72-es verziót.

Már több helyen megjelent a hír, hogy Dan Rosenberg helyi jogosultságkiterjesztésre alkalmas exploitot publikált a Full-Disclosure listán. A szerzemény igen érdekes, ugyanis három különböző hiba összekapcsolásával éri el a root állapotot:

Az exploit alapjául a CVE-2010-4258 jelű probléma szolgál: clone()-al bizonyos módon létrehozott szálak egy NULL szót írnak a felhasználó által meghatározott helyre a memóriában kilépéskor. Ez az írás természetesen csak a felhasználó számára kijelölt, userspace memóriaterületen történhet...elvileg. Ha ugyanis a kernel kiterjeszti a folyamat adatszegmensét egy kernel módból induló rendszerhívás végrehajtásához, de ezután egy oops miatt a szál elhasal, az adatszegmens nem kerül visszaállításra, így a kernelspace-be is lehet írni.

Namármost, ehhez kell valamilyen bug, ami oopsra futtat egy szálat, miután megtörtént az adatszegmens kiterjesztése. Erre jó a CVE-2010-3849 jelű Econet driver NULL pointer dereferencia, szépséghibája, hogy Econet interfészeket manapság senki sem konfigurál a rendszerén, márpedig a hiba triggereléséhez ez kell. A CVE-2010-3850 jelet kiérdemelt probléma lényege viszont éppen az, hogy egy átlag júzer is képes Econet interfészt konfigurálni, ezzel pedig a kör bezárult (vagy mi).

Látható, hogy a szálkezeléssel kapcsolatos hiba fölé elméletileg bármilyen alkalmas exploit felhúzható, erre a kétlépcsős econetes virtuózkodásra valószínűleg csak azért volt szükség, hogy Rosenberg ne unja magát halálra kódolás közben (meg persze az is szép, hogy mindhárom kihasznált hibát Nelson Elhage fedezte fel) :)

A nagyobb disztrók közül a Slackware, a Debian és az Ubuntu tartalmazza az Econet drivereket, az exploitban használt kernel szimbólumok csak Ubuntun elérhetőek, de az ezt érintő hibákat már ott is javították. Ezen kívül bekerült némi "script-kiddie védelem" is a kódba, szóval ne ész nélkül használjátok!

És akkor egy pár szóban a katedrálisról, a bazárról, meg a hibakezelésről az előző blogos poszt kapcsán. Előre bocsátanám, hogy hivatalosan nem értek sem a sebezhetőség-menedzsmenthez, sem más kapcsolódó területhez, a leírtak csak a saját tapasztalataimat és gondolataimat összegzik, támaszkodva néhány, nálam sokkal tapasztaltabb szakember hasonló okfejtésére.

Bizonyára mindenki, aki ide kommentel felfedezte már, hogy a blog.hu admin felületén van egy nagy, narancsságra "Bugreport" gomb (mailto:), amit lehet nyomogatni, ha valakinek baja van, ezen kívül ott a Gépház blog és egy általános kontakt e-mail cím a főoldalon a nem regisztrált felhasználók számára. A Postr-en a lap alján van egy Írjon Nekünk! link, ami átdob az origo.hu-ra, ahonnan egy webes formon keresztül küldhetünk üzenetet, Origo címlap tárgymegjelöléssel, miután megoldunk egy CAPTCHA-t - ez a form mellesleg pár hónapja szintén SQL errort dobott ha jól rémlik.

A blog.hu-nak küldött e-mailemre 2:03 perc után kaptam választ, majd kicsivel később kértek, hogy írjam le a kihasználás pontos módját, hogy tudják ellenőrizni az addigra elkészült javításukat, valamint megkértek, hogy ne publikáljak semmit, amíg mindent le nem ellenőriztek.

Ha ugyanezt az Origo felületéről indulva akartam volna eljátszani, akkor nem tudtam volna elrakni az eredeti e-mailem, és fogalmam sem lett volna arról, hogy egyáltalán történt-e valami a túloldalon - a Mailer-Daemon bácsi ezzel szemben hasznos infókkal tud szolgálni a legtöbb esetben. Szerencsére annak idején pont a Postr kapcsán beszélgettünk egy origo-s illetékessel, akin keresztül (2 hopon át...) el tudtam juttatni a fejlesztőkhöz az információt.

Aztán két nap múlva írtam egy türelmetlen e-mailt, hogy mi a vihar van, mert a site ugyanúgy áll bugosan. Mint a válaszból megtudtam, a fejlesztők már kijavítottak valamit, de azért jó lenne ha küldenék támadási mintákat, hogy ellenőrizzék magukat. Ezen kívül a frissítési folyamat a Magenta Óriás gyomrában nem triviális, 1-2 napnál hamarabb nem tudnak kikerülni a javítások. 

Igen, elfeledkeztem róla, hogy a Postr kiadója az Origo, akit pedig bezony a Magyar Telekom tart kézben az egész blogszolgáltatás meg integrálva van az iWiW-vel, a Videával és a Freemaillel is. Bazárt feltételeztem ott, ahol már rég katedrális áll, az pedig mint tudjuk, nehezen mozdul meg.

A történet egyik tanulsága tehát az, hogy nem szabad ugyanúgy hozzáállni egy hatalmas multihoz, mint egy olyan céghez, ahol közvetlenül lehet levelezni a fejlesztőkkel. Türelmesnek kell lenni, mert a belső szabályzatok és a vállalati hierarchia a legtettrekészebb emberek kezét is megkötheti - nincs kétségem affelől, hogy a Postr munkatársai lehetőségeikhez képest a leghatékonyabban jártak el ebben a szituációban.

De az eset ugyanakkor a technikai segítségnyújtás prüszkölő állatorvosi lova is, álljon hát itt néhány tanács azok számára, akik szeretnének hatékonyan reagálni a kívülről érkező hibajelentésekre:

• Ne nehezítsük meg a hibajelentést! Legyen legalább egy közvetlen technikai kontakt e-mail cím a weboldalon, minimum az impresszumban, mert a magunkfajta nem fog telefonálni, levelet írni, faxot, vagy füstjeleket küldeni, meg önmagát CAPTCHA-kkal szívatni, mikor a hibajavítás kizárólag a szolgáltató érdeke. Nagy fejlesztők esetében általában egy security@ fiók létezése is elvárás. Spamszűrő meg legyen.
• A technikai kapcsolat címére küldött e-mailek lehetőleg ne a PR-osztályon landoljanak, mert ott nem tudják, hogy mit kell kezdeni vele.
• A bejelentővel közöljük, hogy várható-e javítás, és ha igen, mikorra. Ezzel kapcsolatban ezt a levelet tudom ajánlani. 
• Szerezzünk meg a bejelentőtől minden javításhoz szükséges információt mihamarabb, nem tudjuk mikor válik köddé az illető.

Akinek ez mániája, írhat erre valami szabályzatot is :)