Huskede du Heartbleed? Hvis man skal tro på hypen i dag, er Shellshock i den liga og med et lige så fantastisk navn, om end det er uden et fedt logo (nogen i marketingafdelingen for disse vulner skal tage sig af det). Men i al alvor har det potentiale til at blive en biggie, og som jeg gjorde med Heartbleed, ønskede jeg at sammensætte noget definitivt både for mig at få styr på situationen og for andre at dissekere hypen fra den sande underliggende risiko.
For at sætte scenen, lad mig dele noget indhold fra Robert Grahams blogindlæg, der har lavet nogle fremragende analyser på dette. Forestil dig en HTTP-forespørgsel som denne:
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 udstedes mod en række sårbare IP-adresser, resulterer i dette:
Sammenfattende sagt har Robert lige orkestreret en masse eksterne maskiner til at pinge ham, blot ved at udsende en omhyggeligt udformet forespørgsel over nettet. Det virkelig foruroligende er, at han effektivt har fået disse maskiner til at udsende en vilkårlig kommando (om end en ret godartet ping), og det åbner en hel verden af meget alvorlige muligheder. Lad mig forklare.
Hvad er Bash, og hvorfor har vi brug for det?
Skip dette, hvis det er gamle nyheder, men konteksten er vigtig for dem, der ikke er bekendt med Bash, så lad os etablere en grundlæggende forståelse. Bash er en *nix shell eller med andre ord en fortolker, der giver dig mulighed for at orkestrere kommandoer på Unix- og Linux-systemer, typisk ved at oprette forbindelse via SSH eller Telnet. Den kan også fungere som en parser for CGI-scripts på en webserver, sådan som vi typisk ser dem køre på Apache. Den har eksisteret siden slutningen af 80’erne, hvor den udviklede sig fra tidligere shell-implementationer (navnet er afledt af Bourne-shell) og er enormt populær. Der findes andre shells til Unix-varianter, men sagen med Bash er dog, at det er standard-shell til Linux og Mac OS X, som naturligvis er ekstremt udbredte styresystemer. Det er en vigtig faktor for, at denne risiko er så betydelig – Bash’ allestedsnærværelse – og det beskrives som “et af de mest installerede hjælpeprogrammer på ethvert Linux-system”.
Du kan få en fornemmelse af Bash’ fodaftryk, når du ser på den seneste Netcraft-statistik over webservere:
Når halvdelen af nettet kører Apache (som typisk findes på Linux), er det en betydelig størrelse af en meget, meget stor kage. Den samme Netcraft-artikel rapporterer, at vi også lige har passeret grænsen på en milliard websteder, og selv om en stor del af disse deler de samme værter, er det stadig en hel masse Bash-installationer. Åh – det er også kun webservere, glem ikke, at der er en masse andre servere, der kører Linux, og vi kommer også tilbage til andre enheder med Bash lidt senere.
Bash kan bruges til en lang række typiske administrative funktioner, alt fra konfiguration af websteder til styring af indlejret software på en enhed som f.eks. et webcam. Det er naturligvis ikke en funktionalitet, der er beregnet til at være åben for hele verden, og i teorien taler vi om autentificerede brugere, der udfører kommandoer, som de har fået tilladelse til at køre. I teorien.
Hvad er fejlen?
Lad mig starte med CVE’en fra NIST’s sårbarhedsdatabase, fordi den giver en god fornemmelse af alvorligheden (fremhævning fra mig):
GNU Bash gennem 4.3 behandler efterfølgende strenge efter funktionsdefinitioner i værdierne for miljøvariabler, hvilket gør det muligt for fjernangribere at udføre vilkårlig kode via et fabrikeret miljø, som demonstreret af vektorer, der involverer ForceCommand-funktionen i OpenSSH sshd, mod_cgi- og mod_cgid-modulerne i Apache HTTP Server, scripts, der udføres af uspecificerede DHCP-klienter, og andre situationer, hvor indstilling af miljøet sker på tværs af en rettighedsgrænse fra Bash-eksekvering.
De fortsætter med at vurdere den til “10 ud af 10” for alvorlighed eller med andre ord, så slemt som det kan blive. Dette forværres af, at det er let at udføre angrebet (adgangskompleksiteten er lav) og måske mest betydningsfuldt, at der ikke kræves nogen autentificering, når Bash udnyttes via CGI-scripts. Ovenstående resumé er dog lidt indviklet, så lad os koge det ned til fejlens mekanik.
Risikoen er centreret omkring muligheden for vilkårligt at definere miljøvariabler inden for en Bash-shell, som specificerer en funktionsdefinition. Problemet begynder, når Bash fortsætter med at behandle shell-kommandoer efter funktionsdefinitionen, hvilket resulterer i, hvad vi vil klassificere som et “kodeinjektionsangreb”. Lad os se på Roberts eksempel igen, og vi tager blot denne linje:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Funktionsdefinitionen er () { :; };; og shell-kommandoen er ping-erklæringen og de efterfølgende parametre. Når dette behandles inden for rammerne af en Bash-shell, udføres den vilkårlige kommando. I en webkontekst ville det betyde via en mekanisme som f.eks. et CGI-script og heller ikke nødvendigvis som en request header. Det er værd at læse seclists.org advisory, hvor de går mere i detaljer, herunder at stien og forespørgselsstrengen kan være potentielle vektorer for angrebet.
En måde at afbøde denne særlige angrebsvektor på er naturligvis blot at deaktivere enhver CGI-funktionalitet, der foretager opkald til en shell, og det er der faktisk nogle, der anbefaler. I mange tilfælde vil det dog være en alvorligt ødelæggende ændring og i det mindste en ændring, der vil kræve omfattende testning for at sikre, at den ikke forårsager umiddelbare problemer på webstedet, hvilket den i mange tilfælde vil gøre.
HT HTTP-beviset ovenfor er et simpelt, men effektivt bevis, selv om det kun er en implementering over en fælles protokol. Når du begynder at smide Telnet og SSH og tilsyneladende endda DHCP ind, øges omfanget dramatisk, så vi taler på ingen måde kun om udnyttelse af webapp-servere her. (Tilsyneladende er risikoen kun til stede i SSH post-auth, men på et så tidligt stadie af den offentlige afsløring vil vi uundgåeligt se andre angrebsvektorer dukke op endnu.)
Hvad du også skal huske er, at omfanget af potentiel skade strækker sig langt ud over at pinge en vilkårlig adresse som i Roberts eksempel, det er simpelthen et pænt lille bevis på, at han kunne orkestrere en maskine til at udsende en shell-kommando. Spørgsmålet bliver dette:
Hvad er de potentielle konsekvenser?
Potentialet er enormt – at “få shell” på en boks har altid været en stor gevinst for en angriber på grund af den kontrol, det giver dem over målmiljøet. Adgang til interne data, rekonfiguration af miljøer, offentliggørelse af deres egen skadelige kode osv. Det er næsten ubegrænset, og det kan også let automatiseres. Der findes allerede mange, mange eksempler på exploits derude, som nemt kan affyres mod en stor mængde maskiner.
Dårligt nok er potentialet ret bredt, når det gælder udførelse af vilkårlig kode i en shell på op til halvdelen af webstederne på internettet, når det gælder udførelse af vilkårlig kode i en shell på op til halvdelen af webstederne på internettet. En af de indlysende (og særligt ubehagelige) er at dumpe interne filer til offentlig hentning. Adgangskodefiler og konfigurationsfiler med legitimationsoplysninger er de oplagte, men kunne tænkes at blive udvidet til alle andre filer på systemet.
Det samme kunne ligeledes anvendes til at skrive filer til systemet. Dette er potentielt den nemmeste vektor til defacement af websteder, vi nogensinde har set, for ikke at nævne en meget nem måde at distribuere malware på
Og hvad med dette: Et ord, jeg bliver ved med at se meget, er “orm”:
Når vi taler om orm i en ondsindet computerkontekst, taler vi om et selvreplikerende angreb, hvor en ondsindet aktør skaber kode, der er i stand til at sprede sig på tværs af mål. Vi så f.eks. en meget effektiv gennemførelse af dette med Samy’s MySpace XSS-worm, hvor det lykkedes nogle omhyggeligt udformede JavaScript-sider at “inficere” en million ofres sider på mindre end et døgn.
Sorgensen med Shellshock er, at et angreb af denne art kan replikere sig med en alarmerende hastighed, især tidligt, mens størstedelen af maskinerne fortsat er i fare. I teorien kunne det ske ved, at en inficeret maskine scanner efter andre mål og spreder angrebet til dem. Dette ville heller ikke på nogen måde være begrænset til offentligt tilgængelige maskiner; hvis man får dette bag virksomhedens firewall, er der ingen grænser.
Der arbejdes på at udnytte dette lige nu. Det er det, der gør disse tidlige dage så interessante, da våbenkapløbet mellem dem, der kæmper for at patche, og dem, der kæmper for at angribe, bliver stadig mere intenst.
Hvilke versioner af Bash er berørt?
I overskrifterne står der alt til og med 4.3 eller med andre ord, omkring 25 års Bash-versioner. Eftersom alle bliver ved med at sammenligne dette med Heartbleed, skal man tænke på, at de berørte versioner af OpenSSL strakte sig over blot to år, hvilket er en dråbe i havet sammenlignet med Shellshock. Ja, folk opgraderer deres versioner, men nej, de gør det ikke konsekvent, og uanset hvordan man ser på det, vil bredden af risikomaskiner være betydeligt større med Shellshock, end den var med Heartbleed.
Men risikoen kan meget vel også strække sig ud over 4.3. Vi ser allerede nu rapporter om patches, der ikke er helt effektive, og i betragtning af den hastighed, hvormed de bliver udrullet, er det ikke så overraskende. Det er den slags ting, som de, der er berørt af det, ønsker at holde et meget nøje øje med, ikke bare “patch and forget”.
Hvornår fik vi først kendskab til det, og hvor længe har vi været i fare?
Den første omtale, jeg har fundet i de offentlige æteren, var dette meget korte resumé på seclists.org, som virker omkring 14:00 GMT i onsdags (omkring midnat i morges for os i den østlige del af Australien). Detaljerne kom i den tidligere nævnte meddelelse en time senere, så vi nærmer os midt på eftermiddagen onsdag i Europa eller morgenen i USA. Det er stadig en meget frisk nyhed med alle de sædvanlige pressespekulationer og Chicken Little-forudsigelser; det er for tidligt at observere nogen udbredt udnyttelse i naturen, men det kan også komme meget snart, hvis risikoen lever op til sit potentiale.
Rul tilbage ud over det, der er blevet offentliggjort, og fejlen blev tilsyneladende opdaget i sidste uge af Stéphane Chazelas, en “Unix/Linux-, netværks- og telekommunikationsspecialist” fyr i Storbritannien. Når det er sagt, så taler de i Akamais indlæg om fejlen om, at den har været til stede i “en længere periode”, og sårbare versioner af Bash går naturligvis to og et halvt årti tilbage i tiden. Spørgsmålet vil, ligesom med Heartbleed, være, om ondsindede aktører var klar over dette før nu, og om de faktisk aktivt udnyttede det.
Er vores “ting” påvirket?
Det er her, det bliver interessant – vi har en masse “ting”, der potentielt kører Bash. Når jeg bruger dette udtryk, refererer jeg naturligvis til “Internet of Things” (IoT), som er den stigende udbredelse af at smække en IP-adresse og en trådløs adapter ind i alt fra vores bestik til vores dørlåse og vores lyskugler.
Mange IoT-enheder kører indlejrede Linux-distributioner med Bash. De samme enheder har allerede vist sig at udvise alvorlige sikkerhedssårbarheder på andre områder, f.eks. blev LIFX-lyskugler for blot et par måneder siden afsløret i at lække wifi-credentialer. Selv om det ikke er en Bash-sårbarhed som Shellshock, viser det os, at vi ved at forbinde vores ting kommer ind i en helt ny verden af sårbarheder på steder, der aldrig har været i fare før.
Rediger: Et par personer har henvist til forekomsten af BusyBox, der kører Ash-shell på mobile enheder. Enheder, der kører dette, ser ikke ud til at være i risiko for Shellshock. Vanskeligheden for en forbruger er, at de ikke ved, hvad der kører på deres enheder, og det omfatter også mere traditionelle “ting” som routere. Den lange historie med denne fejl betyder, at vi har mere end et par årtier med enheder derude, som har gennemgået forskellige udviklinger af forskellige indlejrede OS, og vi har nu et meget varieret landskab af maskiner og shells, der spænder over en lang periode.
Dette medfører mange nye udfordringer; for eksempel, hvem tænker aktivt på, at de regelmæssigt skal patche deres pærer? Tænk også på levetiden af de enheder, som denne software optræder i, og om de faktisk bliver aktivt vedligeholdt. I et tilfælde som de sårbare Trendnet-kameraer fra et par år siden er der utvivlsomt et stort antal af dem, der stadig ligger på nettet, for med hensyn til patching er de stort set et “sæt og glem” forslag. I det tilfælde er der faktisk en hel Twitter-konto, der er dedikeret til at udsende de billeder, som den har optaget af intetanende ejere af sårbare versioner. Det er et stort problem uden nogen nemme løsninger, og det vil følge os i meget lang tid.
Men Bash-shells er også til stede i mange mere almindelige enheder, f.eks. vores routere i hjemmet, som generelt er internetvendte. Kan du huske, da du sidst patchede firmwaren på din router? Ok, hvis du læser dette, så er du måske den type teknisk person, der rent faktisk patcher sin router, men sæt dig selv i den almindelige forbrugers sted og spørg dig selv om det igen. Præcis.
Alle vores ting er på Microsoft-stacken, er vi i fare?
Kort svar: “Nej”, langt svar: “Ja”. Jeg tager fat på det nemme først – Bash findes ikke nativt på Windows, og selv om der findes Bash-implementeringer til Windows, er det bestemt ikke almindeligt, og det vil ikke blive fundet på forbruger-pc’er. Det er heller ikke klart, om produkter som win-bash overhovedet er sårbare over for Shellshock.
Det længere svar er, at bare fordi man opererer i et overvejende Microsoft-centreret miljø, betyder det ikke, at man ikke har Bash kørende på maskiner, der tjener andre diskrete formål i dette miljø. Da jeg skrev om Heartbleed, henviste jeg til Nick Cravers indlæg om at flytte Stack Overflow mod SSL og henviste til dette diagram over deres infrastruktur:
Der er ikke-Microsoft-komponenter, der sidder foran deres Microsoft-applikationsstack, komponenter, som trafikken skal passere, før den rammer webservere. Det er også komponenter, der kan have forhøjede privilegier bag firewallen – hvad er virkningen, hvis Shellshock udnyttes på disse? Det kunne være betydeligt, og det er det, jeg vil sige her; Shellshock har potentiale til at påvirke aktiver ud over de udsatte Bash-implementationer, når det findes i et bredere økosystem af andre maskiner.
Jeg er systemadministrator – hvad kan jeg gøre?
For det første er det trivielt at finde ud af, om du er udsat for risiko, da det er en så let reproducerbar risiko. Der er en meget simpel test The Register foreslår, som bare kører denne kommando i din shell:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Du bliver “busted” echo’d tilbage ud og du har med succes udnyttet fejlen.
Selvfølgelig er prioriteringen her vil være at lappe på risikosystemer og patch væsentlige koger ned til at sikre ingen kode kan udføres efter afslutningen af en Bash-funktion. Linux-distributioner som Red Hat frigiver vejledning om patching af risikoen, så hop på det som en prioritet.
Vi vil uundgåeligt også se definitioner for intrusion detection systemer også, og der vil helt sikkert være fælles mønstre at kigge efter her. Det kan meget vel vise sig at være en god implementering på kort sigt for mange organisationer, især hvor der kan være tunge testkrav, før patches til risikosystemer rulles ud. Qualys’ sigter mod at have en definition til at opdage angrebet ret hurtigt, og det er uundgåeligt, at andre IDS-leverandører også arbejder på dette døgnet rundt.
Andre mere drastiske muligheder omfatter udskiftning af Bash med en alternativ shell-implementering eller afspærring af risikosystemer, som begge kan have vidtrækkende konsekvenser og er næppe beslutninger, der skal tages let. Men det vil sandsynligvis være karakteren af denne fejl for mange mennesker – svære beslutninger, der kan have håndgribelige forretningsmæssige konsekvenser for at undgå potentielt meget mere betydelige konsekvenser.
Det andet spørgsmål, der nu vil begynde at komme meget op, er spørgsmålet om, hvorvidt Shellshock allerede er blevet udnyttet i et miljø. Det kan være svært at afgøre, hvis der ikke er nogen logning af angrebsvektorerne (det vil der ofte ikke være, hvis det overføres via HTTP request header eller POST body), men det er mere sandsynligt, at det bliver fanget end med Heartbleed, da hjerteslagspayloads, med undtagelse af fuld pcaps, normalt ikke ville være blevet logget nogen steder. Men stadigvæk vil det mest almindelige svar på “blev vi angrebet via Shellshock” være dette:
Det er desværre ikke “Nej, vi har beviser for, at der ikke var nogen kompromitteringer;” snarere “vi har ikke beviser, der spænder over levetiden for denne sårbarhed”. Vi tvivler på, at mange har det – og det efterlader systemejere i den ubehagelige situation, at de ikke ved, hvilke kompromitteringer der eventuelt er sket.
Lad spekulationerne om, hvorvidt NSA var med i sagen, begynde…
Jeg er forbruger – hvad kan jeg gøre?
Det kommer an på. Shellshock påvirker Macs, så hvis du kører OS X, ser det på nuværende tidspunkt ud til at være i fare, hvilket på den ene side er dårligt på grund af udbredelsen af OS X, men på den anden side vil det være nemt (og forhåbentlig hurtigt) at afhjælpe på grund af en ret velafprøvet opdateringsmekanisme (dvs. Apple kan fjernstyre opdateringer til maskinen).
Hvis du er på en Mac, kan risikoen let testes som beskrevet i dette Stack Exchange-svar:
Det er en nem test, selv om jeg tvivler på, at den gennemsnitlige Mac-bruger vil føle sig tryg ved at gå igennem den foreslåede rettelse, som indebærer genkompilering af Bash.
Den større bekymring er de enheder, der ikke har nogen nem patchingvej, f.eks. din router. Medmindre du tjekker producentens websted for opdateret firmware, bliver dette en rigtig svær nød at knække. Ofte er routere, der leveres af internetudbydere, låst ned, så forbrugerne ikke tilfældigt ændrer hverken konfigurationen eller firmwaren, og der er ikke altid en fjernopgraderingsvej, som de kan udløse enten. Kombiner det med det enorme udvalg af enheder og aldre, der findes, og det kan blive særdeles vanskeligt. Det er naturligvis heller ikke den slags ting, som den gennemsnitlige forbruger vil være tryg ved at gøre selv.
Kort sagt er rådet til forbrugerne følgende: Hold øje med sikkerhedsopdateringer, især på OS X. Hold også øje med de råd, du måtte få fra din internetudbyder eller andre udbydere af enheder, du har, som kører indlejret software. Vær forsigtig med e-mails, der anmoder om oplysninger eller beder dig om at køre software – sådanne hændelser bliver ofte efterfulgt af phishing-angreb, der udnytter forbrugernes frygt. Fupnumre får i øjeblikket folk til at lægge deres iPhones i mikrobølgeovnen, så tro ikke et øjeblik, at de ikke vil køre et tilfældigt stykke software, der sendes til dem via e-mail som et “fix” for Shellshock!
Summary
Sandsynligvis har vi ikke engang begyndt at fatte bredden af denne sårbarhed. Der bliver naturligvis lavet mange sammenligninger med Heartbleed, og der er en række ting, som vi lærte af den øvelse. Den ene er, at det tog lidt tid at synke ind, da det gik op for os, i hvor høj grad vi var afhængige af OpenSSL. Den anden er, at den havde en meget lang hale – måneder efter, at den ramte, var der stadig hundredtusindvis af kendte værter, der stadig var sårbare.
Men på en måde er Heartbleed-sammenligningen ikke retfærdig – dette er potentielt langt værre. Heartbleed gav fjernadgang til små datamængder i hukommelsen på de berørte maskiner. Shellshock giver mulighed for fjernkodeinjektion af vilkårlige kommandoer før autentificering, hvilket potentielt er langt værre. I den henseende må jeg give Robert ret:
Det er meget, meget tidligt endnu – det er kun en halv dag siden, at det først kom i luften i skrivende stund – og jeg formoder, at vi indtil videre kun skraber på overfladen af, hvad der endnu er på vej.
Sikkerhed