Remote code execution (RCE), uitgelegd: wat het is en hoe het te voorkomen

Remote code execution (RCE) is een klasse van software beveiligingsfouten/kwetsbaarheden. RCE kwetsbaarheden zal een kwaadaardige acteur om een code van hun keuze uit te voeren op een externe machine via LAN, WAN, of internet. RCE behoort tot de bredere klasse van willekeurige code execution (ACE) kwetsbaarheden. Met het internet steeds alomtegenwoordig, hoewel, RCE kwetsbaarheden’ impact groeit snel. Zo, RCEs zijn nu waarschijnlijk de belangrijkste soort ACE kwetsbaarheid.

in dat geval wilden we een meer gedetailleerde blik werpen op de verschillende soorten RCE-kwetsbaarheden en de mogelijke tegenmaatregelen.

RCE-classificatie naar oorsprong

de meeste, zo niet alle, bekende RCE-kwetsbaarheden hebben een klein aantal onderliggende oorzaken.

uitvoering van dynamische code

uitvoering van dynamische code is meestal de meest voorkomende aanvalsvector die leidt tot RCE. De meeste programmeertalen hebben een manier om code met code te genereren en deze ter plaatse uit te voeren. Dit is een zeer krachtig concept dat helpt bij het oplossen van veel complexe problemen. Echter, een kwaadaardige derde partij kan gemakkelijk misbruik maken van het om RCE mogelijkheden te krijgen.

vaak is de code gegenereerd tijdens runtime gebaseerd op enige gebruikersinvoer. Vaker wel dan niet, de code bevat die invoer in een of andere vorm. Een kwaadaardige acteur, zich realiserend dat de dynamische code generatie gebruik zal maken van een bepaalde ingang te maken, kan geldige code te bieden als een ingang om uw toepassing aan te vallen. Als de gebruiker ingangen niet worden gecontroleerd, dan zal die code worden uitgevoerd op de doel machine.

in het algemeen veroorzaakt dynamische code-uitvoering twee grote klassen van RCE-kwetsbaarheden: direct en indirect.

Direct

bij directe dynamische code-uitvoering is de kwaadwillende actor zich ervan bewust dat de invoer ervan gebruikt zou worden bij het genereren van code.

Indirect

een indirect geval komt neer op dynamische codegeneratie inclusief gebruikersinput. De invoer van de gebruiker gaat echter door een of meer lagen. Sommige lagen kunnen zelfs transformeren die invoer voordat het eindigt met dynamische code generatie. Ook kan dynamische codegeneratie een bijwerking zijn en niet het primaire gebruik van de input. Als zodanig, het is niet echt duidelijk voor de gebruiker die de input zal worden gebruikt als een bouwsteen in een code fragment uit te voeren op een externe machine.

deserialisatie

deserialisatie is een zeer goed voorbeeld van dit scenario. Schijnbaar geen dynamische code generatie zou moeten gebeuren op deserialisatie. Dat is in feite het geval wanneer het geserialiseerde object alleen gegevensvelden van primitieve typen of andere objecten van dat soort bevat. Het wordt echter ingewikkelder als methoden/functies van een object worden geserialiseerd. Deserialisatie zal dan meestal een vorm van dynamische code generatie omvatten.

u zou kunnen denken dat dynamische talen de enige plaats zijn waar functieserialisatie zinvol is. Het probleem zal dan van beperkte omvang zijn. Maar het is ook een handig scenario in statische talen. Het is iets moeilijker te bereiken in een statische taal, maar verreweg niet onmogelijk.

vaak bestaat de implementatie uit door deserialisatie gegenereerde proxy-objecten / – functies. Het genereren van objecten / functies tijdens runtime is een geval van dynamische code generatie. Zo, als de gegevens te deserialized afkomstig is van een verzoek van een externe machine, een kwaadaardige acteur kan wijzigen. Zorgvuldig vervaardigde serialized code fragmenten kunnen worden geïnjecteerd dat Truc de dynamische code generatie om ze uit te voeren wanneer aangeroepen als onderdeel van de deserialisatie.

Geheugenveiligheid

een andere oorzaak van RCE-kwetsbaarheden heeft te maken met geheugenveiligheid. Geheugen veiligheid betekent het voorkomen van code toegang tot delen van het geheugen dat het niet initialiseren of krijgen als een ingang. Intuïtief, je zou verwachten dat een gebrek aan geheugen veiligheid te leiden tot onbevoegde toegang tot gegevens. Het besturingssysteem en de onderliggende hardware gebruiken echter geheugen om daadwerkelijk uitvoerbare code op te slaan. Metadata over de uitvoering van code wordt ook opgeslagen in het geheugen. Toegang krijgen tot dit soort geheugen kan resulteren in ACE en eventueel RCE. Dus wat zijn de belangrijkste redenen achter het geheugen veiligheidsproblemen?

fouten in het ontwerp van Software

fouten in het ontwerp van Software zijn een type beveiligingsprobleem met een ontwerpfout in een onderliggende component. Vaker wel dan niet, dat zou een compiler, interpreter, of virtuele machine, of potentieel het besturingssysteem kernel of bibliotheken. Er zijn een aantal verschillende gebreken die behoren tot deze klasse. We gaan wat gedetailleerder kijken naar wat misschien wel de meest voorkomende is.

Buffer overflow of buffer overread

Buffer Overflow (ook bekend als buffer overread) is een vrij eenvoudige en bekende techniek om de geheugenveiligheid te schenden. Het maakt gebruik van een ontwerpfout of een bug om te schrijven naar de geheugencellen die het werkelijke einde van een geheugenbuffer volgen. De buffer zelf wordt teruggestuurd van een legitieme oproep aan de openbare API. Nochtans, dient de buffer slechts als punt van Oorsprong om de fysieke geheugenadressen van privé veld/lidwaarden van één of andere object of programmateller te berekenen. Hun relatieve positie ten opzichte van de buffer is ofwel goed bekend of kan worden geraden. Het onderzoeken van de code indien beschikbaar of het debuggen van de uitvoering van het programma tijdens runtime kan helpen een kwaadaardige acteur relatieve posities te verkrijgen.

een bufferoverloop maakt het mogelijk om geheugen te wijzigen dat door ontwerp ontoegankelijk zou moeten zijn. Die buffer kan zich in de adresruimte van een andere machine bevinden en worden gewijzigd door een externe API aan te roepen. Dat geeft toegang tot het geheugen van de machine op afstand. Het is duidelijk dat er verschillende manieren zijn om dit type toegang te gebruiken bij het instrumenteren van een RCE. De algemene aanname is dat als er een buffer overflow kwetsbaarheid bestaat, dan is een RCE mogelijk. Zo, code-eigenaren moeten buffer overflows zo snel mogelijk te repareren, lang voordat de werkelijke RCE aanval komt.

Scope

vaak is bufferoverflow gericht op C / C++ – code, omdat deze talen geen ingebouwde buffergroottecontroles hebben. Veel andere populaire frameworks en technologieën uiteindelijk met behulp van C/C++ bibliotheken diep onder de oppervlakte die automatisch maakt ze kwetsbaar voor dit soort aanval.

Node.js is een goed voorbeeld hiervan, omdat JavaScript runtime niet alleen gebaseerd is op C/C++, maar ook zorgt voor native C/C++ add-ons. Hierdoor, een aanvaller kan zorgvuldig ambachtelijke de verzoeken om een knooppunt.js server om buffer overflow te veroorzaken en zo het systeemgeheugen op de getroffen machine te wijzigen, waardoor het uitvoeren van willekeurige code.

hardware-ontwerpfouten

interessant genoeg, kunnen geheugenveiligheidsfouten ook optreden als gevolg van hardware-ontwerpfouten. Hoewel minder vaak en moeilijker te vinden, hebben dergelijke kwetsbaarheden meestal een extreem hoge impact.

RCE-aanvallen afbuigen

terwijl de uitkomst van elke RCE-aanval hetzelfde is in termen van een aanvaller die code uitvoert, zijn de aanvalsvectoren zeer verschillend van aard. Het blokkeren van alle van hen vergt aanzienlijke inspanning. Bovendien groeit de inspanning samen met de technologiestack. Alle aanvalsvectoren beschreven in dit bericht zijn technologie-agnostisch. Alle implementaties zijn echter technologie-specifiek, net als de verdedigingsmechanismen.

een traditionele tijdbesparende aanpak is dus het monitoren van netwerkverkeer op verdachte inhoud in plaats van het bewaken van elk eindpunt met zijn specifieke technologie. Een web application firewall (WAF) voert deze taak meestal uit. Terwijl dat tijd bespaart, het komt ook aan een prijs—de WAF is een netwerk prestaties bottleneck, en het mist alle achtergrondinformatie die beschikbaar is op het werkelijke eindpunt of op het niveau van de toepassing en de gebruiker. Vandaar dat WAF-verkeersanalyse nooit perfect zou kunnen zijn. Heuristiek is onvermijdelijk zonder volledige gegevens, dus ofwel zullen niet alle bedreigingen ontstaan of valse positieven ontstaan, of meestal beide.

verplaatsen binnen het app: Sqreen ‘ s approach

sqreen pakt deze WAF-tekortkomingen aan zonder de ontwikkelingskosten voor de eindgebruiker te verhogen door de zichtbaarheid binnen de applicatie te verplaatsen, waardoor een meer volledige bescherming wordt geboden met een technologiespecifieke RASP en in-App WAF. SQREEN ‘ s RASP en WAF draait in de werkelijke webapplicatie, API, of microservice ontvangen netwerkverkeer. Het vereist geen code wijziging, hoewel. Het maakt gebruik van instrumentatie punten specifiek voor elke technologie (bijvoorbeeld, JVM API voor Java, V8 API voor Node.js, enz.) om de code te wijzigen voor uitvoering tijdens runtime. Het is dus in staat om systeem-en netwerkgebeurtenissen te monitoren en te wijzigen, terwijl het de volledige context heeft van alles wat er in de applicatie gebeurt.

Zo kan Sqreen detecteren dat de app componenten gebruikt met bekende problemen met geheugenveiligheid. Het kan ook detecteren de werkelijke gebruiker ingangen die het maken om de dynamische code uitvoering gebeurtenissen. Uiteraard is dit een superieure benadering van het detecteren en voorkomen van RCEs in vergelijking met een traditionele WAF die alleen toegang heeft tot netwerkverkeer.

het is duidelijk dat RCE een zeer krachtige aanvalsvector is. Maar, gelukkig, is het mogelijk om jezelf te verdedigen tegen RCE aanvallen, ook. De bovenstaande informatie kan echt helpen bij het opbouwen van uw defensie strategie. Als je geïnteresseerd bent in andere aanvalsvectoren en details, bekijk dan onze vorige berichten op SQL injection, XXE en LFI.