Jak sprawdzić, czy mój serwer jest podatny na błąd ShellShock?

80

Jak mogę się upewnić, że moja instalacja Bash nie jest już podatna na błąd ShellShock po aktualizacji?

Giovanni Tirloni
źródło
Pamiętaj, że w bashie są jeszcze dwie inne luki (CVE-2014-7186 i CVE-2014-7187).
Deer Hunter
Poprawki, które naprawiają CVE-2014-7186 i CVE-2014-7187 są dostępne wkrótce po opublikowaniu komentarza przez Deer Hunter. Jeśli masz łatkę dostarczoną z dystrybucją dla CVE-2014-7169, możesz mieć już wystarczająco dużo, aby zablokować 7186/7187, przetestuj swój system za pomocą poniższych poleceń i zobacz. Sprawdź także, czy nie ma więcej aktualizacji zabezpieczeń dla Twojej dystrybucji.
BeowulfNode42

Odpowiedzi:

83

Aby sprawdzić lukę w zabezpieczeniach CVE-2014-6271

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

NIE powinno to odzwierciedlać wrażliwego słowa.


Aby sprawdzić, czy występuje luka w zabezpieczeniach CVE-2014-7169
(ostrzeżenie: jeśli Twoja awaria zakończy się niepowodzeniem, utworzy lub zastąpi plik o nazwie /tmp/echo, który można usunąć później i trzeba go usunąć przed ponownym testowaniem)

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

powinna zawierać słowo „data”, a następnie narzekać na wiadomość typu „jak” cat: echo: No such file or directory. Jeśli zamiast tego powie Ci, jaka jest aktualna godzina, oznacza to, że twój system jest podatny na ataki.


Aby sprawdzić CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

NIE powinno to odzwierciedlać tekstu CVE-2014-7186 vulnerable, redir_stack.


Aby sprawdzić CVE-2014-7187

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

NIE powinno to odzwierciedlać tekstu CVE-2014-7187 vulnerable, word_lineno.


Aby sprawdzić CVE-2014-6277. Nie jestem w 100% pewien tego, ponieważ wydaje się, że opiera się on na częściowo poprawionym systemie, do którego nie mam już dostępu.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

Wynik pozytywny w tym przypadku polega tylko na odbiciu tekstu testing CVE-2014-6277. Jeśli uruchamia się w Perlu lub jeśli skarży się, że Perl nie jest zainstalowany, to z pewnością jest to błąd. Nie jestem pewien co do innych cech awarii, ponieważ nie mam już niezałatowanych systemów.


Aby sprawdzić CVE-2014-6278. Ponownie, nie jestem w 100% pewien, czy ten test, ponieważ nie mam już niepakowanych systemów.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

Zaletą tego testu jest to, że powinien on WYŁĄCZNIE odzwierciedlać tekst testing CVE-2014-6278. Jeśli twoje echo wróci hi momgdziekolwiek, to zdecydowanie porażka.

BeowulfNode42
źródło
1
Czy możemy dodać do tego ogólny test foo='() { echo not patched; }' bash -c foo? Dopóki eksport funkcji nie zostanie umieszczony w osobnej przestrzeni nazw, nie przestaniemy działać od jednego błędu parsera do następnego.
billyw
Czy ten test ma CVE? Czy masz jakieś odniesienia do opisania tego problemu? Również tego rodzaju informacje mogą należeć do jednego z pozostałych pytań na temat shellshocka, ponieważ ten Q dotyczy testowania sukcesu lub niepowodzenia istniejących łatek.
BeowulfNode42
To pochodzi z wpisu na blogu Michała Zalewskiego na nadchodzące CVE's Shellshock ( lcamtuf.blogspot.com/2014/09/… ). To jego sugerowany test dla CVE-2014-6278, który wciąż jest niepubliczny. Wygląda jednak na to, że myliłem się co do ogólności testu; Spotkałem już przypadek, w którym test Zalewskiego przeszedł pomyślnie, ale test CVE-2014-7187 nie powiódł się.
billyw
A oto pełne ujawnienie CVE-2014-6277 i CVE-2014-6278, wraz z poleceniami, aby je sprawdzić: seclists.org/fulldisclosure/2014/Oct/9
billyw
Jedna uwaga: nawet jeśli wersja BASH jest podatna na atak, jeśli nic z niej nie korzysta (tj. Wszystkie konta używane przez demony, takie jak „www” lub „cup” itp.), Są skonfigurowane z BASH jako domyślną powłoką i żadne twoje kody wywołują system () lub podobny, posiadanie podatnej wersji może być mniej ryzykowne, ale mimo to zaktualizuj BASH jak najszybciej.
DTK
32

Wyeksportuj specjalnie spreparowaną zmienną środowiskową, która zostanie automatycznie oceniona przez wrażliwe wersje Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Teraz wykonaj proste echo, aby sprawdzić, czy Bash oceni kod w $ testbug, nawet jeśli sam nie użyłeś tej zmiennej:

$ bash -c "echo Hello"
VULNERABLE
Hello

Jeśli pokazuje ciąg „VULNERABLE”, odpowiedź jest oczywista. W przeciwnym razie nie musisz się martwić, a łatana wersja Bash jest w porządku.

Uwaga: główne dystrybucje Linuksa wydały wiele poprawek, a czasem nie usuwają całkowicie tej luki. Sprawdzaj ostrzeżenia dotyczące bezpieczeństwa i wpis CVE dotyczący tego błędu.

Giovanni Tirloni
źródło
5
Oprócz CVE-2014-6271, niekompletna poprawka Red Hat w szczególności ma swoją własną, którą również warto śledzić : CVE-2014-7169 .
DocMax,
3
Jednowierszowy, który nie zanieczyszcza środowiska env powłoki i zdarza się, że działa, nawet jeśli „używasz alternatywnej powłoki logowania (o której może nie wiedzieć export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki,
1
Jest kilka szczegółów dotyczących Ubuntu tutaj askubuntu.com/questions/528101/... - osobiście musiałem zaktualizować system z Ubuntu 13.10 do 14.04, aby rozwiązać problem
dodgy_coder
2

ShellShock jest praktycznie połączeniem więcej niż jednej luki w bash , aw tej chwili istnieje również złośliwe oprogramowanie, które wykorzystuje tę lukę , więc ShellShock może być problemem, który jest nadal otwarty, jest wątek z aktualizacjami od RedHat na ten temat .

Redhat zaleca następujące czynności:

Uruchom polecenie:

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

Jeśli dane wyjściowe to:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

nie masz żadnej poprawki.

Jeśli dane wyjściowe to:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

masz CVE-2014-6271naprawę

Jeśli twój wynik to:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

nie jesteś wrażliwy.

Drugą częścią testu ShellShock jest kontrola podatności CVE-2014-7169, która zapewnia ochronę systemu przed problemem związanym z tworzeniem plików. Aby sprawdzić, czy twoja wersja Bash jest podatna na CVE-2014-7169, uruchom następującą komendę:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

Jeśli twój system jest podatny na zagrożenia, wyświetli się data i godzina i zostanie utworzony / tmp / echo.

Jeśli twój system nie jest wrażliwy, zobaczysz dane wyjściowe podobne do:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory
Eduard Florinescu
źródło
2

Napisałem narzędzie CLI o nazwie ShellShocker, aby przetestować twój serwer pod kątem luk w skryptach CGI. Aby przetestować swoją witrynę, uruchom:

python shellshocker.py <your-server-address>/<cgi-script-path>

to znaczy

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

EDYCJA: narzędzie zostało usunięte, przepraszam: „(

Liam Marshall
źródło
Twój link nie działa
SSK
@SSK Przepraszamy;) Błąd.
Liam Marshall
Twój link jest nadal martwy.
Mxx
Tak, przepraszam, zdjąłem to. Był wykorzystywany w sposób, który mi się nie podobał.
Liam Marshall
1

Możesz przesłać swój adres URL CGI do tego testu online:

http://shellshock.iecra.org

użytkownik245089
źródło
4
Uprzejmie jest podawać powody głosów negatywnych.
David
4
„Rejestrujemy wszystkie skany” ??? Przerażający. Pobrałbym pytona i sam go uruchomiłem.
Brad
1
@brad przynajmniej ci mówią. Jestem pewien, że gdybym zapewniał usługę bezpieczeństwa whitehat, która oferowała tę usługę, równie dobrze mógłbym prowadzić dziennik (jeśli tylko licznik bez indywidualnych danych), ile osób ślepo wprowadziło dane swojej witryny na stronę internetową, która powiedziała, że ​​będzie próbę przeprowadzenia testu penetracyjnego, nie wiedząc wiele o autentyczności strony oferującej test ... a oni chcieliby dziennika, kto przetestował, na wypadek gdyby ktoś użył ich usługi do znalezienia wrażliwych witryn należących do innych ...
Rob Moir
-1

wpisz env x = '() {:;}; echo wrażliwy „bash -c” echo to jest test ”, a jeśli to zwróci podatność i jest to test, oznacza to, że ma to wpływ na komputer z systemem OSX / Linux. Rozwiązaniem jest aktualizacja do najnowszej wersji bash.

Hen-Al
źródło
6
Dlaczego jako root? Całkowicie niepotrzebne.
Mat