Ontdek Hacker Code

Het ontdekken van malafide code is een belangrijke eigenschap van een security analist. Elke dag bekijken en scannen we vele MB’s aan code. Daarbij zien we snel code over het hoofd. In deze post laat ik je zien hoe snel je code over het hoofd ziet en waardoor een potentieel gevaar onopgemerkt blijft.

Denk als een hacker:

Stel je eens voor dat jij een spionage script geschreven hebt en deze hebt kunnen installeren implementeren op een website. Allereerst een dikke schouderklop voor jezelf. Maar hoe zou je deze code wegschrijven? Zou je erbij zetten:

===SPY APP by HACKERx1===

? Nee toch? Waarschijnlijk zou je dit iets subtieler aanpakken. Malafide code is dus meestal niet zomaar te vinden. Of zoals de Amerikanen dat zo mooi zeggen “don’t judge a book by it’s cover’.

Kijk verder:

Ook als scripts helemaal vertrouwd lijken te zijn maar niet 100% bekend zijn is het goed om verder te kijken.

Bekijk de volgende code:

Klik op de afbeelding om te vergroten.

Deze Javascript code zien we vaak terug op gehackte websites. De echte (goed leesbare) code is verborgen. Zodra we deze bekijken zullen we zien dat er een iFrame geladen van en externe website (welke waarschijnlijk malafide code in de gehackte website plaatst).

De volgende code is een stukje voorbeeld PHP code die we ook veel zien (op gehackte Joomla websites):

Klik op de afbeelding om te vergroten.

Deze code is een stukje encoded PHP script. De “eval(base64_decode());” functie decode de malafide code en de “eval()” voert deze code uit (evalueert hem).

De code die uitgevoerd wordt zou je zelf kunnen bekijken door “eval(base64_decode());” te vervangen voor “echo base64_decode();”. Uiteraard kun je ook een PHP Decoder uitproberen om de encoded code te lezen zoals deze.

Bovenstaande code’s zullen bij de meeste webmasters een belletje doen rinkelen. Ze zien er vreemd uit en bevatten code die niet gelezen mag worden. Dit betreft meestal een betaalde plugin waarbij de source code verborgen is of malafide code.

Er zijn echter ook voorbeelden waarbij het een stuk lastiger is om malafide code te ontdekken. Zie bijvoorbeeld onderstaande code:

Klik op de afbeelding om te vergroten.

Het eerste script ziet er netjes uit. Het script is gewoon leesbaar (variabelen hebben een normale naam) en het script ziet eruit als een Google Tracking script. We zien dat het script een Javascript laad die waarschijnlijk extra functionaliteiten / logmethodes toevoegt aan de normale Google Analytics functionaliteit. Op zich niets ongewoons.

Het tweede script is een bekend script. Dit is het primaire Google Analytics script. Ook niets vreemds dus.

Kortom: over deze code wordt heel gemakkelijk heen gelezen. Dus stop en bekijk de eerste code nogmaals.

Als we goed kijken zien we dat er een ga.js Javascript file ingeladen wordt van “googleanalyticsextra.pl”. En dat is op zich verdacht. .pl is een Poolse domeinnaam. Logischerwijs zou Google altijd scripts van een .com domein laden.

Bij bovenstaande constatering is het dus zaak om uit te zoeken wat het “googleanalyticsextra.pl/js/ga.js” script werkelijk doet, waar het vandaan komt en hoe het in de website geladen wordt (wat is er lek waardoor dit script in de broncode geïnjecteerd is).

Daarnaast is een volledige check-up van de website en de database nodig omdat er waarschijnlijk meerdere files geïnjecteerd zijn met malafide code. Ook een database controle is op zijn plek omdat deze vaak ook geïnjecteerd is met code.

Conclusie:

Een security analist moet malafide code kunnen herkennen. Als er ook maar enige twijfel over het script bestaat moet uitgezocht worden wat het script exact doet en waar het vandaan komt. Door te snel te oordelen en niet nauwkeurig te kijken kunnen we fouten maken waardoor de veiligheid van de website in gevaar blijft.

Ook website bouwers en website eigenaren moeten op de hoogte zijn van dit soort scripts. U kunt gemakkelijk zien of een bestand malafide code bevat doordat deze “veranderd” is terwijl u fysiek niets in het bestand heeft aangepast. U kunt b.v. uw huidige bestanden vergelijken met de laatste backup. U kunt dit doen middels het –diff commando:

ssh user@website “cat /pad/naar/website/file” | diff – /pad/naar/local_backup/file