Shellshock to błąd w powłoce interfejsu wiersza poleceń Bash, który istnieje od 30 lat i został odkryty jako znaczące zagrożenie w 2014 roku. Dziś Shellshock nadal pozostaje zagrożeniem dla przedsiębiorstw.
Zagrożenie to jest z pewnością mniej ryzykowne niż w roku odkrycia. Jednak w roku, w którym priorytety bezpieczeństwa zostały przekalibrowane, aby nadążyć za chaotycznym krajobrazem, jest to dobry czas, aby spojrzeć wstecz na to zagrożenie i czynniki leżące u podstaw, które utrzymują te ataki przy życiu w dzisiejszych czasach.
Dlaczego Shellshock jest istotny w 2020 roku?
Shellshock jest krytyczną luką ze względu na eskalację przywilejów przyznanych atakującym, które pozwalają im na dowolne kompromitowanie systemów. Chociaż luka ShellShock, CVE-2014-6271, została odkryta w 2014 roku, wiadomo, że nadal istnieje na dużej liczbie serwerów na świecie. Podatność została zaktualizowana (CVE-2014-7169) wkrótce potem i była modyfikowana aż do 2018 roku.
Główny powód, dla którego Shellshock jest wciąż w użyciu, nie jest żadnym szokiem. Ta luka jest prostym i niedrogim atakiem, który źli aktorzy mogą zastosować przeciwko nieświadomemu celowi. Łatki są dostępne od czasu wprowadzenia CVE, ale każda organizacja bez odpowiedniego systemu zarządzania poprawkami może być nadal podatna na atak.
Shellshock był nadal widoczny w 2017 roku. Kiedy wszystko, czego potrzebują atakujący to podstawowe umiejętności programistyczne, serwer i dostęp do złośliwego oprogramowania, nie jest to zaskakujące. Dodatkowo, koszt przeprowadzenia ataku nie jest dużo większy niż kilka dolarów miesięcznie. Rachunek jest na korzyść atakujących. Minimalna wiedza, niewielki wysiłek i niski koszt równa się jedna łatwa strategia hakerska.
Pomimo wszystkich obszernych relacji w mediach na temat cyberbezpieczeństwa, a nawet ostrzeżenia Departamentu Bezpieczeństwa Wewnętrznego, niektóre systemy pozostają niezałatane. W jednym z przykładów, urzędnicy z Center for Election Systems nie zastosowali poprawki, która naruszyła system wyborczy w Georgii.
Jak działa Shellshock?
W uproszczeniu, Shellshock jest luką, która pozwala na wykorzystanie systemów zawierających podatną wersję Basha do wykonywania poleceń z wyższymi uprawnieniami. Pozwala to atakującym na potencjalne przejęcie kontroli nad systemem.
Głębiąc się w szczegóły techniczne, Shellshock jest błędem bezpieczeństwa w powłoce Bash (GNU Bash do wersji 4.3), który powoduje, że Bash wykonuje niezamierzone polecenia ze zmiennych środowiskowych. Podmioty wykorzystujące tę lukę mogą zdalnie wydawać polecenia na atakowanym hoście. Chociaż Bash nie jest z natury skierowany do Internetu, wiele wewnętrznych i zewnętrznych usług, takich jak serwery internetowe, wykorzystuje zmienne środowiskowe do komunikacji z systemem operacyjnym serwera.
Jeśli te dane wejściowe nie zostaną oczyszczone – standardowy proces kodowania, który zapewnia, że kod nie jest częścią danych wejściowych – przed wykonaniem, napastnicy mogą uruchomić polecenia żądania HTTP wykonywane za pośrednictwem powłoki Bash.
Podatność w szczegółach
Serwery WWW nie są jedynymi podatnymi na ataki zasobami sieciowymi. Narażone na atak mogą być również serwery poczty elektronicznej i serwery DNS, które wykorzystują BASH do komunikacji z systemem operacyjnym. Chociaż BASH jest zwykle spotykany w systemach opartych na Uniksie, organizacje korzystające z systemów opartych na Windowsie nie są na niego odporne. Prawdopodobnie wykorzystują one urządzenia lub sprzęt, które są podatne na ataki. Pamiętajmy, że BASH może być częścią domowych routerów, wielu urządzeń IoT i systemów wbudowanych.
Shellshock może być nawet wykorzystywany do przeprowadzania ataków typu Denial of Service (DOS).
Tutaj znajduje się linia kodu (deklaracja funkcji Bash, po której następuje średnik i polecenie 'sleep’ uruchamiane z trzech możliwych ścieżek, aby zapewnić jego wykonanie):
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
To polecenie „sleep” zmusza serwer do odczekania dwudziestu sekund przed udzieleniem odpowiedzi. W ten sposób zasoby na maszynie są w zasadzie zakładnikami, ponieważ maszyna nie może robić nic innego przez dwadzieścia sekund.
Jedno polecenie uśpienia może być nieszkodliwe, ale atakujący może być w stanie zastąpić je złośliwym kodem. Następnie, kod ten może zakuć w kajdanki serwer lub zasób tak, że nie jest on w stanie obsłużyć żadnych żądań.
Ryzyko dopuszczenia szkodliwych użytkowników Internetu do zdalnego wykonywania wybranych przez nich poleceń jest wysokie. Korzystając z otwarcia, źli aktorzy mogą uruchamiać programy w systemie, tworzyć połączenia wychodzące do własnych systemów i wykonywać złośliwe oprogramowanie.
Prawdopodobnie najbardziej krytycznie, luka może zostać wykorzystana do kradzieży poufnych danych i informacji przechowywanych w systemie, takich jak dane kart kredytowych, hasła i informacje umożliwiające identyfikację osób (PII).
Is Shellshock Still Rampant?
Shellshock nie jest tak powszechny, jak był, gdy został odkryty w 2014 roku. Wyobraź sobie wyzwanie, jakim była konieczność załatania wszystkich podatnych serwerów Twojej firmy (a w tamtym czasie było ich wiele).
To powiedziawszy, Shellshock pozostaje problemem.
Na przykład, trwa kampania cyberzagrożeń i luk w zabezpieczeniach o nazwie „Sea Turtle”, która wykorzystuje rekordy DNS, aby uzyskać dostęp do wrażliwych systemów. Aby ataki się powiodły, konieczne jest wykorzystanie wielu typowych luk w sprzęcie i oprogramowaniu – Shellshock jest jedną z nich.
Chociaż nie jest to już tak powszechne jak wcześniej, każda firma powinna upewnić się, że cały sprzęt i oprogramowanie są załatane i aktualne.
Jak sprawdzić, czy jesteś dotknięty
Ponieważ Shellshock ma już sześć lat, dostępnych jest wiele skanerów podatności. Niektóre z nich są darmowe. Jeden z nich, bashcheck, można pobrać z Githuba.
Dla osób technicznych, wpisanie prostego polecenia w wierszu poleceń Bash również załatwi sprawę:
env X=”() { :;} ; echo Bash is Infected” /bin/sh -c „echo completed”
env X=”() { :} ; echo Bash jest zainfekowany” `which bash` -c „echo completed”
env VAR='() { :;}; echo Bash jest zainfekowany’ bash -c „echo completed”
Jeśli zachęta zwraca komunikat „Bash jest zainfekowany”, czas na aktualizację i poprawkę. Jeśli twoje wyjście nie zwróci komunikatu „Bash jest zainfekowany”, odpowie czymś w rodzaju:
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR’
Test Bash
Jeśli chciałbyś przetestować podatności dla stron internetowych lub konkretnych skryptów CGI, poniższe narzędzie może Ci pomóc: 'ShellShock’ Bash Vulnerability CVE-2014-6271 Test Tool. W jednym z dwóch pól wejściowych wpisz adres URL witryny lub skryptu CGI, który chcesz przetestować, i kliknij niebieskie przyciski.
Czego możemy się nauczyć o zagrożeniach bezpieczeństwa cybernetycznego
Największą lekcją dla przedsiębiorstw jest łatanie systemów.
Zespoły, które mogą skrócić czas łatania, są w lepszej sytuacji, aby przesunąć te zasoby na bardziej naglące problemy związane z bezpieczeństwem. Podczas gdy niektóre firmy uważają, że zarządzanie poprawkami jest bardziej obowiązkiem IT niż bezpieczeństwa, zarządzanie poprawkami musi być zawsze na pierwszym miejscu dla działów bezpieczeństwa, ponieważ jest krytyczne dla postawy bezpieczeństwa firmy.
Jeśli wasze systemy są nadal podatne na ataki, prawdopodobnie istnieją pewne podstawowe problemy operacyjne, którymi należy się zająć. Shellshock to bardzo stara luka, na którą dostępne są łatki dla niemal każdego systemu. Najlepszym sposobem zabezpieczenia się przed tego typu luką jest aktualizowanie systemów na bieżąco, stosując wszystkie poprawki wydane dla tego exploita.
Podczas łatania zasobów, co zazwyczaj jest prostym procesem, należy przyjąć podejście strategiczne.
Łatki dokładnie przetestowane są doskonałym sposobem na zminimalizowanie wpływu na biznes – na przykład w przypadku serwera o znaczeniu krytycznym działającego pod starym systemem operacyjnym. Jeśli system nie może być załatany natychmiast, potencjalne ryzyko związane z luką musi być rozważone w stosunku do wpływu na biznes.
Shellshock jest tylko jedną z długiej listy luk, z którymi przedsiębiorstwo musi sobie poradzić. Zarządzanie pozornie niekończącym się strumieniem podatności jest i zawsze będzie krytyczną strategią, która leży u podstaw cyberbezpieczeństwa.
Lista kontrolna bezpiecznej organizacji
Aby skutecznie zarządzać podatnościami, firmy muszą mieć możliwość osiągnięcia sukcesu w tych trzech obszarach:
- Szybka identyfikacja potencjalnie groźnych podatności: Szybkość jest tutaj wszystkim. Posiadanie wszystkich na tej samej stronie z solidnym planem powinno promować szybszy czas reakcji.
- Określenie poziomu dotkliwości podatności: Znajomość tolerancji organizacji na ryzyko pozwoli określić, jak poważna może być luka. W zależności od infrastruktury sieciowej, niektóre podatności są bardziej szkodliwe niż inne.
- Posiadanie planu działania, który równoważy pilną potrzebę zapewnienia bezpieczeństwa z potencjalnym wpływem na środowiska produkcyjne: Równoważenie bezpieczeństwa z produkcją i produktywnością jest stałą przeszkodą, ale organizacje z najbardziej dobrze zdefiniowanymi planami zarządzania podatnościami zazwyczaj znajdują najlepszą równowagę.
Dla niezależnego badacza bezpieczeństwa Roda Soto, największą lekcją wyniesioną z Shellshock było to, że Internet opiera się na wielu podatnych na ataki aplikacjach i zawsze niesie ze sobą potencjał kompromitacji dużej części jego segmentów.
„Sposobem na zarządzanie tymi potencjalnymi podatnościami w przyszłości jest utrzymanie otwartej i przejrzystej komunikacji pomiędzy deweloperami, opiekunami i specjalistami ds. bezpieczeństwa” – mówi Soto. „Jeśli więc zostanie znaleziona tak rozległa i znacząca luka, koordynacja pomiędzy wszystkimi zainteresowanymi stronami może zostać wykorzystana do załatania lub złagodzenia dotkniętych systemów.”
Nawet w przypadkach, w których Twoja firma odnosi sukcesy w ograniczaniu ryzyka związanego z Shellshock lub jakąkolwiek inną luką, nie możesz zakładać, że Twój plan reagowania jest doskonały. Plan reagowania powinien być żywym, oddychającym dokumentem i powinien być często przeglądany, tak aby organizacja mogła szybko reagować na zagrożenia.
Na koniec, jak w każdym scenariuszu po ataku, istnieją pytania, które należy zadać podczas przeglądu każdej fazy planu.
- Które części planu były udane?
- Które części planu nie były udane?
- Czego nie zrobiliśmy, a teraz zdajemy sobie sprawę, że musieliśmy to zrobić?
- Czego się nauczyliśmy, co pozwoli nam być lepiej przygotowanym na kolejną podatność, która pojawi się na naszej drodze?
Shellshock może i jest starym atakiem, ale dla atakującego spełnia wszystkie kryteria wykorzystania ofiar, którym brakuje odpowiedniej higieny bezpieczeństwa.