Shellshock på djupet:

Shellshock är en bugg i kommandoradsgränssnittet Bash som har funnits i 30 år och upptäcktes som ett betydande hot 2014. I dag är Shellshock fortfarande ett hot mot företag.

Hotet är förvisso mindre riskabelt än det år då det upptäcktes. Men under ett år då säkerhetsprioriteringarna har omkalibrerats för att hålla jämna steg med det kaotiska landskapet är det ett bra tillfälle att se tillbaka på detta hot och de underliggande faktorer som håller dessa attacker vid liv idag.

Varför är Shellshock relevant år 2020?

Shellshock är en kritisk sårbarhet på grund av de upptrappade privilegier som angriparna får, vilket gör att de kan kompromettera system när de vill. Även om ShellShock-sårbarheten, CVE-2014-6271, upptäcktes 2014 är det känt att den fortfarande finns på ett stort antal servrar i världen. Sårbarheten uppdaterades (CVE-2014-7169) kort därefter och har ändrats fram till 2018.

Den främsta anledningen till att Shellshock fortfarande används är ingen chock. Sårbarheten är en enkel och billig attack som dåliga aktörer kan använda mot ett ovetande mål. Patchar har funnits tillgängliga sedan CVE-inlägget, men alla organisationer utan lämpliga system för patchhantering kan fortfarande vara sårbara.

Shellshock var fortfarande framträdande under 2017. När allt angripare behöver är några grundläggande programmeringskunskaper, en server och tillgång till skadlig kod är det inte förvånande. Dessutom är kostnaden för att genomföra en attack inte mycket mer än några dollar per månad. Matematiken är till angriparnas fördel. Minimal kunskap, liten ansträngning och låg kostnad är lika med en enkel hackningsstrategi.

Trots all den omfattande mediebevakningen av cybersäkerhet och till och med en varning från Department of Homeland Security är vissa system fortfarande inte uppdaterade. I ett exempel misslyckades tjänstemän vid Center for Election Systems med att tillämpa en patch som äventyrade valsystemen i Georgia.

Hur fungerar Shellshock?

Shellshock är en sårbarhet som gör att system som innehåller en sårbar version av Bash kan utnyttjas för att utföra kommandon med högre privilegier. Detta gör det möjligt för angripare att potentiellt ta över systemet.

Du går djupare in på det tekniska, Shellshock är ett säkerhetsfel i Bash-skalet (GNU Bash upp till version 4.3) som gör att Bash kan utföra oavsiktliga Bash-kommandon från miljövariabler. Hotaktörer som utnyttjar sårbarheten kan utfärda kommandon på distans på målvärden. Bash är inte i sig självt inriktad på Internet, men många interna och externa tjänster, t.ex. webbservrar, använder miljövariabler för att kommunicera med serverns operativsystem.

Om dessa datainmatningar inte saneras – den kodningsstandard som säkerställer att koden inte är en del av inmatningen – innan de exekveras, kan angripare starta HTTP-begärningskommandon som exekveras via Bash-skalet.

Sårbarhet i detalj

Vebservrar är inte de enda sårbara nätverksresurserna. E-postservrar och DNS-servrar som använder Bash för att kommunicera med operativsystemet kan också påverkas. BASH finns normalt på Unix-baserade system, men organisationer som använder Windows-baserade system är inte immuna. Dessa använder troligen apparater eller hårdvara som är sårbara. Kom ihåg att BASH kan vara en del av hemroutrar, många IoT-enheter och inbyggda system.

Shellshock kan till och med användas för att starta DOS-attacker (Denial of Service).

Här är kodraden (en Bash-funktionsdeklaration följt av ett semikolon och kommandot ”sleep” som körs från tre möjliga vägar för att se till att det blir utfört):

new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20

Detta ”sleep”-kommando tvingar servern att vänta tjugo sekunder innan den svarar. På så sätt hålls resurserna på maskinen i princip som gisslan eftersom maskinen inte kan göra något annat under tjugo sekunder.

Ett sleep-kommando kan vara ofarligt, men en angripare kan ersätta detta med skadlig kod. Den koden kan sedan lägga servern eller resursen i handbojor så att den inte kan hantera några förfrågningar.

Risken för att låta skadliga Internetanvändare utföra valfria kommandon på distans är stor. Genom att använda öppningen kan dåliga aktörer starta program på systemet, skapa utgående anslutningar till sina egna system och exekvera skadlig programvara.

Kanske mest kritiskt är att sårbarheten kan utnyttjas för att stjäla konfidentiella data och information som lagras i systemet, t.ex. kreditkortsuppgifter, lösenord och personligt identifierbar information (PII).

Är Shellshock fortfarande utbredd?

Shellshock är inte lika utbredd som den var när den upptäcktes 2014. Föreställ dig utmaningen att behöva patcha alla företagets sårbara servrar (och det fanns många vid den tidpunkten).

Med det sagt är Shellshock fortfarande ett problem.

Det finns till exempel en pågående cyberhot- och sårbarhetskampanj kallad ”Sea Turtle” som utnyttjar DNS-poster för att få tillgång till känsliga system. För att attackerna ska lyckas krävs ett antal vanliga sårbarheter i hård- och mjukvara – Shellshock är en av dem.

Och även om det inte är lika utbrett som tidigare bör alla företag se till att all hård- och mjukvara är patchad och uppdaterad.

Hur man vet om man är drabbad

Då Shellshock är sex år gammalt finns det gott om sårbarhetsskannrar att tillgå. En del av dem är gratis. En av dem, bashcheck, kan laddas ner via Github.

För de tekniska personerna räcker det också att skriva ett enkelt 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”

Om prompten returnerar ett ”Bash is Infected”-meddelande är det dags att uppdatera och fixa. Om din utdata inte returnerar ”Bash is Infected” kommer den att svara med något i stil med:

bash: warning: VAR: ignoring function definition attempt

bash: error importing function definition for `VAR’

Bash Test

Om du vill testa sårbarheten för webbplatser eller specifika CGI-skript kan följande verktyg hjälpa dig: ShellShock’ Bash-sårbarhet CVE-2014-6271 Testverktyg. I något av de två inmatningsfälten anger du webbadressen för den webbplats eller det CGI-skript som du vill testa och klickar på de blå knapparna.

Vad vi kan lära oss om hot mot cybersäkerheten

Den största lärdomen för företaget här – och den tål att upprepas – är att lappa dina system.

Team som kan förkorta tiden för lappning har bättre förutsättningar att flytta över dessa resurser till mer brådskande säkerhetsfrågor. Även om vissa företag anser att patchhantering är mer ett IT-ansvar än ett säkerhetsansvar, måste patchhantering alltid vara en prioriterad fråga för säkerhetsavdelningarna eftersom den är avgörande för ett företags säkerhetsställning.

Om dina system fortfarande är sårbara idag finns det förmodligen några underliggande driftsproblem som bör åtgärdas. Shellshock är en mycket gammal sårbarhet med patchar som finns tillgängliga för nästan alla system. Det bästa sättet att skydda sig mot den här typen av sårbarhet är att hålla systemen uppdaterade och tillämpa alla rättelser som släppts för den här exploateringen.

När du patchar tillgångar, som vanligtvis är en enkel process, bör du anamma ett strategiskt tillvägagångssätt.

Patchar som testas grundligt är ett bra sätt att minimera påverkan på verksamheten – som till exempel en verksamhetskritisk server som kör ett gammalt operativsystem. Om ett system inte kan lappas omedelbart måste den potentiella risken med sårbarheten vägas mot affärspåverkan.

Shellshock är bara en i en lång lista av sårbarheter som företaget måste ta itu med. Att hantera den till synes oändliga strömmen av sårbarheter är och kommer alltid att vara en viktig strategi som ligger till grund för cybersäkerheten.

Checklista för en säker organisation

För en framgångsrik sårbarhetshantering måste företagen ha förmåga att lyckas inom dessa tre områden:

• Identifiera potentiellt påverkbara sårbarheter snabbt: Snabbhet är allt här. Att ha alla på samma sida med en solid plan bör främja snabbare reaktionstider.
• Fastställa sårbarhetens allvarlighetsgrad: Om du känner till din organisations risktolerans kommer du långt när det gäller att avgöra hur allvarlig en sårbarhet kan vara. Beroende på din nätverksinfrastruktur är vissa sårbarheter skadligare än andra.
• Att ha en handlingsplan som balanserar säkerhetens brådskande karaktär med potentiell påverkan på produktionsmiljöer: Att balansera säkerhet med produktion och produktivitet är ett ständigt hinder, men organisationer med de mest väldefinierade planerna för hantering av sårbarheter hittar vanligtvis den bästa balansen.

För den oberoende säkerhetsforskaren Rod Soto var den största lärdomen från Shellshock att internet bygger på många sårbara tillämpningar och att det alltid finns en potential för att kompromettera en stor del av segmenten.

”Sättet att hantera dessa potentiella sårbarheter i framtiden är att hålla kommunikationen öppen och transparent mellan utvecklare, underhållare och säkerhetspersonal”, säger Soto. ”Så om en sådan omfattande och betydande sårbarhet hittas kan samordning mellan alla berörda parter användas för att lappa eller mildra berörda system.”

Även i de fall ditt företag lyckas mildra risken för Shellshock eller någon annan sårbarhet kan du inte utgå från att din responsplan är perfekt. Svarsplanen bör vara ett levande dokument och bör ses över ofta så att din organisation snabbt kan reagera på hot.

Slutningsvis, precis som i alla scenarier efter en attack, finns det frågor som du bör ställa när du granskar varje fas i planen.

• Vilka delar av planen var framgångsrika?
• Vilka delar av planen var inte framgångsrika?
• Vad gjorde vi inte som vi nu inser att vi måste göra?
• Vad lärde vi oss som gör att vi kan vara bättre förberedda på nästa sårbarhet som kommer i vår väg?

Shellshock må vara ett gammalt angrepp, men för en angripare är det ett perfekt sätt att utnyttja offer som inte har en ordentlig säkerhetshygien.