John the Ripper e Aplicação de Políticas de Senha

Introdução

No cenário digital atual, políticas de senhas fortes são cruciais para proteger informações sensíveis. No entanto, mesmo com políticas implementadas, vulnerabilidades podem existir. Este laboratório irá guiá-lo através do processo de uso do John the Ripper, uma poderosa ferramenta de quebra de senhas, para avaliar a eficácia das políticas de senhas existentes. Você aprenderá a identificar fraquezas, recomendar políticas mais fortes e entender como implementar verificações de conformidade automatizadas para aprimorar a segurança geral. Esta experiência prática fornecerá a você habilidades práticas em auditoria e aplicação de segurança de senhas.

Analisar Políticas de Senha Existentes

Nesta etapa, você começará a entender como analisar as políticas de senha existentes em um sistema Linux. Embora não modificaremos as políticas de todo o sistema diretamente neste laboratório, entender onde essas políticas são configuradas é crucial para auditoria. Focaremos em examinar arquivos de configuração comuns que ditam a complexidade, idade e configurações de bloqueio de senha.

Primeiro, vamos examinar o arquivo /etc/login.defs, que contém configurações globais para o conjunto de senhas shadow. Este arquivo define parâmetros como envelhecimento de senha, comprimento mínimo de senha e idade máxima de senha.

Use o comando grep para procurar configurações relacionadas a senhas em /etc/login.defs:

grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE|ENCRYPT_METHOD" /etc/login.defs

Você deverá ver uma saída semelhante a esta, embora os valores possam variar:

PASS_MAX_DAYS	99999
PASS_MIN_DAYS	0
PASS_WARN_AGE	7
ENCRYPT_METHOD SHA512

Em seguida, examinaremos /etc/pam.d/common-password, que é um arquivo de configuração do PAM (Pluggable Authentication Modules) que controla as regras de complexidade de senha. Este arquivo frequentemente inclui módulos como pam_cracklib.so ou pam_pwquality.so, que aplicam regras como a exigência de letras maiúsculas e minúsculas, dígitos e caracteres especiais.

Use cat para visualizar o conteúdo de /etc/pam.d/common-password:

cat /etc/pam.d/common-password

Você verá muitas linhas, mas preste atenção às linhas que contêm pam_pwquality.so ou pam_cracklib.so e seus parâmetros (por exemplo, minlen, difok, ucredit, lcredit, dcredit, ocredit).

password        [success=1 default=ignore]      pam_unix.so obscure sha512 shadow
password        requisite                       pam_pwquality.so retry=3 minlen=8 difok=3 reject_username enforce_for_root
password        optional                        pam_gnome_keyring.so
password        optional                        pam_kwallet.so
password        optional                        pam_systemd.so

Finalmente, vamos verificar o arquivo /etc/security/pwquality.conf, que fornece controle mais granular sobre as configurações de qualidade de senha quando pam_pwquality.so é usado.

cat /etc/security/pwquality.conf

Você pode ver configurações como minlen, dcredit, ucredit, lcredit, ocredit, maxrepeat, etc.

## Configuration for the pam_pwquality module
#
## The setting of the PAM module is usually in /etc/pam.d/common-password
#
## minlen = 8
## difok = 3
## dcredit = -1
## ucredit = -1
## lcredit = -1
## ocredit = -1
## minclass = 0
## maxrepeat = 0
## maxsequence = 0
## gecoscheck = 0
## dictcheck = 1
## usercheck = 1
## enforce_for_root

Ao examinar esses arquivos, você pode obter uma boa compreensão das configurações atuais da política de senha no sistema.

Usar John the Ripper para Testar a Eficácia das Políticas

Nesta etapa, você usará o John the Ripper (JtR) para testar a eficácia das políticas de senha. Simularemos um cenário em que você tem acesso a um arquivo de hash de senha e tenta quebrar senhas fracas.

Primeiro, vamos criar um arquivo de senha fictício para fins de demonstração. Criaremos um arquivo chamado passwords.txt com algumas senhas fracas.

echo "user1:password123" > ~/project/passwords.txt
echo "user2:welcome" >> ~/project/passwords.txt
echo "user3:labexrocks" >> ~/project/passwords.txt

Agora, precisamos converter essas senhas em texto simples para um formato que o John the Ripper possa entender. Usaremos unshadow (um componente do JtR) para combinar um arquivo fictício /etc/passwd e /etc/shadow. Para simplificar, usaremos apenas o arquivo passwords.txt diretamente com o modo stdin do JtR para quebra.

Vamos criar um arquivo de lista de palavras simples chamado wordlist.txt que o John the Ripper usará para tentar quebrar as senhas.

echo "password123" > ~/project/wordlist.txt
echo "welcome" >> ~/project/wordlist.txt
echo "labexrocks" >> ~/project/wordlist.txt
echo "secret" >> ~/project/wordlist.txt
echo "123456" >> ~/project/wordlist.txt

Agora, use o John the Ripper para quebrar as senhas de passwords.txt usando wordlist.txt.

john --format=raw-md5 --wordlist=~/project/wordlist.txt ~/project/passwords.txt

Você poderá ver uma saída semelhante a esta, indicando senhas quebradas:

Using default input encoding: UTF-8
Loaded 3 password hashes with no different salts (Raw-MD5 [MD5])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
password123 (user1)
welcome (user2)
labexrocks (user3)
3g 0:00:00:00 DONE (2023-10-27 08:30) 100.0% 3g/s 100.0p/s 100.0c/s 100.0C/s password123 welcome labexrocks
Session completed.

Para visualizar as senhas quebradas, você pode usar a opção --show:

john --show ~/project/passwords.txt

Saída:

user1:password123

user2:welcome

user3:labexrocks

3 password hashes cracked, 0 left

Isso demonstra com que facilidade senhas fracas podem ser quebradas usando uma lista de palavras simples.

Identificar Lacunas nas Políticas de Senha

Nesta etapa, você identificará as lacunas nas políticas de senha simuladas com base nos resultados de quebra da etapa anterior. O fato de o John the Ripper ter conseguido quebrar facilmente as senhas indica fraquezas significativas.

Com base nas senhas quebradas (password123, welcome, labexrocks), aqui estão algumas lacunas comuns que permitiram que elas fossem quebradas:

1. Falta de Requisitos de Complexidade: As senhas welcome e labexrocks são palavras simples de dicionário ou frases facilmente adivinháveis. password123 é um padrão comum. Uma política forte deve impor uma mistura de letras maiúsculas, minúsculas, números e caracteres especiais.
2. Comprimento Insuficiente: Embora password123 e labexrocks tenham 11 e 10 caracteres, respectivamente, elas ainda são vulneráveis devido à sua simplicidade. As políticas devem impor um comprimento mínimo, geralmente de 12 caracteres ou mais, para aumentar o espaço de busca para os atacantes.
3. Sem Verificação de Palavras de Dicionário: A política não impediu que os usuários escolhessem palavras comuns de dicionário ou variações simples.
4. Sem Verificação de Padrões Comuns: Senhas como password123 seguem padrões previsíveis que são frequentemente incluídos em listas de palavras para quebra.
5. Falta de Histórico de Senha/Prevenção de Reutilização: Se os usuários puderem reutilizar senhas antigas, mesmo que já tenham sido fortes, elas se tornam vulneráveis se essas senhas antigas forem vazadas.

Para simular a identificação dessas lacunas, vamos considerar como seria uma política de senha mais forte. Por exemplo, se nossa política atual permitir minlen=8 e nenhum requisito específico de classe de caracteres, então welcome (7 caracteres) falharia, mas password123 (11 caracteres, sem caracteres especiais) passaria. Os resultados da quebra destacam que, mesmo que uma senha atenda a um requisito básico de comprimento, ela ainda pode ser fraca se a complexidade e as verificações de dicionário não forem aplicadas.

Pense em como os parâmetros do módulo pam_pwquality.so (como minlen, dcredit, ucredit, lcredit, ocredit, dictcheck) poderiam ser ajustados para evitar senhas fracas como essas. Por exemplo, definir dcredit=-1 exigiria pelo menos um dígito, ucredit=-1 para maiúsculas, etc.

Esta etapa é principalmente conceitual, focando na análise dos resultados do exercício de quebra anterior para entender as deficiências da política.

Recomendar Políticas de Senha Mais Fortes

Nesta etapa, você formulará recomendações para políticas de senha mais fortes com base nas lacunas identificadas. Políticas de senha eficazes equilibram segurança e usabilidade.

Aqui estão algumas recomendações para uma política de senha mais robusta:

1. Comprimento Mínimo: Aumente o comprimento mínimo da senha para pelo menos 12-14 caracteres. Senhas mais longas são exponencialmente mais difíceis de quebrar.
   • Exemplo de configuração PAM: minlen=12 em /etc/security/pwquality.conf ou pam_pwquality.so minlen=12 em /etc/pam.d/common-password.
2. Requisitos de Complexidade: Imponha o uso de uma mistura de tipos de caracteres:
   • Letras maiúsculas (A-Z)
   • Letras minúsculas (a-z)
   • Números (0-9)
   • Caracteres especiais (!@#$%^&*()_+-=[]{}|;':",./<>?)
   • Exemplo de configuração PAM: dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 em /etc/security/pwquality.conf ou pam_pwquality.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 em /etc/pam.d/common-password.
3. Verificação de Dicionário e Padrões Comuns: Impede o uso de palavras comuns de dicionário, nomes comuns e padrões facilmente adivinháveis (como password123, qwerty, 123456).
   • Exemplo de configuração PAM: dictcheck=1 usercheck=1 em /etc/security/pwquality.conf ou pam_pwquality.so dictcheck=1 usercheck=1 em /etc/pam.d/common-password.
4. Histórico de Senha/Prevenção de Reutilização: Impede que os usuários reutilizem um certo número de suas senhas anteriores. Isso mitiga o risco se uma senha antiga for comprometida.
   • Exemplo de configuração PAM: remember=5 com pam_unix.so em /etc/pam.d/common-password (por exemplo, password required pam_unix.so obscure sha512 shadow remember=5).
5. Política de Bloqueio de Conta: Implemente uma política de bloqueio de conta após um certo número de tentativas de login falhadas para dissuadir ataques de força bruta.
   • Exemplo de configuração PAM: Usando pam_tally2.so ou pam_faillock.so em /etc/pam.d/common-auth (por exemplo, auth required pam_faillock.so deny=3 unlock_time=600).
6. Alterações Regulares de Senha (com cautela): Embora tradicionalmente recomendado, alterações frequentes e obrigatórias de senha podem levar os usuários a escolher senhas mais simples e previsíveis. Uma abordagem melhor é impor complexidade e comprimento fortes, e apenas exigir alterações se uma violação for suspeita.

Para demonstrar uma mudança conceitual, vamos imaginar que estamos atualizando uma política. Não modificaremos realmente os arquivos do sistema, mas você pode ver como o arquivo pwquality.conf poderia ser editado.

Abra um arquivo fictício para simular as recomendações de política:

nano ~/project/recommended_policy.txt

Adicione o seguinte conteúdo ao arquivo:

## Recommended Password Policy Settings
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
dictcheck = 1
usercheck = 1
maxrepeat = 3
maxsequence = 3

Salve e saia do nano (Ctrl+S, Ctrl+X).

Essas configurações imporiam um comprimento mínimo de 14 caracteres, exigiriam pelo menos um dígito, maiúscula, minúscula e caractere especial, e impediriam palavras de dicionário e nomes de usuário.

Implementar Verificações Automatizadas de Conformidade de Políticas

Nesta etapa, você aprenderá sobre a implementação de verificações automatizadas de conformidade de políticas. Embora a aplicação de políticas em todo o sistema seja feita via PAM e outros arquivos de configuração, verificações automatizadas podem ser usadas para auditar regularmente senhas de usuários ou configurações de sistema em relação a políticas definidas.

Para este laboratório, simularemos uma verificação de conformidade simples usando um script shell. Este script verificará se a senha de um usuário fictício atende a um requisito básico de comprimento. Em um cenário do mundo real, tais scripts seriam mais complexos, potencialmente integrando-se a ferramentas como OpenSCAP ou scripts personalizados para auditar hashes de senha reais (se permitido e ético) ou arquivos de configuração.

Primeiro, vamos criar um usuário fictício e um arquivo de hash de senha fictício para simular um estado do sistema. Não criaremos usuários reais do sistema.

echo "testuser:\$6\$salt\$hashedpassword" > ~/project/dummy_shadow.txt

Agora, crie um script shell simples chamado check_password_compliance.sh que verifica se o comprimento da senha para testuser em dummy_shadow.txt é maior que um determinado valor (por exemplo, 10 caracteres).

nano ~/project/check_password_compliance.sh

Adicione o seguinte conteúdo ao script:

#!/bin/bash

## This script simulates a basic password length compliance check.
## In a real scenario, you would parse actual shadow file entries
## or use more sophisticated tools.

MIN_LENGTH=10
PASSWORD_HASH=$(grep "testuser" ~/project/dummy_shadow.txt | cut -d':' -f2)

## For demonstration, we'll just check the length of a placeholder hash.
## In reality, you'd need to crack or analyze the actual hash.
## Here, we're just checking if the hash string itself is long enough,
## which is NOT how real password length checks work, but serves as a
## placeholder for a compliance check.

if [ ${#PASSWORD_HASH} -ge $MIN_LENGTH ]; then
  echo "Compliance Check: testuser password hash length meets minimum requirement ($MIN_LENGTH characters)."
  exit 0
else
  echo "Compliance Check: testuser password hash length DOES NOT meet minimum requirement ($MIN_LENGTH characters)."
  exit 1
fi

Salve e saia do nano (Ctrl+S, Ctrl+X).

Torne o script executável:

chmod +x ~/project/check_password_compliance.sh

Agora, execute o script de verificação de conformidade:

~/project/check_password_compliance.sh

Você deverá ver uma saída indicando conformidade com base no comprimento do hash fictício:

Compliance Check: testuser password hash length meets minimum requirement (10 characters).

Este exemplo simples ilustra o conceito de uma verificação de conformidade automatizada. Em um ambiente de produção, tais scripts poderiam ser agendados para serem executados periodicamente usando cron para garantir a adesão contínua às políticas de senha. Verificações mais avançadas envolveriam a análise de hashes de senha reais (se permitido e com considerações de segurança adequadas), a verificação contra listas de dicionário ou a integração com frameworks de conformidade de segurança.

Resumo

Neste laboratório, você adquiriu experiência prática na auditoria e aplicação de políticas de senha. Você aprendeu a analisar as configurações de política de senha existentes em um sistema Linux examinando arquivos-chave como /etc/login.defs, /etc/pam.d/common-password e /etc/security/pwquality.conf. Em seguida, você usou o John the Ripper para demonstrar com que facilidade senhas fracas podem ser quebradas, destacando a importância de políticas robustas. Com base nessas descobertas, você formulou recomendações para políticas de senha mais fortes, focando em comprimento, complexidade e verificações de dicionário. Finalmente, você explorou o conceito de verificações automatizadas de conformidade criando um script simples para verificar a adesão à política de senha. Este laboratório fornece uma compreensão fundamental da auditoria de segurança de senhas, equipando você com as habilidades para identificar e mitigar vulnerabilidades relacionadas a senhas.