Herinnert u zich Heartbleed nog? Als je de hype van vandaag mag geloven, is Shellshock van dezelfde klasse en met een even geweldige naam, zij het zonder een cool logo (iemand in de marketingafdeling van deze vulnissen moet zich daarmee bezighouden). Maar in alle ernst, het heeft de potentie om een biggie te zijn en net als ik deed met Heartbleed, wilde ik iets definitiefs samenstellen, zowel voor mezelf om grip te krijgen op de situatie en voor anderen om de hype te ontleden van het echte onderliggende risico.
Om de scène te zetten, laat me wat inhoud delen van Robert Graham’s blog post die een aantal uitstekende analyses over dit heeft gedaan. Stel je een HTTP-verzoek als dit voor:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Dat, wanneer het wordt verzonden naar een reeks kwetsbare IP-adressen, resulteert in dit:
Kort gezegd, Robert heeft zojuist een aantal externe machines georkestreerd om hem te pingen door simpelweg een zorgvuldig opgesteld verzoek via het web te verzenden. Wat echt zorgwekkend is, is dat hij effectief deze machines een willekeurig commando heeft laten geven (zij het een tamelijk onschuldige ping) en dat opent een hele wereld van zeer serieuze mogelijkheden.
Wat is Bash en waarom hebben we het nodig?
Skip dit als het oud nieuws is, maar de context is belangrijk voor degenen die niet bekend zijn met Bash, dus laten we een basiskennis opdoen. Bash is een *nix shell of met andere woorden, een interpreter waarmee je commando’s kunt uitvoeren op Unix en Linux systemen, meestal door verbinding te maken via SSH of Telnet. Het kan ook werken als een parser voor CGI scripts op een web server zoals we die typisch op Apache zien draaien. Hij bestaat al sinds het eind van de jaren 80, waar hij zich ontwikkelde uit eerdere shell implementaties (de naam is afgeleid van de Bourne shell) en is enorm populair. Er zijn andere shells voor Unix-varianten, maar Bash is de standaard shell voor Linux en Mac OS X, wat natuurlijk veelgebruikte besturingssystemen zijn. Dat is een belangrijke factor waarom dit risico zo groot is – de alomtegenwoordigheid van Bash – en het wordt beschreven als “een van de meest geïnstalleerde programma’s op elk Linux-systeem”.
Je kunt een idee krijgen van de voetafdruk van Bash als je kijkt naar de laatste Netcraft-webserverstatistieken:
Als de helft van het net Apache draait (wat meestal op Linux staat), is dat een aanzienlijke grootte van een zeer, zeer grote taart. Hetzelfde Netcraft-artikel meldt dat we ook net de grens van één miljard websites zijn gepasseerd en hoewel een hoop daarvan dezelfde hosts delen, zijn dat nog steeds een heleboel Bash-installaties. Oh – dat zijn alleen nog maar webservers, vergeet niet dat er nog een hoop andere servers zijn die Linux draaien en we komen later nog terug op andere apparaten met Bash.
Bash kan worden gebruikt voor een hele reeks typische administratieve functies, alles van het configureren van websites tot het aansturen van embedded software op een apparaat zoals een webcam. Natuurlijk is deze functionaliteit niet bedoeld om open te zijn voor de wereld en in theorie hebben we het over geauthenticeerde gebruikers die commando’s uitvoeren waarvoor ze toestemming hebben gekregen. In theorie.
Wat is de bug?
Laat ik beginnen met de CVE van NIST kwetsbaarheden database, omdat het een goed gevoel geeft van de ernst (markering van mij):
GNU Bash door 4.3 verwerkt achterlopende tekenreeksen na functiedefinities in de waarden van omgevingsvariabelen, waardoor externe aanvallers willekeurige code kunnen uitvoeren via een aangepaste omgeving, zoals aangetoond door vectoren waarbij de ForceCommand-functie in OpenSSH sshd, de mod_cgi en mod_cgid-modules in de Apache HTTP Server, scripts die worden uitgevoerd door niet-gespecificeerde DHCP-clients en andere situaties waarin het instellen van de omgeving plaatsvindt over een privilegegrens van de uitvoering van Bash heen.
Ze geven het een beoordeling van “10 op 10” voor de ernst van het probleem, met andere woorden: zo slecht als het maar kan zijn. Daar komt nog bij dat de aanval eenvoudig uit te voeren is (de complexiteit van de toegang is laag) en misschien wel het belangrijkste is dat er geen authenticatie vereist is bij misbruik van Bash via CGI-scripts. De samenvatting hierboven is echter een beetje ingewikkeld, dus laten we het terugbrengen tot de mechanismen van de bug.
Het risico draait om de mogelijkheid om willekeurig omgevingsvariabelen te definiëren binnen een Bash-shell die een functiedefinitie specificeren. Het probleem begint wanneer Bash doorgaat met het verwerken van shell commando’s na de functiedefinitie, wat resulteert in wat wij classificeren als een “code injectie aanval”. Laten we nog eens naar Roberts voorbeeld kijken en alleen deze regel nemen:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
De functiedefinitie is () { :; }; en het shell commando is de ping-instructie en de daaropvolgende parameters. Wanneer dit wordt verwerkt binnen de context van een Bash-shell, wordt het arbitraire commando uitgevoerd. In een webcontext zou dit betekenen via een mechanisme zoals een CGI-script en ook niet noodzakelijkerwijs als een request-header. Het is de moeite waard om de seclists.org advisory door te lezen, waar ze meer in detail treden, inclusief de vermelding dat het pad en de query string potentiële vectoren voor de aanval kunnen zijn.
Eén manier om deze specifieke aanvalsvector te beperken is natuurlijk het uitschakelen van alle CGI functionaliteit die een shell aanroept, en sommigen bevelen dit ook aan. In veel gevallen zal dat echter een zeer ingrijpende verandering zijn en op zijn minst een die uitgebreid getest zal moeten worden om er zeker van te zijn dat het niet direct problemen veroorzaakt op de website, wat in veel gevallen wel het geval zal zijn.
Het HTTP bewijs hierboven is een eenvoudig maar effectief bewijs, zij het slechts een implementatie over een gemeenschappelijk protocol. Zodra je Telnet en SSH en blijkbaar zelfs DHCP erbij gaat betrekken, neemt het bereik dramatisch toe, dus we hebben het hier zeker niet alleen over het misbruiken van web app servers. (Blijkbaar is het risico alleen aanwezig in SSH post-auth, maar in zo’n vroeg stadium van de openbaarmaking zullen we onvermijdelijk nog andere aanvalsvectoren zien opduiken.)
Wat je ook moet onthouden is dat het bereik van de potentiële schade veel verder gaat dan het pingen van een willekeurig adres zoals in Roberts voorbeeld, dat is gewoon een keurig klein bewijs dat hij een machine kon orkestreren om een shell commando te geven. De vraag wordt deze: Welke schade kan een aanvaller aanrichten als hij een shell commando naar keuze kan uitvoeren op een kwetsbare machine?
Wat zijn de mogelijke vertakkingen?
Het potentieel is enorm – “shell” krijgen op een machine is altijd een grote overwinning geweest voor een aanvaller vanwege de controle die het hem biedt over de doelomgeving. Toegang tot interne gegevens, herconfiguratie van omgevingen, publicatie van hun eigen kwaadaardige code, enz. Het is bijna grenzeloos en het is ook gemakkelijk te automatiseren. Er zijn al vele voorbeelden van exploits die gemakkelijk tegen een groot aantal machines kunnen worden ingezet.
Wanneer het aankomt op het uitvoeren van willekeurige code in een shell op tot wel de helft van de websites op het internet, is het potentieel helaas behoorlijk groot. Een van de voor de hand liggende (en bijzonder vervelende) is het dumpen van interne bestanden zodat ze publiekelijk kunnen worden opgehaald. Wachtwoordbestanden en configuratiebestanden met referenties liggen voor de hand, maar het is denkbaar dat dit ook voor andere bestanden op het systeem geldt.
Zo zou dezelfde aanpak ook kunnen worden toegepast om bestanden naar het systeem te schrijven. Dit is in potentie de eenvoudigste manier om websites te defacen die we ooit hebben gezien, om nog maar te zwijgen van de eenvoudige manier om malware te verspreiden.
Of wat dacht je hiervan: een woord dat ik veel blijf tegenkomen is “worm”:
Wanneer we het over worm hebben in een kwaadaardige computercontext, hebben we het over een zichzelf replicerende aanval waarbij een kwaadwillende code creëert die zich kan verspreiden over doelwitten. We hebben bijvoorbeeld een zeer effectieve implementatie hiervan gezien met Samy’s MySpace XSS Worm, waarbij een aantal zorgvuldig opgestelde JavaScript erin slaagde om een miljoen pagina’s van slachtoffers in minder dan een dag te “infecteren”.
De zorg met Shellshock is dat een aanval van deze aard zich in een alarmerend tempo kan vermenigvuldigen, vooral in een vroeg stadium terwijl de meerderheid van de machines nog risico loopt. In theorie zou dit de vorm kunnen aannemen van een geïnfecteerde machine die naar andere doelwitten scant en de aanval naar hen verspreidt. Dit is zeker niet beperkt tot machines die op het publiek zijn gericht; als dit achter de bedrijfsfirewall gebeurt, is de sky the limit.
Mensen zijn nu bezig om hier misbruik van te maken. Dit is wat deze vroege dagen zo interessant maakt, omdat de wapenwedloop tussen degenen die op zoek zijn naar patches en degenen die op zoek zijn naar aanvallen, verhit raakt.
Welke versies van Bash zijn getroffen?
De krantenkoppen vermelden alles tot en met 4.3, of met andere woorden, ongeveer 25 jaar aan Bash-versies. Aangezien iedereen dit blijft vergelijken met Heartbleed, bedenk dan dat de getroffen versies van OpenSSL slechts twee jaar besloegen, wat een druppel op een gloeiende plaat is vergeleken met Shellshock. Ja, mensen upgraden hun versies, maar nee, ze doen het niet consequent en hoe je het ook wendt of keert, het aantal machines met een risico zal bij Shellshock aanzienlijk groter zijn dan bij Heartbleed.
Maar het risico kan ook verder gaan dan 4.3. We zien nu al berichten dat patches niet helemaal effectief zijn en gezien de snelheid waarmee ze worden uitgerold, is dat niet zo verwonderlijk. Dit is het soort ding dat degenen die erdoor worden getroffen heel goed in de gaten willen houden, niet alleen “patch en vergeet”.
Wanneer hoorden we er voor het eerst van en hoe lang lopen we al risico?
De eerste vermelding die ik heb gevonden in de openbare ether was deze zeer korte samenvatting op seclists.org die woensdag om ongeveer 14:00 GMT uitkwam (ongeveer middernacht vanochtend voor degenen onder ons aan de oostkant van Australië). De details kwamen een uur later in het advies dat ik eerder noemde, dus zo rond het midden van de middag woensdag in Europa of de ochtend in de VS. Het is nog erg vers nieuws met alle gebruikelijke pers speculaties en Chicken Little voorspellingen; het is nog te vroeg om een wijdverspreide exploitatie in het wild waar te nemen, maar dat zou ook heel snel kunnen komen als het risico zijn potentieel waarmaakt.
Scroll verder terug dan alleen wat openbaar is gemaakt en de bug werd blijkbaar vorige week ontdekt door Stéphane Chazelas, een “Unix/Linux, netwerk en telecom specialist” kerel in het Verenigd Koninkrijk. Dat gezegd hebbende, in Akamai’s bericht over de bug, hebben ze het erover dat de bug al “een lange periode” aanwezig is en natuurlijk gaan kwetsbare versies van Bash nu al twee en een halve decennia terug. De vraag is, net als bij Heartbleed, of kwaadwillenden hier al eerder van op de hoogte waren en of ze er actief gebruik van maakten.
Worden onze “dingen” getroffen?
Dit is waar het interessant wordt – we hebben veel “dingen” waarop Bash kan draaien. Als ik deze term gebruik, verwijs ik natuurlijk naar het “Internet der Dingen” (IoT), de toenemende verspreiding van een IP-adres en een draadloze adapter in alles, van ons bestek tot onze deursloten tot onze gloeilampen.
Veel IoT-apparaten draaien embedded Linux-distributies met Bash. Deze zelfde apparaten hebben al ernstige beveiligingslekken op andere gebieden, bijvoorbeeld LIFX lichtbollen nog maar een paar maanden geleden bleek wifi geloofsbrieven te lekken. Hoewel het geen Bash kwetsbaarheid is zoals Shellshock, laat het ons zien dat door het verbinden van onze dingen we een hele nieuwe wereld van kwetsbaarheden betreden op plaatsen die nooit eerder risico liepen.
Edit: Een paar mensen hebben verwezen naar de prevalentie van BusyBox die de Ash shell op mobiele apparaten draait. Apparaten waarop dit draait, lijken geen risico te lopen op Shellshock. Het probleem voor een consument is dat hij niet weet wat er op zijn apparaat draait, en dat geldt ook voor meer traditionele “dingen” zoals routers. De lange geschiedenis van deze bug betekent dat we meer dan een paar decennia apparaten hebben die verschillende evoluties van verschillende embedded OS hebben doorgemaakt en we hebben nu een zeer divers landschap van machines en shells over een lange periode.
Dit brengt veel nieuwe uitdagingen met zich mee; wie denkt er bijvoorbeeld actief aan om regelmatig hun gloeilampen te patchen? Denk ook aan de levensduur van de apparaten waarin deze software opduikt en of ze daadwerkelijk actief worden onderhouden. In een geval als de kwetsbare Trendnet-camera’s van een paar jaar geleden staan er ongetwijfeld nog heel veel op het web omdat ze, wat patchen betreft, zo goed als “klaar en vergeten” zijn. In feite is er in dat geval een heel Twitter-account gewijd aan het uitzenden van de beelden die het heeft vastgelegd van nietsvermoedende eigenaars van kwetsbare versies. Het is een groot probleem zonder gemakkelijke oplossingen en het zal ons nog heel lang bijblijven.
Maar Bash shells zijn ook aanwezig in veel meer gewone apparaten, bijvoorbeeld onze thuisrouters die over het algemeen op het internet zijn gericht. Weet je nog wanneer je voor het laatst de firmware van je router hebt gepatcht? Ok, als je dit leest dan ben je misschien het type technisch persoon dat zijn router ook echt patcht, maar verplaats je eens in de schoenen van de gemiddelde consument en vraag jezelf dat nog eens af. Precies.
Al onze spullen zitten op de Microsoft stack, lopen we risico?
Kort antwoord “nee”, lang antwoord “ja”. Ik zal eerst het makkelijke antwoord geven – Bash is niet van nature aanwezig op Windows en hoewel er Bash implementaties voor Windows zijn, is het zeker niet gebruikelijk en zal het ook niet op consumenten PC’s te vinden zijn. Het is ook niet duidelijk of producten als win-bash überhaupt kwetsbaar zijn voor Shellshock.
Het langere antwoord is dat het feit dat je in een voornamelijk Microsoft-centrische omgeving werkt, niet betekent dat je geen Bash hebt draaien op machines die andere discrete doelen dienen binnen die omgeving. Toen ik over Heartbleed schreef, verwees ik naar Nick Cravers bericht over de verschuiving van Stack Overflow naar SSL en verwees ik naar dit diagram van hun infrastructuur:
Er zijn niet-Microsoft-componenten die voor hun Microsoft-toepassingsstack zitten, componenten waar het verkeer doorheen moet voordat het de webservers bereikt. Dit zijn ook componenten met mogelijk verhoogde rechten achter de firewall – wat is de impact als Shellshock daarop wordt misbruikt? Het zou aanzienlijk kunnen zijn en dat is het punt dat ik hier maak; Shellshock heeft de potentie om activa te beïnvloeden die verder gaan dan alleen Bash-implementaties die risico lopen, wanneer het bestaat in een breder ecosysteem van andere machines.
Ik ben een systeembeheerder – wat kan ik doen?
Ten eerste, ontdekken of je risico loopt is triviaal omdat het zo’n gemakkelijk te reproduceren risico is. Er is een zeer eenvoudige test die The Register voorstelt, namelijk het uitvoeren van dit commando in je commandoregel:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Je wordt “busted”, je wordt teruggeëchood en je hebt de bug succesvol uitgebuit.
De prioriteit ligt hier natuurlijk bij het patchen van risicosystemen en de patch komt er in essentie op neer dat er geen code kan worden uitgevoerd na het einde van een Bash-functie. Linux distro’s zoals Red Hat brengen richtlijnen uit voor het patchen van risicosystemen, dus spring daar met voorrang op in.
We zullen onvermijdelijk ook definities voor inbraakdetectiesystemen zien en er zullen zeker gemeenschappelijke patronen zijn om hier naar te zoeken. Dat zou voor veel organisaties wel eens een goede onmiddellijke implementatie kunnen blijken te zijn, vooral waar er zware testvereisten kunnen zijn voordat er patches worden uitgerold voor systemen die een risico vormen. Qualys’ mikt op een definitie om de aanval vrij snel te detecteren en andere IDS aanbieders werken hier onvermijdelijk ook de klok rond aan.
Andere meer drastische opties zijn het vervangen van Bash door een alternatieve shell implementatie of het afschermen van risicosystemen, die beide verstrekkende gevolgen kunnen hebben en waarschijnlijk geen lichtvaardige beslissingen zullen zijn. Maar dat is waarschijnlijk de aard van deze bug voor veel mensen – moeilijke beslissingen die tastbare zakelijke gevolgen kunnen hebben om potentieel veel grotere vertakkingen te voorkomen.
De andere kwestie die nu veel aan de orde zal komen is de vraag of Shellshock al is uitgebuit in een omgeving. Dit kan moeilijk vast te stellen zijn als er geen logging is van de aanvalsvectoren (vaak niet als het wordt doorgegeven via de HTTP request header of POST body), maar de kans is groter dat het wordt opgemerkt dan bij Heartbleed, toen de heartbeat payloads normaal gesproken nergens zouden zijn gelogd, tenzij er sprake was van volledige pcaps. Maar toch, het meest voorkomende antwoord op de vraag “werden we aangevallen via Shellshock” zal het volgende zijn:
Helaas is dit niet “Nee, we hebben bewijs dat er geen compromissen zijn geweest”, maar “we hebben geen bewijs dat de levensduur van deze kwetsbaarheid overspant”. We betwijfelen of veel mensen dat wel hebben – en dit laat systeemeigenaren in de ongemakkelijke positie dat ze niet weten of er al sprake is geweest van compromissen.
Laat het speculeren over de vraag of de NSA hierbij betrokken was maar beginnen…
Ik ben een consument – wat kan ik doen?
Het hangt ervan af. Shellshock treft Macs, dus als je OS X draait, lijkt dat in dit stadium risico te lopen, wat aan de ene kant slecht is vanwege de gangbaarheid van OS X, maar aan de andere kant gemakkelijk (en hopelijk snel) te verhelpen zal zijn vanwege een behoorlijk beproefd updatemechanisme (d.w.z. Apple kan op afstand updates naar de machine pushen).
Als je een Mac hebt, kun je het risico gemakkelijk testen zoals beschreven in dit Stack Exchange-antwoord:
Het is een gemakkelijke test, hoewel ik betwijfel of de gemiddelde Mac-gebruiker zich op zijn gemak zal voelen om de voorgestelde oplossing uit te voeren, die het opnieuw compileren van Bash inhoudt.
De grotere zorg betreft de apparaten zonder gemakkelijk patchtraject, bijvoorbeeld je router. Behalve het controleren van de website van de fabrikant voor bijgewerkte firmware, zal dit een heel moeilijke noot worden om te kraken. Vaak zijn routers die door ISP’s worden geleverd vergrendeld zodat consumenten niet willekeurig de configuratie of firmware kunnen wijzigen en er is ook niet altijd een extern upgradepad dat ze kunnen activeren. Combineer dat met de enorme hoeveelheid apparaten en leeftijden die er zijn en dit zou bijzonder lastig kunnen zijn. Natuurlijk is het ook niet iets wat de gemiddelde consument graag zelf doet.
Kortom, het advies aan de consument is dit: let op beveiligingsupdates, vooral van OS X. Houd ook de adviezen in de gaten die je krijgt van je ISP of andere leveranciers van apparaten met embedded software. Wees op uw hoede voor e-mails waarin om informatie wordt gevraagd of waarin u wordt opgedragen software uit te voeren – dergelijke gebeurtenissen worden vaak gevolgd door phishing-aanvallen die inspelen op de angst van de consument. Hoaxes zorgen er tegenwoordig voor dat mensen hun iPhones in de magnetron stoppen, dus denk geen moment dat ze niet een willekeurig stukje software zullen draaien dat ze via email toegestuurd krijgen als “fix” voor Shellshock!
Summary
Naar alle waarschijnlijkheid zijn we nog niet eens begonnen met het doorgronden van de omvang van deze kwetsbaarheid. Natuurlijk worden er veel vergelijkingen gemaakt met Heartbleed en er zijn een aantal dingen die we geleerd hebben van die oefening. Een daarvan is dat het even duurde voordat het doordrong, omdat we ons realiseerden in hoeverre we afhankelijk waren van OpenSSL. Het andere is dat het een zeer lange staart had – maanden nadat het aansloeg waren er nog steeds honderdduizenden bekende hosts kwetsbaar.
Maar in één opzicht is de vergelijking met Heartbleed niet eerlijk – dit is potentieel veel erger. Heartbleed maakte toegang op afstand mogelijk tot een kleine hoeveelheid gegevens in het geheugen van de getroffen machines. Shellshock maakt code-injectie op afstand van willekeurige commando’s mogelijk, pre-auth, wat potentieel veel ernstiger is. In dat opzicht moet ik Robert gelijk geven:
Het is nog heel, heel vroeg dag – op het moment van schrijven is het nog maar een halve dag geleden dat het voor het eerst de ether in ging – en ik vermoed dat we tot nu toe nog maar een tipje van de sluier oplichten van wat ons nog te wachten staat.
Beveiliging