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...