Как стать автором
Обновить

Комментарии 30

Но я так и не нашла, куда мне надо прописать этот trap, чтобы при нажатии на ctrl + C, например, из ping у меня открылся reverse-shell. А создавать свой скрипт, с которым это работает - очень такое себе.

Ну почему же? Вполне себе метод - пишем враппер с вызовом бинаря, которым заменяем оригинальный бинарь или подкладываем в $PATH руту путь к врапперу. Внутри враппера вызов целевого бинаря обмазываем по своему вкусу.

Ну если только так)

Но с другой стороны во wrapper можно сразу положить полезную нагрузку, без лишнего шага в виде trap :)

Ведь тогда какого-то пользователя системы надо заставить периодически запускать мой скрипт да еще и нажимать ctrl + C.

можно использовать kill

Другой способ не потерять доступ при смене пароля, это прописать свой открытый ключ в ~/.ssh/authorized_keys. Тогда вообще никакой пароль больше не будет нужен.

Тогда придётся править ещё sudoers

It depends

Если у нас уже root, и мы добавляем ключ в его домашнюю директорию, то тут больше вопрос, можно ли руту подключаться по SSH. И тогда скорее надо править конфиг ssh.

Если это обычный пользователь, то мы вряд ли сможем отредактировать sudoers

Есть третий вариант, когда пользователь не root, но имеет его привилегии (может делать sudo su). Но тогда нам в любом случае надо знать пароль. Или через sudoers можно сделать так, чтобы пароль не запрашивался?

Можешь подробнее объяснить, что ты имеешь в виду?

Или через sudoers можно сделать так, чтобы пароль не запрашивался?

%somegroup ALL=NOPASSWD: ALL

Не существует ли какого-нибудь пакета, который будет при запуске анализировать все эти места?

Это не имеет смысла. Настоящий хакер установит руткит, который невозможно будет определить изнутри системы.


Если имеются подозрения о взломе, то единственное решение — установить систему с нуля.

Есть детекторы руткитов же. Вряд ли крутые приватные штуки сильно распространены, это невыгодно.

А иначе, если рассуждать на том же уровне паранойи - если имеются подозрения о взломе надо выкидывать сервак, т.к. настоящий хакер пропатчит BIOS и добавит efi-модуль, который после переустановки системы будет заново устанавливать руткит.

Или вот гипервизор как efi-модуль поставит например. И все ОС которые будут ставиться в будущем будут под гипервизором сидеть.

tripwire

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

И ни слова про пам, хотя, казалось бы, какие такие пароли? Одна строчка в паме, и вы можете себе позволить всё. Хоть рутом, хоть собачьим логином.

PAM
Pluggable Authentication Modules — модули для аутентификации, как несложно догадаться по переводу. До появления PAM администратору приходилось пройти все 12 кругов ада, чтобы настроить какую-то внешнюю систему аутентификации. Сейчас надо изменить пару строчек в паре конфигурационных файлов. Если в файле /etc/pam.d для всех определенных модулей выставить control_flag в значение optional, то мы сможет входить в систему вообще без пароля. Как и администраторы. Поэтому наш бекдорчик быстро найдут и закроют точку входа.


Вы имеете в виду этот пам?

Именно его. Самые dreaded конфиги в системе. Одна опечатка - и либо в систему не зайти, либо в систему зайти без пароля. У меня на домашней машине он используется для расшифровки домашнего каталога через pam_exec, но злоумышленнику никто не мешает встроить свой код именно в pam_exec, и фиг его вы разберёте вот в таком:

auth		sufficient	pam_rootok.so
session	[default=1]			pam_permit.so
session	requisite			pam_deny.so
session	required			pam_permit.so
session	required	pam_unix.so 
session	optional	pam_systemd.so 
account	requisite			pam_deny.so
account	required			pam_permit.so
auth optional pam_gnome_keyring.so
session  required        pam_limits.so
session  required        pam_loginuid.so
session      required pam_env.so readenv=1
session      required pam_env.so readenv=1 envfile=/etc/default/locale

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

Вдобавок, я не первый раз вижу организации, в которых конфиги pam.d не вносят в файловый аудит вообще.

Уровень 1: useradd -s /bin/bash hacker - команда более низкого уровня, она позволяет задавать разные параметры

Особые извращенцы могут вручную отредактировать файлы /etc/passwd, /etc/shadow и /etc/group

Как аналитик SOC могу вам сказать точно, мы очень внимательно мониторим изменения во всех /etc/passwd и /etc/shadow

Так собственно все эти useradd, adduser меняют /etc/passwd, /etc/shadow, /etc/group

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

Например банально - вместо того, чтобы создавать целый свой демон и добавлять новый юнит, в чем проблема посмотреть уже существующие демоны, найти те, которые запускаются не бинарником, а шелл скриптом, и добавить в существующий шелл скрипт немного своих команд? Мониторинг всей файловой системы - уже не то, что делают повсеместно, в отличие от мониторинга /etc/passwd, /etc/shadow, /etc/sudoers.

Называть ручное редактирование системных файлов извращением - бред. То есть сперва вы говорите, что лучше adduser, чем отредактировать файл напрямую, а парой абзацев позже "Затем мы создаем свою библиотеку с таким же именем и определяем в ней такую же функцию". Можете уточнить, сколько раз вы создавали свои библиотеки с такими же именами и пользовались таким способом?

Привет!

Так собственно все эти useradd, adduser меняют /etc/passwd, /etc/shadow, /etc/group

Когда я писала про мониторинг файлов /etc/passwd, /etc/shadow и /etc/group — это был как вывод ко всему разделу, что создавать пользователя — так себе идея для скрытого закрепления (какой бы техникой вы не пользовались). Возможно из-за прямого упоминания файлов, непонятно, что фраза относится к любому из перечисленных способов. Я подумаю, как перестроить абзац, чтобы подобных казусов не возникало.

Насчет демона — спасибо, я просто совсем об этом не подумала. Это действительно проще и тоньше.

Можете уточнить, сколько раз вы создавали свои библиотеки с такими же именами и пользовались таким способом?

Если честно, то один раз на CTF. Так как я пыталась сделать просто обзор, то включила эту технику. Сложная техника — это тоже техника. И она имеет право на жизнь.

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

Отличная статья. Спасибо. Даже без относительно закрепления в системе, для себ узнал несколько особенностей, которые раньше не знал.

Не узнал ничего нового, зато вспомнил забытое. Спасибо было интересно.

Хотел высказать пару "фи", но выше уже всё сказали.

даже в putty есть штатный функционал для port knocking

наверное в какой-то спецсборке. В версии 0.76 win64 не нашел

я так и предположил изначально, что это специальная сборка, а не оригинальная. А потом привел ответ разработчиков, почему они не намерены добавлять эту функцию в оригинальную сборку

Учитывая что статья в целом "entry level", внесу свои 5 копеек. Во избежание закрепления у читателя "магического сознания".


  • "rc.local": исполняется как юнит systemd (или upstart, или init — не важно). Встречается в RH и deb-based. Чтобы включить, в RH например нужно сходить по символической ссылке и сделать "chmod +x".
  • "Что интересно, при старте системы, скрипты выполняются с правами root."
    Что ещё интереснее, без зачистки окружения. Что например позволяет кинуть сюрприз прямо в "/usr/local/sbin/".
  • В разделе про "Окружения рабочего стола", можно напомнить про полезность suid-бита. И про всякие attr'ы интересные — тоже.
  • "nc -lvp 1234" — "-v"-то зачем? И вообще, "-Z" рулит! Раз уж учимся собирать "на коленке".
  • "Скорее всего такой бекдор проживет ровно до момента"… когда горе-администратор повторно запустит что-то из-под sudo. Я бы таки удивился, увидев ругань от netcat в stderr. В примерах ниже таки появляется перенаправление "2>куда_то", а в начале — нет.
  • "нет ни малейшего намека на то, в результате чего произошло выполнение команды" — Серьёзно? Аудит ppid не пишет?

И да, если уж речь идёт о вкручивании качественного бэкдора, нужно хотя бы упомянуть про сборку initrd ("initial RAM disk" aka "initramfs"). По моему опыту, 99/100 админов вообще не осознают как оно работает.


P.S. Отдельное спасибо за упоминание таймеров. Они несут в жизнь разнообразие (или, на латинский манер, диверсию), которого так не хватает. На моих локалхостах оно правда выглядит так:


### systemctl cat logrotate.timer
# /usr/lib/systemd/system/logrotate.timer
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

"Угадайте, что/когда я запущу" <здесь должна быть картинка с косоглазым волком>


P.P.S. В конце статьи сто́ит добавить disclaimer про то что все описанные способы в основном подходят для углублённого изучения структуры ОС. И ни в коем разе не рекомендуются для практического рутования/обэкдоривания чего-либо отличного от собственного локалхоста.

Есть в теории еще один путь, но это действительно изврат.

Apt перед тем, как установить приложение выполняет 2 действия - проверяет кеш и, при необходимости, скачивает пакет.

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

Из минусов - если админ не рукожоп хотя бы 50 лвла то он очистит кеш перед обновлением. Плюс не будет совпадать md5, что так же при желании проверяется.

Я буду очень удивлен, если apt не проверяет подпись пакета перед установкой. pacman проверяет, например.

НЛО прилетело и опубликовало эту надпись здесь
> APT::Update::Pre-Invoke {«CMD»};
Моё почтение)

Ну и ещё модуль ядра, который sh-ник при старте выполняет (там 20 строчек из гугла скопировать), можно собрать и добавить в modprobe.

>Так как переменная PATH анализируется с конца, будет исполняться наш вредоносный ls, а не хороший системный.

Я аж чаем подавился. С каких это пор PATH с конца то?
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found.

Или это как всегда - на паблик выкладывают идею, но в реализации маленькая ошибка, что бы script kiddies "без должного понимания функций копируемых фрагментов" зафэйлились?

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

Текст несколько тяжеловат, но стиль неплох, может и не стоит разбавлять "водой".

Тут вообще большая часть "взлома" и вредоносности заключается в том, что некто узнал что систему можно КОНФИГУРИРОВАТЬ и думает что это и есть взлом.

Если человек получил доступ к пользовательскому профайлу на запись или вообще смог зайти на чужой сервер, то наделать делов можно и в линукс и в виндовс, и даже сложно сказать где можно найти больше скрытых мест.

Поэтому подобные вещи как "вредоносный ls" напоминают мне детские забавы, когда во времена доса в бат файлы писали "вредные команды" типа "echo вася дурак", предваряя их сотней пробелов, чтобы в большинстве текстовых редакторов их не было видно (тогда не каждый текстовый редактор показывал что строка не влазит в экран).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации