How to remediate – Unpassworded ‘friday’ Account

1. Introduction

The ‘friday’ account has no password set. This means anyone with access to the system could log in as this user without authentication, potentially gaining further control. Systems running any operating system supporting local accounts are affected. A successful exploit could compromise confidentiality, integrity and availability of data on the host.

2. Technical Explanation

The account ‘friday’ lacks a password due to either an intentional configuration or oversight during user creation. An attacker can directly log in without credentials if they have access to the system. This is documented as CVE-1999-0502, though it represents a general misconfiguration rather than a specific software flaw. For example, an attacker with shell access could simply switch users to ‘friday’ without being prompted for a password. Affected systems include any operating system allowing local account creation and login.

• Root cause: The account ‘friday’ was created without a password assigned.
• Exploit mechanism: An attacker gains access to the host and uses standard user switching mechanisms (e.g., ‘su friday’ on Linux, or directly logging in via the GUI) to assume the identity of the unpassworded account.
• Scope: All operating systems supporting local accounts are potentially affected.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking for password-less accounts. A quick check involves listing all user accounts with empty password fields. More thorough assessment requires reviewing account policies and auditing logs for failed login attempts (which won’t occur in this case).

• Quick checks: On Linux, run cut -d: -f1 /etc/shadow | while read user; do sudo chage -l $user | grep "Password last set"; done. Accounts with “Never” listed will have no password.
• Scanning: Nessus plugin ID 23805 may identify unpassworded accounts, but results should be verified manually.
• Logs and evidence: Windows event logs do not directly indicate an unpassworded account; review user creation events for missing password policies. Linux systems typically don’t log this specifically.

cut -d: -f1 /etc/shadow | while read user; do sudo chage -l $user | grep "Password last set"; done

4. Solution / Remediation Steps

Fix the issue by setting a strong password for the ‘friday’ account or disabling it if no longer needed. Follow these steps carefully to avoid service disruption.

4.1 Preparation

• No services need stopping, but inform users if ‘friday’ is an active account.
• Roll back plan: If the password change causes issues, revert to the backup or snapshot. A record of the original state should be kept.
• Change window needs: Standard maintenance window may apply depending on system criticality and user impact. Approval from IT manager recommended.

4.2 Implementation

1. Step 1: Set a password for the ‘friday’ account using the appropriate command for your operating system. On Linux, run sudo passwd friday and follow prompts to enter a new password twice.
2. Step 2: Verify the password has been set successfully by attempting to switch users or log in as ‘friday’ with the new password.
3. Step 3: If ‘friday’ is not required, disable the account using sudo userdel -r friday on Linux, or via Active Directory Users and Computers on Windows.

4.3 Config or Code Example

Before

friday::0:0:99999:Friday Account,,,:/home/friday:/bin/bash

After

friday:$6$rounds=5000$salt$hashedpassword:18734:0:99999:Friday Account,,,:/home/friday:/bin/bash

4.4 Security Practices Relevant to This Vulnerability

Several security practices can prevent this issue. Least privilege reduces the impact if an account is compromised. Strong password policies enforce complexity and regular changes. Regular account audits identify unused or misconfigured accounts.

• Practice 1: Implement least privilege, ensuring users only have access to resources they need.
• Practice 2: Enforce strong password policies with minimum length, complexity requirements, and regular rotation.

4.5 Automation (Optional)

#!/bin/bash
# Script to set passwords for unpassworded accounts
for user in $(cut -d: -f1 /etc/shadow | while read u; do sudo chage -l $u | grep "Password last set" | grep "Never"; done); do
  echo "Setting password for user: $user"
  sudo passwd $user
done

5. Verification / Validation

• Post-fix check: On Linux, run cut -d: -f1 /etc/shadow | while read user; do sudo chage -l $user | grep "Password last set"; done. Accounts should now show a password age instead of “Never”.
• Re-test: Re-run the quick check from Section 3 to confirm no accounts are listed as having passwords never set.
• Smoke test: Verify that other user logins and core system services continue to function normally.
• Monitoring: Monitor authentication logs for failed login attempts against ‘friday’ account, which could indicate a brute-force attack.

cut -d: -f1 /etc/shadow | while read user; do sudo chage -l $user | grep "Password last set"; done

6. Preventive Measures and Monitoring

Update security baselines to include password requirements for all local accounts. Implement automated account creation processes with enforced policies. Regular patch cycles ensure systems are up-to-date, reducing the risk of misconfigurations.

• Baselines: Update a CIS benchmark or internal security policy to require passwords on all local accounts.
• Pipelines: Integrate checks into CI/CD pipelines to validate account configurations during deployment.
• Asset and patch process: Review new user creation requests and regularly audit existing accounts for compliance with password policies.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Password change may require updating application configurations using ‘friday’ as a service account.
• Risk or side effect 2: Disabling ‘friday’ could break applications relying on this user ID.
• Roll back: Restore the system from the backup or snapshot created in Preparation (Section 4.1).

8. References and Resources

• Vendor advisory or bulletin: No specific vendor advisory exists for this general misconfiguration.
• NVD or CVE