Koledzy, którzy używają Exima w wersjach 4.87...4.91 na swoich serwerach pocztowych - pilnie zaktualizujcie go do wersji 4.92, zatrzymując najpierw samego Exima, aby uniknąć włamania się przez CVE-2019-10149.
Kilka milionów serwerów na całym świecie jest potencjalnie podatnych na ataki, a luka jest oceniana jako krytyczna (bazowy wynik CVSS 3.0 = 9.8/10). Atakujący mogą uruchamiać dowolne polecenia na serwerze, w wielu przypadkach z poziomu konta root.
Upewnij się, że używasz wersji poprawionej (4.92) lub takiej, która została już załatana.
Lub załataj istniejący, zobacz wątek .
Aktualizacja dla CentOS 6: cm. — w przypadku centos 7 działa również, jeśli nie dotarło jeszcze bezpośrednio od Epel.
UPD: Problem dotyczy Ubuntu 18.04 i 18.10, wydano dla nich aktualizację. Nie ma to wpływu na wersje 16.04 i 19.04, chyba że zainstalowano w nich opcje niestandardowe. Więcej szczegółów .
Teraz opisany tam problem jest aktywnie wykorzystywany (prawdopodobnie przez bota), zauważyłem infekcję na niektórych serwerach (działających w wersji 4.91).
Dalsza lektura jest istotna tylko dla tych, którzy już to „dostali” - musisz albo przenieść wszystko na czysty VPS ze świeżym oprogramowaniem, albo poszukać rozwiązania. Powinniśmy spróbować? Napisz, czy komukolwiek uda się pokonać to złośliwe oprogramowanie.
Jeśli ty, będąc użytkownikiem Exima i czytając to, nadal nie dokonałeś aktualizacji (nie upewniłeś się, że dostępna jest wersja 4.92 lub poprawiona), zatrzymaj się i uruchom, aby zaktualizować.
Dla tych, którzy już tam dotarli, kontynuujmy…
UPD: i daje właściwą radę:
Może istnieć ogromna różnorodność złośliwego oprogramowania. Wprowadzając lek na niewłaściwy lek i oczyszczając kolejkę, użytkownik nie zostanie wyleczony i może nie wiedzieć, na co należy go leczyć.
Infekcja jest zauważalna w następujący sposób: [kthrotlds] ładuje procesor; na słabym VDS-ie jest to 100%, na serwerach jest słabiej ale zauważalnie.
Po infekcji złośliwe oprogramowanie usuwa wpisy cron, rejestrując się tam tylko i uruchamiając je co 4 minuty, jednocześnie sprawiając, że plik crontab jest niezmienny. Crontab -tj nie można zapisać zmian, pojawia się błąd.
Niezmienny można usunąć na przykład w ten sposób, a następnie usunąć wiersz poleceń (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Następnie w edytorze crontab (vim) usuń linię i zapisz:dd
:wq
Jednak niektóre aktywne procesy ponownie się nadpisują, już to rozumiem.
Jednocześnie na adresach ze skryptu instalacyjnego wisi kilka aktywnych wgetów (lub loków) (patrz poniżej). Na razie je usuwam w ten sposób, ale zaczynają od nowa:
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}'`
Znalazłem skrypt instalacyjny trojana tutaj (centos): /usr/local/bin/nptd... Nie publikuję go, aby tego uniknąć, ale jeśli ktoś jest zainfekowany i rozumie skrypty powłoki, proszę przestudiować go dokładniej.
Dodam w miarę aktualizacji informacji.
UPD 1: Usuwanie plików (ze wstępnym chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nie pomogło, ani zatrzymanie usługi - musiałem crontab, na razie całkowicie go wyrwij (zmień nazwę pliku bin).
UPD 2: Instalator trojana czasami ukrywał się także w innych miejscach, pomogło wyszukiwanie według rozmiaru:
znajdź / -rozmiar 19825c
UPD 3: Ostrzeżenie! Oprócz wyłączania selinuksa trojan dodaje także własne Klucz SSH w ${sshdir}/authorized_keys! I aktywuje następujące pola w /etc/ssh/sshd_config, jeśli nie zostały jeszcze ustawione na TAK:
PermitRootLogin tak
RSAAuwierzytelnianie tak
PubkeyAuthentication tak
echo UżyjPAM tak
Uwierzytelnianie hasłem tak
UPD 4: Podsumowując na razie: wyłącz Exim, cron (z rootami), pilnie usuń klucz trojana z ssh i edytuj konfigurację sshd, uruchom ponownie sshd! I nie jest jeszcze jasne, czy to pomoże, ale bez tego jest problem.
Ważne informacje przeniosłem z komentarzy na temat łatek/aktualizacji na początek notki, tak aby czytelnicy zaczęli od nich.
UPD 5: że szkodliwe oprogramowanie zmieniło hasła w WordPressie.
UPD 6: , przetestujmy! Po ponownym uruchomieniu lub wyłączeniu lek wydaje się znikać, ale na razie to wszystko.
Ktokolwiek stworzy (lub znajdzie) stabilne rozwiązanie, proszę napisać, pomożesz wielu osobom.
UPD 7: pisze:
Jeśli jeszcze nie powiedziałeś, że wirus został wskrzeszony dzięki niewysłanemu listowi w Eximie, przy ponownej próbie wysłania listu zostaje on przywrócony, zajrzyj do /var/spool/exim4
Możesz wyczyścić całą kolejkę Exima w ten sposób:
exipick -i | xargs exim - Pan
Sprawdzanie ilości wpisów w kolejce:
exim-bpc
UPD 8: Znowu : FirstVDS zaoferowało swoją wersję skryptu leczenia, przetestujmy ją!
UPD 9: Wygląda na to działa, Dzięki za scenariusz!
Najważniejszą rzeczą jest, aby nie zapomnieć, że serwer został już przejęty i atakującym udało się umieścić bardziej nietypowe, paskudne rzeczy (niewymienione w dropperze).
Dlatego lepiej przenieść się na całkowicie zainstalowany serwer (vds), lub chociaż w dalszym ciągu monitorować temat - jeśli pojawi się coś nowego, pisz tutaj w komentarzach, bo oczywiście nie każdy przeniesie się na nową instalację...
UPD 10: Jeszcze raz dziękuję : przypomina, że zainfekowane są nie tylko serwery, ale także Raspberry Pii wszelkiego rodzaju maszyny wirtualne... Więc po zapisaniu serwerów nie zapomnij zapisać swoich konsol wideo, robotów itp.
UPD 11: Od Ważna uwaga dla uzdrowicieli ręcznych:
(po zastosowaniu tej czy innej metody zwalczania tego złośliwego oprogramowania)
Zdecydowanie musisz zrestartować komputer - złośliwe oprogramowanie znajduje się gdzieś w otwartych procesach i odpowiednio w pamięci i co 30 sekund zapisuje sobie nowy do cron
UPD 12: Exim ma w kolejce inne(?) złośliwe oprogramowanie i radzi, abyś najpierw przestudiował konkretny problem, zanim rozpoczniesz leczenie.
UPD 13: raczej przejdź do czystego systemu i przesyłaj pliki bardzo ostrożnie, ponieważ Szkodnik jest już publicznie dostępny i można go wykorzystać w inny, mniej oczywisty i bardziej niebezpieczny sposób.
UPD 14: zapewnienie siebie, że mądrzy ludzie nie uciekają przed rootem – jeszcze jedno :
Nawet jeśli to nie działa z roota, dochodzi do włamań... Mam debian jessie UPD: rozciągnij na moim OrangePi, Exim działa z Debian-exim i nadal zdarzało się hackowanie, utracone korony itp.
UPD 15: przenosząc się na czysty serwer z skompromitowanego, nie zapomnij o higienie, :
Podczas przesyłania danych zwracaj uwagę nie tylko na pliki wykonywalne lub konfiguracyjne, ale także na wszystko, co może zawierać złośliwe polecenia (na przykład w MySQL może to być CREATE TRIGGER lub CREATE EVENT). Nie zapomnij także o plikach .html, .js, .php, .py i innych plikach publicznych (najlepiej te pliki, podobnie jak inne dane, powinny zostać przywrócone z lokalnego lub innego zaufanego magazynu).
UPD 16: и : system miał zainstalowaną w portach jedną wersję Exima, ale w rzeczywistości działała inna.
Więc wszyscy po aktualizacji powinieneś się upewnić że używasz nowej wersji!
exim --versionWspólnie wyjaśniliśmy ich specyficzną sytuację.
Serwer korzystał z DirectAdmin i jego starego pakietu da_exim (stara wersja, bez luki).
W tym samym czasie, za pomocą menedżera pakietów Custombuild DirectAdmin, zainstalowano nowszą wersję Exima, która była już podatna na ataki.
W tej konkretnej sytuacji pomogła również aktualizacja za pomocą niestandardowej kompilacji.
Nie zapomnij zrobić kopii zapasowych przed takimi eksperymentami, a także upewnij się, że przed/po aktualizacji wszystkie procesy Exima są w starej wersji i nie „utknęły” w pamięci.
Źródło: www.habr.com