1. YouTube aangevallen

Het is al weer een tijd geleden, 2008 om precies te zijn: door een fout in de website van Youtube was het mogelijk voor een hacker om hun eigen video populair te laten worden of om andere video’s als ongepast te laten bestempelen. Dat kon met behulp van Cross-Site Request Forgery, afgekort tot CSRF. Dit wordt ook wel uitgesproken als sea-surf. Hoe werkt zo’n aanval?

Cross-Site Request Forgery (CSRF)

Om een aanval via CSRF te kunnen doen moet worden voldaan aan twee voorwaarden:

Voorwaarde 1: Een website verwerkt opdrachten van de gebruiker.

Als je op de website van YouTube een filmpje bekijkt heb je de mogelijkheid om allerlei ‘opdrachten’ te geven. Je kunt bijvoorbeeld aangeven: ‘Ik vind dit leuk’, of ‘Ik vind dit niet leuk’. Dat doe je door op de knopjes te klikken (duimpje omhoog, duimpje omlaag). Als je op zo’n knopje klikt, gaat er een bericht van de browser naar de webserver van YouTube, bijvoorbeeld zoiets als:

like-video id=72378923

De id geeft aan om welke video het gaat. Als we naar de HTML kijken ziet dat er uit als hieronder.

<a href=”https://youtube.com/like-video?id=72378923”>Ik vind dit leuk</a>

Er verschijnt dan op de pagina Ik vind dit leuk, een link waar je op kunt klikken.

Als je kijkt naar bovenstaande html-link dan zie je eigenlijk 2 variabelen namelijk like-video en id. Bij de cursus Een interactieve applicatie heb je al gehad hoe een GET-variabele in een servlet kunnen worden verwerkt. De variabele like-video wordt op een andere manier verwerkt (er zit een algoritme tussen) maar uiteindelijk wordt het ook een GET-variabele. Het algoritme wat op deze website hiervoor wordt gebruikt heet PrettyFaces.

Voorwaarde 2: De website kan achterhalen van wie deze opdracht komt.

Als je bent ingelogd, kan YouTube zien dat jij degene bent die de video leuk vindt. Je kunt dit dus maar één keer doen, het heeft geen zin om vaker aan te geven dat je de video leuk vindt. Anders zou het het wel heel makkelijk worden om te zorgen dat een video in de top 100 best gewaardeerd komt.

Ook als je niet bent ingelogd, kan YouTube zien waar de opdracht vandaan komt. Bijvoorbeeld op basis van het ip-adres, of op basis van de cookies die je browser meestuurt. Zo weet YouTube dus: deze persoon heeft al eerder aangegeven de video leuk te vinden, een tweede keer wordt niet toegestaan.

Als aan de twee voorwaarden wordt voldaan, zou het kunnen dat de website kwetsbaar is voor een CSRF-aanval. Dat gaat in twee stappen.

1. Eve verspreidt een link Als Eve (een hacker) wil dat haar video vaak leuk wordt gevonden, moet ze er voor zorgen dat zo veel mogelijk mensen die opdracht geven aan YouTube. Hoe doet ze dat? Ze kan bijvoorbeeld e-mails rondsturen, met daarin een link: Dit is een superleuk filmpje. Echter, de link leidt niet naar een video, maar naar een opdracht aan YouTube. Kijk maar naar de bijbehorende HTML.

   <a href=”https://youtube.com/like-video?id=72378923”>Dit is een superleuk filmpje!</a>​

2. Alice (een bezoeker van Youtube) klikt op de link. Ze denkt een filmpje te gaan bekijken, maar eigenlijk wordt er een opdracht gestuurd naar YouTube om aan te geven dat ze het filmpje leuk vindt.

Is Youtube tegenwoordig beveiligd tegen CSRF? Zoals het hierboven uitgelegd is wel. Bekijk onderstaande afbeelding waarin je de html kunt bekijken van de like. Merk op dat er geen href is ingevuld.

2. CSRF via een website

Eve had de link ook op andere manier kunnen verspreiden. Bijvoorbeeld door het volgende stukje HTML op een website te plaatsen. Je ziet, er wordt gebruik gemaakt van de IMG-tag. Alice zal echter nooit een plaatje zien, want de hoogte en breedte zijn beide 0. Dit heet ook wel een 0x0 afbeelding.

<img src=”https://youtube.com/like-video?id=72378923” width=0 height=0 />

Als Alice de website bekijkt, zal haar browser het plaatje proberen te downloaden. De browser stuurt dan, zonder dat Alice het door heeft, een opdracht naar YouTube om de video van Eve leuk te vinden.

3. Bescherming tegen CSRF

Eigenlijk is elke interactieve website in theorie kwetsbaar voor Cross-Site Request Forgery. Denk aan een webwinkel, internetbankieren, social media, etc. CSRF werkt alleen als de gebruiker al is ingelogd op die site. Op veel sites ben je echter automatisch ingelogd door het gebruik van cookies (denk aan Instagram, YouTube, Twitter, etc).

Gelukkig zijn er voldoende manier voor websites om zich hier tegen te beschermen. Bij een bank kun je nooit zomaar een bedrag overmaken zonder dat je dit moet bevestigen met een wachtwoord of zelfs met twee-factor-authenticatie (zie het hoofdstuk over authenticatie). Wat dat betreft is de eerdere opdracht (Opdracht 16 CSRF voorbeeld) niet realistisch. Daarnaast, je wordt bij een bank automatisch uitgelogd als je even niets doet op de site.

Ook voor andere sites zijn er oplossingen. Een website kan bijvoorbeeld een uniek ‘token’ gebruiken. Hieronder zie je een voorbeeld.

<a href=”https://youtube.com/like-video?id=72378923&token=PFQURKS”>Ik vind dit leuk</a>

Het token is voor iedere gebruiker uniek en verandert ook steeds. Een opdracht zonder token wordt niet verwerkt door YouTube. Ook de gebruikers kunnen CSRF voorkomen, door niet zo maar op links te klikken in e-mails bijvoorbeeld en door te voorkomen schimmige sites te openen.

cookies

Cookies zijn tekstbestandjes die worden opgeslagen op jouw computer om een website de volgende keer van informatie te voorzien. Iedere cookie heeft een naam en een waarde. Met behulp van Firefox kunnen we deze cookies zien. Open Firefox (evt. downloaden) en druk op Shift-F9. Hieronder zie je dat edictum vrijwel geen cookies gebruikt.

Je ziet dat edictum alleen maar cookies gebruikt van zijn eigen website. Je kunt ook cookies binnenkrijgen van een derde partij. Dat is bijvoorbeeld het geval als er een iframe is geprogrammeerd.

Er bestaan ook zogenaamde SameSite cookies. Dit zijn cookies die alleen maar worden geaccepteerd als ze van de eigen website afkomstig zijn. In de volgende les gaan we deze daadwerkelijk maken.

4. Cookies maken

In de cursus Een interactieve applicatie in Java heb je geleerd om een servlet te maken. We hebben een servlet gemaakt die cookies kan maken. Je kunt deze hier downloaden. Pak deze uit en open het project in Netbeans en start het. De startpagina ziet er als volgt uit:

Vul iets in en laat het vakje strict open. Open nu de button de header van de cookie. Wat zie je nu? Probeer vervolgens hetzelfde met het vakje strict. Je ziet nu dat er een verschil is. Je kunt ook in de servlet ziet hoe een cookie wordt gemaakt, namelijk met behulp van een header.

if (strict != null) {
    if (strict.equals("on")) {
        samesite = "SameSite=strict";
    }
}
response.addHeader("Set-Cookie", "bewaardeCookie=" + bewaardeCookie + "; HttpOnly;" + samesite);

Deze zogenaamde SameSite instelling heeft grote gevolgen voor zogenaamde derde partij. Als deze instelling aan staat kan een link die "van buitenaf" komt de cookie niet lezen.

5. Twitter dicht beveiligingslek

Nieuwsbericht over twitter

TweetDeck, de officiële client van Twitter, werd woensdag geteisterd door een XSS-bug die voor veel ergernis zorgde bij gebruikers. En voor hilariteit bij anderen.
XSS staat voor cross-site scripting. Een Oostenrijkse tiener ontdekte per toeval dat tweets in TweetDeck als normale html worden verwerkt. Daardoor is het mogelijk om JavaScript-code aan een tweet toe te voegen, die dan vervolgens ook wordt uitgevoerd. De 19-jarige Oostenrijker rapporteerde de softwarebug onmiddellijk aan Twitter, dat snel heeft gereageerd om het probleem op te lossen.

Maar omdat de bug ondertussen publiek bekend was gemaakt, werd er vrolijk misbruik van gemaakt door de hacker community. Die gebruikten de bug om flauwe grappen te verspreiden naar andere gebruikers. Zo stuurde de Duitse twitteraar @derGeruhn een script de wereld in dat automatisch werd geretweet door elke TweetDeck-gebruiker die de tweet zag voorbijkomen. Die tweet klokte uiteindelijk af op bijna 82.000 retweets. Anderen maakte gebruik van de bug om een pop-up in TweetDeck te laten verschijnen met een referentie naar de bekende RickRoll-meme of een schuine mop.

Bron: https://techpulse.be/nieuws/156151/tweetdeck-xss-bug-gaat-viraal/

Je hebt nu al twee soorten kwetsbaarheden leren kennen: de buffer overflow en cross site request forgery. Weer een andere manier is een kwetsbaarheid via Cross-Site Scripting, afgekort tot XSS. In het bovenstaande nieuwsbericht zie je daar een voorbeeld van. XSS kan net als CSRF worden gebruikt om een webapplicatie aan te vallen.

6. Cross-Site Scripting (XSS)

Een aanval via Cross-Site Scripting bestaat uit de volgende stappen.

1. Eve (de hacker) opent de kwetsbare website waar je als gebruiker berichten achter kunt laten. Denk bijvoorbeeld aan een webwinkel waar je reviews achter kunt laten. Eve misbruikt deze mogelijkheid en plaatst een stukje JavaScript, een simpel programmaatje, in de review.
2. De webserver slaat het JavaScipt-programmaatje op, alsof het een review is.\
3. Alice, een niets-vermoedende gebruiker opent de website, inclusief alle reviews. Eén van deze reviews bevat de JavaScript van Eve.
4. De browser van Alice voert het JavaScript automatisch uit. Dat programmaatje zorgt ervoor dat de cookies van Alice van deze website naar Eve worden gestuurd.

7. Bescherming tegen XSS

De ontwikkelaars van een website kunnen een aanval via XSS vermijden door de invoer van gebruikers goed te filteren en geen JavaScript toe te staan.
Een gebruiker kan de uitvoer van JavaScript standaard uitzetten de browser. Dit leidt er echter wel toe dat veel sites niet goed functioneren. De gebruiker kan per site bepalen of JavaScript wordt ingeschakeld.

Maak in deze een aantal opdrachten over XSS en Cross-Site Scripting.

8. Verdienen aan kwetsbaarheden

Kwetsbaarheden zijn het goud in de digitale wereld. Je kunt het verhandelen op de criminele markt maar dat is natuurlijk illegaal. Je kunt er ook geld aan verdienen op een legale manier. In deze podcast hoor je Michiel Prins uit Groningen, die een goedlopend bedrijf in Amerika heeft opgezet.

Een zero-day is een kwetsbaarheid die nog niet bekend is bij de ontwikkelaars van de software en waar dus nog geen update voor is. Deze zero-days kunnen veel geld waard zijn, in het criminele circuit, maar ook via grote softwarebedrijven. Zij hebben hiervoor vaak een bountyprogramma. Dat is een specifiek programma waarbij gebruikers kwetsbaarheden kunnen aangeven.

Instagram-gebruikers die hun wachtwoord zijn vergeten kunnen hun mobiele telefoonnummer invoeren. Vervolgens wordt er een zescijferige code naar de telefoon gestuurd. De gebruiker moet deze code bij Instagram invoeren en kan daarna een nieuw wachtwoord instellen. Dat houdt in dat er maximaal 1 miljoen mogelijkheden zijn. Muthiyah ontdekte dat de bescherming van Instagram tegen bruteforce-aanvallen onvoldoende is, waardoor een aanvaller alle mogelijke combinaties kon proberen.

Een aanvaller die over voldoende ip-adressen beschikte kon zo de resetcode achterhalen en invoeren, om vervolgens een wachtwoord voor het account van zijn slachtoffer op te geven. Het was mogelijk om vanaf één ip-adres 200 verzoeken te versturen. Een aanvaller met 5000 ip-adressen zou zo elk account kunnen kapen. Via clouddiensten van Amazon of Google zou een dergelijke aanval voor een bedrag van 150 dollar mogelijk zijn, aldus Muthiyah. Hij waarschuwde Facebook dat het probleem verhielp en een beloning van 30.000 dollar uitkeerde.

Bron: https://www.security.nl/posting/617222/Onderzoeker+kon+elk+Instagram-account+door+lek+overnemen

Met behulp van fuzzing kun je proberen een kwetsbaarheid te ontdekken. Fuzzing houdt in dat er allerlei gegevens in een applicatie worden ingevoerd die (een beetje) afwijkend zijn van normale invoer. Als de software daar niet goed op is voorbereid is het wellicht mogelijk om een kwetsbaarheid te vinden.

Er zijn allerlei bedrijven die beloningen geven als je een kwetsbaarheid in hun softwware vindt, waaronder Facebook (waar ook Instagram en WhatsApp onder vallen), Microsoft en Apple. Bounty hunters zijn mensen die er hun werk van maken om dit soort kwetsbaarheden op te sporen.

Deze website geeft een overzicht van de top 30 bounty programma’s. Je kunt zien welke bedragen softwarebedrijven beschikbaar stellen voor het vinden van kwetsbaarheden. Apple biedt zelfs 1 miljoen dollar voor het vinden van bepaalde kwetsbaarheden, zie: 

9. Fuzzing

Bij vrijwel elk systeem kun je gegevens invoeren. Je voert je login-gegevens in, er is een zoekvenster, enzovoort. Meestal werkt het systeem prima bij normale invoer. Maar wat als je nou eens afwijkende invoer geeft. Bijvoorbeeld heel lange teksten, of allerlei leestekens zoals ~, `, “, <, >, etc. Het zou zo maar kunnen dat het systeem daar niet goed mee omgaat. Misschien crasht het systeem wel bij zo’n invoer, en dan is het heel makkelijk om een Denial-Of-Service (DOS) aanval op te zetten. Of wellicht is het mogelijk om malware te installeren (zie de uitleg van HackSplaining over Buffer Overflows

Een manier om dat te doen is via fuzzing: het testen van een programma op allerlei willekeurige data. Daarbij kun je een fuzzer gebruiker, dat is software die dat soort willekeurige data genereert.

Fuzzing kan worden toegepast op alle invoer die een programma verwerkt, bijvoorbeeld:

• Invoer van de gebruiker
• Berichten op basis van netwerkprotocollen (denk bijvoorbeeld aan een browser die via het HTTP protocol communiceert met de server)
• Bestanden die worden verwerkt (denk bijvoorbeeld aan SnapChat waar afbeeldingen worden verwerkt)

Eerder in deze module heb je kunnen lezen over Heartbleed: een gevaarlijke kwetsbaarheid in webservers. Als deze software was getest met een fuzzer, dan was de kwetsbaarheid waarschijnlijk al gelijk ontdekt.

Het idee van fuzzing is om heel veel verschillende invoeren uit te proberen. Dat doe je niet handmatig, dat kost veel te veel tijd. Er zijn softwareprogramma’s waarmee je dit kunt doen. Je kunt hiermee willekeurige invoer laten genereren, maar dat is meestal niet effectief. Beter kun je een template maken op basis van de verwachte invoer en de fuzzing-software daar op laten varieren.

Bijvoorbeeld, stel je hebt een programma dat als invoer een geboortedatum verwacht. Deze datum moet in het volgende format zijn: dd-mm-jjjj. Daarbij geldt dat:

• dd : een getal tussen 1 en 31
• mm: een getal tussen 1 en 12
• jjjj: een getal tussen 1900 en 2020.

De fuzzer kan hier allerlei varianten van produceren, bijvoorbeeld:

• 00-01-2020
• -01-2020
• 32-01-2020
• 01-01-0000
• 01-01-20200
• 1-01-2020
• m1-01-2020
• enzovoorts