Złośliwe oprogramowanie o nazwie XOR.DDoS pierwszy raz zauważyli we wrześniu badacze organizacji Malware Must Die. Jak donosi FireEye, pierwsze doniesienia na temat podobnych ataków są jednak starsze, pochodzą z końca stycznia. Celem są systemy osadzone pracujące pod kontrolą Linuksa, atak rozpoczyna się od rozpoznania zdalnego dostępu za pomocą protokołu SSH i łamania haseł metodą brute-force. Połączenia IP przychodzą z adresów zarejestrowanych na przedsiębiorstwo Hee Thai Limited, zarejestrowane w Hong Kongu i wykorzystują komendy zdalne SSH, które mają być wykonane z uprawnieniami systemowymi.

Sprytne połączenie, długa komenda, malware na żądanie

Napastnicy wykorzystali w praktyce dwie istotne słabości systemów osadzonych – słabe hasła oraz brak szczegółowego logowania zdalnych komend SSH. Oprogramowanie łamiące zabezpieczenia próbuje odgadnąć hasło użytkownika root za pomocą różnych technik słownikowych oraz popularnych list haseł z różnych ataków. Badacze FireEye obserwowali ponad 20 tysięcy prób logowania per serwer na dobę oraz w sumie ponad milion ataków od połowy grudnia do końca stycznia. Ataki te były również widoczne podczas zbierania danych na potrzeby badań bezpieczeństwa ruchu sieciowego, prowadzonych przez IDG Poland w drugim kwartale 2015r.

Zobacz również:

• Dzięki tej umowie polska policja zyska wiedzę i narzędzia zapobiegające cyfrowym zagrożeniom
• Ta inicjatywa ma ułatwić firmom zadanie wdrażania systemów AI

Po odgadnięciu hasła, użytkownicy uzyskują dostęp na poziomie uprawnień roota i następnie wysyłają skomplikowaną komendę SSH. Komenda ta jest bardzo długa (niekiedy ponad 6000 znaków) i zawiera wiele poleceń powłoki systemu wykonywanych w odpowiedniej kolejności. Poszczególne komendy, separowane średnikami, pobierają i wykonują różne skrypty, które w efekcie swojej pracy utworzą łańcuch zbudowania i pobrania złośliwego oprogramowania specjalnie skompilowanego na potrzeby każdego z ataków osobno.

Zdalna komenda zamiast sesji terminala

Podczas ataków napastnicy wykorzystują zdalne komendy SSH (wykonywane jako jedno polecenie), co ma swoje istotne implikacje. Jak powszechnie wiadomo, serwer OpenSSH nie zapisuje takich komend do logu, nawet przy najwyższym poziomie dokładności logowania (DEBUG3). Narzędzia zapisujące zdarzenia w sesji terminalowej nie również nie działają, bo przy omawianym wywołaniu SSH nie jest otwierana sesja TTY. Śladów nie znajdzie się również ani za pomocą komendy last, ani lastlog. Jedynym sposobem w przypadku typowej instalacji Linuksa na serwerach lub stacjach roboczych jest instalacja dedykowanego narzędzia audytowego, takiego jak acct (Debian/Ubuntu) lub psacct (RedHat/CentOS), a następnie użycie komendy lastcomm, która umożliwi odczytanie zapisu audytowego każdego użytkownika w systemie. Niestety narzędzia te nie są instalowane w systemach osadzonych.

Jak powstaje moduł do jądra systemu

Mimo wielkiej różnorodności systemów, włamywacze znaleźli sposób na zbudowanie kodu rootkita instalowanego jako moduł do jądra (LKM) – skrypty uruchamiane w zdalnych poleceniach pobierają nagłówki jądra z infekowanych systemów, ustalają i wysyłają oznaczenie „vermagic” z istniejących modułów jądra. Ta informacja po przesłaniu na serwer kontroli budowy kodu umożliwia automatyczne zbudowanie (przygotowanie, kompilacja, konsolidacja, pozostałe czynności), a następnie wysłanie rootkita specjalnie skompilowanego pod kątem danego urządzenia. Skomplikowana infrastruktura budowy kodu pod kątem każdego z urządzeń z osobna umożliwia w praktyce zbudowanie rootkitów w formie ładowalnego modułu LKM dla różnych architektur oraz wersji jądra.

Malware zainstalowane w przejętych systemach posłuży później do uruchomienia rozproszonych ataków odmowy obsługi. Oprogramowanie to potrafi także pobrać i uruchomić dowolny plik, a zatem posiada możliwość automatycznej aktualizacji swojego kodu. Jak dotąd zaobserwowano na żywo dwie główne wersje XOR.DDoS. Częścią tego kodu jest rootkit w formie modułu jądra, który ma za zadanie ukrywać procesy, pliki i porty związane z pracą całego oprogramowania. Urządzenia osadzone, z natury dysponują ograniczonymi zasobami i rootkit jest niezbędny, by wykrycie faktu przejęcia urządzenia przez włamywaczy było możliwie trudne.

Badacze FireEye wyjaśniają: „w odróżnieniu od typowych prostych botów służących do ataków odmowy obsługi, XOR.DDoS jest jednym z bardziej skomplikowanych złośliwych programów, które mogą zaatakować Linuksa. Jest to oprogramowanie wieloplatformowe, napisane w C/C++ i przeznaczone do kompilacji dla platform x86, ARM i innych”.

Urządzenia osadzone trudno zabezpieczyć

Małe urządzenia osadzone oraz niewielkie urządzenia sieciowe takie jak routery i punkty dostępowe są bardziej podatne na łamanie haseł SSH niż normalne stacje robocze. Użytkownicy na pewno będą mieli problemy z właściwym zabezpieczeniem. Skala problemu nadal rośnie. Coraz więcej urządzeń jest skonfigurowanych do zdalnej administracji i dostępnych przez Internet. W większości przypadków użytkownicy nie wprowadzili żadnych ograniczeń na adresy IP, z których na router lub kamerkę można się połączyć. W 2012r. anonimowy pentester poinformował o tym, że w rozpoczętym przez niego projekcie Internet Census 2012, w którym miało się odbyć skanowanie całej puli adresowej Internetu, wykorzystał 420 tysięcy urządzeń osadzonych, które nie miały w ogóle ustawionych haseł do zdalnego dostępu przez telnet lub korzystały z domyślnych ustawień. Liczba urządzeń dostępnych przez SSH i korzystających przy tym ze słabych haseł, które będą złamane w wyniku skomplikowanych słownikowych ataków brute-force może być znacznie większa.

Jak utrzymać bezpieczny serwer SSH

Specjaliści podkreślają, że podstawowy problem wynika z możliwości samego połączenia z zewnątrz w zestawieniu ze słabymi hasłami lub niedostatkami technicznymi. Problem dotyczy każdego serwera SSH, nie tylko tego, który działa w urządzeniach osadzonych. Można minimalizować ryzyko włamania na serwer SSH, wprowadzając kilka zasad:

1. Zadbać o szybką i sprawną aktualizację oprogramowania.
2. Wprowadzić zasadę ograniczania połączeń z zewnątrz kierowanych do interfejsu administracyjnego. Wprowadzić listy kontroli dostępu, skonfigurować SSH w taki sposób, by odrzucał połączenia przychodzące spoza puli dozwolonych adresów IP. Wiele routerów i kamer pozwala na wprowadzenie podobnych obostrzeń.
3. Serwery SSH należy skonfigurować, by korzystały z uwierzytelnienia za pomocą kluczy kryptograficznych zamiast haseł. Jeśli hasła są niezbędne, należy zadbać o ich odpowiednią złożoność i dostatecznie częstą zmianę.
4. Wyłączyć bezpośrednie logowanie na użytkownika root (dyrektywa konfiguracyjna: PermitRootLogin), przejść na korzystanie z komendy su (nie sudo).
5. Użyć oprogramowania takiego jak fail2ban lub DenyH0sts, które wykrywa i blokuje łamanie haseł metodą brute-force. Można także ograniczyć liczbę połączeń do danego serwera SSH w wybranym przedziale czasu za pomocą narzędzia ufw
6. Przenieść port SSH z domyślnego 22 na inny wybrany, może być także powyżej 1024.
7. Użyć dwuskładnikowego uwierzytelnienia za pomocą HOTP lub TOTP.
8. Jeśli w samym urządzeniu trudno wprowadzić powyższe restrykcje, warto ochronić urządzenia, umieszczając je wewnątrz wirtualnych sieci prywatnych. Niektórzy administratorzy korzystają do tego celu z sieci Tor, umieszczając serwer SSH wewnątrz domeny .onion. Jest to dość kontrowersyjna metoda, ale na pewno ogranicza dostęp z publicznie dostępnej sieci Internet.
9. Zadbać, by żadne z urządzeń w danej podsieci nie było listowane w wyszukiwarkach dedykowanych do znajdowania podatnych serwisów (na przykład SHODAN).
10. Wprowadzić centralne logowanie zdarzeń, uruchomić narzędzia wykrywania i prewencji, poszukiwać symptomów włamań.