🥇Jeg er root. Lær om privilegeret adgang i O.S. Linux

I det første kvartal af 2020 brugte jeg tid på at forberede mig til OSCP-eksamenen. At finde information på Google og lave mange "blinde" forsøg tog al min fritid. Det var især svært at forstå mekanismerne bag privileggehævning. PWK-kurset fokuserer meget på dette emne, men der har altid været for lidt metodisk materiale. Der er masser af manualer online med nyttige kommandoer, men jeg er ikke tilhænger af blindt at følge anbefalinger uden at forstå, hvor det fører hen.

Jeg vil gerne dele med jer, hvad jeg har lært i løbet af forberedelsen og den succesfulde beståelse af eksamen (inklusive periodiske besøg på Hack The Box). Jeg følte en dyb taknemmelighed for hver lille smule information, der hjalp mig med at navigere Try Harder-forløbet mere bevidst; nu vil jeg gerne give noget tilbage til fællesskabet.

Jeg vil give jer en manual om privileggehævning i OS Linux, som inkluderer de mest almindelige vektorer og relaterede tricks, der vil være nyttige for jer. Ofte er selve mekanismerne for privileggehævning ikke så komplekse, men udfordringer opstår, når man skal strukturere og analysere informationen. Derfor har jeg besluttet at starte med en "overordnet rundvisning" og derefter behandle hver vektor i en separat artikel. Jeg håber, jeg kan spare jer tid i jeres studier af emnet.

Så, hvorfor er privileggehævning overhovedet muligt i 2020, hvis metoderne har været velkendte i lang tid? Faktisk, med en korrekt håndtering af systemet af brugeren, er det ikke muligt at hæve privilegierne. Det grundlæggende globale problem, der skaber sådanne muligheder, er usikre konfigurationer. At have forældede versioner af software i systemet, der indeholder sårbarheder, er også et specifikt tilfælde af usikre konfigurationer.

Privileggehævning gennem usikre konfigurationer

Lad os først forstå usikre konfigurationer. Lad os begynde med, at IT-specialister ofte bruger manualer og ressourcer som stackoverflow, mange af hvilke indeholder usikre kommandoer og konfigurationer. Et tydeligt eksempel er nyheder at den mest kopierede kode fra stackoverflow indeholdt en fejl. En erfaren administrator vil se fejlene, men det er i en ideel verden. Selv dygtige specialister kan have forhøjet arbejdsbyrde. kan begå fejl. Forestil dig, at en administrator er i gang med at forberede og godkende dokumentationen til et nyt udbud, mens han samtidig sætter sig ind i en ny teknologi, som skal implementeres i næste kvartal, og regelmæssigt løser bruger-supportopgaver. Her får han lige pludselig en opgave om hurtigt at oprette et par virtuelle maskiner og implementere tjenester på dem. Hvad tror du er sandsynligheden for, at administratoren simpelthen ikke bemærker en fejl? Senere skifter specialisterne, mens de midlertidige løsninger forbliver, og virksomhederne forsøger altid at minimere omkostningerne, herunder til IT-personale.

Pseudo-shell og jailbreak

System-shell, der opnås under driftsfasen, er ofte begrænset, især hvis du har fået den via et hackerangreb på en webserver. For eksempel kan shell-begrænsninger forhindre brugen af kommandoen sudo og returnere fejlmeddelelsen:

sudo: no tty present and no askpass program specified

Efter at have fået shellen anbefaler jeg at oprette en fuld terminal, for eksempel ved hjælp af Python.

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

Du spørger: «Hvorfor har jeg brug for tusind kommandoer, når jeg kan bruge én, for eksempel til filoverførsler?» Det er fordi systemer kan være konfigureret forskelligt, og på en given vært kan Python være fraværende, men Perl være tilgængelig. Kunstfærdigheden ligger i at kunne udføre velkendte opgaver i systemet uden de sædvanlige værktøjer. En komplet liste over funktioner kan findes her.

En lavprivilegeret shell kan opnås ved at bruge kommandoer 1 og kommandoer 2 (overraskende, at selv GIMP).

Visning af kommandohistorik

Linux indsamler historien om alle udførte kommandoer i filen ~/.bash_history. Hvis serveren bruges aktivt, og dens historie ikke ryddes, er der en stor sandsynlighed for at finde legitimationsoplysninger i denne fil. At rydde historikken er simpelthen ubelejligt. Hvis administratoren er tvunget til at vælge ti-tegnede kommandoer, vil det selvfølgelig være lettere for ham at kalde denne kommando fra historikken end at indtaste den igen. Plus mange er ikke klar over denne "hack"). Hvis der findes alternative shells som Zsh eller Fish på systemet, gemmer de også deres egen historik. For at udskrive kommandohistorikken i enhver shell, er det tilstrækkeligt at skrive kommandoen history.

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

Der findes shared hosting, hvor en server bruges til at hoste flere websteder. Normalt oprettes der en bruger med sin egen hjemmemappe og en virtuel vært for hver ressource i denne konfiguration. Ved forkert opsætning kan en fil .bash_history findes i rodmappen for webressourcen.

Søgning efter adgangskoder i filsystemet og angreb på tilknyttede systemer

Konfigurationsfiler for forskellige tjenester kan være tilgængelige for læsning af din nuværende bruger. I dem kan man finde oplysninger i klartekst — adgangskoder til databasen eller tilknyttede tjenester. Den samme adgangskode kan bruges både til adgang til databasen og til autentificering af brugeren root (credential staffing).
Nogle gange tilhører de fundne legitimationsoplysninger tjenester på andre værter. Udviklingen af et angreb på infrastrukturen via en kompromitteret vært er ikke dårligere end udnyttelse af andre værter. Tilknyttede systemer kan også findes ved at søge efter 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 der er et webapplikation på den kompromitterede vært, der er tilgængelig fra internettet, er det bedst at udelukke dens logs fra søgningen efter IP-adresser. Adresserne fra brugerne af ressourcen fra internettet vil næppe være nyttige, men adresserne fra det interne netværk (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) og hvor de går hen ifølge logs kan være interessante.

Sudo

Sudo-kommandoen giver brugeren mulighed for at udføre en kommando i root-konteksten ved hjælp af sin egen adgangskode eller slet ikke bruge den. Mange operationer i Linux kræver root-rettigheder, men arbejde som root betragtes som en meget dårlig praksis. I stedet er det bedre at anvende selektive tilladelser til at udføre kommandoer i root-konteksten. Dog kan mange Linux-værktøjer, inklusive standardværktøjer som vi, bruges til at hæve rettighederne på helt legitime måder. For at finde den passende metode anbefaler jeg, at du kigger. her.

Det første, du skal gøre, når du får adgang til systemet, er at udføre kommandoen sudo -l. Denne vil vise tilladelsen til at bruge sudo-kommandoen. Hvis brugeren ikke har et kodeord (f.eks. apache eller www-data), er det usandsynligt, at der kan opnås privilegiumshøjnings gennem sudo. Ved brug af sudo vil systemet anmode om et kodeord. Du kan heller ikke ændre kodeord via kommandoen passwd, da den vil anmode om den nuværende brugers kodeord. Men hvis sudo er tilgængeligt, er det i princippet nødvendigt at lede efter:

enhver fortolker, alle kan spawne shell (PHP, Python, Perl);
enhver teksteditor (vim, vi, nano);
enhver visning (less, more);
enhver mulighed for at arbejde med filsystemet (cp, mv);
værktøjer, der har udgang til bash, interaktivt eller som en eksekverbar kommando (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Der er mange manualer på internettet, der anbefaler at samle alle suid/sgid-kommandoer, men få artikler giver konkret information om, hvad man skal gøre med disse programmer. Muligheder for privilegiumshøjnings, der ikke tager hensyn til eksploitering, kan findes. her. Desuden har en række eksekverbare filer specifikke sårbarheder for OS-versionen, for eksempel.

I en ideel verden skal alle installerede pakker i det mindste gennemgås med searchsploit. I praksis bør dette gøres med de mest populære programmer som sudo. Der er også altid mulighed for at bruge og støtte udviklingen af automatiserede værktøjer, der fremhæver interessante eksekverbare filer med sat suid/sgid-bits. Jeg vil give en liste over sådanne værktøjer i den relevante sektion af artiklen.

Skripter, der er tilgængelige for skrivning, kørt af Cron eller Init, i Root-kontekst

Cron-opgaver kan udføres i konteksten af forskellige brugere, herunder root. Hvis der er oprettet en opgave i cron, der henviser til en eksekverbar fil, og denne er tilgængelig for dig til skrivning, kan du nemt erstatte den med en ondsindet fil og udføre privilegiumshøjnings. Standardmæssigt er filer med cron-opgaver tilgængelige til læsning for enhver bruger.

ls -la /etc/cron.d  # vis cron-job

På lignende vis er det med init. Forskellen er, at opgaver i cron udføres periodisk, mens init udføres ved systemstart. For at udnytte dette kræves en genstart af systemet, og nogle tjenester kan muligvis ikke starte (hvis de ikke er angivet til automatisk opstart).

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

Man kan også lede efter filer, der kan skrives af enhver bruger.

find / -perm -2 -type f 2>/dev/null # find verdensskrevne filer

Metoden er ret kendt, og erfarne systemadministratorer bruger forsigtigt chmod-kommandoen. Dog findes der i de fleste vejledninger på nettet en beskrivelse af, hvordan man tildeler maks. rettigheder. Uerfarne systemadministratorers tilgang 'bare det fungerer' skaber generelt muligheder for forhøjelse af privilegier. Hvis det er muligt, er det bedst at søge i kommandohistorikken efter usikker brug af chmod.

chmod +w /path 
chmod 777 /path

Få adgang til shell fra andre brugere

Vi ser på listen over brugere i /etc/passwd. Vi lægger mærke til dem, der har en shell. Det kan være, at vi kan brute-force disse brugere — det er ikke udelukket, at vi kan opnå forhøjelse af privilegier gennem den opnåede bruger.

For at øge sikkerheden anbefaler jeg altid at følge princippet om minimale privilegier. Det giver også mening at bruge tid på at tjekke usikre konfigurationer, der kan være tilbage efter fejlfinding — det er 'teknisk gæld' for systemadministratoren.

Håndskrevet kode

Det er vigtigt at kigge grundigt på de eksekverbare filer i brugerens hjemmemappe og webserverens mappe (/var/www/, medmindre en anden er angivet). Disse filer kan vise sig at være en helt usikker løsning og indeholde utallige

For at forbedre sikkerheden er det bedst at undgå at bruge legitimationer i håndskrevne scripts samt potentielt farlig funktionalitet, som f.eks. at læse /etc/shadow eller manipulere med id_rsa.

Forhøjelse af privilegier gennem udnyttelse af sårbarheder

Før du forsøger at forhøje privilegier gennem udnyttelse, er det vigtigt at forstå filoverførsel til målavl. Udover de sædvanlige midler som ssh, ftp, http (wget, curl) er der et helt ‘zoo’ af muligheder.

For at forbedre systemets sikkerhed, opdater det regelmæssigt til den aktuelle stabile versioner versioner, og stræb efter at bruge distributioner, der er designet til virksomheder. Ellers kan der sjældent, men nogle gange, opstå situationer, hvor apt upgrade gør systemet ubrugeligt.

Drift af tjenester, der kører under brugeren root

Nogle Linux-tjenester kører som den privilegerede bruger root. Disse kan findes med kommandoen ps aux | grep root. En tjeneste kan dog være usynlig på nettet og kun være tilgængelig lokalt. Hvis den har offentlige exploits, kan de frit anvendes: nedbruddet af tjenesten ved en fejl er meget mindre kritisk end nedbruddet af operativsystemet.

ps -aux | grep root # Linux

Den mest succesfulde situation kan betragtes som drift af en hacked tjeneste under brugeren root. Udnyttelse af SMB-tjenesten giver privilegeret SYSTEM-adgang i Windows-systemer (f.eks. via ms17-010). Dog er dette sjældent i Linux-systemer, så man kan bruge meget tid på at hæve privilegierne.

Udnyttelse af sårbarheder i Linux-kernen

Dette er vejen, man kun bør gå som en sidste udvej. En mislykket udnyttelse kan føre til systemnedbrud, og ved genstart kan nogle tjenester (herunder dem, gennem hvilke man fik den oprindelige shell) muligvis ikke starte. Nogle gange glemmer administratoren bare at anvende kommandoen systemctl enable. Desuden vil dette skabe meget utilfredshed med dit arbejde, hvis udnyttelsen ikke var godkendt.
Hvis du har besluttet at bruge kildekoder fra exploitdb, skal du sørge for at læse kommentarer i begyndelsen af scriptet. Blandt andet står der normalt, hvordan man korrekt kompilerer denne exploit. Hvis man ikke gider, eller hvis det var nødvendigt 'i går', kan man lede efter repositories med allerede compiliterede exploits, for eksempel. Men man skal forstå, at du i så fald får en kat i sækken. På den anden side, hvis programmøren vidste alt ned til byte-niveau, hvordan computeren og det anvendte software fungerer, ville han aldrig have skrevet én linje kode i sit liv.

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

Metasploit

For capturing and handling connections, it's always better to use the exploit/multi/handler module. The key is to set the right payload, such as generic/shell/reverse_tcp or generic/shell/bind_tcp. The shell obtained in Metasploit can be upgraded to Meterpreter using the post/multi/manage/shell_to_meterpreter module. With Meterpreter, you can automate the post-exploitation process. For instance, the post/multi/recon/local_exploit_suggester module checks the platform, architecture, and necessary entities for exploitation and suggests Metasploit modules for privilege escalation on the target system. Thanks to Meterpreter, privilege escalation sometimes comes down to running the right module, but hacking without understanding what's happening under the hood isn’t 'real' (you still need to write a report).

Tools

Automation tools for local information gathering will save you a lot of effort and time; however, they alone cannot fully identify the path for privilege escalation, especially in case of kernel vulnerability exploitation. Automation tools will execute all necessary commands for system information collection on your behalf, but it's also important to be able to analyze the data obtained. I hope my article will be useful to you in this regard. Of course, there are many more tools than I will list below, but they all essentially do roughly the same — it's more a matter of preference.

Linpeas

A fairly new tool, with the first commit dating back to January 2019. Currently, it’s my favorite tool. The essence is that it highlights the most interesting privilege escalation vectors. Agree, it's more convenient to get an expert evaluation at this level than to sift through monolithic raw data.

LinEnum

My second favorite tool; it also collects and organizes data obtained from local enumeration.

Linux-exploit-suggester (1,2)

This exploit will analyze the system for suitable conditions for exploits. Essentially, it will perform the same function as the Metasploit local_exploit_suggester module but will offer links to the source codes on exploit-db instead of Metasploit modules.