Een ‘gaatje’ in mijn agenda
Wij bij HackDefense proberen hedendaagse digitale technologie tot op het diepste niveau te begrijpen. We kunnen echt genieten van de technieken die achter een hack schuilgaan. Maar daarna is het de uitdaging om deze technische materie inzichtelijk te maken voor beslissers met én zonder ICT-achtergrond. Voor bestuurders en CISO’s die de strategie en tactiek moeten bepalen. En voor de beheerders en de technici die meer willen weten over de details van de techniek.
Kwetsbaarheden verhelpen
Wij zijn groot liefhebbers van open source software. Dit is de filosofie waarbij de broncode van een stuk software vrij beschikbaar is, zodat iedere enthousiaste programmeur – of ethische hacker – toevoegingen of verbeteringen kan aanbrengen. Zo zijn collega Niels van Gijzen en ik de afgelopen maanden bezig geweest om drie kwetsbaarheden in het softwarepakket DAViCal te melden en te verhelpen.
DAViCal is een open source softwarepakket voor het delen van agenda’s. Je kan het vergelijken met Google Agenda maar hier ben je zelf in controle over de data. In deze blogpost wil ik dit praktijkvoorbeeld gebruiken om de kwetsbaarheid Cross-site Scripting (XSS) uit te leggen.
Cross-Site Scripting in het kort
Cross-Site Scripting (XSS) is een type kwetsbaarheid die een aanvaller in staat stelt om kwaadaardige scriptcode in een kwetsbare webapplicatie te injecteren. Het probleem wordt veroorzaakt doordat de gebruikersinvoer die de webapplicatie ontvangt – bijvoorbeeld een speciaal geprepareerde URL – niet juist wordt verwerkt en zo in de uitvoer terechtkomt naar de eindgebruiker. Er zijn twee vormen van XSS: reflected XSS en persistent XSS.
Reflected XSS
Bij de eerste vorm van een XSS-aanval wordt de invoer van de gebruiker gebruikt, bijvoorbeeld informatie uit de URL, om een stuk van de pagina te genereren, zonder deze informatie te controleren of te beveiligen. Dit is de eenvoudigste vorm van cross-site scripting. Deze abstracte theorie wil ik aan de hand van het praktijkvoorbeeld uitleggen.
De DAViCal-webapplicatie kent onder andere onderstaande pagina:
Als je het woord principal in de URL vervangt door test word je naar een andere pagina geleid.
Je ziet hier dat het woord ‘test’ wordt overgenomen op deze pagina. Deze pagina wordt dynamisch opgebouwd op basis van de HTML-code <li class="messages">No page found to edit a test</li>. Omdat de DAViCal-webapplicatie niet filtert op karakters die een speciale betekenis hebben in HTML, zoals <, >, " en ', kan een kwaadwillende speciale scriptcode invoeren om zo het antwoord van de webserver te manipuleren.
Zo kun je bijvoorbeeld het woord ‘test’ onderstrepen door de HTML-code <u> te gebruiken.
Behalve HTML wordt vaak JavaScript gebruikt, om een website interactief te maken. Om aan te tonen dat het mogelijk is om JavaScript uit te voeren, wordt vaak een pop-up ofwel alertbox opgeroepen met de JavaScript-code:
http://davical.host/admin.php?action=edit&t=<script>alert()</script>
Dit resulteert in de volgende HTML-code:
<li class="messages">No page found to edit a <script>alert()</script></li>
Persistent XSS
Bij de tweede vorm van een XSS-aanval wordt de invoer van de gebruiker naar de server gestuurd en daar wordt de invoer, zonder gecontroleerd of beveiligd te worden, gebruikt om onder andere een HTML-pagina te genereren. Hieronder geef ik een ander praktijkvoorbeeld om deze kwetsbaarheid te demonstreren.
We gaan weer terug naar de eerste pagina. Als we nu het veld ‘Fullname’ aanpassen, zien we dat deze invoer aan de bovenkant van de pagina wordt overgenomen.
Ook nu testen we, met de HTML-code <u>, of deze gebruikersinvoer correct gefilterd wordt op karakters met een speciale betekenis in HTML.
Ook proberen we, met de bekende alertbox, of we JavaScript kunnen injecteren.
Impact van XSS in de praktijk
Misschien denk je nu: nou en? Dan heb je een alertbox, wat is daar erg aan? Maar deze simpele alertbox kun je vergelijken met het ontbreken van de veiligheidsschakelaar van een pistool. Een leek ziet slechts dat een kleine schakelaar niet op zijn plek zit. Maar gaat het pistool onverhoopt af en ben je getuige van de schade die zo’n wapen kan veroorzaken, begrijp je ineens het belang van dat kleine schakelaartje. Een alertbox brengt een kwetsbaarheid aan het licht. Iemand die kwaad wil, kan zo’n XSS-kwetsbaarheid misbruiken door een gebruiker door te sturen naar een andere, malafide, website of door een sessie-ID van een gebruiker te stelen en zich voor te doen als die gebruiker. Zo kunnen allerlei schadelijke scripts uitgevoerd worden. Over twee weken zoomen we verder in op de gevaren van XSS.
En nu?
Je kunt een dergelijke kwetsbaarheid voorkomen door invoer en uitvoer te valideren. Wil je daar meer over weten of ben je benieuwd wat wij met onze – ethische – hacker mindset voor jouw organisatie kunnen betekenen? Neem gerust contact met ons op, we denken graag met je mee.
Rick Verdoes, Senior Ethical Hacker en IT Security Advisor