PATH Hijacking: когда Linux запускает не ту команду

👋 Приветствую в мире цифровой безопасности!

Сегодня разберём атаку PATH Hijacking. Она интересна тем, что хакеру по факту даже не нужно менять сам скрипт. Достаточно повлиять на то, какую команду он запустит.

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

tar -czf /backup/site.tar.gz /var/www

Но путь к tar не указан. Поэтому оболочка ищет исполняемый файл в каталогах из переменной $PATH, причём строго по порядку.

⏺Если первым в списке окажется каталог, куда атакующий может записывать файлы, он сможет разместить там свою программу с именем tar. При следующем запуске скрипта система может выполнить её вместо /usr/bin/tar. Особенно неприятно, если скрипт запускается через cron или от имени root. Тогда подменённая команда получит права этого процесса.

⏺Проверить порядок поиска можно буквально двумя командами:

echo “$PATH”
type -a tar

Первая покажет список каталогов, а вторая - все найденные варианты команды. Если раньше /usr/bin стоит подозрительный пользовательский каталог, это повод разобраться.

⏺Для защиты в критичных скриптах лучше указывать полный путь к исполняемым файлам:

/usr/bin/tar -czf /backup/site.tar.gz /var/www

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

PATH=/usr/sbin:/usr/bin:/sbin:/bin
export PATH

⏺Отдельно стоит проверять задания cron, systemd-сервисы и скрипты, которые запускаются с повышенными правами. Даже безобидный вызов cp, tar или curl может стать проблемой, если команда ищется в каталоге, доступном для записи посторонним.

⏺И важный нюанс: сама по себе переменная PATH не даёт повышения привилегий. Для атаки нужно, чтобы привилегированный процесс действительно использовал небезопасный путь поиска.

Если нужна вторая часть с практическим разбором обнаружения PATH Hijacking, ставьте ``🔥

🤖Бесплатный ChatGPT