How to remediate – Enumerate MAC Addresses via SSH

1. Introduction

The vulnerability “Enumerate MAC Addresses via SSH” allows an attacker with valid credentials to discover Media Access Control (MAC) addresses on a remote host. This information can be used for network reconnaissance, potentially aiding in further attacks like man-in-the-middle or ARP poisoning. Systems running SSH are usually affected. A successful exploit could compromise the confidentiality of network topology and enable targeted attacks.

2. Technical Explanation

Nessus identifies this vulnerability by connecting to a remote host via SSH using supplied credentials and enumerating MAC addresses present on the system. This indicates that SSH access allows for discovery of internal network information. The precondition is valid SSH login details. There is no CVE associated with this specific enumeration, but it represents a general information disclosure risk.

• Root cause: SSH access permits querying of network interface data revealing MAC addresses.
• Exploit mechanism: An attacker logs into the remote host via SSH and uses standard networking tools to list interfaces and their corresponding MAC addresses. For example, using `ifconfig` or `ip addr`.
• Scope: Systems running an SSH server with accessible credentials are affected.

3. Detection and Assessment

You can confirm the vulnerability by attempting to connect via SSH and listing network interfaces. A thorough method involves reviewing SSH access logs for unusual activity.

• Quick checks: Attempt to log in via SSH with valid credentials, then run `ifconfig` or `ip addr`. If MAC addresses are displayed, the system is vulnerable.
• Scanning: Nessus plugin ID 16842 can identify this vulnerability.
• Logs and evidence: Review `/var/log/auth.log` (Debian/Ubuntu) or `/var/log/secure` (CentOS/RHEL) for SSH login events, looking for successful connections followed by network interface queries.

ifconfig

4. Solution / Remediation Steps

Disable any unused network interfaces to reduce the attack surface and limit information disclosure.

4.1 Preparation

• Dependencies: Ensure you have SSH access to the remote host. Roll back plan: Re-enable any disabled interfaces if issues occur.
• Change window needs: Standard maintenance window may be appropriate, depending on service impact. Approval from network team is recommended.

4.2 Implementation

1. Step 1: Identify unused network interfaces using `ifconfig` or `ip addr`.
2. Step 2: Disable the interface using `sudo ifdown ` (Debian/Ubuntu) or `sudo nmcli device disconnect ` followed by `sudo nmcli device set connection.autoconnect no` (CentOS/RHEL).
3. Step 3: Verify the interface is disabled using `ifconfig` or `ip addr`.

4.3 Config or Code Example

Before

eth0      Link encap:Ethernet, hwaddr 00:11:22:33:44:55 ...

After

# No output for eth0 after disabling the interface.

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Least privilege – limit SSH access to only authorized users with the minimum necessary permissions.
• Practice 2: Secure Defaults – Disable unused services and interfaces by default to reduce the attack surface.

4.5 Automation (Optional)

#!/bin/bash
# Script to disable unused interfaces on CentOS/RHEL
for interface in $(ip link show | grep -v lo | awk '{print $2}' | sed 's/://g'); do
  if ! ping -c 1 google.com > /dev/null 2>&1; then # Check if the interface has internet connectivity
    echo "Disabling interface: $interface"
    sudo nmcli device disconnect $interface
    sudo nmcli device set $interface connection.autoconnect no
  fi
done

5. Verification / Validation

Confirm the fix by attempting to connect via SSH and listing network interfaces again. The disabled interface should not be visible.

• Post-fix check: Run `ifconfig` or `ip addr`. The previously listed unused interface should no longer appear in the output.
• Re-test: Re-run the Nessus scan; it should no longer report the vulnerability.
• Monitoring: Monitor SSH logs for unexpected login attempts or interface queries.

ifconfig

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update security baselines or policies to include disabling unused network interfaces as a standard configuration setting (for example, CIS benchmarks).
• Pipelines: Implement infrastructure-as-code checks to ensure unused interfaces are disabled during deployment.
• Asset and patch process: Regularly review SSH access logs for unusual activity and unnecessary logins.

7. Risks, Side Effects, and Roll Back

• Roll back: Step 1: Re-enable the disabled interface using `sudo ifup ` (Debian/Ubuntu) or `sudo nmcli device connect ` (CentOS/RHEL).

8. References and Resources

• Vendor advisory or bulletin: N/A – This is a general configuration issue, not a specific vendor flaw.
• NVD or CVE entry: N/A – No specific CVE associated with this enumeration.
• Product or platform documentation relevant to the fix: Debian ifdown man page, CentOS nmcli man page