Windows XP SP2/SP3 (NtUserConsoleControl) - Local Privilege Escalation

 ( trey | 2009. augusztus 6., csütörtök - 8:52 )

A SecurityTracker egyik figyelmeztetője szerint egy, a Windows XP kernelében található sebezhetőség lehetővé teszi a helyi felhasználó számára privilégium-szintjének emelését. A helyi felhasználó meghívva a win32k.sys-ben található NtUserConsoleControl() függvényt tetszőleges kódot hajthat végre a rendszeren emelt privilégium-szinttel.

Júniusban Jonathan Ness azt írta egy, a hibára publikált 0day-re a Microsoft Security Research & Defense blogban, hogy futtatásához adminisztrátori jogok kellenek, és ugyan tovább vizsgálják a problémát annak érdekében, hogy kiderüljön, kihasználható-e privilégium-szint emelésre, a hiba "reliability" problémának látszik inkább, mintsem biztonsági sebezhetőségnek.

A SecurityTracker mostani figyelmeztetője azonban nem tartalmaz olyan információt, amely arra utalna, hogy adminisztrátori jogok kellenek egy, a hibára mostanában készült exploit-hoz, amely megtalálható itt.

Az NTInternals bejelentésében van ugyan utalás arra, hogy administrator jogok kellenek a kihasználáshoz, de mivel a hibajegy ezt nem tartalmazta, kapcsolatba léptem az exploit szerzőjével, aki megerősítette, hogy !adminisztrátor helyi felhasználói jogosultság nem elég az exploit-hoz:

Idézet:
Hi Gabor,

No. This exploit requires administrator privileges! Regular users can't gain SE_DEBUG_PRIVILEGE privilege, so they can't open csrss.exe process and play with protected services.

Regards,
Alex

A Milw0rm is publikálta a napokban az exploit-ot, szintén elfelejtve megemlíteni, hogy a használatához administrator privilégium-szint kell.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ha valakinek admin jogosultsága van, akkor mire jó egy privilege escalation? (bocs, nem értek hozzá, csak kérdezek!)

----------------------------------
feel the beat - it's everywhere!

Én arra jutottam, hogy ez egy administrator -> LocalSystem account privilágium-szint emelés.

A LocalSystem account leírása a TechNet-ben:

The LocalSystem Account
LocalSystem Account

Ha admin jogod van, az gyakorlatilag majdnem ugyanez, így valóban nincs nagy különbség. A probléma számomra ott volt zavaró, hogy a hibajegy csak "local user"-t írt. Elolvasva az eredeti cikket nekem az volt az érzésem, hogy a hibajegy téved, ezért rákérdeztem. És valóban, nem elég a "local user".

--
trey @ gépház

meglepődnél mit csinál pl egy psexec -s cmd.exe

Mielőtt még támadni kezdesz, a cikk _pont azért_ született, hogy elmondja, az exploit gyakorlatilag nem olyan veszélyes, mint amilyennek leírták / látszik.

--
trey @ gépház

"az exploit gyakorlatilag nem olyan veszélyes, mint amilyennek leírták / látszik"

akkor mennyire "veszélyes"?
Valóban gyári, supportált, microsoft toolok vannak az admin->local system jogosultság emelésére. Nekem ez első látásra annak tűnik, hogy egy hibát kihasználva eléred azt amire egyébként dokumentált api van, amennyiben eleve volt rá jogosultságod, tehát az ég világon semmire nem lehet használni a hibát.

Sajnos én azt nem tudom megállapítani, hogy mennyire veszélyes. Csak azt tudtam megállapítani a rendelkezésre álló információkból, hogy annyira nem, mint ahogy az hibajegyben szerepelt. Talán az exploit szerzője tud neked bővebb felvilágosítást adni arra nézve, hogy ez miért ért annyit, hogy érdemes volt egyáltalán említeni, illetve exploitot írni rá.

--
trey @ gépház

az ég világon semmire nem lehet használni a hibát

Dehogynem, pl. HIDS/HIPS evasion.

Abban lehet valami, de szerintem 100x előbb harap egy IDS (de még egy heurisztikus viruskereső is) egy ilyen "dokumentálatlan" trükkre mint egy teljesen hivatalos api hivásra. (ha nem most, akkor majd a következő def. frissités után)

Akkor "harap" rá, ha tud róla, kihasználni meg pont akkor szokták, amikor(/amíg) nem tud róla... ;)

Attól mert Jonathan Ness úgy gondolkozik mint az OpenBSD csapat, hogy minden ilyen jellegű bug "reliability issue" csupán és nem pedig "security vulnerability", attól még ez nem lesz igaz.

Ha a kernelhez (vagy általánosan nézve: bármilyen funkcióhoz) nem csak a megengedett mód(ok)on lehet hozzáférni, akkor az bizony biztonsági probléma és pont.

Te tudsz olyan IDS-ről ami harap a "legális" admin -> local system privilégium emelő api hivásra?
Engem mondjuk nem zavar, ha biztonsági problémának hivjuk, de valószinűleg az utolsó helyek egyikén lenne a listán amit befoltozok, ha a patch-tesztelő kapacitás szűkös. És ha a ms nem fogja elkapkodni a javitását, azt se fogom főbenjáró bűnnek tekinteni, szerintem marginális probléma. Ha az IDS már csak azt veszi észre, hogy egy bejutott kód admin-ról localsystemre emeli/változtatja a jogait, akkor már régen rossz.

Konkretan nem tudom, mennyire mondhatjuk ra, hogy IDS, inkabb security ellenor, de a RSBAC linuxon peldaul minden privilegium emelesre harap, es fajlszinten lehet megmondani neki, hogy kit engedjen es kit ne. Ilyesmi lehet kellene Windowsra is.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

gyanitom, hogy winen is megoldható, hogy ilyen eventre történjen valami, a kérdés inkább az, hogy minek. Egyrészt régen rossz, ha már adminként fut egy támadó kód, másrészt bármi megoldható localsystem nélkül is, ha megvan az admin.

Te tudsz olyan IDS-ről ami harap a "legális" admin -> local system privilégium emelő api hivásra?

Mint mondtam, nem az admin -> SYSTEM itt a lényeg, hanem a kernel memóriaterületéhez való hozzáférés. Az hogy a publikált exploit ezt éppen pont SYSTEM jogosultság szerzésére használja ki csak okozat, nem pedig maga az ok.

A filozófia órán pedig még hrgy84 is megtanulta (csak ocsieu nem), hogy az ok és okozat közötti szoros kapcsolat csak akkor feltétlenül szükségszerű, ha logikai bukfenchez, azaz mindenképp ellentmondáshoz vezetne azon elgondolás, miszerint az okot bármely más okozat követhetné. ;)

"Az hogy a publikált exploit ezt éppen pont SYSTEM jogosultság szerzésére használja ki csak okozat, nem pedig maga az ok."

Az esetek 99%-ban azért használ ki "csak" adott dolgot egy exploit (esetünkben ráadásul egy értelmetlen dolgot, amit "legálisan" is meg tudna csinálni) mert a hiba ennyit tesz lehetővé. Ha kiderül, hogy többet is lehetővé tesz, akkor majd lehet sikoltozni. :)

A kernelhez többféleképp hozzá lehet férni, de az egyetlen (hogy a te szavaddal éljek) "legális" út, az a driver betöltés. Ezt azonban lehet loggolni, korlátozni (pl. trusted tanúsítványhoz kötni, esetleg fehérlistázni), vagy a használt driverek betöltése után teljesen tiltani. Mivel ez a hétköznapi eljárás, amelyre sok HI[DP]S is figyel, ezért egy támadó nem feltétlenül telepítené ilyen módszerrel a rootkitjét, mert nem akar zajt csapni... Ezen kívül vannak kevésbé legális, "szürke" megoldások is (pl. \Device\PhysicalMemory általi kód injektálás és hasonlók), amelyek szintén jól ismertek és publikus mivoltuk miatt szintén veszélyt jelenthetnek egy támadó számára. :)

Tehát az ilyen kerülő megoldások ideálisak arra, hogy anélkül lehessen kártyékon kódot futtatni ring0-ban, hogy a különböző security szoftverek bejelezzenek.

"Tehát az ilyen kerülő megoldások ideálisak arra, hogy anélkül lehessen kártyékon kódot futtatni ring0-ban, hogy a különböző security szoftverek bejelezzenek."

Én ezügyben még várnék pár napot/hetet, mielőtt ilyen szintű veszélyt kiáltanék, mert egyelőre fényévekre van ettől ez a hiba.

Úgy látom nem sok mindent sikerült megérteni abból, amit leírtam...

Hát én se nagyon értem hogyan jutottál egy local admin jogot igénylő, értelmes dologra nem használható "kerülő megoldástól" a ring 0-s kártékony kód futtatási lehetőségéig, de nem is lényeges, szerintem ez a szál kifújt :)
Ha majd kiderül, hogy veszélyes dologra is lehet használni a hibát, akkor majd updatelik az értesitőt és mindenki eljár annak megfelelően.

Hát én se nagyon értem hogyan jutottál egy local admin jogot igénylő, értelmes dologra nem használható "kerülő megoldástól" a ring 0-s kártékony kód futtatási lehetőségéig

Ember, te érted egyáltalán, hogy milyen hibáról van szó és mit tesz lehetővé? Tudod mit jelent a kernel rootkit kifejezés?

Ha majd kiderül, hogy veszélyes dologra is lehet használni a hibát, akkor majd updatelik az értesitőt és mindenki eljár annak megfelelően.

Mit updatelnek barátom? Pontosan tudni, hogy mit tesz lehetővé a bug. Le is írtam.

Mert nincs olyan, hogy admin jogosultság. Administrator felhasználó van és annak _alapesetben_ privilegizált jogosultságai.

Ahogy modern *nix rendszereken sincs root jogosultság, csak root felhasználó van és alapesetben hozzárendelt képességek (Capabilities).

A gyakorlatban ez azt jelenti, hogy könnyen előfordulhat olyan Windows környezet, ahol korlátozott felhasználónak is van SE_DEBUG_PRIVILEGE privilégiuma és így máris kihasználhatóvá válik a hiba nem admin felhasználóval is. Sok szoftverfejlesztő cégnél fordulhat elő ilyen privilégiummal rendelkező, de egyébként más extra jogokkal nem bíró user.

Másrészről vannak olyan lebiztosított Windows rendszerek, ahol nem csak az Administrator, de még a SYSTEM jogai is erősen korlátozva vannak. Ott is ideális lehet a probléma a jogok kiterjesztéséhez.

UNIX/Linux esetén is biztonsági hibának tekintendő, ha egy root (euid=0) felhasználó a neki biztosított erőforrások megkerülésével képes a kernel memóriaterületéhez hozzáférni. Mert a root sem feltétlenül kiemelt felhasználó egy modern *nix rendszeren. Lásd. SELinux által nyújtott biztonsági mechanizmusok.

>> korlátozott felhasználónak is van SE_DEBUG_PRIVILEGE privilégiuma

ebben a szituációban nem is kellett lélegzetvisszafojtva várni erre a hibára ;)

Meglett a spellchecker? :)

--
trey @ gépház

már majdnem beszóltam, erre látom hogy én írtam

Ahahha :))

--
trey @ gépház

vártam a válasszal, hogy kijavíthasd :P

<3 hunger <3

::szivecske::

Jó, de elképzelhető olyan környezet, ahol ez egyszerűbbé teszi a dolgokat... :)

"Mert nincs olyan, hogy admin jogosultság. Administrator felhasználó van és annak _alapesetben_ privilegizált jogosultságai."
Nem. Administrators csoport van, es abba barki belekerul, "Administrator" erossegu user valik belole. Kicsit jobban figyelj oda Windows oran.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Milyen az az "Administrator" erősségű user, mesélj.

szemléletes példa: mi történik, ha a local security policy editorban a debug programs nevű házirendből kiveszem az általad említett csoportot, és beteszem az általad említett usert?

Azért mert pongyolán fogalmazott, még igaza van. Alapesetben a csoportoknak vannak jogosultságai és ezeket öröklik a benne levő felhasználók. Nem szerencsés az általad felvázolt példa, mert nagyon hamar káoszhoz vezet.

és az hogy alapesetben csoportok által öröklődik a jogosultság hol mond ellent annak, amelyet én írtam?

Ott, hogy azt mondod, nincs admin jogosultsag. Ennek nemikeppen ellentmond az, hogy nem csak 1 user rendelkezhet admin jogokkal (mint pl. a Linux eseten, ahol kimondottan a root felhasznalora van a legtobbszor lekorlatozva az adminisztratori jogosultsag), hanem barki, barmilyen felhasznalonevvel kaphat admin jogosultsagot.

De ha masra gondoltal, akkor #define admin_role
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ennek nemikeppen ellentmond az, hogy nem csak 1 user rendelkezhet admin jogokkal (mint pl. a Linux eseten, ahol kimondottan a root felhasznalora van a legtobbszor lekorlatozva az adminisztratori jogosultsag), hanem barki, barmilyen felhasznalonevvel kaphat admin jogosultsagot.

Kicsit jobban figyelj oda Linux órán (is).

"Kicsit jobban figyelj oda Linux órán (is)."

+1

Nem is a te hozzászólásodra reagáltam. Vagy te vagy snq- is?

Nehezen megy a kisbarátod megvédése, úgy látom ;))

Nem a barátom, és nem is akarom megvédeni. Csak egy kérdés volt. Azt nem értem miért vagy ilyen ellenséges? Nem csak most velem, úgy általában mással is.

Úgy általában az emberi butasággal vagyok ellenséges.

Ne légy a magad ellensége.

> Azt nem értem miért vagy ilyen ellenséges?

Csak a trollkommunabeli státusz fenntartása miatt.

ne azon lovagoljál, hogy a példa organizációs szempontból szerencsés-e
az a lényeg, hogy nem kell keverni a 3 fogalmat

Akkor miért nem azt írod.

Alapvetoen en csak es kizarolag arra reagaltam, hogy "nincs admin jogosultsag". Semmi egyeb masra. Igen, vannak hazirendek, melyekhez explicite hozza lehet usereket rendelni, akarmelyik csoportbol. Am ehhez mar explicit beavatkozas szukseges, es nem is trivialis ennek a modja (ne feledjuk, XP-rol beszelunk, es arrol, hogy emberek altalaban Adminstrators csoporttagsagu userrel hasznaljak), tehat totalisan irrelevans, hogy hazirendekben mit lehet tenni es mit nem.

Jelen esetben egy olyan 0day exploitrol beszelunk, melynek elinditasahoz adminisztratori jogosultsag szukseges (user.is_member_of?('Administrators') == true).
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

>> arra reagaltam, hogy "nincs admin jogosultsag"

helyes, nincs is

>> totalisan irrelevans, hogy hazirendekben mit lehet tenni es mit nem

amennyiben azt szeretnénk kimagyarázni valahogy, hogy miért keverjük a fogalmakat, valóban

>> Jelen esetben egy olyan 0day exploitrol beszelunk, melynek elinditasahoz adminisztratori jogosultsag szukseges (user.is_member_of?('Administrators') == true)

vagy éppen nem

Ah, Hunger megelőzőtt.

----------------
Lvl86 Troll

Van bizonyos jogosultsagbeli kulonbseg az Administrator es a LocalSystem account jogosultsagai kozott - peldaul az a nem elhanyagolhato teny, hogy ez utobbi felhasznalora kevesebb megkotes vonatkozik a rendszerfajlokat illetoen, ugyanis a WindowsUpdate szerviz is ennek a felhasznalonak a jogaival fut (pontosabban ez nem teljesen igy van, csak a hotfix telepites fut ezzel, de nem ez a lenyeg).

Ha jol emlexem, valahol le vannak a LocalSystem privilegiumai dokumentalva, erdemes korulnezni.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mert a windows alatt a "root" gyakorlatilag root jogot adhat önmagának.