Håller du Heartbleed i minnet? Om man tror på hypen idag är Shellshock i den ligan och med ett lika häftigt namn om än utan en cool logotyp (någon på marknadsföringsavdelningen för dessa vulner måste ta tag i det). Men allvarligt talat har det potential att bli en stor grej och precis som jag gjorde med Heartbleed ville jag sammanställa något definitivt, både för att jag själv ska kunna ta tag i situationen och för att andra ska kunna skilja hypen från den verkliga underliggande risken.
För att sätta scenen vill jag dela med mig av en del innehåll från Robert Grahams blogginlägg, som har gjort en utmärkt analys av detta. Föreställ dig en HTTP-förfrågan som denna:
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
Som, när den utfärdas mot en rad sårbara IP-adresser, resulterar i detta:
Som kort sagt har Robert just iscensatt ett gäng externa maskiner för att pinga honom helt enkelt genom att utfärda en omsorgsfullt utformad förfrågan via webben. Det som är riktigt oroväckande är att han i praktiken har fått dessa maskiner att utfärda ett godtyckligt kommando (även om det är en ganska godartad ping) och det öppnar en hel värld av mycket allvarliga möjligheter. Låt mig förklara.
Vad är Bash och varför behöver vi det?
Skipp det här om det är gamla nyheter, men sammanhanget är viktigt för dem som inte känner till Bash så låt oss skapa en grundläggande förståelse. Bash är ett *nix shell eller med andra ord en tolk som gör det möjligt för dig att styra kommandon på Unix- och Linuxsystem, vanligtvis genom att ansluta via SSH eller Telnet. Det kan också fungera som en analysator för CGI-skript på en webbserver som vi vanligtvis ser köras på Apache. Det har funnits sedan slutet av 80-talet då det utvecklades från tidigare skalimplementationer (namnet kommer från Bourne shell) och är enormt populärt. Det finns andra skal för Unix-varianter, men det bästa med Bash är att det är standardskalet för Linux och Mac OS X, som uppenbarligen är extremt vanliga operativsystem. Det är en viktig faktor till varför denna risk är så stor – Bash är allestädes närvarande – och det beskrivs som ”ett av de mest installerade verktygen på alla Linuxsystem”.
Du kan få en uppfattning om Bashs fotavtryck när du tittar på den senaste Netcraft-statistiken över webbservrar:
När halva nätet kör Apache (som vanligtvis finns på Linux), är det en betydande del av en mycket, mycket stor kaka. Samma Netcraft-artikel rapporterar att vi precis har passerat gränsen på en miljard webbplatser, och även om en hel del av dessa delar samma värdar är det fortfarande en hel del Bash-installationer. Åh – det är bara webbservrar också, glöm inte att det finns en massa andra servrar som kör Linux och vi kommer att återkomma till andra enheter med Bash lite senare också.
Bash kan användas för en hel rad typiska administrativa funktioner, allt från att konfigurera webbplatser till att styra inbäddad mjukvara på en enhet som en webbkamera. Naturligtvis är detta inte funktioner som är avsedda att vara öppna för hela världen och i teorin talar vi om autentiserade användare som utför kommandon som de har fått tillstånd att köra. I teorin.
Vad är felet?
Låt mig börja med CVE från NIST:s sårbarhetsdatabas, eftersom det ger en bra uppfattning om allvarlighetsgraden (min markering):
GNU Bash through 4.3 bearbetar efterföljande strängar efter funktionsdefinitioner i värdena för miljövariabler, vilket gör det möjligt för fjärrangripare att köra godtycklig kod via en manipulerad miljö, vilket demonstreras av vektorer som involverar ForceCommand-funktionen i OpenSSH sshd, modulerna mod_cgi och mod_cgid i Apache HTTP Server, skript som exekveras av ospecificerade DHCP-klienter och andra situationer där inställningen av miljön sker över en privilegiegräns från Bash-utförandet.
De fortsätter med att ge den en ”10 av 10” för allvarlighetsgrad eller med andra ord, så illa som det bara går. Detta förvärras av det faktum att det är lätt att utföra attacken (åtkomstkomplexiteten är låg) och kanske viktigast av allt är att det inte krävs någon autentisering när man utnyttjar Bash via CGI-skript. Sammanfattningen ovan är dock lite invecklad så låt oss koka ner den till felets mekanik.
Risken kretsar kring möjligheten att godtyckligt definiera miljövariabler inom ett Bash-skal som specificerar en funktionsdefinition. Problemet börjar när Bash fortsätter att bearbeta skalkommandon efter funktionsdefinitionen vilket resulterar i vad vi skulle klassificera som en ”kodinjektionsattack”. Vi tittar på Roberts exempel igen och tar bara den här raden:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Funktionsdefinitionen är () { :; }; och skalkommandot är ping-instruktionen och efterföljande parametrar. När detta bearbetas inom ramen för ett Bash-skal exekveras det godtyckliga kommandot. I ett webbkontext skulle detta innebära via en mekanism som ett CGI-skript och inte heller nödvändigtvis som en begäranhuvudrubrik. Det är värt att läsa igenom seclists.org advisory där de går in mer i detalj, inklusive att sökvägen och frågetecken kan vara potentiella vektorer för attacken.
Ett sätt att mildra den här specifika angreppsvektorn är förstås att helt enkelt inaktivera alla CGI-funktioner som anropar ett skal, och vissa rekommenderar faktiskt detta. I många fall kommer det dock att vara en allvarligt brytande förändring och åtminstone en som kommer att kräva omfattande tester för att säkerställa att den inte orsakar omedelbara problem på webbplatsen, vilket den i många fall kommer att göra.
HTTP-beviset ovan är ett enkelt men effektivt bevis, även om det bara är en implementering över ett gemensamt protokoll. När man börjar lägga till Telnet och SSH och tydligen även DHCP ökar räckvidden dramatiskt, så vi talar inte alls bara om att utnyttja webbapplikationsservrar här. (Tydligen finns risken bara i SSH efter autentisering, men i ett så tidigt skede av offentliggörandet kommer vi oundvikligen att få se andra angreppsvektorer dyka upp ännu.)
Vad man också måste komma ihåg är att omfattningen av den potentiella skadan sträcker sig långt bortom att pinga en godtycklig adress som i Roberts exempel, det är helt enkelt ett snyggt litet bevis på att han kunde iscensätta en maskin för att utfärda ett skalkommando. Frågan blir då följande: Vilka skador kan en angripare göra när de kan utföra ett valfritt skalkommando på vilken sårbar maskin som helst?
Vad är de potentiella konsekvenserna?
Potentialen är enorm – att ”få ett skalkommando” på en dator har alltid varit en stor vinst för en angripare på grund av den kontroll som det ger dem över målmiljön. Tillgång till interna data, omkonfigurering av miljöer, publicering av egen skadlig kod osv. Det är nästan gränslöst och det är också lätt att automatisera. Det finns många, många exempel på exploits där ute redan som lätt skulle kunna avfyras mot en stor mängd maskiner.
Tyvärr när det gäller exekvering av godtycklig kod i ett skal på upp till hälften av webbplatserna på Internet är potentialen ganska stor. En av de uppenbara (och särskilt otäcka) är att dumpa interna filer så att de kan hämtas av allmänheten. Lösenordsfiler och konfigurationsfiler med autentiseringsuppgifter är de uppenbara, men kan tänkas utsträckas till alla andra filer på systemet.
Samma tillvägagångssätt kan tillämpas för att skriva filer till systemet. Detta är potentiellt den enklaste vektor för defacement av webbplatser som vi någonsin sett, för att inte tala om ett mycket enkelt sätt att distribuera skadlig kod
Och vad sägs om det här: ett ord som jag ser ofta är ”mask”:
När vi pratar om mask i ett skadligt datorsammanhang, pratar vi om ett självreplikerande angrepp där en illasinnad aktör skapar kod som kan spridas över mål. Vi såg till exempel ett mycket effektivt genomförande av detta med Samy’s MySpace XSS-worm där en del noggrant utformad JavaScript lyckades ”infektera” en miljon offrens sidor på mindre än en dag.
Oroheten med Shellshock är att ett angrepp av den här karaktären skulle kunna replikera i en alarmerande takt, särskilt i ett tidigt skede medan majoriteten av maskinerna förblir i riskzonen. I teorin skulle detta kunna ske genom att en infekterad maskin söker efter andra mål och sprider attacken till dem. Detta skulle inte heller på något sätt vara begränsat till maskiner som är öppna för allmänheten; om man får in detta bakom företagets brandvägg så är himlen gränslös.
Människor arbetar på att utnyttja detta just nu. Det är detta som gör dessa tidiga dagar så intressanta då kapprustningen mellan de som försöker patcha och de som försöker attackera hettar upp.
Vilka versioner av Bash berörs?
I rubrikerna står det allt till och med 4.3, eller med andra ord, ungefär 25 års Bash-versioner. Med tanke på att alla fortsätter att jämföra detta med Heartbleed bör man betänka att de påverkade versionerna av OpenSSL sträckte sig över endast två år, vilket är en droppe i havet jämfört med Shellshock. Ja, folk uppgraderar sina versioner, men nej, de gör det inte konsekvent, och hur man än vrider och vänder på det kommer bredden av riskmaskiner att vara betydligt större med Shellshock än vad den var med Heartbleed.
Men risken kan mycket väl sträcka sig längre än till 4.3 också. Vi ser redan rapporter om att patchar inte är helt effektiva och med tanke på den hastighet med vilken de rullas ut är det inte så förvånande. Detta är den typ av sak som de som påverkas av det vill hålla ett mycket noggrant öga på, inte bara ”lappa och glömma”.
När fick vi först reda på det och hur länge har vi varit i riskzonen?
Det första omnämnandet som jag hittade i de offentliga etern var den här mycket korta sammanfattningen på seclists.org, som gjordes omkring klockan 14:00 GMT i onsdags (omkring midnatt i morse för oss som bor i östra delen av Australien). Detaljerna kom i det meddelande som jag nämnde tidigare en timme senare, så vi närmar oss mitten av onsdagseftermiddagen i Europa eller morgonen i USA. Det är fortfarande en mycket färsk nyhet med alla de vanliga spekulationerna i pressen och de vanliga förutsägelserna från Chicken Little; det är för tidigt att observera någon omfattande exploatering i det vilda, men det kan också komma mycket snart om risken lever upp till sin potential.
Skrolla tillbaka bortom det som har offentliggjorts och felet upptäcktes tydligen i förra veckan av Stéphane Chazelas, en ”Unix/Linux-, nätverks- och telekommunikationsspecialist” i Storbritannien. I Akamais inlägg om felet talar de dock om att det har funnits under ”en längre tid” och sårbara versioner av Bash har naturligtvis funnits två och ett halvt decennium tidigare. Frågan är, precis som med Heartbleed, om skadliga aktörer var medvetna om detta tidigare och om de aktivt utnyttjade det.
Infekteras våra ”saker”?
Det är här det blir intressant – vi har många ”saker” som potentiellt kan köra Bash. När jag använder denna term hänvisar jag naturligtvis till ”Internet of Things” (IoT) som är den ökande förekomsten av att sätta en IP-adress och en trådlös adapter i allt från våra bestick till våra dörrlås och våra ljusglober.
Många IoT-enheter kör inbäddade Linuxdistributioner med Bash. Samma enheter har redan visat sig uppvisa allvarliga säkerhetsbrister på andra områden, t.ex. har LIFX-ljusglober för bara ett par månader sedan visat sig läcka wifi-informationer. Även om det inte är en Bash-sårbarhet som Shellshock visar det oss att vi genom att koppla ihop våra saker går in i en helt ny värld av sårbarheter på ställen som aldrig tidigare varit i riskzonen.
Redigera: Några personer har hänvisat till förekomsten av BusyBox som kör Ash-skalet på mobila enheter. Enheter som kör detta verkar inte vara i riskzonen för Shellshock. Svårigheten för en konsument är att de inte vet vad som körs på deras enheter, och det gäller även mer traditionella ”saker” som routrar. Den långa historiken för denna bugg innebär att vi har mer än ett par decennier av enheter där ute som har gått igenom olika evolutioner av olika inbäddade operativsystem och vi har nu ett mycket varierat landskap av maskiner och shells som sträcker sig över en lång tidsperiod.
Detta för med sig många nya utmaningar; till exempel, vem tänker aktivt på att de regelbundet bör lappa sina glödlampor? Tänk också på livslängden hos de enheter som denna programvara dyker upp i och om de faktiskt underhålls aktivt. I ett fall som de sårbara Trendnet-kamerorna för ett par år sedan finns det utan tvekan ett stort antal av dem som fortfarande finns på webben, för när det gäller patching är de i stort sett en ”ställ in och glömma”-lösning. I det fallet finns det faktiskt ett helt Twitter-konto som ägnar sig åt att sända ut bilder som det har tagit på intet ont anande ägare av sårbara versioner. Det är ett stort problem utan några enkla lösningar och det kommer att följa oss under mycket lång tid.
Men Bash-shells finns också i många mer vanliga enheter, t.ex. i våra hemroutrar som i allmänhet har kontakt med Internet. Kommer du ihåg när du senast lappade den fasta programvaran på din router? Ok, om du läser det här så kanske du är den typ av teknisk person som faktiskt patchar sin router, men sätt dig i den vanliga konsumentens skor och fråga dig själv det igen. Exakt.
Alla våra saker är på Microsofts stack, är vi i riskzonen?
Kort svar ”nej”, långt svar ”ja”. Jag tar itu med det enkla först – Bash finns inte naturligt i Windows och även om det finns Bash-implementationer för Windows, är det verkligen inte vanligt och det kommer inte att finnas på konsumentdatorer. Det är inte heller klart om produkter som win-bash överhuvudtaget är sårbara för Shellshock.
Det längre svaret är att bara för att du arbetar i en övervägande Microsoft-centrerad miljö betyder det inte att du inte har Bash som körs på maskiner som tjänar andra diskreta syften inom den miljön. När jag skrev om Heartbleed hänvisade jag till Nick Cravers inlägg om att flytta Stack Overflow till SSL och hänvisade till det här diagrammet över deras infrastruktur:
Det finns icke-Microsoft-komponenter som sitter framför deras Microsoft-applikationsstack, komponenter som trafiken måste passera innan den når webbservrarna. Dessa är också komponenter som kan ha förhöjda privilegier bakom brandväggen – vilka konsekvenser får det om Shellshock utnyttjas på dessa? Den kan vara betydande och det är det jag menar här; Shellshock har potential att påverka tillgångar utöver riskfyllda Bash-implementationer när den finns i ett bredare ekosystem av andra maskiner.
Jag är systemadministratör – vad kan jag göra?
För det första är det trivialt att ta reda på om man löper en risk, eftersom det är en sådan lätt reproducerbar risk. Det finns ett mycket enkelt test som The Register föreslår som bara är att köra det här kommandot i ditt skal:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Du får ”busted” echo’d tillbaka ut och du har framgångsrikt utnyttjat felet.
Självklart är prioriteringen här kommer att vara att lappa på risk system och patchen i huvudsak kokar ner till att se till att ingen kod kan exekveras efter slutet av en Bash-funktion. Linuxdistributioner som Red Hat ger ut vägledning om hur man patchar riskerna, så det bör prioriteras.
Vi kommer oundvikligen också att få se definitioner för intrångsdetekteringssystem också och det kommer säkert att finnas gemensamma mönster att leta efter här. Det kan mycket väl visa sig vara ett bra genomförande på kort sikt för många organisationer, särskilt där det kan finnas betungande testkrav innan patchar rullas ut till risksystem. Qualys’ siktar på att ha en definition för att upptäcka attacken ganska snabbt och oundvikligen arbetar andra IDS-leverantörer också med detta dygnet runt.
Andra mer drastiska alternativ inkluderar att ersätta Bash med en alternativ skalimplementation eller att spärra av risksystem, vilket båda skulle kunna få långtgående konsekvenser och är osannolikt att besluten tas lättvindigt. Men det kommer förmodligen att vara det som detta fel innebär för många människor – svåra beslut som kan få påtagliga affärseffekter för att undvika potentiellt mycket större konsekvenser.
Den andra frågan som nu kommer att börja dyka upp ofta är frågan om huruvida Shellshock redan har utnyttjats i en miljö. Detta kan vara svårt att avgöra om det inte finns någon loggning av angreppsvektorerna (det gör det ofta inte om de överförs via HTTP-förfrågningshuvudet eller POST-kroppen), men det är mer troligt att det fångas upp än i fallet med Heartbleed, då hjärtfrekvensens nyttoladdningar normalt sett inte skulle ha loggats någonstans, med undantag för fullständiga pcaps. Men ändå kommer det vanligaste svaret på frågan ”blev vi attackerade via Shellshock” att bli följande:
Det är tyvärr inte ”Nej, vi har bevis för att det inte förekom några kompromisser”, utan snarare ”vi har inga bevis som sträcker sig över sårbarhetens hela livstid”. Vi tvivlar på att många har det – och detta lämnar systemägare i den obekväma positionen att de inte vet vilka eventuella kompromisser som kan ha inträffat.
Låt spekulationerna om huruvida NSA var inblandad i detta börja…
Jag är konsument – vad kan jag göra?
Det beror på. Shellshock påverkar Macs så om du kör OS X verkar det i detta skede vara i riskzonen, vilket å ena sidan är dåligt på grund av OS X:s utbredning, men å andra sidan kommer det att vara lätt (och förhoppningsvis snabbt) att åtgärda på grund av en ganska väl beprövad uppdateringsmekanism (dvs. Apple kan fjärrstyra uppdateringar till maskinen).
Om du har en Mac är risken lätt att testa enligt detta svar från Stack Exchange:
Det är ett enkelt test, även om jag tvivlar på att den genomsnittlige Mac-användaren kommer att känna sig bekväm med att gå igenom den föreslagna lösningen, som innebär att man måste kompilera Bash på nytt.
Det större orosmomentet är de enheter som inte har någon enkel patchningsväg, till exempel din router. Om man inte kan kolla på tillverkarens webbplats för att få uppdaterad firmware kommer detta att vara en riktigt svår nöt att knäcka. Ofta är routrar som tillhandahålls av internetleverantörer låsta så att konsumenterna inte slumpmässigt ändrar vare sig konfigurationen eller den fasta programvaran, och det finns inte alltid en uppgraderingsväg på distans som de kan aktivera heller. Kombinera detta med det enorma utbudet av enheter och åldrar som finns där ute och detta kan bli särskilt svårt. Naturligtvis är det inte heller något som den genomsnittlige konsumenten kommer att känna sig bekväm med att göra själv.
Kort sagt, rådet till konsumenterna är följande: håll utkik efter säkerhetsuppdateringar, särskilt för OS X. Håll också ett öga på alla råd du kan få från din internetleverantör eller andra leverantörer av enheter du har som kör inbyggd programvara. Var försiktig med e-postmeddelanden där du begär information eller uppmanas att köra programvara – sådana händelser följs ofta av nätfiskeattacker som utnyttjar konsumenternas rädsla. I dagsläget får bluffakturor människor att stoppa sina iPhones i mikrovågsugnen, så tro inte för ett ögonblick att de inte kommer att köra ett slumpmässigt program som skickas till dem via e-post som en ”fix” för Shellshock!
Sammanfattning
Vi har med all sannolikhet inte ens börjat förstå hur omfattande den här sårbarheten är. Naturligtvis görs många jämförelser med Heartbleed och det finns ett antal saker som vi lärde oss av den övningen. En är att det tog lite tid att sjunka in när vi insåg i vilken utsträckning vi var beroende av OpenSSL. Den andra är att den hade en mycket lång svans – månader efter att den slog till fanns det fortfarande hundratusentals kända värdar som var sårbara.
Men på ett sätt är Heartbleed-jämförelsen inte rättvis – den här är potentiellt mycket värre. Heartbleed gav fjärråtkomst till små datamängder i minnet på de drabbade maskinerna. Shellshock möjliggör fjärrkodinjektion av godtyckliga kommandon före autentisering, vilket är potentiellt mycket värre. I det avseendet måste jag hålla med Robert:
Det är mycket, mycket tidigt ännu – i skrivande stund har det bara gått en halv dag sedan det först kom ut i etern – och jag misstänker att vi än så länge bara skrapar på ytan av vad som kommer att hända.
Säkerhet