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?
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.
@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.”
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.
I not implement and instead try obfuscate by create /etc/NetworkManager/conf.d/33-obfuscate-mac.conf
[device]
wifi.scan-rand-mac-address=yes
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 ;)
# https://arxiv.org/pdf/1703.02874v1.pdf pg.8 section 5.1.2
[connection]
connection.stable-id=${CONNECTION}/${BOOT}
# Stable identifiers are exclusive per connection and persist until reboot
ethernet.cloned-mac-address=stable
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.cloned-mac-address=stable
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
ipv6.ip6-privacy=2
# Enable IPv6 Privacy Extensions preferring temporary addresses
ipv4.dhcp-client-id=stable
# DHCP client identifier stable, per connection, until reboot
ipv6.dhcp-duid=stable-uuid
# DHCPv6 Unique Identifier generated per connection
Might be wise to test with tcpdump/wireshark what actually happens. Seems work here but ymmv
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
