Pamiętacie Heartbleed? Jeśli wierzyć dzisiejszemu szumowi, Shellshock jest w tej lidze i ma równie niesamowitą nazwę, aczkolwiek pozbawioną fajnego logo (ktoś z działu marketingu tych vulnów musi się tym zająć). Ale z całą powagą, ma on potencjał, aby być poważnym problemem i tak jak w przypadku Heartbleed, chciałem zebrać coś ostatecznego, zarówno dla mnie, aby zorientować się w sytuacji, jak i dla innych, aby oddzielić szum od prawdziwego ryzyka.
Aby ustawić scenę, pozwólcie, że podzielę się treścią wpisu na blogu Roberta Grahama, który przeprowadził na ten temat doskonałą analizę. Wyobraźmy sobie żądanie HTTP takie jak to:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
, które po wystosowaniu na szereg podatnych na ataki adresów IP, skutkuje następująco:
Mówiąc krótko, Robert właśnie zaaranżował grupę zewnętrznych maszyn do pingowania go po prostu poprzez wystosowanie starannie spreparowanego żądania przez sieć. Co jest naprawdę niepokojące, to fakt, że skutecznie spowodował, że te maszyny wydały arbitralne polecenie (aczkolwiek raczej łagodny ping), a to otwiera cały świat bardzo poważnych możliwości. Pozwólcie mi wyjaśnić.
Co to jest Bash i dlaczego go potrzebujemy?
Pomińcie to, jeśli to stare wiadomości, ale kontekst jest ważny dla tych, którzy nie znają Basha, więc ustalmy podstawowe zrozumienie. Bash jest powłoką *nixową lub innymi słowy, interpreterem, który pozwala na wykonywanie poleceń w systemach Unix i Linux, zazwyczaj poprzez połączenie przez SSH lub Telnet. Może również działać jako parser dla skryptów CGI na serwerze WWW, takich jak typowe skrypty Apache. Istnieje od późnych lat 80-tych, kiedy to wyewoluowała z wcześniejszych implementacji powłoki (nazwa pochodzi od powłoki Bourne’a) i jest ogromnie popularna. Istnieją inne powłoki dla różnych wariantów Uniksa, rzecz w tym, że Bash jest domyślną powłoką dla Linuksa i Mac OS X, które są oczywiście bardzo rozpowszechnionymi systemami operacyjnymi. To jest główny czynnik, dlaczego to ryzyko jest tak znaczące – wszechobecność Basha – i jest on opisywany jako „jedno z najczęściej instalowanych narzędzi w każdym systemie Linux”.
Możesz uzyskać poczucie śladu Basha, gdy spojrzysz na najnowsze statystyki serwerów WWW Netcraft:
Gdy połowa sieci działa na Apache (który zazwyczaj znajduje się na Linuksie), jest to znaczący rozmiar bardzo, bardzo dużego tortu. Ten sam artykuł Netcraft donosi, że właśnie przekroczyliśmy granicę miliarda stron internetowych i podczas gdy wiele z nich korzysta z tych samych hostów, to wciąż jest to bardzo dużo instalacji Basha. Aha – to tylko serwery WWW, nie zapominaj, że istnieje mnóstwo innych serwerów działających pod Linuksem, a my wrócimy do innych urządzeń z Bash trochę później.
Bash może być używany do całego szeregu typowych funkcji administracyjnych, wszystko od konfigurowania stron internetowych do kontrolowania oprogramowania wbudowanego w urządzenie, takie jak kamera internetowa. Oczywiście nie jest to funkcjonalność, która ma być otwarta dla świata i w teorii mówimy tu o uwierzytelnionych użytkownikach wykonujących polecenia, do których zostali upoważnieni. W teorii.
Co to za błąd?
Zacznę od CVE z bazy podatności NIST, ponieważ daje dobre poczucie powagi (podkreślenie moje):
GNU Bash przez 4.3 przetwarza ciągi znaków po definicjach funkcji w wartościach zmiennych środowiskowych, co pozwala zdalnym napastnikom na wykonanie dowolnego kodu poprzez spreparowane środowisko, jak pokazano na przykładzie wektorów obejmujących funkcję ForceCommand w OpenSSH sshd, moduły mod_cgi i mod_cgid w Apache HTTP Server, skrypty wykonywane przez niesprecyzowanych klientów DHCP i inne sytuacje, w których ustawianie środowiska odbywa się w poprzek granicy przywilejów z wykonaniem Basha.
Dalej oceniają go na „10 na 10” pod względem dotkliwości lub innymi słowy, jest tak zły, jak tylko się da. Na to nakłada się fakt, że atak jest łatwy do przeprowadzenia (złożoność dostępu jest niska), a co najważniejsze, nie wymaga uwierzytelnienia podczas korzystania z Basha za pośrednictwem skryptów CGI. Powyższe podsumowanie jest jednak trochę zawiłe, więc sprowadzmy je do mechaniki błędu.
Ryzyko koncentruje się wokół możliwości arbitralnego definiowania zmiennych środowiskowych w powłoce Bash, które określają definicję funkcji. Kłopoty zaczynają się, gdy Bash kontynuuje przetwarzanie poleceń powłoki po zdefiniowaniu funkcji, co skutkuje czymś, co sklasyfikowalibyśmy jako „atak wstrzyknięcia kodu”. Przyjrzyjmy się ponownie przykładowi Roberta i weźmy tylko ten wiersz:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Definicja funkcji to () { :; }; a polecenie powłoki to deklaracja ping i kolejne parametry. Gdy jest to przetwarzane w kontekście powłoki Bash, wykonywane jest dowolne polecenie. W kontekście sieciowym, oznaczałoby to, że poprzez mechanizm taki jak skrypt CGI i niekoniecznie jako nagłówek żądania. Warto zapoznać się z poradą seclists.org, gdzie podano więcej szczegółów, w tym stwierdzenie, że ścieżka i ciąg zapytania mogą być potencjalnymi wektorami ataku.
Oczywiście jednym ze sposobów ograniczenia tego konkretnego wektora ataku jest po prostu wyłączenie wszelkich funkcji CGI, które wykonują wywołania do powłoki i rzeczywiście niektórzy to zalecają. W wielu przypadkach będzie to jednak poważna zmiana, a co najmniej taka, która będzie wymagała szeroko zakrojonych testów w celu zapewnienia, że nie spowoduje ona natychmiastowych problemów na stronie, co w wielu przypadkach będzie miało miejsce.
Powyższy dowód HTTP jest prosty, ale skuteczny, aczkolwiek jest to tylko jedna z implementacji wspólnego protokołu. Gdy zaczniesz wrzucać Telnet i SSH, a najwyraźniej nawet DHCP, zakres drastycznie wzrasta, więc w żadnym wypadku nie mówimy tu tylko o wykorzystywaniu serwerów aplikacji internetowych. (Najwyraźniej ryzyko jest obecne tylko w SSH post-auth, ale na tak wczesnym etapie publicznego ujawnienia nieuchronnie zobaczymy, że pojawią się jeszcze inne wektory ataku.)
Co również należy pamiętać, to że zakres potencjalnych szkód rozciąga się daleko poza pingowanie dowolnego adresu, jak w przykładzie Roberta, to jest po prostu zgrabny mały dowód na to, że mógł zaaranżować maszynę do wydania polecenia powłoki. Pytanie staje się następujące: Jakie szkody może wyrządzić atakujący, gdy może wykonać wybraną przez siebie komendę powłoki na dowolnej podatnej maszynie?
Jakie są potencjalne konsekwencje?
Potencjał jest ogromny – „zdobycie powłoki” na maszynie zawsze było główną wygraną dla atakującego ze względu na kontrolę, jaką oferuje mu środowisko docelowe. Dostęp do wewnętrznych danych, rekonfiguracja środowisk, publikacja własnego złośliwego kodu itp. Jest to niemal nieograniczone i łatwo zautomatyzowane. Istnieje wiele przykładów exploitów, które mogą być łatwo odpalone przeciwko dużej liczbie maszyn.
Niestety, jeśli chodzi o wykonanie dowolnego kodu w powłoce na połowie stron w Internecie, potencjał jest dość szeroki. Jednym z oczywistych (i szczególnie paskudnych) jest wyrzucanie wewnętrznych plików do publicznego użytku. Pliki z hasłami i pliki konfiguracyjne z danymi uwierzytelniającymi są oczywiste, ale można je rozciągnąć na dowolne inne pliki w systemie.
Podobnie, to samo podejście można zastosować do zapisu plików w systemie. Jest to potencjalnie najłatwiejszy wektor niszczenia stron internetowych, jaki kiedykolwiek widzieliśmy, nie wspominając o bardzo łatwym sposobie dystrybucji złośliwego oprogramowania
A co powiecie na to: jedno słowo, z którym często się spotykam, to „robak”:
Gdy mówimy o robaku w kontekście złośliwego oprogramowania, mówimy o samoreplikującym się ataku, w którym złośliwy aktor tworzy kod zdolny do rozprzestrzeniania się po celach. Na przykład, widzieliśmy bardzo skuteczną implementację tego ataku w MySpace XSS Worm Samy’ego, gdzie starannie spreparowany JavaScript zdołał „zainfekować” strony miliona ofiar w mniej niż jeden dzień.
Zaniepokojenie Shellshockiem jest takie, że atak tego typu może replikować się w alarmującym tempie, szczególnie na wczesnym etapie, gdy większość maszyn pozostaje zagrożona. W teorii, może to przybrać formę skanowania zainfekowanej maszyny w poszukiwaniu innych celów i rozprzestrzeniania na nie ataku. Nie będzie to w żaden sposób ograniczone do maszyn publicznych, ale za korporacyjnym firewallem, a niebo jest nieograniczone.
Ludzie pracują nad wykorzystaniem tego już teraz. To właśnie sprawia, że te wczesne dni są tak interesujące, ponieważ wyścig zbrojeń między tymi, którzy starają się załatać, a tymi, którzy starają się zaatakować, rozgrzewa się do czerwoności.
Których wersji Basha dotyczy problem?
W nagłówkach podano wszystko do wersji 4.3 lub innymi słowy, około 25 lat wersji Basha. Biorąc pod uwagę, że wszyscy porównują to do Heartbleed, rozważmy, że dotknięte wersje OpenSSL obejmowały zaledwie dwa lata, co jest kroplą w morzu w porównaniu do Shellshocka. Tak, ludzie aktualizują swoje wersje, ale nie robią tego konsekwentnie i niezależnie od tego, jak to wytniemy, liczba zagrożonych maszyn będzie znacznie wyższa w przypadku Shellshocka niż w przypadku Heartbleeda.
Ryzyko może również wykraczać poza 4.3. Już teraz widzimy raporty o łatach, które nie są całkowicie skuteczne, a biorąc pod uwagę szybkość, z jaką są one rozwijane, nie jest to aż tak zaskakujące. Jest to rodzaj rzeczy, na którą ci, których to dotknęło, chcą mieć bardzo dokładne oko, a nie tylko „załatać i zapomnieć”.
Kiedy po raz pierwszy się o tym dowiedzieliśmy i jak długo byliśmy zagrożeni?
Pierwszą wzmianką, jaką znalazłem na publicznej antenie, było to bardzo krótkie podsumowanie na seclists.org, które działa około 14:00 GMT w środę (około północy tego ranka dla tych z nas na wschodnim krańcu Australii). Szczegóły pojawiły się w doradztwie, o którym wspomniałem wcześniej godzinę później, więc coraz w kierunku mid-afternoon Środa w Europie lub rano w USA. Jest to wciąż bardzo świeża wiadomość z wszystkimi zwykłymi spekulacjami prasowymi i przewidywaniami Kurczaka Małego; jest zbyt wcześnie, aby zaobserwować jakiekolwiek powszechne wykorzystanie w środowisku naturalnym, ale to może również nadejść bardzo szybko, jeśli ryzyko spełni swój potencjał.
Scroll back beyond just what has been disclosed publicly and the bug was apparently discovered last week by Stéphane Chazelas, a „Unix/Linux, network and telecom specialist” bloke in the UK. Mimo to, w poście Akamai dotyczącym błędu, mówią oni o tym, że był on obecny przez „dłuższy okres czasu” i oczywiście podatne wersje Basha sięgają dwóch i pół dekady wstecz. Pytanie, podobnie jak w przypadku Heartbleed, będzie dotyczyło tego, czy złośliwi aktorzy wiedzieli o tym wcześniej i czy aktywnie to wykorzystywali.
Czy nasze „rzeczy” są dotknięte?
Tutaj robi się ciekawie – mamy wiele „rzeczy” potencjalnie wykorzystujących Basha. Oczywiście, kiedy używam tego terminu, odnoszę się do „Internetu rzeczy” (IoT), który jest coraz bardziej powszechnym zjawiskiem polegającym na umieszczaniu adresu IP i adaptera bezprzewodowego we wszystkim, począwszy od naszych sztućców, poprzez zamki do drzwi, aż po żarówki.
Wiele urządzeń IoT uruchamia wbudowane dystrybucje Linuksa z Baszą. Te same urządzenia już wykazały poważne luki w zabezpieczeniach w innych obszarach, na przykład lampy LIFX zaledwie kilka miesięcy temu zostały uznane za wyciek danych uwierzytelniających wifi. Chociaż nie jest to luka w Bashu jak Shellshock, pokazuje nam, że łącząc nasze rzeczy wchodzimy w zupełnie nowy świat luk w miejscach, które nigdy wcześniej nie były zagrożone.
Edit: Kilka osób odniosło się do powszechności BusyBoxa uruchamiającego powłokę Ash na urządzeniach mobilnych. Urządzenia z tym systemem nie wydają się być narażone na ryzyko Shellshocka. Trudność dla konsumenta polega na tym, że nie wie, co jest uruchomione na jego urządzeniu, a to obejmuje również bardziej tradycyjne „rzeczy”, takie jak routery. Długa historia tego błędu oznacza, że mamy więcej niż kilka dekad urządzeń, które przeszły przez różne ewolucje różnych wbudowanych OS-ów i mamy teraz bardzo zróżnicowany krajobraz maszyn i powłok obejmujący długi okres czasu.
Przynosi to ze sobą wiele nowych wyzwań; na przykład, kto aktywnie myśli, że powinien regularnie łatać swoje żarówki? Należy również wziąć pod uwagę trwałość urządzeń, w których to oprogramowanie się pojawia i to, czy są one rzeczywiście aktywnie utrzymywane. W przypadku takim, jak podatne na ataki kamery Trendnet sprzed kilku lat, bez wątpienia istnieje ogromna liczba tych urządzeń, które wciąż siedzą w sieci, ponieważ pod względem łatania, są one w zasadzie propozycją typu „ustaw i zapomnij”. W rzeczywistości w tym przypadku istnieje całe konto na Twitterze poświęcone nadawaniu przechwyconych zdjęć niczego nie podejrzewających właścicieli podatnych wersji. To duży problem, który nie ma łatwych rozwiązań i będzie nam towarzyszył przez bardzo długi czas.
Ale powłoki Bash są również obecne w wielu bardziej powszechnych urządzeniach, na przykład w naszych domowych routerach, które są generalnie skierowane do internetu. Pamiętasz kiedy ostatnio poprawiałeś firmware na swoim routerze? Ok, jeśli to czytasz, to może jesteś typem osoby technicznej, która rzeczywiście robi patch ich router, ale postaw się w butach przeciętnego Joe konsumenta i zadać sobie to pytanie ponownie. Exactly.
Wszystkie nasze rzeczy są na stosie Microsoft, czy jesteśmy zagrożeni?
Krótka odpowiedź „nie”, długa odpowiedź „tak”. Najpierw zajmę się łatwym – Bash nie jest natywnie dostępny w systemie Windows i chociaż istnieją implementacje Bash dla Windows, to z pewnością nie są one powszechne i nie będzie ich można znaleźć na komputerach konsumenckich. Nie jest też jasne, czy produkty takie jak win-bash są w ogóle podatne na Shellshocka.
Dłuższa odpowiedź jest taka, że tylko dlatego, że działacie w środowisku skoncentrowanym głównie na Microsofcie, nie oznacza, że nie macie Basha uruchomionego na maszynach obsługujących inne dyskretne cele w tym środowisku. Kiedy pisałem o Heartbleed, odniosłem się do postu Nicka Cravera o przeniesieniu Stack Overflow w kierunku SSL i odniosłem się do tego diagramu ich infrastruktury:
Przed stosem aplikacji Microsoftu siedzą komponenty spoza Microsoftu, komponenty, przez które ruch musi przejść, zanim trafi na serwery internetowe. Są to również komponenty, które mogą mieć podwyższone uprawnienia za firewallem – jaki będzie wpływ, jeśli Shellshock zostanie na nich wykorzystany? Shellshock ma potencjał, aby wpłynąć na aktywa wykraczające poza zagrożone implementacje Bash, gdy istnieje w szerszym ekosystemie innych maszyn.
Jestem administratorem systemu – co mogę zrobić?
Po pierwsze, odkrycie czy jesteś zagrożony jest banalne, ponieważ jest to tak łatwe do odtworzenia ryzyko. Istnieje bardzo prosty test sugerowany przez The Register, który polega na uruchomieniu tej komendy w powłoce:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Dostajesz „busted” echo’d z powrotem i pomyślnie wykorzystałeś błąd.
Oczywiście priorytetem będzie tutaj łatanie zagrożonych systemów, a łatka sprowadza się do zapewnienia, że żaden kod nie może być wykonany po zakończeniu funkcji Bash. Dystrybutorzy Linuksa, tacy jak Red Hat, wydają wytyczne dotyczące łatania ryzyka, więc skocz na to jako sprawę priorytetową.
Nieuchronnie zobaczymy również definicje dla systemów wykrywania włamań i z pewnością będą wspólne wzorce do poszukiwania tutaj. To może okazać się dobrym natychmiastowym wdrożeniem dla wielu organizacji, szczególnie tam, gdzie mogą istnieć uciążliwe wymagania dotyczące testowania przed wprowadzeniem poprawek do zagrożonych systemów. Qualys’ dąży do tego, aby mieć definicję wykrywania ataku dość szybko i nieuchronnie inni dostawcy IDS pracują nad tym przez całą dobę, jak również.
Inne bardziej drastyczne opcje obejmują zastąpienie Bash z alternatywną implementacją powłoki lub odgradzanie zagrożonych systemów, z których oba mogą mieć daleko idące konsekwencje i są mało prawdopodobne, aby być decyzje podjęte lekko. Ale to prawdopodobnie będzie natura tego błędu dla wielu ludzi – trudne decyzje, które mogą mieć namacalny wpływ na biznes, aby uniknąć potencjalnie dużo bardziej znaczących konsekwencji.
Inną kwestią, która zacznie się teraz często pojawiać, jest pytanie, czy Shellshock został już wykorzystany w środowisku. Może to być trudne do ustalenia, jeśli nie ma logowania wektorów ataku (często nie będzie, jeśli są one przekazywane przez nagłówek żądania HTTP lub ciało POST), ale jest bardziej prawdopodobne, że zostanie to wyłapane niż w przypadku Heartbleeda, kiedy to w przypadku braku pełnych pcapsów, ładunki Heartbeat nie byłyby nigdzie logowane. Jednak nadal, najczęstszą odpowiedzią na pytanie „czy zostaliśmy zaatakowani przez Shellshocka” będzie:
Niestety, nie jest to „Nie, mamy dowody na to, że nie było żadnych kompromisów”, a raczej „nie mamy dowodów na to, że ta podatność była wykorzystywana przez cały okres jej istnienia”. Wątpimy, by wiele osób je posiadało – a to pozostawia właścicieli systemów w niewygodnej sytuacji, w której nie wiedzą, jakie, jeśli w ogóle, kompromisy mogły mieć miejsce.
Niech zaczną się spekulacje na temat tego, czy NSA brała w tym udział…
Jestem konsumentem – co mogę zrobić?
To zależy. Shellshock wpływa na komputery Mac, więc jeśli używasz OS X, na tym etapie, że wydaje się być zagrożony, co z jednej strony jest złe ze względu na powszechność OS X, ale z drugiej strony będzie łatwo (i miejmy nadzieję szybko) remediated ze względu na dość dobrze sprawdzony mechanizm aktualizacji (tj. Apple może zdalnie popchnąć aktualizacje do maszyny).
Jeśli jesteś na Macu, ryzyko jest łatwe do przetestowania, jak opisano w tej odpowiedzi Stack Exchange:
To łatwy test, chociaż wątpię, że przeciętny użytkownik Maca będzie czuć się komfortowo krocząc przez sugerowaną poprawkę, która obejmuje rekompilację Bash.
Większym zmartwieniem są urządzenia bez łatwej ścieżki łatania, na przykład router. Krótko sprawdzając na stronie producenta dla zaktualizowanego firmware, to będzie naprawdę twardy orzech do zgryzienia. Często routery dostarczane przez dostawców usług internetowych są zablokowane tak, że konsumenci nie są przypadkowo zmieniając albo konfigurację lub firmware i nie zawsze jest zdalna ścieżka aktualizacji mogą one uruchomić albo. Połącz to z ogromnym wachlarzem urządzeń i wieku, które są tam i to może być szczególnie trudne. Oczywiście nie jest to również rodzaj rzeczy twój przeciętny konsument będzie wygodne robi się albo.
W skrócie, rada dla konsumentów jest to: oglądać na aktualizacje zabezpieczeń, szczególnie na OS X. Miejcie również oko na wszelkie porady, które możecie otrzymać od waszego ISP lub innych dostawców urządzeń, które posiadają wbudowane oprogramowanie. Należy zachować ostrożność w przypadku wiadomości e-mail z prośbą o informacje lub instrukcje dotyczące uruchomienia oprogramowania – po takich wydarzeniach często następują ataki phishingowe, które wykorzystują obawy konsumentów. Obecnie ludzie wkładają swoje iPhone’y do mikrofalówki, więc ani przez chwilę nie myślcie, że nie uruchomią przypadkowego oprogramowania wysłanego do nich e-mailem jako „poprawka” dla Shellshocka!
Podsumowanie
Wszystko wskazuje na to, że nawet nie zaczęliśmy jeszcze zgłębiać skali tej luki. Oczywiście, jest wiele porównań do Heartbleed i jest kilka rzeczy, których nauczyliśmy się z tego ćwiczenia. Jedną z nich jest to, że zajęło nam trochę czasu, zanim zdaliśmy sobie sprawę, jak bardzo jesteśmy zależni od OpenSSL. Drugą jest to, że miał on bardzo długi ogon – miesiące po jego wystąpieniu nadal setki tysięcy znanych hostów pozostawało podatnych na ataki.
Pod jednym względem porównanie z Heartbleedem nie jest sprawiedliwe – ten atak jest potencjalnie dużo gorszy. Heartbleed pozwalał na zdalny dostęp do niewielkich ilości danych w pamięci zaatakowanych maszyn. Shellshock umożliwia zdalne wstrzykiwanie kodu do dowolnych komend przed autoryzacją, co jest potencjalnie o wiele bardziej tragiczne. W tym względzie muszę zgodzić się z Robertem:
Jest jeszcze bardzo, bardzo wcześnie – w momencie pisania tego tekstu minęło zaledwie pół dnia od momentu, gdy po raz pierwszy trafił na antenę – i podejrzewam, że jak na razie tylko zarysowujemy powierzchnię tego, co jeszcze przed nami.
Bezpieczeństwo