<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras formas de apoiar o HackTricks:
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
Leia o arquivo _ **/etc/exports** _, se você encontrar algum diretório configurado como **no\_root\_squash**, então você pode **acessá-lo****como um cliente** e **escrever dentro** desse diretório **como** se fosse o **root** local da máquina.
**no\_root\_squash**: Essa opção basicamente dá autoridade ao usuário root no cliente para acessar arquivos no servidor NFS como root. E isso pode levar a sérias implicações de segurança.
**no\_all\_squash:** Essa opção é semelhante à **no\_root\_squash**, mas se aplica a **usuários não-root**. Imagine que você tenha um shell como usuário nobody; verificou o arquivo /etc/exports; a opção no\_all\_squash está presente; verifique o arquivo /etc/passwd; emule um usuário não-root; crie um arquivo suid como esse usuário (montando usando nfs). Execute o suid como usuário nobody e torne-se um usuário diferente.
* **Montando esse diretório** em uma máquina cliente e, **como root, copiando** para dentro da pasta montada o binário **/bin/bash** e concedendo a ele direitos **SUID**, e **executando a partir da máquina vítima** esse binário bash.
* **Montando esse diretório** em uma máquina cliente e, **como root, copiando** dentro da pasta montada nosso payload compilado que abusará da permissão SUID, dar a ele direitos **SUID** e **executar a partir da máquina vítima** esse binário (você pode encontrar aqui alguns [payloads C SUID](payloads-to-execute.md#c)).
Note que se você puder criar um **túnel da sua máquina para a máquina vítima, você ainda pode usar a versão Remota para explorar essa escalada de privilégios tunelando as portas necessárias**.\
A dica a seguir é para o caso do arquivo `/etc/exports`**indicar um endereço IP**. Neste caso, você **não poderá usar** de forma alguma o **exploit remoto** e precisará **abusar desta dica**.\
Outro requisito necessário para o funcionamento do exploit é que **a exportação dentro de `/etc/export`****deve estar usando a flag `insecure`**.\
\--_Não tenho certeza de que se `/etc/export` estiver indicando um endereço IP, esta dica funcionará_--
Agora, vamos supor que o servidor de compartilhamento ainda execute `no_root_squash`, mas há algo que nos impede de montar o compartilhamento em nossa máquina de pentesting. Isso aconteceria se o `/etc/exports` tivesse uma lista explícita de endereços IP permitidos para montar o compartilhamento.
Isso significa que estamos presos explorando o compartilhamento montado na máquina localmente a partir de um usuário não privilegiado. Mas acontece que existe outro exploit local menos conhecido.
Esse exploit depende de um problema na especificação do NFSv3 que determina que é responsabilidade do cliente anunciar seu uid/gid ao acessar o compartilhamento. Assim, é possível falsificar o uid/gid forjando as chamadas RPC do NFS se o compartilhamento já estiver montado!
Uma vez com privilégios de root local na máquina, eu queria vasculhar o compartilhamento NFS em busca de possíveis segredos que me permitissem pivotar. Mas havia muitos usuários do compartilhamento, todos com seus próprios uids, que eu não conseguia ler apesar de ser root, devido à incompatibilidade de uids. Eu não queria deixar rastros óbvios como um chown -R, então criei um pequeno trecho de código para definir meu uid antes de executar o comando de shell desejado:
<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) no github.