Software Security

XML External Entities (XXE)

XML External Entities (XXE).jpg

Wat is het en waar komt het voor?

Een jaar of tien geleden is XML de standaard geworden en sindsdien is het gebruik ervan sterk toegenomen. Daarmee is XML tegelijkertijd ook voor kwaadwilligen steeds interessanter geworden. Een van de kwetsbaarheden die XML met zich meebrengt, die deze aanvallers gebruiken, zijn XML External Entities, afgekort XXE.

Zoals voor de meeste bekend is, is het mogelijk om in XML via de syntax <!ENTITY entity-name SYSTEM “URI/URL”> een eigen entiteit te definiëren. Dit kan in het document zelf gedaan worden - een internal entity - of door een extern document via een URI/URL te importeren, waarin deze definitie staat - een external entity. Het laatste geval is waar de kwetsbaarheid XXE gebruik van maakt. Het kan zich dan ook voordoen op elke plek waar dit toegestaan is.

Een typische XXE-aanval geeft op de plaats van de URI/URL een XML bestand mee waarin kwaadwillige code staat, of juist een verwijzing naar iets volledig anders. Denk aan iets als “file:///etc/passwd” om toegang tot privégegevens te kunnen krijgen. Of een URL in de vorm van “https://”192.168.1.1/private”, waarmee via dit IP-adres van de router het bedrijfsnetwerk verkend kan worden.

Wat kunnen de gevolgen zijn?

Zoals zojuist vernoemd, heeft een aanvaller vele mogelijkheden om gebruik te maken van deze kwetsbaarheid in XML. Het zal dan ook erg afhangen van het doel van de aanvaller wat de gevolgen zullen zijn. Enkele mogelijke gevolgen van een XXE exploitatie zijn:

  • Extractie van (gevoelige) gegevens.

  • Blootstelling van de interne structuur van je bedrijf.

  • Een DoS, zoals de Billion Laughs aanval.

  • Legio andere aanvallen, doordat er remote requests gedaan kunnen worden.

Hoe beveilig je je er tegen?

Deze kwetsbaarheid doet zich in tegenstelling tot sommige andere voor op één specifieke plek. Hierdoor is XXE in theorie heel makkelijk te verhelpen, namelijk door simpelweg XML in zijn geheel te vermijden. Gebruik als alternatief een simpeler data format, zoals JSON.

Echter, als XML alom gebruikt wordt in jouw applicatie of web service, dan is bovenstaande oplossing niet of lastig toe te passen. In dat geval kun je als bedrijf logische stappen nemen zoals XML-validatie - zodat niet zomaar ongecontroleerd alle XML geparsed wordt - en het verminderen of zelfs vermijden van serialisatie. Implementeer hiervoor bijvoorbeeld Apache Xerces in je pipeline om dit na een relatief simpele set-up geautomatiseerd te laten doen. Daarnaast kun je een dependency checker zoals Dependency-check-maven implementeren, die kwaadaardige XML files detecteert, zelfs als ze zeer diep nested zijn.

 

Vooruitblik

Het volgende artikel zal over een vrij algemeen fenomeen gaan: Broken Acces Control. Voor de echte hacker is dit een absolute basisvaardigheid. Voor ieder serieus bedrijf zou hiervoor dan ook een absolute basisbeveiliging moeten zijn. In de praktijk blijkt dit echter vaker niet dan wel het geval te zijn. Soms door laksheid, maar vaak door onwetendheid. Want hoe zorg je er als bedrijf nu eigenlijk voor dat niet heel je database direct volledig bloot gesteld wordt doordat de secretaresse een foutje gemaakt heeft? Lees het in het vijfde artikel van mijn cybersecurity reeks.

Broken Authentication

Door Lucas Dresscher

Wat is het en waar komt het voor?

In dit tweede artikel van mijn serie over de “OWASP Top 10 Application Security Risks – 2017” lijst behandel ik de kwetsbaarheid Broken Authentication. Misschien herkent niet iedereen direct deze officiële term, maar wel zeer herkenbaar is de zoveelste krantenkop waarin staat “Miljoenen accounts gehackt door datalek”. Broken authentication heeft hier veelal mee te maken.

Broken authentication kan de oorzaak zijn van zo'n krantenkop, maar vaker is het een gevolg. Vrijwel alle applicaties volgen namelijk voor inlog processen en dergelijke het volgende drie stappen principe:

1. Identification: “Wie ben je?” - dit is vaak de gebruikersnaam.
2. Authentication: “Ben je wie je zegt dat je bent? - dit is vaak het wachtwoord.
3. Authorization - “Wat mag je?” - dit zijn de rechten die deze gebruiker heeft.

Zoals de naam Broken Authentication doet vermoeden, doet het zich voor in de tweede stap. Een aanvaller gebruikt verkregen credentials om zich voor te doen als een bepaalde gebruiker om op deze manier diens rechten te krijgen. De aanvaller kan aan deze gegevens gekomen zijn door bijvoorbeeld eerdere datalekken, maar ook door zelf een Brute Force Attack (BFA)/Dictionary Attack of een ietwat geavanceerdere Rainbow Table Attack uit te voeren.

Wat kunnen de gevolgen zijn?

Bij een applicatie die kwetsbaar is voor Broken Authentication is het risico op identity theft zeer groot. Tevens kan er andere (bedrijfs)gevoelige gegevens geopenbaard worden. Dit zou niet moeten gebeuren, aangezien de meeste accounts die gehackt worden van gewone gebruikers zijn. Deze groep hoort in theorie zo weinig mogelijke rechten te hebben. Echter, de praktijk leert dat - veelal uit gemakzucht - dergelijke groepen veel meer rechten hebben dan nodig is. Hierdoor kan zelfs een matige hacker met het kraken van een simpel account al ver komen, laat staan een gevorderde hacker. Onder het volgende kopje “Hoe beveilig je je er tegen?” behandel ik dit probleem verder.

Hoe beveilig je je er tegen?

Om te voorkomen dat je direct in gevaar bent als de secretaresse op een phishing mail geklikt heeft, is het van belang dat je als bedrijf goed nagedacht hebt over Identity and Access management (IAM). Dit is gebaseerd op de volgende drie principes: (1) need to know basis, (2) least privilege en (3) segregation of duties. Ofwel, ga voor elke gebruikersrol precies na welke rechten nodig zijn en stel het systeem vervolgens zo in – en niet meer. Zorg er daarnaast voor dat gebruikerstaken gescheiden zijn; iemand die een aanpassing kan voorstellen, moet deze niet zelf kunnen goedkeuren.

Hieronder geef ik een korte lijst met do’s en don’ts om Broken Authentication tegen te gaan.

DO'S

  • Multi-factor authentication: hiermee laat je de gebruiker met twee of meerdere verschillende manieren authenticeren, in plaats met alleen een wachtwoord. Een veelgebruikte implementatie is een combinatie van een wachtwoord en een code verkregen via SMS of via een authenticator app zoals Google Authenticator.

  • Bouw een weak-password check in, die controleert of een gebruiker geen wachtwoord uit de lijst met met 1000 of 10000 slechtste wachtwoorden (uit gemak) wilt instellen.

  • Beperk het aantal inlogpogingen die iemand kan doen en log alle mislukte inlogpogingen.


DON'TS

  • Gebruik geen default credentials. Oftewel, stel geen standaard gebruikersnamen, wachtwoorden of andere accountgegevens in. Denk aan standaardgebruikersnamen admin of gebruiker1 en standaardwachtwoorden als password of wachtwoord.

  • Leg de gebruiker buiten de weak-password checker en een standaard minimumlengte van in ieder geval 8 tekens niet teveel restricties op tijdens het instellen van hun gebruikersgegevens. In tegenstelling tot wat sommige bedrijven nog steeds denken, is onderzocht dat verplichtingen als speciale tekens en hoofdletters of het verplicht periodiek aanpassen van je wachtwoord juist averechts werkt.


Vooruitblik

In het volgende artikel zal ik een kwetsbaarheid behandelen die velen verwarren met degene die ik hier heb besproken: Sensitive Data Exposure. Sensitive Data Exposure heeft zeker overeenkomsten met Broken Authentication, maar is op meerdere vlakken toch fundamenteel anders. Waarin zit dit verschil? Kun je je als bedrijf met enkele hier besproken preventiemaatregelen ook direct tegen deze kwetsbaarheid beveiligen? En welke rol speelt encryptie hierin? Lees het in het derde artikel van mijn Cybersecurity reeks.


 


 


 

 

Kwetsbaarheid Nummer 1: Command Injection

Door: Lucas Dresscher

Wat is het en waar komt het voor?

In dit artikel behandel ik de nummer 1 op de “OWASP Top 10 Application Security Risks – 2017” lijst: injection. Injection houdt in dat een aanvaller, via een vorm van input in een applicatie, code kan doorsturen naar een interpreter. Het doel van de aanvaller is om hiermee onrechtmatig gegevens te verkrijgen en te gebruiken/misbruiken. Rechtsonder staat een praktijkvoorbeeld van injection:

OS_Command_injection.png

Ondanks dat bijna iedereen die in de IT werkt bekend is met injection, is injection nog steeds de meest voorkomende kwetsbaarheid in applicaties. Dit is opmerkelijk, maar ook heel logisch. Het grootste probleem aan deze kwetsbaarheid is dat er vrijwel overal in een applicatie injection flaws kunnen zitten. Op elke plek waar sprake is van user input data – URL’s, XML of JSON inputs, cookies etc. - kan een aanvaller (trachten te) gebruiken voor injection. Hierdoor zijn er vele varianten, zoals de welbekende (No)SQL injection maar ook LDAP injection, EL injection en OS command injection. Het is daardoor niet gemakkelijk om je applicatie volledig tegen deze kwetsbaarheid te beveiligen.


Wat kunnen de gevolgen zijn?

injection.jpeg

Afhankelijk van de fail securely maatregelen die genomen zijn (zie “Hoe beveilig je je er tegen?”), kan er van alles met je data gebeuren, en op elke schaal. Typische gevolgen van een geslaagde injection-aanval zijn verlies of corruptie van data, ontzegging van toegang tot data en het doorspelen van data aan (criminele) derde partijen.

Hoe beveilig je je er tegen?

Hoewel er dus vele vormen van injection zijn, zijn de preventie- en detectiemaatregelen tegen alle vormen vergelijkbaar. Hieronder volgt een overzicht van de mogelijke maatregelen die je kunt nemen.

Preventiemaatregelen

  1. De beste manier om injection te voorkomen is input validation. Controleer en valideer alle vormen van user input in je code alvorens je deze gebruikt voor een aanroep naar je interpreter.

  2. Gebruik een veilige API voor je applicatie, die het gebruik van een interpreter volledig omzeilt.

  3. Fail securely, oftewel beperk de schade als er iets fout gaat. Beperk bijvoorbeeld de hoeveelheid informatie die weergegeven wordt als resultaat van een query door TOP (SQL), LIMIT (MySQL) of ROWNUM (Oracle) aan de query toe te voegen.

Detectiemaatregelen

  1. Voer een handmatige source code review uit. Ga na waar in je applicatie user input wordt gegeven en controleer op deze plekken de input validation.

  2. Voer op elke plek waar injection mogelijk is een geautomatiseerde test uit. Gebruik hiervoor bijvoorbeeld het MetaSploit Framework in combinatie met Kali Linux.

Vooruitblik

In het volgende artikel zal ik de op één na meest voorkomende kwetsbaarheid in applicaties behandelen: Broken Authentication. Dit is een kwetsbaarheid die al vele jaren hoog in de lijst staat.

"BROKEN AUTHENTICATION ZAL IN HET VOLGENDE ARTIKEL WORDEN BEHANDELD"

Door de alsmaar groeiende beschikbare rekenkracht die aanvallers hebben voor bijvoorbeeld Brute Force Attacks zal dat ook nog wel lang zo blijven. Gelukkig kun je je applicatie met een aantal maatregelen hiertegen beveiligen. Hoe? Lees het in het volgende artikel van mijn Cybersecurity reeks.

Eerder verschenen:
Introductie Lucas - Cybersecurity

 

Introductie Lucas - Cybersecurity

Foto.png

Mijn naam is Lucas Dresscher, ik ben 22 jaar oud en ik studeer informatica aan de Universiteit Utrecht.

Daarnaast werk ik 2 dagen per week als Cybersecurity expert in het Young Professional programma, voor Softwarebedrijven in Nederland.

Cybersecurity is een zeer omvangrijk vakgebied; het is letterlijk overal in de IT-wereld. Daarbij is Cybersecurity ook nog eens enorm relevant en actueel. Dit maakt het fenomeen voor velen al snel ontastbaar en afschrikwekkend. Dat wordt versterkt wordt door de enorme hoeveelheid vaktermen en de honderden beschikbare Cybersecurity tools.

Het is dan ook mijn persoonlijke doel om deze ongrijpbaarheid van cybersecurity weg te nemen en het PEN-testen praktisch in te richten. Ik wil de onnavolgbare Wizzkid wegen vervangen door duidelijkheid.

Een kleine hoeveelheid van mijn kennis over cybersecurity deel ik op dit blog, door een reeks van de meest voorkomende kwetsbaarheden in software. Hiervoor hanteer ik de erkende “OWASP Top 10 Application Security Risks - 2017” van het Open Web Application Security Project, zijnde: 

  1. Injection

  2. Broken Authentication

  3. Sensitive Data Expose

  4. XML External Entities

  5. Broken Access Control

  6. Security Misconfiguration

  7. Cross-Site Scripting

  8. Insecure Deserialization

  9. Using Components with Known Vulnerabilities

  10. Insufficient Logging & Monitoring

Bij elk van deze kwetsbaarheid geef ik een uitleg over de kwetsbaarheid, waar het zich in applicaties voordoet en bovenal, wat je er tegen kunt doen.

In het eerstvolgende blog begin ik meteen met de nummer 1 van de lijst: Injection. De meesten zullen deze beruchte kwetsbaarheid herkennen in de vorm van SQL injection, maar er bestaan nog vele andere varianten. Welke zijn dit allemaal? Wat kunnen de gevolgen ervan zijn? En wat doe je er nu precies tegen? Lees het binnenkort in mijn cybersecurity reeks.

Cybersecurityavond Hogeschool Utrecht

Op 23 mei hebben Ewan Klomp, Lars Tijsmans en Jan Vlietland van het Young Professional programma een Cybersecurity avond met Hogeschool Utrecht gehouden.

IMG-20180529-WA0010.jpg

Het onderwerp van de avond was:

"Cybersecurity en de softwareontwikkelaar".

 

De stelling was: 

"elke ontwikkelaar moet verstand hebben van Cybersecurity". 

Het was een avondvullend programma waarin presentatie, discussie en experimenten speels werden afgewisseld. Een leerzame avond vol ontmoetingen tussen professionals en young professionals, met als doel om met elkaar antwoorden te vinden.

IMG-20180529-WA0003.jpg

De eindconclusie was dat:

"bijna elke ontwikkelaar moet verstand hebben van Cybersecurity".

We danken Hogeschool Utrecht voor de interesse en gastvrijheid. Tot een volgende keer!

Een Hackathon zoals het is bedoeld

Vorige weekend hebben we met een groep medewerkers een supertoffe Hackathon georganiseerd, bestaande uit een serie challenges.

Tijdens de voorpret waren er al bijzondere challenges bedacht. Ze varieerden van het maken van een website binnen een half uur, tot het PEN-testen van een wireless accessible REST-API. Maar ook het hacken van een wireless netwerk met een *CRACK* attack in Kali was een challenge.

 
hackathon_2.jpg
 

We organiseren de hackathons op verschillende locaties en evalueren samen wat de prettigste werkomgeving is. We kiezen werkomgevingen die creativiteit en werkplezier het best ondersteunt. Een ruimtelijke huiselijke omgeving blijkt hier tot nu toe het best te passen.

De volgende dag, aan het einde van de hackathon bleken er alleen winnaars te zijn.