maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/linux-hardening/privilege-escalation/nfs-no_root_squash

Browse Source
This commit is contained in:
Translator 2025-02-05 09:39:17 +00:00
parent 3cfc132eac
commit eae85f7463
2 changed files with 24 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
View File

@ -2,18 +2,18 @@
# Informações Básicas sobre Squashing
O NFS geralmente (especialmente no linux) confia no `uid` e `gid` indicados pelo cliente que se conecta para acessar os arquivos (se o kerberos não for usado). No entanto, existem algumas configurações que podem ser definidas no servidor para **mudar esse comportamento**:
O NFS geralmente (especialmente no Linux) confia no `uid` e `gid` indicados pelo cliente que se conecta para acessar os arquivos (se o kerberos não for usado). No entanto, existem algumas configurações que podem ser definidas no servidor para **mudar esse comportamento**:
- **`all_squash`**: Ele reduz todos os acessos mapeando todos os usuários e grupos para **`nobody`** (65534 unsigned / -2 signed). Portanto, todos são `nobody` e nenhum usuário é utilizado.
- **`all_squash`**: Ele reduz todos os acessos mapeando todos os usuários e grupos para **`nobody`** (65534 sem sinal / -2 com sinal). Portanto, todos são `nobody` e nenhum usuário é utilizado.
- **`root_squash`/`no_all_squash`**: Este é o padrão no Linux e **apenas reduz o acesso com uid 0 (root)**. Portanto, qualquer `UID` e `GID` são confiáveis, mas `0` é reduzido para `nobody` (então nenhuma impersonação de root é possível).
- **`no_root_squash`**: Esta configuração, se habilitada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, você pode acessá-lo como root.
- **`no_root_squash`**: Esta configuração, se habilitada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, pode acessá-lo como root.
No arquivo **/etc/exports**, se você encontrar algum diretório que está configurado como **no_root_squash**, então você pode **acessar** a partir de **um cliente** e **escrever dentro** desse diretório **como** se você fosse o **root** local da máquina.
No arquivo **/etc/exports**, se você encontrar algum diretório que está configurado como **no_root_squash**, então você pode **acessar** esse diretório **como cliente** e **escrever dentro** desse diretório **como** se você fosse o **root** local da máquina.
Para mais informações sobre **NFS**, consulte:
{{#ref}}
/network-services-pentesting/nfs-service-pentesting.md
../../network-services-pentesting/nfs-service-pentesting.md
{{#endref}}
# Escalada de Privilégios
@ -23,7 +23,7 @@ Para mais informações sobre **NFS**, consulte:
Opção 1 usando bash:
- **Montando esse diretório** em uma máquina cliente e **como root copiando** dentro da pasta montada o binário **/bin/bash** e dando a ele direitos **SUID**, e **executando a partir da máquina vítima** esse binário bash.
- Observe que para ser root dentro do compartilhamento NFS, **`no_root_squash`** deve estar configurado no servidor.
- No entanto, se não estiver habilitado, você pode escalar para outro usuário copiando o binário para o compartilhamento NFS e dando a ele a permissão SUID como o usuário para o qual você deseja escalar.
- No entanto, se não estiver habilitado, você pode escalar para outro usuário copiando o binário para o compartilhamento NFS e dando a ele a permissão SUID como o usuário para o qual deseja escalar.
```bash
#Attacker, as root user
mkdir /tmp/pe
@ -37,7 +37,7 @@ cd <SHAREDD_FOLDER>
./bash -p #ROOT shell
```
Opção 2 usando código compilado em C:
- **Montando esse diretório** em uma máquina cliente, e **como root copiando** dentro da pasta montada nosso payload compilado que irá abusar da permissão SUID, dando a ele direitos de **SUID**, e **executando a partir da máquina da vítima** esse binário (você pode encontrar aqui alguns [C SUID payloads](payloads-to-execute.md#c)).
- **Montando esse diretório** em uma máquina cliente, e **como root copiando** dentro da pasta montada nosso payload compilado que irá abusar da permissão SUID, dando a ele direitos **SUID**, e **executando a partir da máquina da vítima** esse binário (você pode encontrar aqui alguns [C SUID payloads](payloads-to-execute.md#c)).
- Mesmas restrições que antes
```bash
#Attacker, as root user
@ -55,10 +55,10 @@ cd <SHAREDD_FOLDER>
## Exploit Local
> [!NOTE]
> Note que se você puder criar um **túnel da sua máquina para a máquina da vítima, ainda poderá usar a versão Remota para explorar essa escalada de privilégio, tunelando as portas necessárias**.\
> Note que se você puder criar um **túnel da sua máquina para a máquina da vítima, você ainda pode usar a versão Remota para explorar essa escalada de privilégio, tunelando as portas necessárias**.\
> O seguinte truque é caso o arquivo `/etc/exports` **indique um IP**. Nesse caso, você **não poderá usar** em nenhum caso o **exploit remoto** e precisará **abusar desse truque**.\
> Outro requisito necessário para que o exploit funcione é que **a exportação dentro de `/etc/export`** **deve estar usando a flag `insecure`**.\
> --_Não tenho certeza se, quando `/etc/export` indica um endereço IP, esse truque funcionará_--
> --_Não tenho certeza se, caso `/etc/export` indique um endereço IP, esse truque funcionará_--
## Informações Básicas
@ -66,7 +66,7 @@ O cenário envolve explorar um compartilhamento NFS montado em uma máquina loca
### Compilando a Biblioteca
Os passos de compilação da biblioteca podem exigir ajustes com base na versão do kernel. Neste caso específico, as chamadas de sistema fallocate foram comentadas. O processo de compilação envolve os seguintes comandos:
Os passos de compilação da biblioteca podem exigir ajustes com base na versão do kernel. Neste caso específico, as syscalls fallocate foram comentadas. O processo de compilação envolve os seguintes comandos:
```bash
./bootstrap
./configure

28
src/network-services-pentesting/nfs-service-pentesting.md
View File

@ -12,9 +12,9 @@
```
### Autenticação
Um aspecto notável deste protocolo é a sua habitual falta de **mecanismos de autenticação** ou **autorização** integrados. Em vez disso, a autorização depende das **informações do sistema de arquivos**, com o servidor encarregado de traduzir com precisão as **informações do usuário fornecidas pelo cliente** no formato de **autorização** exigido pelo sistema de arquivos, seguindo principalmente a **sintaxe UNIX**.
Um aspecto notável deste protocolo é sua habitual falta de **mecanismos de autenticação** ou **autorização** embutidos. Em vez disso, a autorização depende das **informações do sistema de arquivos**, com o servidor encarregado de traduzir com precisão as **informações do usuário fornecidas pelo cliente** no formato de **autorização** exigido pelo sistema de arquivos, seguindo principalmente a **sintaxe UNIX**.
A autenticação comumente depende de **identificadores `UID`/`GID` do UNIX e associações a grupos**. No entanto, um desafio surge devido ao potencial descompasso nas **mapeações `UID`/`GID`** entre clientes e servidores, não deixando espaço para verificação adicional pelo servidor. Além disso, esses detalhes são enviados pelo cliente e confiados pelo servidor, de modo que um cliente mal-intencionado poderia potencialmente **se passar por outro usuário enviando `uid` e `gid` mais privilegiados.**
A autenticação comumente depende de **identificadores `UID`/`GID` do UNIX e associações a grupos**. No entanto, um desafio surge devido ao potencial descompasso nas **mapeações `UID`/`GID`** entre clientes e servidores, não deixando espaço para verificação adicional pelo servidor. Além disso, esses detalhes são enviados pelo cliente e confiados pelo servidor, de modo que um cliente mal-intencionado poderia potencialmente **se passar por outro usuário enviando `uid` e `gid` mais privilegiados**.
**No entanto, observe que, por padrão, não é possível se passar pelo `UID` 0 (root) usando NFS. Mais sobre isso na seção de squashing.**
@ -34,21 +34,21 @@ Como você pode ver, ele permite configurar um **IP** ou **hostname** específic
- **NFSv3**: Introduzido com uma série de melhorias, o NFSv3 expandiu seu predecessor ao suportar tamanhos de arquivo variáveis e oferecer mecanismos de relatórios de erro aprimorados. Apesar de seus avanços, enfrentou limitações na compatibilidade total com clientes NFSv2.
- **NFSv4**: Uma versão marcante na série NFS, o NFSv4 trouxe um conjunto de recursos projetados para modernizar o compartilhamento de arquivos em redes. Melhorias notáveis incluem a integração do Kerberos para **alta segurança**, a capacidade de atravessar firewalls e operar pela Internet sem a necessidade de portmappers, suporte para Listas de Controle de Acesso (ACLs) e a introdução de operações baseadas em estado. Suas melhorias de desempenho e a adoção de um protocolo com estado distinguem o NFSv4 como um avanço crucial nas tecnologias de compartilhamento de arquivos em rede.
- Observe que é muito estranho encontrar um host Linux NFS suportando autenticação kerberos.
- Note que é muito estranho encontrar um host Linux NFS suportando autenticação kerberos.
Cada versão do NFS foi desenvolvida com a intenção de atender às necessidades em evolução dos ambientes de rede, aprimorando progressivamente a segurança, compatibilidade e desempenho.
### Squashing
Como mencionado anteriormente, o NFS geralmente confia no `uid` e `gid` do cliente para acessar os arquivos (se o kerberos não for usado). No entanto, existem algumas configurações que podem ser definidas no servidor para **mudar esse comportamento**:
Como mencionado anteriormente, o NFS geralmente confiará no `uid` e `gid` do cliente para acessar os arquivos (se o kerberos não for usado). No entanto, existem algumas configurações que podem ser definidas no servidor para **mudar esse comportamento**:
- **all_squash**: Ele reduz todos os acessos mapeando cada usuário e grupo para **`nobody`** (65534 unsigned / -2 signed). Portanto, todos são `nobody` e nenhum usuário é utilizado.
- **root_squash/no_all_squash**: Este é o padrão no Linux e **apenas reduz o acesso com uid 0 (root)**. Portanto, qualquer `UID` e `GID` são confiáveis, mas `0` é reduzido a `nobody` (então nenhuma impersonação de root é possível).
- **no_root_squash**: Esta configuração, se ativada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, poderá acessá-lo como root.
- **no_root_squash**: Esta configuração, se habilitada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, poderá acessá-lo como root.
### Subtree check
Disponível apenas no Linux. man(5) exports diz: "Se um subdiretório de um sistema de arquivos for exportado, mas o sistema de arquivos inteiro não, então sempre que um pedido NFS chegar, o servidor deve verificar não apenas se o arquivo acessado está no sistema de arquivos apropriado (o que é fácil), mas também se está na árvore exportada (o que é mais difícil). Essa verificação é chamada de verificação de subárvore."
Disponível apenas no Linux. man(5) exports diz: "Se um subdiretório de um sistema de arquivos for exportado, mas o sistema de arquivos inteiro não, então sempre que um pedido NFS chegar, o servidor deve verificar não apenas se o arquivo acessado está no sistema de arquivos apropriado (o que é fácil), mas também se está na árvore exportada (o que é mais difícil). Esta verificação é chamada de verificação de subárvore."
No Linux, o **recurso `subtree_check` está desativado** por padrão.
@ -56,8 +56,8 @@ No Linux, o **recurso `subtree_check` está desativado** por padrão.
### Showmount
Isso pode ser usado para **obter informações de um servidor NFSv3**, como a lista de **exports**, quem está **autorizado a acessar** esses exports e quais clientes estão conectados (o que pode ser impreciso se um cliente se desconectar sem avisar o servidor).
Nos **clientes NFSv4, eles acessam diretamente o / export** e tentam acessar os exports a partir daí, falhando se for inválido ou não autorizado por qualquer motivo.
Isso pode ser usado para **obter informações de um servidor NFSv3**, como a lista de **exports**, quem está **autorizado a acessar** esses exports e quais clientes estão conectados (o que pode ser impreciso se um cliente desconectar sem avisar o servidor).
Nos **clientes NFSv4, eles acessam diretamente o / export** e tentam acessar exports a partir daí, falhando se for inválido ou não autorizado por qualquer motivo.
Se ferramentas como `showmount` ou módulos do Metasploit não mostrarem informações de uma porta NFS, é potencialmente um servidor NFSv4 que não suporta a versão 3.
```bash
@ -77,7 +77,7 @@ scanner/nfs/nfsmount #Scan NFS mounts and list permissions
Esta ferramenta de [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) pode ser usada para obter muitos dados de um servidor NFS, como **montagens**, versões NFS suportadas, IPs conectados e até mesmo se é possível **escapar das exportações** para outras pastas no FS ou **se `no_root_squash` está habilitado**.
## Montagem
## Mounting
Para saber **qual pasta** o servidor tem **disponível** para montar, você pode perguntar usando:
```bash
@ -96,7 +96,7 @@ mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
```
## Ataques
### Confiando em UID e GID
### Confiando no UID e GID
Claro, o único problema aqui é que, por padrão, não é possível se passar por root (`UID` 0). No entanto, é possível se passar por qualquer outro usuário ou, se `no_root_squash` estiver habilitado, você também pode se passar por root.
@ -108,14 +108,14 @@ Claro, o único problema aqui é que, por padrão, não é possível se passar p
Verifique a página:
{{#ref}}
/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
{{#endref}}
### Escapando das exportações
Neste [ótimo artigo](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/) é possível ver que é possível **escapar das exportações para acessar outras pastas no FS**.
Portanto, se uma exportação estiver exportando uma pasta que é uma **subpasta** do **sistema de arquivos inteiro**, é possível acessar arquivos fora da exportação se **`subtree_check`** estiver desabilitado. E está **desabilitado por padrão no Linux**.
Portanto, se uma exportação estiver exportando uma pasta que é uma **subpasta** do **sistema de arquivos inteiro**, é possível acessar arquivos fora da exportação se **`subtree_check`** estiver desativado. E está **desativado por padrão no Linux**.
Por exemplo, se um servidor NFS estiver exportando `/srv/` e `/var/` estiver no mesmo sistema de arquivos, é possível ler logs de `/var/log/` ou armazenar um webshell em `/var/www/`.
@ -125,9 +125,9 @@ A ferramenta **`nfs_analyze`** de [https://github.com/hvs-consulting/nfs-securit
### NSFShell
Para listar, montar e mudar UID e GID facilmente para ter acesso a arquivos, você pode usar [nfsshell](https://github.com/NetDirect/nfsshell).
Para listar, montar e mudar facilmente o UID e GID para ter acesso a arquivos, você pode usar [nfsshell](https://github.com/NetDirect/nfsshell).
[Ótimo tutorial do NFSShell.](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/)
[Ótimo tutorial sobre NFSShell.](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/)
## Arquivos de configuração
```