Jeg brugte det første kvartal af 2020 på at forberede os til OSCP-eksamenen. Søgning efter information på Google og en masse "blinde" forsøg tog al min fritid. Det viste sig at være særligt svært at forstå mekanismerne for eskalering af privilegier. PWK-kurset lægger stor vægt på dette emne, men metodiske materialer er altid ikke nok. Der er mange manualer på internettet med nyttige kommandoer, men jeg er ikke tilhænger af blindt at følge anbefalingerne uden at forstå, hvor det vil føre hen.
Jeg vil gerne dele med dig, hvad jeg formåede at lære under forberedelsen og den vellykkede beståelse af eksamen (inklusive periodiske raids på Hack The Box). Jeg følte en dyb følelse af taknemmelighed for hver en smule information, der hjalp mig til at gå Try Harder-stien mere bevidst, nu er det min tid til at give tilbage til samfundet.
Jeg vil gerne give dig en guide til privilegieeskalering i OS Linux, som inkluderer en analyse af de mest almindelige vektorer og relaterede funktioner, som du helt sikkert får brug for. Ofte er privilegie-eskaleringsmekanismerne i sig selv ret enkle, der opstår vanskeligheder ved strukturering og analyse af information. Derfor besluttede jeg at starte med en "sightseeing-tur" og derefter overveje hver vektor i en separat artikel. Jeg håber, jeg vil spare dig tid til at studere emnet.
Så hvorfor er privilegieeskalering overhovedet mulig i 2020, hvis metoderne har været velkendte i meget lang tid? Faktisk, hvis brugeren håndterer systemet korrekt, vil det virkelig ikke være muligt at øge privilegier i det. Det største globale problem, der giver anledning til sådanne muligheder, er usikker konfiguration. Tilstedeværelsen af forældede softwareversioner, der indeholder sårbarheder i systemet, er også et særligt tilfælde af en usikker konfiguration.
Privilegeeskalering gennem usikker konfiguration
Først og fremmest, lad os beskæftige os med den usikre konfiguration. Lad os begynde med IT-professionelle bruger ofte manualer og ressourcer som stackoverflow, hvoraf mange indeholder usikre kommandoer og konfigurationer. Et slående eksempel er at den kode, der blev kopieret mest fra stackoverflow, indeholdt en fejl. En erfaren administrator vil se jamben, men dette er i en ideel verden. Selv kompetente fagfolk øget arbejdsbyrde i stand til at lave fejl. Forestil dig, at administratoren forbereder og godkender dokumentation til næste udbud, samtidig med at den dykker ned i den nye teknologi, der introduceres i næste kvartal, og samtidig løser brugersupportopgaver med jævne mellemrum. Og så får han til opgave hurtigt at rejse et par virtuelle maskiner og udrulle tjenester på dem. Hvad tror du, hvad er sandsynligheden for, at administratoren simpelthen ikke bemærker jamben? Så skifter specialisterne, men krykkerne bliver tilbage, mens virksomhederne altid stræber efter at minimere omkostningerne, også dem til it-specialister.
Pseudo-shell og jailbreak
Systemskallen opnået i produktionsfasen er ofte begrænset, især hvis du opnåede den ved at hacke en webserverbruger. For eksempel kan shell-begrænsninger forhindre dig i at bruge sudo-kommandoen med en fejl:
sudo: no tty present and no askpass program specifiedEfter at have fået en shell, anbefaler jeg at oprette en fuldgyldig terminal, for eksempel med Python.
python -c 'import pty;pty.spawn("/bin/bash")'Du spørger: "Hvorfor har jeg brug for tusinde kommandoer, hvis jeg for eksempel kan bruge en til at overføre filer?" Faktum er, at systemerne er konfigureret anderledes, på den næste vært er Python muligvis ikke installeret, men Perl kan være tilgængelig. Færdigheden er at kunne gøre velkendte ting i systemet uden kendte værktøjer. En komplet liste over funktioner kan findes .
En lav privilegeret shell kan fås ved hjælp af и (overraskende endda GIMP).
Se kommandohistorik
Linux samler en historik over alle udførte kommandoer i en fil ~ / .bash_history. Hvis serveren er i aktiv brug, og dens historie ikke er ryddet, er der en god chance for, at legitimationsoplysningerne findes i denne fil. At rydde historien er banalt ubelejligt. Hvis administratoren er tvunget til at vælge kommandoer på ti niveauer via , vil det selvfølgelig være mere bekvemt for ham at kalde denne kommando fra historikken end at indtaste den igen. Plus, mange kender ikke til dette "hack". Hvis der er alternative skaller som Zsh eller Fish i systemet, har de deres egen historie. For at vise historikken for kommandoer i en hvilken som helst shell, skal du blot skrive kommandohistorikken.
cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_historyDer er delt hosting, hvor serveren bruges til at være vært for flere websteder. Med denne konfiguration har hver ressource typisk sin egen bruger med en separat hjemmemappe og en virtuel vært. Så hvis den er konfigureret forkert, kan du finde .bash_history-filen i webressourcens rodbibliotek.
At finde adgangskoder i filsystemet og angreb på tilstødende systemer
Konfigurationsfiler for forskellige tjenester kan læses af din nuværende bruger. I dem kan du finde legitimationsoplysninger i klar tekst - adgangskoder til adgang til databasen eller relaterede tjenester. Den samme adgangskode kan bruges både til at få adgang til databasen og til at autorisere root-brugeren (legitimationsbemanding).
Det sker, at de fundne legitimationsoplysninger tilhører tjenester på andre værter. Udviklingen af et angreb på infrastrukturen gennem en kompromitteret vært er ikke værre end udnyttelsen af andre værter. Tilstødende systemer kan også findes ved at slå IP-adresser op 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 logsHvis den kompromitterede vært har en webapplikation, der er tilgængelig fra internettet, er det bedre at udelukke dens logfiler fra søgningen efter IP-adresser. Det er usandsynligt, at adresserne på ressourcebrugere fra internettet er nyttige for os, men adresserne på 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, at dømme efter logs, kan være af interesse.
sudo
Sudo-kommandoen giver brugeren mulighed for at udføre en kommando i forbindelse med root med deres egen adgangskode eller helt uden at bruge den. Mange operationer i Linux kræver root-privilegier, men at køre som root betragtes som meget dårlig praksis. I stedet er det bedre at anvende selektiv tilladelse til at udføre kommandoer i root-konteksten. Imidlertid kan mange Linux-værktøjer, inklusive standardværktøjerne som vi, bruges til at eskalere privilegier på legitime måder. For at finde den rigtige vej anbefaler jeg at kigge .
Den første ting at gøre efter at have fået adgang til systemet er at køre sudo -l kommandoen. Det vil vise tilladelse til at bruge sudo-kommandoen. Hvis der opnås en bruger uden adgangskode (såsom apache eller www-data), er en sudo-privilegie-eskaleringsvektor usandsynlig. Når du bruger sudo, vil systemet bede om en adgangskode. Brug af passwd-kommandoen til at indstille en adgangskode vil heller ikke virke, den vil bede om den aktuelle brugeradgangskode. Men hvis sudo stadig er tilgængelig, så skal du faktisk kigge efter:
- alle tolke, alle kan skabe en shell (PHP, Python, Perl);
- alle teksteditorer (vim, vi, nano);
- alle seere (mindre, mere);
- eventuelle muligheder for at arbejde med filsystemet (cp, mv);
- værktøjer, der har output i bash, enten interaktivt eller som en eksekverbar kommando (awk, find, nmap, tcpdump, man, vi, vim, ansible).
Suid/Sgid
Der er mange manualer på internettet, der råder til at bygge alle suid/sgid-kommandoer, men en sjælden artikel giver detaljer om, hvad man skal gøre med disse programmer. Der kan findes muligheder for eskalering af privilegier, der ikke tager højde for brugen af udnyttelser . Desuden har en række eksekverbare filer specifikke sårbarheder for OS-versionen, .
I en ideel verden bør du køre alle installerede pakker gennem mindst searchsploit. I praksis bør dette gøres med de mest populære programmer som sudo. Det er også altid en mulighed at bruge og understøtte udviklingen af automatiserede værktøjer, der vil fremhæve interessante, fra et privilegie-eskaleringssynspunkt, eksekverbare filer med suid/sgid bits sat. Jeg vil give en liste over sådanne værktøjer i den tilsvarende sektion af artiklen.
Skrivbare scripts køres af Cron eller Init i root-kontekst
Cron-job kan køre i sammenhæng med forskellige brugere, inklusive root. Hvis der er en opgave i cron med et link til en eksekverbar fil, og den er tilgængelig for dig at skrive, kan du nemt erstatte den med en ondsindet og udføre privilegieeskalering. Samtidig er filer med cron-opgaver som standard tilgængelige for læsning af enhver bruger.
ls -la /etc/cron.d # show cron jobs Det samme er tilfældet med init. Forskellen er, at opgaver i cron udføres periodisk, og i init - ved systemstart. Til drift skal du genstarte systemet, mens nogle af tjenesterne muligvis ikke stiger (hvis de ikke blev registreret i autoload).
ls -la /etc/init.d/ # show init scripts Du kan også søge efter filer, der kan skrives af enhver bruger.
find / -perm -2 -type f 2>/dev/null # find world writable filesMetoden er ret velkendt, erfarne systemadministratorer bruger omhyggeligt kommandoen chmod. Men på nettet beskriver langt de fleste manualer indstilling af maksimale rettigheder. Uerfarne systemadministratorers "bare få det til at fungere"-tilgangen skaber principielt muligheder for privilegieeskalering. Hvis det er muligt, er det bedst at kigge i kommandohistorikken for usikker brug af chmod.
chmod +w /path
chmod 777 /pathFår shell-adgang for andre brugere
Vi ser på listen over brugere i /etc/passwd. Vi er opmærksomme på dem, der har en skal. Du kan brute disse brugere - det er muligt, at gennem den resulterende bruger vil du til sidst være i stand til at øge privilegier.
For at forbedre sikkerheden anbefaler jeg, at du altid overholder princippet om mindste privilegium. Det giver også mening at tage sig tid til at kontrollere usikre konfigurationer, der kunne forblive efter fejlfinding - dette er systemadministratorens "tekniske pligt".
Selvskrevet kode
Det er værd at se nærmere på de eksekverbare filer i brugerens og webserverens hjemmemappe (/var/www/ medmindre andet er angivet). Disse filer kan vise sig at være en fuldstændig usikker løsning og indeholde utrolige krykker. Selvfølgelig, hvis du har nogle rammer i din webserver-mappe, giver det ikke mening at søge efter zero-day i det som en del af en pentest, men det anbefales at finde og studere tilpassede ændringer, plugins og komponenter.
For at øge sikkerheden er det bedre at undgå at bruge legitimationsoplysninger i selvskrevne scripts, såvel som potentielt farlig funktionalitet, såsom at læse /etc/shadow eller manipulere id_rsa, hvis det er muligt.
Forhøjelse af privilegier gennem udnyttelse af sårbarheder
Før du forsøger at hæve privilegier gennem udnyttelse, er det vigtigt at forstå overføre filer til målværten. Ud over de sædvanlige værktøjer som ssh, ftp, http (wget, curl) er der en hel .
For at forbedre sikkerheden på dit system skal du opdatere det regelmæssigt til det nyeste stabil versioner, og forsøg også at bruge distributioner designet til Enterprise. Ellers sjældent, men der er situationer, hvor apt upgrade gør systemet ubrugeligt.
Udnyttelse af tjenester, der kører i sammenhæng med rodbrugeren
Nogle Linux-tjenester kører som den privilegerede brugerrod. De kan findes ved hjælp af ps aux | grep root. I dette tilfælde vil tjenesten muligvis ikke blive annonceret på nettet og være tilgængelig lokalt. Hvis det har offentlige udnyttelser, kan de sikkert bruges: et tjenestenedbrud i tilfælde af fejl er meget mindre kritisk end et OS-nedbrud.
ps -aux | grep root # LinuxDet mest succesrige tilfælde kan betragtes som driften af en hacket tjeneste i sammenhæng med root-brugeren. Betjening af SMB-tjenesten giver SYSTEM privilegeret adgang på Windows-systemer (f.eks. via ms17-010). Dette er dog ikke almindeligt på Linux-systemer, så du kan bruge meget tid på privilegie-eskalering.
Udnyttelse af Linux-kernesårbarheder
Dette er den sidste vej at gå. Mislykket drift kan føre til et systemnedbrud, og i tilfælde af en genstart vil nogle tjenester (inklusive dem, hvorigennem det var muligt at få den originale shell) muligvis ikke stige. Det sker, at administratoren simpelthen har glemt at bruge kommandoen systemctl enable. Derudover vil det give en masse utilfredshed med dit arbejde, hvis udnyttelsen ikke er aftalt.
Hvis du beslutter dig for at bruge kilderne fra exploitdb, skal du sørge for at læse kommentarerne i begyndelsen af scriptet. Der står blandt andet som regel, hvordan man kompilerer denne udnyttelse korrekt. Hvis du var for doven eller havde brug for "i går" på grund af deadlines, kan du kigge efter repositories med allerede kompilerede exploits, . Det skal dog forstås, at i dette tilfælde vil du få en gris i en poke. På den anden side, hvis en programmør forstod til byten, hvordan en computer fungerer og den software, den bruger, ville han ikke have skrevet en linje kode i hele sit liv.
cat /proc/version
uname -a
searchsploit "Linux Kernel" Metasploit
For at fange og håndtere en forbindelse er det altid bedre at bruge modulet exploit/multi/handler. Det vigtigste er at indstille den korrekte nyttelast, for eksempel generic/shell/reverce_tcp eller generic/shell/bind_tcp. Skallen opnået i Metasploit kan opgraderes til Meterpreter ved hjælp af post/multi/manage/shell_to_meterpreter-modulet. Med Meterpreter kan du automatisere processen efter udnyttelse. For eksempel tjekker post/multi/recon/local_exploit_suggester-modulet platformen, arkitekturen og enheder, der kan udnyttes, og foreslår Metasploit-moduler til privilegieeskalering på målsystemet. Takket være Meterpreter kommer privilegieeskalering nogle gange ned til at køre det rigtige modul, men hacking uden at forstå, hvad der sker under motorhjelmen, er ikke sandt (du skal stadig skrive en rapport).
Værktøjer
Værktøjer til at automatisere lokal indsamling af information vil spare dig for mange kræfter og tid, men er i sig selv ikke i stand til fuldt ud at identificere privilegieeskaleringsstien, især i tilfælde af udnyttelse af kernesårbarheder. Automatiseringsværktøjer udfører alle de nødvendige kommandoer for at du kan indsamle information om systemet, men det er også vigtigt at kunne analysere modtagne data. Jeg håber, at min artikel vil være nyttig for dig i dette. Selvfølgelig er der mange flere værktøjer, end jeg vil liste nedenfor, men de gør alle omtrent det samme – det er mere en smagssag.
Et ret friskt værktøj, den første commit er dateret januar 2019. I øjeblikket mit yndlingsinstrument. Den nederste linje er, at den fremhæver de mest interessante privilegie-eskaleringsvektorer. Enig, det er mere bekvemt at få en ekspertvurdering på dette niveau end at analysere monolitiske rådata.
Mit andet yndlingsværktøj, det indsamler og organiserer også de data, der modtages som et resultat af lokal optælling.
Denne udnyttelse vil analysere systemet for passende betingelser for udnyttelser. Faktisk vil det udføre et job, der er identisk med Metasploit local_exploit_suggester-modulet, men vil tilbyde links til exploit-db-kildekoder i stedet for Metasploit-moduler.
Dette script vil indsamle og organisere efter sektioner en stor mængde information, der kan være nyttig til dannelsen af en privilegie-eskaleringsvektor.
En anden gang vil jeg uddybe .
Kilde: www.habr.com