Log4Shell een jaar later: lessen voor de volgende code rood
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.
Verder lezen bij de bron- Persoonlijke gegevens van ruim 1000 leerlingen gelekt bij datalek in Amersfoort - 19 september 2024
- Cyberopslag is een essentieel onderdeel van de gegevensbeveiligingsstrategie - 18 september 2024
- Let op, gebruik AI chatbot kan leiden tot datalekken - 18 september 2024
Lees ons boek
Gemeenten. Bewustzijn. Privacy.
Nieuwsbrief
Deze versturen we 3-4x per jaar.
Recente blogs
Meer recente berichten
Persoonlijke gegevens van ruim 1000 leerlingen gelekt bij datalek in Amersfoort | Verder lezen | |
Cyberopslag is een essentieel onderdeel van de gegevensbeveiligingsstrategie | Verder lezen | |
Let op, gebruik AI chatbot kan leiden tot datalekken | Verder lezen | |
Rabobank moet gegevens vermeende oplichter met getroffen klant delen | Verder lezen | |
De mate waarin organisaties zijn voorbereid op een cybercrisis loopt sterk uiteen | Verder lezen | |
Defensie heeft te weinig inzicht in zwaktes ICT infrastructuur | Verder lezen | |
AP: kabinet moet wet aanpassen om journalisten bij Kadaster database te laten | Verder lezen | |
Minister Heinen in gesprek met BKR over verwijderen registraties | Verder lezen | |
Ict aanbieders onvoldoende voorbereid op cyberramp | Verder lezen | |
Security op de productievloer, gemakkelijker gezegd dan gedaan | Verder lezen |