Jag är root. Förstå Linux OS Privilege Escalation

Jag tillbringade det första kvartalet 2020 med att förbereda mig för OSCP-provet. Att söka information på Google och en massa "blinda" försök tog upp all min lediga tid. Det visade sig vara särskilt svårt att förstå mekanismerna för att eskalera privilegier. PWK-kursen ägnar stor uppmärksamhet åt detta ämne, men metodiskt material är alltid inte tillräckligt. Det finns många manualer på Internet med användbara kommandon, men jag är ingen anhängare av att blint följa rekommendationerna utan att förstå vart detta leder.

Jag skulle vilja dela med mig av vad jag lyckades lära mig under förberedelserna och framgångsrika godkända provet (inklusive periodiska räder på Hack The Box). Jag kände en djup känsla av tacksamhet för varje bit av information som hjälpte mig att gå Try Harder-vägen mer medvetet, nu är det dags att ge tillbaka till samhället.

Jag vill ge dig en guide till privilegieskalering i OS Linux, som inkluderar en analys av de vanligaste vektorerna och relaterade funktioner som du definitivt kommer att behöva. Ofta är själva privilegieupptrappningsmekanismerna ganska enkla, svårigheter uppstår när man strukturerar och analyserar information. Därför bestämde jag mig för att börja med en "sightseeingtur" och sedan överväga varje vektor i en separat artikel. Jag hoppas att jag sparar tid för dig att studera ämnet.

Så varför är privilegieupptrappning ens möjlig 2020 om metoderna har varit välkända under mycket lång tid? Faktum är att om användaren hanterar systemet korrekt kommer det verkligen inte att vara möjligt att öka privilegierna i det. Det största globala problemet som ger upphov till sådana möjligheter är osäker konfiguration. Förekomsten av föråldrade programvaruversioner som innehåller sårbarheter i systemet är också ett specialfall av en osäker konfiguration.

Privilegiumupptrappning genom osäker konfiguration

Först och främst, låt oss ta itu med den osäkra konfigurationen. Låt oss börja med IT-proffs använder ofta manualer och resurser som stackoverflow, av vilka många innehåller osäkra kommandon och konfigurationer. Ett slående exempel är nyheterna att koden som kopierades mest från stackoverflow innehöll ett fel. En erfaren administratör kommer att se jamben, men detta är i en idealisk värld. Även kompetenta proffs ökad arbetsbelastning kan göra misstag. Föreställ dig att administratören förbereder och godkänner dokumentation inför nästa anbud, samtidigt som han fördjupar sig i den nya tekniken som kommer att introduceras under nästa kvartal, samtidigt som den periodvis löser användarstödsuppgifter. Och så får han i uppdrag att snabbt höja ett par virtuella maskiner och rulla ut tjänster på dem. Vad tror du, vad är sannolikheten att administratören helt enkelt inte märker jamben? Sedan byter specialisterna, men kryckorna finns kvar samtidigt som företagen alltid strävar efter att minimera kostnaderna, även för IT-specialister.

Pseudo-skal och jailbreak

Systemskalet som erhålls under produktionsfasen är ofta begränsat, speciellt om du skaffat det genom att hacka en webbserveranvändare. Till exempel kan skalbegränsningar hindra dig från att använda sudo-kommandot med ett fel:

sudo: no tty present and no askpass program specified

Efter att ha skaffat ett skal rekommenderar jag att du skapar en fullfjädrad terminal, till exempel med Python.

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

Du frågar: "Varför behöver jag tusen kommandon, om jag till exempel kan använda ett för att överföra filer?" Faktum är att systemen är konfigurerade på olika sätt, på nästa värd kanske Python inte installeras, men Perl kan vara tillgänglig. Färdigheten är att kunna göra bekanta saker i systemet utan bekanta verktyg. En komplett lista över funktioner kan hittas här.

Ett lågprivilegierat skal kan erhållas med hjälp av lag 1 и lag 2 (överraskande till och med GIMP).

Visa kommandohistorik

Linux samlar in en historik över alla körda kommandon i en fil ~ / .bash_history. Om servern är i aktiv användning och dess historik inte rensas, finns det en god chans att referenserna finns i den här filen. Att rensa historien är banalt obekvämt. Om administratören tvingas välja kommandon på tio nivåer via , är det naturligtvis bekvämare för honom att anropa detta kommando från historiken än att skriva in det igen. Plus att många inte känner till detta "hack". Om det finns alternativa skal som Zsh eller Fish i systemet har de sin egen historia. För att visa historiken för kommandon i valfritt skal, skriv bara kommandohistoriken.

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

Det finns delad hosting, där servern används för att vara värd för flera webbplatser. Vanligtvis, med denna konfiguration, har varje resurs sin egen användare med en separat hemkatalog och en virtuell värd. Så om den är felaktigt konfigurerad kan du hitta filen .bash_history i webbresursens rotkatalog.

Hitta lösenord i filsystemet och attacker mot angränsande system

Konfigurationsfiler för olika tjänster kan vara läsbara av din nuvarande användare. I dem kan du hitta autentiseringsuppgifter i klartext - lösenord för åtkomst till databasen eller relaterade tjänster. Samma lösenord kan användas både för att komma åt databasen och för att auktorisera root-användaren (legitimationspersonal).
Det händer att de hittade referenserna tillhör tjänster på andra värdar. Utvecklingen av en attack på infrastrukturen genom en komprometterad värd är inte värre än utnyttjandet av andra värdar. Intilliggande system kan också hittas genom att slå upp 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

Om den komprometterade värden har en webbapplikation tillgänglig från Internet, är det bättre att utesluta dess loggar från sökningen efter IP-adresser. Adresserna till resursanvändare från Internet är osannolikt användbara för oss, men adresserna till det interna nätverket (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) och vart de går, att döma av loggar, kan vara av intresse.

sudo

Kommandot sudo låter användaren utföra ett kommando i root-sammanhang med sitt eget lösenord eller utan att använda det alls. Många operationer i Linux kräver root-privilegier, men att köra som root anses vara mycket dålig praxis. Istället är det bättre att använda selektiv behörighet för att utföra kommandon i rotkontexten. Men många Linux-verktyg, inklusive standardverktyg som vi, kan användas för att eskalera privilegier på legitima sätt. För att hitta rätt sätt rekommenderar jag att du letar här.

Det första du ska göra efter att ha fått tillgång till systemet är att köra kommandot sudo -l. Det kommer att visa behörighet att använda kommandot sudo. Om en användare utan lösenord erhålls (som apache eller www-data) är det osannolikt att eskaleringsvektorn för sudo-privilegier uppstår. När du använder sudo kommer systemet att fråga efter ett lösenord. Att använda kommandot passwd för att ställa in ett lösenord kommer inte heller att fungera, det kommer att fråga efter det aktuella användarlösenordet. Men om sudo fortfarande är tillgängligt måste du faktiskt leta efter:

• alla tolkar, vem som helst kan skapa ett skal (PHP, Python, Perl);
• alla textredigerare (vim, vi, nano);
• alla tittare (färre, fler);
• eventuella möjligheter att arbeta med filsystemet (cp, mv);
• verktyg som har utdata i bash, antingen interaktivt eller som ett körbart kommando (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Det finns många manualer på Internet som rekommenderar att man bygger alla suid/sgid-kommandon, men en sällsynt artikel ger detaljer om vad man ska göra med dessa program. Alternativ för eskalering av privilegier som inte tar hänsyn till användningen av utnyttjande kan hittas här. Dessutom har ett antal körbara filer specifika sårbarheter för OS-versionen, exempelvis.

I en idealisk värld bör du köra alla installerade paket genom åtminstone searchsploit. I praktiken bör detta göras med de mest populära programmen som sudo. Det är också alltid ett alternativ att använda och stödja utvecklingen av automatiserade verktyg som kommer att lyfta fram intressanta, ur en privilegieskaleringssynpunkt, körbara filer med suid/sgid-bitar inställda. Jag kommer att ge en lista över sådana verktyg i motsvarande avsnitt av artikeln.

Skrivbara skript som körs av Cron eller Init i root-sammanhang

Cron-jobb kan köras i olika användares sammanhang, inklusive root. Om det finns en uppgift i cron med en länk till en körbar fil, och den är tillgänglig för dig att skriva, kan du enkelt ersätta den med en skadlig och utföra privilegieskalering. Samtidigt är filer med cron-uppgifter som standard tillgängliga för läsning av alla användare.

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

Liknande är fallet med init. Skillnaden är att uppgifter i cron exekveras med jämna mellanrum och i init - vid systemstart. För drift måste du starta om systemet, medan vissa av tjänsterna kanske inte kommer upp (om de inte registrerades i autoload).

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

Du kan också söka efter filer som kan skrivas av vilken användare som helst.

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

Metoden är ganska välkänd, erfarna systemadministratörer använder noggrant kommandot chmod. Men på webben beskriver de allra flesta manualer att sätta maximala rättigheter. "Just make it work"-metoden hos oerfarna systemadministratörer skapar i princip möjligheter till privilegieskalering. Om möjligt är det bäst att leta i kommandohistoriken efter osäker användning av chmod.

chmod +w /path 
chmod 777 /path

Får skalåtkomst för andra användare

Vi tittar på listan över användare i /etc/passwd. Vi uppmärksammar dem som har ett skal. Du kan brute dessa användare - det är möjligt att du genom den resulterande användaren så småningom kommer att kunna öka privilegier.

För att förbättra säkerheten rekommenderar jag att du alltid följer principen om minsta privilegium. Det är också vettigt att ta sig tid att kontrollera osäkra konfigurationer som kan finnas kvar efter felsökning - detta är systemadministratörens "tekniska plikt".

Självskriven kod

Det är värt att ta en närmare titt på de körbara filerna i användarens och webbserverns hemkatalog (/var/www/ om inget annat anges). Dessa filer kan visa sig vara en helt osäker lösning och innehålla otroliga kryckor. Naturligtvis, om du har något ramverk i din webbserverkatalog, är det inte meningsfullt att söka efter nolldagar i den som en del av ett pentest, men det rekommenderas att hitta och studera anpassade modifieringar, plugins och komponenter.

För att öka säkerheten är det bättre att undvika att använda referenser i självskrivna skript, såväl som potentiellt farliga funktioner, som att läsa /etc/shadow eller manipulera id_rsa, om möjligt.

Förhöjning av privilegier genom utnyttjande av sårbarheter

Innan du försöker höja privilegier genom exploatering är det viktigt att förstå överföra filer till målvärden. Förutom de vanliga verktygen som ssh, ftp, http (wget, curl) finns det en helhet "zoo" av möjligheter.

För att förbättra säkerheten för ditt system, uppdatera det regelbundet till det senaste stabil versioner och även försöka använda distributioner designade för Enterprise. Annars sällan, men det finns situationer när apt uppgradering gör systemet oanvändbart.

Utnyttja tjänster som körs i rotanvändarens sammanhang

Vissa Linux-tjänster körs som den privilegierade användarroten. De kan hittas med hjälp av ps aux | grep root. I det här fallet kanske tjänsten inte annonseras på webben och är tillgänglig lokalt. Om det har offentliga utnyttjande kan de användas säkert: en tjänstkrasch i händelse av fel är mycket mindre kritisk än en OS-krasch.

ps -aux | grep root # Linux

Det mest framgångsrika fallet kan betraktas som driften av en hackad tjänst i sammanhanget med rotanvändaren. Att använda SMB-tjänsten ger SYSTEM privilegierad åtkomst på Windows-system (t.ex. via ms17-010). Detta är dock inte vanligt på Linux-system, så du kan spendera mycket tid på privilegieskalering.

Utnyttja Linux-kärnas sårbarheter

Detta är den sista vägen att ta. Misslyckad operation kan leda till en systemkrasch, och i händelse av en omstart kan vissa tjänster (inklusive de genom vilka det var möjligt att få det ursprungliga skalet) inte stiga. Det händer att administratören helt enkelt glömde att använda kommandot systemctl enable. Dessutom kommer det att orsaka mycket missnöje med ditt arbete om utnyttjandet inte har kommit överens om.
Om du bestämmer dig för att använda källorna från exploitdb, se till att läsa kommentarerna i början av skriptet. Bland annat brukar det stå hur man kompilerar denna exploit på rätt sätt. Om du var för lat eller behövde "igår" på grund av deadlines, kan du leta efter arkiv med redan kompilerade exploits, exempelvis. Det bör dock förstås att i det här fallet kommer du att få en gris i en poke. Å andra sidan, om en programmerare förstod för byten hur en dator fungerar och vilken programvara den använder, skulle han inte ha skrivit en rad kod i hela sitt liv.

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

Metasploit

För att fånga och hantera en anslutning är det alltid bättre att använda modulen exploit/multi/hanterare. Huvudsaken är att ställa in rätt nyttolast, till exempel generic/shell/reverce_tcp eller generic/shell/bind_tcp. Skalet som erhålls i Metasploit kan uppgraderas till Meterpreter med post/multi/manage/shell_to_meterpreter-modulen. Med Meterpreter kan du automatisera processen efter exploatering. Till exempel kontrollerar post/multi/recon/local_exploit_suggester-modulen plattformen, arkitekturen och exploateringsbara enheter och föreslår Metasploit-moduler för privilegieskalering på målsystemet. Tack vare Meterpreter kommer privilegieeskalering ibland till att köra rätt modul, men att hacka utan att förstå vad som händer under huven är inte sant (du måste fortfarande skriva en rapport).

verktyg

Verktyg för att automatisera lokal insamling av information kommer att spara mycket ansträngning och tid, men i sig själva kan de inte helt identifiera privilegieskaleringsvägen, särskilt i fallet med att utnyttja kärnans sårbarheter. Automationsverktyg kommer att utföra alla nödvändiga kommandon för att du ska kunna samla in information om systemet, men det är också viktigt att kunna analysera mottagna data. Jag hoppas att min artikel kommer att vara användbar för dig i detta. Naturligtvis finns det många fler verktyg än jag kommer att lista nedan, men alla gör ungefär samma sak – det är mer en smaksak.

Linärter

Ett ganska nytt verktyg, det första åtagandet är daterat i januari 2019. För närvarande mitt favoritinstrument. Summan av kardemumman är att den belyser de mest intressanta privilegieskaleringsvektorerna. Håller med, det är bekvämare att få en expertbedömning på denna nivå än att analysera monolitiska rådata.

LinEnum

Mitt andra favoritverktyg, det samlar också in och organiserar data som tas emot som ett resultat av lokal uppräkning.

linux-exploit-suggester(1,2)

Denna exploatering kommer att analysera systemet för lämpliga förhållanden för exploateringar. Faktum är att det kommer att göra jobbet identiskt med local_exploit_suggester Metasploit-modulen, men kommer att erbjuda länkar till exploit-db-källkoder istället för Metasploit-moduler.

Linuxprivchecker

Det här skriptet kommer att samla in och organisera efter sektioner en stor mängd information som kan vara användbar för att bilda en privilegieskaleringsvektor.

En annan gång ska jag utveckla det Eskalering av Linux-privilegier via suid/sgid.

Källa: will.com