BashBug – czy jest się czego bać?

W świecie bezpieczeństwa informatycznego znów pali się czerwona lampka – we wszystkich systemach *Nix, włącznie z OS X Apple’a, wykryto nową lukę. Sprawa jest prawdopodobnie tak poważna, jak odkrycie luki Heartbleed wcześniej tego roku. Prawdopodobnie, ponieważ podczas gdy jedni eksperci wydają się bagatelizować jej potencjał, inni twierdzą, że jest co najmniej tak poważna, jak wspomniany kwietniowy numer jeden blogów i mediów z rynku bezpieczeństwa IT. Witaj, BashBugu, czy też Shellshocku.

O co chodzi?

Opis techniczny: luka jest obecna w Bashu – systemowej powłoce uniksowej, napisanej w 1989 r. Jest to domyślna powłoka systemowa w Linuksie i systemie OS X, a więc wszystkie te systemy są potencjalnie zagrożone.

Błąd wykryty przez Stephane Chazelasa z Akamai umożliwia atakującemu zdalne załączenie do zmiennej szkodliwego pliku wykonywalnego, który jest aktywowany podczas uruchamiania Basha.

Krajowa baza luk w Ameryce oznaczyła wspomniany błąd jako CVE-2014-6271 i opisuje go tak: „GNU Bash w wersji 4.3 po określeniu funkcji w wartościach zmiennych środowiskowych przetwarza ciągi końcowe, co umożliwia zdalnym atakującym wykonanie wybranego kodu w spreparowanym środowisku, co można było zaobserwować w przypadku wektorów wykorzystujących funkcję ForceCommand w OpenSSH: sshd, moduły mod_cgi i mod_cgid w serwerze HTTP Apache, skryptów wykonywanych przez dowolne klienty DHCP oraz innych sytuacjach, w których konfigurowanie środowiska narusza granicę uprawnień wykonania Basha”.

BashBug: czy to Heartbleed 2.0?

Tweet

Problem skończył już 25 lat. A ponieważ Bash jest obecnie powszechnie używany, błąd jest obecny niemal wszędzie.

Co wiadomo?

Wszystko wskazuje na to, że BashBug jest śmiertelnie poważny. Ponieważ łatwo go wykorzystać, może być potencjalnie bardzo szkodliwy, a obecność w prawie każdym systemie *Nix czyni z niego prawdziwą bestię wśród luk. Amerykański NVD przypisuje możliwościom jego wykorzystania oraz wpływowi równe 10 punktów, z kolei trudność dostępu ocenia jako niską.

Napisany przez Red Hat poradnik głosi: „Luka CVE-2014-6271 może umożliwić wykonanie dowolnego kodu. Pewne usługi i aplikacje umożliwiają nieautoryzowanym atakującym zdalne dołączenie zmiennych środowiskowych, dzięki czemu mogą wykorzystać wykryty błąd… Problem ten dotyczy wielu produktów, które używają powłoki systemowej Bash i analizują wartości zmiennych środowiskowych. Jest to tym bardziej niebezpieczne, że istnieje wiele możliwości wywołania Basha przez aplikację. Dosyć często zdarza się, że gdy aplikacja wykonuje inny plik binarny, Bash jest wywoływany do realizacji zadania”.

Według Ars Technica „Jeśli Bash zostanie ustawiony jako domyślna powłoka systemowa, może zostać wykorzystany przez atakujących za pośrednictwem sieci przeciwko serwerom i innym urządzeniom Unix i Linux poprzez żądania sieciowe, bezpieczną powłokę, sesje telnet lub inne programy, które używają Basha do wykonywania skryptów”.

Badacz bezpieczeństwa Robert Graham z Errata Security jest przekonany, że BashBug to problem tak duży jak Heartbleed, lub nawet większy.

„Znaczna część oprogramowania w jakiś sposób współdziała z powłoką systemową”,  napisał. „Dlatego nigdy nie będziemy mogli wskazać, które programy są podatne na lukę bash. To jest podobne do sytuacji z błędem w OpenSSL, który znajduje się w ogromnej ilości pakietów oprogramowania i z tego powodu nigdy nie mogliśmy całkowicie i dokładnie określić, jaka część oprogramowania jest dziurawa”.

Graham wskazuje także, że błąd jest szczególnie niebezpieczny dla urządzeń korzystających z tzw. internetu rzeczy (np. kamery wideo), ponieważ znaczna część ich oprogramowania opiera się na sieciowych skryptach bash. Mniej prawdopodobne jest to, że luki zostaną załatane, ale bardziej prawdopodobne – że zostaną otwarte dla zewnętrznego świata.

Należy także pamiętać, że nie wszystkie z tych starych urządzeń można załatać, więc sprawa wygląda nieciekawie.

Z drugiej strony Rapid7 nie spieszy się, by nazywać nową lukę Heartbleedem 2.0, stwierdzając, że zdalne wykorzystanie obecnego błędu nie jest tak powszechne:

„Każda podatna aplikacja może zostać wykorzystana przez nieznacznie różniący się wektor lub posiada inne wymagania do wykorzystania dziurawego kodu. Może to znacznie ograniczyć skalę rozprzestrzenienia ataków na wolności. Heartbleed był znacznie łatwiejszy w ostatecznych testach, a jego sposób działania bardziej rozpowszechniony”.

Jednak w tym poście Robert Graham mówi, że błąd ShellShock jest podatny na robaki. Wykonał on kilka wstępnych, pobieżnych skanowań i niemal natychmiast wykrył około 3000 luk systemowych na samym porcie 80, tylko w katalogu głównym URL-a („/”), bez użycia pola Host”. Graham mówi, że obecnie jest tam ich znacznie więcej. I – uwaga! – ktoś właśnie używa masowego skanowania w celu dostarczenia szkodliwego oprogramowania. „Prawdopodobnie złamali większość systemu, zobaczę jutro rano. Jeśli używają innych adresów URL i użyli pola Host, dostaną znacznie więcej”.

Czy słyszysz tykający zegar?

Zdalne ataki

Najistotniejsze jest pytanie: Z jaką łatwością błąd ten może zostać wykorzystany do wykonania zdalnych ataków? Warunki do wykorzystania są „dość rzadkie” (Red Hat już je wymienił). Jednak wciąż ataki te są całkiem możliwe. Wolfgang Kandek, szef w firmie Qualys, mówi o takim scenariuszu:

„Bash jest bardzo często potrzebny w ustawieniach sieciowych do wykonywania poleceń i to umożliwia przeprowadzenie interesującego ataku. Wyobraź sobie serwer pocztowy, który umożliwia Ci pingowanie adresu IP (mój domowy router posiada na przykład taką funkcję), najpewniej wywołałby on pinga dostarczonym przez Ciebie argumentem wykonywalnym i prawdopodobnie sprawdziłby, czy argument jest poprawnie sformatowany w odniesieniu do adresu IP. Znając lukę CVE-2014-6271, która umożliwia kontrolowanie wartości zmiennej środowiskowej danej powłoki systemowej, możesz sprawić, że powłoka systemowa uruchamia dowolne polecenia. Kontrolowanie zmiennej środowiskowej nie jest takie trudne, ponieważ wiele z nich jest pod kontrolą atakujących, takie jak ustawienia dla Referer czy UserAgent. W związku z tym scenariusz, w którym ustawienia CGI-BIN są wykorzystane do wykonania poleceń na serwerze, może zostać całkiem łatwo wykonany”.

Łaty

Tutaj sprawa nieco się komplikuje. Łata dla CVE-2014-6271 została szybko opublikowana przez Red Hat, ale natychmiast wykazano jej niekompletność [1, 2] i luka wciąż była możliwa do wykorzystania. Amerykańska baza luk ma już nowy pomysł: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169, dla którego także projektowane są już łaty. Jednak te, które już istnieją, są słabe, więc obecna sytuacja wygląda jak podwójna porażka.

Opublikowane łaty dla BashBuga są niekompletne

Tweet

Nowa łata jest już dostępna, chociaż ze względu na powagę sytuacji wszyscy dostawcy zagrożonego oprogramowania prawdopodobnie i tak opublikują swoje łaty. Bądźcie czujni i obserwujcie horyzont.

Czy jest się czego bać?

Wypadałoby.

OK, i co teraz?

Po pierwsze, użyj tego narzędzia do sprawdzenia swoich serwerów pod kątem luk. Co ciekawe, w trakcie pisania tego artykułu statystyki pokazują, że uruchomiono 7362 testów i znaleziono 749 luk.

Instalowanie łat CVE-2014-6271 ma sens, nawet jeśli one nie łatają całkowicie BashBuga: Rapid7 twierdzi, że załatane pakiety są trudniejsze do wykorzystania. Zatem naprawdę warto jest sprawdzić strony swojego dostawcy pakietów i uzyskać te uaktualnienia.

Ponadto Rapid7 mówi, że niezałatane systemy – takie jak stare sprzęty z osadzonym lub „dołączonym” oprogramowaniem – powinny zostać ukryte za zaporą sieciową. I powinna ona być porządna i bezpieczna.

Dla użytkowników systemów Apple’a: Konieczne uaktualnienia i szczegóły techniczne są dostępne tutaj. OS X 10.9.5 (najnowsza stabilna wersja na ten moment) jest dostarczana z Bashem v3.2.51.

Konkluzja

Najwidoczniej istnieje nowy szeryf w mieście. Luka ta była obecna przez wiele lat, dlatego nie jest wykluczone, że przed ujawnieniem jej ktoś o niej wcześniej wiedział. Oraz że nie została już wykorzystana. Nie wiadomo też, jakie zniszczenia może wyrządzić (inne niż nieodwracalna utrata komórek nerwowych), ale jeśli Graham ma rację… cóż, jutro może być nieciekawie.

Więc łatajcie się, ludzie, i używajcie wszystkiego, co jest dostępne.