🥇Én vagyok a root. Nézzük meg a jogosultságok emelését az OS Linuxban

2020 első negyedévét az OSCP vizsgára való felkészüléssel töltöttem. Az információkeresés a Google-on és a sok „vakon” végrehajtott próbálkozás szinte minden szabadidőmet elvette. Különösen nehéz volt megérteni a jogosultságok emelésének mechanizmusait. A PWK kurzus nagy hangsúlyt fektet erre a témára, de a módszertani anyagok mindig hiányosak. Az interneten sok hasznos parancsot tartalmazó útmutató található, de nem támogatom a vak követést, anélkül hogy megérteném, hová vezet ez.

Szeretném megosztani veletek, amit a felkészülés és a sikeres vizsga során megtudtam (beleértve a Hack The Box periódikus látogatásait). Rendkívüli hálát éreztem minden egyes információért, amely segített, hogy a Try Harder utam tudatosabb legyen, most pedig eljött az idő, hogy tisztelegjek a közösség előtt.

Egy útmutatót szeretnék adni nektek az OS Linux jogosultság-emeléséről, amely a leggyakoribb vektorok és kapcsolódó trükkök elemzését tartalmazza, amelyek biztosan a hasznotokra válnak. Gyakran a jogosultságok emelésének mechanizmusai viszonylag egyszerűek, a nehézségek az információ strukturálásakor és elemzésekor adódnak. Ezért úgy döntöttem, hogy egy "áttekintő túrával" kezdem, majd minden egyes vektort külön cikkben fogok tárgyalni. Remélem, időt fogok megspórolni nektek a téma tanulmányozásában.

Tehát miért lehetséges a jogosultságok emelése 2020-ban, ha a módszerek már régóta ismertek? Valójában, ha a felhasználó megfelelően kezeli a rendszert, a jogosultságok emelése valóban nem lehetséges. A fő globális probléma, amely ilyen lehetőségeket teremthet, a nemszerveres konfiguráció.A rendszerben lévő elavult szoftverváltozatok, amelyek sebezhetőségeket tartalmaznak, szintén egy példája a nembiztonságos konfigurációnak.

Jogosultságok emelése a nembiztonságos konfiguráción keresztül

Először is nézzük meg a nembiztonságos konfigurációt. Kezdetnek az IT szakemberek gyakran használnak útmutatókat és olyan forrásokat, mint a stackoverflow,sok közülük nem biztonságos parancsokat és konfigurációkat tartalmaz. Kiváló példa, hogy hírek arról számoltak be, hogy a legtöbbet másolt kód a stackoverflow-on hibát tartalmazott. Egy tapasztalt admin látja a hibát, de ez egy ideális világ. Még a jól képzett szakemberek is, amikor megnövekedett munkaterhelés alatt vannak. hibák is előfordulhatnak. Képzelje el, hogy az adminisztrátor éppen egy dokumentációt készít és egyeztet egy újabb pályázatra, miközben egy új technológiát ismer meg, amelyet a következő negyedévben kell bevezetni, és időnként felhasználói támogatási feladatokat is megold. És ekkor gyorsan kiosztanak neki egy feladatot, hogy állítson be pár virtuális gépet és telepítse rájuk a szolgáltatásokat. Ön szerint mennyi a valószínűsége annak, hogy az admin nem észlel egy hibát? Később a szakemberek változnak, de a workaround-ok megmaradnak, miközben a vállalatok mindig arra törekednek, hogy minimalizálják a költségeket, beleértve az IT szakembereket is.

Pszicho-frontend és jailbreak

Az üzemeltetés során kapott rendszer shellje gyakran korlátozott, különösen, ha a webkiszolgáló felhasználójától törték fel. Például a shell korlátozásai megakadályozhatják a sudo parancs futtatását, hibás kimenetet adva:

sudo: nem jelenik meg tty és nem megadott askpass program

A shell megszerzése után javaslom, hogy hozzon létre egy teljes terminált, például Python segítségével.

python -c 'import pty; pty.spawn("/bin/bash")'

Megkérdezheti: "Miért van szükségem ezer parancsra, ha használhatok egyet, például fájlok átvitelére?" Az a helyzet, hogy a rendszerek különbözőképpen vannak konfigurálva, lehet, hogy a következő hoszton nincs telepítve a Python, de a Perl elérhető. A mesterség abban rejlik, hogy lehetőségünk van szokásos dolgokat csinálni a rendszerben szokásos eszközök nélkül. A teljes lista elérhetősége itt található: itt.

Alacsony jogosultságú shellt lehet kapni az alábbiak használatával parancsok 1 és parancsok 2 (meglepő, hogy még a GIMP is).

A parancsok történetének megtekintése

A Linux az összes végrehajtott parancsot összegyűjti a következő fájlban: ~/.bash_history. Ha a szerver aktívan használatban van, és a történetet nem törlik, nagy a valószínűsége, hogy megtalálja a hitelesítő adatokat ebben a fájlban. A történelem tisztítása kényelmetlen. Ha az adminisztrátornak tízlábú parancsokat kell választania, természetesen kényelmesebb lesz számára a történelemből előhívni a parancsot, mint újra beírni. Ezen kívül sokan nem tudnak erről a „hackról”. Ha a rendszerben alternatív shell-ek, mint a Zsh vagy a Fish találhatók, akkor azok saját történetet vezetnek. Bármely shell-ben a parancsok történetének megjelenítéséhez elegendő beírni a history parancsot.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Van olyan megosztott tárhely, ahol a szerver több weboldal hosztolására szolgál. Általában ilyen konfigurációban minden erőforráshoz saját felhasználó és külön állományi könyvtár, valamint virtuális hoszt tartozik. Ha a gyökérkönyvtárban a webes erőforrás rosszul van beállítva, akkor a .bash_history fájl is fellelhető.

Jelszavak keresése a fájlrendszerben és támadások a kapcsolódó rendszerek ellen

Különböző szolgáltatások konfigurációs fájlai olvashatóak a jelenlegi felhasználó számára. Ezekben nyílt szövegként találkozhatunk hitelesítő adatokkal — adatbázis-hozzáférési jelszavakkal vagy kapcsolódó szolgáltatásokhoz. Ugyanaz a jelszó használható az adatbázis elérésére és a root felhasználó azonosítására (credential staffing).
Előfordulhat, hogy a megtalált hitelesítő adatok más hosztok szolgáltatásaihoz tartoznak. A kompromittált hoszton keresztüli infrastruktúra támadása nem kevésbé hatékony, mint más hosztok kihasználása. A kapcsolódó rendszerek IP-címek fájlrendszerbeli keresésével is megtalálhatók.

grep -lRi "password" \/home \/var\/www \/var\/log 2>/dev/null | sort | uniq #Jelszó keresése (nincs cs) ezekben a könyvtárakban
grep -a -R -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' \/var\/log\/ 2>/dev/null | sort -u | uniq #IP-címek a naplókban

Ha a kompromittált hoszton van egy webalkalmazás, ami az Internetről hozzáférhető, érdemes kizárni a naplók IP-cím kereséséből. Az Interneten lévő erőforrás felhasználóinak címei valószínűleg nem lesznek hasznosak, de a belső hálózat címek (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) és az ottani belépési helyek a naplók alapján érdekesek lehetnek.

Sudo

A sudo parancs lehetővé teszi a felhasználó számára, hogy parancsokat hajtson végre root kontextusban saját jelszavával, vagy akár annak használata nélkül. Sok művelet az Linuxban root privilégiumokat igényel, de a root felhasználóként való munka nagyon rossz gyakorlatnak számít. Ehelyett jobb, ha a parancsok root kontextusban való végrehajtására választott engedélyt alkalmazunk. Sok Linux eszköz, beleértve a szokásosakat, mint a vi, teljesen legálisan használható az privilegizált műveletekhez. Ajánlom a megfelelő módszer keresését. itt.

Az első lépés, miután hozzáférést kapunk a rendszerhez, a sudo -l parancs végrehajtása. Ez megmutatja a sudo parancs használatára vonatkozó engedélyeket. Ha jelszónélküli felhasználót kaptunk (például apache vagy www-data), akkor a sudo-n keresztüli jogosultságemelés valószínűtlen. A sudo használatakor a rendszer jelszót kér. A passwd parancson keresztül jelszót megadni nem lehet, mivel megköveteli a felhasználó aktuális jelszavát. De ha a sudo mégis elérhető, akkor lényegében a következőket kell keresni:

bármilyen értelmezőt, ahol bárki elindíthat shell-t (PHP, Python, Perl);
bármilyen szövegszerkesztőt (vim, vi, nano);
bármilyen megjelenítőt (less, more);
bármilyen fájlrendszerrel kapcsolatos lehetőséget (cp, mv);
olyan eszközöket, amelyeknek hozzáférése van bash-hoz, interaktív módon vagy végrehajtható parancsként (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Az interneten számos kézikönyv található, amelyek azt javasolják, hogy gyűjtsük össze az összes suid/sgid parancsot, azonban ritkán találunk konkrét útmutatást arról, mit tegyünk ezekkel a programokkal. A jogosultságemelési lehetőségek, amelyek nem veszik figyelembe az exploiteket, megtalálhatók itt. Emellett számos végrehajtható fájl specifikus sebezhetőségekkel rendelkezik az operációs rendszer verziója szerint, például.

Ideális világban minden telepített csomagot legalább a searchsploit segítségével kellene átvizsgálni. A gyakorlatban ezt a legnépszerűbb programokkal, például a sudóval érdemes megtenni. Mindig van lehetőség automatizált eszközök használatára és fejlesztésére is, amelyek kiemelik az érdekes, jogosultságemelés szempontjából releváns végrehajtható fájlokat, amelyek suid/sgid bitekkel rendelkeznek. Az ilyen eszközök listáját a cikk megfelelő részében fogom bemutatni.

Írásra elérhető script-ek, amelyeket Cron vagy Init futtat, Root kontextusában

A cron feladatokat különböző felhasználók, beleértve a root-ot is, végrehajthatják. Ha a cron beállításakor egy végrehajtható fájlra hivatkozó feladat van, és ez írásra elérhető számunkra, akkor könnyen kicserélhető egy rosszindulatú fájlra, és végrehajtható a jogosultságemelés. Alapértelmezés szerint a cron feladatok fájljai bárki számára olvashatóak.

ls -la /etc/cron.d  # cron feladatok megjelenítése

Hasonló a helyzet az init-fel. A különbség az, hogy a cron feladatok időszakonként futnak, míg az init a rendszer indításakor. A kihasználáshoz szükség van a rendszer újraindítására, ekkor egyes szolgáltatások esetleg nem indulnak el (ha nem voltak bejegyezve az automatikus indításba).

ls -la /etc/init.d/  # inicializáló szkriptek megjelenítése

Ezen kívül meg lehet keresni a fájlokat, amelyek írásra elérhetők bármely felhasználó számára.

find / -perm -2 -type f 2>/dev/null # világosan írható fájlok keresése

A módszer elég ismert, a tapasztalt rendszergazdák gondosan használják a chmod parancsot. Az interneten azonban a legtöbb útmutató a maximális jogok beállításáról szól. A tapasztalatlan rendszergazdák „csak működjön” megközelítése alapvetően lehetőségeket teremt a jogosultságok emelésére. Ha lehetséges, jobb keresni a chmod nem biztonságos használatát a parancsok történetében.

chmod +w /path 
chmod 777 /path

Hozzáférés más felhasználók shelljéhez

Nézzük meg a felhasználók listáját a /etc/passwd fájlban. Figyeljünk azokra, akiknek van shelljük. Ezeket a felhasználókat bruteforce-olhatjuk — nem kizárt, hogy a megszerzett felhasználón keresztül végül sikerül megnövelni a jogosultságokat.

A biztonság növelése érdekében mindig ajánlom a minimális jogosultságok elvét követni. Érdemes időt szánni a nem biztonságos konfigurációk ellenőrzésére is, amelyek a hibaelhárítás után megmaradhattak — ez a rendszergazda „technikai adóssága”.

Saját kód

Érdemes alaposan megnézni a felhasználó és a webszerver otthoni könyvtárában található végrehajtható fájlokat (/var/www/, hacsak nincs más megadva). Ezek a fájlok teljesen nem biztonságos megoldásnak bizonyulhatnak, és hihetetlen trükköket tartalmazhatnak. Természetesen, ha van valamilyen keretrendszer a webszerver könyvtárában, nincs értelme zero-day keresni a peneteszt során, de a testreszabott fejlesztések, pluginek és komponensek megtalálása és tanulmányozása ajánlott.

A biztonság növelése érdekében, lehetőség szerint, érdemes elkerülni az azonosítókat saját kódban, valamint a potenciálisan veszélyes funkciókat, például a /etc/shadow olvasását vagy az id_rsa manipulálását.

Jogosultságok emelése sebezhetőségek kihasználásával

Mielőtt megpróbálnánk emelni a jogosultságokat sebezhetőségek kihasználásával, fontos megérteni fájlok átvitele a célzott hosztra. A szokásos eszközök, mint például az ssh, ftp, http (wget, curl) mellett számos „zoológiai kert” lehetőség áll rendelkezésre.

A biztonság növelése érdekében rendszeresen frissítse a rendszert a legfrissebb stabil verziókra változatokat, és próbálja meg használni az Enterprise-ra tervezett disztribúciókat. Ellenkező esetben, bár ritkán, de előfordulnak olyan helyzetek, amikor az apt upgrade a rendszert használhatatlanná teszi.

Szolgáltatások üzemeltetése a root felhasználói kontextusában

Néhány Linux szolgáltatás a privilegizált root felhasználóként fut. Ezeket a ps aux | grep root paranccsal találhatjuk meg. Fontos, hogy a szolgáltatás nem hirdethető meg a hálózaton, és csak helyben érhető el. Ha nyilvános exploitatok állnak rendelkezésre, nyugodtan használhatók: a szolgáltatás leállása egy sikertelen kísérlet esetén sokkal kevésbé kritikus, mint az operációs rendszeré.

ps -aux | grep root # Linux

A legmegfelelőbb esetnek tekinthető, ha a feltört szolgáltatás a root felhasználói kontextusában fut. Az SMB szolgáltatás kihasználása privilégizált SYSTEM hozzáférést biztosít Windows rendszerekben (például az ms17-010-en keresztül). Linux rendszerekben azonban ez ritkán fordul elő, ezért sok időt pazarolhatunk a privilégiumok megemelésére.

Linux kernel sebezhetőségek kihasználása

Ez az a megközelítés, amelyhez az utolsó lehetőségként kell folyamodnunk. A sikertelen kihasználás a rendszer összeomlásához vezethet, és egy reboot esetén egyes szolgáltatások (beleértve azokat is, amelyeken keresztül a kezdeti shellhez jutottunk) nem indulhatnak el. Előfordulhat, hogy az adminisztrátor egyszerűen elfelejtette alkalmazni a systemctl enable parancsot. Ráadásul sok elégedetlenséget okozhat, ha a kihasználás nem volt egyeztetve.
Ha az exploitdb-ből származó forráskódok használatát döntötted el, mindenképpen olvasd el a szkript elején található megjegyzéseket. Egyebek mellett ott általában le van írva, hogyan kell megfelelően lefordítani ezt az exploitot. Ha magadnak nincs kedved vagy az időkorlát miatt "már tegnap" kellett volna, kereshetsz olyan repozitóriumokat, ahol már lefordított exploitatokat találsz. például. Ugyanakkor fontos megérteni, hogy ilyen esetben egy macskát kapsz zsákban. Másrészt, ha a programozó a gép felépítését és a használt szoftvert byte-ra nézve ismerné, akkor egész életében nem írta volna meg egy sor kódot sem.

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Metasploit

A kapcsolatok befogásához és kezeléséhez mindig jobb a exploit/multi/handler modult használni. A legfontosabb a megfelelő payload beállítása, például generic/shell/reverse_tcp vagy generic/shell/bind_tcp. A Metasploitban kapott shellt a post/multi/manage/shell_to_meterpreter modul használatával Meterpreterré lehet fejleszteni. Meterpreter birtokában automatizálhatja a poszt-exploatációs folyamatokat. Például a post/multi/recon/local_exploit_suggester modul ellenőrzi a platformot, az architektúrát és a kihasználáshoz szükséges entitásokat, és javaslatokat tesz a Metasploit modulokra a célrendszeren való jogosultságok emeléséhez. A Meterpreter segítségével a jogosultságok emelése néha egy megfelelő modul indítására redukálódik, azonban a hackelés, anélkül, hogy megértenénk, mi történik a háttérben, nem "igazi" (még jelentést is kell írnia).

Helyi futtatás (web / android bemutató tesztek előkészítése és helyi futtatásuk)

A helyi információgyűjtés automatizáló eszközei jelentős mennyiségű erőt és időt spórolhatnak meg Önnek, azonban önállóan nem képesek teljes mértékben feltárni a jogosultság-emelés útját, különösen a kernel sebezhetőségek kihasználása esetén. Az automatizáló eszközök elvégzik Ön helyett a szükséges parancsokat a rendszerinformációk gyűjtésére, de fontos, hogy meg tudja elemezni a megszerzett adatokat. Remélem, hogy cikkem hasznos lesz Önnek. Természetesen sokkal több eszköz létezik, mint amennyit alább felsorolok, azonban mindegyik körülbelül ugyanazt a célt szolgálja — itt inkább ízlés kérdése.

Linpeas

Ez egy viszonylag új eszköz, az első commit 2019 januárjára datálható. Jelenleg az egyik kedvenc eszközöm. A lényege, hogy kiemeli a legérdekesebb jogosultság-emelési vektorokat. Egyetértene, hogy kényelmesebb egy szakmai értékelést kapni egy ilyen szinten, mint masszív nyers adatokkal foglalkozni?

LinEnum

A másik kedvenc eszközöm, szintén gyűjti és rendszerezi azokat az adatokat, amelyeket a helyi felsorolás eredményeként nyerünk.

Linux-exploit-suggester (1,2)

Ez a kihasználás meg fogja vizsgálni a rendszert a megfelelő körülmények esetén a kihasználáshoz. Alapvetően ugyanazt a munkát fogja elvégezni, mint a Metasploit local_exploit_suggester modulja, de nem a Metasploit moduljait, hanem a exploit-db forráskódjára mutató hivatkozásokat javasol.