Hackers gehacked

NB: deze blog post is redelijk oud

We hebben sinds dit artikel een nieuwe website gekregen. Wellicht ziet dit artikel er daarom niet zo uit zoals je zou verwachten.

Als je denkt dat deze pagina erg nuttig is, en hij er niet mooi uit ziet of niet goed functioneert, neem dan contact met ons op.

Attribution: Some rights reserved by Dan Zen

Het gebeurt helaas af en toe dat een site van een klant van ons gehacked wordt. Vaak komt dit doordat de klant niet de laatste versie van de door hem of haar gebruikte software geïnstalleerd heeft. Hoewel veelgebruikte pakketten zoals Joomla!, Drupal of WordPress gelukkig nog maar zelden kritieke bugs hebben is dit lang niet het geval bij veel gebruikte plugins binnen deze omgevingen. Het zijn vaak deze plugins, die een gebruiker in  staat stellen om bestanden zoals foto's via de webbrowser te uploaden, die bugs bevatten. Een hacker misbruikt dan zo'n plugin om een dynamisch uitvoerbaar bestand (php of perl) te uploaden en deze vervolgens uit te voeren. Het is dan de plugin die verzuimt goed te controleren of de gebruiker überhaupt ingelogd is en de juiste rechten heeft, of het bestand goed te controleren op type; wordt er daadwerkelijk een foto ge-upload?

Het doel van de hacker is tegenwoordig nog maar zelden om een site te defacen, maar heeft vaak als doel de infrastructuur van de hoster (in ons geval dus Greenhost) te misbruiken. Door de capaciteit van hoster (die meestal via breedbandige verbindingen is aangesloten) te gebruiken kan een hacker op deze manier een andere site aanvallen of spam versturen zonder dat de hacker zelf deze capaciteit hoeft in te kopen.

Hosters beschermen meestal hun klanten door iedere klant een maximale capaciteit toe te wijzen en/of uitgaande verbindingen te beperken. Desalniettemin, zal op deze manier een site van de getroffen klant wel minder goed of niet meer bereikbaar zijn.

Laatst is het weer gebeurd dat een site van een van onze klanten door zo'n hacker misbruikt werd. Gelukkig was het lek snel gevonden en kon deze dicht gezet worden. Echter, leek het ons interessant om uit te zoeken wie deze hacker was, wat zijn doel was  en welke scripts hij gebruikte.

1. De hack

De hacker gebruikte een lek in een veelgebruikte plugin voor een bekend webshop programma. Met deze plugin is het voor de legitieme gebruiker mogelijk om plaatjes/foto's te uploaden en te plaatsen in een map (/images) welke bij producten toegevoegd kunnen worden. Echter de plugin verzuimt te controleren of de gebruiker ingelogd is & of het wel een plaatje is en niet toevallig een php bestand. Door de plugin met bepaalde argumenten aan te roepen is de hacker in staat geweest een php script te plaatsen in /images/ map. Vervolgens is het script aan te roepen via een webbrowser.

2. Het script

Op het moment dat het script aangeroepen werd, maakte deze verbinding met een IRC server. Echter door de connectie te maskeren als zijnde een MySQL verbinding wordt deze door de meeste firewalls doorgelaten. Het script meldt zich vervolgens aan op een specifiek kanaal op de IRC server met een random gebruikersnaam. Deze methode is een veelgebruikte methode die we onder andere ook terug zien bij Trojaanse paarden. Het idee hierachter is dat alle bot's die zo'n verbinding opgebouwd hebben volgens vanuit de IRC te besturen zijn. Zo kunnen ze op afstand een commando's toegestuurd krijgen door deze priveberichten te sturen.

3. Analyse

Na het gebruikte script geanalyseerd te hebben, bleek het bijzonder eenvoudig om mijzelf voor te doen als zijnde een bot en in te loggen op dezelfde IRC server. Deze IRC server was echter maar beperkt beveiligd. Via deze methode was het evident om een lijst op te vragen van andere aangemelde bots. Het bleek zelfs mogelijk om de andere bots een commando te sturen, echter deze reageerde hier niet op. Na verdere analyse van het script, bleek dat er eerste twee specifieke berichten naar een bot gestuurd moeten worden alvorens deze overige commando's kon begrijpen. Deze commando's zijn een soort van login/wachtwoord beveiliging. Echter het bleek dat het wachtwoord wat voor het bij ons geïnstalleerde script hetzelfde was voor alle andere bot's. Op deze manier was het mogelijk alle andere bot's te 'besturen'. Zojuist hadden we een klein botnet overgenomen.

4. Het botnet gebruiken

Nadat we controle hadden over het botnet is de vraag wat we er precies mee konden. Helaas was er slechts beperkt tijd beschikbaar om uitgebreid een analyse te doen over de mogelijkheden. De voornaamste wens was het uitzoeken waar de hack geplaatst was om de beheerder van de sites te kunnen inlichten. Uiteindelijk hebben we besloten om vanuit de bot een email naar ons zelf te sturen, met deze informatie was het mogelijk op zijn minst de beheerder te vinden, welke vervolgens gewaarschuwd is. Daarna hebben we de bot uitgeschakeld/offline gehaald (hier was een commando voor). Uiteindelijk was het botnet dus leeg.

Vanwege de eigenschappen van IRC, waarbij als een kanaal niet bestaat, degene die als eerste inlogt beheerder wordt van dat kanaal, konden we nu beheerder worden van het bewuste IRC kanaal. Ongeveer een uur later logde er een 'normale' gebruiker in (dus niet een bot). Aangezien wij nog steeds beheerder van het kanaal waren, had deze gebruiker het idee dat wij ook de beheerder van het hele botnet waren. Dit heeft nog tot een zeer verwarrende chat geleid waarbij wij geprobeerd hebben te achterhalen waarom ze een botnet hadden en waar deze tegen gebruikt werd.

Het bleek dat dit gebruikt werd om servers van een computerspel (Tibia) aan te vallen. In de virtuele werelden van Tibia heeft iedere wereld een eigen server. Een hoog opgelopen ruzie tussen twee werelden heeft dit misbruik als grondslag gehad.

5. Afloop

Uiteraard hebben we de beheerder van het netwerk waar de IRC server draaide ingelicht. Enkele dagen later was deze server offline. Hopelijk is het botnet nu helemaal offline, het kan ook zijn dat deze ergens anders weer herrezen is…