Hoe ga je om met kwetsbaarheden met een laag risiconiveau? Kleine problemen, grote problemen…
Disclaimer: Dit verhaal is fictie, elke gelijkenis met echte mensen en netwerken, levend of dood, is puur toeval…. of niet.
Wacht ! Hebben jullie een IT-manager die Jean heet? 😉
De tijdlijn van het verhaal
November 2016
Je bedrijf groeit, je bent geen start-up meer en je hebt nieuwe behoeften en eisen. Samen met Jean, je IT-manager, heb je besloten om een nieuwe server in de cloud te installeren om de bedrijfscommunicatie met je consultants te verbeteren.
Het project is heel eenvoudig: Maak niet-gevoelige gegevens die al op uw intranet staan, beschikbaar voor uw consultants.
Jean is nogal bezorgd over de beveiliging. Hij weet dat de intranettoepassing lang geleden is ontwikkeld en hij weigert de server bloot te stellen aan het grote boze internet.
Acties:
- Dus besluit hij om de intranetserver in een DMZ te plaatsen en de toegang tot deze DMZ te beperken tot een enkele server waarop een CMS is geïnstalleerd (dat bekend staat als veilig).
- Om er zeker van te zijn dat deze nieuwe “openheid” je bedrijf niet in gevaar brengt, plant Jean een black box pentest door een bekend beveiligingsbedrijf (Approach?).
Resultaten: Het resultaat van de penetratietest is echt goed en meldt slechts één kwetsbaarheid (Nee, het is geen Approach! De keuze is aan jou…):
Omdat het risiconiveau “Laag” is, hecht je niet veel waarde aan het rapport en gaat je IT-manager door met zijn dagelijkse activiteiten …
15 december 2018 – nieuwe behoefte …
Het is bijna het einde van het jaar en je wilt een bedrijfsdag organiseren om je consultants samen te brengen.
Je hebt een soort doodle nodig op het CMS om de beschikbaarheid van je team voor het evenement te oogsten, maar de IT-manager is overboekt en delegeert de ontwikkelingstaak aan zijn stagiair.
20 december 2018 – impact ….
U krijgt een telefoontje van de gegevensbeschermingsautoriteit: de complete dump van uw intranet database is gevonden op het darknet. Inclusief gevoelige informatie over klanten en contracten.
Wat is er gebeurd?
Je stagiair heeft een kleine fout gemaakt bij het coderen van de database query in de plugin en een SQL injectie kwetsbaarheid geïntroduceerd.
Een hacker kon het gebruiken met de SQL-query ” SELECT INTO OUTFILE “. Zo kon hij PHP-code uitvoeren en systeemcommando’s uitvoeren.
- Om dit te doen, injecteerde hij/zij een vergelijkbare SQL-code:
- Vervolgens kon hij/zij systeemcommando’s uitvoeren vanuit zijn browser:
Je denkt waarschijnlijk dat het de schuld van de student is. Hij heeft immers de SQL-injectie geïntroduceerd!
In feite is het een beetje ingewikkelder: om de SQL-injectie te laten escaleren in een injectie van code op afstand, moest de aanvaller het volledige pad naar de webdirectory kennen… en jij gaf hem die informatie!
Herinnert u zich deze “lage” kwestie in het rapport?
Het enige wat de hacker hoefde te doen, toen de webserver eenmaal in bezit was, was je oude en zeer kwetsbare intranetserver aanvallen en de database dumpen.
En het verhaal eindigt, althans dat is wat je graag denkt:
Twee jaar geleden was je nog een kleine start-up, de tijd verstrijkt en je hebt nooit de tijd genomen om een goed monitoringsysteem op te zetten.
Je zult dus waarschijnlijk nooit weten wat er met je interne netwerk is gebeurd, maar …
De moraal van het verhaal is:
Niets mag achterblijven als het gaat om beveiliging. Deze aanval had op veel manieren beperkt kunnen worden, van het harden van servers tot het installeren en onderhouden van web application firewalls.
Approach biedt alle services die u nodig hebt om uw infrastructuur te beveiligen:
