Op 14 december 2021 publiceerden Fox-IT en NCC Group een blogpost over ‘Log4Shell’ (code CVE-2021-44228. Het is nu een jaar later, een geschikt moment om terug te kijken. Wat hebben we goed gedaan en wat kunnen we de volgende keer beter doen?
Log4Shell was een schoolvoorbeeld van een ‘code rood’ scenario: het benutten ervan was makkelijk, de software werd op grote schaal gebruikt in allerlei toepassingen die toegankelijk waren vanaf het internet, patches waren nog niet beschikbaar en een succesvolle aanval zou resulteren in de mogelijkheid op afstand code uit te voeren. Tot overmaat van ramp liepen de adviezen in de eerste uren van het incident sterk uiteen, met als gevolg tegenstrijdige informatie over welke producten waren getroffen.
We kijken nu terug naar hoe we het Log4Shell-probleem in het begin hebben aangepakt. Maar ook welke lessen we hebben geleerd, voor als er weer zoiets gebeurt. Het tweede deel van deze blog gaat over de rest van het jaar, waarin we zijn benaderd door allerlei verschillende organisaties die via Log4Shell zijn aangevallen. Die gevallen hebben we onderzocht en we hebben daar de nodige conclusies uit getrokken.
Quick wins
Tijdens het Log4Shell-incident was onze primaire doelstelling onze klanten veilig te houden door gecompromitteerde systemen snel en effectief te identificeren. Toen we ons bewust werden van een proof-of-concept waarmee aanvallers Log4Shell gemakkelijk konden exploiteren, was ons eerste aandachtspunt het verkrijgen van zichtbaarheid. Maatregelen om de zichtbaarheid te vergroten, zullen bovendien vaak helpen bij de rest van de respons. Een van de eerste dingen die we deden was het toevoegen van detectie voor exploitatiepogingen. We waren vervolgens in staat om een lijst van zeer betrouwbare Indicators of Compromise (IOC’s) op te stellen en deze te gebruiken als input voor de jacht op noodsituaties.
Maar die ‘emergency threat hunting’-aanpak was niet waterdicht. Het zijn quick wins die ons de broodnodige tijd gaven om dieper in de kwetsbaarheid te duiken en te onderzoeken hoe die het beste kon worden opgespoord. We wilden echter in staat zijn om in real time mislukte exploitatiepogingen te onderscheiden van succesvolle. Onderzoek hiernaar kostte tijd, maar binnen een dag hadden we onze detectie van real-time exploitatie werkend.
Klanten informeren
Anderhalf etmaal nadat we waren begonnen met het verzamelen van IOC’s en de jacht op dreigingen, besloten we onze klanten te informeren over wat wij tot dan toe hadden gedaan. We verstrekten IOC’s en legden uit wat we hadden gedaan op het gebied van detectie. We verwezen naar adviezen en repositories van anderen als het ging om patching en mitigatie. Achteraf gezien hadden we dit eerder moeten doen. Dat had onnodig werk kunnen voorkomen en klanten hadden hun aandacht op andere zaken kunnen richten.
Samenwerking
Tegelijkertijd bracht het Nationaal Cyber Security Centrum (NCSC-NL) alle bedrijven bij elkaar die deel uitmaken van Cyberveilig Nederland, een initiatief waar Fox-IT aan deelneemt. NCSC-NL had een repository opgezet waar cybersecuritybedrijven informatie over Log4Shell konden documenteren, inclusief de identificatie van kwetsbare software. Deze repository maakte het voor ons veel gemakkelijker om ons werk te delen op een manier waarvan we wisten dat anderen het gemakkelijk konden vinden binnen de grotere context van het Log4Shell-incident. Dit laat zien hoe belangrijk samenwerking is tijdens een code red en dat organisaties bijdragen op basis van hun eigen specialiteiten, zodat overbodig werk kan worden vermeden.
Ondanks het alarmerende karakter van de Log4Shell-kwetsbaarheid en waarschuwingen dat er direct actie moest worden ondernomen, bleek Log4Shell een ‘lange staart’ te hebben. In het jaar dat volgde, zouden voor verschillende producten off-the-shelf exploits beschikbaar komen en sommige oplossingen die eerder werden uitgebracht, bleken op de lange termijn onvoldoende.
Alle incidenten hadden voorkomen kunnen worden
In het afgelopen jaar hebben we op verschillende incidenten gereageerd waarbij de Log4Shell-kwetsbaarheid deel uitmaakte van de hoofdoorzaak. We vergeleken de verschillende aanbevelingen die we in deze incident response cases gaven. Alle incidenten die hebben geleid tot inschakeling van onze incident response teams hadden voorkomen kunnen worden als:
- De kwetsbare systemen tijdig waren bijgewerkt: In alle gevallen had de leverancier van het product met de Log4Shell-kwetsbaarheid een beveiligingswaarschuwing uitgebracht. En in alle gevallen was er een beveiligingsupdate beschikbaar op het moment van de inbreuk.
- Het systeem zich had bevonden in een gesegmenteerd netwerk: Hierdoor zouden willekeurige uitgaande verbindingen zijn geblokkeerd. In de meeste situaties had het kwetsbare systeem of apparaat alleen toegang nodig tot specifieke diensten en dus geen toegang nodig tot externe bronnen.
Gebrek aan communicatie
In vervolggesprekken met organisaties die contact met ons hadden opgenomen, zagen we een patroon. Velen van hen hadden van Log4Shell gehoord, maar dachten dat ze veilig waren. De meest voorkomende reden voor hun valse gevoel van veiligheid is een zeer ongelukkige reeks misverstanden rond het patch- en levenscyclusbeheer. Zo waren er leveranciers die een eerste mitigatiescript uitbrachten, later gevolgd door updates. Dit deden ze echter zonder de klant daarvan op de hoogte te stellen. Hierdoor wisten verschillende slachtoffers niet dat ze nog steeds kwetsbare software draaiden.
We zijn ook incidenten tegengekomen waarbij beheerders de beveiligingsupgrades bleven uitstellen of de upgrade uitvoerden maar moesten terugdraaien naar een snapshot vanwege technische problemen na de upgrade. De rollback herstelde de oude situatie waarin de software nog steeds kwetsbaar was. De les hier is dat duidelijke en voortdurende communicatie van leveranciers over kwetsbaarheden en oplossingen essentieel is.
Bestemming onbereikbaar
Netwerksegmentatie had verschillende incidenten kunnen voorkomen. Exploitatie van dit type kwetsbaarheid vereist uitgaande netwerkverbindingen om een secundaire payload te downloaden. In een netwerksegment waar verbindingen sterk gereguleerd zijn, zou deze aanval dus eenvoudigweg niet werken. Het belangrijkste securityvoordeel van strikte netwerksegmentatie is dus dat het een extra verdedigingslaag biedt.
In enkele gevallen waren de eerste pogingen van kwaadwillenden niet succesvol, omdat de uitgaande verbindingen werden geblokkeerd of gehinderd door de netwerkinfrastructuur van de klant. Met latere ‘verbeteringen’ slaagden sommige aanvallers er echter in sommige mechanismen te omzeilen of ze vonden kwetsbare diensten op niet-standaardpoorten. Die gevallen bewijzen dat het een race tegen de klok was, want ook aanvallers verbeteren hun technieken.
Schoenmaker, blijf bij je leest
Terugkijkend hebben we met veel minder incidenten te maken gehad dan we eerder hadden verwacht. Betekent dit dat we te pessimistisch waren? Of betekent het we als beveiligingsindustrie zeer effectief waren? Wij geloven natuurlijk graag het laatste.
Maar er is één risico dat we allemaal nemen: het risico dat we ons publiek afstompen. We moeten daarom voorzichtig zijn met het versturen van ‘code rood’ adviezen. In dit geval hebben wij als securitygemeenschap erg veel aandacht besteed aan Log4Shell. En dat was terecht denken we. De kwetsbaarheid was gemakkelijk te misbruiken en de Log4J-component werd in veel softwareproducten gebruikt. Bovendien zagen we op grote schaal aanvalspogingen op basis van Log4Shell.
Voor een component dat zoveel gebruikt wordt, is het erg lastig voor een securityleverancier om specifiek advies te geven. Specifieke beveiligingsadviezen moeten van de softwareleveranciers komen die deze component gebruiken en die adviezen moeten natuurlijk bruikbaar zijn. Het grote publiek kan die specifieke adviezen dan het beste nauwgezet volgen.
Het herhalen van al beschikbare informatie leidt alleen maar tot verwarring. In plaats daarvan moeten we binnen onze eigen expertisegebieden bijdragen leveren. Voor de volgende ‘code rood’ weten we wat we zullen doen: onze inspanningen richten op gebieden waar we iets toe te voegen hebben en ons niet begeven op gebieden waar we dat niet kunnen.
Een uitgebreide, gedetailleerde technische weergave is hier te vinden
Edwin van Vliet en Max Groot werken voor Fox-IT
TIP: Techzine heeft een jaar geleden en daarna vanzelfsprekend ook uitgebreid verslag gedaan van Log4J/Log4Shell. Via deze overzichtspagina kun je dit allemaal nog eens bekijken. We hebben daarnaast ook snel na de uitbraak (op 17 december 2021) een aflevering van onze Techzine Talks-podcast gepubliceerd. Die aflevering kun je via deze link beluisteren.
9 uur geleden
