☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! - Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) - Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com) - **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.** - **Compartilhe suas técnicas de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.

PAM é uma coleção de módulos que essencialmente formam uma barreira entre um serviço em seu sistema e o usuário do serviço. Os módulos podem ter propósitos amplamente variados, desde impedir o login de usuários de um determinado grupo UNIX \(ou netgroup, ou subnet…\), até implementar limites de recursos para que seu grupo de "pesquisa" não possa monopolizar os recursos do sistema. # Arquivos de Configuração Solaris e outros sistemas UNIX comerciais têm um modelo de configuração ligeiramente diferente, centrado em um único arquivo, **`/etc/pam.conf`**. Na maioria dos sistemas Linux, esses arquivos de configuração ficam em **`/etc/pam.d`**, e são nomeados de acordo com o serviço - por exemplo, o arquivo de configuração "login" é chamado **`/etc/pam.d/login`**. Vamos dar uma olhada rápida 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 ``` ## **Realms de Gerenciamento PAM** A coluna mais à esquerda contém quatro palavras únicas, que representam quatro realms de gerenciamento PAM: **auth**, **account**, **password** e **session**. Embora muitos módulos suportem mais de um desses realms \(de fato, pam\_unix suporta todos eles\), outros, como pam\_cracklib, por exemplo, são adequados apenas para um \(no caso do pam\_cracklib, a facilidade 'password'\). * **auth**: O realm 'auth' \(eu o chamo de realm - a documentação se refere a ele como um 'grupo de gerenciamento' ou 'facilidade'\) é responsável por verificar se o usuário é quem ele 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 variedade 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 com base em **verificação de associação de grupo**, hora do dia, se uma conta de usuário é local ou remota, etc., geralmente são 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 'comum', 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 qualquer número de coisas que acontecem durante a **configuração ou limpeza de um serviço** para um determinado usuário. Isso pode incluir qualquer número de coisas; lançando um script de inicialização em todo o sistema, realizando log especial, **montando o diretório home do usuário**, ou definindo limites de recursos. ## **Controles de Módulo PAM** A **coluna do meio** contém uma palavra-chave que essencialmente determina **o que o PAM deve fazer se o módulo tiver sucesso ou falhar**. Essas palavras-chave são chamadas de '**controles**' no PAM-speak. 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' retorna um status que **não é 'success'**, a **operação sempre falhará**, mas somente depois que os **módulos abaixo dele forem invocados**. Isso parece sem sentido à primeira vista, suponho, mas serve ao propósito de **sempre agir 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 invasor **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 encerrada** com uma falha sem invocar nenhum outro módulo. * **sufficient**: Se um módulo **sufficient** **tiver sucesso**, é suficiente para satisfazer os requisitos de módulos suficientes nesse realm para uso do serviço, e **os 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 'opcional', de acordo com a página do manual pam\(8\), **só causará uma operação falhar se for o único módulo na pilha para essa facilidade**. ## Exemplo Em nosso arquivo de exemplo, temos quatro módulos empilhados para o realm 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 ``` Como os módulos são invocados em ordem, aqui está 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 de root não serão permitidos**. Se você tentar fazer login como root em um terminal 'ruim', este módulo falhará. Como é 'obrigatório', 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 'requisito', a operação terminaria com uma falha imediatamente, sem invocar nenhum dos outros módulos, não importando o status deles. 2. O módulo '**pam_env**' irá **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 eles não precisem definir isso manualmente se quiserem enviar um 'xterm' de volta para sua área de trabalho remota (embora isso possa ser resolvido automaticamente pelo OpenSSH). 3. O módulo '**pam_ldap**' irá **solicitar** a senha do usuário 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' conseguir autenticar o usuário. Se pam_ldap tiver sucesso, 'pam_unix' não será invocado. 4. O módulo '**pam_unix**', neste caso, **não solicitará a senha do usuário**. 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 do sistema padrão getpw\*. Se pam_unix falhar e pam_ldap falhar, a operação falhará. Se pam_ldap falhar, mas pam_unix tiver sucesso, a operação terá sucesso (isso é extremamente útil em casos em que root não está no diretório ldap, mas ainda está no arquivo local /etc/passwd!).