Zacznijmy od podstaw, czyli od tego, czym jest shell (po polsku - powłoka). Bez względu na zainstalowany system operacyjny użytkownik nie może komunikować się z jego jądrem bezpośrednio. Potrzebuje do tego celu programu pośredniczącego, który odpowiednio zinterpretuje wprowadzane polecenia i zleci systemowi wykonanie określonych zadań. W systemie Windows rolę tę pełni Eksplorator, a w większości dystrybucji Linuksa i w Mac OS X (od wersji 10.3) domyślną powłoką systemową jest bash.

Luka w bashu, udokumentowana jako CVE-2014-6271 oraz CVE-2014-7169, której nadano też nazwę Shellshock, umożliwia zdalne wykonanie kodu w wyniku wadliwego przetwarzania zmiennych środowiskowych. Na atak podatne są wszystkie wersje basha do 4.3 włącznie, odpowiednich poprawek powinni spodziewać się także użytkownicy systemów wykorzystujących powłoki sh, zsh itp.

Więcej szczegółów technicznych można znaleźć w analizie przygotowanej przez CERT Polska, tutaj napomknę tylko, że każda zmienna, której wartość zaczyna się od () { jest przez bash traktowana jak wyeksportowana funkcja. Jeżeli na końcu definicji dodamy jakiś kod, zostanie on wykonany przed wywołaniem powłoki potomnej, co daje atakującym spore pole do popisu. Znającym język angielski polecam prezentację wideo przygotowaną przez SANS Internet Storm Center:

Jak sprawdzić swoją podatność na atak?

Eksperci z firmy RedHat proponują skorzystać z następującego polecenia:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Jeżeli używany przez nas system da się zaatakować przez lukę w bashu, w odpowiedzi otrzymamy komunikat:

vulnerable
this is a test

W przeciwnym wypadku zobaczymy na ekranie:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Wszystko w porządku? Według Tavisa Ormandy'ego z firmy Google pierwsze z pilnie udostępnionych poprawek nie załatały luki do końca, warto więc przetestować basha także jego sposobem:

The bash patch seems incomplete to me, function parsing is still brittle. e.g. $ env X='() { (a)=>' sh -c "echo date"; cat echo

— Tavis Ormandy (@taviso) wrzesień 24, 2014

Przydatne może okazać się również narzędzie Sysdig. Aby uruchomić wyszukiwanie zagrożonych procesów, wpisujemy polecenie:

sysdig -c shellshock_detect

W przypadku serwerów WWW ich podatność na atak możemy sprawdzić za pomocą stron shellshock.brandonpotter.com oraz bashsmash.ccsir.org - wystarczy zastosować się do zamieszczonych tam instrukcji.

Shellshock vs Heartbleed - możliwości wykorzystania luki

Od momentu ujawnienia Shellshock porównywany jest do podatności o nazwie Heartbleed, która spędzała administratorom sen z powiek na początku kwietnia br. Eksperci wydają się podzieleni - część uspokaja, że nie należy wpadać w panikę, ale nie brakuje też takich, którzy twierdzą, że omawiana luka jest poważniejsza niż Heartbleed. W takim tonie wypowiada się m.in. Secunia. Sam odkrywca luki, Stéphane Chazelas z firmy SeeByte, powstrzymuje się od głosu (gdyby ktoś natrafił w sieci na jego komentarz w tej sprawie, będę wdzięczna za podanie linku).

Jak może pamiętacie, Heartbleed (oficjalnie CVE-2014-0160) to błąd w bibliotece OpenSSL, który pozwala na odczytanie poufnych informacji, np. loginów i haseł, znajdujących się w pamięci procesu korzystającego z podatnej biblioteki. Shellshock, jak już wspomniałam, umożliwia zdalne wykonanie kodu, co z punktu widzenia ekspertów jest groźniejsze od przejęcia wrażliwych danych. Jak to może wyglądać w praktyce? Kilka sposobów wykorzystania luki podają specjaliści z CERT Polska:

• Opcja demona protokołu SSH ForceCommand jest często używana do ograniczenia możliwości wykonania komend zdalnym użytkownikom. Niektóre wdrożenia serwerów Git i Subversion używają tej opcji. Ponieważ wykonanie kodu za definicją funkcji odbywa się z uprawnieniami użytkownika demona SSH, można rozszerzyć zakres wykonywanych poleceń.
• Moduły serwera Apache mod_cgi czy też mod_cgid używają powłoki do deklaracji zmiennych. W ten sposób tworzą zmienne z np. wartości nagłówków. Przekazując odpowiednio spreparowany nagłówek, można wykonać polecenie w kontekście użytkownika serwera Apache.
• Narzędzia niestandardowe, które wykorzystują funkcje takie 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, mogą być również podatne.
• Klienci protokołu DHCP uruchamiają skrypty powłoki, aby skonfigurować system. Przekazanie odpowiednich wartości może spowodować wykonanie poleceń jako użytkownik, z którym chodzi demon DHCP. Najczęściej tym użytkownikiem jest root!

Według Dariena Kindlunda z firmy FireEye na atak może być podatnych od 20 do 50 proc. używanych obecnie serwerów WWW. Odnotowano już wiele przypadków skanowania sieci w poszukiwaniu podatnych maszyn, a jeden z czytelników Niebezpiecznika opisuje, jak to wygląda na polskim gruncie. Warto też odwiedzić blog firmy TrendMicro, gdzie znajdziemy kilka przykładów rozpowszechniania złośliwego oprogramowania za pomocą luki w bashu - zamieszczony poniżej schemat pokazuje działanie exploita ELF_BASHLITE.A (można kliknąć, aby powiększyć).

Czy grozi nam więc Shellshockowa katastrofa? Zdania są podzielone. Sama skłaniam się ku twierdzeniu, że nie. W sierpniu miałam okazję zapoznać się z raportem firmy Cisco. Jego autorzy ubolewali, że zarówno specjaliści, jak i zwykli użytkownicy koncentrują się na usuwaniu najpoważniejszych, medialnie nagłośnionych zagrożeń, takich jak choćby Heartbleed, lekceważąc luki o mniejszym znaczeniu, tak samo chętnie wykorzystywane przez atakujących. Jeśli jednak to prawda, wszyscy rzucą się teraz do łatania basha i katastrofa zostanie zażegnana. Zgadzacie się ze mną?