How to remediate – Kismet Server Information Disclosure

1. Introduction

Kismet Server Information Disclosure allows an attacker to collect information about a wireless monitoring service running on your network. This could allow them to gain a better understanding of your network layout and potentially identify targets for further attacks. Systems running Kismet server software are usually affected, impacting confidentiality by exposing network details.

2. Technical Explanation

The vulnerability occurs because the Kismet server allows clients to access information about wireless activity without sufficient restriction. An anonymous attacker can query the service and collect data on connected devices and networks. There is no CVE associated with this specific disclosure, but it relates to insecure defaults in the Kismet configuration. For example, an attacker could use a simple script to enumerate all visible access points and their associated details.

• Root cause: The Kismet server does not restrict access to client information by default.
• Exploit mechanism: An attacker connects to the Kismet server and requests data about wireless networks.
• Scope: Affected platforms are those running the Kismet server software, typically Linux-based systems.

3. Detection and Assessment

To confirm if a system is vulnerable, check if the Kismet server is running and accessible from outside your network. You can also review the server configuration for insecure settings.

• Quick checks: Use the command `ps aux | grep kismet` to see if the Kismet server process is active.
• Scanning: Nessus plugin ID 139785 may identify exposed Kismet servers, but results should be verified manually.
• Logs and evidence: Check `/var/log/kismet/kismet.log` for client connections or unusual activity.

ps aux | grep kismet

4. Solution / Remediation Steps

To fix this issue, limit incoming traffic to the Kismet server port and restrict access to sensitive information.

4.1 Preparation

• Ensure you have appropriate permissions to modify the Kismet configuration. Change windows should be scheduled during off-peak hours with approval from network administrators.

4.2 Implementation

1. Step 1: Configure your firewall to allow only trusted IP addresses or networks to connect to the Kismet server port (typically TCP port 803).
2. Step 2: Edit the Kismet configuration file (`/etc/kismet/kismet.conf`) and disable client listing if appropriate by setting `client_listing = false`.
3. Step 3: Restart the Kismet service: `sudo systemctl start kismet`.

4.3 Config or Code Example

Before

# /etc/kismet/kismet.conf
client_listing = true

After

# /etc/kismet/kismet.conf
client_listing = false

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – restrict access to the Kismet server and its data to only authorized users and systems.
• Practice 2: Network segmentation – isolate the Kismet server on a separate network segment to limit potential damage from compromise.

4.5 Automation (Optional)

No automation is provided due to the complexity of firewall configuration and the need for specific network settings.

5. Verification / Validation

To confirm the fix, check that only authorized IP addresses can connect to the Kismet server port and verify that client listing is disabled.

• Post-fix check: Use `netstat -tulnp | grep 803` to see which IPs are connected to the Kismet server.
• Re-test: Attempt to connect to the Kismet server from an unauthorized IP address and verify that the connection is blocked.
• Smoke test: Ensure authorized users can still monitor wireless activity as expected.
• Monitoring: Monitor `/var/log/kismet/kismet.log` for any unexpected client connections or errors.

netstat -tulnp | grep 803

6. Preventive Measures and Monitoring

Update security baselines to include restrictions on access to wireless monitoring services.

• Baselines: Update your network security baseline to require firewall rules for all external-facing services, including Kismet.
• Pipelines: Include configuration checks in CI/CD pipelines to ensure that the `client_listing` setting remains disabled.
• Asset and patch process: Review Kismet configurations regularly as part of a vulnerability management program.

7. Risks, Side Effects, and Roll Back

Restricting access to the Kismet server may prevent legitimate users from monitoring wireless activity if not configured correctly.

• Roll back: Restore the original Kismet configuration files and restart the service: `sudo systemctl stop kismet; sudo cp /path/to/backup/kismet.conf /etc/kismet/kismet.conf; sudo systemctl start kismet`.

8. References and Resources

Links to resources related to this vulnerability.

• Vendor advisory or bulletin: http://svn.kismetwireless.net/code/trunk/docs/DEVEL.client