ZeroDay | Кибербезопасность
PATH Hijacking, часть 2: как поймать подмену команды в Linux
👋 Приветствую в мире цифровой безопасности!
В прошлой части разобрали, как через $PATH можно заставить скрипт запустить чужой исполняемый файл. Но что делать, если подозрительный скрипт уже работает, а в вашей оболочке всё выглядит нормально?
⏺Сначала проверим окружение самого процесса. У systemd-сервиса или cron-задания $PATH может отличаться от того, что показывает терминал:
tr ‘\0’ ‘\n’ < /proc/PID/environ | grep ‘^PATH=‘
Так можно увидеть переменную окружения, переданную процессу при запуске. Но если скрипт изменил $PATH уже после старта, /proc этого не покажет.
⏺Проверим, что реально выполняется. Для воспроизведения подозрительного запуска подойдёт strace:
strace -f -e trace=execve,execveat \
-s 256 -o /tmp/exec.log ./backup.sh
В журнале будут видны попытки запуска исполняемых файлов, включая неудачные. Так можно заметить, что вместо ожидаемого /usr/bin/tar скрипт обращается к файлу из /opt/scripts или другого каталога.
⏺А если процесс уже работает? Можно проверить его текущий исполняемый файл:
readlink -f /proc/PID/exe
Но здесь есть нюанс: если скрипт запускает короткоживущие команды, поймать их через /proc сложно. Для постоянного наблюдения лучше использовать аудит execve через auditd или eBPF.
⏺Ищем причину, а не только следствие. Проверим права на подозрительный файл и каталоги по пути к нему:
namei -l /opt/scripts/tar
Команда покажет владельцев и права каждого компонента пути. Даже если сам tar защищён от записи, доступный посторонним родительский каталог может позволить заменить файл.
⏺И ещё момент: безопасный $PATH не спасёт, если злоумышленник может менять сам скрипт, его конфигурацию или каталог с исполняемыми файлами.
🤖Бесплатный ChatGPT Если у вас установлено приложение,
вы можете сразу перейти в канал