Het jaar onder de oppervlakte

Door Lex Borger 18 feb 2022

We hebben een kwetsbaar jaar achter de rug. Nog niet eerder werden er zoveel zero-days ontdekt met zoveel impact als in 2021. De log4shell kwetsbaarheid in log4j zal nog jaren na-echoën, het maakt bijna dat we vergeten dat er eerder dit jaar nog andere kwetsbaarheden zijn langsgekomen. Microsoft had een drietal episodes. Allereerst de Microsoft Exchange servers in januari, waarbij vier zerodays gezamenlijk een totale overname van een exchangeserver mogelijk maakten. Een klassieke killchain: authentication bypass, privilege escalation tot admin, en twee methodes voor remote code execution. Pas in maart kwamen er patches beschikbaar en waren er al een kwart miljoen exchangeservers gecompromitteerd.

De volgende, een maand later, was PrintNightmare. Het aloude print-spooling systeem in Windows bleek ook kwetsbaar voor remote code execution en privilege escalation. De patches blokkeerden ook (kwetsbare) standaardfunctionaliteit, wat tot extra verwarring leidde. Dit werd meteen gevolgd door HiveNightmare/SeriousSAM. Dit was een configuratiefout in de Windows standaardinstallatie, waardoor de SAM (Security Account Manager) database door gewone gebruikers gelezen kon worden. Dell had ook een vergelijkbare access control kwetsbaarheid in november in hun dbutil driver, die standaard meegeleverd wordt. Het frappante is dat flink wat van deze kwetsbaarheden geen codeerfouten waren, maar eigenlijk voortvloeiden uit bedoelde functionaliteit, die door de algemene internetconnectiviteit uiteindelijk massaal te misbruiken zijn. De functionaliteiten in je software bepalen dus ook de grootte van je aanvalsoppervlakte (attack surface).

Wat gaat het komend jaar dan brengen? Eerst een schot voor open doel: ransomware-aanvallen blijven komen, en ze zullen zich aanpassen door nieuwe tactieken te gebruiken. De COVID-19 pandemie heeft de verschillen in de wereldpolitiek zichtbaarder gemaakt en spanningen gebracht of uitvergroot. Verwacht dus dat nation-state aanvallers meer noodzaak hebben zich te nestelen in de infrastructuur van anderen om te spioneren en potentieel te verstoren. De aanvalsoppervlakte van organisaties is tijdens de COVID-19 pandemie veranderd. Het werken op afstand is de norm geworden binnen organisaties. Zelfs grote bedrijven zweren er nu bij. Dit maakt dat thuiswerkomgevingen onderdeel zijn geworden van deze oppervlakte, met alle IoT-apparaten die daarbij horen. Daarnaast is er meer OT gekoppeld met IT om remote beheerd te kunnen worden, wat potentieel ook weer de oppervlakte uitbreidt. Supplychain beveiliging is al een aantal jaren een aandachtspunt, CISO’s moeten meer beveiligen middels afspraken en controles dan dat ze zelf kunnen beveiligen met maatregelen. Preventie is niet langer genoeg. Monitoren van de omgeving en het inrichten van detectie en response processen wordt essentieel. Het effectief gebruik van beschikbare threat intel is belangrijk. Het delen van deze informatie is van belang voor iedereen.

Een andere uitbreiding van de aanvalsoppervlakte is het gebruik van clouddiensten. Vooral de SaaSvorm van dienstverlening introduceert een vergroting door de uitdaging om de verschillende klanten gescheiden te houden in een multi-tenancy dienst. Ook de onderliggende cloud-API’s zelf worden direct aangevallen. De aanvalsoppervlakte is zo bepalend dat deze centraal zou mogen staan in het cybersecurityplan van je organisatie. Allereerst voor de preventie: er is de laatste jaren zoveel gewijzigd in het IT-landschap dat het nodig wordt om te evalueren of we nog werken volgens de beveiligingsprincipes die we altijd al gebruikten in het opzetten van de eigen IT. De principes zijn nog altijd geldig, maar de invulling daarvan moet wellicht heel anders ingestoken worden. De adoptie van een zero-trust architectuur, hardening op dienstniveau en toegangsbeheer blijken een effectieve aanpak te zijn tegen cyberaanvallen. En ook bij de detectie en respons moeten we rekening houden met de aanvalsoppervlakte in de breedste zin. Hiervoor is een goed zicht op de gehele oppervlakte nodig. Je moet kunnen monitoren en valideren dat alles naar behoren werkt. De log4shell kwetsbaarheid in log4j heeft pijnlijk duidelijk gemaakt hoe slecht we inzicht hebben in welke software-libraries waar gebruikt worden en hoe deze afhankelijkheden beheerd moeten worden.

Lex Borger
security consultant bij Tesorion en oud-hoofdredacteur van iB-Magazine.
Lex is bereikbaar via lex.borger@tesorion.nl

Deze column verscheen in IB1-2022