Bashdoor (även engelska Shellshock [1] ) är en serie sårbarheter i mjukvara som upptäcktes i GNU Bash- programmet i september 2014 och släpptes offentligt den 24 september [2] . Många internettjänster , inklusive webbservrar , kan använda Bash för att bearbeta vissa förfrågningar, till exempel vid exekvering av CGI- skript. Sårbarheten tillåter en angripare att utföra godtyckliga kommandon och få obehörig åtkomst till datorsystem [3] .
Sårbarheterna ligger i det faktum att Bash, i motsats till de deklarerade kapaciteterna, exekverar kommandon när den tar emot vissa icke-standardiserade värden av miljövariabler ( miljö ) [1] [4] . Några dagar efter publiceringen av den ursprungliga sårbarheten upptäcktes flera liknande buggar, vilket förhindrade lanseringen av en korrigerad version snabbt.
Det ursprungliga felet upptäcktes av Stéphane Chazelas [1] ( franska Stéphane Chazelas ) den 12 september 2014 [1] , som föreslog att man skulle kalla det "bashdoor" (konsonant med bakdörr ) [1] . Sårbarheten fick numret CVE-2014-6271 i MITER -databasen och förblev opublicerad ( förbjöds med embargo ) fram till 14:00 UTC den 24 september, så att författarna till programmet, skaparna av distributioner och andra intresserade organisationer kunde ta det nödvändiga åtgärder [5] .
En analys av Bash-källkoden indikerar att sårbarheten introducerades i koden runt version 1.13 1992 eller tidigare [6] och har förblivit oupptäckt för allmänheten och odeklarerad sedan [4] . Bashs författarteam har svårt att bestämma den exakta tidpunkten då buggen introducerades på grund av otillräckligt detaljerad ändringslogg ( changelog ) [1] .
Den 25 september 2014, baserat på sårbarheten, skapades redan botnät för att utföra DoS- och DDoS- attacker, samt för att skanna sårbarheter [7] [8] . Det uppskattas att miljontals system är sårbara. Buggen fick högsta betyg på allvarlighetsskalan och jämförs i värde med Heartbleed - en bugg i OpenSSL (april 2014) [9] [10] .
Shellshock-sårbarheten (bashdoor) hänvisar till bash- programmet (utvecklat av GNU-projektet ) som används i många Unix -liknande operativsystem och distributioner som en kommandoradstolk och för att köra skalskript. Ofta inställd som standardsystemtolk.
På Unix-liknande och andra bash-stödda operativsystem har varje program en lista med namn- värdepar som kallas miljövariabler . När ett program startar ett annat skickas även den initiala listan med miljövariabler [11] . Förutom miljövariabler upprätthåller bash även en intern lista med funktioner, namngivna skript som kan anropas från ett körbart bash-skript [12] . När du startar nya bash-instanser från en befintlig bash är det möjligt att skicka ( exportera ) värdena för befintliga miljövariabler och funktionsdefinitioner till den skapade processen [13] . Funktionsdefinitioner exporteras genom att koda dem som nya miljövariabler av ett speciellt format, som börjar med tomma parenteser "()" följt av funktionsdefinitionen som en sträng. Nya instanser av bash skannar alla miljövariabler vid start, detekterar det givna formatet och konverterar det tillbaka till en intern funktionsdefinition [14] . Denna transformation görs genom att skapa ett bash-kodfragment baserat på värdet av miljövariabeln och exekvera det, det vill säga "on-the-fly". Berörda versioner av bash kontrollerar inte att den körbara filen endast innehåller en funktionsdefinition [14] . Således, om en angripare har förmågan att tillhandahålla en godtycklig miljövariabel till bash-starten, blir det möjligt att utföra godtyckliga kommandon.
Den 27 september publicerades en kvalitetspatch som lägger till ett speciellt prefix till alla exporterade och importerade funktioner när de konverteras till miljövariabler och vice versa [15] .
Samma dag som informationen om den ursprungliga sårbarheten och patchar som fixar den publicerades upptäckte Tavis Ormandy en ny relaterad bugg CVE-2014-7169 [3] . Uppdaterade korrigeringar blev tillgängliga den 26 september [3] [16] [17] [18] [19] [20] .
Under arbetet med att fixa den ursprungliga Shellshock-buggen upptäckte Red Hat-forskaren Florian Weimer ytterligare två buggar: CVE-2014-7186 och CVE-2014-7187 [21] [22] .
Den 26 september 2014 märkte två utvecklare med öppen källkod, David A. Wheeler och Norihiro Tanaka att det fanns ytterligare problem som fortfarande inte åtgärdades av de patchar som var tillgängliga vid den tiden. I sitt mejl till e-postlistorna "oss-sec" och "bash bug" skrev Wheeler:
Den här patchen fortsätter bara "kill the mole" ( whac-a-mole ) [23] -arbetet för att fixa olika analysbuggar som startade med den första patchen. Bash-parsern innehåller naturligtvis många många andra sårbarheter.
Originaltext (engelska)[ visaDölj] Den här patchen fortsätter bara "whack-a-mole"-jobbet att fixa parsningsfel som började med den första patchen. Bashs parser är säker på att ha många många andra sårbarheter — [24]Den 27 september 2014 meddelade Michal Zalewski att han hade upptäckt flera andra buggar i bash [25] [26] , varav en utnyttjar det faktum att bash ofta kompileras utan att använda skyddstekniken ASLR ( Address Space Layout Randomization ) [27 ] . Zalewski efterlyste också en brådskande patch från Florian Weimer [25] [26] [27] .
Den ursprungliga bashdoor: En speciell typ av miljövariabel består av definitionen av en exporterad funktion följt av godtyckliga kommandon. Sårbara versioner av Bash exekverar dessa godtyckliga kommandon under uppstart [28] . Exempel på fel:
env x = '() { :;}; echo Vulnerable' bash -c "echo Test print"På sårbara system kommer detta test att skriva ut frasen "Sårbar" genom att utföra kommandot från miljövariabeln x [29] .
Den 29 september offentliggjordes inte detaljerna om sårbarheten [25] [27] [30] .
Den 29 september offentliggjordes inte detaljerna om sårbarheten [25] [31] .
Upptäckt av Tavis Ormandy när han arbetade på CVE-2014-6271 :
env X='() { (a)=>\' sh -c "echo date"; cat echo
Testet gör att "eko" blir filnamnet för omdirigering av utdata och att "datum" exekveras. Felet fick numret CVE-2014-7169 [3] .
Ett exempel på fel 7169 på ett system som fick en fix för felet CVE-2014-6271 men inte felet CVE-2014-7169 [32] $ X = '() { (a)=>\' bash -c "echo date" bash: X: rad 1 : syntaxfel nära oväntat token ` = ' bash: X: rad 1: `' bash: fel vid importfunktion definition för ` X ' [ root@ ec2-användare ] # cat echo fre 26 sep 01:37:16 UTC 2014Att fixa både CVE-2014-6271 och CVE-2014-7169 kommer att bryta testet:
$ X = '() { (a)=>\' bash -c "ekodatum" datum $ katteko cat: echo: Ingen sådan fil eller katalogFelet orsakas av liknande problem i Bash-kod [33] men påverkas av upprepade "<<EOF"
Testa bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "Sårbar av CVE-2014-7186, redir_stack" Det berörda systemet kommer att visa texten "Sårbar av CVE-2014-7186, redir_stack".Felet orsakas av liknande problem i Bash-koden [33] , men det påverkas av flera upprepningar av "klar"
Testa ( för x i { 1 ..200 } ; gör eko "för x $x i ; gör :" ; klar ; för x i { 1 ..200 } ; gör eko gjort ; klar ) | bash || echo "Sårbar av CVE-2014-7187, word_lineno" Det berörda systemet kommer att visa texten "Sårbar av CVE-2014-7187, word_lineno".Inom en timme efter publiceringen av Bash-sårbarheten kom det rapporter om att ha hackat datorsystem med dess hjälp. Den 25 september bekräftades olika "in the wild"-attacker, allt från enkla DoS- attacker till utplacering av kommando- och kontrollservrar via det skadliga "BASHLITE"-systemet [34] [35] . Kaspersky Labs rapporterade att några av de infekterade datorerna startade en DDoS-attack mot tre mål [8] . Den 26 september upptäcktes ett "wopbot"-botnät, som består av servrar infekterade via bashdoor och används i DDoS mot Akamai Technologies CDN:er och för att skanna det amerikanska försvarsdepartementets nätverk [7] .
Det finns flera möjliga sätt som en angripare kan använda för att skicka godtyckliga miljövariabler till bash som körs på den attackerade servern:
Webbservrar som kör Common Gateway Interface (CGI)-skript skickar information om en användarförfrågan genom miljövariabler som HTTP_USER_AGENT. Om begäran behandlas av Bash-programmet, eller ett annat program som anropar bash internt, kan angriparen ersätta User-Agent- strängen som sänds via http med en Shellshock-attackutlösare genom att lägga till sina egna kommandon [36] . Till exempel kan instruktionen "pinga" med angriparens adress ges som ett sådant kommando. Från inkommande ping-förfrågningar kommer angriparen att veta om attacken har fungerat.
Även om CGI är ett äldre gränssnitt med andra säkerhetsrisker [37] används det fortfarande. Till exempel är ett av de vanliga cPanel- skripten sårbart [38] , det uppskattas att det sårbara cPanel kan användas på 2-3 % av webbplatserna [39] .
OpenSSH SSH-servern låter dig begränsa användaren till en fast uppsättning tillgängliga kommandon ("ForceCommand"-alternativet). Ett fast kommando utförs även om användaren har begärt att ett annat kommando ska utföras. Det begärda kommandot i detta fall lagras i miljövariabeln "SSH_ORIGINAL_COMMAND". Om ett fast kommando exekveras i ett Bash-skal (om användarens tolk är inställd på Bash), kommer GNU Bash att upptäcka SSH_ORIGINAL_COMMAND-värdena som är inbäddade i miljön vid start och, i händelse av en Bashdoor-sårbarhet, kommer att utföra kommandon inbäddade där. Således får en angripare med tillgång till endast ett begränsat skal obegränsad åtkomst [3] .
En DHCP- klient begär vanligtvis en IP-adress från en DHCP-server. Servern kan dock skicka flera ytterligare alternativ, som kan skrivas till miljövariabler och göra att Shellshock utnyttjas på en dator eller bärbar dator ansluten till det lokala nätverket [40] [41] .
Ett program med setuid- bitar kan anropa bash direkt eller indirekt med hjälp av systemanrop system(3) , popen och andra, utan att återställa miljövariabler. En Shellshock-attack i sådana fall skulle tillåta den lokala användaren att höja sina egna privilegier till ägaren av det setuid-liknande programmet, ofta upp till root (superanvändare).
Felet kan potentiellt nå system som inte är anslutna till Internet under offlinebehandling med bash [42] .