n0mad1k/bigbrother
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Append 4 operator Q&A sections with detailed exploitation scenarios and OPSEC analysis

Browse Source
This commit is contained in:
Cobra
2026-04-09 08:25:52 -04:00
parent d4354074c8
commit 87e7587136
1 changed files with 193 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SECURITY_REVIEW.md
+193
View File
@@ -1317,3 +1317,196 @@ For operational deployment, prioritize FIX-NOW (unblock tool), then FIX-OPSEC (c
---
**End of Report**
---
## Operator Questions & Direct Answers
### Q1: Does 60-second interface-flap suppression create exploitable blind spot for physical device removal?
**Answer: YES — Severe blind spot. Exploitation window: 60 seconds minimum, up to 15 minutes with debounce.**
**Attack Scenario:**
1. Attacker triggers interface flap via mdk4 WiFi deauth burst or brief cable disconnect (3+ simultaneous ARP departures in 3-second window)
2. Flap detection engages, suppresses ALL departures for 60 seconds
3. During 60-second window, attacker physically removes target device from network
4. Net-alerter logs nothing; operator remains blind to removal
5. At 60 seconds, suppression lifts — but device stays offline beyond 15-minute debounce trigger (device already gone)
6. Result: Silent removal undetectable in logs
**Preconditions:**
- Attacker has network access to trigger flap (cable access, WiFi proximity for deauth)
- Attacker can time physical removal to 60-second suppression window (OR knows debounce is 15 min and waits after flap)
**Recommended Fixes:**
1. FIX-NOW: Require operator confirm flap before suppressing (human-in-loop)
2. FIX-OPSEC: Randomize suppression window per incident (30-120 seconds); avoid fixed 60-second constant
3. Alternative: Use exponential backoff (10s, then 30s, then 60s) instead of immediate full suppression
**Exploit Time Estimate:** < 2 minutes with network access
---
### Q2: Does permanently excluding gateway from departure alerts create rogue AP/gateway compromise blind spot?
**Answer: YES — Critical blind spot. Gateway compromise undetectable; rogue AP invisible.**
**Attack Scenario:**
1. Attacker compromises home gateway or sets up rogue AP with spoofed gateway MAC
2. Devices connect to rogue, net-alerter sees DHCP with IP=10.0.0.0
3. Hardcoded exclusion prevents alert; operator stays blind
4. Attacker controls all traffic on network
**Rogue AP Variant:**
- Rogue AP services DHCP with gateway IP 10.0.0.0, net-alerter excludes it per hardcoded rule
- Attacker intercepts traffic from devices joining rogue AP
**Recommended Fixes:**
1. FIX-NOW: Remove hardcoded gateway exclusion; require operator whitelist
2. FIX-DETECTION: Alert on gateway IP changes (MITM detection)
3. FIX-OPSEC: Use external config for infrastructure IP whitelist, not hardcoded
4. Alternative: Enforce MAC-based gateway identification; alert if MAC changes
**Exploit Time Estimate:** < 10 minutes (WiFi MITM setup)
---
### Q3: Is 15-minute departure debounce too aggressive?
**Answer: YES — Dangerous in offensive context. Creates 15-minute blind spot for device swaps + persistence evasion.**
**Operational Context:**
The 15-minute debounce delay is designed to suppress noisy re-arrivals when devices briefly disconnect (WiFi roaming, DHCP renewal glitches). But in the attacker-controlled network (implied by net-alerter deployment), this creates severe blind spots.
**Attack Scenario 1: Device Swap / Replacement**
1. Target device offline (attacker removes it)
2. Within 15-minute debounce window, attacker introduces new device with same/spoofed MAC
3. Device re-joins; net-alerter suppresses departure alert + arrival (re-arrival window overlap)
4. Operator never detects swap
**Attack Scenario 2: Persistence Through Device Churn**
1. Attacker plants implant on network device
2. Device naturally goes offline (reboot, maintenance)
3. Returns within 15 minutes; net-alerter suppresses both departure/arrival
4. Operator blind to implant; repeat weekly as normal network churn
**Attack Scenario 3: Evasion During Flap + Debounce Overlap**
1. Attacker triggers flap (60-second suppression)
2. Real devices offline > 60 seconds; rejoin after suppression expires
3. But their departures still within 15-minute debounce window
4. Re-arrival suppressions overlap; attacker inserts new device during high-churn
5. Operator blind due to overlapping suppression windows (20-minute total blind spot)
**Preconditions:**
- Attacker can trigger device offline state (cable, WiFi, physical)
- Attacker can control MAC/IP via spoofing or device swap
- Attack operates within 15-min + 5-min suppression overlap (20-minute window)
**Recommended Fixes:**
1. FIX-NOW: Reduce debounce to 3-5 minutes (tolerate brief roaming/DHCP churn, block device swaps)
2. FIX-DETECTION: Alert on MAC-IP mismatch (re-appears with different MAC = potentially new device)
3. FIX-OPSEC: Make debounce randomized (3-8 min) to prevent pattern matching
4. FIX-QUALITY: Distinguish "expected" churn (known device re-roaming) vs "unexpected" (new device)
**Exploit Time Estimate:** 5-10 minutes (device swap + insertion)
**Severity Assessment:**
- Defensive deployment (home network intrusion detection): 15 min reasonable
- Offensive deployment (attacker monitoring): 15 min catastrophic — enables silent persistence
---
### Q4: What are OPSEC risks in flap detection implementation?
**Answer: CRITICAL — Flap detection adds 5+ new fingerprints, reveals tool intent, creates forensic smoking gun.**
**8 OPSEC Risks:**
**Risk 1: Distinctive Log Message '[Interface flap detected]' is Tool Fingerprint**
- Journalctl shows: `Interface flap detected — suppressing departures for 60s`
- Blue team recognizes immediately as net-alerter
- Forensic indicator post-compromise
- OPSEC fix: Randomize message phrasing (30+ variations)
**Risk 2: Specific Flap Threshold (≥3 departures in 3 seconds) is Distinctive**
- Thresholds (3, 3 seconds) are arbitrary design choices
- Forensic analysts reverse-engineer from traffic patterns
- Example: "Suppression triggered at exactly 3 simultaneous departures in 3-second window — net-alerter"
- OPSEC fix: Randomize thresholds per deployment (2-5 departures, 2-5 second windows)
**Risk 3: Fixed 60-Second Suppression Duration Enables Pattern Matching**
- Blue team pattern-matches: "60 seconds of zero alerts after flap = net-alerter signature"
- Forensic timeline shows precise 60-second gaps after multi-departure clusters
- OPSEC fix: Randomize per-incident (30-120 seconds)
**Risk 4: Global Variable NameError (_flap_lock) Reveals Code Source**
- Proposed code has syntax error: `_flap_lock` not initialized (IR-005)
- If code discovered on disk, error is forensic evidence
- Signals amateurish, under-development operation
- OPSEC fix: Fix NameError immediately; use production-ready code only
**Risk 5: Thread Name 'flap-detector' Adds Process-Level Fingerprint**
- `/proc/[net_alerter_pid]/status` reveals thread list
- Thread name 'flap-detector' is distinctive and tool-identifying
- OPSEC fix: Use generic name ('worker', 'service') or randomize per deployment
**Risk 6: Flap Detection Reveals Tool Intent to Network Defender**
- Flap suppression = operator aware of network-level evasion
- Only sophisticated threat actors implement this (most tools don't)
- Blue team infers: "Not home-user device; targeted malware with anti-detection"
- Forensic indicator: "Flap suppression = APT-level sophistication; narrows attacker profile"
- OPSEC fix: Don't deploy unless network has documented, recurring flaps
**Risk 7: Flap Configuration Exposed in .env or Deploy Scripts**
- If stored: `FLAP_THRESHOLD=3, FLAP_WINDOW_SEC=3, FLAP_SUPPRESSION_SEC=60`
- Config file discoverable post-compromise; directly reveals tuning
- OPSEC fix: Hardcode conservative values; don't expose in config files
**Risk 8: Flap Detection Implies Specific Network Environment Knowledge**
- Presence suggests operator has prior knowledge of target network behavior
- If network is stable + flap detection enabled anyway = reveals intent to suppress alerts regardless
- Forensic indicator: "Flap logic present despite zero natural flaps — attacker foreknowledge"
- OPSEC fix: Deploy only if evidence of actual network flaps exists
**Recommended OPSEC Mitigations (Priority Order):**
1. **FIX-NOW: Fix NameError (IR-005) — Don't deploy broken code**
- Broken code = forensic smoking gun
2. **FIX-OPSEC: Randomize all flap detection parameters**
- Threshold: 2-5 departures
- Window: 1-5 seconds
- Suppression: 30-120 seconds
- Deploy-time config in encrypted .env
3. **FIX-OPSEC: Obfuscate log messages**
- No hardcoded '[Interface flap detected]' strings
- Generic message: "Suppressing alerts"
- Randomize phrasing across deployments
4. **FIX-OPSEC: Use generic thread names**
- Replace 'flap-detector' with 'worker' or randomized name
5. **FIX-OPSEC: Disable flap detection by default**
- Requires operator opt-in per deployment
- Reduces fingerprint surface for networks without flaps
6. **RECONSIDER: Does flap detection add more risk than benefit?**
- 20-minute blind spot (60s flap + 15min debounce overlap) is severe
- Flap detection adds 5+ new fingerprints
- Unless network has documented, recurring flaps, cost > benefit
- Alternative: Keep debounce/re-arrival suppression; remove flap detection entirely
**Forensic Timeline (Post-Compromise Analysis):**
```
1. Systemd service file → "net_alerter" name revealed
2. /opt/net_alerter/net_alerter.py → Source code acquired
3. Reverse-engineer → Finds flap logic with hardcoded numbers (3, 3sec, 60sec)
4. Journalctl logs → "[Interface flap detected]" messages + timing
5. DHCP correlation → Confirms flap detection on specific packet patterns
6. Conclusion: "Sophisticated net-alerter with deliberate flap suppression"
7. Attribution: Narrows threat actor to small group using this specific tool
```
---