Ahogy azt már bizonyára sok helyen olvastátok, a Microsoft ismét mennyiségi rekordot döntött az ehavi frissítőcsomagjával:

• MS10-071: Hét javítás az Internet Explorerhez. A csomag az összes támogatott verziót gyógyítja, és szokás szerint távoli kódfuttatásra alkamas sebezhetőségek javításai is helyet kaptak a csomagban.
• MS10-072: Kisebb, információszivárgást lehetővé tevő probléma javítása a SharePointban a SafeHTML szolgáltatásában. A Groove Server és az Office Web Apps is érintett (a Google Docs vetélytárs sem érintetlen többé...).
• MS10-073: Három jogosultságkiterjesztést lehetővé tevő probléma javítása a Windows összes támogatott verziójában. Az egyik ezek közül a CVE-2010-2549-ben leírt problémát orvosolja, amelnyek részletes tárgyalása ebben a júniusi levélben olvasható.
• MS10-074: Na, ez egy érdekes darab. A Microsoft Foundation Classes könyvtár rosszul kezeli az ablakok címét. A probléma távoli, és csak távoli kódfuttatásra használható, ha egy adminisztrátorként bejelentkezett felhasználó egy MFC alkalmazást nyit meg, amely valamely ablakának címét egy távoli támadó befolyásolhatja. A Microsoft a saját szoftverei között nem talált ilyet, de egy másik féltől származó támadható szoftvert azonosított. (Vicces látni, hogy a MS bulletinlegózó programja automatikusan leírta, hogy ha admin felhasználóval futunk bele a problémába akkor hajjaj, a hiba viszont csak így kihasználható...)
• MS10-075: Windows Vistát és 7-et érintő probléma javítása, amely távoli kódfuttatást tett lehetővé a Media Player Network Sharing ("legyünk mi is kalózok" ?) szolgáltatásának küldött spéci RTSP csomag segítségével. A probléma alapértelmezetten csak helyi hálózaton használható ki mivel a szolgáltatás Internet felöli elérése le van tiltva.
• MS10-076: Szeretjük a betűkészleteket. Ezúttal az Embeded Open Type fontok feldolgozásában elkövetett bénázásra derült fény. A probléma távoli kódfuttatásra ad lehetőséget, tipikusan úgy, ha a kedves felhasználó gonosz weboldalra téved.
• MS10-077: Jóféle .NET sebezhetőség, ami egyrészt kódfuttatást tesz lehetővé XAML Browser Application-öket futtató böngészőkben, másrészt IIS-en, ha egy támadónak lehetősége van feltölteni rá ASP.NET alkalmazásokat. Az érintett termkek listáját böngészve viszont sajnálattal tapasztalhatjuk megnyugodhatunk, mivel csak a legújabb .NET 4.0 érintett, az is csak x64-en és Itaniumon
• MS10-078: Windows XP-t és 2003-at érintő OpenType Font kezelést érintő probléma javítása (mondom, hogy szeretjük a betűkészleteket). A hiba jogosultságkiterjesztést tesz lehetővé. Bővebb infó illetve PoC erre van.
• MS10-079: 11 (!) darab hibajavítás az Office Word különböző változataihoz. A kódfuttatás lehetőségét egyik változat sem úszta meg.
• MS10-080: 13 (jeeez!) darab hibajavítás az Office Excelhez. Azt hiszem ezek az Office javítások dobták meg durván a most javításra került hibaszámot... Kódfuttatási lehetőség, de a 2010-es változatok, illetve a Works 9 nem érintett.
• MS10-081: A Common Control Library egy sebezhetőségét javító patch. A probléma távoli kódfuttatást tesz lehetővé speciláis weboldalak meglátogatásakor. A hiba ilyetén (úristen de késő van...) kihasználásához telepítve kell legyen egy SVG képeket feldolgozni vágyó böngésző, vagy más alkalmazás (ilyen értelemben persze a "távoli" jelző sérülhet).
• MS10-082:  A Windows Media Player 9-12 változatait érintő távoli kódfuttatásra alkalmas sebezhetőség javítása. A probléma kihasználásához az áldozatnak meg kell látogatnia egy weboldalt, amely WMP-vel feldolgozandó médiát tartalmaz, majd kattintania kell néhány pop-up ablakon.
• MS10-083: A WordPad és a Windows Shell (?!) rosszul kezeli bizonyos COM objektumok betöltését, ezért kódfuttatás fordulhat elő, ha spéci WordPad fájlt nyitunk meg, vagy kijellölünk ill. megnyitunk egy hálózati megosztáson található parancsikont. Ezt rakjátok össze!
• MS10-084: Jogosultságkiterjesztésre alkalmas probléma javítása a Windows régebbi (XP-2003) rendszereinek Local Procedure Call alrendszerében. A nem triviális exploitot itt lehet megtekinteni.
• MS10-085: DoS lehetőség javítása az újabb Windowsok (>=Vista) SChannel réteg TLSv1 megvalósításában. A probléma kihasználásával az LSASS-t lehet kinyírni tipikusan IIS 7.0-n vagy 7.5-n keresztül
• MS10-086: Failover clusterbe pakolt Windows Server 2008-akat érintő probléma, amely a Failover Cluster Manager felületén keresztül hozzáférést enged jogosulatlan felhasználóknak az adminisztratív megosztás bütyköléséhez. A probléma (amennyire a bulletinből ki lehet venni) akkor jön elő, amikor új diszket adunk a klaszterhez, ilyenkor ugyanis alapértelmezetten túlzottan megengedő hozzáférési szabályok kerülnek megállapításra. Érdeklődőknek ajánlandó az SRD vonatkozó posztja.

Végül álljon itt egy szép ábra az MSRC-ről, ami szépen mutatja a különböző javítócsomagok fontosságát:

A poszt létrejöttét Ranger 5 órás dubstep mixe és a sarki éjjel-nappali tette lehetővé.

Ilyen sem volt még, de éppen ideje elkezdeni: A Szak Kiadó jóvoltából hozzájutottam Szőr Péter: A vírusvédelem művészete című munkájához, ami bár külföldön alapműnek számít az IT-biztonság területén, magyarul most jelent meg először.

Őszintén szólva először szkeptikusan álltam a könyvhöz, hiszen nem egy olyan kiadvánnyal találkoztam a boltok polcain, amiben gyakorlatilag szép képernyőképekkel demonstrálva rágják újra az ember szájába, hogy miért kell vírusírtót frissíteni. Nos, a szkepticizmusom megingott, amikor kezembe kaptam a több mint 600 oldalas művet, a tartalomjegyzék átfutása után pedig legszívesebben bezárkóztam volna valami eldugodt helyre egy olvasólámpával, hogy hagyjon mindenki békén tanulni.

Pedig nem is tervezek vírusírtót készíteni. Szőr Péter azonban felismerte azt, hogy a védekezés nem lehetséges a támadási módszerek megismerése nélkül, így a  heurisztikák, kódemulációs módszerek mellett remek összefoglalót kapunk a különböző exploit-technikákról - az egyszerű veremtúlcsordulástól a ROP-on át a JIT-compilerek kihasználási módjaiig -, anti-debuging módszerekről és önmódosító kódokról is. Platformok tekintetében a klasszikus DOS-os kártevőktől a manapság jellemző 32-bites Windowsokat sújtó vírusokon és férgeken át az olyan egzotikusnak számító kódok is terítékre kerülnek mint a linuxos Slapper vagy éppen az SAP rendszereket célzó ABAP-ban írt Rivpas. 

A vírusvédelem művészete emellett nem marad meg a puszta történeti áttekintésnél és osztályozásnál, a könyv szakembereknek szól, szakember(ek)től. Az oldalakról nem hiányoznak a forráskódok és disassembly-k, valamint külön fejezet foglalkozik a vírusanalízishez használható környezet kialakításával. A defenzív és offenzív módszerek egymásnak feszülésével létrejött "vírusevolúció" bemutatása ugyanakkor határozottan olvasmányossá teszi a fejezeteket, egyúttal remek képet kapunk a vírusvédelem jelenlegi helyzetéről és a jövő lehetőségeiről is, objektíven szemléltetve az eredményeket de a megoldandó kihívásokat is.

Zavaró momentumként talán egyedül a fordítást tudom felhozni, de itt sem arról van szó, hogy dilettánsokra bízták volna a magyarítást. Egyedül az akasztott meg néha-néha az olvasásban, hogy a hazai szakzsargonban is rendszeresen angolul használt kifejezések (debugger, return-2-libc) is magyarul szerepelnek, és bár a fordítás ezek esetében is jól sikerült, a szokás hatalma rákényszerít, hogy fejben mindig visszafordítsam ezeket a kifejezéseket angolra. 

Összességében azt mondhatom, hogy ilyen jó összefoglalóval magyar nyelven még nem találkoztam. A könyvet bátran tudom ajánlani mindenkinek, aki ael szeretne mélyedni a kártékony kódok lelki világában, legyen szó lelkes kezdőről, vagy tapasztalt "vén rókáról". Előbbiek számára A vírusvédelem művészete remek kiindulási alapot nyújt a tanuláshoz, utóbbiak pedig egyfajta kisenciklopédiaként vehetik hasznát.

A könyv megjelenését az ESET magyarországi képviseletét ellátó Sicontact Kft. támogatta. Szerintem megérte.

A hihetetlenül bonyolult nevű Maksymilian Arciemowicz egy több terméket érintő, túlterheléses támadások kivitelezésére alkalmas sebezhetőségről számolt be. A hiba a tipikusan szabadszavas fájlkereséseknél használt glob() eljárástban leledzik. A probléma ott van, hogy az eljárás nem veszi figyelembe a GLOB_LIMIT értékét, amely megszabná az általa maximálisan felhasználható memória méretét, ha keresett mintára nem illeszkedik fájl. Tehát amíg a */../*/../*/../*/../* keresés kiértékelésekor előbb-utóbb leáll a folyamat a GLOB_LIMIT megsértése miatt, addig a ../*/../*/../*/../*blablalbalba keresés szépen elkezdni felzabálni a memóriát.

A probléma több gyártó termékeit is érinti, Arciemowicz az FTP szerverekre ment rá, és azt találta, hogy a FreeBSD, az OpenBSD, a NetBSD, és az Oracle Solaris fájlkiszolgálói is lelőhetők ilyen módon, valamint potenciálisan az összes globoló, GNU libc-t használó projekt is érintett lehet.

 BSH küldte a hírt a következő eseményről:

A 2010. október 4-i megakonferencia, azaz a TechNet Szakmai Nap első követő eseményét egy hatalmas és kiemelkedően fontos téma köré szerveztük, és ez a biztonság. Ezen a területen nem könnyű a témaválasztás, hiszen az operációs rendszerektől az alkalmazásokon keresztül a hálózati forgalomig és akár az Internetig sok-sok technológia és megoldás szóba jöhet. Éppen ezért mi ezen a napon a 4x60 percben egyszerre próbálunk átfogó ismereteket nyújtani, mindemellett egy-egy témába mélyebben is belemenni.

Tematika

1. A Windows biztonsági palettája

2. Forefront Endpoint Protection – A végpontok védelmi bástyája

3. Egységes felhasználói adatkezelés a Forefront Identity Manager segítségével

4. Forefront TMG mint tűzfal

További részletekért fáradjatok át a hivatalos oldalra! A beugró 6000 HUF, ezért cserébe kaptok ebédet, és Gál Tamás A kapun túl című könyve is ajándék.

(ez nem egy Microsoft által szponzorált poszt)

• Kijött az Adobe előrehozott októberi frissítőcsomagja, amely javítja az utóbbi hetekben feltűnt kritikus biztonsági hiányosságokat. Frissíteni kötelező. A következő negyedéves adag februárban jön, de nem fizetnek jól a bukmékerirodák azoknak, akik fogadnának még egy idei javításra. Ezen kívül megjelent egy összefoglaló a majdan bevezetendő sandboxról, ez sajnos nem lett túl izgalmas.
• Megjelent az IDA Pro 6.0 valamint frissült a HexRays decompiler is. A legnagyobb újdonság a vadonatúj Qt-s GUI, amitől a Linuxot illetve OS X-et preferáló bitvadászoknak minden bizonnyal könnybe lábad majd a szemük. Itt pedig egy csodaszép prezi.com-os előadás keretében betekintést nyerhettek a reverse engineering alapjaiba.
• Megkezdődött a Hacktivity anyagainak feltöltése, valamint régi adósságom, hogy beszámoljak az Ethical Hacking videóinak elérhetőségéről is.

Ebben a posztban megpróbálom öszefoglalni a méltán elhíresült "Padding Oracle Attack" lényegét, ami bizonyára nem kevés álmatlan éjszakát okozott néhány programozónak és egy rakás üzemeltetőnek. 

Matekozni fogunk, szóval igyatok egy kávét vagy ilyesmi!

SGHCTomának hála megoldódott a "rejtély", a következők derültek ki:

• A hakin9 magazinban valóban le volt írva az MS10-061-es sebezhetőség, de furcsa módon a cikk szerzője sem fedezte fel a benne rejlő (távoli kódfuttatást biztosító) lehetőséget, így a cikk a helyi jogosultságkiterjesztésre ment rá, és így nekem is elkerülte a figyelmemet a dolog.
• Mint kiderült, az említett cikkben tárgyalt jogosultságkiterjesztésre alkalmas módszer nem pontosan úgy működik, ahogy le van írva. Nem a wmarkps.dll, hanem a wmarkui.dll belépési pontjára kerül SYSTEM joggal a vezérlés.
• Bár a távoli kódfuttatás lehetősége javítva lett, a jogosultságkiterjesztés még mindig működik teljesen patchelt rendszereken!

És hogy meglegyen a tanulság a mai napra is, íme, hogyan érhető el kódfuttatás fájlírással Windowson:

Az MS10-061-et kihasználó Metasploit modul nem egy, hanem két fájlírást végez: az első létrehozza magát a lefuttatandó állományt, a másik pedig az ATSVC named pipe-ot nyitja meg írásra. Ezen keresztül RPC hívások indíthatók a Windows időzítő szolgáltatása felé, vagyis az elsőnek létrehozott fájl felírható a "lefuttatandó folyamatok" listájára. Külön gyönyörű, hogy a rendszeridőt és időzónát a távoli hoszt SMB válaszában visszakapjuk a nyomtatóhoz történő csatlakozáskor :)

Szóval ennyi volt a móka, most pedig egy kicsit más vizekre evezek...

Nos, sikerült valamelyest előrelépnem az MS10-061 témájában, a következő a helyzet: Végigcsináltam a Carsten Köhler-féle mókát, és vagy elbénáztam valamit, vagy nem működik a dolog. A spéci nyomtatódriverem szépen betöltődik és le is futtatja a notepad.exe-t (nem is egyszer...) de mindig a nyomtatót installáló, ill a nyomtatást elindító felhasználó nevében. Teszteltem zsírúj XP SP0-n, úgy hogy éppen csak az MS10-061 volt fent, és úgy hogy egy frissítés sem hiányzott, az eredmény mindhárom esetben azonos.

Akinek van tippje, ne tartsa magában! 

A Hacktivity-nek "köszönhetően" kimaradt a legutóbbi MS frissítőkeddet bemutató írás, ezt szeretném most részben pótolni ezzel a kissé formabontó poszttal.

Az utóbbi napokban kicsit utánamentem az MS10-061-es azonosítóval ellátott hibának, mivel jónéhány körülmény felkeltette az érdeklődésemet vele kapcsolatban, ugyanakkor még ebben a pillanatban is van néhány dolog, ami nem krisálytiszta.

A javított probléma a LocalSystem-ként futó Print Spooler szolgáltatás megszemélyesítését tette lehetővé minden támogatott Windowson, kritikus besorolást ugyanakkor csak Windows XP esetében kapott, ugyanis csak itt lehet távolról kihasználni a problémát alapértelmezett beállítások mellett. A sebezhetőség kihasználhatóságát korlátozza, hogy a célponton regisztrálva kell hogy legyen egy megosztott nyomtató, és engedélyezve kell hogy legyen a Guest account*, vagy a támadónak rendelkeznie kell a nyomtató használatához szükséges hitelesítő adatokkal. A hiba érdekességét nem is az univerzális kihasználhatóság adja, hanem az, hogy

• ezt a problémát használja ki (többek között) a Stuxnet
• a hiba állítólag már 2009-ben nyilvánosságra került a hackin9 magazin jóvoltából, javítás viszont csak most készült.

Az első ponttal nem nagyon kell vitatkozni, annyit érdemes látni, hogy a viszonylag szűkre szabott lehetőségek mellett azért van létjogosultsága az ilyen problémák kihasználásának.

A második pont volt az, ahol elkezdte piszkálni a fantáziámat a dolog. A hackin9 vonatkozó számában (2009/4.) ugyanis Carsten Köhler egy helyi jogosultságkiterjesztésre alkalmas problémát ír le, míg a Microsoft tanácslata egyértelműen távoli kódfuttatásról beszél.

Nézzük először Köhler módszerét: Adott egy Windows hoszt, amihez korlátozott felhasználói hozzáféréssel rendelkezünk, de többet szeretnénk ennél. Legyen egy másik hoszt is a hálózaton, amihez korlátlan hozzáférésünk van. A célponton nem tudunk (nyomtató) drivereket installálni, viszont tudunk telepíteni távoli megosztott nyomatatókat. A saját gépünkön (amihez teljes hozzáférésünk van) regisztrálunk egy nyomtatómegosztást, majd a célponton telepítjük ezt a távoli printert. Amikor egy új nyomtatási feladat érkezik a célpont ehhez a nyomtatóhoz tartozó várakozási sorába, spooler elkéri és telepíti a nyomtatóhoz tartozó tartozó meghajtót a nyomtatókiszolgálótól - vagyis tőlünk. Innentől kezdve nyertünk, hiszen olyan drivert adunk a célpontnak, amilyet akarunk (bár problémák még lesznek, az eredeti cikk tartalmaz néhány ügyes trükköt ezek feloldására!).

De ez még koránt sem távoli kódfuttatás! Szerencsére jduck a Metasploit csapatból rögtön össze is dobott egy exploit modult a hiba kihasználására, ebből kiderül, hogy hogyan is érhető el a kívánt eredmény. A lényeg a start_doc_printer metódusban van, ahol is az RpcStartDocPrinter távoli eljárás kerül meghívásra. Az átadott paraméter egy DOC_INFO_CONTAINER struktúra, melynek pDocInfo1 adattagja tartalmazza a printer által létrehozandó fájl elérési útját. Ahogy az exploit kommentjeiből (és a vonatkozó blogpoasztból) kiderül, a CWD a system32 könyvtár, ahonnan az úvonal megfelelő beállításával akár a teljes fájlrendszer bejárható.

Mink van eddig? Egy megosztott nyomtatón keresztül tetszőleges fájlt tudunk írni a Local System jogosultságaival. Hol a hiba? Természetesen elsősorban ott, hogy a spooler nem dobja el a jogosultságait és veszi fel a távolról csatlakozó felhasználó (tipikusan Guest) tokenjeit a fájműveletekhez. Másrészt érdekesnek tűnik (bár nem biztos hogy köze van a szóban forgó problémához) a DOC_INFO_CONTAINER dokumentációjának következő pontja:

Ha a pDocInfoContainer paraméterta a "unique" IDL attributummal deklarálták, melynek értéke NULL, ugorjuk át a validációs lépéseket, és feltételezzük, hogy a validáció sikeres volt

Érdekes, de ne kanyarodjunk el a témától... A két megoldás (Köhleré és a Metasploit csapaté) látszólag - és ez az én problémám - lényegesen különbözik: hogy mást ne mondjak, első esetben egy driver/DLL betöltésével lényegében azonnal parancsfuttatást értünk el, addig utóbbi  esetben egy fájlt tudtunk írni (persze ebből ügyesen tovább lehet lépni, de erről majd talán egy másik posztban). A megoldás, vagyis a probléma gyökere valószínűleg ott keresendő, hogy a spoolsv.exe, aki végig a bajok okozója volt, egyáltalán nem foglalkozott a jogosultság-eldobással, ami elég durva szarvashibának tűnik, és implikálja a kérdést, hogy miért nem fedezte fel ezeket a problémákat más már jóval korábban (2009 előtt)?

A választ egyelőre én sem tudom, lehet, hogy maga a következtetésem is hibás, ezért kíváncsi lennék a véleményetekre!

* Windows XP-n letiltott Guest fiókkal gond nélkül lefut a cucc, a tanácslatot ezek után nehezen tuodm értelmezni

Frissítés #1: Yitsushi küldött egy érdekes linket, amiben szépen szétszedik a patchet. Ebben jól látszik, hogy valóban a StartDocPrinter hívásnál történt változás, egyebek mellett bekerült egy CheckLocalCall(), egy CheckTokenMenebership illetve ValidateOutputFile() hívás is, azaz - ha lehet hinni a függvényneveknek - ellenőrzésre kerül, hogy helyi hívásról van-e szó, hogy a hívó rendelkezik-e a megfelelő jogosultságokkal, valamint, hogy nem akar-e kellemetlen helyre írni. Látszólag tehát nem jártam rossz nyomon, de azért nekem is fel kéne ébresztenem IDA nénit...

Lassan jönnek az önkormányzati választások, de nálunk sajnos nem nyílik olyan mértékű mókázásra lehetőség ezzel kapcsolatban, mint a svédeknél, ahol elfogadják a kézzel írt válaszokat is.

A lehetőséget kihasználva egy vicces kedvű választó a következő jelöltre adta le szavazatát:

R;13;Hallands län;80;Halmstad;01;Halmstads västra valkrets;0904;Söndrum 4;pwn DROP TABLE VALJ;1

Egy másik politikailag tudatos állampolgár pedig ezzel próbálkozott:

R;14;Västra Götalands län;80;Göteborg;03;Göteborg, Centrum;0722;Centrum, Övre Johanneberg;(Script src=http://hittepa.webs.com/x.txt);1

A voksoláson egyébként kiemelkedő helyezést ért el Donald Kacsa és a Hard Alcohol Party is bezsebelt 237 szavazatot.

Ez is egy jó hatásvadász cím lett, íme a gumicsont:

Korábban már én is írtam róla, hogy a Stuxnet bizonyos támadó moduljait ipari vezérlőrendszerekbe történő bejutásra tervezték. Ehhez hozzávéve, hogy a botnet a Realtek Semiconductortól és a JMicron Technology-tól lopott privát kulcsokat használja p2p hálózata kommunikációjának titkosítására, valamint hogy terjedéséhez legalább 4 darab 0-day exploitot használt, egyértelművé teszik, hogy ezt a jószágot nem Haxor Pistike ((c) ???) dobta össze a Malware Lego 2010-zel. 

A Langner Communications GmbH. ipari IT-biztonsággal foglalkozó kutatói a malware részletes elemzése után egy igen merész elmélettel álltak elő: Véleményük szerint jó esély van arra, hogy a Stuxnetet Irán busehri atomerőművének szabotázsa céljából készítették, a támadás pedig a közeli jövőre lett időzítve. 

Ezt persze maguk a kutatók is egyszerű spekulációnak minősítik, azért nézzük végig az érveiket:

• A fertőzés Iránra és környékére koncentrálódik
• A Stuxnet készítői professzionális, SCADA rendszerekben jártas, és azokhoz valószínűleg hozzáférő emberek (vagy nem emberek, de ez egy másik összeesküvéselmélet :) - ez a professzionális szabotázst támasztja alá
• A Stuxnek egy jól meghatározott "gyors lefolyású" folyamatot állít meg, amely egy olyan valós idejű folyamatot jelent, amelynek (ebben az esetben) 100 milliszekundumon belül le kell futnia. - Tehát valószínűleg nem arról van szó, hogy odaég-e a rendszergazda kávéja
• A célpont nagy értéket képvisel a támadó szemében - Minden bizonnyal, egyébként nem foglalkozott volna vele ennyit
• Az analízis ki fogja deríteni, hogy pontosan milyen folyamatot támad a féreg. Ez meg fogja mutatni a pontos célpontot és ezzel együtt a támadót is. Erre a Stuxnet készítői is fel voltak készülve, és valószínűleg nem tartanak attól, hogy börtönbe kéne fáradniuk.

Ezen kívül van egy majdnem-tárgyi "bizonyíték" is, ami a legérdekesebb mind közül, egyúttal pontosan ez az, ami szvsz. az egész elméletet megborítja.

Ez a kép állítólag Busehrben készült és azt mutatja, hogy a WinCC éppen licensz problémákra panaszkodik. Ami az elmélet szempontjából pro: ugyanezt a SCADA megoldást támadja a Stuxnet (lásd a korábbi posztot).

Kontra 1.: Ha Iránban licensz nélküli vezérlőszoftvert használnak egy épülő atomerőműben, akkor fölösleges a kibertámadás.

Kontra 2.: Ha az ember le akar tölteni pl. egy sima asztali kripto szoftvert, háromszor meg kell esküdnie az összes jelenlegi és jövőbeni leszármazottja életére, hogy nem fogja bevinni Iránba (ill. Észak-Koreába, meg néhány hasonló helyre). Egy urándúsításhoz használható célszoftvert, a speciális PLC-ket és a hozzájuk való Windows hálózatot szemrebbenés nélkül szállítják és licenszelik a kollegáknak, akiknek még a Red Alert készítői is a Terroristát adták speciális egységként?

Érdekes elgondolás... Nektek mi a véleményetek?

trey@HUP

2007 őszén egy exploit látott napvilágot a 2.4-es és a 2.6-os kernelekhez. Az exploit a 64 bites kernelek 32 bites emulációjának sebezhetőségét használta ki. A sebezhetőséget eredetileg a 2009-ben repülőbalesetben elhunyt, ismert lengyel kernelhacker, Wojciech "Cliph" Purczyński fedezte fel. Az exploit sikeres használata esetén a helyi támadó root jogokhoz juthatott. A hibát a kernelfejlesztők kijavították 2007-ben a 2.6.22.7-es kernelben.

Ben Hawkes nemrég gondosan átvizsgálta a kernel szóban forgó kódját és Tavis Ormandy jelenlétében észrevette, hogy valami nem stimmel. Szólt Robert Swiecki-nek, aki 2007-ben az eredeti sebezhetőségre az exploit-ot megírta. Swiecki megerősítette, hogy valóban érdekes az, amit talált. Elővették a régi exploit-ot, egy kicsit alakítottak rajta és végül a használatával root shell-hez jutottak.

Kiderült, hogy 2008 elején a javításra készített patch-et eltávolították, így a sebezhetőség ismét kihasználhatóvá vált.

Szeptember 14-én Ben Hawkes bejelentése nyomán javításra került a korábbi baklövés.

PoC exploit itt.

A sztori itt olvasható.

Az eredeti poszt többször frissült, látogassatok el a HUP-ra további részletekért (ill. igyén szerint flame-elni :)

 Nem sokon múlt, de sikerült túlélni a Hacktivity-t, az utóbbi 3 napban viszont még e-mailt nézegetni sem volt időm, így a posztok is elmaradtak, pedig lett volna miről írni. Szerencsére Balássy György a saját blogjában már megírta az utóbbi napok egyik legnagyobb durranásának, egy most nyilvánosságra hozott, ASP.NET alkalmazásokat érintő kripto-problémának az összefoglalóját:

A fenti mondatot a minap hallottam egy kedves ismerősömtől az Adobe-val kapcsolatban, indoklásul álljanak itt a következők:

Alig egy héttel az után, hogy kártékony rakománnyal közlekedő, az elterjedt hardening megoldásokra fittyet hányó Adobe Reader exploitról érkezett jelentés, most a Flash Player egyik 0day hibájára szálltak rá a támadók. A probléma a lejátszó által támogatott összes platfromot érinti (Androidosok, szevasztok!) a szoftver 9-es és 10-es főverziójában is. További technikai részletekkel most sajnos nem szolgálhatok, de az érintett verziókról részletes leírást találtok a hivatalos tanácslatban.

Az Adobe a szeptember 27-i hétre ígér javítást a Player problémájára, a Reader foltjára pedig legalább október 4-ig várnunk kell. Jó tudni ugyanakkor, hogy utóbbi probléma Windowson megelőzhető a Microsoft új Enhanced Mitigation Experience Toolkitjának segítségével.

Múltkor bemutattam, hogy hogy kell pocsék marketingkampányt keríteni egy IT-biztonsági termék köré. Most megmutatom, hogyan kell ugyanezt jól csinálni:

Aktívan kihasznált javítatlan Adobe Reader sebezhetőséget fedeztek fel két napja több biztonsági cég szakemberei is. A problémát a cooltype.dll helytelen TTF betűtípuskezelése okozza, mivel a program egy 256 byte hosszú bufferbe akar bepakolni egy ellenőrizetlen, felhasználó által szolgáltatott adatot. A felfedezett exploit heap spraying és ROP technikákat alkalmazva megkerüli az ASLR és DEP nyújtotta védelmet, így a kártékony PDF dokumentum odavág a Windows Vistáknak és a 7-eseknek is. Jelenleg az egyetlen (részleges) védekezési módot a JavaScript kikapcsolása jelenti, azonban megjelenhetnek JS-t nem igénylő kártevő variánsok is.

A problémáról és a vadon talált exploitról részletes elemzés olvasható itt és itt.

Ma két FreeBSD sebezhetőségekkel foglalkozó levél is érkezett a Full-Disclosure listára: 

Przemyslaw Frasunek NULL-pointer dereferenciát okozó hibát fedezett fel az operációs rendszer régebbi, 7.0-7.2 és 8.0 változataiban, a fájlrendszerek pseudofs attributumának kezelésében. A probléma egy pseudofs attributummal rendelkező fájlrendszerre kiadott extattr_get_attribute() hívás során jelentkezhet a pfs_unlock() és psf_attr() metódusok helytelen hívása miatt. A hibát javították a FreeBSD legújabb változataiban, a bugot viszont nem értékelték biztonsági hibaként. Przemyslaw ugyanakkor ígérete szerint két hét múlva ki fog adni egy erre a problémára építő, helyi jogosultságkiterjesztésre alkalmas exploitot.

Maksymillian Arciemowicz egy helyi DoS támadásra alkalmas, versenyhelyzetből adódó problémát fedezett fel a vm.pmap kernelparaméter(-struktúra) kezelésében. A hiba kihasználásához több felhasználóval kell nagy számú folyamatot elindítani, így átléphető a kernel számára beállított maximális folyamatszám. A probléma a legfrissebb kiadásokat (is?) érinti.

Az Errata Security érdekes cikket jelentetett meg az iPhone-ok WiFi kezelési szokásaival kapcsolatban. Ha egy iPhone-nal rendelkező bitbűvész elkezdni sniffelni a telefon vezetéknélküli-hálózati forgalmát, hamar kiderül, hogy egy új hálózatra történő csatlakozáskor a készülék a http://www.apple.com/library/test/success.html weboldalt próbálja meg elérni, mindenfajta felhasználói utasítás nélkül. Erre azért van szükség, mert sok helyen működnek ún. captive portalok, melyek csak hitelesítés után hajlandóak kiengedni az újonnan csatlakozó felhasználókat az internetre, így ha csak a levelezőkliensnek lenne szükséges a hálózat, de az iPhone nem az elvárt választ kapja az Apple.com-tól, automatikusan megjelenik egy Safari ablak, melyben a felhasználó bejelentkezhet. 

A kérés részletesebb vizsgálatakor kiderül az is, hogy ennek az első HTTP kérésnek a UserAgent fejlécében szerepel a "wispr" string, ami a Wireless Internet Service Provider roaming protokollra utal. Az ezt átmogató portálok ill. AP-k érzékelik ezt a fejlécet, és egy XML üzenetváltás segítségével automatikusan hitelesítik a felhasználót. 

Vegyük észre, hogy a teljes forgalom nyílt HTTP csatornán zajlik!

• Captive portal jelenléte esetén a Safari ablak mindenképpen felpattan, egy közbeékelődő támadó pedig olyan exploitot plántál az oldalba, amilyet szeretne.
• Az XML üzenetekben küldött bejelentkezési azonosítók passzívan lehallgathatók
• A programozók imádják elszúrni az XML feldolgozást

A felhasználó pedig még mindig nem csinált semmit, csak csatlakozott egy WiFi hálózathoz.

De az iPhone üzeneteiben történő vájkálás közvetlen pozitív hasznot is eredményezhet: Az AT&T hálózatának használata az Államokban ingyenes az iPhone tulajdonosoknak. Az iPhone (felteszem ESSID alapján) ilyen HotSpotokon a http://attwifi.apple.com/library/test/success.html oldalhoz csatlakozik első körben, amit feltehetően érzékel a captive portal, és automatikusan beengedi a felhasználót. Nem tudom, hogy itthon van-e hasonló kedvezmény, de ha igen, érdemes lehet belelesni a szifonok forgalmába!

 Csak röviden: a TechCrunch Európai oldalai Zeus igájába taszítják a látogatók gépeit. Az üzemeltetők már napok óta tudnak a dologról, de téves riasztásként értékelték az esetet, így nem állították le az oldalt. A letöltődő malware variánt a VirusTotal adatbázisában szereplők közül csak két antivírus termék fogja meg!

(Avagy erre a címre tuti kapok néhány tucat Google találatot)

A Meta Rhein Main Chaos Days 111b minikonferencián Alexander Klink egy olyan módszert mutatott be, melynek segítségével némi social engineeringet és MitM támadást bevetve távolról bekapcsolható a Flash Player felhasználók mikrofonja és kamerája. 

A problémát a Macromedia.com-on elérhető Settings Manager okozza: ez a szolgáltatás nem más, mint két egymásba épülő SWF applet egy HTML oldalba ágyazva, melyek  közül a legbelső dokumentálatlan API hívások segítségével közvertlenül módosíthatja a látogató Flash Playerének beállításait (figyeljetek, egyes appletek egyenlőbbek a többinél!). Bár ez a belső applet hitelesített HTTPS csatornán töltődik le a felhasználóhoz, az áldozat gépén futó szoftver csak a felhasználóra hagyatkozik a tanúsítvány ellenőrzésekor, aki vagy figyelmen kívül hagyja a böngészőtől kapott figyelmeztetést, vagy nem (lehet tippeket tenni), előbbi esetben a letöltődő applet megnyitja a multimédia eszközöket a nagyvilág számára, és már el is lehet kezdeni streamelni a műsort.

A pontos hogyanokról a slideshow sajnos nem tesz említést, de a fentieken kívül rejt még egy vicces érdekességet, ezt mindenki nézze meg maga!

Bizonyára mindenki tudja, hogy az idei Hacktivity egyik keynote előadója Bruce Schneier lesz. Az azonban engem is meglepetésként ért, hogy a neves biztonsági szakértő egy nappal a konferencia előtt a BME-n is tart majd egy előadást, melynek témája a "Biztonság újraértelmezése" lesz. Szóval aki nem tud eljönni konferenciára, az is kaphat egy kis kárpótlást szeptember 17-én 15:00-tól, a BME I épületének IB017-es előadójában. 

A Hacktivityt csak emiatt természetesen vétek kihagyni! Köszönet Stefnek az infóért!

trey@HUP:

Chris Evans, Google egyik biztonsági szakértője a full disclosure levelezési lista nyilvánosságához fordult [hivatkozás tőlem] egy eddig még javítatlan Internet Explorer 8 buggal kapcsolatban. Levele szerint azért tette ezt, mert eddig sikertelenül próbálta rávenni a Microsoft-ot a hiba javítására. A biztonsági problémára egy PoC-t is publikált. Az Internet Explorer 8-ban jelenlevő bugot kihasználva a weben keresztül támadást intéző képes lehet az IE felhasználók 3rd party oldalahoz tartozó authentikált session-jeit eltéríteni (például egy tetszőleges weboldal ráveheti a felhasználót, hogy az postázzon ki egy tweet-et a Twitter-re). Chris szerint bizonyítékok vannak arra, hogy a Microsoft 2008 óta tud a hibáról, de javítani azt még nem javította.

A PoC megvalósítás itt érhető el (gombnyomásra üzenetet helyez el a Twitteren, ha van aktív session). Evans eredeti bejegyzése a problémáról itt olvasható.

Régen volt szó hardver hackekről, most viszont egy igazi csemegét szállított a Hack-a-Day! Adrian Crenshaw egy vonalkód fuzzert készített a Teensy fejlesztői boardra, amely mindössze egy LED kimenettel képes tetszőleges vonalkódot mutatni a fényvisszaverődést alapul vevő leolvasók felé. A módszer lényege Nathan Pegramtól származik, aki a Pauldotcom podcast egyik adásában vetette fel, hogy az egyszerű, egydimenziós kódok (ami a sörösdobozon is van) leolvasói "átverhetők" úgy, ha az olvasó saját fényforrása helyett egy sajátot használunk. Minden az időzítésen múlik: egyszerűen olyan ütemben kell felvillantani a LED-et amilyen ütemben a leolvasó fénysugara elsuhanna a vonalkód fehér részei fölött. A leolvasó ugyanis a fényvisszaverődést érzékeli, ami nyilvánvalóan elsősorban a fehér felületeken érvényesül.

De a dolog lényege nem is az ilyen jellegű átverés, hanem az olvasót használó szoftver megbolondítása: Adrian kütyüje például autómatikusan lejátssza az ASCII tábla első 31 elemét, valamint néhány hagyományos támadási mintát (pl. egyszerű SQL injectionre vagy XSS-re), hátha a tisztelt programozók nem gondoltak rá, hogy valaki ilyen jeleket vagy karaktersorozatokat is beleírhat egy vonalkódba. 

A mikrokontroller programjának forráskódja természetesen szabadon elérhető, így bárki tesztelheti a helyi közértet, csak nehogy infarktust kapjon a pénztáros néni! Adrian tervei között szerepel még az eszköz továbbfejlesztésse E-Ink alapon, de az ehhez potenciálisan használható e-könyv olvasók egyelőre túl drágák. 

Remélem születnek majd hasonlóan ügyes apróságok a Hacktivityn is!

A Symantec - talán a Pwnie-díjak között már sokadik éve kiosztott "Legjobb Dal" kategória sikerén felbuzdulva - új marketingkampányba kezdett. A neves biztonsági cég a neves gengszterrepper Snoop Doggal karöltve arra buzdítja a szövegben erős fiatalokat, hogy késztsenek rap számokat, melyekkel az interneten leselkedő veszélyekre hívják fel a figyelmet. Alább látható a zenésszel készült spontán interjú:

Az akció akkora sikert aratott, hogy a hét elején indult weboldalra már fel is töltöttek hét (7) darab videót - ráadásul az oldalt egy időre le kellett kapcsolni a rajta talált XSS hibák miatt! A szerencsés nyertes koncertjegyet és laptopot nyerhet, valamint találkozhat Snoop Dogg menedzsmentjével is!

A Forbes bloggere felhívja a figyelmet (további facepalmok reményében érdemes kattintani), hogy nem ez volt az első kísérlet a szoftver- és a rap-ipar összeboronálására.Az alábbi, 1992-ben készült, közel 10 perces (!!!) videót csak erős idegzetűeknek ajánlom:

Bocs a minőségi posztok hiányáért, erősen gyúrunk Hacktivity-re, ott megkapjátok a pótlást ;)

Mától lehet regisztrálni az Informatikai Biztonság Napjára. A sajtóközleményből (kiemelések tőlem):

Mérföldkőhöz érkezett az „Informatikai Biztonság Napja”, amely 2010. szeptemberben 28-29-én két napos IT biztonsági konferencia és kiállítás lesz. A több mint 1200 IT biztonsági szakembert a tavaly már jól bevált – helyszínre, a Cinema City Arénába várják  Idén először ítélik oda a rendezvényen az „ITBN Security Award”- díjat a szakma legjobb vállalkozásainak és kiemelkedő személyiségeinek.  . A támogatók jóvoltából a rendezvényre történő bejutás regisztrációhoz kötött, térítésmentes. Az innováció fontosságát szeretnék hangsúlyozni a szervezők, ezért a nagy Magyar feltalálók, és találmányok állnak ebben az évben a fókuszban