How to remediate – Unpassworded ‘lp’ Account

1. Introduction

The ‘lp’ account vulnerability means an account on a remote host has no password set. This allows attackers to gain unauthorised access and potentially escalate privileges on affected systems. Systems commonly affected are those running CUPS, the Common Unix Printing System, particularly Linux and macOS servers. A successful exploit could compromise confidentiality, integrity, and availability of the system.

2. Technical Explanation

The ‘lp’ account is a default user created by CUPS for printing management. When no password is set, it’s possible to log in without authentication. CVE-1999-0502 describes this issue. An attacker could use this to execute commands with the privileges of the ‘lp’ account and potentially gain root access.

• Root cause: The CUPS installation process does not enforce a password for the ‘lp’ account by default, leaving it open for remote login without credentials.
• Exploit mechanism: An attacker can attempt to log in remotely using the ‘lp’ username with no password provided. If successful, they gain access to the system via a shell session or other CUPS management interfaces. For example, an attacker could use SSH to connect as ‘lp’ without a password if SSH is configured to allow it.

3. Detection and Assessment

You can check for the vulnerability by verifying whether a password exists for the ‘lp’ account. A thorough method involves checking shadow file entries.

• Quick checks: Use the following command to see if a password hash is present for the ‘lp’ user: getent passwd lp If no hash appears, it indicates no password has been set.
• Scanning: Nessus vulnerability ID 10824 may detect this issue as an example.
• Logs and evidence: Check system logs (e.g., /var/log/auth.log or /var/log/secure) for failed login attempts to the ‘lp’ account, which might indicate probing activity.

getent passwd lp

4. Solution / Remediation Steps

To fix this issue, set a strong password for the ‘lp’ account or disable it if it’s not required.

4.1 Preparation

• Ensure you have an alternative administrator account available in case of issues. Roll back by reverting the password change or re-enabling the account if disabled.
• A standard change window may be required depending on your organisation’s policies, and approval from a senior IT admin might be needed.

4.2 Implementation

1. Step 1: Set a password for the ‘lp’ account using the `passwd` command: sudo passwd lp. You will be prompted to enter a new password twice.
2. Step 2: Verify the password has been set by running getent passwd lp again and confirming a hash is present in the output.

4.3 Config or Code Example

Before

lp:x:100:101::/home/lp:/bin/false

After

lp:x:100:101:LP Administrator,,,:/home/lp:/bin/false

4.4 Security Practices Relevant to This Vulnerability

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

• Practice 1: Least privilege reduces the impact of exploitation by limiting the permissions available to compromised accounts.
• Practice 2: Secure defaults ensure systems are configured with strong security settings out-of-the-box, reducing the risk of common misconfigurations like unpassworded accounts.

4.5 Automation (Optional)

A simple script can be used to check and set passwords for default accounts at scale.

#!/bin/bash
# Check if 'lp' account has a password
if ! getent passwd lp | grep -q ':*:' ; then
  echo "Setting password for 'lp' account..."
  sudo passwd lp
fi

5. Verification / Validation

Confirm the fix by verifying that a password is set for the ‘lp’ account and attempting to log in with an incorrect password. A smoke test should confirm printing functionality remains operational if required.

• Post-fix check: Run getent passwd lp. The output should show a hash after the colon, indicating a password has been set.
• Re-test: Re-run the initial detection command (getent passwd lp) to confirm no blank password is present.
• Smoke test: Attempt to print a test page using CUPS to ensure printing functionality still works as expected.
• Monitoring: Monitor system logs for failed login attempts to the ‘lp’ account, which could indicate ongoing brute-force attacks.

getent passwd lp

6. Preventive Measures and Monitoring

Update security baselines to include password requirements for default accounts. Implement checks in CI/CD pipelines to prevent unpassworded accounts from being deployed.

• Baselines: Update your system security baseline or policy to require a strong password for all default accounts, including ‘lp’.
• Asset and patch process: Review the configuration of new systems regularly to ensure compliance with security policies. A monthly review cycle is sensible.

7. Risks, Side Effects, and Roll Back

Setting a password may break existing scripts or applications that rely on unauthenticated access to CUPS. Disabling the account might affect printing functionality.

• Risk or side effect 2: Loss of printing functionality if the account is disabled without proper configuration. Mitigation: Ensure alternative administrator accounts are available for managing CUPS.
• Roll back: If setting a password causes issues, revert to the previous state by removing the password using sudo passwd -d lp. If disabling caused problems, re-enable the account with sudo useradd -e lp (replace <date> with expiry date).

8. References and Resources

• Vendor advisory or bulletin: KDE Security Advisory
• NVD or CVE entry: CVE-1999-0502
• Product or platform documentation relevant to the fix: CUPS Documentation