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)