mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-24 03:53:29 +00:00
81 lines
9.8 KiB
Markdown
81 lines
9.8 KiB
Markdown
<details>
|
||
|
||
<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong> <a href="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
|
||
* **Participe do** 💬 [**grupo no Discord**](https://discord.gg/hRep4RUj7f) ou do [**grupo no 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.
|
||
|
||
</details>
|
||
|
||
|
||
PAM é uma coleção de módulos que essencialmente formam uma barreira entre um serviço no seu sistema e o usuário do serviço. Os módulos podem ter propósitos bastante variados, desde proibir o login de usuários de um determinado grupo UNIX \(ou netgroup, ou sub-rede...\), até implementar limites de recursos para que seu grupo de ‘pesquisa’ não monopolize os recursos do sistema.
|
||
|
||
# Arquivos de Configuração
|
||
|
||
Solaris e outros sistemas UNIX comerciais têm um modelo de configuração um pouco diferente, centrado em torno de um único arquivo, **`/etc/pam.conf`**. Na maioria dos sistemas Linux, esses arquivos de configuração estão localizados em **`/etc/pam.d`**, e são nomeados de acordo com o serviço – por exemplo, o arquivo de configuração de ‘login’ é chamado **`/etc/pam.d/login`**. Vamos dar uma rápida olhada em uma versão desse arquivo:
|
||
```text
|
||
auth required /lib/security/pam_securetty.so
|
||
auth required /lib/security/pam_nologin.so
|
||
auth sufficient /lib/security/pam_ldap.so
|
||
auth required /lib/security/pam_unix_auth.so try_first_pass
|
||
account sufficient /lib/security/pam_ldap.so
|
||
account required /lib/security/pam_unix_acct.so
|
||
password required /lib/security/pam_cracklib.so
|
||
password required /lib/security/pam_ldap.so
|
||
password required /lib/security/pam_pwdb.so use_first_pass
|
||
session required /lib/security/pam_unix_session.so
|
||
```
|
||
## **Domínios de Gerenciamento do PAM**
|
||
|
||
A coluna mais à esquerda pode conter quatro palavras únicas, que representam quatro domínios de gerenciamento do PAM: **auth**, **account**, **password** e **session**. Embora existam muitos módulos que suportam mais de um desses domínios \(de fato, pam\_unix suporta todos eles\), outros, como pam\_cracklib, por exemplo, são adequados apenas para um \(a funcionalidade ‘password’ no caso do pam\_cracklib\).
|
||
|
||
* **auth**: O domínio 'auth' \(eu o chamo de domínio – a documentação se refere a ele como 'grupo de gerenciamento' ou 'facilidade'\) é responsável por verificar se o usuário é quem diz ser. Os módulos que podem ser listados nesta área **geralmente** suportam **solicitação de senha**.
|
||
* **account**: Esta área é responsável por uma ampla gama de possíveis funcionalidades de **verificação de conta**. Existem muitos módulos disponíveis para esta facilidade. Restrições ao uso de um serviço baseadas na **verificação de pertencimento a grupos**, hora do dia, se uma conta de usuário é local ou remota, etc., são geralmente aplicadas por módulos que suportam esta facilidade.
|
||
* **password**: Os módulos nesta área são responsáveis por qualquer funcionalidade necessária no curso de **atualização de senhas** para um determinado serviço. Na maioria das vezes, esta seção é bastante simples, simplesmente chamando um módulo que **solicitará uma senha atual**, e, assumindo que isso seja bem-sucedido, solicitará uma nova. Outros módulos podem ser adicionados para realizar **complexidade de senha** ou verificação de dicionário também, como o realizado pelos módulos pam\_cracklib e pam\_pwcheck.
|
||
* **session**: Módulos nesta área realizam uma série de coisas que acontecem **durante a configuração ou limpeza de um serviço** para um determinado usuário. Isso pode incluir várias coisas; lançar um script de inicialização do sistema, realizar registros especiais, **montar o diretório home do usuário** ou definir limites de recursos.
|
||
|
||
## **Controles de Módulo do PAM**
|
||
|
||
A **coluna do meio** contém uma palavra-chave que determina essencialmente o que o PAM deve fazer se o módulo **tiver sucesso ou falhar**. Essas palavras-chave são chamadas de '**controles**' no jargão do PAM. Em 90% dos casos, você pode usar uma das palavras-chave comuns \(**requisite**, **required**, **sufficient** ou **optional**\). No entanto, isso é apenas a ponta do iceberg em termos de liberar a flexibilidade e o poder do PAM.
|
||
|
||
* **required**: Se um módulo 'required' retornar um status que **não seja 'sucesso'**, a **operação falhará SEMPRE**, mas somente após os **módulos abaixo dele serem invocados**. Isso pode parecer sem sentido à primeira vista, mas serve ao propósito de **agir sempre da mesma maneira do ponto de vista do usuário** que tenta utilizar o serviço. O efeito líquido é que se torna **impossível** para um possível cracker **determinar** **qual** **módulo** causou a **falha**.
|
||
* **requisite**: Se um módulo 'requisite' falhar, a **operação** não apenas **falha**, mas a operação é **imediatamente** **terminada** com uma falha sem invocar quaisquer outros módulos.
|
||
* **sufficient**: Se um módulo **sufficient** **tiver sucesso**, é o suficiente para satisfazer os requisitos dos módulos sufficient naquele domínio para o uso do serviço, e **módulos abaixo dele que também são listados como 'sufficient' não são invocados**. **Se falhar, a operação falha a menos que um módulo invocado após ele tenha sucesso**.
|
||
* **optional**: Um módulo 'optional', de acordo com a página de manual pam\(8\), **só causará falha na operação se for o único módulo na pilha para aquela facilidade**.
|
||
|
||
## Exemplo
|
||
|
||
Em nosso arquivo de exemplo, temos quatro módulos empilhados para o domínio auth:
|
||
```text
|
||
auth required /lib/security/pam_securetty.so
|
||
auth required /lib/security/pam_env.so
|
||
auth sufficient /lib/security/pam_ldap.so
|
||
auth required /lib/security/pam_unix.so try_first_pass
|
||
```
|
||
À medida que os módulos são invocados em ordem, eis o que acontecerá:
|
||
|
||
1. O módulo '**pam\_securetty**' verificará seu arquivo de configuração, **`/etc/securetty`**, e verá se o terminal usado para este login está listado no arquivo. Se **não estiver, logins como root não serão permitidos**. Se você tentar fazer login como root em um terminal 'ruim', este módulo falhará. Como é 'required', ainda invocará todos os módulos na pilha. No entanto, mesmo que todos eles tenham sucesso, o login falhará. É interessante notar que se o módulo fosse listado como 'requisite', a operação terminaria com uma falha imediatamente, sem invocar nenhum dos outros módulos, independentemente do status deles.
|
||
2. O módulo '**pam\_env**' **definirá variáveis de ambiente** com base no que o administrador configurou em /etc/security/pam\_env.conf. Em uma configuração padrão do Redhat 9, Fedora Core 1 e Mandrake 9.2, o arquivo de configuração para este módulo na verdade não define nenhuma variável. Um bom uso para isso pode ser definir automaticamente uma variável de ambiente DISPLAY para um usuário que faz login via SSH para que ele não precise defini-la se quiser enviar um 'xterm' de volta para sua área de trabalho remota (embora isso possa ser cuidado pelo OpenSSH automaticamente).
|
||
3. O módulo '**pam\_ldap**' **solicitará** ao usuário uma **senha** e, em seguida, verificará o diretório ldap indicado em **`/etc/ldap.conf`** para autenticar o usuário. Se isso falhar, a operação ainda pode ter sucesso se 'pam\_unix' tiver sucesso na autenticação do usuário. Se pam\_ldap tiver sucesso, 'pam\_unix' não será invocado.
|
||
4. O módulo '**pam\_unix**', neste caso, **não solicitará ao usuário uma senha**. O argumento 'try\_first\_pass' dirá ao módulo para **usar a senha fornecida pelo módulo anterior** (neste caso, pam\_ldap). Ele tentará autenticar o usuário usando as chamadas de sistema getpw\* padrão. Se pam\_unix falhar e pam\_ldap também tiver falhado, a operação falhará. Se pam\_ldap falhar, mas pam\_unix tiver sucesso, a operação terá sucesso (isso é extremamente útil em casos onde root não está no diretório ldap, mas ainda está no arquivo local /etc/passwd!).
|
||
|
||
|
||
|
||
<details>
|
||
|
||
<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong> <a href="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ê quiser 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>
|