🥇Ik ben wortel. Inzicht in OS Linux privilege-escalatie

Het eerste kwartaal van 2020 heb ik besteed aan de voorbereiding op het OSCP-examen. Informatie zoeken op Google en veel "blinde" pogingen namen al mijn vrije tijd in beslag. Het bleek bijzonder moeilijk te zijn om de mechanismen voor het escaleren van privileges te begrijpen. De PWK-cursus besteedt veel aandacht aan dit onderwerp, maar methodologische materialen zijn altijd niet voldoende. Er zijn veel handleidingen op internet met handige commando's, maar ik ben er geen voorstander van om blindelings de aanbevelingen op te volgen zonder te begrijpen waar dit toe zal leiden.

Ik wil graag met je delen wat ik heb geleerd tijdens de voorbereiding en het succesvol behalen van het examen (inclusief periodieke raids op Hack The Box). Ik voelde een diep gevoel van dankbaarheid voor elk stukje informatie dat me hielp om het Try Harder-pad bewuster te bewandelen, nu is het mijn tijd om terug te geven aan de gemeenschap.

Ik wil je een gids geven voor privilege-escalatie in OS Linux, inclusief een analyse van de meest voorkomende vectoren en gerelateerde functies die je zeker nodig zult hebben. Vaak zijn de privilege-escalatiemechanismen zelf vrij eenvoudig, er doen zich moeilijkheden voor bij het structureren en analyseren van informatie. Daarom besloot ik om te beginnen met een "sightseeingtour" en vervolgens elke vector in een apart artikel te bekijken. Ik hoop dat ik je tijd zal besparen om het onderwerp te bestuderen.

Dus waarom is escalatie van privileges zelfs mogelijk in 2020 als de methoden al heel lang bekend zijn? Als de gebruiker correct met het systeem omgaat, is het in feite niet mogelijk om de rechten erin te vergroten. Het belangrijkste wereldwijde probleem dat dergelijke kansen creëert, is onveilige configuratie. Ook de aanwezigheid van verouderde softwareversies met kwetsbaarheden in het systeem is een bijzonder geval van een onveilige configuratie.

Escalatie van bevoegdheden door onveilige configuratie

Laten we eerst eens kijken naar de onveilige configuratie. Laten we beginnen met IT-professionals gebruiken vaak handleidingen en bronnen zoals stackoverflow, waarvan vele onveilige opdrachten en configuraties bevatten. Een treffend voorbeeld is het nieuws dat de meest gekopieerde code van stackoverflow een fout bevatte. Een ervaren admin zal de stijl zien, maar dit is in een ideale wereld. Zelfs bekwame professionals verhoogde werkdruk in staat om fouten te maken. Stel je voor dat de beheerder documentatie voorbereidt en goedkeurt voor de volgende aanbesteding, terwijl hij zich tegelijkertijd verdiept in de nieuwe technologie die in het volgende kwartaal wordt geïntroduceerd, terwijl hij periodiek gebruikersondersteuningstaken oplost. En dan krijgt hij de taak om snel een paar virtuele machines op te zetten en daar services op uit te rollen. Wat denk je, wat is de kans dat de beheerder de stijl gewoon niet opmerkt? Dan veranderen de specialisten, maar de krukken blijven, terwijl bedrijven er altijd naar streven de kosten te minimaliseren, ook die voor IT-specialisten.

Pseudoshell en ontsnapping uit de gevangenis

De systeemschil die tijdens de productiefase is verkregen, is vaak beperkt, vooral als u deze hebt verkregen door een webservergebruiker te hacken. Shell-beperkingen kunnen bijvoorbeeld voorkomen dat u de sudo-opdracht met een fout gebruikt:

sudo: no tty present and no askpass program specified

Nadat ik een shell heb gekregen, raad ik aan om een volwaardige terminal te maken, bijvoorbeeld met Python.

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

U vraagt: "Waarom heb ik duizend commando's nodig, als ik er bijvoorbeeld één kan gebruiken om bestanden over te dragen?" Het feit is dat systemen anders zijn geconfigureerd, op de volgende host is Python mogelijk niet geïnstalleerd, maar Perl is mogelijk beschikbaar. De vaardigheid is om vertrouwde dingen in het systeem te kunnen doen zonder bekende tools. Een volledige lijst met functies is te vinden hier.

Een shell met lage bevoegdheden kan worden verkregen met behulp van teams 1 и teams 2 (verrassend zelfs GIMP).

Commandogeschiedenis bekijken

Linux verzamelt een geschiedenis van alle uitgevoerde commando's in een bestand ~ / .bash_geschiedenis. Als de server actief wordt gebruikt en de geschiedenis niet is gewist, is de kans groot dat de inloggegevens in dit bestand worden gevonden. Het wissen van de geschiedenis is banaal onhandig. Als de beheerder gedwongen wordt om commando's van tien niveaus te selecteren via , is het natuurlijk handiger voor hem om dit commando uit de geschiedenis op te roepen dan om het opnieuw in te voeren. Bovendien weten velen niet van deze "hack". Als er alternatieve shells zoals Zsh of Fish in het systeem zijn, hebben ze hun eigen geschiedenis. Om de geschiedenis van commando's in een willekeurige shell weer te geven, typt u gewoon de commandogeschiedenis.

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

Er is shared hosting, waarbij de server wordt gebruikt om meerdere sites te hosten. Doorgaans heeft elke resource bij deze configuratie zijn eigen gebruiker met een afzonderlijke homedirectory en een virtuele host. Dus als het verkeerd is geconfigureerd, kunt u het bestand .bash_history vinden in de hoofdmap van de webresource.

Het vinden van wachtwoorden in het bestandssysteem en aanvallen op aangrenzende systemen

Configuratiebestanden voor verschillende services kunnen leesbaar zijn voor uw huidige gebruiker. Daarin vindt u inloggegevens in duidelijke tekst - wachtwoorden voor toegang tot de database of gerelateerde services. Hetzelfde wachtwoord kan zowel worden gebruikt om toegang te krijgen tot de database als om de rootgebruiker te autoriseren (credential staffing).
Het komt voor dat de gevonden inloggegevens behoren tot services op andere hosts. De ontwikkeling van een aanval op de infrastructuur via een gecompromitteerde host is niet erger dan de uitbuiting van andere hosts. Aangrenzende systemen kunnen ook worden gevonden door IP-adressen op te zoeken in het bestandssysteem.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
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 #IPs inside logs

Als de gecompromitteerde host een webtoepassing heeft die toegankelijk is via internet, is het beter om de logboeken ervan uit te sluiten van het zoeken naar IP-adressen. De adressen van brongebruikers van internet zijn waarschijnlijk niet nuttig voor ons, maar de adressen van het interne netwerk (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) en waar ze naartoe gaan, te oordelen naar de logs, kan interessant zijn.

sudo

Met het sudo-commando kan de gebruiker een commando uitvoeren in de context van root met zijn eigen wachtwoord of helemaal zonder het te gebruiken. Veel bewerkingen in Linux vereisen rootrechten, maar het uitvoeren als root wordt als zeer slecht beschouwd. In plaats daarvan is het beter om selectieve toestemming toe te passen om opdrachten in de rootcontext uit te voeren. Veel Linux-tools, inclusief de standaardtools zoals vi, kunnen echter worden gebruikt om privileges op legitieme manieren te escaleren. Om de juiste weg te vinden, raad ik aan om te kijken hier.

Het eerste dat u moet doen nadat u toegang tot het systeem hebt gekregen, is de opdracht sudo -l uitvoeren. Het geeft toestemming om de sudo-opdracht te gebruiken. Als een gebruiker zonder wachtwoord wordt verkregen (zoals apache of www-data), is een sudo-privilege-escalatievector onwaarschijnlijk. Bij gebruik van sudo zal het systeem om een wachtwoord vragen. Het gebruik van de opdracht passwd om een wachtwoord in te stellen zal ook niet werken, het zal om het huidige gebruikerswachtwoord vragen. Maar als sudo nog steeds beschikbaar is, moet je in feite zoeken naar:

elke tolk, iedereen kan een shell spawnen (PHP, Python, Perl);
alle teksteditors (vim, vi, nano);
eventuele kijkers (minder, meer);
eventuele mogelijkheden om met het bestandssysteem te werken (cp, mv);
tools die uitvoer hebben in bash, interactief of als een uitvoerbaar commando (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Er zijn veel handleidingen op internet die adviseren om alle suid / sgid-commando's te bouwen, maar een zeldzaam artikel geeft details over wat te doen met deze programma's. Er zijn opties voor privilege-escalatie die geen rekening houden met het gebruik van exploits hier. Ook hebben een aantal uitvoerbare bestanden specifieke kwetsbaarheden voor de OS-versie, bij voorbeeld.

In een ideale wereld zou u alle geïnstalleerde pakketten op zijn minst door searchsploit moeten laten lopen. In de praktijk zou dit moeten gebeuren met de meest populaire programma's zoals sudo. Het is ook altijd een optie om de ontwikkeling van geautomatiseerde tools te gebruiken en te ondersteunen die, vanuit het oogpunt van escalatie van bevoegdheden, interessante uitvoerbare bestanden met suid/sgid-bits instellen. Ik zal een lijst van dergelijke tools geven in het overeenkomstige gedeelte van het artikel.

Beschrijfbare scripts uitgevoerd door Cron of Init in rootcontext

Cron-taken kunnen worden uitgevoerd in de context van verschillende gebruikers, inclusief root. Als er een taak in cron is met een link naar een uitvoerbaar bestand, en het is voor u beschikbaar om te schrijven, kunt u deze eenvoudig vervangen door een kwaadwillende taak en privilege-escalatie uitvoeren. Tegelijkertijd zijn bestanden met cron-taken standaard beschikbaar voor lezen door elke gebruiker.

ls -la /etc/cron.d  # show cron jobs

Hetzelfde is het geval met init. Het verschil is dat taken in cron periodiek worden uitgevoerd en in init - bij het opstarten van het systeem. Voor gebruik moet u het systeem opnieuw opstarten, terwijl sommige services mogelijk niet stijgen (als ze niet zijn geregistreerd in autoload).

ls -la /etc/init.d/  # show init scripts

U kunt ook zoeken naar bestanden die door elke gebruiker kunnen worden geschreven.

find / -perm -2 -type f 2>/dev/null # find world writable files

De methode is vrij bekend, ervaren systeembeheerders gebruiken zorgvuldig de opdracht chmod. Op het web beschrijft de overgrote meerderheid van de handleidingen echter het instellen van maximale rechten. De "laat het gewoon werken"-benadering van onervaren systeembeheerders creëert in principe kansen voor escalatie van bevoegdheden. Indien mogelijk is het het beste om in de opdrachtgeschiedenis te kijken naar onveilig gebruik van chmod.

chmod +w /path 
chmod 777 /path

Shell-toegang verkrijgen voor andere gebruikers

We bekijken de lijst met gebruikers in /etc/passwd. We besteden aandacht aan degenen die een schaal hebben. U kunt deze gebruikers bruteren - het is mogelijk dat u via de resulterende gebruiker uiteindelijk de rechten kunt vergroten.

Om de veiligheid te verbeteren, raad ik u aan om altijd het principe van de minste privileges aan te houden. Het is ook zinvol om de tijd te nemen om onveilige configuraties te controleren die kunnen blijven bestaan na het oplossen van problemen - dit is de "technische plicht" van de systeembeheerder.

Zelf geschreven code

Het is de moeite waard om de uitvoerbare bestanden in de homedirectory van de gebruiker en webserver (/var/www/ tenzij anders vermeld) nauwkeurig te bekijken. Deze bestanden kunnen een volledig onveilige oplossing blijken te zijn en ongelooflijke krukken bevatten. Als je een bepaald framework in je webserverdirectory hebt, heeft het natuurlijk geen zin om daarin te zoeken naar zero-day als onderdeel van een pentest, maar het wordt aanbevolen om aangepaste aanpassingen, plug-ins en componenten te vinden en te bestuderen.

Om de veiligheid te verhogen, is het beter om het gebruik van inloggegevens in zelfgeschreven scripts te vermijden, evenals potentieel gevaarlijke functionaliteit, zoals het lezen van /etc/shadow of het manipuleren van id_rsa, indien mogelijk.

Verhoging van privileges door misbruik van kwetsbaarheden

Voordat u probeert om privileges te verhogen door middel van uitbuiting, is het belangrijk om de bestanden overbrengen naar de doelhost. Naast de gebruikelijke tools als ssh, ftp, http (wget, curl) is er een geheel "dierentuin" van mogelijkheden.

Om de veiligheid van uw systeem te verbeteren, dient u het regelmatig bij te werken naar de nieuwste versie stal versies, en probeer ook distributies te gebruiken die zijn ontworpen voor Enterprise. Anders zelden, maar er zijn situaties waarin apt-upgrade het systeem onbruikbaar maakt.

Services exploiteren die worden uitgevoerd in de context van de rootgebruiker

Sommige Linux-services worden uitgevoerd als de bevoorrechte root van de gebruiker. Ze kunnen worden gevonden met behulp van de ps aux | grep wortel. In dit geval wordt de service mogelijk niet aangekondigd op internet en is deze lokaal beschikbaar. Als het openbare exploits heeft, kunnen ze veilig worden gebruikt: een servicecrash in geval van een storing is veel minder kritiek dan een OS-crash.

ps -aux | grep root # Linux

Het meest succesvolle geval kan worden beschouwd als de werking van een gehackte service in de context van de rootgebruiker. Het gebruik van de SMB-service geeft SYSTEM bevoorrechte toegang op Windows-systemen (bijv. via ms17-010). Dit is echter niet gebruikelijk op Linux-systemen, dus u kunt veel tijd besteden aan privilege-escalatie.

Exploitatie van kwetsbaarheden in de Linux-kernel

Dit is de laatste weg die we moeten bewandelen. Een mislukte bewerking kan leiden tot een systeemcrash en in het geval van een herstart kunnen sommige services (inclusief die waardoor het mogelijk was om de originele shell te krijgen) niet stijgen. Het komt voor dat de beheerder simpelweg vergat de opdracht systemctl enable te gebruiken. Bovendien zorgt het voor veel onvrede over je werk als de uitbuiting niet is afgesproken.
Als u besluit de bronnen van exploitdb te gebruiken, lees dan zeker de opmerkingen aan het begin van het script. Er staat onder andere meestal in hoe deze exploit correct moet worden gecompileerd. Als je te lui was of "gisteren" nodig had vanwege deadlines, kun je zoeken naar repositories met reeds gecompileerde exploits, bij voorbeeld. Het moet echter duidelijk zijn dat u in dit geval een varken in de zak krijgt. Aan de andere kant, als een programmeur tot op de letter begreep hoe een computer werkt en welke software hij gebruikt, zou hij zijn hele leven geen regel code hebben geschreven.

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

Metasploit

Om een verbinding op te vangen en af te handelen, is het altijd beter om de exploit/multi/handler-module te gebruiken. Het belangrijkste is om de juiste payload in te stellen, bijvoorbeeld generic/shell/reverce_tcp of generic/shell/bind_tcp. De shell verkregen in Metasploit kan worden geüpgraded naar Meterpreter met behulp van de module post/multi/manage/shell_to_meterpreter. Met Meterpreter kunt u het post-exploitatieproces automatiseren. De module post/multi/recon/local_exploit_suggester controleert bijvoorbeeld het platform, de architectuur en exploiteerbare entiteiten en stelt Metasploit-modules voor voor privilege-escalatie op het doelsysteem. Dankzij Meterpreter komt privilege-escalatie soms neer op het uitvoeren van de juiste module, maar hacken zonder te begrijpen wat er onder de motorkap gebeurt, is niet waar (je moet nog steeds een rapport schrijven).

Tools

Tools om het lokaal verzamelen van informatie te automatiseren, zullen u veel moeite en tijd besparen, maar zijn op zichzelf niet in staat om het pad naar escalatie van privileges volledig te identificeren, vooral in het geval van misbruik van kernelkwetsbaarheden. Automatiseringstools voeren alle benodigde opdrachten voor u uit om informatie over het systeem te verzamelen, maar het is ook belangrijk om dit te kunnen analyseren ontvangen data. Ik hoop dat mijn artikel hierin nuttig voor je zal zijn. Natuurlijk zijn er veel meer tools dan ik hieronder zal opsommen, maar ze doen allemaal ongeveer hetzelfde - het is meer een kwestie van smaak.

Linerwten

Een vrij nieuwe tool, de eerste commit dateert van januari 2019. Momenteel mijn favoriete instrument. Het komt erop neer dat het de meest interessante vectoren voor privilege-escalatie benadrukt. Mee eens, het is handiger om op dit niveau een deskundige beoordeling te krijgen dan om monolithische ruwe gegevens te ontleden.

Bron: www.habr.com

ik ben wortel. Inzicht in Linux OS-privilege-escalatie