From eae85f746327aca52c5994039ea029ea081b0381 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 5 Feb 2025 09:39:17 +0000 Subject: [PATCH] Translated ['src/linux-hardening/privilege-escalation/nfs-no_root_squash --- .../nfs-no_root_squash-misconfiguration-pe.md | 20 ++++++------- .../nfs-service-pentesting.md | 28 +++++++++---------- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md b/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md index 68a6fda98..885be14e3 100644 --- a/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md +++ b/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md @@ -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 ./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 ## 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 diff --git a/src/network-services-pentesting/nfs-service-pentesting.md b/src/network-services-pentesting/nfs-service-pentesting.md index eae0b9abd..d7e64f247 100644 --- a/src/network-services-pentesting/nfs-service-pentesting.md +++ b/src/network-services-pentesting/nfs-service-pentesting.md @@ -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 ```