🥇Jeg er root. Forstå Linux OS-privilegieeskalering

Jeg brukte det første kvartalet av 2020 på å forberede OSCP-eksamenen. Å søke etter informasjon på Google og mange "blinde" forsøk tok opp all min fritid. Det var spesielt vanskelig å forstå mekanismene for å øke privilegiene. PWK-kurset legger stor vekt på dette temaet, men undervisningsmateriellet er aldri nok. Det er mange håndbøker på Internett med nyttige kommandoer, men jeg er ikke en fan av blindt å følge anbefalinger uten å forstå hva det vil føre til.

Jeg vil gjerne dele med deg hva jeg lærte under forberedelsen og vellykket bestått eksamen (inkludert periodiske forsøk på Hack The Box). Jeg følte en sterk følelse av takknemlighet for hver bit av informasjon som hjalp meg å gå Prøv Harder-banen mer bevisst, nå er tiden min for å gi tilbake til samfunnet.

Jeg vil gi deg en manual om hvordan du kan eskalere privilegier i OS Linux, som inkluderer en analyse av de vanligste vektorene og relaterte funksjoner som definitivt vil være nyttige for deg. Ofte er mekanismene for å øke privilegiene i seg selv ganske enkle; det oppstår vanskeligheter når man strukturerer og analyserer informasjon. Derfor bestemte jeg meg for å starte med en "sightseeingtur" og deretter vurdere hver vektor i en egen artikkel. Jeg håper jeg sparer deg litt tid på å undersøke emnet.

Så hvorfor er privilegieeskalering mulig i 2020 hvis metodene har vært godt kjent i svært lang tid? Faktisk, hvis brukeren håndterer systemet riktig, vil det virkelig ikke være mulig å øke privilegiene i det. Det største globale problemet som gir opphav til slike muligheter er usikker konfigurasjon. Tilstedeværelsen av utdaterte programvareversjoner som inneholder sårbarheter i systemet er også et spesielt tilfelle av en usikker konfigurasjon.

Privilegeeskalering via usikker konfigurasjon

Først, la oss håndtere usikker konfigurasjon. La oss begynne med IT-fagfolk bruker ofte manualer og ressurser som stackoverflow, hvorav mange inneholder usikre kommandoer og konfigurasjoner. Et slående eksempel - nyhetene at koden som ble mest kopiert fra stackoverflow inneholdt en feil. En erfaren administrator vil se jamben, men dette er i en ideell verden. Selv kompetente spesialister økt arbeidsmengde i stand til å gjøre feil. Tenk deg at en administrator utarbeider og koordinerer dokumentasjon for neste anbud, samtidig som den fordyper seg i den nye teknologien som skal implementeres i neste kvartal, samtidig som den med jevne mellomrom løser brukerstøtteproblemer. Og så får han i oppgave å raskt sette opp et par virtuelle maskiner og rulle ut tjenester på dem. Hva tror du er sannsynligheten for at administratoren rett og slett ikke legger merke til jamben? Da skifter spesialister, men krykkene gjenstår, mens bedriftene alltid streber etter å minimere kostnadene, også for IT-ansatte.

Pseudo-shell og jailbreak

Systemskallet som oppnås under utnyttelsesstadiet er ofte begrenset, spesielt hvis du fikk det gjennom å hacke en bruker av webserveren. For eksempel kan skjellrestriksjoner hindre deg i å kjøre sudo-kommandoen, og produsere en feil:

sudo: no tty present and no askpass program specified

Når du har et skall, anbefaler jeg å lage en fullverdig terminal, for eksempel ved å bruke Python.

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

Du kan spørre: "Hvorfor trenger jeg tusen kommandoer hvis jeg kan bruke en, for eksempel til å overføre filer?" Faktum er at systemene er konfigurert annerledes; en gitt vert har kanskje ikke Python installert, men kan ha Perl. Ferdigheten er å kunne gjøre kjente ting i systemet uten kjente verktøy. Du finner en komplett liste over funksjoner her.

Et lavt privilegert skall kan fås ved å bruke lag 1 и lag 2 (overraskende nok, til og med GIMP).

Se kommandohistorikk

Linux samler en historikk over alle utførte kommandoer i en fil ~ / .bash_history. Hvis serveren brukes aktivt og historikken ikke tømmes, er det stor sannsynlighet for å finne legitimasjon i denne filen. Å tømme historikken er rett og slett upraktisk. Hvis administratoren blir tvunget til å velge ti-etasjers kommandoer gjennom, vil det selvfølgelig være mer praktisk for ham å ringe denne kommandoen fra historien enn å skrive den inn igjen. I tillegg er det mange som ikke vet om dette "hakket". Hvis det er alternative skjell som Zsh eller Fish i systemet, har de sin egen historie. For å vise kommandohistorikken i et hvilket som helst skall, skriv inn kommandohistorikken.

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

Det er delt hosting, der serveren brukes til å være vert for flere nettsteder. Vanligvis, med denne konfigurasjonen, har hver ressurs sin egen bruker med en egen hjemmekatalog og en virtuell vert. Så hvis den er konfigurert feil, kan du finne .bash_history-filen i rotkatalogen til nettressursen.

Søking etter passord i filsystemet og angrep på tilstøtende systemer

Konfigurasjonsfiler for ulike tjenester kan være lesbare av din nåværende bruker. I dem kan du finne legitimasjon i klartekst - passord for tilgang til en database eller relaterte tjenester. Det samme passordet kan brukes både for å få tilgang til databasen og for å autorisere root-brukeren (legitimasjonsbemanning).
Det hender at legitimasjonen som er funnet tilhører tjenester på andre verter. Å utvikle et angrep på infrastruktur gjennom en kompromittert vert er ikke verre enn å utnytte andre verter. Tilstøtende systemer kan også finnes ved å slå opp IP-adresser i filsystemet.

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

Hvis den kompromitterte verten har en nettapplikasjon tilgjengelig fra Internett, er det bedre å ekskludere loggene fra søket etter IP-adresser. Adresser til ressursbrukere fra Internett er neppe nyttige for oss, men adressene til det interne nettverket (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) og hvor de går, etter loggene å dømme , kan være av interesse.

sudo

Sudo-kommandoen gir brukeren muligheten til å utføre en kommando i root-konteksten ved å bruke sitt eget passord eller uten å bruke et passord i det hele tatt. Mange operasjoner i Linux krever root-privilegier, men å kjøre som root anses som en veldig dårlig praksis. I stedet er det bedre å bruke selektiv tillatelse til å utføre kommandoer i rotkonteksten. Imidlertid kan mange Linux-verktøy, inkludert standard som vi, brukes til å eskalere privilegier på legitime måter. For å finne en passende metode anbefaler jeg å lete her.

Det første du må gjøre når du får tilgang til systemet er å kjøre kommandoen sudo -l. Den vil vise tillatelse til å bruke sudo-kommandoen. Hvis en bruker uten passord oppnås (som apache eller www-data), er privilegieeskaleringsvektoren via sudo usannsynlig. Når du bruker sudo, vil systemet be om et passord. Du vil heller ikke kunne angi et passord ved å bruke passwd-kommandoen; den vil be om brukerens gjeldende passord. Men hvis sudo fortsatt er tilgjengelig, må du i hovedsak se etter:

alle tolker, hvem som helst kan skape et skall (PHP, Python, Perl);
alle tekstredigerere (vim, vi, nano);
alle seere (mindre, mer);
enhver evne til å jobbe med filsystemet (cp, mv);
Verktøy som har utgang i bash, interaktiv eller som en kjørbar kommando (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Det er mange manualer på Internett som anbefaler å samle alle suid/sgid-kommandoer, men en sjelden artikkel gir detaljer om hva du skal gjøre med disse programmene. Alternativer for å eskalere privilegier som ikke tar hensyn til bruk av utnyttelser kan bli funnet her. En rekke kjørbare filer har også spesifikke sårbarheter for OS-versjonen, for eksempel.

I en ideell verden vil du kjøre alle installerte pakker gjennom minst searchsploit. I praksis bør dette gjøres med de mest populære programmene som sudo. Det er også alltid muligheten til å bruke og støtte utviklingen av automatiserte verktøy som vil fremheve interessante, fra synspunktet om rettighetsopptrapping, kjørbare filer med suid/sgid-bitene satt. Jeg vil gi en liste over slike verktøy i den tilsvarende delen av artikkelen.

Skrivbare skript drevet av Cron eller Init i sammenheng med Root

Cron-jobber kan kjøres under forskjellige brukerkontekster, inkludert root. Hvis en cron-oppgave er satt opp med en lenke til en kjørbar fil, og den er tilgjengelig for deg å skrive, kan den enkelt erstattes med en ondsinnet og privilegieeskalering. Men som standard er filer med cron-oppgaver lesbare av enhver bruker.

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

Situasjonen er lik med init. Forskjellen er at oppgaver i cron utføres med jevne mellomrom, og i init - ved systemoppstart. Operasjonen vil kreve en omstart av systemet, og noen tjenester vil kanskje ikke starte opp (hvis de ikke ble registrert ved oppstart).

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

Du kan også søke etter filer som kan skrives av en hvilken som helst bruker.

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

Metoden er ganske godt kjent; erfarne systemadministratorer bruker chmod-kommandoen nøye. Men på Internett beskriver de aller fleste manualer å sette maksimale rettigheter. «Bare få det til å fungere»-tilnærmingen til uerfarne systemadministratorer skaper muligheter for eskalering av privilegier i prinsippet. Hvis det er mulig, er det bedre å se i kommandohistorikken for usikker bruk av chmod.

chmod +w /path 
chmod 777 /path

Får shell-tilgang til andre brukere

Vi ser på listen over brukere i /etc/passwd. Vi tar hensyn til de som har et skall. Du kan brute disse brukerne - det er mulig at gjennom den resulterende brukeren vil det til slutt være mulig å øke privilegiene.

For å forbedre sikkerheten anbefaler jeg at du alltid følger prinsippet om minste privilegium. Det er også fornuftig å bruke tid på å sjekke usikre konfigurasjoner som kan forbli etter feilsøking - dette er den "tekniske plikten" til systemadministratoren.

Selvskrevet kode

Det er verdt å ta en nærmere titt på de kjørbare filene i hjemmekatalogen til brukeren og webserveren (/var/www/, med mindre annet er spesifisert). Disse filene kan vise seg å være en helt utrygg løsning og inneholde utrolige krykker. Selvfølgelig, hvis du har et slags rammeverk i webserverkatalogen, gir det ingen mening å se etter nulldager i den som en del av en pentest, men det anbefales å finne og studere tilpassede modifikasjoner, plugins og komponenter.

For å øke sikkerheten er det bedre om mulig å unngå å bruke legitimasjon i selvskrevne skript, samt potensielt farlig funksjonalitet, som å lese /etc/shadow eller manipulere id_rsa.

Utvidelse av privilegier gjennom utnyttelse av sårbarheter

Før du forsøker å eskalere privilegier gjennom utnyttelse, er det viktig å forstå overføre filer til målverten. I tillegg til de vanlige verktøyene som ssh, ftp, http (wget, curl) er det en hel "zoo" av muligheter.

For å forbedre systemsikkerheten, oppdater den regelmessig til den nyeste stabil versjoner, og også prøve å bruke distribusjoner designet for Enterprise. Ellers er det sjelden, men det er situasjoner der apt-oppgradering gjør systemet ubrukelig.

Utnytte tjenester som kjører under rotbrukerkonteksten

Noen Linux-tjenester kjører som root. De kan bli funnet ved å bruke kommandoen ps aux | grep rot. I dette tilfellet kan det hende at tjenesten ikke annonseres på Internett og være tilgjengelig lokalt. Hvis den har offentlige utnyttelser, kan de trygt brukes: en tjenestekrasj i tilfelle feil er mye mindre kritisk enn et krasj av operativsystemet.

ps -aux | grep root # Linux

Det mest vellykkede tilfellet kan betraktes som driften av en hacket tjeneste i sammenheng med rotbrukeren. Drift av SMB-tjenesten gir privilegert SYSTEM-tilgang på Windows-systemer (for eksempel gjennom ms17-010). Dette er imidlertid ikke vanlig på Linux-systemer, så du kan bruke mye tid på å eskalere privilegier.

Utnyttelse av Linux-kjernesårbarheter

Dette er veien du bør gå sist. Mislykket operasjon kan føre til systemkrasj, og i tilfelle en omstart kan det hende at enkelte tjenester (inkludert de som det originale skallet ble hentet gjennom) ikke starter opp. Det hender at administratoren rett og slett glemte å bruke systemctl enable-kommandoen. I tillegg vil det føre til mye misnøye med arbeidet ditt hvis operasjonen ikke ble avtalt.
Hvis du bestemmer deg for å bruke kildekodene fra exploitdb, sørg for å lese kommentarene i begynnelsen av skriptet. Blant annet står det vanligvis hvordan man korrekt kompilerer en gitt utnyttelse. Hvis du er for lat eller måtte gjøre det "i går" på grunn av tidsfrister, kan du se etter depoter med allerede kompilerte utnyttelser, for eksempel. Du bør imidlertid forstå at i dette tilfellet vil du få en gris i en poke. På den annen side, hvis en programmerer helt ned til byten forsto hvordan en datamaskin fungerer og programvaren den bruker, ville han ikke skrevet en eneste linje med kode i hele sitt liv.

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

Metasploit

For å fange opp og håndtere forbindelsen er det alltid bedre å bruke utnyttelse/multi/handler-modulen. Det viktigste er å sette riktig nyttelast, for eksempel generic/shell/reverse_tcp eller generic/shell/bind_tcp. Skallet produsert av Metasploit kan oppgraderes til Meterpreter ved å bruke post/multi/manage/shell_to_meterpreter-modulen. Med Meterpreter kan du automatisere prosessen etter utnyttelse. For eksempel sjekker post/multi/recon/local_exploit_suggester-modulen plattformen, arkitekturen og enhetene som kreves for utnyttelse og foreslår Metasploit-moduler for å eskalere privilegier på målsystemet. Takket være Meterpreter kommer eskalerende privilegier noen ganger ned til å starte den nødvendige modulen, men hacking uten å forstå hva som skjer under panseret er ikke "sant" (du må fortsatt skrive en rapport).

verktøy

Verktøy for å automatisere lokal informasjonsinnsamling vil spare deg for mye krefter og tid, men i seg selv er de ikke i stand til fullt ut å identifisere veien til eskalering av privilegier, spesielt i tilfelle utnyttelse av kjernesårbarheter. Automatiseringsverktøy vil utføre alle nødvendige kommandoer for at du skal samle informasjon om systemet, men det er også viktig å kunne analysere mottatte data. Jeg håper artikkelen min vil være nyttig for deg i denne forbindelse. Selvfølgelig er det mange flere verktøy enn jeg vil liste opp nedenfor, men de gjør alle omtrent det samme - dette er snarere en smakssak.

Linpeas

En ganske fersk Tula, den første forpliktelsen går tilbake til januar 2019. Mitt favorittverktøy for øyeblikket. Poenget er at det fremhever de mest interessante vektorene for privilegieeskalering. Enig, det er mer praktisk å få en ekspertvurdering på dette nivået enn å analysere monolittiske rådata.

Kilde: www.habr.com

Jeg er root. Forstå Linux OS Privilege Escalation