Kommer jiggy med Busybox og LD_PRELOAD

Hvad er den vigtigste komponent i et operativsystem? Nå nok er det kernen. Og hvis noget går galt med kernen og dets tilknyttede filer, vil du ikke være i stand til din boks, ikke? Eksempel, den initrd problem vi talte om for nogle år siden.

Men hvad med glibc? Hvad sker der, hvis du sletter nogle af de vigtige C-biblioteker, der styrer dit startede system? Hvordan ville du gå om at komme sig fra en sådan fiasko? I denne vejledning skal jeg deltage i nogle halvmassede hackery og lære dig alle mulige gode selvreddelsesmetoder til at fastsætte turbobrudte systemer ved hjælp af busybox og et par andre flotte tricks. Hvis du stadig spekulerer på, er dette en Linux guide. Efter mig.

Scenario

Okay. Lad os tale om vores system og hvordan vi nemt kan ødelægge det. Til lidt, lidt baggrund på, hvordan Linux fungerer under da hood. Jeg har allerede forklaret dette i detaljer i min fjerde hacking tutorial, men her er en kort recap. Og vær venlig at undskylde lingo, jeg kommer ikke til at være 100% præcis her.

Linux-programmer kommer normalt i to smag - eksekverbare og fælles biblioteker, som normalt er dynamisk forbundet. Programmerne er udarbejdet i Executable og Linkable Format (ELF), som definerer hvordan programkoden skal indlæses i hukommelsen og udføres.

Indlæsningen af ​​data i hukommelsen falder på skuldrene af to andre programmer, standard C-biblioteket (glibc) og den dynamiske linker (ld), som kalder på delte biblioteker, som programmerne er blevet udarbejdet sammen med. Alle oplysninger om filstrukturen, herunder segmenter, sektioner, symboler og lignende, gemmes i ELF'en, og kan analyseres ved hjælp af kommandoen for læsning.

Læs selv, header

Læs selv, sektionsoverskrifter

Hvis du skal fjerne enten glibc eller ld, vil de fleste programmer stoppe med at fungere, fordi de ikke kan laste ind i hukommelsen og køre korrekt. Så hvad sker der, hvis du sletter, siger /usr/lib64/glibc.so.6-fil, som tilfældigvis er dette meget kritiske bibliotek?

/ bin / ld -v
GNU ld-version 2.25-17.fc23

/usr/lib64/libc.so.6
GNU C Library (GNU libc) stabil udgivelsesversion 2.22, af Roland McGrath et al.
Ophavsret (C) 2015 Free Software Foundation, Inc.
Dette er gratis software; se kilden til kopieringsbetingelser.
Der er ingen garanti; ikke engang for SALGBARHED ELLER EGNETHED TIL ET BESTEMT FORMÅL.
Udarbejdet af GNU CC version 5.3.1 20151207 (Red Hat 5.3.1-2).
Tilgængelige udvidelser:
C stubs add-on versionen 2.1.2.
crypt add-on version 2.1 af Michael Glad og andre
GNU Libidn af Simon Josefsson
Native POSIX Threads Library af Ulrich Drepper et al
BIND-8.2.3-T5B
RT bruger linux kernel aio
libc ABI'er: UNIQUE IFUNC
For fejlrapporteringsinstruktioner, se venligst:
<Http://www.gnu.org/software/libc/bugs.html>.

Under alle omstændigheder er dette, hvad der vil ske - Jeg vil målrettet IKKE skrive kommandoen, der flytter libc biblioteket væk fra dets naturlige sted, så du ikke ved et uheld kopiere det og ødelægge din boks. Men når du gør det, vil enhver efterfølgende kommando, du forsøger at køre, ikke allerede er blevet indlæst i hukommelsen, mislykkes:

ls
ls: fejl under indlæsning af delte biblioteker: libc.so.6: kan ikke åbne delt objektfil: Ingen sådan fil eller mappe

Kan ikke åbne

Og hvis vi forsøger at rette ved at flytte glibc tilbage til sin plads igen, ingen glæde:

Kan ikke rettes

Fang 22. Vi har brug for libc.so.6 for at indlæse andre biblioteker, men det er væk. Derfor vil ingenting fungere. På dette tidspunkt vil de fleste panikere, genstarte og så panikere lidt mere. Igen, ingen biggie, start i en live session, kopier filerne til deres rette sted, og Bob er din onkel. Men vi vil diskutere det særskilt. Lad os fokusere på vores specialværktøjer i handel - Busybox og LD_PRELOAD hack. Men først en ansvarsfraskrivelse.

Forbehold

Nu, før vi går videre, lad os klargøre nogle få punkter. En, du skal altid have fulde data sikkerhedskopier og system billeder, for netop denne type scenarier. To, du bør aldrig slette kritiske systemfiler, så vær forsigtig med dine sudo eller root rettigheder. Tre, du skal være behagelig at arbejde på kommandolinjen. Fire, du har brug for en åben rodskal til den slags arbejde, vi vil gøre i dag, ellers fungerer det ikke rigtigt. Sidst men ikke mindst, prøv det ikke hjemme, medmindre du virkelig ved hvad du laver. Bonus, du kan altid rette brudte Linux-systemer ved at starte i en live session. Nu og fremad.

busybox

Hvis du ikke er bekendt med busybox, er det et godt værktøj. For det første er det en særlig snefnug. I modsætning til de fleste andre programmer er det designet til at køre på egen hånd uden nogen afhængighed af delte biblioteker. Årsagen er, busybox er standardskallen i små indlejrede enheder, og den skal være stram og uafhængig, så du kan udføre kritiske funktioner uden at stole på tonsvis af data, som du ikke kan gemme i den meget begrænsede hukommelse på embedded hardware.

Hvis det ikke er installeret, få det. For eksempel, på Fedora 23, det er ikke der, så du bliver nødt til at installere hele 1.2MB værdien af ​​egenkapitalen. Så lad os undersøge programmets underskrift. Vigtigst er det ikke en dynamisk forbundet eksekverbar.

ldd / usr / sbin / busybox
ikke en dynamisk eksekverbar

fil / usr / sbin / busybox
/ usr / sbin / busybox: ELF 64-bit LSB eksekverbar, x86-64, version 1 (SYSV), statisk forbundet, strippet

Programmet er helt selvafhængigt. Det har ingen fancy symboler, gruppesektioner, dynamisk sektion, flytninger eller understøttede afviklingsafsnit. Hvis du ikke er en udvikler, kan nogle af disse ting være sejre, men hvad det fortæller os er, at busybox kan leve alene, uden at det afhænger af glibc og ld.

Gruppesektioner

Dynamisk sektion

Relocations

Afvikl sektioner

...

Sektion til segmentkortlægning:
Segmentafdelinger ...
00 .note.gnu.build-id .init .text .fini .rodata .eh_frame
01 .data .bss
02 .note.gnu.build-id
03

Der er ingen dynamisk sektion i denne fil.

Der er ingen flytninger i denne fil.

Afkodningen af ​​unwind sektioner til maskintype Advanced Micro Devices X86-64 understøttes ikke i øjeblikket.

Ingen versionsoplysninger fundet i denne fil.

Viser notater fundet ved filforskydning 0x00000120
med længde 0x00000024:
Ejer Datastørrelse Beskrivelse
GNU 0x00000014 NT_GNU_BUILD_ID
Build ID: 7a9ff994b55730b373cabf88c8ca219d7b40f652

Programmet kommer med tonsvis af buildins. Dybest set, stort set enhver kommando, du kan tænke på, har Busybox. Hvis du f.eks. Vil se listen over indlæste kernemoduler, kører du derefter busybox lsmod. Det kommer også med vigtige funktioner som su, mv, cp, ifconfig og andre. I det væsentlige skal du kunne gøre alt.

Kommandoer

Og så bliver rettelsen simpelthen (som defineret i vores eksempel):

busybox mv /lib64/libc.so.6.bak /lib64/libc.so.6

Root tilladelser

Nu vil alt ovenstående kun fungere, hvis du har en root shell indeni som du vil køre din travlbox. Det virker ikke, hvis du forsøger at gøre systemændringer fra en brugerskal. Årsagerne er indlysende, fordi det ville gøre det muligt for nogen som helst at få adgang til root.

Selvtilladelser

busybox chown roger / usr / sbin / busybox
chown: / usr / sbin / busybox: Drift er ikke tilladt

/ usr / sbin / busybox rm /usr/lib64/libc.so.6.bak
rm: fjern '/usr/lib64/libc.so.6.bak'? y
rm: kan ikke fjerne '/usr/lib64/libc.so.6.bak': Tilladelse nægtet

busybox su
su: skal være syd for at fungere ordentligt

Et trick ville være at setuid på den travle box binære - ved roden, FØR en fiasko. Da den er ejet af rod, så i teorien, ja, alle, der kører skallen, skal kunne gøre ting som rod. Imidlertid vil moderne sikkerhedsmekanismer som SELinux og AppArmor hæmme din indsats, og så er det stadig ikke noget, der skal være let at opnå af åbenbare grunde. Du vil virkelig ikke have en shell, der giver brugerne adgang til root. Tænk over det. Og pas på.

sudo chmod + s / usr / sbin / busybox

Ikke en sølvkugle

Så selvom du har rod, kan du måske ikke gøre alt, især hvis du har ødelagt en sådan fin og delikat blomst som glibc. Jeg indrømmer at det ikke er den typiske usecase for busybox, men hvis du forsøger at su i root med busybox på et system, der ikke har sin glibc på det rigtige sted, vil du mislykkes. Rigtigt så.

Kan ikke su

Boot spil

Du kan forsøge at være ekstra klog og logge ind i busybox i de tidlige stadier af systemstart. På samme måde som du ville erklære init = / bin / bash på et typisk og funktionelt Linux-system for at nulstille root-adgangskoden, kan du gå til dette her. Bortset fra uden glibc får du nok en god, saftig kerne panik. Så det samme gælder, hvis du forsøger at påberåbe busybox som din init.

Hvad hvis du ikke har busybox?

På nogle systemer er busybox muligvis ikke tilgængelig. Ideelt, ja, hvis cacky rammer fanen, vil dit system, mens du forsøger at starte, falde ind i en busybox-skal og lade dig gøre alle mulige flotte magi. Men hvis det ikke er der, er der stadig nogle seje skjulte godbidder, der hjælper dig med at ordne din ødelagte boxen.

LD_PRELOAD

I vores eksempel ødelagde vi kun en fil, men ld.so skal stadig være funktionel. Hvilket betyder at det kan indlæse objekter, men problemet er, glibc laster først. Heldigvis kan du bruge LD_PRELOAD miljøvariablen til at fortælle din løbeskal at først indlæse bestemte objekter før andre, og forhåbentlig omgå glibc-problemet.

Taler om glibc er der mere end en forekomst af det glibc delte bibliotek på disken og nogle få symbolske links, hvilket betyder at selvom du har flyttet objektet glibc.so.6 væk fra dets retmæssige sted, har vi stadig en evne til at forsøge at genoprette vores system. Hvad vi egentlig har brug for er at kunne flytte eller kopiere en fil. Faktisk skal der på de fleste Linux-systemer, med en lille variation i placerings- og navngivningskonventionen, være en anden kopi af standardbiblioteket med det fulde navn. Brug Fedora som et eksempel, så ville du have libc.so.6 og libc-2.22.so. Nogle gange kan de to være rent faktisk symbolsk forbundet. Hvis du er heldig, bliver kopien eller flytningen rettet:

LD_PRELOAD = / usr / lib64 / libc-2.22.so cp /usr/lib64/libc.so.6.bak /usr/lib64/libc.so.6

Og du bør være tilbage til at have et funktionelt system.

Sunde metoder

Okay, og nu hvor vi har lært alt det ovenstående, er der nogle ting, du skal huske og øve. Slet aldrig systemfiler, selvom du behøver dem til at gå væk. Flyt dem til side, til at begynde med, så du kan flytte dem tilbage, hvis det er nødvendigt. Undtagelsen fra reglen er glibc og den dynamiske linker, som hvis væk, vil medføre mange problemer med dit system.

Gør aldrig fancy rør og xargs fjernelse af filer, når du arbejder under systemmapper. Altid ekko outfit først, skriv altid kommandoer med hash (#) -tasten som første tegn, så hvis du ved et uheld slår Enter-tasten, sker der ikke noget dårligt. Prøv at teste med uskyldige og ubetydelige filer.

Brug aldrig miljøvariabler til at erklære stier og filnavne. Du kunne ender med at slette alt. Altid gå til fulde stier og navne. Altid.

Backups og systembilleder, geddit?

Mere læsning

Trænger du efter mere fancy viden? Læs nedenfor da:

Meget nyttig Linux kommandoer & konfigurationer

Linux hacking guides en to og tre - nej. fire knyttet tidligere

System super debugging tutorial

Sådan bruger perf

Og bog selvfølgelig!

Konklusion

Og her er vi i slutningen af ​​denne lange og nørdige artikel. Men forhåbentlig har du lært meget, og jeg mener virkelig mange nye ting her: hvordan Linux virker, ELF's intricacies, hvad der ikke er med dine systemfiler og hvordan man undgår tårer og smerter og derefter en dræb af nyttiggørelsesmetoder, herunder sikkerhedskopier, systembilleder, live cd-spil og mere detaljeret, vores arbejde med busybox og LD_PRELOAD.

Vi lærte også lidt mere om begrænsningerne ved at forsøge at komme sig ud af en dårlig botched situation, og hvorfor skulle du muligvis have en rotskal, der kører på din kasse, og så alle grundene til, hvorfor du virkelig ikke bør lade dine brugere have nogen adgang til rodfiler. "Det er et dobbeltkantsværdigt sværd. Under alle omstændigheder vil jeg gerne tro på, at du var oplyst og underholdt. Se dig omkring for mere blid hackerologi.


Kilde

Giv en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.