Blind retur orientert programmering - Blind return oriented programming

Se også: Returorientert programmering

Blind retur orientert programmering (BROP) er en utnyttelsesteknikk som med hell kan skape en utnyttelse selv om angriperen ikke har målet binær. BROP-angrep vist av Bittau et al. har beseiret randomisering av adresseplassoppsett (ASLR) og stablet kanarifugler på 64-biters systemer.

ROP-historie

Med de nåværende forbedringene i OS-sikkerhet og maskinvare, sikkerhetsfunksjoner som Linux PAX- prosjektet, er kodeinjeksjon nå umulig. Sikkerhetsforskere oppfattet deretter et nytt angrep som de kalte returorientert programmering for å beseire NX (ikke-kjørbart) minne. Dette angrepet er avhengig av å påvirke programflyten ved å kontrollere stabelen, spesielt returadresser. Gadgets er de grunnleggende enhetene for dette angrepet. Gadgets er en gruppe instruksjonssekvenser som ender i en returinstruksjon, sammen med en viss tilstand av stabelen. En innretning kan utføre en operasjon som å laste et ord fra minnet i et register, eller utføre en mer kompleks operasjon som et betinget hopp. Med et stort nok mål binært, kan en Turing-komplett samling av gadgets konstrueres, noe som er mer enn nok til å få en shellcode utført. En antagelse som ROP legger til grunn er at angriperen har målbinariene og dermed kjenner adressene til gadgetene på forhånd.

Scenarier for BROP

Det er tre nye scenarier som BROP kan være relevant for. De er:
(i) I tilfelle lukkede binære tjenester, å oppdage sårbarheter der teknikker som fuzz og penetrasjonstesting må brukes.
(ii) En kjent sårbarhet i et åpen kildekode-bibliotek kan utnyttes for å utføre en utnyttelse, selv om den proprietære binæren som bruker den er lukket kilde.
(iii) Den kan også brukes til å hacke en åpen kildekodeserver som binær er ukjent for.
Angrepet forutsetter at det er en tjeneste på serveren som har en kjent stack-sårbarhet, og at tjenesten skal starte på nytt ved krasj.

Angrepsfaser

Staklesing

Retningsinstruksjonspekere er vanligvis beskyttet av kanarifugler. En stabelkanari får programmet til å krasje hvis verdien endres av en bufferoverskridelse. I BROP-angrepsmodellen bæres bufferoverskridelsen byte for byte. Hvert forsøk på overkjøringen resulterer enten i et programkrasj eller fortsatt kjøring. Et programkrasj innebærer at stakkverdien ble feilaktig gjettet, derfor kan 256 sannsynligvis estimeres i 256 forsøk (gjennomsnittlig tilfelle er 128 forsøk). På 64-bits maskiner vil det være nødvendig med fire slike stakkavlesninger for å lekke kanarifuglen. Når kanarien er lekket, kan returinstruksjonspekeren bli forstyrret på samme måte. Det kan imidlertid bemerkes at selv om estimeringen av stabelkanaren er nøyaktig, kan det samme ikke sies om returinstruksjonsadressen. Angriperen ville være fornøyd med å kunne lekke en hvilken som helst adresse i tekstsegmentet i adresseområdet.

Blind ROP

Denne fasen er hjertet i angrepet. Målet i denne fasen er å starte en skriveanropssending, sende en dump av binæren til angriperen. Skrivesystemanropet har tre parametre: stikkontakt, buffer og lengde. Ettersom x86-64-anropskonvensjoner krever at parametrene sendes gjennom registre, vil passende popinstruksjoner til rsi, rdi og rdx være nødvendige for å sette opp argumentene for skrivesystemanropet. Instruksjonssekvenser som pop rdi, ret og lignende vil være nyttige i denne forbindelse. En enkel ROP-versjon av skrivesystemanropet vil være:
(1) pop rdi; ret (socket)
(2) pop rsi; ret (buffer)
(3) pop rdx; ret (lengde)
(4) pop rax; ret (skriv syscall nummer)
(5) syscall

Et problem med denne metoden er at selv om nyttige gadgets blir funnet i adresserommet etter at de returnerer adressen på bunken, vil det føre til ikke-kjørbar stabel med stor sannsynlighet. For å avhjelpe dette oppfattet BROP-forslagsstillere stopp-gadgets. En stopp-gadget er alt som kan føre til at programmet blokkeres, som en uendelig sløyfe eller et blokkeringssystemanrop (som søvn). Dette arbeider også prosessorer som er berørt i angrepet for å bli sittende fast i en uendelig løkke og dermed la angriperen fortsette angrepet.

Det som er nevnt ovenfor er den bare beinmetoden for angrepet. I virkeligheten kan det utføres noen få optimaliseringer som hjelper til effektivt å utføre angrepet. Primær blant dem er bruken av Procedure Linker Tables (PLTs) for å spore skrivesystemanropet i stedet for å sende systemanropsnummeret til syscall-funksjonen. Andre inkluderer bruk av strcmp for å fylle ut RDX-registeret, da pop RDX er ret instruksjons sekvenser ekstremt sjeldne.

Bygg utnyttelsen

Når skrivingen er funnet i PLT, kan angriperen dumpe innholdet i målet binært for å finne flere gadgets. Angriperen kan bruke konvensjonelle ROP-gadgettsøkteknikker for å samle nok og lage en shellcode. Når de har shellcode, kan det utnyttede systemet tas under full kontroll med root-tilgang.

BROP-forebygging

En enorm antagelse i BROP-angrepet er at serveren starter på nytt etter hvert krasj, og når du starter på nytt, ikke randomiserer adresseplassen. Så å aktivere re-randomisering av adresseområdet ved oppstart kan gi nesten fullstendig beskyttelse mot BROP. En annen teknikk som brukes av NetBSD og Linux er søvn på krasj. Dette bremser angrepet betraktelig og lar systemadministratoren se på mistenkelig aktivitet. Bortsett fra dette, den konvensjonelle beskyttelsen mot ROP-stilflytkapringangrep, kan Control Flow Integrity også gi bevisbar forebygging, men med en betydelig ytelse overhead.

Lignende angrep

Et annet angrep som ligner på BROP, er JIT (Just-In-Time) -ROP, eller JIT-ROP. Det er også et annet angrep som er basert på informasjonsinformasjon, som også er i stand til å beseire Address Space Layout Randomization . Både BROP og JIT-ROP vil prøve å finne gadgets på binæren for å starte et ROP-angrep, der målet er å utnytte en slags datalekkasje. I motsetning til BROP er JIT-ROP imidlertid ikke et interaktivt angrep, og søker å tilpasse seg situasjoner uten krasj / krasj, men angriperen sender ut et skript som vil oppdage gadgets, og oppretter deretter et angrep for levering . Dessuten må JIT-ROP ha to forskjellige sårbarheter (både en bunke og stabel) kjent før angrepet, mens BROP bare krever bevissthet om en stakkesårbarhet.

Referanser