Piggybacking common web beacons to track users maliciously
In this video I demonstrate this attack in a controlled environment.
How it Works
A user connects to a malicious network. The network’s DNS server is controlled by the attacker. Every time the user makes a DNS request, the DNS server responds with the IP of an HTTP proxy server controlled by the attacker. The proxy server allows the attacker to modify the responses made by the user.
When the user requests an HTML page, the proxy detects this based on the response’s
<img> tags. This forces the browser to make additional HTTP requests for each of these files.
<img> is used rather than
<script> so that the code does not run immediately but is cached to run later.
I have identified a number of popular websites for which this attack has proven to be effective at skimming customer credit-card information. Several vendors have been contacted and are working on fixes. Strict application of the Payment Card Industry Data Security Standard will nullify this attack. In particular, using HTTPS to transfer the credit card information is not sufficient; HTTPS must appear in the URL displayed by the browser (as per PCI-DSS 4.1.e)
While the widespread use of CDNs and tracking beacons makes this attack highly pervasive, in principle the attack can be used to target any site that is loaded over HTTP. I do not suggest indiscriminately serving all content in HTTPS because of this threat, but this type of attack should be taken into consideration when deciding between HTTP and HTTPS.
Although the attack described involves a custom DNS server, DNS control is not required for this attack to work. The request rewriting could be done by intercepting the individual packets. DNS is merely a convenient way to demonstrate it since even the most basic routers allow DNS server configuration without installing custom firmware.
- Do not use untrusted WiFi networks
- Clear cache after disconnecting from an untrusted network
- Do not enter sensitive information over a site that did not load over HTTPS, even if it claims that data will be sent securely and has a GIF of a padlock
- For all pages that display or touch sensitive data, make sure HTTPS is used for every page element (including the HTML page itself)