the Power in Power Users

először májusban jelent meg a TechNet-en 01, 2006

A Windows felhasználói fiókok elhelyezése az energiafelhasználók biztonsági csoportjában egy általános megközelítés, amelyet az informatikai szervezetek alkalmaznak annak érdekében, hogy a felhasználókat a legkevésbé jogosult környezetbe juttassák, miközben elkerülik a korlátozott felhasználóként való valóban futás sok fájdalmát. Az energiafelhasználók csoport szoftvereket telepíthet, kezelheti az energiagazdálkodási és időzónabeállításokat, valamint telepíthet ActiveX-vezérlőket, olyan műveleteket, amelyeket a korlátozott felhasználók megtagadnak.
amit azonban sok adminisztrátor nem vesz észre, az az, hogy ennek a hatalomnak a valódi korlátozott felhasználói biztonság ára van. Számos cikk, beleértve ezt a Microsoft tudásbázis cikket és a Microsoft biztonsági szakemberének, Jesper Johansen blogbejegyzését, rámutat arra, hogy az energiafelhasználók csoportjába tartozó felhasználó könnyen fel tudja emelni magát teljes kiváltságos rendszergazdákká, de nem találtam részletes leírást az általuk hivatkozott magassági mechanizmusokról. Ezért úgy döntöttem, hogy kivizsgálom.
a vizsgálat megkezdése előtt meg kellett határoznom a problémát. Biztonsági hiba, például puffertúlcsordulási jogosultság hiányában az eszkaláció csak akkor lehetséges, ha egy fiók tetszőleges kódot konfigurálhat egy kiváltságosabb fiók kontextusában történő végrehajtásra. Az alapértelmezett fiókok, amelyek több jogosultsággal rendelkeznek, mint az energiafelhasználók, a rendszergazdák és a helyi rendszerfiók, amelyben több Windows szolgáltatási folyamat fut. Így, ha egy Power Users tag módosíthatja az egyik ilyen fiók által végrehajtott fájlt, konfigurálhatja egyik végrehajtható fájlját tetszőleges DLL betöltésére, vagy végrehajtható automatikus indítást adhat ezekhez a fiókokhoz, teljes rendszergazdai jogosultságokat szerezhet be.
az első lépés az volt, hogy milyen fájlokat és könyvtárakat, amelyek a Power Users csoport írási hozzáférést, de a korlátozott felhasználók nem. Az általam figyelembe vett rendszerek A Windows 2000 Professional SP4, a Windows XP SP2 és a Windows Vista készletei voltak. Nem fogom zavarni a szerverrendszereket, mert a leggyakoribb Energiafelhasználói forgatókönyv egy munkaállomáson van.
a brute force módszer, hogy lássuk, milyen fájlrendszer-objektumokat módosíthatnak az energiafelhasználók, megköveteli az egyes fájlok és könyvtárak meglátogatását és az engedélyek vizsgálatát, ami nyilvánvalóan nem praktikus. A parancssori Cacls segédprogram, amelyet a Windows tartalmaz, eldobja a biztonsági leírókat, de soha nem zavartam a Security Descriptor Description Language (SDDL) tanulását és a kimenet elemzését, szkriptet kellene írni. A Bryce által írt AccessEnum segédprogram ígéretesnek tűnt, és megvizsgálhatja a rendszerleíró adatbázis biztonságát is, de célja a lehetséges engedélyek gyengeségeinek bemutatása, nem pedig az egyes fiókok számára elérhető hozzáférések. Továbbá tudtam, hogy meg kell vizsgálnom a Windows szolgáltatásokra alkalmazott biztonságot is.

arra a következtetésre jutottam, hogy új segédprogramot kell írnom a munkához, ezért létrehoztam az AccessChk-t . Megadja az AccessChk-nak egy fiók – vagy csoportnevet, valamint egy fájlrendszer elérési útját, rendszerleíró kulcsát vagy Windows-szolgáltatásnevét, és a fiók vagy csoport tényleges hozzáféréseit jelenti az objektumhoz, figyelembe véve a fiók csoporttagságait. Például, ha a Mark-fiók hozzáfér egy fájlhoz, de a Mark A Fejlesztői csoporthoz tartozik, amelyhez kifejezetten megtagadják a hozzáférést, akkor az AccessChk azt mutatja, hogy a Mark nem rendelkezik hozzáféréssel.
annak érdekében, hogy a kimenet könnyen olvasható legyen, az AccessChk kiírja a ‘W’ – t az objektum neve mellé, ha egy fiók rendelkezik olyan engedélyekkel, amelyek lehetővé teszik az objektum módosítását, és az ‘R’ – t, ha egy fiók képes olvasni az objektum adatait vagy állapotát. Különböző kapcsolók hatására az AccessChk alkönyvtárakba vagy Beállításkulcsokba rekurzálódik, a –v kapcsoló pedig jelentést készít a fiókhoz elérhető konkrét hozzáférésekről. Egy kapcsoló, amelyet kifejezetten olyan objektumok felkutatására adtam hozzá, amelyekhez egy fiók írási hozzáféréssel rendelkezik, a –w.
ezzel az új eszközzel felfegyverkezve készen álltam a vizsgálat megkezdésére. Az első célom egy Windows XP SP2 VMware telepítés volt, amely a VMWare eszközökön kívül nem telepített alkalmazásokat. Az első parancs, amit végrehajtottam, a következő volt:
accesschk-ws “power users” c:\windows
ez az összes fájlt és könyvtárat megjeleníti a \Windows könyvtárban, amelyet a Power Users csoport módosíthat. Természetesen a \Windows alatt található fájlok közül sok az operációs rendszer vagy a Windows szolgáltatások része, ezért a helyi Rendszerfiókban hajtják végre. Az AccessChk arról számolt be, hogy az energiafelhasználók módosíthatják a \Windows alatt található könyvtárak többségét, ami lehetővé teszi a tagfelhasználók számára, hogy fájlokat hozzanak létre ezekben a könyvtárakban. Így a Power Users csoport tagja fájlokat hozhat létre a \ Windows and \ Windows \ System32 könyvtárban, ami a rosszul megírt örökölt alkalmazások általános követelménye. Ezenkívül az energiafelhasználóknak képesnek kell lenniük fájlok létrehozására a \Windows\letöltött Programfájlok könyvtárban, hogy telepíthessék az ActiveX-vezérlőket, mivel az Internet Explorer ebbe a könyvtárba menti őket. Azonban egyszerűen egy fájl létrehozása ezekben a könyvtárakban nem a jogosultság magasságának elérési útja.
annak ellenére, hogy az energiafelhasználók fájlokat hozhatnak létre a \Windows és a legtöbb alkönyvtár alatt, a Windows beállítja az alapértelmezett biztonsági engedélyeket az ezekben a könyvtárakban található legtöbb fájlra úgy, hogy csak a Rendszergazdák csoport és a helyi rendszerfiók tagjai rendelkezzenek írási hozzáféréssel. Kivételek közé tartozik a font fájlokat (.fon), sok rendszer naplófájlok (.napló), néhány súgófájl (.chm), képek és hangfájlok (.jpg, .gif, és .wmv) és telepítőfájlok (.inf), de ezen fájlok egyikét sem lehet módosítani vagy kicserélni az Adminisztrátori jogosultság megszerzése érdekében. A \Windows\System32\Drivers eszközillesztői lehetővé tennék a könnyű eszkalációt, de az energiafelhasználóknak nincs írási hozzáférésük egyikükhöz sem.

láttam néhány .exe és .a dll szerepel a listán, bár, ezért megvizsgáltam őket a lehetséges kihasználások szempontjából. A legtöbb futtatható fájl, amelyhez az energiafelhasználók írási hozzáféréssel rendelkeznek, interaktív segédprogramok vagy csökkentett jogosultságokkal futnak. Hacsak nem tudja becsapni a rendszergazdát, hogy interaktív módon jelentkezzen be a rendszerbe, ezeket nem lehet felemelni. De van egy kirívó kivétel: ntoskrnl.exe:

így van, az energiafelhasználók kicserélhetik vagy módosíthatják a Windows operációs rendszer alapvető fájlját. Öt másodperccel a fájl módosítása után azonban a Windows File Protection (WFP) kicseréli azt egy biztonsági másolatra, amelyet a legtöbb esetben a \Windows\System32\Dllcache fájlból tölt le. Az energiafelhasználók nem rendelkeznek írási hozzáféréssel a Dllcache fájljaihoz, így nem tudja felforgatni a biztonsági másolatot. De a Power Users csoport tagjai megkerülhetik a WFP-t egy egyszerű program írásával, amely helyettesíti a fájlt, átöblíti a módosított adatokat a lemezre, majd újraindítja a rendszert, mielőtt a WFP cselekedne.
ellenőriztem, hogy ez a megközelítés működik-e, de a kérdés továbbra is az maradt, hogy ez a biztonsági rés hogyan használható fel a privilégiumok emelésére. A válasz olyan egyszerű, mint egy szétszerelő segítségével megtalálni azt a funkciót , amelyet a Windows a jogosultság-ellenőrzésekhez használ, SeSinglePrivilegeCheck, és a belépési pont javítása a lemezen lévő képen úgy, hogy mindig TRUE értéket adjon vissza, ami az eredménykód, amely azt jelzi, hogy a felhasználó jogosultsággal rendelkezik. Ha egy felhasználó egy ilyen módon módosított kernelen fut, úgy tűnik, hogy minden jogosultsággal rendelkezik, beleértve a betöltő illesztőprogramot, a tulajdonjogot és a Token létrehozását, hogy csak néhányat említsünk a jogosultságok közül, amelyeket könnyen kihasználhatnak a rendszer teljes adminisztratív ellenőrzéséhez. Bár a 64 bites Windows XP megakadályozza a kernel manipulálását PatchGuard, kevés vállalkozás fut 64 bites Windows rendszeren.
Helyett Ntoksrnl.az exe azonban nem az egyetlen módja annak, hogy a \Windows könyvtáron keresztül adminisztrátori jogosultságot érjen el. A DLL-ek közül legalább az egyik, amelyhez az alapértelmezett engedélyek lehetővé teszik a Power User, Schedsvc módosítását.dll, Windows szolgáltatásként fut a helyi Rendszerfiókban. Schedsvc.a dll az a DLL, amely megvalósítja a Windows Feladatütemező szolgáltatást. A Windows sikeresen működhet a szolgáltatás nélkül, így az energiafelhasználók tetszőleges DLL-re cserélhetik a DLL-t, például olyanra, amely egyszerűen hozzáadja fiókját a helyi Rendszergazdák csoporthoz. Természetesen a WFP ezt a fájlt is védi, így annak cseréje megköveteli az általam leírt WFP-bypass technika használatát.

már több magassági vektort azonosítottam, de folytattam a vizsgálatot a \Program Files könyvtárhoz való Energiafelhasználói hozzáféréssel, ahol a \Windows könyvtárhoz hasonló alapértelmezett engedélyeket találtam. Az energiafelhasználók alkönyvtárakat hozhatnak létre a \Program Files alatt, de nem módosíthatják az előre telepített Windows-összetevők többségét. Ismét a kivételek, mint a Windows Messenger (\Program Files\Messenger \ Msmgs.exe) és a Windows Media Player (\Program Files\Windows Media Player \ Wmplayer.exe) futtassa interaktívan.
ez nem jelenti azt, hogy a \ Program Files nem rendelkezik potenciális lyukakkal. Amikor megvizsgáltam a legfrissebb kimenetet, láttam, hogy az energiafelhasználók módosíthatják a \Program Files-ben létrehozott fájlokat vagy könyvtárakat az alap Windows telepítés során létrehozottakat követően. Az én vizsgálati rendszer \ Program Files \ Vmware \ VMware Tools \ Vmwareservice.az exe, a helyi Rendszerfiókban futó VMware Windows szolgáltatás képfájlja ilyen fájl volt. Egy másik kissé ironikus példa a Microsoft Windows Defender Beta 2, amely az alapértelmezett biztonsági beállításokkal telepíti a futtatható szolgáltatást a \Program Files\Windows Defender fájlba. Ezeknek a szolgáltatásképfájloknak a cseréje gyors elérési út a rendszergazdai jogosultsághoz, és még egyszerűbb, mint a \Windows könyvtárban lévő fájlok cseréje, mivel a WFP nem avatkozik bele a cserékbe.
ezután a következő parancs futtatásával fordítottam a figyelmemet a rendszerleíró adatbázisra:
accesschk-swk” power users ” hklm
a kimeneti lista hatalmas volt, mert a Power Users írási hozzáféréssel rendelkezik a HKLM\Software kulcs túlnyomó többségéhez. Az első terület, amelyet a lehetséges emelkedések szempontjából tanulmányoztam, a HKLM\System kulcs volt, mert az alatta lévő számos beállításhoz, például a Windows szolgáltatáshoz és a HKLM\System\CurrentControlSet\Services illesztőprogram-konfigurációs kulcsaihoz való Írási hozzáférés lehetővé tenné a helyi rendszerfiók triviális felforgatását. Az elemzés kimutatta, hogy az energiafelhasználóknak nincs írási hozzáférésük semmi jelentőshez a kulcs alatt.
a legtöbb energiafelhasználó-a HKLM másik fő ágának írható területei, az Internet Explorer, Az Explorer és fájltársításai, valamint az energiagazdálkodási konfiguráció. Az energiafelhasználók írási hozzáféréssel rendelkeznek a HKLM\Software\Microsoft\Windows\CurrentVersion\Run-hoz is, lehetővé téve számukra tetszőleges végrehajtható fájlok futtatását, amikor valaki interaktív módon bejelentkezik, de ennek kihasználásához adminisztrátori jogosultsággal rendelkező felhasználó szükséges, hogy interaktív módon jelentkezzen be a rendszerbe (ami a rendszertől függően soha nem történhet meg, vagy ritkán fordulhat elő). Csakúgy, mint a \Program Files könyvtár esetében, a Power Users alapértelmezett írási hozzáféréssel rendelkezik a HKLM\Software nem Windows alkulcsaihoz, ami azt jelenti, hogy a harmadik féltől származó alkalmazások, amelyek végrehajtható kódútvonalakat konfigurálnak a rendszerszintű rendszerleíró kulcsaikban, biztonsági réseket nyithatnak meg. A rendszerre telepített egyetlen alkalmazás, a VMWare nem.

a kutatás fennmaradó területe a Windows services volt. Az AccessChk csak a SERVICE_CHANGE_CONFIG és a WRITE_DAC szolgáltatásengedélyeket tekinti írási hozzáférésnek. A felhasználó SERVICE_CHANGE_CONFIG konfigurálhat egy tetszőleges futtatható indítani, amikor a szolgáltatás elindul, és adott WRITE_DAC tudják módosítani az engedélyeket a szolgáltatás, hogy biztosítsák maguknak SERVICE_CHANGE_CONFIG hozzáférést. AccessChk kiderült, a következő Az én állomány Windows XP SP2 rendszer:

ezután futtattam a PsService-t, hogy megnézzem azt a fiókot, amelyben a DcomLaunch szolgáltatás végrehajtja:

így a Power Users csoport tagjai egyszerűen megváltoztathatják a DComLauncher képútvonalát, hogy a saját képükre mutassanak, újraindítsák a rendszert, és adminisztrátori jogosultságokat élvezzenek.
potenciálisan lehetnek más szolgáltatások, amelyek biztonsági kihasználásokat vezetnek be. A harmadik féltől származó alkalmazások által létrehozott szolgáltatások Windows által beállított alapértelmezett engedélyei nem teszik lehetővé az energiafelhasználók írási hozzáférését, de egyes harmadik féltől származó alkalmazások egyéni engedélyeket konfigurálhatnak erre. Tény, hogy az én termelés 64 bites Windows XP telepítés AccessChk feltárja a lyuk, hogy nem csak a hatalom a felhasználók használhatják felemelni magukat, de a korlátozott felhasználók is:

most befejeztem a vizsgálatom fő szakaszát, és csak megerősítettem azt, amit mindenki mond: az energiafelhasználók csoportjának elszánt tagja meglehetősen könnyen teljes adminisztrátorrá teheti magát az operációs rendszer és a harmadik féltől származó alkalmazások által létrehozott kihasználások felhasználásával.
az utolsó lépésem az volt, hogy megnézzem, hogyan fejlődött a Microsoft megközelítése a Power Users fiókhoz az idő múlásával. Ez az 1999-es Microsoft Tudásbázis-cikk dokumentálja a híres képernyővédő magassági biztonsági rést, amely a Windows NT 4 rendszeren létezett, de a Microsoft bezárta ezt a lyukat a Windows 2000 megjelenése előtt. A KB cikk azt is mutatja, hogy a Microsoft nyilvánvalóan nem volt tisztában más, valószínűleg létező biztonsági résekkel. A Windows 2000 SP4 lyukakat is tartalmaz, de valójában valamivel biztonságosabb, mint az alapértelmezett Windows XP SP2 konfiguráció: az energiafelhasználók nem rendelkeznek írási hozzáféréssel az Ntoskrnl-hez.exe vagy a Feladatütemező képfájl, de a dcomlauncher Szolgáltatáshoz való Írási hozzáférés helyett felforgathatják a WMI szolgáltatást, amely szintén a helyi Rendszerfiókban fut.
Windows XP SP1 Hozzáadott több energiafelhasználó hiányosságok, beleértve az írási hozzáférést a kritikus rendszer fájlokat, mint Svchost.exe, A Windows service hosting folyamat és további szolgáltatások, WMI és SSDPSRV, kihasználható engedélyekkel. Számos szolgáltatás lehetővé tette a korlátozott felhasználók számára, hogy emeljék a Microsoft KB cikkében leírtak szerint ez év márciusától.
a Microsoft legújabb operációs rendszere, A Windows Vista, megszünteti az összes sebezhetőséget, amelyet az energiafelhasználók ivartalanításával írtam le, hogy a korlátozott felhasználókkal azonos módon viselkedjen. A Microsoft így bezárta az ajtót az energiafelhasználók előtt annak érdekében, hogy arra kényszerítse az informatikai munkatársakat, hogy biztosítsák rendszereiket azáltal, hogy a felhasználókat korlátozott felhasználói fiókokba vagy adminisztratív fiókokba helyezik át, ahol el kell ismerniük a rendszereik feletti végfelhasználói ellenőrzést.
a lényeg az, hogy bár a Microsoft kijavíthatja a vizsgálat során talált sebezhetőségeket, nem tudják megakadályozni, hogy harmadik féltől származó alkalmazások újakat vezessenek be, miközben megőrzik az energiafelhasználók képességét az alkalmazások és az ActiveX-vezérlők telepítésére. A tanulság az, hogy informatikai rendszergazdaként nem szabad becsapnia magát abban, hogy azt gondolja, hogy az energiafelhasználók csoportja biztonságos kompromisszum a korlátozott felhasználóként való futás útján.

eredetileg Mark Russinovich a 5/1/2006 11:01: 00 AM
vándorolt az eredeti Sysinternals.com/Blog