Shellshock is een bug in de Bash command-line interface shell die al 30 jaar bestaat en in 2014 werd ontdekt als een significante bedreiging. Vandaag de dag vormt Shellshock nog steeds een bedreiging voor ondernemingen.
De dreiging is zeker minder riskant dan in het jaar van ontdekking. Maar in een jaar waarin de beveiligingsprioriteiten zijn herijkt om het chaotische landschap bij te houden, is het een goed moment om terug te kijken naar deze dreiging en de onderliggende factoren die deze aanvallen vandaag in leven houden.
Waarom is Shellshock relevant in 2020?
Shellshock is een kritieke kwetsbaarheid vanwege de geëscaleerde privileges die aanvallers krijgen, waardoor ze systemen naar believen kunnen compromitteren. Hoewel de ShellShock-kwetsbaarheid, CVE-2014-6271, in 2014 werd ontdekt, is bekend dat deze nog steeds bestaat op een groot aantal servers in de wereld. De kwetsbaarheid werd kort daarna bijgewerkt (CVE-2014-7169) en is tot 2018 aangepast.
De belangrijkste reden dat Shellshock nog steeds in gebruik is, is geen schokkende. Deze kwetsbaarheid is een eenvoudige en goedkope aanval die slechte actoren kunnen inzetten tegen een onwetend doelwit. Patches zijn beschikbaar sinds de CVE-entry, maar elke organisatie zonder goede patchmanagementsystemen op zijn plaats kan nog steeds kwetsbaar zijn.
Shellshock was nog steeds prominent aanwezig in 2017. Wanneer alles wat aanvallers nodig hebben enkele basis programmeervaardigheden, een server en toegang tot malware zijn, is het niet verwonderlijk. Plus, de kosten om een aanval uit te voeren zijn niet veel meer dan een paar dollar per maand. De wiskunde is in het voordeel van de aanvallers. Minimale kennis, weinig moeite en lage kosten staan gelijk aan een makkelijke hackstrategie.
Ondanks alle uitgebreide media-aandacht voor cyberveiligheid en zelfs een waarschuwing van het Department of Homeland Security, blijven sommige systemen ongepatcht. In één voorbeeld hebben functionarissen van het Center for Election Systems verzuimd een patch toe te passen die de verkiezingssystemen in Georgia in gevaar heeft gebracht.
Hoe werkt Shellshock?
In lekentaal is Shellshock een kwetsbaarheid waarmee systemen met een kwetsbare versie van Bash kunnen worden misbruikt om commando’s met hogere rechten uit te voeren. Hierdoor kunnen aanvallers dat systeem potentieel overnemen.
Duik dieper in de techniek, Shellshock is een beveiligingsfout in de Bash-shell (GNU Bash tot versie 4.3) die ervoor zorgt dat Bash onbedoeld bash-commando’s uitvoert vanuit omgevingsvariabelen. Bedreigers die de kwetsbaarheid misbruiken, kunnen op afstand commando’s uitvoeren op de doelhost. Hoewel Bash niet inherent op het internet is gericht, gebruiken veel interne en externe diensten, zoals webservers, omgevingsvariabelen om te communiceren met het besturingssysteem van de server.
Als die gegevensinvoer niet wordt gezuiverd – het coderingsstandaardproces dat ervoor zorgt dat code geen deel uitmaakt van de invoer – voordat deze wordt uitgevoerd, kunnen aanvallers HTTP-verzoekopdrachten starten die via de Bash-shell worden uitgevoerd.
Vulnerability in Detail
Webservers zijn niet de enige kwetsbare netwerkbronnen. E-mailservers en DNS-servers die BASH gebruiken om met het besturingssysteem te communiceren, kunnen ook worden getroffen. Hoewel BASH normaal gesproken wordt aangetroffen op Unix-gebaseerde systemen, zijn organisaties die Windows-gebaseerde systemen gebruiken niet immuun. Deze maken waarschijnlijk gebruik van appliances of hardware die kwetsbaar zijn. Vergeet niet dat BASH een onderdeel kan zijn van thuisrouters, veel IoT-apparaten en embedded systemen.
Shellshock kan zelfs worden gebruikt om Denial of Service (DOS) -aanvallen uit te voeren.
Hier is de regel code (een Bash-functiedeclaratie gevolgd door een puntkomma en het ‘sleep’-commando uitgevoerd vanuit drie mogelijke paden om ervoor te zorgen dat het wordt uitgevoerd):
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
Dit “sleep” commando dwingt de server om twintig seconden te wachten voordat hij antwoord geeft. Daarbij worden de bronnen op de machine in feite gegijzeld, omdat de machine twintig seconden lang niets anders kan doen.
Een slaapcommando kan onschadelijk zijn, maar een aanvaller kan in staat zijn om dit te vervangen door kwaadaardige code. Vervolgens kan die code de server of bron boeien, zodat deze geen verzoeken meer kan afhandelen.
Het risico dat schadelijke internetgebruikers op afstand commando’s naar keuze kunnen uitvoeren, is groot. Door de opening te gebruiken, kunnen slechte actoren programma’s op het systeem starten, uitgaande verbindingen met hun eigen systemen tot stand brengen en kwaadaardige software uitvoeren.
Het meest kritisch is misschien wel dat de kwetsbaarheid kan worden misbruikt om vertrouwelijke gegevens en informatie te stelen die op het systeem is opgeslagen, zoals creditcardgegevens, wachtwoorden en persoonlijk identificeerbare informatie (PII).
Is Shellshock nog steeds woekerend?
Shellshock is niet meer zo wijdverspreid als toen het in 2014 werd ontdekt. Stel je de uitdaging voor om alle kwetsbare servers van je bedrijf te moeten patchen (en, dat waren er veel op dat moment).
Dat gezegd hebbende, Shellshock blijft een probleem.
Er is bijvoorbeeld een voortdurende cyberdreigings- en kwetsbaarheidscampagne genaamd “Sea Turtle” die gebruikmaakt van DNS-records om toegang te krijgen tot gevoelige systemen. Om de aanvallen te laten slagen, zijn een aantal veelvoorkomende hardware- en softwarekwetsbaarheden nodig – Shellshock is er daar een van.
Hoewel Shellshock lang niet meer zo wijdverbreid is als voorheen, moet elk bedrijf ervoor zorgen dat alle hardware en software is gepatcht en up-to-date is.
Hoe te weten of u bent getroffen
Omdat Shellshock zes jaar oud is, zijn er veel scanners voor kwetsbaarheden beschikbaar. Sommige zijn gratis. Een ervan, bashcheck, kan worden gedownload via Github.
Voor de technische mensen is een simpel commando in de Bash prompt ook voldoende:
env X=”() { :;} ; echo Bash is Infected” /bin/sh -c “echo completed”
env X=”() { :;} ; echo Bash is geïnfecteerd” /bin/sh -c “echo completed”
env VAR=”() { :;}; echo Bash is geïnfecteerd” bash -c “echo completed”
Als de prompt een “Bash is geïnfecteerd”-bericht retourneert, is het tijd om te updaten en te repareren. Als uw uitvoer niet “Bash is geïnfecteerd” terugstuurt, zal het reageren met iets als:
bash: waarschuwing: VAR: negeer poging tot functiedefinitie
bash: fout bij importeren functiedefinitie voor `VAR’
Bash Test
Als u de kwetsbaarheid voor websites of specifieke CGI-scripts wilt testen, kan de volgende tool helpen: ‘ShellShock’ Bash Vulnerability CVE-2014-6271 Test Tool. Voer in een van de twee invoervelden de URL in van de website of het CGI-script dat u wilt testen en klik op de blauwe knoppen.
Wat we kunnen leren over cyberveiligheidsbedreigingen
De grootste les voor de onderneming hier – en het verdient herhaling – is om uw systemen te patchen.
Teams die de patchtijden kunnen verkorten, bevinden zich in een betere positie om die middelen te verschuiven naar dringender beveiligingsproblemen. Hoewel sommige bedrijven patchbeheer meer als een IT-verantwoordelijkheid dan als een beveiligingsverantwoordelijkheid beschouwen, moet patchbeheer altijd bovenaan de agenda van beveiligingsafdelingen staan, omdat het van cruciaal belang is voor de beveiligingspositie van een bedrijf.
Als uw systemen vandaag de dag nog steeds kwetsbaar zijn, zijn er waarschijnlijk enkele onderliggende operationele problemen die moeten worden aangepakt. Shellshock is een zeer oude kwetsbaarheid met patches die voor bijna elk systeem beschikbaar zijn. De beste manier om u tegen dit type kwetsbaarheid te beschermen, is uw systemen up-to-date te houden en alle fixes toe te passen die voor deze exploit zijn uitgebracht.
Bij het patchen van bedrijfsmiddelen, doorgaans een rechttoe rechtaan proces, moet u een strategische benadering omarmen.
Patches die grondig zijn getest, zijn een geweldige manier om de bedrijfsimpact te minimaliseren – zoals een missiekritische server die een oud besturingssysteem draait. Als een systeem niet onmiddellijk kan worden gepatcht, moet het potentiële risico van de kwetsbaarheid worden afgewogen tegen de zakelijke impact.
Shellshock is er slechts een in een lange lijst van kwetsbaarheden waarmee de onderneming moet omgaan. Het beheer van de schijnbaar eindeloze stroom van kwetsbaarheden is en blijft een cruciale strategie die cyberbeveiliging schraagt.
Checklist voor een veilige organisatie
Voor een succesvol beheer van kwetsbaarheden moeten bedrijven in staat zijn om op deze drie gebieden succesvol te zijn:
- Potentieel schadelijke kwetsbaarheden snel identificeren: Snelheid is hier alles. Iedereen op één lijn hebben met een solide plan zou snellere reactietijden moeten bevorderen.
- Het bepalen van de ernst van de kwetsbaarheid: Als u de risicotolerantie van uw organisatie kent, kunt u bepalen hoe ernstig een kwetsbaarheid kan zijn. Afhankelijk van uw netwerkinfrastructuur zijn sommige kwetsbaarheden schadelijker dan andere.
- Het hebben van een plan van aanpak dat een balans vindt tussen de urgentie van beveiliging en de mogelijke impact op productieomgevingen: Het in evenwicht brengen van beveiliging met productie en productiviteit is een constante hindernis, maar organisaties met de meest goed gedefinieerde plannen voor het beheer van kwetsbaarheden vinden doorgaans de beste balans.
Voor onafhankelijk beveiligingsonderzoeker Rod Soto was de grootste les die hij leerde van Shellshock dat het internet is gebaseerd op veel kwetsbare applicaties en altijd de potentie in zich draagt om een groot deel van de segmenten te compromitteren.
“De manier om deze potentiële kwetsbaarheden in de toekomst te beheren, is om de communicatie open en transparant te houden tussen ontwikkelaars, beheerders en beveiligingsprofessionals”, zegt Soto. “Dus als zo’n uitgebreide en significante kwetsbaarheid wordt gevonden, kan coördinatie tussen alle betrokken partijen worden gebruikt om getroffen systemen te patchen of te mitigeren.”
Ook in gevallen waarin uw bedrijf succesvol is in het mitigeren van risico’s voor Shellshock of een andere kwetsbaarheid, kunt u er niet van uitgaan dat uw responsplan perfect is. Het responsplan moet een levend, ademend document zijn, en moet vaak worden herzien, zodat uw organisatie snel op bedreigingen kan reageren.
Ten slotte zijn er, net als in elk ander scenario na een aanval, vragen die u moet stellen bij het beoordelen van elke fase van het plan.
- Welke delen van het plan waren succesvol?
- Welke delen van het plan waren niet succesvol?
- Wat hebben we niet gedaan, waarvan we ons nu realiseren dat we het wel hadden moeten doen?
- Wat hebben we geleerd waardoor we beter voorbereid zijn op de volgende kwetsbaarheid die op ons pad komt?
Shellshock mag dan een oude aanval zijn, maar voor een aanvaller voldoet het aan alle voorwaarden om slachtoffers te misbruiken die geen goede veiligheidshygiëne hebben.