Dear Tails Development Team,
I hope this message finds you well. I am writing to bring to your attention an
important consideration regarding the MAC spoofing feature in Tails. The
existing MAC spoofing feature in Tails OS is a step in the right direction, as
it checks for NIC existence and retries if necessary, treating the NIC as a
unique identifier for WiFi cards. While the current implementation effectively
changes the NIC part of the MAC address, it leaves the OUI (Organizationally
Unique Identifier) exposed, which can potentially compromise user anonymity.
The OUI part of the MAC address identifies the device manufacturer, and if left
unchanged, it can be used for device fingerprinting. This is particularly
concerning for users such as journalists and whistleblowers who rely on Tails
for privacy. The current setup inadvertently makes these users unique, as the
OUI remains constant, even when the NIC is spoofed.
As noted in the Tails documentation on MAC address limitations, tools like
Macchiato may rely on outdated OUI lists, potentially increasing uniqueness.
Ironically, the current Tails implementation already risks this by maintaining
a consistent OUI, making it trivial for entities like ISPs to track devices
across sessions. If you are using tails at home your ISP or anyone monitoring
your network that its the same device on the network since the OUI is always
the same.
This especially true for users on dedicated devices such as journalists or
whistleblowers. I'm sure many journalists, whistleblowers, or privacy folks may
strictly have a separate computer or throwaway dedicated device that they only
use with Tails. Well, those devices most likely have a common or unique OUI
especially if they are older devices. Many such users might also attempt
mitigations, like purchasing external ethernet or WiFi adapters, but this often
deanons them through traceable purchases since most are going to purchase these
through sites like Amazon which require credit cards.
Mind you the best case of action would to be spoofing both OUI and NIC in the
mac address design. Most notably android and Iphone already support this and do
this though their design is flawed since it is only per network and not per
connection to a network. Up until recently it was discovered that iOS prior to
version 17.1, leaked real MAC on port 5353.
* Proposed Solution *
To enhance anonymity, I propose spoofing both the OUI and NIC parts of the MAC
address. While systems like Android and iOS have similar implementations, they
are limited to per-network changes. However, the approach can be adapted and
improved for Tails.
* DHCP Considerations *
When implementing full MAC spoofing, it's crucial to handle DHCP leasing
correctly. If a spoofed MAC is already leased, the device may fail to obtain an
IP address or fail to connect to the internet. To mitigate this, I suggest
integrating an ARP check using `arping` to ensure the new MAC is not already in
use before connecting.
If the DHCP server detects that the MAC address is already associated with an
active lease, it may refuse to assign a new IP address to your system. Send a
DHCP NAK (negative acknowledgment) to your system, indicating that it cannot
assign an IP address. If does the allow you to connect with an already leased
MAC you most likely will not be able to connect to the internet. In
environments with MAC spoofing detection, such as those using Dynamic ARP
Inspection (DAI), the spoofed ARP requests could be ignored or flagged,
potentially leading to no responses. However, these advanced security features
are less common on public WiFi networks with captive portals, where basic DHCP
setups predominate, reducing the likelihood of such detections.
To my knowledge NetworkManager or Linux in general will not explicitly retry
with a new spoofed mac if there is already is a device leased with the same MAC
address already on a network.
Currently it looks like `iputils-arping` is not installed on tails but could
possibly be incorporated into the existing design?
* Example Code Implementation *
The following is example code modifications that could can be incorporated to
include the ARP check:
**Modify `spoof_mac` Function:**
```bash
spoof_mac() {
local max_retries=3
local attempt=1
local msg
local new_mac
local gateway_ip
gateway_ip=$(ip route show | grep default | awk '{print $3}')
set +e
while [ "${attempt}" -le "${max_retries}" ]; do
msg="$(macchanger -e "${1}" 2>&1)"
ret="${?}"
set -e
if [ "${ret}" != 0 ]; then
log "macchanger failed for NIC ${1}, returned ${ret} and said:
${msg}"
unset NEW_MAC
break
fi
NEW_MAC="$(get_current_mac_of_nic "${1}")"
if [ "${OLD_MAC}" != "${NEW_MAC}" ]; then
log "Spoofed MAC for NIC ${1} is: ${NEW_MAC}"
log "Checking if MAC ${NEW_MAC} is already leased..."
if arping -c 1 -I "${1}" -s "${NEW_MAC}" "${gateway_ip}" &>
/dev/null; then
log "MAC ${NEW_MAC} is already leased or in use on NIC ${1}."
attempt=$((attempt + 1))
continue
else
log "No conflict detected for MAC ${NEW_MAC}."
return 0
fi
fi
attempt=$((attempt + 1))
done
set +e
return 1
}
```
**Add Error Handling and Logging:**
```bash
for i in 1 2 3; do
if ! spoof_mac "${NIC}"; then
unset NEW_MAC
break
fi
NEW_MAC="$(get_current_mac_of_nic "${NIC}")"
if [ "${OLD_MAC}" != "${NEW_MAC}" ]; then
log "Checking if MAC ${NEW_MAC} is already leased..."
if arping -c 1 -I "${NIC}" -s "${NEW_MAC}" "${gateway_ip}" &>
/dev/null; then
log "MAC ${NEW_MAC} is already leased, retrying spoofing..."
continue
fi
break
fi
done
```
Enhancing MAC spoofing to include both OUI and NIC, along with ARP checks,
would significantly improve user anonymity in Tails and avoid failure if a
leased device on a network already has the same MAC as the Spoofed one. If
there is not way to anonymously check DHCP leases with leaking the real MAC
address through ARP ping/requests then forget this but rather focus on new mac
spoofing design that spoofs full mac address.
Thank you for your dedication to Tails and user privacy.
Namaste,
Joe
_______________________________________________
Tails-dev mailing list
[email protected]
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
