WPS - Van handig hulpmiddel naar gapend gat

Een goed beveiligd WiFi netwerk opzetten is niet voor iedereen even makkelijk. Daarom is in 2007 WPS (WiFi Protected Setup) in het leven geroepen. Maar hoe protected is het?


Het principe van WPS is heel simpel. Nadat je het accesspoint hebt aangesloten op het thuisnetwerk, hoef je op de apparaten die toegang willen enkel verbinding maken. WPS doet de rest:

Bij elk apparaat wat aan het draadloze netwerk verbonden moet worden, voer je de 8-cijferige WPS PIN in, en klaar. Simpel toch?

Maar wat is het dan het gevaar? Het ontwerp van het WPS protocol zelf. Normaal gesproken zou je denken dat je met een pincode van 8 cijfers 10^8 (10x10x10x10x10x10x10x10) = 100.000.000 mogelijke combinaties zou hebben. Echter, door een ontwerpfout (of feature?) is het mogelijk om te zien of de eerste 4 cijfers van de pincode goed geraden zijn, ook al zijn de laatste 4 onjuist. Dit verkleint het aantal benodigde pogingen om de coden te raden tot 10^4 + 10^4 (10x10x10x10 + 10x10x10x10) = 20.000. Een aantal van een factoor 5000 kleiner! Daarnaast is het zo dat het 8ste getal altijd een checksum is van de eerste 7, wat het maximaal aantal poginen op 11.000 zet, in plaats van 100.000.000.

Nadat dit bekend werd, heeft het niet lang geduurd voor een tool was om dit te exploiten. Een linuxtool met de naam "reaver-wps". Maar hoe werkt het? Hier een kleine demo.

Na de installatie van reaver, is het eerst nodig te kijken welke netwerken er zijn. Daarvoor moet eerst de netwerk adapter in de zogenaamde "monitor mode" geplaatst worden:

Hierna is het mogelijk om het luchtruim af te scannen voor WiFi netwerken:

(Gecensureerd wegens privacy redenen)

Hier is ons netwerk (WPS Crack Demo) te zien, net een WPA2 encryptie. In combinatie met de ingestelde 64bit sleutel zou dit op de "ouderwetse" manier weken, maanden of zelfs jaren duren voor de sleutel achterhaald is. Maar niet met WPS. We zetten de aanval in met reaver:

En zo pruttelt reaver rustig door tot hij eerst de eerste helft, en daarna de tweede helft van de pincode gevonden heeft. Afhankelijk van het type accesspoint, de afstand, en geluk, kan het enkele minuten tot uren duren voordat de sleutel gevonden is. Dit is echter een stuk beter dan de maanden die het zou duren op de oude manier. Een ander voordeel is dat er voor dit soort aanval geen gebruikers actief hoeven te zijn op het accesspoint, en dat het cracken zo goed als geen CPU kracht van de aanvalscomputer vereist.

Als de pincode gevonden is, zal de router ons netjes de 64bit WPA2 sleutel vertellen:

(Hier duurde het slechts 61 seconden, omdat alle omstandigheden ideaal waren)

Dit laat zien dat het met het vinden van deze kwetsbaarheid belachelijk makkelijk is om op elk accesspoint met WPS in te breken. Zelfs MAC filtering of een verborgen SSID zijn maar een kleine hindernis, een MAC adres is immers zo gespoofed, en verborgen netwerken zijn niet echt *verborgen*. Een leuk feitje is dat 90 tot 99% van de consumenten routers en accesspoints deze functie standaard aan hebben staan.

Dus, wil je een echt veilig netwerk, schakel WPS dan uit, en zorg voor een goede, en vooral lange sleutel, samen met WPA2-AES encryptie.

*** DISCLAIMER: Dit blog is geschreven om educatieve redenen. Doe dit *nooit* zonder toestemming van de eigenaar van het netwerk. ***

Gecertificeerd hacker - Doe het zelf DigiD

In mijn laatste blog heb ik het gehad over een groep hackers die bijna alles wat ze deden openbaar maakte op het internet, met de vraag wat er door andere personen allemaal nog verborgen wordt. Deze week is daar een antwoord op gekomen. Een manier om al het internetverkeer van iedereen te onderscheppen.


Mensen die het nieuws gevolgd hebben de laatste tijd weten natuurlijk dat ik het (grotendeels) heb over DigiNotar, de gehackte Certification Authority (CA). Maar niet iedereen zal meteen weten wat een CA is, en wat ze precies doen, dus eerst een kleine uitleg.

Normale websites die men bezoekt zijn niet versleuteld. Dat houdt in dat alle tekst zoals hij te zien is op een website, ook zo over het internet van de webserver naar de opvragende computer gaat. Iemand die dit verkeer kan zien, kan dus ook meekijken met de inhoud van alle websites die iemand bezoekt. Omdat dit bij sommige websites niet bepaald gewenst is (Denk aan dingen als internetbankieren, DigiD, enzovoort), worden "gevoelige" sites beveiligd met een SSL versleuteling.

Hoe herken je een versleutelde websites? Zoals tegenwoordig zelfs de overheid aan mensen vertelt, het alom bekende "Slotje" op een website:

Dit slotje houdt in dat al het verkeer tussen de webserver en de internetbrowser is versleuteld met een certificaat. Als je (In de meeste browsers) op het gedeelte met het slotje klikt, krijg je meer informatie te zien over de website en het gebruikte certificaat:

Hier staat dat de verbinding is gecodeerd met een 256-bits TLS codering, en dat er gebruik wordt gemaakt van een VeriSign Class 3 certificaat. Ook al zou iemand dit verkeer dus onderscheppen, is het onleesbaar. Iemand kan het wel onderscheppen, decoderen, lezen en weer coderen voordat het doorgestuurd wordt, maar dan zal het certificaat dat gebruikt wordt voor de codering niet meer geldig zijn, en zal de browser hier een waarschuwing voor geven.

Maar waarom is het certificaat niet meer geldig? Een certificaat is een certificaat? Dat klopt, iedereen kan certificaten generen. Daarom worden er in browsers gebruik gemaakt van zogenaamde "Root certificaten". Deze certificaten laten de browser (En andere applicaties) weten welke bedrijven geautoriseerd zijn om certificaten uit te geven. Elk certificaat wat door zo'n bedrijf wordt uitgegeven is voor de browser dus automatisch een goed certificaat, en zal een groene balk / tekst met een slotje opleveren. Als iemand dus zelf een certificaat uitgeeft, zal deze door de browser niet gezien worden als authentiek certificaat en zal er een waarschuwing verschjinen:

Een belangrijk punt in deze beveiligingsmethode is dus vertrouwen. We moeten de bedrijven welke certificaten uitgeven (De CA's) vertrouwen alleen goed gecontroleerde certificaten uit te geven, aan mensen die ook het recht hebben deze certificaten te gebruiken..

DigiNotar is één van deze CA's. Helaas voor DigiNotar, en een hoop andere mensen, is een Iraanse hacker achter het Amdministrator wachtwoord gekomen van de server die dit bedrijf gebruikt om de certificaten uit te geven. Met dit wachtwoord is / was het mogelijk voor deze hacker om voor elke website een geldig certificaat uit te geven, en dat heeft hij/zij ook gedaan. In totaal zijn er zelfs 531 "valse" certificaten uitgegeven (Bron). Waaronder ook certificaten voor veelgebruikte diensten als Windows Update en GMail, waardoor het voor deze hacker dus mogelijk is dit verkeer te onderscheppen zonder dat een gebruiker hier iets van door heeft, en waar geen enkele beveiliging tegen opgewassen is.

Dus wat is dan de oplossing? Het root certificaat van DigiNotar intrekken. De grote browsers (Mozilla Firefox, Google Chrome) hebben dit ondertussen ook gedaan. Dit houdt wel in dat ALLE certificaten uitgegeven door DigiNotar nu ongeldig zijn in die browsers. En helaas voor ons gebruikt de Nederlandse overheid DigiNotar certificaten voor websites als DigiD, en de belastingdienst.

Het gevolg is dat zelfs websites als DigiD en de belastingdienst veiligheidswaarschuwingen opleverde in sommige browsers. En dit is het puntje waar veel mensen en nieuwssites de mist in gaan. Deze websites zijn op geen enkele manier gehacked, en er is geen onversleutelde verbinding. Alle data wordt nog steeds verzonden over een SSL versleutelde verbinding tussen de webserver en de browser. Alleen als iemand het verkeer kan omleiden door bijvoorbeeld de DNS server (De server die de computer vertelt naar welk adres de verbinding gelegd moet worden bij een bepaald website adres) te hacken. Maar de kans dat dit kan gebeuren is heel klein. Toch?

Blijkbaar is die kans groter dan gedacht. Een nieuwskop van afgelopen maandag: "Hackers kapen dns-systeem NetNames en bekladden bekende sites". Oeps. Een combinatie van deze twee hacks houdt in dat een kwaadwillende hacker AL het internetverkeer kan omleiden naar waar hij/zij dan ook wil, zonder dat een gebruiker hier IETS van merkt. Een scenario met gevolgen zo groot, dat het de fundamenten van internetbeveiliging kan laten schudden. Maar goed dat men hier uiteindelijk toch achter gekomen is, anders zouden de gevolgen niet te overzien zijn.

Of zouden er toch nog steeds dingen niet boven zijn gekomen? Als we dit bericht van de hacker (volgens eigen zeggen) van DigiNotar moeten geloven heeft hij/zij nog 4 andere CA's onder controle: "You know, I have access to 4 more so HIGH profile CAs, which I can issue certs from them too which I will, I won't name them" (http://pastebin.com/1AxH30em). Dat zou dus betekenen dat er potentiëel honderden websites op dit moment niet veilig zijn. Iedereen spreekt over de "hack van DigiD" terwijl we blij moeten zijn dat men het van die partij doorheeft. Wie weet wat er op dit moment door hackers gelezen wordt? Ik wil er niet eens over nadenken. Dan liever alle gegevens van gehackte bedrijven op straat.

The Chronicles of XSS - HTML, Cookies and Javascript

"Why is that Narnia reference in the title?" you might ask yourself. Well, in the movie, the characters were able to enter a whole new world with new possibilities through a small wardrobe. That's what XSS does, open up new possibilities through a small hole.


First off, let me start with a little disclaimer. This blog is for educational purposes only. I am by no means an expert XSS exploiter or an experienced web developer. I just like to mess around on the internet. If you came here to learn how to exploit XSS, you came to the wrong place. I will not be naming websites or showing the actual XSS used. No websites were harmed in the making of this blog.

So what is XSS? Well, let's quote wikipedia on that one: "Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users.". Does that make it clear? No, didn't think so. I'll try to explain using some real world examples.

As you may or may not know, the most basic language used to create websites is HTML. HTML contains everything a browser needs to know to display a website. It has the style, content and everything else in one file. The browser interprets this file and builds the website for you to browse. Now, some websites also have inputs available for their viewers. Think of things like contact forms, guestbooks, stuff like that. This is where the basics for XSS lie.


When you enter text into an input field and click "Submit", the data is sent to the webserver, who in turn gives your browser a new HTML file with the text you entered processed in it. So if you have signed the guestbook and posted "Great website!", that will show as the latest entry in that guestbook. That means that text is now somewhere in the HTML file. So what if you paste HTML into that text field, can you alter the website? Yes, and that's exactly what XSS is.

When you paste HTML code into an input form on a website that does not properly trim the input, you can "break open" the form and change the layout of the website itself. An example of a guestbook that is vulnerable to XSS exploiting:

This is your typical guestbook. You enter a name, a code to prove you're human, and your message. But what happens if you insert a prepared XSS string? Well then you can add pretty much anything you want outside of the input fields:

As you can see I have succesfully changed the lay-out of the website to show a big "Hello World" underneath the "Your Name:" field. While this change is only visible to me, and not dangerous to the website and it's users, it's still an opening. If I were to post this on the guestbook, all of the visitors to that website would see the broken lay-out.

So, we can change the appearance of a website to all it's users, now what? Well, the next step you could take is to check if you can execute javascript. Javascript is used on most websites, and supported by most browsers. If you want more information about Javascript, see this page. For this example I will use another website, this time the contact form:

And I insert my prepared XSS string with javascript code:

As you can see, I have made the webpage display a pop-up telling me it is exploitable. While this is harmless Javascript, you could theoretically inject any javascript. Javascript that steals your facebook cookies and places them somewhere for the attacker to take them, for example. Post this XSS exploit to a guestbook and everyone visiting that guestbook will have their facebook cookies uploaded somewhere else. So what, you might ask? Well, an attacker can use these cookies to access your facebook profile, thats what. How does that work exactly? Well, check out this blog.

The thing is, although this all sounds very complicated and high tech, almost everyone can do it. Here are some examples of exploitable sites I found on google when searching for "sign guestbook" on the first two or three pages:

Nice collection right? Like I said, I will not be naming these websites, but trust me when I say that some of these examples are not small, private websites. Some are actually quite large with a lot of visitors. A better known example of XSS recently is this twitter exploit where people managed to use XSS to create a self spreading "virus" on Twitter.

So how do you protect yourself from XSS? Well, first of all, make sure that your website is correctly sanitizing inputs. Don't put simple input forms everywhere and expect for them to be secure.

If you're a user? Well, that's a different story. Because XSS is HTML, and executed by the browser, most (all) security software packages will not detect them (or not untill they start calling malicious javascript files at least). So what then? Well, protect the browser itself. There are a number of add-ons for Firefox and Chrome to prevent XSS or even disable all scripts entirely. It's a bit like killing a fly with a shotgun, but it works.

The point of this blog is to create awareness among web designers to properly secure their websites and make sure that XSS is not possible. With properly executed XSS, anything is possible. As XSS is becoming more and more popular, more and bigger sites will get attacked. In the end, this is what a web designer wants someone using XSS exploits to see: