Onze studenten ICT hebben intussen hun pentest ingediend, en de evaluatie is achter de rug. De opdrachtgevers kregen een poos terug een verslag met de resultaten, tijd voor een korte terugblik dus…
Hoewel we geen specifieke richtlijnen gaven, behoren een groot gedeelte van de sites toe aan KMO’s en vzw’s. Dat uit zich in een relatief groot aantal sites die gebouwd zijn op het Wordpress platform.
Vaststelling 1: een gewaarschuwd sysadmin..
.. is vaak plots een erg wakkere sysadmin.
Bij sommige sites viel op dat alles zo keurig gepatcht was, dat er minstens een vermoeden is dat dit gebeurde naar aanleiding van de aangekondigde pentest en niet vanuit een doordachte strategie of automatische workflow.
Daarmee is helemaal niks mis: de wereld wordt er enkel veiliger door. Uiteraard is dat wel een ‘recipe for disaster’ als het enkel nav een eenmalige & aangekondigde pentest gebeurt.
Vaststelling 2: een goed jaar voor de CMS’en
Toen we de pentest enkele jaren geleden een eerste keer lieten uitvoeren waren er quasi altijd kwetsbaarheden te vinden in CMS-installaties. Dat is dit jaar merkelijk beter.
Onze steekrproef is veel te klein om van een trend te spreken, maar het lijkt er toch minstens op dat aandacht voor security bij de verschillende cms’en een stuk groter geworden is, en het aantal vulnerabilities daardoor een pak lager is.
Cijfers (bron: www.cvedetails.com) lijken dat te bevestigen voor bijvoorbeeld Wordpress:
Vaststelling 3: een site zelf hosten is meestal geen goed idee
Servers die binnen (niet gespecialiseerde) bedrijven zelf gehost werden, bleken vaker een dankbaar doelwit. Verouderde serverversies, onnodig geopende poorten, ..
Bezint eer ge begint aan eigen servers dus…
Vaststelling 4: de Owasp top 10 blijft een goeie gids
Er kan niet genoeg benadrukt worden dat de studenten geen voorafgaande pentest-ervaring hadden. Na een korte introductie werden ze op pad gestuurd. Ongetwijfeld waren er dus ook problemen die aan hun aandacht ontsnapten, maar het laagsthangend fruit is vermoedelijk wel geplukt. De studenten kregen voor hun zoektocht als leidraad de OWASP top tien mee, en die houvast werkt goed om gestructureerd naar kwetsbaarheden te zoeken.
In onderstaande tabel vind je een schatting van het aantal gevonden kwetsbaarheden per categorie. Een schatting, omdat sommige problemen soms in de schemerzone tussen twee categorieën zitten, of omdat we zelf geen validatie konden of mochten doen van het resultaat. Soms was er ook sprake van een cascade van problemen, waarbij telkens slechts één ‘hoofd’-probleem aangestipt werd.
| Vulnerability | kwetsbaar |
|---|---|
| Injection | 5% |
| broken authentication | >8% |
| sensitive data exposure | 5% |
| XXE | 0 |
| Broken access control | >8% |
| security misconfig | >7% |
| XSS | >7% |
| insecure deserialization | 0 |
| using components with known vulnerabitites | >10% |
| insufficient logging | nvt |
SQL injectie komt gelukkig minder en minder voor in onze resultaten. Vaak gebruikte frameworks beschermen de ontwikkelaar dan ook al in grote mate tegen deze flaters.
File uploads blijven net als vorige jaren wel een gevoelig punt. De validatie van de input is daar vaak niet voldoende om onze gemotiveerde pentesters tegen te houden.
Op het vlak van authenticatie blijven wachtwoorden problematisch. Al te vaak werden wachtwoorden gevonden in wachtwoorddumps in de diepste krochten van het web, waren ze veel te eenvoudig te raden op basis van publieke informatie (genre N@@m123) of waren ze in een ‘gespecialiseerd’ woordenboek te vinden.
Meer en meer sites ontmoedigen brute force aanvallen door bewust delays in te bouwen, of door blokkades op te werpen bij meerdere foutieve logins. De [Wordfence] plugin is wat dat betreft aan een stevige opmars bezig, en dat kunnen we alleen maar toejuichen…
Brute force ontmoedigen moet dus sowieso op de todo-lijst van elke webbouwer: we leerden nog maar eens de les dat je gebruikers gewoon niet mag vertrouwen in hun wachtwoordkeuze…
Nonchalance blijft ook een oud zeer. Code in debug-modus, veel te gedetailleerde foutmeldingen, zichtbare installatiebestanden, … ze blijven opduiken.
Het is moeilijk dat in een concrete tip te gieten, maar debugging aanzetten op een productieserver is uiteraard not done…
Het leidde tot minder explosieve resultaten dan vorige jaren, maar opnieuw werden toch fel verouderde componenten aangetroffen. Zeker op zelf gehoste sites blijft dat een klassieker.. Het percentage sites waarbij dat opgemerkt werd, is behoorlijk hoog, maar dat cijfer heeft voor deze categorie weinig waarde, omdat het (gelukkig) meestal over vulnerabilities gaat met erg lage cvss scores.. Daarnaast was deze categorie ook moeilijk te verifiëren: het achterhaalde versienummer kan natuurlijk ook fout zijn, of er kan een lokale patch toegepast zijn ipv een versie-upgrade om een probleem op te lossen…
Het aantal sites dat enkel nog via het inherent onveilige http bereikbaar is, is gelukkig met uitsterven bedreigd.
Wel zijn veel https-sites nog niet met hsts beveiligd (hoewel dat geen rocket science is), wat hackers de mogelijkheid geeft om man in the middle aanvallen uit te voeren.
Het XSS-spook blijft ook rondwaren in de testen, en net zoals bij hsts kunnen ook hier enkele http headers al wat hulp bieden. Eén specifieke vondst verdient daarbij een extra vermelding. Eén student vond namelijk een XSS-kwetsbaarheid in een stuk code dat op tientallen e-commerce sites gebruikt wordt, en dat kon gebruikt worden om sessies te stelen…
…En zo zetten we met deze oefening alweer een flinke stap naar een ideale wereld.. ;-)