Webservers hosten de bestanden (webpagina's, afbeeldingen, video's, formulieren, enz.) die deel uitmaken van uw webtoepassing en dienen deze bestanden wanneer iemand uw website bezoekt. Sommige servers zijn geavanceerder en bepalen ook hoeveel toegang webbezoekers hebben. Ze kunnen voorkomen dat reguliere bezoekers toegang krijgen tot de accounts of administratieve dashboards van andere gebruikers. Hoewel webservers efficiënt zijn in wat ze doen - en ze doen het tamelijk veilig - kunnen aanvallers misbruik maken van fouten die het gevolg zijn van menselijke fouten of gebrekkige logica in de manier waarop een server de bestanden bedient die het host.
Wat is een LFI-aanval?
Een Local File Intrusion (LFI)-aanval vindt plaats wanneer aanvallers kwetsbaarheden misbruiken in de manier waarop een webserver de toegang tot zijn bestanden opslaat, bedient, valideert of beheert. Deze kwetsbaarheid komt veel voor bij op PHP gebaseerde websites.
In tegenstelling tot veel vormen van cyberaanvallen waarbij aanvallers vertrouwen op malware om een applicatie te beschadigen, vertrouwen aanvallers in LFI's meestal op slimme trucs en korte regels code. Hiervoor zijn zelden geavanceerde tools of complexe scripts nodig; aanvallen vinden meestal plaats in de webbrowser. De meest voorkomende truc die aanvallers gebruiken, is het wijzigen van de URL-tekenreeks met code, bestandspaden of bestandsnamen.
Hoe gebeuren LFI-aanvallen?
LFI-aanvallen gebeuren meestal in vier fasen.
Eerst identificeert de aanvaller een PHP-website waarop een kwetsbare webtoepassing wordt uitgevoerd, meestal door een basiscode in de browser-URL uit te voeren om te zien of de webtoepassing (d.w.z. de site) de opdracht afhandelt. Zie het als het indrukken van toetscombinaties op je gamecontroller om een paasei te ontgrendelen, bijvoorbeeld door op de toets omlaag te drukken om tunnels in Super Mario binnen te gaan. Maar de commando's die aanvallers uitvoeren in LFI-aanvallen zijn consistenter dan het controleren van elke tunnel in Super Mario.
Een webtoepassing of server die onjuist is geconfigureerd of invoer niet kan valideren, zal de schadelijke code uitvoeren. Vanaf hier kan de hacker de toegang en het privilege krijgen die hij nodig heeft om kwetsbare bestanden te lezen of schadelijke bestanden naar de server te uploaden.
De meeste LFI-aanvallen leiden ertoe dat de aanvaller toegang krijgt tot gevoelige informatie. De mogelijkheid om malware te uploaden is zelden succesvol omdat er geen garantie is dat de webapplicatie het bestand zal opslaan op dezelfde server waar de LFI-kwetsbaarheid bestaat. Dit is vaak het geval als de webapplicatie zich in een multiserveromgeving bevindt.
Dus als de LFI-kwetsbaarheid bestaat op de server die afbeeldingen host, maar niet op de server die de medewerker opslaat referenties of gebruikerswachtwoorden, zou de aanvaller alleen toegang hebben tot afbeeldingsbestanden op die kwetsbare server. Hoe dan ook, cyberevenementen zoals de aanval op LastPass laten zien dat hackers grote schade kunnen aanrichten met schijnbaar het meest onbeduidende toegangsniveau.
Hoe LFI-aanvallen te voorkomen
LFI-aanvallen komen vrij vaak voor, volgens de Open Web Application Security Project (OWASP). Het is begrijpelijk dat hackers deze aanval zouden prefereren omdat, zoals W3Techs rapporten, draaien bijna acht op de tien websites PHP als een programmeertaal aan de serverzijde - een overvloed aan slachtoffers, om zo te zeggen. Het is mogelijk om een LFI-aanval te voorkomen door best practices voor webbeveiliging toe te passen.
Zet openbare serverbestanden op de witte lijst
Webapplicaties gebruiken vaak bestandspaden als URL-invoer. Hackers kunnen dit bestandssysteem misbruiken door het deel van de URL dat ook dienst doet als bestandspad te wijzigen. Een aanvaller kan bijvoorbeeld veranderen https://dummywebsite.com/?module=contact.php naar https://dummywebsite.com/?module=/etc/passwd. Een kwetsbare server met slechte filtering en gebrekkige logica zal de inhoud weergeven van het bestand dat is opgeslagen in het pad /etc/passwd.
Natuurlijk gebruiken hackers variaties op veelgebruikte bestandsnamen en combinaties van zoektekens om de kans op een succesvolle aanval te vergroten. Het doel is om de webtoepassing te misleiden om een script uit te voeren of de bestanden op een webserver weer te geven.
U kunt deze kwetsbaarheid blokkeren door een witte lijst met openbare documenten op uw server te maken en de webtoepassing te instrueren om zoekopdrachten voor elk ander document of bestandspad te negeren. Dus als een aanvaller de URL probeert te manipuleren om codes op te vragen of uit te voeren die om een privéverzoek vragen, krijgen ze in plaats daarvan een foutpagina.
Test regelmatig op kwetsbaarheden
Je kunt gebruiken hulpprogramma's voor webscanning om kwetsbaarheden te vinden en op te lossen die u kunnen blootstellen aan LFI-aanvallen. Webapp-scanners zijn geautomatiseerde tools die uw app crawlen als een aanvaller en u waarschuwen voor mogelijke kwetsbaarheden. Er zijn verschillende open-source webscanners zoals OpenVAS en Wireshark, maar de meeste kwetsbaarheidsscanners zijn propriëtaire software en vereisen betaalde abonnementen om te gebruiken.
Maar u krijgt natuurlijk geen webscanner voor alleen LFI-aanvallen. Deze tools zoeken ook naar bredere beveiligingsproblemen zoals externe bestandsopname, cross-site scripting, SQL-injectie en slechte serverconfiguraties. Ze zijn het dus waard.
Beperk de rechten van sitebezoekers
Hackers voeren LFI-aanvallen vaak met succes uit omdat webapplicaties de gebruikersrechten niet in hokjes verdelen en bezoekers toegang geven tot bestanden die alleen zichtbaar zouden moeten zijn voor beheerders. Deze maatregel werkt als whitelisting: configureer uw webapplicatie en server zo dat ze openbare bestanden bedienen en ongeautoriseerde verzoeken negeren wanneer een bezoeker interactie heeft met de webapp. Dit is vooral belangrijk voor zoekopdrachten naar bestandspaden die gevoelige bestanden bevatten.
Hiertoe moet u mogelijk voorkomen dat bestandspaden rechtstreeks worden gewijzigd. De web-app mag alleen documenten weergeven uit een hardgecodeerde padlijst. Configureer bovendien de web-app om verzoeken te verwerken met dynamische padaaneenschakeling (de URL's moeten alfanumerieke tekens bevatten) in plaats van base64- of bin2hex-functies.
Als u erover nadenkt om bestandsnamen op de zwarte lijst te zetten, doe dat dan niet. Hackers hebben meestal een groeiende lijst met bestandsnamen die ze kunnen gebruiken om een LFI-aanval uit te voeren. Bovendien is het praktisch onmogelijk (en een enorme verspilling van tijd) om een lijst met steeds groter wordende bronnen op de zwarte lijst te zetten van aanval.
Gebruik een omgeving met meerdere servers
In een omgeving met meerdere servers kunt u belangrijke, gevoelige documenten isoleren van openbare bestanden, waardoor uw risico in geval van een inbreuk wordt verkleind. Dedicated servers zijn minder kwetsbaar voor LFI-aanvallen omdat ze weliswaar samenwerken, maar qua configuratie verschillen.
Naast deze beveiliging zijn meerdere servers ook betrouwbaar (met minder risico op downtime), snel en efficiënt. Toegegeven, het gebruik van een multiserveromgeving is niet kosteneffectief als uw website klein is. Overweeg in dat geval om de toegang van uw webapplicatie tot gegevens te splitsen tussen een database voor privégegevens en een server voor openbare bestanden.
Moet u zich zorgen maken over LFI-aanvallen?
De mogelijkheid van een LFI-aanval is aanwezig, vooral als uw site op PHP draait, maar u kunt uw blootstelling verminderen door webapplicaties en servers te configureren volgens best practices voor webbeveiliging.
Bovendien zou u moeten overwegen om routinematige beveiligingscontroles uit te voeren om kwetsbaarheden te vinden. Dingen gaan de hele tijd kapot, vooral omdat de architectuur van de site complex wordt. De tools die je nodig hebt om jezelf te beschermen, zijn geautomatiseerd en voor veel ervan is geen uitgebreide installatie of geavanceerde technische kennis vereist.
