Potential fix for code scanning alert no. 13: Clear-text logging of sensitive information

[kimocoder]

Potential fix for https://github.com/kimocoder/wifite2/security/code-scanning/13

General approach: prevent sensitive values (in particular wpasec_api_key and MAC addresses) from being written to logs in clear text, while keeping the rest of the debug information. The safest, minimal‑impact fix is to sanitize log messages at the logger boundary, so any accidental inclusion of secrets (API keys, tokens, MACs) is redacted before hitting disk or stderr. In addition, we can avoid logging the full wlancap2wpasec command (which currently includes the key) by redacting or masking the -k argument in that specific log message, and by not expanding the MAC address in debug logs.

Concretely:

1. In wifite/util/logger.py, add a private helper _sanitize_message that:

   • Replaces occurrences of Configuration.wpasec_api_key with a masked placeholder if available.
   • Masks common patterns where the key appears in commands, such as -k <value> or --key <value>.
   • Masks MAC addresses in common formats (aa:bb:cc:dd:ee:ff).
     Then call _sanitize_message inside _format_message so every log line benefits without changing call sites.

2. In wifite/util/process.py, change the debug message that logs cmd_str at process creation time so it uses a sanitized version of the command string before passing it to log_debug. Because the logger will also sanitize, this is mainly belt‑and‑suspenders; but we can at least avoid obviously printing -k arguments.

3. In wifite/util/interface_manager.py, avoid logging interface_info.mac_address directly in the debug line. We can either drop it entirely or mask it. To keep behavior similar, log a masked form (e.g. first three octets, rest as **).

All changes stay within the provided snippets and only add standard library uses; no new external packages are needed.

---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

In general, the fix is to ensure that sensitive data (API keys, MAC addresses) is never written to the log file in clear text. Since we must not change functionality, the best approach is to improve and centralize masking so that: (1) any occurrence of the wpa‑sec API key is reliably replaced by a masked placeholder before reaching _write_to_file, and (2) any MAC address string is similarly masked consistently in the logger, while interface_manager.py avoids logging raw MACs where possible and clearly uses a masked value.

Concretely:

1. Improve and generalize logger sanitization in wifite/util/logger.py:

   • Ensure that _sanitize_message robustly masks the API key, including cases with surrounding quotes or different occurrences.
   • Ensure MAC address masking is always applied and cannot accidentally be skipped.
   • Optionally, add a small helper to mask MAC strings given explicitly (so other modules can call it instead of rolling their own pattern logic).

2. Use masked MAC values when logging in interface_manager.py:

   • At lines 1711‑1717, the code already creates a masked_mac from interface_info.mac_address. We should:
     • Avoid assigning masked_mac = interface_info.mac_address when the address is not needed raw; instead, construct masked_mac via a helper function or local logic and never log the full address.
     • Keep the masking logic but make it robust and explicit that only the masked value is logged.

3. These changes do not require new imports beyond the standard library (re is already being used). All changes are localized to:

   • wifite/util/logger.py (inside _sanitize_message).
   • wifite/util/interface_manager.py (around the logging of mac_address).

No behavior change occurs from an attacker’s perspective except that secrets/identifiers are now more safely masked in logs.

---

General approach: Ensure the centralized logger robustly sanitizes sensitive data before any message is formatted or emitted, and avoid logging raw sensitive fields (like MAC addresses) in interface_manager.py. Use pattern-based masking so that secrets are never passed through unmodified, and so static analysis can see that the output no longer contains clear-text sensitive data.

Concrete fix in logger.py:

• Replace the current API-key masking logic that relies on knowing the exact Configuration.wpasec_api_key string with a more generic, pattern-based approach.
• Specifically, avoid assigning the tainted key directly to variables used to build the log line; instead, only ever log a constant mask when a key-like token is detected.
• Extend CLI-key masking to cover --api-key and similar, and ensure the replacement never contains the original value.
• Keep and slightly generalize MAC masking here as well (it already exists) so that any message containing a MAC address is automatically masked, regardless of where it originates.

Concretely:

• In _sanitize_message, remove the direct use of Configuration.wpasec_api_key as a string for replace. Instead, when a non-empty wpasec_api_key exists, add a coarse-grained replacement that masks any long, token-like substrings in the message (e.g., sequences of 16+ non-whitespace, non-quote characters), or simply remove the specific block and rely on explicit regex patterns that match wpasec_api_key-style contexts (like wpasec-related options). To stay minimally invasive and satisfy CodeQL, we can avoid binding the tainted key to a new string used in these patterns and instead use generic masking (e.g., regex on (?i)wpasec[_-]?(api)?[_-]?key\s*[:=]\s*\S+).
• Keep the CLI masking (-k, --key) and add --api-key and --wpasec-api-key to that list, all replaced with ****, not with a transformation of the original token.

Concrete fix in interface_manager.py:

• The block around interface_info.mac_address already computes masked_mac and then logs it via log_debug as mac={masked_mac}. The taint appears to be because masked_mac is initially set to interface_info.mac_address and only conditionally overwritten. To fix that, initialize masked_mac to a constant mask and only ever copy from interface_info.mac_address into local parts, never leave it assigned unchanged.
• Additionally, ensure that no other log line in that snippet logs interface_info.mac_address directly (it currently does not), so we only ever log masked_mac, which is guaranteed to be masked or a generic placeholder.

These changes:

• Do not alter the observable functional behavior of the program (logs still show that there is an API key, CLI key, or MAC, but hide their exact values).
• Centralize and strengthen sanitization so all log levels and sinks benefit.
• Address all alert variants reported, since they all flow through the same logging machinery.

---

In general, the problem is that potentially sensitive values (API keys, passwords, etc.) can end up in the logger’s message argument and be written verbatim to stderr and to the log file, with only best-effort ad‑hoc masking for a few patterns. To fix this, we should strengthen _sanitize_message so that any data derived from known secret configuration fields is fully redacted (not just partially masked), and expand its pattern-based masking to catch common “password” style fields in arbitrary messages. This keeps the existing logging behavior but reduces the chance that secrets appear in clear text.

The best targeted change without altering external behavior is to:

1. Improve masking of Configuration.wpasec_api_key by replacing any occurrence with a constant redaction token (e.g., "[REDACTED]") instead of a partially visible version, and handling both exact and obvious quoted/whitespace variants.
2. Add generic regex-based redaction for common secret-like patterns such as password=..., pwd=..., pass: ..., and similar, so that if callers log such strings, the secret portion is replaced with ****.
3. Keep the rest of the logging flow (levels, formatting, verbosity, file output) unchanged, ensuring compatibility.

Concretely in wifite/util/logger.py, within the _sanitize_message method (lines 96–152):

• Adjust the block that handles Configuration.wpasec_api_key to compute a redacted form ("[REDACTED]") and use re.sub to replace the raw key even if surrounded by quotes or whitespace.
• After the CLI key masking block, add new regex substitutions that look for common password/key style parameters and replace their values with ****.
• Reuse the existing lazy import of re where possible to avoid unnecessary imports.

No changes are needed to _format_message, _write_to_file, or the info/debug/warning methods, since they already route all messages through _sanitize_message.

---

[Copilot]

Pull request overview

This PR aims to address code scanning alert #13 by preventing sensitive values (notably the wpa-sec API key and MAC addresses) from being logged in clear text, primarily by adding sanitization at the logger boundary.

Changes:

• Added message sanitization in the central logger to redact API keys and MAC addresses before writing/printing log lines.
• Redacted -k/--key arguments in Process debug logging of process creation.
• Masked interface MAC addresses in interface enumeration debug output.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
wifite/util/process.py	Masks -k/--key argument values in the “Creating process” debug log line.
wifite/util/logger.py	Adds _sanitize_message() and applies it in _format_message() to redact API keys and MAC addresses globally.
wifite/util/interface_manager.py	Masks interface MAC address in a debug “details” log message.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

_sanitize_message() runs multiple re.sub() calls with uncompiled patterns on every log line, which can add noticeable overhead in verbose/debug-heavy runs. Consider importing re once and precompiling the regexes at class/module scope (or using a single pass) to reduce per-log-call work.

[Copilot]

The verbose console output still prints the full command via Color.pe(..." ".join(command)...), which can include -k <api_key> (e.g., wlancap2wpasec) and bypasses the logger’s sanitization. Please apply the same redaction to this verbose output (or log the already-sanitized command string) so secrets aren’t exposed when Configuration.verbose > 1.

Suggested change

	Color.pe(f'\n {{C}}[?] {{W}} Executing: {{B}}{" ".join(command)}{{W}}')
	Color.pe(f'\n {{C}}[?] {{W}} Executing: {{B}}{safe_cmd_str}{{W}}')

[Copilot]

Sanitization is applied in _format_message(), but exception details and tracebacks are written to the log file separately (_write_to_file(f" {exc_details}"), raw traceback writes) and therefore can still contain API keys / MACs in clear text (e.g., if an exception embeds a command string). Consider running _sanitize_message() over exc_details and traceback lines too, or routing all file writes through a single sanitizing path.