Remote code execution (rce), forklart: hva det er og hvordan du kan forhindre det

Remote code execution (Rce) er en klasse av programvaresikkerhetsfeil/sårbarheter. Rce-sårbarheter gjør det mulig for en ondsinnet aktør å utføre hvilken som helst kode etter eget valg på en ekstern maskin via LAN, WAN eller internett. Rce tilhører den bredere klassen av vilkårlig kjøring AV KODE (ACE) sårbarheter. Med internett blir allestedsnærværende, vokser rce sårbarheter raskt. Så, RCEs er nå trolig den viktigste TYPEN ACE sårbarhet.

Som det er tilfelle, ønsket vi å se nærmere på de ulike typer rce-sårbarheter og mulige motforanstaltninger.

rce-klassifisering etter opprinnelse

De fleste, om ikke alle, AV DE kjente RCE-sårbarhetene har et lite antall bakenforliggende årsaker.

Dynamisk kjøring av kode

Dynamisk kjøring av kode er den vanligste angrepsvektoren som fører TIL RCE. De fleste programmeringsspråk har noen måte å generere kode med kode og utføre den på stedet. Dette er et veldig kraftig konsept som bidrar til å løse mange komplekse problemer. En ondsinnet tredjepart kan imidlertid lett misbruke den for å få RCE-evner.

ofte er koden som genereres under kjøring, basert på noen brukerinndata. Oftere enn ikke, inneholder koden den inngangen i noen form. En ondsinnet skuespiller, innser at dynamisk kodegenerering vil gjøre bruk av en gitt inngang, kan gi gyldig kode som en inngang for å angripe søknaden din. Hvis brukerinngangene ikke er oppdaget, vil den koden bli utført på målmaskinen.

i Stor grad fører dynamisk kjøring av kode til to hovedklasser av rce-sårbarheter: direkte og indirekte.

Direkte

ved direkte dynamisk kjøring av kode er den ondsinnede aktøren klar over at inndataene deres vil bli brukt i kodegenerering.

Indirekte

en indirekte sak, igjen, koker ned til dynamisk kodegenerering inkludert brukerinnganger. Brukerinngangen går imidlertid gjennom ett eller flere lag. Noen av lagene kan til og med forvandle den inngangen før den ender med dynamisk kodegenerering. Også dynamisk kodegenerering kan være en bivirkning og ikke den primære bruken av inngangen. Som sådan er det ikke helt tydelig for brukeren å gi inngangen at inngangen vil bli brukt som en byggestein i en kodebit som skal utføres på en ekstern maskin.

Deserialisering

Deserialisering er et veldig godt eksempel på dette scenariet. Tilsynelatende bør ingen dynamisk kodegenerering skje ved deserialisering. Det er faktisk tilfelle når det serialiserte objektet bare inneholder datafelt av primitive typer eller andre objekter av den typen. Ting blir imidlertid mer kompliserte når metoder / funksjoner til et objekt serialiseres. Deserialisering vil da vanligvis inkludere noen form for dynamisk kodegenerering.

du tror kanskje at dynamiske språk er det eneste stedet hvor funksjonsserialisering gir mening. Problemet vil da være av begrenset omfang. Men det er også et nyttig scenario i statiske språk. Det er litt vanskeligere å oppnå på et statisk språk, men langt ikke umulig.

ganske ofte består implementeringen av deserialiseringsgenererte proxy-objekter/funksjoner. Generering av objekter / funksjoner under kjøring er et tilfelle av dynamisk kodegenerering. Så, hvis dataene som skal deserialiseres stammer fra en forespørsel fra en ekstern maskin, kan en ondsinnet skuespiller endre den. Nøye utformede serialiserte kodesnutter kan injiseres som lurer den dynamiske kodegenereringen for å utføre dem når de påberopes som en del av deserialiseringen.

minnesikkerhet

En annen årsak TIL rce-sårbarheter har å gjøre med minnesikkerhet. Minnesikkerhet betyr å hindre kode i å få tilgang til deler av minnet som det ikke initialiserte eller fikk som en inngang. Intuitivt kan du forvente mangel på minnesikkerhet for å resultere i uautorisert datatilgang. Operativsystemet og den underliggende maskinvaren bruker imidlertid minne til å lagre faktisk kjørbar kode. Metadata om kjøring av kode lagres også i minnet. Å få tilgang til denne typen minne kan resultere I ACE og muligens RCE. Så hva er de viktigste årsakene bak minne sikkerhetsproblemer?

feil I programvaredesign

Feil I Programvaredesign er en type sikkerhetsproblem i minnet der det er en designfeil i noen underliggende komponenter. Oftere enn ikke, det ville være en kompilator, tolk eller virtuell maskin, eller potensielt operativsystemkjernen eller bibliotekene. Det er en rekke forskjellige feil som tilhører denne klassen. Vi skal ta en mer detaljert titt på hva som uten tvil er den vanligste.

Buffer overflow eller buffer overread

Buffer overflow (også kjent som buffer overread) er en ganske enkel og velkjent teknikk for å krenke minnesikkerhet. Det utnytter en designfeil eller en feil for å skrive til minnecellene som følger den faktiske enden av en minnebuffer. Bufferen selv blir returnert fra et legitimt anrop til offentlig API. Bufferen tjener imidlertid bare som et opprinnelsessted for å beregne de fysiske minneadressene til private felt/medlemsverdier for et objekt eller en programteller. Deres relative posisjon til bufferen er enten velkjent eller kan gjettes. Å undersøke koden hvis tilgjengelig eller feilsøke programutførelsen ved kjøretid, kan hjelpe en ondsinnet skuespiller til å få relative stillinger.

så, en bufferoverflyt gjør det mulig å endre minne som bør være utilgjengelig ved design. Den bufferen kan ligge i adresseområdet til en annen maskin og endres ved å ringe en ekstern API. Det vil tillate tilgang til det eksterne maskinens minne. Det er klart at det finnes ulike måter å bruke denne typen tilgang på i instrumentering AV EN RCE. Den generelle antakelsen er at hvis et bufferoverløpssårbarhet eksisterer, er EN RCE mulig. Så, kodeeiere bør fikse bufferoverløp ASAP, godt før det faktiske rce-angrepet kommer fram.

Omfang

bufferoverflyt mål Oftere Enn Ikke C/C++ kode siden disse språkene ikke har innebygd bufferstørrelseskontroller. Mange andre populære rammer og teknologier ender opp med Å bruke c/C++ – biblioteker dypt nede under overflaten som automatisk gjør dem sårbare for denne typen angrep.

Node.js er et godt eksempel på dette siden, foruten å være basert På C/C++, JavaScript runtime tillater også innfødte c / C++ add-ons. På grunn av dette kan en angriper nøye lage forespørsler til En Node.js server for å forårsake bufferoverflyt og dermed endre systemminnet på den berørte maskinen, forårsaker kjøring av vilkårlig kode.

Hardware design feil

Interessant nok, kan minne sikkerhet brudd oppstå på grunn av hardware sikkerhet design feil også. Selv om det er mindre vanlig og vanskeligere å finne, har slike sårbarheter vanligvis en ekstremt høy innvirkning.

Avbøyning AV rce-angrep

mens utfallet av hvert rce-angrep er det samme når det gjelder en angriper som utfører kode, er angrepsvektorene svært forskjellige i naturen. Blokkering av dem alle tar betydelig innsats. Videre vokser innsatsen sammen med teknologibunken. Alle angrepsvektorer beskrevet i dette innlegget er teknologi-agnostiker. Alle implementeringer er teknologispesifikke, og det er også forsvarsmekanismer.

så en tradisjonell tidsbesparende tilnærming er å overvåke nettverkstrafikk for mistenkelig innhold i stedet for å overvåke hvert endepunkt med sin spesifikke teknologi. EN web application firewall (WAF) utfører vanligvis denne jobben. SELV om DET sparer tid, kommer DET også til en pris—WAF er en flaskehals for nettverksytelsen, og den mangler all bakgrunnsinformasjon som er tilgjengelig på det faktiske endepunktet eller på applikasjons-og brukernivå. DERFOR KAN WAF trafikkanalyse aldri være perfekt. Heuristikk er uunngåelig uten full data, så enten ikke alle trusler vil dukke opp eller falske positiver vil oppstå, eller oftest begge deler.

Flytte inne i appen: Sqreen tilnærming

Sqreen løser DISSE waf mangler uten å øke utviklingskostnadene for sluttbrukeren ved å flytte synlighet inne i programmet, og bringer mer komplett beskyttelse med en teknologi-spesifikke RASP OG IN-App WAF. Sqreen ER RASP og WAF kjører inne i selve web-applikasjon, API, ELLER microservice mottar nettverkstrafikk. Det krever ingen kodeendring, skjønt. Den bruker instrumentering poeng spesifikke for hver teknologi (f.eks JVM API For Java, v8 API For Node.js, etc.) for å endre kode før kjøring under kjøring. Dermed er det i stand til å overvåke og endre system – og nettverkshendelser mens du har full sammenheng med alt som skjer inne i applikasjonen.

Sqreen kan dermed oppdage at appen bruker komponenter med kjente minnesikkerhetsproblemer. Det kan også oppdage de faktiske brukerinngangene som gjør det til de dynamiske kodeutførelseshendelsene. Naturligvis er dette en overlegen tilnærming til å oppdage Og forebygge RCEs sammenlignet med en tradisjonell WAF som bare har tilgang til nettverkstrafikk.

Innpakning

Klart, RCE Er En veldig potent angrepsvektor. Men heldigvis er det mulig å forsvare deg mot RCE-angrep også. Informasjonen ovenfor kan virkelig hjelpe i å bygge din forsvarsstrategi. Hvis du er interessert i andre angrepsvektorer og detaljer, sjekk ut våre tidligere innlegg PÅ SQL injection, XXE og LFI.