hacktricks/linux-hardening/linux-post-exploitation/pam-pluggable-authentication-modules.md

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

• Se você quiser ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Verifique os PLANOS DE ASSINATURA!
• Adquira o swag oficial PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção exclusiva de NFTs
• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe seus truques de hacking enviando PRs para os HackTricks e HackTricks Cloud repositórios do github.

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 torno de 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 de 'login' é chamado /etc/pam.d/login. Vamos dar uma olhada rápida em uma versão desse arquivo:

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

Reinos de Gerenciamento do PAM

A coluna mais à esquerda pode conter quatro palavras únicas, que representam quatro reinos de gerenciamento do PAM: auth, account, password e session. Embora existam muitos módulos que suportam mais de um desses reinos de fato, o pam\_unix suporta todos eles, outros, como o pam_cracklib, por exemplo, são adequados apenas para um no caso do pam\_cracklib, a funcionalidade de ‘password’.

• auth: O reino ‘auth’ eu o chamo de reino - a documentação se refere a ele como um ‘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 com base na verificação de pertencimento a um grupo, horário 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 processo 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 seja bem-sucedido, solicitará uma nova. Outros módulos podem ser adicionados para realizar verificação de complexidade de senha ou de dicionário, como a realizada pelos módulos pam_cracklib e pam_pwcheck.
• session: Os 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; iniciar um script de inicialização em todo o sistema, realizar log especial, 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 basicamente determina 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 é ‘sucesso’, a operação sempre falhará, mas somente após os módulos abaixo dele serem 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 outros módulos.
• sufficient: Se um módulo sufficient tiver sucesso, é suficiente para satisfazer os requisitos de módulos suficientes nesse reino para o 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 ‘optional’, de acordo com a página do manual pam(8), só fará 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 reino auth:

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

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, os logins de 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, não importando qual seja 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 se quiserem enviar um 'xterm' de volta para sua área de trabalho remota embora isso possa ser feito automaticamente pelo OpenSSH.
3. O módulo 'pam_ldap' irá solicitar a senha do usuário e então 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 de sistema padrão getpw*. Se pam_unix falhar e pam_ldap também 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!.