How to remediate – Unpassworded ‘toor’ Account

1. Introduction

The ‘toor’ account vulnerability means a system has an account with no password set. This is a serious security issue because it allows attackers to gain immediate access to the system, potentially compromising confidentiality, integrity and availability. Systems running older versions of Unix-like operating systems are most commonly affected. A successful attack could lead to complete system takeover.

2. Technical Explanation

The vulnerability occurs due to a default account being created without requiring an initial password change. An attacker can attempt to log in directly as ‘toor’ with no password, bypassing normal authentication. CVE-1999-0502 describes this issue. A simple example is attempting to SSH into the target system and using ‘toor’ as the username with a blank password.

• Root cause: The ‘toor’ account exists without a mandatory password setting during installation or initial configuration.
• Exploit mechanism: An attacker attempts remote login using the ‘toor’ username and an empty password string.
• Scope: Older versions of Unix, BSD, and Linux distributions are affected. Specific versions depend on the distribution’s default configurations.

3. Detection and Assessment

You can check for this vulnerability by attempting to log in as ‘toor’ or by examining system account lists. A thorough method involves checking shadow file entries.

• Quick checks: Attempt a login via SSH using the username ‘toor’ with no password provided.
• Scanning: Nessus plugin ID 10298 can detect this vulnerability, but results should be verified manually.
• Logs and evidence: Check system authentication logs (e.g., /var/log/auth.log or /var/log/secure) for failed login attempts as ‘toor’.

ssh toor@<target_ip_address>

4. Solution / Remediation Steps

To fix this issue, set a strong password for the ‘toor’ account or disable it entirely. These steps are small and can be easily rolled back if needed.

4.1 Preparation

• Dependencies: Access to the target system with root privileges is required. Rollback involves reverting to the pre-change snapshot or re-enabling the account if disabled.
• Change window: A standard maintenance window may be needed, depending on service impact. Approval from a senior administrator might be necessary.

4.2 Implementation

1. Step 1: Set a password for the ‘toor’ account using the `passwd` command.
2. Step 2: Verify the password has been set successfully by attempting to log in as ‘toor’ with the new password.
3. Step 3: If disabling the account, use the command `usermod -L toor`.

4.3 Config or Code Example

Before

cat /etc/shadow | grep toor
toor:!::0:0:99999:7:::

After

passwd toor
New password: 
Retype new password: 
cat /etc/shadow | grep toor
toor:$6$rounds=5000$salt$hashed_password::0:0:99999:7:::

4.4 Security Practices Relevant to This Vulnerability

Practices like least privilege and secure defaults directly address this vulnerability type.

• Practice 1: Least privilege reduces the impact if an account is compromised, limiting access to only necessary resources.
• Practice 2: Secure defaults ensure accounts are created with strong passwords or disabled by default, preventing easy exploitation.

4.5 Automation (Optional)

A simple script can be used to check and set a password for the ‘toor’ account across multiple systems.

#!/bin/bash
for ip in <list_of_ips>; do
  if grep -q "toor:!::" /etc/shadow; then
    echo "Setting password for toor on $ip"
    ssh root@$ip "passwd toor"
  fi
done

5. Verification / Validation

Confirm the fix by attempting to log in with the new password or verifying the account is disabled. A simple service smoke test involves checking basic system functionality.

• Post-fix check: Attempt to SSH into the target system using ‘toor’ as the username and the newly set password. Expected output should be a successful login prompt.
• Re-test: Re-run the quick check from Section 3, which should now fail due to the required password.
• Smoke test: Verify basic system functionality such as pinging an external address or listing files in a directory.

ssh toor@<target_ip_address>

6. Preventive Measures and Monitoring

Update security baselines and implement checks in CI/CD pipelines to prevent this issue from recurring.

• Baselines: Update a system hardening baseline (e.g., CIS benchmark) to require strong passwords for all accounts or disable default accounts.
• Pipelines: Add checks in your infrastructure as code pipeline to ensure no default accounts are created without password settings.
• Asset and patch process: Implement a regular review cycle of system configurations to identify and address any deviations from security standards.

7. Risks, Side Effects, and Roll Back

Setting an incorrect password could lock out the account. Disabling the account may impact legacy applications. Rolling back involves reverting the password change or re-enabling the account.

• Risk or side effect 1: Incorrectly setting a password can lead to accidental lockout of the ‘toor’ account. Mitigation is careful password entry and testing.
• Roll back: If a password was set incorrectly, use `passwd -d toor` to remove the password and then re-set it correctly. If disabled, use `usermod -U toor`.

8. References and Resources

• Vendor advisory or bulletin: No specific vendor advisory available for this general issue.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-1999-0502
• Product or platform documentation relevant to the fix: Consult your specific operating system’s documentation for account management procedures.