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 не спасёт, если злоумышленник может менять сам скрипт, его конфигурацию или каталог с исполняемыми файлами.