Schadelijke Bestanden Opsporen


Tags: abusebeveiliging

Let op! Deze informatie is bedoeld voor de meer technisch gevorderde lezer. Byte kan hierbij geen technische support leveren. Ben je zelf niet zo technisch? Neem dan contact op met één van onze partners, te vinden op onze Partnerpagina.

Is je site gehackt? In dit artikel wordt globaal omschreven hoe de gevolgen van een hack gevonden kunnen worden. Heb je een Secure, Performance, Optimize of MCU pakket? Maak dan ook gebruik van de standaard inbegrepen Security scanner: NeoPI

Let op! Heb je een Personal hosting pakket? Dan kun je geen gebruik maken van Shell, wat je nodig hebt om schadelijke bestanden op te sporen. We raden je aan tijdelijk te upgraden naar een uitgebreider pakket. Als je klaar bent met de opschoonactiviteiten kan je weer downgraden naar een Personal Hosting pakket. De kosten voor de resterende periode van het tijdelijke pakket wordt op de volgende factuur in korting gebracht.

Hoe is iets aangepast?

Allereerst is het belangrijk om de weblogs te doorzoeken op verdachte activiteiten. Bij Byte zijn de access logs van de afgelopen 30 dagen beschikbaar. Het is aan te raden deze zo snel mogelijk te doorzoeken. Het volgende commando laat zien naar welke URI’s een POST opdracht uitgevoerd is; iets wat je op verdachte bestanden of activiteiten kan wijzen;

zcat ~/weblogs/raw/*|awk '$6 == "\"POST" && $9 == 200 {print $7}'|sort|uniq -c|sort -nr|grep -e ".*php$"

Dit commando doorzoekt de weblogs van de afgelopen 30 dagen op POST opdrachten, filtert de URL er uit, telt het aantal keer dat de betreffende URI voorkomt en sorteert op frequentie.

In de resultaten staan waarschijnlijk adressen als /administrator/index.php en /login/index.php. Om je aan te melden, moet informatie naar de webserver gestuurd worden. Bij sommige acties in de backend komen ook POSTS kijken. Eigenlijk hoop je hier een onbekend bestand tegen te komen. Met een beetje mazzel vind je een bestand wat je niet kent, bijvoorbeeld:

  8 /administrator/index.php  4 /images/stories/51.php

De /images/stories/51.php is handmatig toegevoegd maar dat is uiteraard het bestand waar we in geïnteresseerd zouden zijn! Nadat we vastgesteld hebben dat we een kwaadaardig bestand gevonden hebben (door in het bestand te kijken), kijken we iets verder door de weblogs heen om te kijken of hier nog meer informatie in staat.

We gaan de weblogs doorzoeken om te kijken wat er met dit bestand gebeurd is (afgelopen 30 dagen);

zcat ~/weblogs/raw/*|grep "/images/stories/51.php"

Laten we zeggen dat een van de regels die hier uit komt als volgt luidt;
bijvoorbeeld.nl 123.45.67.89 – – [27/Nov/2012:05:03:04 +0100] “POST /images/stories/51.php HTTP/1.1” 301 248 “-” “Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.34 (KHTML, like Gecko) Qt/4.7.4 Safari/534.34 ” “-” “-” 123.45.67.89 – pid:21055 585 0 0 0 0

Met deze informatie weten we dat iemand met IP-adres 123.45.67.89 heeft zitten rommelen met het geïnfecteerde bestand. Het is dan interessant om te zien wat er verder vanaf dit IP-adres gebeurd is. Soms komen uit de voorgaande zoekopdracht meerdere IP-adressen.

Omdat alleen resultaten met betrekking tot het malafide bestand getoond worden, is het interessant om te weten wat deze mensen uitgevoerd hebben en daar kom je achter met;

zcat ~/weblogs/raw/*|grep "123.45.67.89"

Het resultaat uit dit commando is een log van wat de hacker op de site uitgevoerd heeft tijdens de afgelopen 30 dagen. Met wat mazzel heeft de exploit (waarmee het bestand /images/stories/51.php geplaatst is) tijdens de afgelopen 30 dagen plaatsgevonden vanaf het zelfde IP adres waarmee het script gebruikt is, en kan je zien welke bestanden verantwoordelijk zijn voor het lek in de site.

Zoeken met schone back-up

Om eenvoudig te zien wat er aangepast is, moet je in bezit zijn van een goede back-up. Tenzij de site minder dan 30 dagen terug opgeleverd is of je zeker weet dat de site binnen deze periode gehackt is moet dit een eigen back-up zijn.
Om snel te kunnen zien wat er aangepast is kan je de bestanden zoals ze op de site staan vergelijken met een eigen schone back-up. Er zijn programma’s die dit voor je doen of het kan via de shell met diff. Als je het op onze shell server wilt doen zal je de back-up moeten uploaden naar het pakket. Stel je upload de back-up naar ~/backup/, dan zal het diff commando er als volgt uitzien;

diff -rN ~/backup/~/bijvoorbeeld.nl/

Met (Windows/Linux (grafisch)/OSX) programma’s die misschien helderder zijn dan diff (kan een brei worden, met name met betrekking tot cache mappen etc.) hebben we nog niet zo veel ervaring. Mocht je een programma vinden wat dit helder in kaart brengt dan houden we ons warm aanbevolen.

Zoeken zonder schone back-up

Als je geen back-up tot je beschikking hebt waarvan je zeker weet dat hij schoon is, kan het traceren van een hack voelen als zoeken naar een speld in een hooiberg. Gelukkig zijn er programma’s die voor je zoeken naar kenmerken van geïnfecteerde bestanden.

Ambachtelijk zoeken

Er zijn verschillende manieren om te zien wat er gebeurd is in de site, en als eerdere scans geen resultaten opleveren ben je een stap dichterbij het stuk voor stuk bekijken van elk PHP bestand. Gelukkig zijn we nog niet zo ver. Er zijn meer mogelijkheden om de shell te gebruiken om verdachte activiteiten te vinden.

Zo kan je bijvoorbeeld de inhoud van alle bestanden doorzoeken op verdachte kenmerken. In negen van de tien gevallen wordt misbruik gemaakt van een lek om een webshell te uploaden. In negen van de tien gevallen wordt deze shell “versleuteld” met base64 geëncodeerde code. Om deze code te vinden gaan we op zoek naar een regel code waarin eval gebruikt wordt, want base64 staat vaak niet letterlijk in de code. Je gebruikt hiervoor het volgende commando:

grep-r "eval" ~/*bijvoorbeeld.nl/

Hier komt weer een rits bestanden uit die het bekijken waard zijn. We hebben een handleiding die ons kan helpen bij het PHP Script Decoderen. We zien ook vaak bij Joomla! sites dat er PHP bestanden in de images folder zijn aangepast. Gebruik het volgende commando om in één keer (vanuit je domein.nl map) alle PHP bestanden in deze map(pen) op te sporen :

find images/ -name "*.php"

Mocht je lang niets aan de site gedaan hebben dan kan je kijken welke bestanden tijdens de afwezigheid aangepast zijn. Deze methode is niet waterdicht omdat de timestamp van bestanden aangepast kan worden.

find ~/*bijvoorbeeld.nl/* -mtime -10

Dit commando zoekt alle bestanden die tijdens de afgelopen tien dagen aangepast zijn. Je kan het getal 10 uiteraard naar smaak aanpassen. In de resultaten zal je veel caching bestanden tegen komen, maar dat is geen reden om ze te negeren. Het kan juist zo zijn dat de cache bestanden interessant zijn, bijvoorbeeld omdat een mechanisme misbruikt wordt om PHP code naar de cache map te schrijven.

NeoPI

Een voorbeeld van zo’n programma waar je gebruik van kunt maken is NeoPI. NeoPi zit standaard inbegrepen in de Secure, Performance, Optimize en MCU pakketten. Heb je een Magento of Hypernode pakket? Je kunt dan ook gebruik maken van NeoPI, alleen niet via het Service Panel. Je dient dan handmatig de scanner te gebruiken. Een uitleg hierover vind je op deze pagina van Github.

Hackers hebben vaste trucjes om de malafide bestanden die ze op jouw site plaatsen niet op te laten vallen. NeoPI weet precies waar je op moet letten. De tool scant alle bestanden van jouw website die op onze servers staan. Deze scan bestaat uit een aantal tests die deze bestanden beoordeelt op hoe verdacht deze zijn en geeft elk bestand een score mee. Op basis van de resultaten uit deze scan, kun je gericht op onderzoek uit gaan. Dit bespaart je een hoop tijd! Hoe je je site kan laten scannen en hoe je de resultaten kunt uitlezen wordt hieronder uitgelegd. Kijk ook voor meer informatie over NeoPI in het artikel NeoPI Security Scan.

Meer technische info over hoe de tool te werk gaat? Lees het hier.

Let op! Om NeoPI te kunnen gebruiken heb je Shell nodig. Een Personal hosting pakket dien je dus te upgraden naar minmaal een Secure pakket, mocht je gebruik willen maken van NeoPI.

Verdacht bestand gevonden, wat nu?

Nu kan je gericht op zoek naar de reden dat je site gehackt kon worden: het lek. Sommige mensen zullen zeggen; “die heb ik net gevonden” maar dat is waarschijnlijk niet het geval. Je hebt bestanden gevonden die de hacker toe heeft kunnen voegen aan de site, omdat er ergens misbruik gemaakt kan worden van een mechanisme wat onvoldoende beveiligd is. Meestal is dat een plugin die onvoldoende beveiliging biedt, De bestanden waar de voorgaande zoektocht toe geleid hebben zijn een gevolg en niet de oorzaak.

Met een bestand heb je meestal nog niet alles gevonden. Op het moment dat een hacker een webshell toegevoegd heeft, kan hij alle bestanden bewerken en is het peanuts om bestanden toe te voegen of aan te passen. Dat maakt dat de kans bestaat dat er meerdere webshells in het pakket staan. Als dit het geval is is het een goed idee om te kijken naar de datum waarop deze bestanden toegevoegd zijn, hieraan kan je zien;

– Wanneer de hacker ongeveer actief geweest is.
– Welke van de gevonden bestanden als eerste toegevoegd is.

Het laatste is nog wel het interessantst van allemaal. Als het oudste bestand wat je gevonden hebt het eerste bestand is wat door de hacker toegevoegd is, dan kan de locatie ervan informatie bevatten over het lek wat misbruikt is om het bestand toe te voegen. Een voorbeeld is het timthumb script. Als de oudste webshell die je gevonden hebt zich bevindt in bijvoorbeeld.nl/timthumb/cache/544115448.php dan kan je vrijwel zeker stellen dat het gedateerde timthumb script in bijvoorbeeld.nl/timthumb/ de aanleiding tot de hack geweest is.

Voor het achterhalen van de echte oorzaak van een hack is alle kennis over de code die op de site draait meegenomen, omdat je op zoek moet naar een plausibel scenario om de shell te injecteren. Als je zeker wilt zijn dat het lek wat misbruikt is gedicht is, moet je zorgen dat je als “gewone” bezoeker de stappen kan reproduceren om de webshell die je gevonden hebt te injecteren. Hiervoor hoef je meestal niet helemaal het wiel uit te vinden. Je kunt met Google kijken of er kwetsbaarheden bekend zijn in de gebruikte versie, en kijken of de impact van deze kwetsbaarheden overeen komt met wat je overkomen is.

Meer informatie

1