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 запустить свой процесс?

Спасибо.


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

Разница огромна. В одном дистре каждый Васян любые бинари с /home /tmp /var … запускает, а в другом ни бинаря левого запустить, ни интерпретатора никакого…

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

https://github.com/hackerschoice/memexec

Не должно

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

надо тестовую машину собрать и пробовать.

Если что можно ещё Integrity прикрыться:

echo 'appraise func=MMAP_CHECK mask=MAY_EXEC' > /sys/kernel/security/ima/policy

Тогда все что не подписано в память для исполнения не мапитса. Фичи лет 15, а в каком дистре из коробки используется?

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

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

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

Пользователи имеют право скачивать из интернета программы и запускать, это штатная функция машины, её запрет обессмыслит всё предприятие. Да, можно запретить запуск из /tmp, но хакеры с тем же успехом будут запускать свои программы из домашних директорий пользователей.

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

Пользователи имеют право скачивать из интернета программы и запускать, это штатная функция машины

Выгнать из секурити в толксы.

anonymous
()