NFS no_root_squash/no_all_squash misconfiguration PE
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Прочитайте файл _ /etc/exports _ , якщо ви знайдете деяку директорію, яка налаштована як no_root_squash, тоді ви можете доступитися до неї як клієнт і записувати всередині цієї директорії так, ніби ви були локальним root машини.
no_root_squash: Ця опція в основному надає повноваження користувачу root на клієнті доступатися до файлів на NFS сервері як root. І це може призвести до серйозних проблем з безпекою.
no_all_squash: Це схоже на опцію no_root_squash, але застосовується до не-root користувачів. Уявіть, що у вас є оболонка як користувач nobody; перевірте файл /etc/exports; опція no_all_squash присутня; перевірте файл /etc/passwd; емулюйте не-root користувача; створіть файл suid як цей користувач (монтуванням за допомогою nfs). Виконайте suid як користувач nobody і станьте іншим користувачем.
Якщо ви знайшли цю вразливість, ви можете її експлуатувати:
Монтування цієї директорії на клієнтській машині, і як root копіювання всередину змонтованої папки бінарного файлу /bin/bash і надання йому SUID прав, і виконання з жертви машини цього бінарного файлу bash.
Монтування цього каталогу на клієнтській машині, і як root копіювання всередину змонтованої папки нашого скомпільованого вантажу, який зловживає правами SUID, надання йому прав SUID, і виконання з жертви цієї двійкової програми (ви можете знайти тут деякі C SUID вантажі).
Зверніть увагу, що якщо ви можете створити тунель з вашого комп'ютера до комп'ютера жертви, ви все ще можете використовувати віддалену версію для експлуатації цього підвищення привілеїв, тунелюючи необхідні порти.
Наступний трюк стосується випадку, коли файл /etc/exports
вказує на IP. У цьому випадку ви не зможете використовувати в жодному випадку віддалену експлуатацію і вам потрібно буде зловживати цим трюком.
Ще однією необхідною умовою для роботи експлуатації є те, що експорт всередині /etc/export
повинен використовувати прапор insecure
.
--Я не впевнений, що якщо /etc/export
вказує на IP-адресу, цей трюк спрацює--
Сценарій передбачає експлуатацію змонтованого NFS-спільного ресурсу на локальному комп'ютері, використовуючи недолік у специфікації NFSv3, який дозволяє клієнту вказувати свій uid/gid, що потенційно може дозволити несанкціонований доступ. Експлуатація передбачає використання libnfs, бібліотеки, яка дозволяє підробляти виклики NFS RPC.
Кроки компіляції бібліотеки можуть вимагати коригувань залежно від версії ядра. У цьому конкретному випадку системні виклики fallocate були закоментовані. Процес компіляції включає наступні команди:
Експлуатація полягає у створенні простого C програми (pwn.c
), яка підвищує привілеї до root, а потім виконує оболонку. Програма компілюється, а отриманий бінарний файл (a.out
) розміщується на загальному ресурсі з suid root, використовуючи ld_nfs.so
для підробки uid у викликах RPC:
Скомпілюйте код експлуатації:
Розмістіть експлуатацію на загальному ресурсі та змініть її дозволи, підробляючи uid:
Виконайте експлуатацію для отримання привілеїв root:
Після отримання доступу root, для взаємодії з NFS загальним ресурсом без зміни власності (щоб уникнути залишення слідів), використовується Python скрипт (nfsh.py). Цей скрипт налаштовує uid, щоб відповідати uid файлу, до якого звертаються, що дозволяє взаємодіяти з файлами на загальному ресурсі без проблем з дозволами:
Запустіть як:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)