SGHCToma jóvoltából elolvashatjátok az idei Hacktivity CTF pályáinak részletes megoldásait:

• A selejtezőn (itt került kiválasztásra a legjobb 10 csapat) egyetlen gépet kellett root-ra törni. Ehhez  először is túl kellett lendülni azon, hogy a gépen kilátszó webszerver első szembe jövő belépési felületén egy "nem kihasználható SQL injection" (najó, egy csapda) rejtőzik. Ez után tovább túrva egy alap CGI hacket kellett végrehajtani tetszőleges felhasználó szintű fájlolvasás eléréséért (ez már ért pontot). Ez azonban nem feltétlenül járt együtt felhasználói szintű kódfuttatással: ennek eléréséhez egy kis Perl manual olvasgatás, valamint némi *NIX shell szkriptelési ismeret szükségeltetett. Innen a root szintű jogosultság megszerzéséhez, egy rosszul megírt SUID root binárist kellett megszerezni, majd ezen keresztül egy sima stack overflow-val tetszőleges kódfuttatást elérni. 

A döntőben megjelent csapatoknak a következő démonokkal kellett megküzdenie:

• Jose Luis Torrente egy Linux-os gép volt, amit a legtöbb csapat eleinte meg sem talált, ugyanis egyetlen elérhető szolgáltatása nem TCP-n, hanem UDP-n figyelt. Ez egy TFTP-szerű szolgáltatás volt, amivel történetesen le lehetett tölteni magát az UDP-n figyelő binárist is, melynek disassemblyjében megtalálható volt egy sebezhető függvény, melynek hibáját egy kis ROP-olással lehetett kihasználni.
• Firefly egy Windows 7-es gép volt, melyen figyelt egy webszerver, meg egy furcsa szolgáltatás a TCP/1337-en. Itt a boldogsághoz ki kellett volna találni a mérhetetlenül bonyolult admin:admin123 belépési kombinációt egy webes űrlaphoz, ami után egy sima PHP fájlfeltöltéssel lehetett felhasználói szintű parancsokat végrehajtani. A 1337-en futó szolgáltatás Adminisztrátori fiókkal, DEP-el, és jórészt ASLR nélkül futott, így a bináris letöltéste, és visszafejtése után ismét egy ROP-os exploittal lehetett Administrator jogot szerezni - ezúttal Windows-on.
• NagyonKígyó egy OpenBSD volt - és ehhez sem kellett drága 0day ;) Itt is a weben kezdődött a móka, csakhogy a kommunikáció TLS-be bugyolált JSON-RPC-vel, egy Java appleten keresztül zajlott. A szerver oldalon találhotó Python szkript forrása a szolgáltatáson keresztül letölthető (miután a TLS-ben közlekedő adatok formátumát sikerült megszimatolni), és rövid kódanalízis, valamint egy kis bash-fu után az egyszeri hacker képes felhasználói szinten parancsokat kiadni. A root-hoz szintén egy Python szkriptet kellett megbűvölni, méghozzá egy szerializált objektum lecserélésével: a cPickle modul körültekintés nélkül történő használata ezúttal korlátlan parancsfuttatást eredményez.

Ezek a feladatok nem földtől elrugaszkodott szituációkat modelleztek, a megoldásokhoz csak az aktuális szakirodalmat kellett fellapozni, valamint gondolkodni egy kicsit (najó, néha sokat). Minden esetre Toma leírásaiból is látható, hogy a feladatok alapvetően megoldhatóak voltak, bár az idő szűkös volt. Az eredmények szerint:

• Jó néhányan a Next->Next->Hack filozófiát követve használják az eszközeiket, anélkül, hogy bekonfigurálnák azokat
• A find parancs használata, illetve az olyan fekete mágiák, mint a $( ) még mindig sokakanak problémát okoz
• Több (leendő) mérnök nem hajlandó megmérni, hogy valójában mi is megy a hálózaton egy hálózati program debugolásakor
• Az örökérvényű négybetűs bölcsességet - RTFM - a legtöbben nem szívlelik meg eléggé
• Az admin123 jelszó hiányzik néhány népszerű szótárból

Ezek alapján még mindig meleg szívvel ajánlom mindenkinek a Hacker HOWTO-t, Raymond bácsi nem írt hülyeségeket!

Ezúton is gratulálok a kivételt adó, CTF-et két éve torony magasan nyerő PRAuditors csapatnak, szép munkát végeztetek!

Végezetül néhány szóban a Wargameről:

Srácok, a weben túl is van élet! A Wargame pályák a fentieknél jóval egyszerűbbek voltak, mégsem volt képes megcsinálni őket két éve senki - ilyen hozzáállással kár Hacktivity-re járni. A megoldásokat rövidesen közzétesszük, mindenki okulására.

Ez annyira fájdalmas, hogy muszáj kiraknom: A fiatal tehetségek támogatása mindig szép gesztus egy-egy vállalat részéről, ezeket a kezdeményezéseket én is mindig szívesen propagálom. Nem rég megosztottam Twitteren az idei Ericsson programozóbajnokság kiírását, amire nem sokkal későb ptZool válaszolt egy meglepő és mulatságos linkkel:

Azt, hogy a dolognak van-e biztonsági vonzata, nem ellenőriztem, de nem lennék meglepve...

A szeptemberi meetup kapcsán elkezdtem egyre többet foglalkozni a BeEF-fel, aminek az lett az eredménye, hogy felvettek a commiterek közé, és rögtön a nyakamba is akasztottak egy feladatot: az Inter-Process Expolitation/Communication modulok közül a "POSIX" változatot kellett működésre bírnom. 

De mi is az az IPEC? A válasz részben ebben a régi leírásban, részben egy azóta már az Internet süllyesztőjébe veszett doksiban keresendő - de én inkább a forráskódot választottam :) A kiindulási pont az, hogy (mondjuk egy XSS hibán keresztül) képesek vagyunk JavaScriptet futtatni egy tűzfal mögött ülő áldozat böngészőjében. A tűzfal mögött van egy szigorúan nem-HTTP szolgáltatás, pl. IMAP vagy egy bindshell. Az IPEC lényege az, hogy a protokollmegvalósítások engedékenységét kihasználva (ebben az esetben) HTTP-be tudjuk csomagolni a különböző IMAP illetve shell parancsokat.

A dolog elsőre triviális:

GET /index.html?&ls; HTTP/1.1
Host: 192.168.1.100:4444

Egy egyszerű GET kérést küldve egy nyitott bindshellnek, a kérés &-ig tartó, illetve ; utáni részei értelmezhetetlen parancsként hibát dobnak, míg az ls parancs lefut. Az első probléma akkor jelentkezik, amikor URL-ben nem engedélyezett karaktereket szeretnénk küldeni - ezeket ugyanis az áldozat böngészője rögtön URL-kódolja, ami nem fog tetszeni a shellnek. Ezen az apróságon azonban viszonylag egyszerűen túllendülhetünk, ha az űrlap adatokat multipart POST kérésként küldetjük el, ilyenkor ugyanis az általunk kontrollált üzenet rész (nagyrészt) kódolatlanul kerül be a HTTP kérés törzsébe:

POST / HTTP/1.1
Host: 192.168.1.100:4444

Content-Type: multipart/form-data; boundary=Xx1337xX

--Xx1337xX
Content-Disposition: form-data; name="submit-name"

;ls -la > /var/www/ls.html ;

--Xx1337xX

A komolyabb probléma, hogy hogyan kapom meg a visszaadott adatokat? A fenti példában ugyan megpróbálom kitolni egy DocumentRoot-ba az eredményt, de ez egyrészt nem biztos, hogy lehetséges, másrészt még mindig nem látok be a tűzfal mögé. 

A megoldás itt kevésbé magától értetődő: Készítsünk egy IFRAME-et, benne egy FORM-mal, ami el fogja küldeni a parancsainkat! A parancsokat úgy kell megfogalmaznunk, hogy a bindshell egy szabályos HTTP választ adjon vissza (fejlécekkel, sortöréssel) , hiszen másként az áldozat böngészője jó eséllyel nem fogja feldolgozni az adatokat. Ezzel elérhetjük azt, hogy a parancs eredménye betöltődjön az IFRAME-be, mintha csak egy rendes webszerver válaszolt volna. Az IFRAME-en kívüli kód (ami vissza tudna szólni nekem) azonban nem tudja kiolvasni az IFRAME tartalmát, így ismét trükközni kell: generáltassunk a bindshellel a parancs eredménye után egy JavaScript kódot, ami a window.location paramétert úgy írja át, hogy az tartalmazza a parancs kimenetét:

<div id="ipc_content">
/bin
/boot
/dev <!--...stb...-->
</div>
<script>window.location=parent+'#ipc_result='+ \  encodeURI(document.getElementById('ipc_content').innerHTML);</script>

Mivel az IFRAME-et létrehozó szkript hozzáférhet az IFRAME által mutatott aktuális címhez, a parancs kimenete is hozzáférhetővé vált!

A történet persze tovább bonyolódik, ha kevésbé megengedő, vagy összetettebb szintaktikájú parancsfeldolgozóhoz szeretnénk hozzáférni, de az infromáció kicsatornázásának fenti módja szerintem mindenképpen figyelemre méltó, másrészt pedig nem biztos, hogy szükségünk van a kimenetekre, ha mondjuk csak egy tűzfalszabályt írunk át.

Sajnos úgy érzem, nem lehet tovább halogatni, hogy a Julian Rizzo és Thai Duong által helyi idő szerint pénteken, az argentín Ekoparty konferencián prezentált SSL/TLS támadásról írjak, annak ellenére, hogy még mindig nem tudni pontosan, mit is hozott össze a két kutató.

Minden esetre már megjelent néhány igen hasznosnak tűnő összefoglaló, melyek nagy vonalatkban körüljárják a támadás főbb jellegzetességeit. Az első és legfontosabb, hogy Rizzo és Duong egy majd' tíz éve ismert, választott nyílt szöveg alapú támadásra mutatott egy proof-of-concept megvalósítást - ez lett a BEAST. Az eredeti probléma gyökere az, hogy a TLS 1.0-t használó böngészők CBC módban az utolsó üzenet utolsó blokkját használják a következő üzenet IV-jeként, vagyis a különböző HTTP kéréseket egy hosszú plaintext üzenetté fűzték össze. Nem CBC-módban használt blokktitkosító, illetve a folyamtitkosító használatát kikényszerítve elkerülhetjük a támadást.

A támadás lényege az, hogy egy támadó képes ellenőrizni, hogy egy adott titkosított blokk nyílt szövege megegyezik-e egy általa megtippelt értékkel: Tegyük fel, hogy a támadó tudja, hogy Alice jelszava utazik az M_i blokkban (ezt a támadó titkosítva, C_i-ként látja)! A támadó nem tudja megfejteni ezt a blokkot, viszont meg tudja jósolni az következő IV-t (ez legyen X), valamint rá tudja kényszeríteni Alice-t, hogy küldje el az

X + C_(i-1) + P

üzenetet, ahol P a támadó által megsejtett jelszó, a + a bitenkénti XOR-t jelöli, C_(i-1) pedig a M_i üzenet előtt küldött kriptoszöveg. Amikor a rejtjelező XOR-olja ezt az üzenetet a következő IV-vel, az X kiesik. Amennyiben pedig P=M_i (vagyis a támadó helyesen tippelt), a titkosítás után C_i kell legyen az eredmény.

Ez a támadás jól láthatóan viszonylag erős támadói modellt feltételez. Rizzo és Duong érdeme abban áll, hogy praktikus támadási szcenáriót sikerült mutatniuk, mégpedig az egyik legelterjedtebb felhasználási módra, a webböngészésre.

A támadshoz olyan technológáik használhatók, amelyek megengedik tetszőleges bináris adat átvitelét, úgy mint a Java, vagy a HTML5 WebSockets. Utóbbi esetben a HTTP kliens és szerver előzetesen meg kell, hogy egyezzen a WebSocket használatban, a kézfogás során pedig átvitelre kerülhet a kliens sütije is. Ha feltételezzük, hogy már a kézfogás egy részét is irányítani tudja a támadó (pl. a szerveren belüli útvonal megadásával), elérhető, hogy az egyik üzenetblokk végén csak a süti első bájtja szerepeljen. A blokk maradék része ekkor egyszerűen jósolható (sima HTTP fejlécekről beszélünk), ezért a támadó a fenti módszerrel néhány száz kérésből képes kitalálni a bájtot. A következő lépésben egyel csökkentve a konrollált üzenetrész méretét a süti következő bájtja következhet, és így tovább.

Hogy mindennek milyen hatása lesz a mindennapi életünkre? Várhatóan nem sok. A támadás eleve egy közbeékelődéses szituációt feltételez, ekkor pedig jóval hatékonyabb módszernek tűnik belőni egy SSLStripet. A böngészőgyártók már tesztelik azokat a foltokat, melyek segítségével a kompatibilitást megtartva kiküszöbölhetőek az ilyen jellegű protokolltámadások, és a Tor felhasználók is megnyugodhatnak. A bejelentéstől függetlenül egyébként a WebSocket specifikációt időközben úgy módosították, hogy az újabb implementációk már jóval nehezebben használhatók fel ilyen kriptós trükkökre.

Abból a szempontból viszont a kutatás mindenképpen hasznos lesz, hogy végre talán megadja azt a rég óta várt lökést a különböző SSL/TLS könyvtárak gyártóinak és felhasználóinak, hogy végre teljes támogatást adjanak a TLS 1.1-es és 1.2-es, megerősített változataihoz. És akkor jövőre valaki majd megint készíthet egy ütős prezit a downgrade támadásokról :)

Frissítés: A cikk és a referencia implementáció letölthető innen (link frissítve).

0xFF projektjét szeretném a figyelmetekbe ajánlani, amin még biztosan van optimalizálni való (pl. spóroljuk meg a várakozást azáltal, hogy "belepörgetünk" az SWF-be ;), de maga az ötlet és a megvalósítás igazi "buherálós", egyszerű komponensekből összeállított, ötletes megoldás:

"After numerous requests we have finally released a completely new Dracon Flash CAPTCHA v2.1 for your everyday use. It addresses OCR attacks and comes with a fully AJAXed test email form with anti-hammering measures and facilitates a 128bit AES encryption between PHP and Flash."

Nem az implementációt akartam kijátszani hanem magát a ötletet, mert olyan szépen hullámzik szinte kacérkodik.

Cél : Teljesen automatizálni a captcha megoldását, 0 emberi interakció.

(szerkesztve általam)

Klikk ide a részletekért!

syddd küldte az alábbi érdekességet:

Arról van szó, hogy sok Flash alapú applikáció AMF protokollal kommunikál a szerverrel. Ennek a protokollnak a legelterjedtebb implementációja az AMFPHP csomag. Ebben van egy "service browser" nevű alkalmazás, amit fejlesztéskor lehet használni arra, hogy tesztelje (és listázza) a szerveren található metódusokat.  Persze az AMFPHP manualjában benne van, hogy ezt ki kell törölni mielőtt élesítik a rendszert, csakhát ezt sokan elfelejtik.. így egy szimpla Google kereséssel megtalálható a service browser: "amfphp/browser/servicebrowser.swf" 

Utólagos engedelmével (mivel a levelet eldobható címről kaptam) a dorkot beküldtem GHDB-re is, ugyanis ott még nem szerepelt hasonló rekord.

Nem rég egyébként az FTC úszó szakosztályának honlapjához tartozó admin felület kapott némi védelmet, miután ScottAnyó ügyesen guglizott, majd értesítettük az üzemeltetőt.

És ha már itt tartunk, szeretném megköszönni Kardhal, Paradox, Detritus és Zorg, a Rettenetes munkáját is, akik egy-egy SQL injection felfedezésével tették biztonságosabbá a magyar a webet!

 Az Adobe tegnap rendkívüli frissítést adott ki a Flash Player 10-es főverziójához, melyben összesen hat hibát javítanak, melyek közül egyet aktívan kihasználnak célzott, és feltehetően valamely állam által szponzorált támadásokhoz. Utóbbi hiba kissé meglepő módon egy "egyszerű" XSS sebezhetőség, tehát nem valamilyen memória-korrupciós lehetőségről van szó. 

Az Adobe-al párhuzamosan a Google is frissítette a Chrome böngésző beépített lejátszóját, tehát ezt a szoftvert is érdemes frissíteni. 

Végül bejelentették a Flash Player 11-es verzióját, amely a funkcionális újdonságok mellett magánszféra-védelmi, illetve biztonsági újdonságokat is tartalmaz. Utóbbiak közül a leglényegesebb az SSL kapcsolatok támogatása, melyet a szoftver új, az operációs rendszer kriptográfiai API-ját használó véletlenszám-generátorral támogat. Ezen kívül, mivel az új verzió támogatni fogja a 64-bites architektúrákat is, az ASLR hatékonysága is nagyobb lesz ezeken a rendszereken.

Irán nem a legvidámabb hely, ha az ember mondjuk nőjogi aktivista, reformpárti blogger, vagy esetleg lelkes pornórajongó. Így nem csoda ha több tízezer iráni a Tort használja internetes kommunikációjának védelmére. Az ország internetszolgáltatója azonban tegnap egy ügyes tűzfal szabállyal sikeresen blokkolta az onion routerek illetve bridge-ek felé menő forgalmat: a Tor ugyan igyekszik egyszerű webes HTTPS-nek álcázni a forgalmát, a cenzorok rájöttek, hogy a használt tanúsítványok lejárati ideje a szokásosnál jelentősen rövidebb, mindössze néhány óra, és az ilyen tanúsítványokat használó kiszolgálók felé menő forgalmat nem engedték tovább a TLS kézfogás után. 

A Tor Project 24 órán belül reagált a problémára: az új relay szoftver most már egyszerűen hosszabb lejárati idejű tanúsítványokat generál a csatlakozó kliensek számára. A fejlesztők megjegyzik ugyanakkor, hogy macska-egér játékról van szó, hiszen még számos egyéb módszer létezik az anonimizáló szoftver forgalmának detektálására. A kérdés az, hogy megéri-e ezek fejlesztésére energiát fordítani, amíg nem jelentkezik egy újabb blokkád?

És ha már Iránról beszélünk, emlékeztetnék mindenkit, hogy a DigiNotar incidens is egy iráni felhasználó gyanakvása nyomán derült ki, és a Comodohacker nyilatkozata alapján is valószínűsíthető, hogy az illetéktelenül kiállított tanúsítványok végül a Forradalmi Gárdánál landoltak, de az sem kizárt, hogy egyenesen egy államilag támogatott akcióról volt szó.

Aki ma le szerette volna tölteni az uTorrent-et, az azzal szembesülhetett, hogy nem járt sikerrel, hiszen amit letöltött uTorrent telepítő néven, az minden volt, csak nem torrent kliens. A rosszabbik hír, hogy ráadásul az állomány egy trójait tartalmazott, ami így felkerülhetett a torrentezők számítógépére.

A letöltött állomány tehát nem az uTorrent 3.0 szeptember 13-i kiadása, hanem egy secureshield nevű trójai, egészen pontosan win32/Kryptik.SSY trojan. (XP stílusú ál anti-vírus malware).

[...]

közben megszületett a BitTorrent Inc. hivatalos reakciója: http://blog.bittorrent.com/2011/09/13/security-incident/

Az uTorrent.com és a többi weboldal is ismét működik. A cég sűrű elnézések között elmondja azt, amit kb. már tudtunk. Helyi idő szerint 4:20-kor betörtek a cégek szervereire, és ott az uTorrent telepítője helyére egy malwaret helyeztek el. Szintén helyi idő szerint 6:00-kor kapcsolták le az érintett gépeket, majd elkezdték kivizsgálni az esetet. Úgy tűnik egyébként, hogy a BitTorrent.com, illetve a BitTorrent Mainline/Chrysalis kliensek nem voltak érintettek a fertőzéses ügyben.

A teljes cikkért kattanjatok az ASVA.info-ra!

A Microsoft kiadta szeptemberi frissítőcsomagját, amely összesen 5 bulletint tartalmaz, és főleg kliens oldalon kritikus hibákra fókuszál. Redmond ebben a hónapban (végre) kereső- és felhasználóbaráttá tette a biztonsági frissítések URL-jeit, valószínűleg ezzel áll összefüggésben, hogy az összefoglalók már a múlt héten, a konrét frissítések megjelenése előtt öt nappal véletlenül kiszivárogtak.

• MS11-070: A WINS szolgáltatás hibája jogosultságkiterjesztést tesz lehetővé a Windows támogatott szerver kiadásain (2003, 2008), kivéve Itanium. A probléma kihasználás elég trükkösnek ígérkezik: Amennyiben nagy mennyiségű adatot küldünk a WINS szolgáltatásnak, elérhetjük, hogy egy általános esetben foglalás nélkül meghivatkozott memóriaterület is allokációra kerüljön. Ilyenkor kontrollt szerezhetünk az EDI regiszter felett, melyet a program később pointerként használ egy érték dekrementálására. A hiba részletes leírása itt olvasható, linkekkel a PoC kódra. A Core Security figyelmeztetése (szintén PoC kóddal) itt olvasható.
• MS11-071: DLL hijacking probléma több Windows komponensben. A probléma távoli kódfuttatásra ad lehetőséget, amennyiben egy felhasználó egy támadó által birtokolt hálózati megosztásról nyit meg .txt, .rtf, vagy .doc fájlokat. A hiba független az Office programcsomagtól és a Windows összes támogatott verziójában jelen van. 
• MS11-072: Öt hibajavítás az Excel asztali és webes változataihoz, illetve a SharePoint Excel Services szolgáltatásához. Utóbbi esetben Excel fájlok feltöltésével érhető el kódfuttatás, előbbi esetben a szokásos, tipikusan böngészőn vagy e-mail csatolmányon keresztül elért támadási szcenáriókban lehet gondolkodni. 
• MS11-073: Két hibajavítás az Office-hoz. Az egyik hiba egy összes tartalmazott irodai szoftvert érintő DLL hijacking sebezhetőség, a másik egy Word specifikus, inciálizálatlan pointerhasználatból eredő probléma. 
• MS11-074: Öt hibajavítás a SharePointhoz. A hibák egyrészt információszivárgásra (XML injection), másrészt jogosultságkiterjesztésre adnak lehetőséget tipikus webes hibákon - XSS-en és CSRF-en - keresztül. A hibák kihasználásához minimális social engineering vagy érvényes felhasználói jogosultság szükséges. További információk, PoC-k: itt és itt.

A cég a fentieken túl nem-biztonsági frissítésként bővítette a megbízhatatlannak ítélt CA-k listáját, nyolc köztes DigiNotar szolgáltatóval. A feketelista most már tartalmazza a holland kormányzatot kiszolgáló PKIoverheidot is.

Figyelmeztető üzenet jelenik meg a Linux.com és LinuxFoundation.org oldalakon, valamint összes aldomainjükön, mivel az üzemeltetők szeptember 8-án illetéktelen behatolást észleltek a rendszereken. A kiszolgálókat teljesen újrahúzzák, mielőtt újra csatasorba állítanák őket.

Az incidensek valószínűleg kapcsolatban állnak a kernel.org-ot ért támadással - utóbbi site 10 napja áll, a Linux kernel forráskódját pedig ideiglenesen a GitHub-ra kellett költöztetni. 

Gyors játékot hírdetek azoknak, akiknek még nincs jegyük az idei Hacktivity-re (ejnyebejnye). Az alábbi kérdésre leggyorsabban helyes választ adó kommentelő egy 100% kedvezményt biztosító kuponkódot kap, melyet a hacktivity.com jegyrendelés menüpontjában használhat fel szeptember 14-ig.

A kérdés: Melyik városban tartották meg az első Hacktivity-t?

Ügyeljetek arra, hogy a kommenteléshez használt nickhez olyan e-mail cím tartozzon, amit rendszeresen olvastok, ugyanis erre a címre fogom küldeni a kódot!

És meg is van a nyertesünk :)

Mircbugger küldte az alábbi levelet a wap.menetrendek.hu (van aki még WAP-ol?) üzemeltetőjének. Egy elég egzotikus hibáról van szó, amely egy kis továbbgondolással feltehetően kódfuttatásra is alkalmas lehetett volna. A problémát azóta úgy tűnik, már javították:

Tisztelt WebMester!

A wap.menetrendek.hu-val kapcsolatban írnék, mégpedig arról, hogy szerintem a szerveroldali szkriptek valószínűleg sebezhetőek a forráskódban az uid mező átírásával a következőképpen:

Annyit kívülről is látni, hogy az "uid" egy fájlra mutat és ha az nem létezik, hibaüzenetet ír a szkript, melyből ez kiderül, ahogy látható [az alábbi] képen.

Mivel a fájlelérés nincs levédve a könyvtárak közötti visszalépéstől (../../) így egyfelől elképzelhető olyan fájlokhoz való hozzáférés, melyekhez kívülállónak nem szabadna hozzáférnie, másfelől felveti egy DoS támadás lehetőségét, amennyiben a fájlból olvasott érték vagy kódrészlet nincs megfelelően felülvizsgálva és méretre korlátozva. Példa:

<anchor title="Teleplista">OK<go href="wml.cgi" method="post">
<postfield name="action" value="match"/>
<postfield name="uid" value="../../../dev/urandom"/>
<postfield name="beirta" value="$(honnan_i)"/>
</go></anchor>

Itt ha a CGI szkriptben egy while(<FILEHANDLE>) ciklussal olvasunk, végtelen ciklus lesz belőle és megvalósul a DoS támadás, ráadásul a memóriát is kitelítheti a program, ha minden olvasott értéket tárolunk. Amennyiben ezutóbbi átírást alkalmazzuk, és a form-ot post-oljuk, a szerver [az alább] látható hibát produkálja és utána nem is áll helyre.

A megoldás: Minden mező beolvasásakor regexppel kell validálni az értékeket, például az uid-nél a regex: [0-9]{10}\.[0-9]{5} és csak akkor szabad tovább folytatni a műveletet, ha megfelelt. Így elképzelhetetlen, hogy a "../../"-t tartalmazó sztringek értelmezésre kerüljenek és az uid mező kéretlen fájlra mutasson.

Ezt a levelet azért írtam, hogy a hiba mielőbb kijavításra kerüljön, a szerverre nem törtem be, nem loptam el semmilyen információt.

Üdvözlettel

Egy informatikus kolléga

Néhány szolg. közlemény a hibajelentésekkel kapcsolatban:

• Sokan küldtetek be eddig ki nem került jelentéseket, ezekről nem feledkeztem meg, előbb-utóbb ki fognak kerülni
• A GPG nyilvános kulcsom letölthető a coming out oldalról

Tovább gyűrűzik a DigiNotar ügy, naponta látnak napvilágot újabb és újabb információk az esettel kapcsolatban. 

A szervezet örökre lekerül a Mozilla, a Google és a Microsoft megbízható tanúsítókat gyűjtő listáiról, a példát pedig követte a holland kormány - melynek a DigiNotar hivatalos szállítója volt - és át is vette az irányítást a szervezet felett.

Közben megjelent az incidenssel kapcsolatban egy független biztonsági jelentés előzetes változata. Eszerint 531 tanúsítványt állítottak ki illetéktelenül, a tanúsító összes CA szerverét adminisztrátori szintig törték, és logokat töröltek, melynek eredményeként a DigiNotarnak elképzelése sem lehetett arról, hogy kiknek a nevére generáltak tanúsítványokat. A behatoló június 6-án jutott be a rendszerbe, a DigiNotar július 19-éig mit sem tudott a dologról, és még szeptember 3-án is kiállításra kerültek új tanúsítványok!

És a legjobb: jelentkezett az állítólagos támadó is, aki úgy tűnik, megegyezik a Comodot megtörő hackerrel. Nyílt levele szerint tetteit a muszlimokat ért sérelmek emgbosszulása motiválja, és még négy CA rendszeréhez van hozzáférése. Állításait egy DigiNotartól származó felhasználó/jelszó párossal támasztja alá, ezen kívül az elcsepegtetett technikai részletek (spéci XUDA szkripteket kellett írni az RSA Certificate Managerhez) egybe vágnak a fent említett jelentés megállapításaival. 

Egy [kernel.org users] listára érkezett üzenet tanúsága szerint rosszindulatú támadók korlátlan hozzáférést szereztek a kernel.org több back-end szerverén is. Az behatolásra legkésőbb augusztus 12-én kerülhetett sor, a levlistás üzenet pedig tegnapelőtt érkezett - érdekes, hogy nem tűnt fel előbb senkinek az eset, illetve hogy nem igazán lehetett hallani róla az elmúlt 48 órában sem.

Még vizsgálják, hogy mi történt pontosan, egyelőre annyit tudni, hogy a támadó SSH kulcsokat és hátsó kapukat telepített. Ha van további érdemi információ, frissítek! 

(az infóért köszönet Hungernek)

Friss: Megjelent a hivatalos közlemény a kernel.org-on. Eszerint egy komprommitált account felhasználása után csináltak root-ot valahogy.

A Google nevére illetéktelen felek számára kiállított tanúsítvány jelent meg nem rég a neten. Először egy iráni felhasználónak lett gyanús, hogy a böngészője figyelmeztetést dob a GMail.com meglátogatásakor, mivel az oldal tanúsítványa megváltozott. Az új hitelesítő információ egy holland CA-tól, a DigiNotartól származik.

Bár a tanúsítvány visszavonása megtörtént, a Comodo esetéből tudjuk, hogy ez a gyakorlatban nem sokat ér, így a Mozilla új böngésző kiadással fog jelentkezni az incidens emlékére.

Frissítés:

A DigiNotart birtokló Vasco Inc. kiadott egy közleményt az esettel kapcsolatban, jól figyeljetek:

A DigiNotar rendszerét július 19-én (!) érte támadás, melyet egy belső vizsgálat követett (értsd: mindenki másnak b*sztak szólni). A vizsgálat eredményeként az illetéktelenül kiállított tanúsítványokat visszavonták, de a szóban forgó google.com-os valahogy kimaradt (!!). A cég szerint az incidens hatása minimális, mivel a DigiNotar tanúsító üzletágának éves bevétele csak mintegy 100.000 EUR volt (!!!). Agyameldobom, komolyan.

Az F-Secure a fentieken kívül kiderítette, hogy a www.diginotar.nl-t az elmúlt évben többször megtörték, feltehetően iráni arcok, nyilván ez nem adott okot semmilyen aggodalomra a cégen belül.

Frissítés 2:

Érdemes elolvasni Dr. Berta István Zsolt gondolatait az esettel kapcsolatban! Néhány megjegyzés: 

• A Mozillának az is jó ok lehetett a teljes DigiNotar gyökér letiltására, hogy nem ismert, pontosan milyen tanúsítványok készültek illetéktelenül. A legújabb pletykák szerint a Google mellett több nagy szervezet is érintett lehet.
• A cég bevétele vagy a legitim módon kiállított tanúsítványok száma irreleváns abból a szempontból, hogy hány Google (vagy más) felhasználót lehet átverni egy "hamis" tanúsítvánnyal. Ez alapján nem szabadna a problémát bagatelizálni (ahogy azt a Vasco tette)

Frissítés 3:

A Mozilla újabb közleményt adott ki, melyben megmagyarázzák, hogy miért törölték véglegesen a DigiNotart a megbízható CA-k listájáról. A legfőbb indokok:

• A DigiNotar nem figyelmeztette a Mozillát, pedig az addons.mozilla.org-ra is állítottak ki tanúsítványt a támadók.
• Nem lehet tudni, hogy pontosán mennyi és milyen tanúsítvány került kibocsátásra.
• Éles támadásokat észleltek, melyekben DigiNotaros tanúsítványokat használtak fel.

Igen kellemetlen problémát találtak a nem rég megjelent OS X 10.7 Lion központi hitelesítést biztosító LDAP megvalósításában. Bizonyos esetekben az Apple új operációs rendszerét futtató kliensek nem tudnak bejelentkezni az Open Directory azonosítójukkal, rosszabb esetben pedig bármilyen jelszót elfogad a rendszer egy érvényes felhasználónév mellé. 

Az Apple állítólag képes volt reprodukálni a hibát, de hivatalos közleményt a javítás állapotáról nem találtam. Más operációs rendszert, illetve a korábbi OS X változatokat futtató klienseket nem érinti a probléma. Az első, 10.7.1-es frissítés nem segít. Open Direcory-t használó környezetekben érdemes várni a Lion-ra váltással!

Timo Hirvoven, az F-Secure munkatársa több hónapos kutatás után kibányászta a cég mintaállományai közül a hírhedt "2011 Recruitment Plan.xls" állományt, amely az RSA rendszereibe történő behatoláshoz használt eredeti exploitot tartalmazta.

A fájl egy Outlook üzenetbe ágyazva került elő, így az is kiderült, hogy kinek és hogyan juttaták el a támadó kódot. A levelet március 3-án küldték el összesen négy címzettnek egy látszólag a beyond.com álláskereső portálhoz tartozó címről. Az e-mail tartalma nagyjából annyi volt, hogy "Át kellene nézni ezt a fájlt. Kérlek nyisd meg". A melléklet megnyitásakor mindössze az Excel táblába beágyazódó Flash objektum kis X-e látszódott, a háttérben azonban egy akkor még 0day Flash exploit futott le, ami egy Poison Ivy variánst telepített, ami a good.mincesur.com címre csatlakozott vissza. Külön érdekesség, hogy a rosszindulatú XLS-t március 19-én valaki feltöltötte a VirusTotal-ra, így a biztonsági cégek nyilván belefutottak már korábban, csak nem tudták, milyen különleges jelentőségű fájlról is van szó.

Érdemes kiemelni néhány dolgot a történtekkel kapcsolatban:

• Négyből egy dolgozó lefuttatta a malware-t
• Az RSA biztonsági rendszerei nem szúrtak ki egy bármelyik script kiddie által letölthető és használható trójait, ami aztán hosszú ideig működhetett a hálózaton
• A használt víruskergetők nem találták furcsának, hogy valaki Flash-t ágyaz egy Excel fájlba

Ezek után már az sem okoz nagy meglepetést, ha magán az F-Secure termékein keresztül lehet drive-by-download támadásokat indítani.

Bocs a ritka posztokért, hekk in progress ;)

Nem sokkal a PHP legújabb, 5.3.7-es változatának kiadása után derült ki, hogy a nyelv beépített könyvtárának crypt() függvényében elszúrták a saltolt MD5 hash-ek számítását. A problémát egy helytelenül használt strlcat() hívás okozza, melyet a veszélyesnek ítélt strcat() hívás helyett vezettek be. A hiba következtében egyes esetekben a crypt() nem a kiszámított hash értékkel, hanem csak a salttal tér vissza.

Andrey Bogdanov, Dmitry Khovratovich és Christian Rechberger egy új, kulcsvisszaállításra (elméletileg) alkalmas(!) támadást dolgoztak ki az AES 128, 192 és 256 bites, teljes körszámú változataival szemben. Mielőtt pánikba esnénk:

• Az AES-128 elleni támadás komplexitását 2^128-ról 2^126.1-re
• Az AES-192 elleni támadás komplexitását 2^192-ről 2^189.7-re
• Az AES-256 elleni támadás komplexitását 2^256-ról 2^254.4-re

sikerült csükkenteni, ami minden bizonnyal gyönyörű elméleti eredmény, praktikusan azonban még mindig elképzelhetetlenül nagy számokról beszélünk. 

A támadás egy, az SHA-1 hash algoritmussal szemben korábban sikerrel alkalmazott módszer, az úgynevezett biclique támadás blokk titkosítókra való átültetése*. 

Bár a legátütőbb siker egy titkosítóval szemben a kulcsvisszaállítás, a trió módszere komolyabb sikert ért el az AES speciálisabb alkalmazási eseteinél. Az eddig kidolgozott, csökkentett körszámú algoritmus-variációk támadásainak hatékonsága tovább növelhető a biclique technikával, egyes AES alapú egyirányú kompressziós függvények előkép-generálásának komplexitása pedig 2^125 - 2^127 közé szorítható (63.2%-os siker aránnyal).

Az AES tehát még mindig erős lábakon áll, de nem szabad megfeledkeznünk az örök bölcsességről: a támadások sosem lesznek rosszabbak.

* A támadás részleteiért olvassátok el a publikációt, bár ennek megértése erős kripto tapasztalat nélkül elég esélytelen. Megfelelő tapasztalat hiánya esetén ezt a képregényt tudom ajánlani.

Hao Chen és Lian Caiegy igen meglepő eljárást dolgoztak ki az okostelefonok billentyű-leütéseinek naplózására. A kutatók a készülékek beépített giroszkópján (ez az a cucc, amitől pl. tudja a telefon, hogy mikor kell állóból fekvőbe váltani a képet) keresztül figyelték, hogy milyen apró változások következnek be a telefon orientációjában, miközben a felhasználó éppen a PIN-kódját adja meg az érintőképernyőt használva.

Az Androidra készült prototípus egy 10 jegyű numerikus numerikus interfész esetén 72%-os pontosságot nyújtott, ami ugyan messze van a tökéletestől, de még így is meglepően jó eredménynek tűnik. Egy teljes QWERTY kiosztással minden bizonnyal sokkal rosszabbul boldogulna az eljárás, de komoly előnyként tartható számon, hogy a giroszkóp adataihoz bármely alkalmazás bármikor hozzáférhet.

Az elmúlt héten sokan felkapták a fejüket, mikor Tavis Ormandy - aki a Google szakértője, és mellesleg nem szokott finomkodni, ha hibajelentésről van szó - Twitteren bejelentette, hogy az Adobe Flash aktuális javítócsomagjában kb. 400 hibát javítottak, miközben a bulletin mindössze 13 hibajegyet tartalmazott. 

El kellett telnie néhány napnak, mire tisztázódtak a dolgok, de szerencsére ebben az esetben összeborulással zárult a történet. A Google és az Adobe is hivatalos blogposztban emlékezik meg az esetről, ezeken keresztül pedig érdekes információkkal lehetünk gazdagabbak a két óriáscég biztonsági csoportjainak együttműködésével kapcsolatban.

A 400 hiba nem tévedés, a Google-nél a Chrome-Flash integráció miatt nagyszabású fuzz teszteket végeznek a lejátszón. Ehhez jelen esetben a keresőóriás adatbázisainak segítségével először összeszedtek 20 TB SWF fájlt, melyekből egy olyan részhalmazt választottak ki, amelyek lejátszásakor a Flashben a lehető legtöbb kód-útvonal kerül bejárásra. Ehhez 2000 CPU magra és kb. egy hétre volt szükség. Végül a kiválaszott 20.000 fájlt három héten keresztül mutációs algoritmussal fuzzolták a 2000 magon, így esett ki 400 különbözőnek látszó hiba.

Ezek közül első körben 106 különböző biztonsági problémát azonosítottak, melyeket nagyjából 80 kódmódosítással javítottak. Mivel azonban az Adobe nem szokott CVE azonosítókat rendelni a belső vizsgálatok során felfedezett, nem kihasznált hibákhoz, Ormandy és csapatának munkájára csak a köszönetnyílvánító szekcióban utaltak.

És akkor néhány tanulság:

• A CVE jegyek számának összehasonlítása egy nagyon rossz módszer egy termék biztonsági szintjének megállapításához, hiszen sok problémához nem rendelnek ilyen azonosítókat.
• A cégek közti együttműködésnek eredményeként rövid idő alatt sok hibát lehet javítani.
• A Flash még ennyi év és rászánt kutatás után is ontja magából a hibákat...

10.0-ás CVSS pontszámot érdemlő, kritikus sérülékenységeket javítottak a BlackBerry Enterprise Server-ben. A sérülékenységek a termékben felhasznált, külső gyártótól származó illetve nyílt-forrású szoftverekből származnak, és a PNG valamint TIFF fájlok feldolgozását érintik. 

Kihasználásukkal teljes kontroll szerezhető a sérülékeny szoftvereket futtató kiszolgálókon, ehhez pedig nem kell közvetlenül hozzáférni a BES-ekhez, hanem elég, ha a célpont alá tartozó valamelyik okostelefonon egy rosszindulatú weboldalra látogatnak, vagy egy speciális képet tartalmazó e-mailt fogadnak. Utóbbi esetben az e-mailt meg sem kell nyitni ahhoz, hogy kiszolgáló megadja magát. Frissítsen hamar, aki érintett!

MS11-057: Öt hibajavítás az Internet Explorer összes támogatott verziójához. Természeretesen mindegyik javított sebezhetőség távoli kódfuttatásra adhat lehetőséget. A javított hibák között szerepel Stephen Fewer egyik Pwn2Own-os bugja is.

MS11-058: Ez egy szaftos darab! Egy DoS és egy távoli kódfuttatásra alkalmas hiba javítása a Windows DNS szerverében. Az utóbbi probléma akkor jön elő, amikor a kiszolgáló speciális NAPTR rekordot kap egy rosszindulatú DNS szervertől, ekkor egy nem várt előjeles átalakítás következtében egy hatalmas méretű memcpy() történik, ami heap korrupcióhoz vezet. Az SRD szerint kicsi az esélye egy exploit megjelenésének, egyrészt mivel a másolás művelet jó eséllyel több memóriát fog igényelni az elérhetőnél, másrészt a Windows 2008-ban már alapértelmezett ASLR-nek és DEP-nek köszönhetően (korábbi szerver verziók nem érintettek). 

MS11-059: A Windows Data Access Components DLL hijacking sebezhetősége. A probléma tipikusan Excel-en keresztül használható ki. A Windows 7 és újabb oprendszer változatok érintettek.

MS11-060: Két Visio hiba javítása az irodai szoftver 2003 SP3 vagy újabb változataihoz

MS11-061: A Remote Desktop Web Access nem perzisztens XSS sérülékenysége. A Microsoft szerint az ilyen támadásokat az új IE-k XSS védelme kiszűri az Internet Zónában, de én erre nem vennék mérget. Intranet Zónában az XSS Filter nincs bekapcsolva alapból. 

MS11-062: Jogosultságkiterjesztésre alkalmas hiba a Windows korábbi változataiban, 2003-al bezárólag. A probléma a Remote Access Service NDISTAPI meghajtóját érinti.

MS11-063: A Windows CSRSS alrendszerét érintő jogosultságkiterjesztésre alkalmas probléma javítása. Az összes támogatott Windows verzió érintett. (Egy hasonló hibát jelöltek a mostani Pwnie-ra is, ezek nem összekeverendők, viszont ez a leírás elég érdekesnek tűnik!)

MS11-064: Egy Vistán és ettől felfelé jelentkező DoS problémák a TCP/IP stackben. Egyikük speciális ICMP csomagokkal (Pings of Death? :) fekteti hanyatt az aládozatot, a másikuk HTTP-n keresztül lekért speciális URL-ekkel, amennyiben a célponton engedélyezett az URL alapú QoS. 

MS11-065: Szintén DoS-t előidéző probléma javítása az Windows XP és 2003 RDP szolgáltatásában. Ezt állítólag már el is sütötték a rosszfiúk néhány célzott támadásban!

MS11-066: Chart vezérlőket használó .NET alkalmazásokat érintő probléma javítása. A sebezhetőség nem vezet közvetlen kódfuttatáshoz, viszont kihasználásával információszivárgás idézhető elő, és kiolvasható például a web.config is, ami általában nagyon rossz.

MS11-067: XSS hiba a Microsoft Report Viewerben, a 2005-ös változatig, őszintén szólva nem tűnik túl érdekfeszítőnek (bezzeg a jó öreg MS08-067! ;)

MS11-068: DoS sebezhetőség javítása a Windows kernelben, minimum Vistánál. A probléma úgy is kihasználható, hogy ha az áldozat ellátogat egy speciális metaadatokkal ellátott fájlt tartalmazó hálózati megosztásra, vagy megtekint egy weblapot, ami egy ilyen megosztásra hivatkozik.

MS11-069: Egy információszivárgásként kategorizált probléma javítása a .NET keretrendszerben. A probléma egyrészt azokat érinti, akik XAML Browser Application-ket futtatni képes böngészőt használnak, másrészt a .NET hoszting szolgáltatóknak is érdemes frissíteni. A leírás ugyan nem tér ki arra, hogy mégis milyen információk szivároghatnak ki a hiba következtében, de annyit elárulnak, hogy megkerülhetők a Code Access Security bizonyos szolgáltatásai, valamint hogy a sebezhető böngésző hosztokon keresztül a támadók kapcsolatokat nyithatnak az áldozat belső hálózata felé, ez pedig aggasztó.