Introduction
In this lab, you will gain hands-on experience with John the Ripper, a widely used open-source password security auditing and password recovery tool. Understanding how to use such tools is crucial for identifying vulnerabilities in password policies and strengthening overall system security. You will learn the practical steps involved in collecting password hashes, using John the Ripper to identify weak passwords, generating reports on cracked passwords, and formulating recommendations for improved password policies. This lab will also touch upon the automation of the password auditing process, providing a comprehensive overview of password security best practices.
Collect Password Hashes for Auditing
In this step, you will learn how to collect password hashes, which are essential for password auditing. On Linux systems, password hashes are typically stored in the /etc/shadow file. However, accessing this file directly requires root privileges. For the purpose of this lab, we have created a dummy shadow file named /etc/shadow_dummy that you will use.
First, let's examine the contents of the dummy shadow file.
cat /etc/shadow_dummy
You should see output similar to this, showing usernames and their corresponding password hashes:
user1:5f4dcc3b5aa765d61d8327deb882cf99
user2:21232f297a57a5a743894a0e4a801fc3
user3:d41d8cd98f00b204e9800998ecf8427e
user4:e10adc3949ba59abbe56e057f20f883e
user5:a8b7c6d5e4f3g2h1i0j9k8l7m6n5o4p3
Next, you will copy this dummy shadow file to your current working directory (~/project) to make it easily accessible for John the Ripper.
cp /etc/shadow_dummy ~/project/hashes.txt
Now, verify that the hashes.txt file has been copied successfully to your ~/project directory.
ls ~/project/hashes.txt
The output should confirm the presence of the file:
/home/labex/project/hashes.txt
Run John the Ripper for Weak Password Identification
In this step, you will use John the Ripper to identify weak passwords from the hashes.txt file you prepared. John the Ripper can use various cracking modes, including dictionary attacks. We will perform a dictionary attack using a pre-defined wordlist.
First, ensure you are in the ~/project directory where your hashes.txt and wordlist.txt files are located.
cd ~/project
Now, execute John the Ripper using the hashes.txt file and the wordlist.txt file. The --wordlist option specifies the path to your wordlist.
john --wordlist=wordlist.txt hashes.txt
John the Ripper will start processing the hashes.g. If it finds any matches, it will display the cracked passwords. The output might look similar to this:
Using default input encoding: UTF-8
Loaded 5 password hashes with no different salts (LM HASH, descrypt/BSDI crypt/other crypt(3) [DES/AES-NI])
Press 'q' or Ctrl-C to abort, almost any other key for status
password (user1)
123456 (user2)
test (user3)
admin (user4)
4g 0:00:00:00 DONE (2023-10-27 08:30) 400% (ETA: 08:30) 0.000c/s 0p/s 4.000w/s 4.000P/s user1, user2, user3, user4
Session completed.
In this example, John the Ripper successfully cracked the passwords for user1, user2, user3, and user4. The password for user5 was not cracked because it's not in our simple wordlist.
To see the passwords that John has cracked so far, you can use the --show option.
john --show hashes.txt
The output will list the cracked passwords:
user1:password
user2:123456
user3:test
user4:admin
4 password hashes cracked, 1 left
This command is useful for reviewing the results of your cracking session.
Generate Reports on Cracked Passwords
In this step, you will learn how to generate reports on the cracked passwords. John the Ripper stores the cracked passwords in a file, typically ~/.john/john.pot. You can use the --show option to display these cracked passwords, which serves as a basic report.
To get a clean list of cracked passwords, you can redirect the output of john --show to a file. This is a common practice for generating reports that can be further analyzed or shared.
First, let's ensure we are in the ~/project directory.
cd ~/project
Now, redirect the output of john --show hashes.txt to a new file named cracked_passwords.txt.
john --show hashes.txt > cracked_passwords.txt
This command will not produce any output on the terminal, but it will create the cracked_passwords.txt file in your current directory.
Next, view the content of the cracked_passwords.txt file to confirm the report has been generated correctly.
cat cracked_passwords.txt
You should see the list of cracked passwords, similar to the following:
user1:password
user2:123456
user3:test
user4:admin
4 password hashes cracked, 1 left
This cracked_passwords.txt file now serves as your report, detailing the user accounts with weak, cracked passwords. In a real-world scenario, this report would be used to identify users who need to change their passwords immediately.
Recommend Password Policy Improvements
In this step, you will formulate recommendations for improving password policies based on the findings from the password auditing. Identifying weak passwords is only the first step; the next crucial step is to implement measures to prevent such vulnerabilities in the future.
Based on the cracked passwords (password, 123456, test, admin), it's clear that the current password policy (or lack thereof) allows for very simple and common passwords.
Here are some key recommendations for improving password policies:
- Minimum Length: Enforce a minimum password length, typically 12 characters or more. Longer passwords are exponentially harder to crack.
- Complexity Requirements: Mandate the use of a mix of character types:
- Uppercase letters (A-Z)
- Lowercase letters (a-z)
- Numbers (0-9)
- Special characters (!@#$%^&*()_+-=[]{}|;:'",.<>/?`~)
- Avoid Common Passwords: Implement a blacklist of commonly used or easily guessable passwords (like those found in our
wordlist.txt). Many systems can check new passwords against such blacklists. - No Personal Information: Advise users against using personal information (names, birthdays, pet names) that can be easily guessed or found online.
- Regular Changes (with caution): While historically recommended, frequent mandatory password changes can lead users to choose simpler, more predictable passwords. A better approach is to enforce strong passwords and only require changes if a breach is suspected.
- Multi-Factor Authentication (MFA): For critical systems, implement MFA. Even if a password is compromised, MFA adds an additional layer of security.
- Password Managers: Encourage or provide password managers to users. These tools can generate and store strong, unique passwords for different services.
To demonstrate understanding, consider how you would communicate these recommendations. For instance, you might draft a simple policy statement.
Let's create a file named password_policy_recommendations.txt in your ~/project directory and add a few key recommendations to it.
cd ~/project
echo "--- Password Policy Recommendations ---" | tee password_policy_recommendations.txt > /dev/null
echo "1. Minimum length: 12 characters" | tee -a password_policy_recommendations.txt > /dev/null
echo "2. Complexity: Mix of uppercase, lowercase, numbers, special characters" | tee -a password_policy_recommendations.txt > /dev/null
echo "3. Avoid common passwords and personal information" | tee -a password_policy_recommendations.txt > /dev/null
echo "4. Implement Multi-Factor Authentication (MFA) for critical systems" | tee -a password_policy_recommendations.txt > /dev/null
Now, view the content of the password_policy_recommendations.txt file.
cat password_policy_recommendations.txt
The output should show your recommendations:
--- Password Policy Recommendations ---
1. Minimum length: 12 characters
2. Complexity: Mix of uppercase, lowercase, numbers, special characters
3. Avoid common passwords and personal information
4. Implement Multi-Factor Authentication (MFA) for critical systems
This file represents a basic report of your recommendations.
Automate Password Auditing Process
In this step, you will explore how to automate parts of the password auditing process. While John the Ripper is a manual tool, its execution can be scripted to run periodically, making the auditing process more efficient and proactive. Automation helps in continuously monitoring password strength and identifying new vulnerabilities as they emerge.
A simple way to automate is to create a shell script that performs the steps you've learned: collecting hashes, running John the Ripper, and generating a report.
Let's create a simple shell script named audit_script.sh in your ~/project directory.
cd ~/project
nano audit_script.sh
Inside the nano editor, add the following content:
#!/bin/bash
## Define paths
HASH_FILE="/etc/shadow_dummy" ## In a real scenario, this would be /etc/shadow
WORDLIST_FILE="wordlist.txt"
OUTPUT_DIR="~/project/audit_results"
CRACKED_REPORT="$OUTPUT_DIR/cracked_passwords_$(date +%Y%m%d_%H%M%S).txt"
## Create output directory if it doesn't exist
mkdir -p "$OUTPUT_DIR"
echo "--- Starting Password Audit ---"
## Step 1: Copy hashes
cp "$HASH_FILE" "$OUTPUT_DIR/hashes.txt"
echo "Hashes copied to $OUTPUT_DIR/hashes.txt"
## Step 2: Run John the Ripper
echo "Running John the Ripper..."
john --wordlist="$WORDLIST_FILE" "$OUTPUT_DIR/hashes.txt"
## Step 3: Generate report
echo "Generating cracked password report..."
john --show "$OUTPUT_DIR/hashes.txt" > "$CRACKED_REPORT"
echo "Audit complete. Report saved to $CRACKED_REPORT"
echo "--- Audit Finished ---"
Press Ctrl+X, then Y, then Enter to save and exit nano.
Next, make the script executable:
chmod +x audit_script.sh
Now, run the script to see it in action:
./audit_script.sh
You will see output similar to the manual steps, indicating the audit process is running and a report is being generated.
--- Starting Password Audit ---
Hashes copied to /home/labex/project/audit_results/hashes.txt
Running John the Ripper...
Using default input encoding: UTF-8
Loaded 5 password hashes with no different salts (LM HASH, descrypt/BSDI crypt/other crypt(3) [DES/AES-NI])
Press 'q' or Ctrl-C to abort, almost any other key for status
password (user1)
123456 (user2)
test (user3)
admin (user4)
4g 0:00:00:00 DONE (2023-10-27 08:35) 400% (ETA: 08:35) 0.000c/s 0p/s 4.000w/s 4.000P/s user1, user2, user3, user4
Session completed.
Generating cracked password report...
Audit complete. Report saved to /home/labex/project/audit_results/cracked_passwords_YYYYMMDD_HHMMSS.txt
--- Audit Finished ---
Finally, verify that the audit_results directory and a report file within it have been created.
ls ~/project/audit_results/
You should see hashes.txt and a cracked_passwords_YYYYMMDD_HHMMSS.txt file (where YYYYMMDD_HHMMSS is the current timestamp).
cracked_passwords_20231027_083500.txt hashes.txt
This script can be scheduled to run periodically using tools like cron on a real Linux system, enabling continuous password auditing.
Summary
In this lab, you have successfully learned how to use John the Ripper for password auditing. You started by collecting password hashes from a dummy shadow file, then used John the Ripper with a wordlist to identify weak passwords. You generated a report of the cracked passwords and formulated key recommendations for improving password policies, such as enforcing minimum length, complexity, and avoiding common passwords. Finally, you created a basic shell script to automate the password auditing process, demonstrating how these tasks can be integrated into a continuous security monitoring strategy. This hands-on experience provides a foundational understanding of password security auditing, a critical skill for any system administrator or security professional.
