CYBER SECURITY.
CYBER SECURITY.
Preventie
Inzicht
Cyberlab

Pentest website of webapplicatie: schaken met hackers

24 oktober, 2019

Door het uitvoeren van pentesten helpt IP4Sure Nederlandse bedrijven en organisaties bij het beveiligen van hun netwerken, applicaties en websites. Maar wat doen we precies bij een pentest? Hoe gaat het in zijn werk? Wat testen we allemaal en welke methoden gebruiken we daarbij? En wat hebben onze klanten er uiteindelijk aan? Ik merk dat er nog veel onduidelijkheden bestaan over de pentest en die wil ik met deze blogserie zoveel mogelijk wegnemen. Ik beschrijf wat een pentest inhoudt, ik bespreek het belang van geautomatiseerd én handmatig testen en ik vertel hoe het organisaties kan helpen de onopgemerkt gebleven gaten in hun beveiliging te dichten voor ze kunnen worden uitgebuit door hackers. Vandaag: pentesten op de webomgeving.

Door: Stan van der Vleuten, Ethisch Hacker

Een penetratietest of pentest is het testen van websites, netwerken, applicaties of computersystemen op kwetsbaarheden, waarbij deze kwetsbaarheden ook werkelijk gebruikt worden om in deze systemen in te breken. Een pentest vindt plaats met toestemming van de eigenaar van de systemen of applicaties die onderzocht worden en heeft als doel om kwetsbaarheden op te sporen en de systemen of applicaties beter te beveiligen. Veel mensen zullen bij een pentest in eerste instantie denken aan het testen van de kwetsbaarheden van een bedrijfsnetwerk. Maar tegenwoordig zijn webapplicaties bijna belangrijker dan het gemiddelde interne netwerk en we zien de focus dan ook verschuiven.

Wat is de reikwijdte van de website pentest?

Belangrijk is om eerst te bepalen wat een klant met een pentest wil bereiken. Wil men nagaan of de beveiliging goed op orde is? Wil men de kroonjuwelen van het bedrijf optimaal beschermen? Wil het bedrijf voor klanten aantoonbaar maken dat ze serieus met security bezig zijn? En wat moet er precies getest worden? De volledige website van de klant, of bijvoorbeeld alleen een specifieke webapplicatie van een developer? Wat de doelstelling ook is, voor we aan de slag kunnen gaan, moeten we dit eerst in overleg met de klant scherp zien te krijgen.

Dan is er de fase die we ‘threat modeling’ noemen. Daarbij brengen we in kaart in welke context het bedrijf of de webapplicatie staat en wat het belang van mogelijke kwaadwillende actoren kan zijn. Op basis hiervan kunnen we uitvoerbare doelen opstellen. Een doel kan bijvoorbeeld zijn om de webserver over te nemen, of een admin-account aan te maken. Dit soort praktische doelstellingen zorgt ervoor dat de klant na voltooiing van de pentest niet per se de technische verhandelingen door hoeft te lezen, maar direct weet of de gestelde doelen behaald zijn of niet. Zo kunnen mensen binnen de organisatie die de technische details niet volledig snappen, toch begrijpen wat de status van hun webapplicatie is.

White box of black box

Vervolgens spreken we met de klant af welke benadering we gaan gebruiken bij de pentest. Meestal adviseren wij het zogenaamde whitebox-onderzoek. Dat houdt in dat de klant ons zoveel mogelijk informatie verschaft over de applicatie of de omgeving die getest moet worden: we spelen open kaart. De klant overhandigt ons bijvoorbeeld de documentatie die over de ontwikkeling is bijgehouden en de informatie over de structuur en de architectuur. Op die manier hebben we van tevoren een duidelijk beeld van wat we aan zullen treffen en dat kan veel tijd besparen.

Het kan echter ook zo zijn dat de klant tijdbesparing minder belangrijk vindt en echt wil onderzoeken wat een buitenstaander zonder informatie over het bedrijf of de webomgeving voor elkaar kan krijgen. In dat geval kiezen we voor een blackbox-onderzoek, wat inhoudt dat we van tevoren zo min mogelijk informatie krijgen. We weten dan bijvoorbeeld alleen de URL van de website die getest moet worden. Kunnen we op dit domein misschien een account voor onszelf aanmaken? Kunnen we via een fout in de code meer rechten op dat account verkrijgen? Kunnen we bij databasegegevens komen die ontoegankelijk zouden moeten zijn? Omdat we niet precies weten wat we aan zullen treffen en zelf moeten achterhalen hoe de scripts en applicaties werken, kan dit veel tijd in beslag nemen.

Hoewel een blackbox-onderzoek in sommige gevallen de aangewezen methode kan zijn, adviseren wij doorgaans de whitebox-methode, omdat kwaadwillenden in veel gevallen online dezelfde hoeveelheid informatie kunnen achterhalen die wij kunnen verkrijgen door het netjes te vragen. Blackbox brengt dus vooral in kaart wat iemand op korte termijn te weten kan komen over de website of applicatie.

Techneuten onder elkaar

Nadat we met de klant hebben bepaald wat de scope en de methode is die we bij het onderzoek gaan gebruiken, legt onze technisch specialist contact met de technisch specialist van de klant. Tussen hen worden operationele afspraken gemaakt. Wanneer communiceren we dat we een ernstige kwetsbaarheid hebben gevonden? Hoe ernstig moet een kwetsbaarheid zijn om de organisatie direct op de hoogte te stellen? Het kan bijvoorbeeld zo zijn dat de klant een kwetsbaarheid in een webapplicatie snel wil verhelpen, zodat de fix mee kan worden genomen in de volgende release. Andere klanten willen direct alles wat toevallig opvalt of misgaat weten, omdat er potentieel veel belangen mee gemoeid zijn. Weer andere klanten willen alleen een assessment achteraf om een globaal beeld te krijgen van hoe veilig ze zijn.

Handmatige pentest versus tooling

Nu de scope, de methode en de operationele afspraken zijn vastgelegd, kan het daadwerkelijke onderzoek beginnen. Een pentest voor website en webapplicatie test eigenlijk alleen maar op acceptatieomgevingen. De website is immers vaak belangrijk voor een organisatie en je hebt liever niet dat er met de website die live staat iets misgaat, of dat de beheerder allemaal vreemde zoekopdrachten voorbij ziet komen in de logbestanden. Waar sommige beveiligingsspecialisten voornamelijk geautomatiseerde tooling inzetten bij beveiligingstesten, hanteren wij een mix van tooling en handwerk. Tooling is zeker belangrijk, omdat je hiermee veel laaghangend fruit en bekende kwetsbaarheden geautomatiseerd op kunt sporen, maar het zorgt potentieel ook voor ‘false positives’. Elke applicatie is immers anders, dus de tooling zal de reacties van de software niet altijd juist interpreteren. Soms lijkt een reactie op een kwetsbaarheid te duiden, maar is die reactie in de context van de specifieke applicatie juist gewenst. Ook is er het risico dat de tooling bepaalde kwetsbaarheden simpelweg niet opmerkt, omdat zij niet als zodanig door de algoritmes herkend worden.

Daarom bestaat een website pentest die IP4Sure uitvoert voor het grootste deel uit handwerk. Het webprotocol zorgt ervoor dat informatie leesbaar en begrijpelijk is voor mensen. Daarom is de menselijke factor in een pentest zo belangrijk. Het handwerk bestaat onder meer uit het analyseren van de requests die plaatsvinden, oftewel de verzoeken die gebruikers aan de applicatie kunnen doen. Zo’n request kan bijvoorbeeld het volgende inhouden: “ik wil graag de loginpagina van de webserver opvragen en dat wil ik doen met deze extra informatie die ik verstuur”. Een groot deel van het pentesten van websites en webapplicaties is simpelweg onderzoeken wat er gebeurt als je die extra informatie weglaat, of wat er gebeurt als de tester zegt dat hij een beheerder is met adminrechten. Je probeert de logica van de webapplicatie voor de gek te houden met scenario’s die de developer van de applicatie misschien niet voorzag tijden het ontwikkelen. Dat is de meerwaarde van menselijke intelligentie versus automatische tooling.

Wat halen onze klanten uit de website pentest?

Als je een dienst afneemt van een beveiligingsspecialist, dan verwacht je natuurlijk wel een duidelijk en begrijpelijk resultaat, waarmee je vervolgens aan de slag kan om je beveiliging aan te scherpen. IP4Sure levert daarom niet alleen een technische rapportage, die misschien alleen door de developer van de applicatie begrepen kan worden, maar ook een rapportage die de bevindingen duidelijk omschrijft en voorziet van uitgewerkte oplossingen met referenties. Zo wordt meteen voor iedereen in de organisatie duidelijk wat er moet gebeuren om de beveiliging op orde te krijgen en hoe ze de oplossing kunnen implementeren.

Onze bevindingen worden bovendien voorzien van een ernstniveau volgens de CVSS-classificatie dat bestaat uit vier lagen: laag, medium, hoog en kritisch. Bij een laag niveau is er wel een kleine kans op gevaar, maar het is niet erg realistisch dat er iets zal gebeuren. Ons advies is dan evenwel om er toch naar te kijken. Bij een kritisch niveau is het aan te raden om de applicatie direct offline te halen, bijvoorbeeld omdat de mogelijkheid bestaat dat iemand de hele webserver over zal nemen. We geven duidelijk aan hoe de kwetsbaarheid is ontdekt en hoe hij in een paar eenvoudige stappen kan worden gereproduceerd, zodat de ontwikkelaar de hack zelf ‘na kan spelen’. Een pentest levert zo concrete en uitvoerbare resultaten op, waarmee organisaties de beveiliging van hun webapplicaties kunnen optimaliseren om hackers te slim af te zijn.

Wij werken met veel plezier o.a. voor