Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-19 09:34:03 +00:00

Translator 52830fce7c Translated ['generic-methodologies-and-resources/shells/README.md', 'lin

2024-01-06 23:17:06 +00:00

9.8 KiB

Raw Blame History

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

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!
Adquira o material oficial PEASS & HackTricks
Descubra A Família PEASS, nossa coleção de NFTs exclusivos
Participe do 💬 grupo no Discord ou do grupo no telegram ou siga-me no Twitter 🐦 @carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud no github.

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:

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:

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á:

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.
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).
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.
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!).