Koledzy, którzy używają na swoich serwerach pocztowych Exim wersji 4.87…4.91 — natychmiast zaktualizujcie do wersji 4.92, wcześniej zatrzymując sam Exim, aby uniknąć włamania przez CVE-2019-10149.
Potencjalnie narażonych jest kilka milionów serwerów na całym świecie, a luka oceniana jest jako krytyczna (CVSS 3.0 base score = 9.8/10). Hakerzy mogą uruchamiać na Twoim serwerze dowolne komendy, w wielu przypadkach z uprawnieniami roota.
Proszę upewnić się, że używacie poprawionej wersji (4.92) lub już załatanej.
Lub załatacie istniejącą, patrz wątek .
Aktualizacja dla centos 6: patrz — dla centos 7 również działa, jeśli jeszcze prosto z epel nie dotarło.
UPD: Ubuntu jest dotknięte 18.04 i 18.10, aktualizacja została wydana. Wersje 16.04 i 19.04 nie są dotknięte, chyba że zainstalowane zostały niestandardowe wersje. Szczegóły .
Obecnie opisany tam problem jest aktywnie wykorzystywany (przez bota, przypuszczam), zauważyłem u siebie na niektórych serwerach (działających na 4.91) infekcję.
Dalej czytać jest istotne tylko dla tych, którzy już „wpadli” — trzeba albo przenieść wszystko na czystą VPS z nowym oprogramowaniem, albo szukać rozwiązania. Spróbujemy? Napiszcie, jeśli ktoś może pokonać tego malware.
Jeśli jesteś użytkownikiem Exim i czytasz to, a wciąż się nie zaktualizowałeś (nie upewniłeś się, że masz 4.92 lub załatane wersje), proszę zatrzymaj się i biegnij aktualizować.
Dla już wpadłych — kontynuujemy…
UPD: i daje słuszną radę:
Złośliwych programów może być nieskończoność. Uruchamiając lekarstwo nie od tego i oczyszczając kolejkę, użytkownik ani nie wyleczy się, ani być może nie dowie się, od czego musi się leczyć.
Infekcja jest zauważalna tak: [kthrotlds] obciąża procesor; na słabej VDS na 100%, na słabszych serwerach, ale jest to zauważalne.
Po infekcji złośliwy program usuwa wpisy w cronie, wpisując tylko siebie, uruchamiając co 4 minuty, przy tym plik crontaba czyni immutable. Crontab -e nie może zapisać zmian, wyświetla błąd.
Immutable można zdjąć na przykład tak, po czym należy usunąć linię komendy (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Następnie w edytorze crontab (vim) usuwamy linię i zapisujemy:dd
:wq
Jednak jakiś aktywny proces zapisuje to z powrotem, próbuję to zrozumieć.
Jednocześnie wisi wiele aktywnych wgetów (lub curlów) na adresy z skryptu instalatora (patrz poniżej), na razie je zabijam, ale znowu się uruchamiają:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Skrypt instalatora trojana znaleziony tutaj (centos): /usr/local/bin/nptd… nie publikuję w obawie, ale jeśli ktoś jest zarażony i zna się na skryptach shellowych, proszę dokładniej go zbadać.
Będę uzupełniać w miarę aktualizacji informacji.
UPD 1: Usunięcie plików (z wcześniejszym chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nie pomogło, podobnie jak zatrzymanie usługi — musiałem w tymczasowo usunąć crontab (zmienić nazwę pliku bin).
UPD 2: Instalator trojana czasami był również w innych miejscach, pomogło wyszukiwanie według rozmiaru:
find / -size 19825c
UPD 3: Uwaga! Oprócz wyłączenia selinux, trojan również dodaje swój klucz SSH do ${sshdir}/authorized_keys! I aktywuje następujące pola w /etc/ssh/sshd_config, jeśli nie zostały one jeszcze zapisane jako YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Podsumowując na chwilę obecną: wyłączamy exim, cron (z uprawnieniami root), pilnie usuwamy klucz trojana z ssh i poprawiamy konfigurację sshd, restartujemy sshd! I to na razie nie jest pewne, że to pomoże, ale bez tego jest naprawdę źle.
Ważne informacje z komentarzy dotyczące poprawek/aktualizacji wyciągnąłem na początek notatki, aby czytający zaczynali od nich.
UPD 5: że złośliwe oprogramowanie zmieniło hasła w WordPressie.
UPD 6: , testujemy! Po ponownym uruchomieniu lub wyłączeniu lekarstwa wydaje się, że znika, ale na razie przynajmniej tak.
Kto znajdzie (lub zrobi) stabilne rozwiązanie, proszę pisać, pomożecie wielu.
UPD 7: pisze:
Jeśli jeszcze tego nie powiedziano, wirus odnawia się dzięki nie wysłanemu e-mailowi w exim, przy ponownej próbie wysłania e-maila się odzyskuje, spójrzcie w /var/spool/exim4
Wszystką kolejkę exim można wyczyścić tak:
exipick -i | xargs exim -Mrm
Sprawdzanie liczby wpisów w kolejce:
exim -bpc
UPD 8: Znowu : FirstVDS zaproponowali swoją wersję skryptu do leczenia, testujmy to!
UPD 9: Wydaje się, że pracuje, dziękuję za skrypt!
Nie zapomnijcie, że serwer był już skompromitowany i przestępcy mogli zdążyć wprowadzić jeszcze inne nietypowe złośliwe oprogramowanie (nie zapisane w dropperze).
Dlatego najlepiej przejść na czysto zainstalowany serwer (vds), lub przynajmniej na bieżąco śledzić temat — jeśli będą jakieś nowości, piszcie w komentarzach tutaj, ponieważ nie wszyscy będą przechodzić na świeżą instalację…
UPD 10: Jeszcze raz dziękuję : przypomina, że zarażają się nie tylko serwery, ale na przykład i Raspberry Pi, różne wirtualki… Więc po ocaleniu serwerów nie zapomnijcie uratować swoich konsol do gier, robotów itd.
UPD 11: Od ważna uwaga dla «leczących ręcznie»:
(po zastosowaniu danej metody walki z tym złośliwym oprogramowaniem)
należy koniecznie zrestartować — malware siedzi gdzieś w otwartych procesach i, odpowiednio, w pamięci, i zapisuje się na nowo w cron co 30 sekund
UPD 12: u siebie w kolejce exim innego(?) złośliwego oprogramowania i radzi najpierw dokładnie zbadać swoją konkretną problematykę przed rozpoczęciem leczenia.
UPD 13: szybciej przejść na czysty system i przenosić pliki bardzo ostrożnie, ponieważ malware już jest publicznie dostępny i może być używany przez innych, mniej oczywistymi i bardziej niebezpiecznymi sposobami.
UPD 14: uspokajając się tym, że mądrzy ludzie nie uruchamiają z roota — jeszcze jedno :
Nawet jeśli działa to nie z roota, dochodzi do włamania… U mnie na OrangePi jest debian jessie UPD: stretch, exim uruchomiony od Debian-exim i mimo to doszło do włamania, skasowało cron i inne.
UPD 15: przy przejściu na czysty serwer z skompromitowanego nie zapominajcie o higienie, :
Podczas przenoszenia danych zwróćcie uwagę nie tylko na pliki wykonywalne lub konfiguracyjne, ale także na wszystko, co może zawierać złośliwe komendy (na przykład w MySQL może to być CREATE TRIGGER lub CREATE EVENT). Również nie zapominajcie o .html, .js, .php, .py i innych publicznych plikach (w idealnym przypadku te pliki, jak i inne dane, powinny być przywrócone z lokalnego lub innego zaufanego repozytorium).
UPD 16: i : w systemie w portach była jedna wersja exim, a w rzeczywistości wykonywana była inna.
Więc wszyscy po aktualizacji powinni upewnić się że używają właśnie nowej wersji!
exim --versionW konkretnej sytuacji wspólnie się z tym uporaliśmy.
Na serwerze używany był DirectAdmin i stał jego stary pakiet da_exim (starej wersji, bez luk w zabezpieczeniach).
W rzeczy samej, za pomocą menedżera pakietów custombuild w DirectAdmin zainstalowano nowszą wersję exim, która jest już podatna na ataki.
W tej konkretnej sytuacji pomogła również aktualizacja przez custombuild.
Nie zapominajcie robić kopii zapasowych przed takimi eksperymentami, a także upewnijcie się, że przed i po aktualizacji wszystkie procesy exim starej wersji i nie "utknęły" w pamięci.
Źródło: habr.com
