Preventing Active WiFi Probing

This is a follow up to this great post OPSEC considerations when using wifi

I am trying to confirm that using a disposable sys-net will avoid this active WiFi probing from happening.

Being a disposable I don’t need to worry about NetworkManager storing SSIDs to perform the active probing, but my biggest concern is the possibility that the WiFi chip/physical device would ever cache SSIDs on the hardware itself. I can’t find much information on this, is it something that is possible or do WiFi chips have no persistent memory for this purpose?

Thank you.


If the device itself would store this data and do active probing you could theoretically see that by capturing the traffic and looking for the SSIDs.
I guess each device has some kind of writable memory for the MAC address on board. Some do have a small external EEPROM for that which also stores some other information. I could not find a network name in the dump I have but in theory it would be possible to store the name/mac address of the AP in there.

confused response

Cannot confirm :frowning:
Depend what you mean “active WiFi probing”?

In Disabling default sys-net traffic necessary when moving networks? - #8 by Patrick - Qubes-Whonix - Whonix Forum

@uesqoho998 interesting question. i know no solution (other no WiFi)

I learn from peripheral firmware section Heads Threat model - Heads - Wiki
“Cleartext data should never be presented to the NIC, so it shouldn’t be able to do much exfiltration. Custom firmware like Thundergate Thundergate - an open source toolkit for PCI bus exploration or NICssh Project Maux II (PDF) - Triulzi, 2008 allow potentially malicious code to run on the NIC, so again it is important to configure devices like the IOMMU to prevent random read/writes to system memory from occurring. Where possible the write protect pins on the devices should be hard wired to prevent software updates, although physical attackers might still be able rewrite the firmware.”

And read below today in other thread.

Wonder what others in community suggest

This is a different issue @Confused. Active probing is when a WiFi device announces its list of previously connected networks to speed up the reconnection process.

Sorry for confusion. @uesqoho998 prior research lead to Protect against fingerprinting via active Wi-Fi networks probing (#6453) · Issues · tails / tails · GitLab
Re: [Tails-dev] active probing vs. AdvGoalTracking [Was: [RFC] Design (and prototype) for MAC spoofing in Tails]
disable_wifi_scan_when_connected.patch - aur.git - AUR Package Repositories

I not implement and instead try obfuscate by create /etc/NetworkManager/conf.d/33-obfuscate-mac.conf

wifi.scan-generate-mac-address-mask=FE:FF:FF:00:00:00 DA:A1:19:00:00:00
# Generate wifi scans MAC addresses with CID DA:A1:19, local-address bit set,
# and randomize the rest. Why DA:A1:19?
# To look like a strange malfunctioning Google device ;)
# pg.8 section 5.1.2

# Stable identifiers are exclusive per connection and persist until reboot

ethernet.generate-mac-address-mask=FE:FF:FF:00:00:00 3C:97:0E:00:00:00
# mask random wired MAC addresses with OUI 3C:97:0E found in old Thinkpads  

wifi.generate-mac-address-mask=FE:FF:FF:00:00:00 8C:70:5A:00:00:00
# mask wifi MAC addresses with Intel OUI found in old Thinkpads' Centrino N

# Enable IPv6 Privacy Extensions preferring temporary addresses

# DHCP client identifier stable, per connection, until reboot
# DHCPv6 Unique Identifier generated per connection

Might be wise to test with tcpdump/wireshark what actually happens. Seems work here but ymmv

Please tell what you do. Thanks

I am not 100% into how that works that deep down the hardware level, however this can be tested manually, als @bored pointed out.

You will need 2 (new, never connected to) networks that you can connect to, another device with wifi and monitor mode capabilities and wireshark oder airodump-ng on that second device.

Start up your disp-sys-network and connect to network 1.

Watch with your other device for the probes.

Restart your disp-sys-network and connect to network 2.

If you still see probes for network 1 some kind of caching is going on.

This may be device depended but i would guess that no such caching occurs. Only way to be sure is trying it out :slight_smile: