🥇Ik ben root. Laten we ons verdiepen in het verhogen van de privileges in O/S Linux

In het eerste kwartaal van 2020 heb ik me voorbereid op het OSCP-examen. Het zoeken naar informatie op Google en talloze 'blinde' pogingen namen al mijn vrije tijd in beslag. Vooral het begrijpen van de mechanen van privilege-escalatie bleek een uitdaging. De PWK-cursus besteedt hier veel aandacht aan, maar er is altijd een tekort aan methodisch materiaal. Er zijn veel handleidingen op het internet met nuttige opdrachten, maar ik ben geen voorstander van blind volgen van aanbevelingen zonder te begrijpen wat de gevolgen zijn.

Ik wil graag met jullie delen wat ik heb geleerd tijdens mijn voorbereiding en het succesvol afleggen van het examen (inclusief mijn sporadische bezoeken aan Hack The Box). Ik voelde een diepe dankbaarheid voor elk klein beetje informatie dat me hielp om het Try Harder-pad bewuster te volgen; nu is het mijn tijd om de gemeenschap te eren.

Ik wil jullie een handleiding geven voor privilege-escalatie in OS Linux, die de meest voorkomende vectoren en gerelateerde trucs behandelt die je absoluut nodig zult hebben. Vaak zijn de mechanismen van privilege-escalatie relatief eenvoudig, maar de moeilijkheden ontstaan bij het structureren en analyseren van informatie. Daarom heb ik besloten te beginnen met een 'overzichts-excursie' en later elke vector in een apart artikel te behandelen. Ik hoop je tijd te besparen bij het bestuderen van het onderwerp.

Dus, waarom is privilege-escalatie in 2020 überhaupt mogelijk, als de methoden al heel lang bekend zijn? Eigenlijk is het niet mogelijk om privileges in het systeem te verhogen als de gebruiker op de juiste manier met het systeem omgaat. Het belangrijkste globale probleem dat dergelijke mogelijkheden creëert, ligt in een onveilige configuratie. Het hebben van verouderde softwareversies in het systeem met kwetsbaarheden is ook een specifiek geval van onveilige configuratie.

Privilege-escalatie via onveilige configuratie

Laten we eerst kijken naar onveilige configuratie. Laten we beginnen met het feit dat IT-specialisten vaak gebruik maken van handleidingen en bronnen zoals stackoverflow, waarvan veel onveilige opdrachten en configuraties bevatten. Een helder voorbeeld is nieuws dat de meest gekopieerde code van stackoverflow een fout bevatte. Een ervaren admin zal de fout opmerken, maar dat is in de ideale wereld. Zelfs ervaren specialisten onder een verhoogde werkdruk kan fouten maken. Stel je voor dat een admin bezig is met het voorbereiden en overeenkomen van documentatie voor een nieuwe aanbesteding, terwijl hij zich ook verdiept in een nieuwe technologie die in het komende kwartaal moet worden geïmplementeerd, en ondertussen af en toe taken oplost voor gebruikerssupport. En dan krijgt hij snel de taak om een paar virtual machines op te zetten en daarop services te installeren. Wat denk je, wat is de kans dat de admin een fout gewoon niet opmerkt? Vervolgens wisselen de specialisten, maar de tijdelijke oplossingen blijven bestaan, terwijl bedrijven altijd proberen de kosten te minimaliseren, ook op het gebied van IT-personeel.

Pseudokernel en jailbreak

Een systeemkernel, verkregen in de exploitatiestatus, is vaak beperkt, vooral als je deze hebt verkregen via een hack van de gebruiker van de webserver. Bijvoorbeeld, beperkingen van de shell kunnen het toepassen van het commando sudo belemmeren met de foutmelding:

sudo: no tty present and no askpass program specified

Na het verkrijgen van de shell raad ik aan om een volledige terminal aan te maken, bijvoorbeeld met Python.

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

Je vraagt je af: "Waarom heb ik duizend commando's nodig als ik er één kan gebruiken, bijvoorbeeld voor het overdragen van bestanden?" Het probleem is dat systemen op verschillende manieren kunnen zijn geconfigureerd, op de ene host is Python misschien niet geïnstalleerd, terwijl Perl wel beschikbaar is. De kunst is om in staat te zijn om de gebruikelijke taken met ongebruikelijke tools uit te voeren. Een volledige lijst van mogelijkheden is te vinden here.

Een laaggeprivilegieerde shell kan worden verkregen door commando's 1 en commando's 2 (verrassend genoeg zelfs GIMP).

Bekijk de opdrachtgeschiedenis

Linux verzamelt de geschiedenis van alle uitgevoerde commando's in het bestand ~/.bash_history. Als de server actief wordt gebruikt en de geschiedenis niet wordt gewist, is er een grote kans dat je in dit bestand inloggegevens vindt. De geschiedenis schoonmaken is eenvoudigweg onhandig. Als de administrator gedwongen is om tienduizenden commando's te doorzoeken, is het voor hem natuurlijk handiger om dat commando uit de geschiedenis aan te roepen dan het opnieuw in te voeren. Bovendien weten veel mensen niet van deze "hack". Als er alternatieve shells zoals Zsh of Fish aanwezig zijn, hebben zij hun eigen geschiedenis. Om de opdrachtgeschiedenis in elke shell te tonen, volstaat het om het commando history in te voeren.

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

Er bestaat shared hosting waarbij een server wordt gebruikt om meerdere websites te hosten. Gewoonlijk wordt bij deze configuratie voor elke bron een eigen gebruiker met een aparte thuismap en virtuele host aangemaakt. Bij een verkeerde configuratie kan in de hoofdmap van de webresource een bestand .bash_history worden aangetroffen.

Zoeken naar wachtwoorden in het bestandssysteem en aanvallen op gerelateerde systemen

Configuratiebestanden van verschillende diensten kunnen leesbaar zijn voor uw huidige gebruiker. Hierin kunnen openlijk opgeslagen inloggegevens worden aangetroffen, zoals wachtwoorden voor toegang tot databases of gerelateerde diensten. Eén en hetzelfde wachtwoord kan zowel voor toegang tot de database als voor de autorisatie van de root-gebruiker worden gebruikt (credential staffing).
Het komt voor dat de gevonden inloggegevens toebehoren aan diensten op andere hosts. De ontwikkeling van een aanval op de infrastructuur via een gecompromitteerde host is net zo ernstig als de exploitatie van andere hosts. Gerelateerde systemen kunnen ook worden gevonden door IP-adressen in het bestandssysteem te doorzoeken.

grep -lRi "wachtwoord" /home /var/www /var/log 2>/dev/null | sort | uniq #Vind string wachtwoord (zonder hoofdlettergevoeligheid) in deze 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 in logs

Als er op de gecompromitteerde host een webapplicatie beschikbaar is via het internet, is het beter om de logs hiervan uit te sluiten van de IP-adressenzoekopdracht. De adressen van gebruikers op de internetresource zijn voor ons waarschijnlijk niet nuttig, maar adressen van het interne netwerk (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) en de locaties waar ze naartoe gaan, afgaand op de logs, kunnen interessant zijn.

Sudo

De sudo-opdracht geeft de gebruiker de mogelijkheid om een opdracht in de context van root uit te voeren met behulp van zijn eigen wachtwoord of zelfs zonder het gebruik daarvan. Veel operaties in Linux vereisen root-rechten, maar werken vanuit root wordt als een zeer slechte praktijk beschouwd. In plaats daarvan is het beter om selectieve machtigingen voor het uitvoeren van opdrachten in de context van root toe te passen. Veel Linux-tools, waaronder standaardtools zoals vi, kunnen echter op legitieme manieren worden gebruikt om privileges te verhogen. Voor het vinden van een geschikte manier raad ik aan om te kijken. hier.

Het eerste dat je moet doen nadat je toegang hebt gekregen tot het systeem, is de opdracht sudo -l uitvoeren. Hiermee krijg je de toestemming om sudo-commando's te gebruiken. Als je een gebruiker zonder wachtwoord hebt (bijvoorbeeld apache of www-data), is de kans op privilege escalation via sudo zeer klein. Bij gebruik van sudo vraagt het systeem om een wachtwoord. Met het commando passwd kun je ook geen wachtwoord instellen; het vraagt om het huidige wachtwoord van de gebruiker. Maar als sudo wel beschikbaar is, moet je in wezen zoeken naar:

elke uitvoerbare omgeving waar iemand een shell kan spawn (PHP, Python, Perl);
elke teksteditor (vim, vi, nano);
elke viewer (less, more);
elke mogelijkheid om met het bestandssysteem te werken (cp, mv);
tools die toegang hebben tot bash, interactief of als uitvoerbare opdracht (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Er zijn tal van handleidingen op internet die adviseert om alle suid/sgid-commando's te verzamelen, maar zelden wordt specifiek aangegeven wat er met deze programma's moet gebeuren. Opties voor privilege escalation, zonder exploitatie, kunnen worden gevonden here. Ook hebben verschillende uitvoerbare bestanden specifieke kwetsbaarheden voor de versie van het besturingssysteem, bijvoorbeeld.

In een ideale wereld zou je alle geïnstalleerde pakketten minstens door searchsploit moeten laten lopen. In de praktijk moet je dit doen met de meest populaire programma's zoals sudo. Er is ook altijd de optie om geautomatiseerde tools te gebruiken en te ontwikkelen die interessante uitvoerbare bestanden met suid/sgid-bits markeren op basis van privilege escalation. Een lijst van dergelijke tools zal ik in het relevante gedeelte van het artikel geven.

Schrijfrechten scripts die worden uitgevoerd door Cron of Init in de context van Root

Cron-taken kunnen worden uitgevoerd in de context van verschillende gebruikers, inclusief root. Als er een Cron-taak is ingesteld die verwijst naar een uitvoerbaar bestand, en het beschikbaar is voor jou om te schrijven, kun je dit gemakkelijk vervangen door een kwaadaardig bestand en privilege escaluatie uitvoeren. Standaard zijn bestanden met cron-taken leesbaar voor elke gebruiker.

ls -la /etc/cron.d  # toon cron-taken

Hetzelfde geldt voor init. Het verschil is dat cron-taken periodiek worden uitgevoerd, terwijl init -taken worden uitgevoerd bij het opstarten van het systeem. Voor exploitatie is een herstart van het systeem vereist, waarbij sommige services mogelijk niet worden opgestart (als ze niet in de autostart zijn opgenomen).

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

Je kunt ook zoeken naar bestanden die door elke gebruiker schrijfbaar zijn.

find / -perm -2 -type f 2>/dev/null # vind wereld schrijfbare bestanden

De methode is vrij bekend, ervaren systeembeheerders gebruiken de chmod-opdracht zorgvuldig. Maar op het internet beschrijven de meeste handleidingen het toekennen van maximale rechten. De aanpak van onervaren systeembeheerders van "als het maar werkt" creëert in principe mogelijkheden voor privilege-escalatie. Als het kan, zoek dan in de opdrachtgeschiedenis naar onveilige toepassingen van chmod.

chmod +w /path 
chmod 777 /path

Toegang krijgen tot de shell van andere gebruikers

We bekijken de lijst met gebruikers in /etc/passwd. Let op degenen met een shell. We kunnen deze gebruikers brute-forcen — het is mogelijk dat we via de verkregen gebruiker uiteindelijk privileges kunnen verhogen.

Voor meer veiligheid raad ik aan altijd het principe van minimale privileges te volgen. Het is ook zinvol om tijd te besteden aan het controleren van onveilige configuraties die mogelijk zijn achtergebleven na troubleshooting — dit is de "technische schuld" van de systeembeheerder.

Zelfgeschreven code

Het is verstandig om aandacht te besteden aan uitvoerbare bestanden in de thuismap van de gebruiker en de webserver (/var/www/, tenzij anders ingesteld). Deze bestanden kunnen een heel onveilige oplossing blijken te zijn en ongelooflijke haken en ogen bevatten. Natuurlijk, als je een of andere framework in de directory van de webserver hebt, heeft het geen zin om hierin zero-days te zoeken in het kader van pentesten, maar het wordt aanbevolen om aangepaste aanpassingen, plugins en componenten te vinden en te bestuderen.

Voor meer veiligheid is het beter om waar mogelijk af te zien van het gebruik van wachtwoorden in zelfgeschreven scripts, evenals van potentieel gevaarlijke functionaliteit, zoals het lezen van /etc/shadow of manipulaties met id_rsa.

Privilege-escalatie via exploitatie van kwetsbaarheden

Voordat je probeert privileges te verhogen via exploitatie, is het belangrijk om te begrijpen de bestandsoverdracht naar de doelhost. Naast de gebruikelijke middelen zoals ssh, ftp, http (wget, curl) zijn er een hele ‘dierentuin’ van mogelijkheden.

Om de beveiliging van het systeem te verbeteren, update het regelmatig naar de actuele stabilen Versies, en probeer distributies te gebruiken die zijn afgestemd op Enterprise. Anders kunnen er zeldzame situaties zijn waarin apt upgrade het systeem onbruikbaar maakt.

Exploiteren van diensten die draaien in de context van de gebruiker root

Sommige Linux-diensten draaien onder de priviliged gebruiker root. Deze zijn te vinden met de opdracht ps aux | grep root. Deze dienst hoeft zich niet aan te melden op het netwerk en kan lokaal toegankelijk zijn. Als deze publieke exploits heeft, kunnen deze zonder bezwaar worden gebruikt: het falen van de dienst is veel minder kritiek dan het falen van het OS.

ps -aux | grep root # Linux

De beste situatie is wanneer een gehackt dienst draait in de context van de gebruiker root. Het exploiteren van de SMB-dienst geeft SYSTEM toegangsrechten in Windows-systemen (bijvoorbeeld via ms17-010). Echter, dit komt niet vaak voor in Linux-systemen, daarom kan er veel tijd worden besteed aan het verhogen van de privileges.

Exploiteren van kernelkwetsbaarheden in Linux

Dit is de laatste weg die je zou moeten inslaan. Een mislukte exploitatie kan leiden tot het falen van het systeem, en bij een reboot kunnen sommige diensten (inclusief die waarmee je aanvankelijk shell kreeg) mogelijk niet opnieuw opstarten. Soms vergeet de beheerder simpelweg de opdracht systemctl enable te gebruiken. Bovendien zal dit veel ontevredenheid veroorzaken over je werk als de exploitatie niet is goedgekeurd.
Als je besluit om de broncodes uit exploitdb te gebruiken, lees dan zeker de opmerkingen aan het begin van het script. Daar staat meestal ook hoe je deze exploit correct moet compileren. Als je er zelf geen zin in hebt of als de deadline "gisteren" was, kun je zoeken naar repositories met al samengestelde exploits. bijvoorbeeld. Maar begrijp dat je in dat geval een kat in de zak krijgt. Aan de andere kant, als een programmeur het tot op de byte zou begrijpen van hoe een computer werkt en de software die hij gebruikt, zou hij in zijn leven geen regel code hebben geschreven.

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

Metasploit

Om een verbinding te vangen en te verwerken, is het altijd beter om de module exploit/multi/handler te gebruiken. Het belangrijkste is om de juiste payload in te stellen, zoals generic/shell/reverse_tcp of generic/shell/bind_tcp. De shell die je in Metasploit krijgt, kan worden verbeterd tot Meterpreter met behulp van de module post/multi/manage/shell_to_meterpreter. Met Meterpreter kun je het proces van post-exploitatie automatiseren. Bijvoorbeeld, de module post/multi/recon/local_exploit_suggester controleert het platform, de architectuur en de benodigde entiteiten voor exploitatie en biedt Metasploit-modules aan voor verhoogde privileges op het doel systeem. Dankzij Meterpreter kan privilege-escalatie soms worden teruggebracht tot het uitvoeren van de juiste module, maar hacken zonder te begrijpen wat er onder de motorkap gebeurt is niet "echt" (je moet uiteindelijk nog wel een rapport schrijven).

Tools

Automatiseringstools voor lokale informatieverzameling besparen je veel moeite en tijd, maar zelf zijn ze niet in staat om volledig de weg naar privilege-escalatie te bepalen, vooral niet bij het exploiteren van kernel kwetsbaarheden. Automatiseringstools voeren alle noodzakelijke commando's uit voor het verzamelen van systeeminformatie, maar het is ook belangrijk om de verkregen gegevens te begrijpen. geanalyseerd worden Ik hoop dat mijn artikel je hierbij nuttig zal zijn. Natuurlijk zijn er veel meer tools dan ik hieronder zal noemen, maar ze doen ongeveer hetzelfde — het is eerder een kwestie van voorkeur.

Linpeas

Een relatief nieuwe tool, de eerste commit dateert van januari 2019. Momenteel is dit mijn favoriete tool. Het idee is dat het de meest interessante privilege-escalatie vectoren markeert. Je moet toegeven, het is handiger om een deskundige beoordeling op dit niveau te krijgen dan om monolithische ruwe gegevens te analyseren.

LinEnum

Mijn tweede favoriete tool, die ook gegevens verzamelt en systematiseert die zijn verkregen door lokaal opsporen.

Linux-exploit-suggester (1,2)

Deze exploit zal het systeem analyseren op geschikte voorwaarden voor exploits. Het zal feitelijk hetzelfde werk doen als de Metasploit local_exploit_suggester module, maar in plaats van Metasploit-modules, zal het links naar de broncodes van exploit-db aanbieden.