Shellshock er en fejl i kommandolinjeskemaet Bash, som har eksisteret i 30 år og blev opdaget som en betydelig trussel i 2014. I dag er Shellshock stadig en trussel mod virksomheder.
Truslen er bestemt mindre risikabel end i det år, hvor den blev opdaget. Men i et år, hvor sikkerhedsprioriteterne er blevet omkalibreret for at holde trit med det kaotiske landskab, er det et godt tidspunkt at se tilbage på denne trussel og de underliggende faktorer, der holder disse angreb i live i dag.
Hvorfor er Shellshock relevant i 2020?
Shellshock er en kritisk sårbarhed på grund af de eskalerede privilegier, som angriberne får, og som gør det muligt for dem at kompromittere systemer efter forgodtbefindende. Selv om ShellShock-sårbarheden, CVE-2014-6271, blev opdaget i 2014, er det kendt, at den stadig findes på et stort antal servere i verden. Sårbarheden blev opdateret (CVE-2014-7169) kort efter og er blevet ændret frem til 2018.
Den vigtigste årsag til, at Shellshock stadig er i brug, er ikke chokerende. Denne sårbarhed er et simpelt og billigt angreb, som dårlige aktører kan implementere mod et uvidende mål. Der har været patches til rådighed siden CVE-angivelsen, men enhver organisation uden ordentlige patch management-systemer på plads kan stadig være sårbar.
Shellshock var stadig fremtrædende i 2017. Når alt, hvad angribere har brug for, er nogle grundlæggende programmeringsfærdigheder, en server og adgang til malware, er det ikke overraskende. Desuden er omkostningerne til at gennemføre et angreb ikke meget mere end et par dollars om måneden. Regnestykket er i angribernes favør. Minimal viden, lille indsats og lave omkostninger er lig med en nem hackerstrategi.
Trods al den omfattende cybersikkerhedsdækning i medierne og endda en advarsel fra Department of Homeland Security er der stadig nogle systemer, der ikke er blevet patchet. I et eksempel undlod embedsmænd fra Center for Election Systems at anvende en patch, som kompromitterede valgsystemerne i Georgia.
Hvordan virker Shellshock?
Shellshock er en sårbarhed, der gør det muligt at udnytte systemer, der indeholder en sårbar version af Bash, til at udføre kommandoer med højere privilegier. Dette giver angribere mulighed for potentielt at overtage det pågældende system.
Dykker man dybere ned i det tekniske, er Shellshock en sikkerhedsfejl i Bash-shellen (GNU Bash op til version 4.3), der får Bash til at udføre utilsigtede bash-kommandoer fra miljøvariabler. Trusselsaktører, der udnytter sårbarheden, kan udstede kommandoer eksternt på målværten. Selv om Bash ikke i sig selv er rettet mod internettet, bruger mange interne og eksterne tjenester som f.eks. webservere miljøvariabler til at kommunikere med serverens styresystem.
Hvis disse datainput ikke er sanitized – den kodningsstandardproces, der sikrer, at kode ikke er en del af input – før de udføres, kan angribere lancere HTTP-anmodningskommandoer, der udføres via Bash-shell’en.
Sårbarhed i detaljer
Webservere er ikke de eneste sårbare netværksressourcer. E-mailservere og DNS-servere, der bruger BASH til at kommunikere med operativsystemet, kan også blive påvirket. Mens BASH normalt findes på Unix-baserede systemer, er organisationer, der anvender Windows-baserede systemer, ikke immune. De anvender sandsynligvis apparater eller hardware, der er sårbare. Husk, at BASH kan være en del af hjemme-routere, mange IoT-enheder og indlejrede systemer.
Shellshock kan endda bruges til at iværksætte Denial of Service (DOS)-angreb.
Her er kodelinjen (en Bash-funktionsdeklaration efterfulgt af et semikolon og kommandoen “sleep”, der køres fra tre mulige stier for at sikre, at den bliver eksekveret):
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
Denne “sleep”-kommando tvinger serveren til at vente tyve sekunder, før den svarer. Derved holdes ressourcerne på maskinen i det væsentlige som gidsler, fordi maskinen ikke kan gøre andet i tyve sekunder.
En sleep-kommando kan være harmløs, men en angriber kan være i stand til at erstatte den med skadelig kode. Derefter kan denne kode lægge serveren eller ressourcen i håndjern, så den ikke kan håndtere nogen anmodninger.
Risikoen for, at skadelige internetbrugere får mulighed for at udføre kommandoer efter eget valg på afstand, er stor. Ved at bruge åbningen kan skadelige aktører starte programmer på systemet, oprette udgående forbindelser til deres egne systemer og udføre skadelig software.
Måske mest kritisk er det, at sårbarheden kan udnyttes til at stjæle fortrolige data og oplysninger, der er gemt på systemet, såsom kreditkortoplysninger, adgangskoder og personligt identificerbare oplysninger (PII).
Er Shellshock stadig udbredt?
Shellshock er ikke så udbredt som dengang, den blev opdaget i 2014. Forestil dig udfordringen ved at skulle patche alle din virksomheds sårbare servere (og der var mange på det tidspunkt).
Det sagt er Shellshock stadig et problem.
For eksempel er der en igangværende cybertrussel og sårbarhedskampagne kaldet “Sea Turtle”, som udnytter DNS-poster til at få adgang til følsomme systemer. For at angrebene kan lykkes, kræver det en række almindelige hardware- og softwaresårbarheder – Shellshock er en af dem.
Selv om det ikke er nær så udbredt som tidligere, bør alle virksomheder sørge for, at al hardware og software er patchet og opdateret.
Sådan ved du, om du er berørt
Da Shellshock er seks år gammel, er der masser af sårbarhedsscannere til rådighed. Nogle af dem er gratis. En, bashcheck, kan downloades ved hjælp af Github.
For de tekniske folk vil det også gøre tricket at skrive en simpel kommando i Bash-prompten:
env X=”() { :;} ; echo Bash is Infected” /bin/sh -c “echo completed”
env X=”() { :;} ; echo Bash is Infected” `which bash` -c “echo completed”
env VAR='() { :;}; echo Bash is Infected’ bash -c “echo completed”
Hvis prompten returnerer en “Bash is Infected”-meddelelse, er det tid til at opdatere og rette. Hvis dit output ikke returnerer “Bash is Infected”, vil det svare med noget i stil med:
bash: warning: VAR: ignorerer forsøg på funktionsdefinition
bash: error importing function definition for `VAR’
Bash Test
Hvis du gerne vil teste sårbarheden for websteder eller specifikke CGI-scripts, kan følgende værktøj være en hjælp: ‘ShellShock’ Bash-sårbarhed CVE-2014-6271 Testværktøj. Indtast URL-adressen for det websted eller CGI-script, du vil teste, i et af de to indtastningsfelter, og klik på de blå knapper.
Hvad vi kan lære om cybersikkerhedstrusler
Den største læring for virksomheden her – og den tåler at blive gentaget – er at patche dine systemer.
Teams, der kan reducere patching-tiden, er i en bedre position til at flytte disse ressourcer til mere presserende sikkerhedsproblemer. Selv om nogle virksomheder betragter patch management mere som et it-ansvar end et sikkerhedsansvar, skal patch management altid være øverst på dagsordenen for sikkerhedsafdelingerne, da det er afgørende for en virksomheds sikkerhedstilstand.
Hvis dine systemer stadig er sårbare i dag, er der sandsynligvis nogle underliggende operationelle problemer, som bør løses. Shellshock er en meget gammel sårbarhed med patches til rådighed for næsten alle systemer. Den bedste måde at beskytte sig mod denne type sårbarhed på er at holde dine systemer opdateret og anvende alle de rettelser, der er udgivet for denne udnyttelse.
Når du patcher aktiver, som typisk er en simpel proces, bør du omfavne en strategisk tilgang.
Patches, der er testet grundigt, er en god måde at minimere forretningspåvirkningen på – som f.eks. en forretningskritisk server, der kører et gammelt operativsystem. Hvis et system ikke kan patches med det samme, skal den potentielle risiko ved sårbarheden afvejes mod forretningspåvirkningen.
Shellshock er blot én i en lang række sårbarheder, som virksomheden skal forholde sig til. Håndtering af den tilsyneladende uendelige strøm af sårbarheder er og vil altid være en afgørende strategi, der understøtter cybersikkerhed.
Checkliste for en sikker organisation
For at få succes med sårbarhedsstyring skal virksomheder have evnen til at lykkes på disse tre områder:
- Identificering af potentielt følsomme sårbarheder hurtigt: Hurtighed er det vigtigste her. At have alle på samme side med en solid plan bør fremme hurtigere reaktionstider.
- Fastsættelse af sårbarhedens alvorlighedsgrad: Hvis du kender din organisations risikotolerance, kan du i høj grad bestemme, hvor alvorlig en sårbarhed kan være. Afhængigt af din netværksinfrastruktur er nogle sårbarheder mere skadelige end andre.
- At have en handlingsplan, der balancerer sikkerhedens hastende karakter med den potentielle indvirkning på produktionsmiljøer: At balancere sikkerhed med produktion og produktivitet er en konstant hurdle, men organisationer med de mest veldefinerede planer for håndtering af sårbarheder finder typisk den bedste balance.
- Hvilke dele af planen var vellykkede?
- Hvilke dele af planen var ikke vellykkede?
- Hvad gjorde vi ikke, som vi nu indser, at vi var nødt til at gøre?
- Hvad lærte vi, som gør det muligt for os at være bedre forberedt på den næste sårbarhed, der kommer på vores vej?
For den uafhængige sikkerhedsforsker Rod Soto var den største læring fra Shellshock, at internettet er baseret på mange sårbare applikationer og altid har potentiale til at kompromittere en stor del af segmenterne.
“Måden at håndtere disse potentielle sårbarheder i fremtiden er at holde kommunikationen åben og gennemsigtig mellem udviklere, vedligeholdere og sikkerhedseksperter”, siger Rod Soto. “Så hvis der findes en så omfattende og betydelig sårbarhed, kan koordineringen mellem alle berørte parter bruges til at patche eller afbøde de berørte systemer.”
Selv i de tilfælde, hvor det lykkes din virksomhed at afbøde risikoen for Shellshock eller en anden sårbarhed, kan du ikke gå ud fra, at din responsplan er perfekt. Responsplanen bør være et levende dokument, der lever og ånder, og den bør revideres ofte, så din organisation kan reagere hurtigt på trusler.
Sluttelig er der, som i ethvert scenarie efter et angreb, spørgsmål, du bør stille, når du gennemgår hver fase af planen.
Shellshock er måske nok et gammelt angreb, men for en angriber er det en god mulighed for at udnytte ofre, der mangler ordentlig sikkerhedshygiejne.