LINUX.ORG.RU

Помогите понять причину взлома

 ,


0

1

Два вопроса к уважаемым специалистам по безопасности в линуксе.

Есть машина с Debian 12.9 с открытым портом 22, на ней много пользователей без прав рута и один с правами рута, и предполагается, что пароль пользователя с правами рута не украден. Секьюрити-обновления установлены.

pstree показывает следующее:

systemd(1)-+-PysNI(600637)-+-sh(1007684)---python3(1007685)---su(1007686)---edbEqxos(1007687)---{edbEqxos}(1007689)
           |               |-sh(1007934)---python3(1007935)---su(1007936)---sh(1007937)
           |               `-{PysNI}(601368)



Файл PysNI находился в /tmp и самоудалился после запуска:
$ ps ax | grep PysNI
 600637 ?        Sl     2:03 /tmp/PysNI


Аналогичная история с файлом edbEqxos, он был запущен из питоновского скрипта:

# ps ax | grep /tmp/edbEqxos
[...]
1007685 ?        S      0:00 python3 -c import os, pty, base64;read = lambda fd: os.read(fd, 1024);write = lambda fd: base64.b64decode('YWQ4N3F2eTUyMGthbGk=');command = 'su - USERNAME -c /tmp/edbEqxos';os.close(0);pty.spawn(command.split(), read, write);
1007687 ?        Ssl    1:16 /tmp/edbEqxos

(USERNAME — имя одного из пользователей без прав рута.)

Программа открыла канал на какой-то внешний адрес:

# lsof -p 1007687
COMMAND      PID   USER   FD      TYPE    DEVICE SIZE/OFF NODE NAME
[...]
edbEqxos 1007687 USERNAME  txt       REG       8,1  1068952 7375607 /tmp/edbEqxos (deleted)
edbEqxos 1007687 USERNAME    0u      CHR    136,35      0t0 38 /dev/pts/35
edbEqxos 1007687 USERNAME    1u      CHR    136,35      0t0 38 /dev/pts/35
edbEqxos 1007687 USERNAME    2u      CHR    136,35      0t0 38 /dev/pts/35
edbEqxos 1007687 USERNAME    3u     IPv4 642434257      0t0 TCP SERVER_IP:54442->d3824.colo.hc.ru:4433 (CLOSE_WAIT)
edbEqxos 1007687 USERNAME    4u  a_inode      0,14        0 55 [eventfd:147]
[...]


Итак, два вопроса к уважаемым специалистам.

1. Это уже повышение привилегий или ещё нет?
2. В чём первопричина взлома, как им удалось заставить systemd запустить свой процесс?

Спасибо.


systemd становится родителем процесса, если процесс запущен с nohup.

Если su - USERNAME выполнился, значит, пароль пользователя утёк. Какую именно информацию таскал этот скрипт — надо восстанавливать его, пока он не завершил работу, но он, скорее всего, обфусцирован. С высокой долей вероятности там был майнер или программа для сканирования диапазона IP, но это не точно.

Повышения привилегий — надо было делать ps aux вместо ps ax, тогда бы пользователя показали, но скорее всего, опять же, не имело места быть.

Пароль USERNAME менять в любом случае. Ещё полезно прочитать про auditd и включить его, если залезут повторно, у тебя будет намного больше информации.

Aceler ★★★★★
()
Ответ на: комментарий от anonymous

Если пользователя взломали, украв его пароль — это не страшно, легко исправить, но хотелось бы понять, имеют ли взломщики какие-то ещё возможности, повысили ли они права до рута или работают с правами пользователя.

ringill
() автор топика

base64.b64decode('YWQ4N3F2eTUyMGthbGk=') => 'ad87qvy520kali'

ad87qvy520kali - дело раскрыто, Ватсон.

Повышения привилегий пока не видно, но пароль юзеру смените и понаблюдайте за его активностью.

Obezyan
()
Ответ на: комментарий от unDEFER

Вот такое

# ls -l /proc/600637/fd/
total 0
lr-x------ 1 USERNAME USERNAME 64 Mar 20 15:22 0 -> /dev/null
l-wx------ 1 USERNAME USERNAME 64 Mar 20 15:22 1 -> 'pipe:[642443617]'
l-wx------ 1 USERNAME USERNAME 64 Mar 20 15:22 11 -> 'pipe:[646058579]'
lr-x------ 1 USERNAME USERNAME 64 Mar 20 15:22 12 -> 'pipe:[646058580]'
l-wx------ 1 USERNAME USERNAME 64 Mar 20 15:22 2 -> 'pipe:[642443618]'
lrwx------ 1 USERNAME USERNAME 64 Mar 20 15:22 3 -> 'socket:[662868216]'
lrwx------ 1 USERNAME USERNAME 64 Mar 20 15:22 4 -> 'anon_inode:[eventfd]'
lr-x------ 1 USERNAME USERNAME 64 Mar 20 15:22 5 -> 'pipe:[646540545]'
lr-x------ 1 USERNAME USERNAME 64 Mar 20 15:22 6 -> 'pipe:[646058578]'
l-wx------ 1 USERNAME USERNAME 64 Mar 20 15:22 8 -> 'pipe:[646540546]'
lr-x------ 1 USERNAME USERNAME 64 Mar 20 15:22 9 -> 'pipe:[646540547]'
# ls -l /proc/1007687/fd/
total 0
lrwx------ 1 root root 64 Mar 20 15:21 0 -> /dev/pts/35
lrwx------ 1 root root 64 Mar 20 15:21 1 -> /dev/pts/35
l-wx------ 1 root root 64 Mar 20 15:21 10 -> 'pipe:[646540547]'
lrwx------ 1 root root 64 Mar 20 15:21 2 -> /dev/pts/35
lrwx------ 1 root root 64 Mar 20 15:21 3 -> 'socket:[642434257]'
lrwx------ 1 root root 64 Mar 20 15:21 4 -> 'anon_inode:[eventfd]'
lr-x------ 1 root root 64 Mar 20 15:21 7 -> 'pipe:[646540546]'
l-wx------ 1 root root 64 Mar 20 15:21 8 -> 'pipe:[646540546]'
lr-x------ 1 root root 64 Mar 20 15:21 9 -> 'pipe:[646540547]'

ringill
() автор топика
Ответ на: комментарий от ringill

Не, 1007687 это именно процесс edbEqxos, а вам нужен именно shell, который его читает. По идее в данном случае это 1007686 (процесс su).

А так наверное lsof’ом или каким-нибудь fuser можно удерживающий PID узнать.

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER
# ls -l /proc/1007686/fd/
total 0
lrwx------ 1 root root 64 Mar 20 15:19 0 -> /dev/pts/35
lrwx------ 1 root root 64 Mar 20 15:19 1 -> /dev/pts/35
l-wx------ 1 root root 64 Mar 20 15:19 10 -> 'pipe:[646540547]'
lrwx------ 1 root root 64 Mar 20 15:19 2 -> /dev/pts/35
lrwx------ 1 root root 64 Mar 20 15:19 3 -> 'socket:[642434257]'
lrwx------ 1 root root 64 Mar 20 15:19 4 -> 'socket:[646495516]'
lr-x------ 1 root root 64 Mar 20 15:19 7 -> 'pipe:[646540546]'
l-wx------ 1 root root 64 Mar 20 15:19 8 -> 'pipe:[646540546]'
lr-x------ 1 root root 64 Mar 20 15:19 9 -> 'pipe:[646540547]'
ringill
() автор топика
Ответ на: комментарий от ringill

Похоже это не скрипт никакой, а exe-шник.

Проверить можно как сказал @firkax ls -l /proc/1007687/exe. Если там ссылка на /tmp/edbEqxos, то восстановить можно командой

$ cat /proc/1007687/exe > /tmp/edbEqxos.restored

Только вряд ли это что-то даст, если только вы не собираете препарировать его средствами отладки и/или дизассемблинга.

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER

Спасибо! Исполняемые файлы сохранил.

Питоны открывали следующее:

# ls /proc/1007685/fd -l 
total 0
lrwx------ 1 USERNAME USERNAME 64 Mar 20 16:33 0 -> /dev/ptmx
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:33 1 -> pipe:[646540547]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:33 10 -> pipe:[646540547]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:33 2 -> pipe:[646540545]
lrwx------ 1 USERNAME USERNAME 64 Mar 20 16:33 3 -> socket:[642434257]
lr-x------ 1 USERNAME USERNAME 64 Mar 20 16:33 7 -> pipe:[646540546]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:33 8 -> pipe:[646540546]
lr-x------ 1 USERNAME USERNAME 64 Mar 20 16:33 9 -> pipe:[646540547]


# ls /proc/1007935/fd -l 
total 0
lrwx------ 1 USERNAME USERNAME 64 Mar 20 16:34 0 -> /dev/ptmx
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:34 1 -> pipe:[646058580]
lr-x------ 1 USERNAME USERNAME 64 Mar 20 16:34 10 -> pipe:[646058579]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:34 11 -> pipe:[646058579]
lr-x------ 1 USERNAME USERNAME 64 Mar 20 16:34 12 -> pipe:[646058580]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:34 13 -> pipe:[646058580]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:34 2 -> pipe:[646058578]
lrwx------ 1 USERNAME USERNAME 64 Mar 20 16:34 3 -> socket:[642434257]
lr-x------ 1 USERNAME USERNAME 64 Mar 20 16:34 5 -> pipe:[646540545]
l-wx------ 1 USERNAME USERNAME 64 Mar 20 16:34 8 -> pipe:[646540546]
lr-x------ 1 USERNAME USERNAME 64 Mar 20 16:34 9 -> pipe:[646540547]

ringill
() автор топика
Ответ на: комментарий от unDEFER

… может быть интересно что ещё открыли python3 …

Там уже внешнее управление: загружаются скрипты/бинарники и запускаются, через пайп или из /tmp. Весь процесс надо логировать.

anonymous
()

Debian 12.9
портом 22
много пользователей

А неудивительно.

Сервер скомпрометирован, продумывай политики безопасности и переустанавливай.

Квотирования, apparmor и контейнеризация в помощь.

hargard ★★★
()

Помогите понять причину взлома

  • Использование паролей, а не ключей.
  • Использование стандартного порта SSH. Нестандартный порт от прошаренных ботнетов конечно не поможет, но долбёжку в SSH сократит в разы.
ALiEN175
()
Ответ на: комментарий от ringill

Нет, а с чем связан вопрос?

Большое количество пользователей с доступом по ssh на 22 порту, которые не переживают за сохранность своих паролей. Наверняка сервер скомпрометирован, а если нет, то вопрос времени.

В вашем случае лучше использовать Cloudlinux. Там защита реализована на уровне ядра, каждый пользователь в клетке.

Aleksandra
()
Ответ на: комментарий от Aleksandra

Спасибо, а какой смысл вложен в слова «сервер скомпрометирован»? Что конкретно случится на данном сервере (и не случится на Cloudlinux) в результате того, что пароль непривилегированного пользователя (уже отключенного к настоящему моменту) попал в руки взломщиков?

Многие в треде упоминают скомпрометированность, и хочется понять мотивацию, почему из-за взлома одного пользователя следует идти на такие радикальные меры.

ringill
() автор топика
Последнее исправление: ringill (всего исправлений: 1)
Ответ на: комментарий от ringill

Что конкретно случится на данном сервере (и не случится на Cloudlinux)

В Cloudlinux есть инструмент CageFS (собственно клетка). Для каждого пользователя создает свою собственную, изолированную от других пользователей и корневой ФС, виртуальную файловую систему. Это позволяет ограничить доступ процессов одного пользователя к данным других пользователей и самого сервера.

Aleksandra
()
Ответ на: комментарий от ringill

Многие в треде упоминают скомпрометированность, и хочется понять мотивацию, почему из-за взлома одного пользователя следует идти на такие радикальные меры.

Если хакеры получили доступ не только к пользователю, а всей системе, то обнаружив что их раскрыли могут запросто сделать rm -rf всему до чего дотянутся, в том числе и на соседних серверах, например, если у кого-то в хомяке ключик лежит.

masa ★★
()
Ответ на: комментарий от masa

Как бы да, но домашние директории открыты в лучшем случае на чтение, а ключи лежат в .ssh, которые всегда закрыты от всех других пользователей, но идея ясна.

ringill
() автор топика
Ответ на: комментарий от anonymous

Левый бинарь Васи не запустишь никак, ни через интерпритаторы ни через ld. Это фундаментальное требование безопасности UNIX.

Левый скрипт, через интерпритаторы запустить Васи можно. Здесь стоит ограничить DAC доступ к интерпретаторам:

chown root:python /usr/bin/python* chmod o-rwx /usr/bin/python*

И в группу python добавить необходимых пользователей.

anonymous
()
Ответ на: комментарий от anonymous

Левый бинарь в системе запускатся не должен:

# cp --preserve=all /bin/ls /tmp

# /bin/ls
работает
# /tmp/ls
-bash: /tmp/ls: Permission denied

# /lib/ld-linux-x86-64.so.2 /bin/ls
работает
# /lib/ld-linux-x86-64.so.2 /tmp/ls
/tmp/ls: error while loading shared libraries: /tmp/ls: failed to map segment from shared object

https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309

anonymous
()
Ответ на: комментарий от anonymous

дыру с ld.so прикрыли, это не новость

Где прикрыли? А дыра была? Все осталось на своих местах. Где использовался noexec, nodev, nosuid и была правильно организована работа с интерпретатором ld там никогда и не было дыры. А в остальных дыры как были так их и никто не прикрывал.

anonymous
()

Насколько я помню, если в SonarQube включены флаги безопасности, то он начнет выдавать предупреждения при записи и чтении из общедоступного каталога /tmp.

Patifon_Kakao
()
Ответ на: комментарий от anonymous

Была и есть. Просто дёрнуть ld-linux.so уже не получится

Не у всех есть. Надо тестить дистрибутивы. У меня дыры никогда и не было.

есть более креативные решения.

Какие? Расскажи..

anonymous
()

пхп - одна сплошная дырка, особенно плагины для вротпресс так же могли выкачать бекапы, дампы, .env файлы, композы и тп. поэтому вот безопасников и называют бесполезниками и 30 мая 2025 года будет днем бесполезника, когда многие крупные сайты получать требования поделиться своими сверхприбылями с честными хацкерами… твой сервер скомпрментирован полностью. переставляй с нуля систему и всю вебню что на нем пофайлово сравнивай. рут для большинства целей не нужен

rtxtxtrx ★★★
()