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)
Lees die _ /etc/exports _ lêer, as jy 'n gids vind wat geconfigureer is as no_root_squash, dan kan jy dit toegang vanaf as 'n kliënt en binne daardie gids skryf asof jy die plaaslike root van die masjien was.
no_root_squash: Hierdie opsie gee basies gesag aan die root-gebruiker op die kliënt om lêers op die NFS-bediener as root te benader. En dit kan lei tot ernstige sekuriteitsimplikasies.
no_all_squash: Dit is soortgelyk aan die no_root_squash opsie, maar dit geld vir nie-root gebruikers. Stel jou voor, jy het 'n shell as nobody gebruiker; het die /etc/exports lêer nagegaan; no_all_squash opsie is teenwoordig; kyk na die /etc/passwd lêer; emuleer 'n nie-root gebruiker; skep 'n suid lêer as daardie gebruiker (deur te monteer met nfs). Voer die suid uit as nobody gebruiker en word 'n ander gebruiker.
As jy hierdie kwesbaarheid gevind het, kan jy dit benut:
Monteer daardie gids in 'n kliëntmasjien, en as root kopieer binne die gemonteerde gids die /bin/bash binêre en gee dit SUID regte, en voerde van die slagoffer masjien daardie bash binêre uit.
Monteer daardie gids op 'n kliëntmasjien, en as root kopieer binne die gemonteerde vouer ons saamgecompileerde payload wat die SUID-toestemming sal misbruik, gee vir dit SUID regte, en voer vanaf die slagoffer masjien daardie binêre uit (jy kan hier 'n paar C SUID payloads vind).
Let daarop dat as jy 'n tunnel van jou masjien na die slagoffer masjien kan skep, jy steeds die Remote weergawe kan gebruik om hierdie privaatheidsverhoging te exploiteer deur die vereiste poorte te tunnelle.
Die volgende truuk is in die geval waar die lêer /etc/exports
'n IP aandui. In hierdie geval **sal jy in elk geval nie die remote exploit kan gebruik nie en jy sal hierdie truuk moet misbruik.
Nog 'n vereiste vir die exploit om te werk is dat die eksport binne /etc/export
die insecure
vlag moet gebruik.
--Ek is nie seker of hierdie truuk sal werk as /etc/export
'n IP adres aandui nie--
Die scenario behels die eksploitering van 'n gemonteerde NFS deel op 'n plaaslike masjien, wat 'n fout in die NFSv3 spesifikasie benut wat die kliënt toelaat om sy uid/gid te spesifiseer, wat moontlik ongeoorloofde toegang moontlik maak. Die eksploitering behels die gebruik van libnfs, 'n biblioteek wat die vervalsing van NFS RPC oproepe toelaat.
Die biblioteek samevoegingsstappe mag aanpassings vereis gebaseer op die kern weergawe. In hierdie spesifieke geval was die fallocate syscalls uitgekommenteer. Die samevoegingsproses behels die volgende opdragte:
Die exploit behels die skep van 'n eenvoudige C-programma (pwn.c
) wat voorregte na root verhoog en dan 'n shell uitvoer. Die program word gecompileer, en die resulterende binêre (a.out
) word op die deel geplaas met suid root, met behulp van ld_nfs.so
om die uid in die RPC-oproepe te vervals:
Compileer die exploit kode:
Plaas die exploit op die deel en verander sy toestemmings deur die uid te vervals:
Voer die exploit uit om root voorregte te verkry:
Sodra root-toegang verkry is, om met die NFS-deel te kommunikeer sonder om eienaarskap te verander (om spore te vermy), word 'n Python-skrip (nfsh.py) gebruik. Hierdie skrip pas die uid aan om ooreen te stem met dié van die lêer wat toeganklik is, wat interaksie met lêers op die deel moontlik maak sonder toestemmingprobleme:
Hardloop soos:
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)