Could DNSSEC have protected against DNSChanger malware scam?
According to major media sites, a two-year FBI investigation has culminated in the arrest of six individuals involved in a DNSChanger malware scam. DNSChanger is downloaded under the guise of a video codec in many cases and is installed on an individual's computer. DNSChanger then modifies the recursive server settings from those provided by the individual's ISP to one administered by the attackers. As the individual browses the web entering URLs, the local resolver queries the attacker's DNS servers, which can return IP addresses leading to falsified sites unbeknownst to the individual.
This scam has reportedly led to the infection of over four million computers in over 100 countries and had netted the conspirators over $14 million. The FBI has published a very basic description of the issue and a listing of falsified DNS sever addresses.
So the question arises, could the widespread implementation of DNSSEC have prevented this type of attack? Unfortunately, in this case, no. The attack modified the client (stub) resolver, which inherently trusts its configured recursive server(s) to validate DNSSEC queries on its behalf. The manner in which DNSSEC commonly deployed with validation performed by the recursive server resolver, not the stub resolver, performing DNSSEC validation would not have prevented this. Once the stub resolver issues the query to the attacker's DNS recursive server under this attack, the attacker could have spoofed DNSSEC-validated responses to the client.
If the client stub resolver performed and required DNSSEC validation, and was configured with trusted root keys, it could have detected falsified zone information. Of course, if the DNSChanger was able to modify the resolver's recursive server address settings, it presumably could have modified the trusted key to point to an attacker's public key! So as advertised, DNSSEC helps prevent cache poisoning attacks, but it does not mitigate resolver configuration attacks, which require ongoing vigilance to detect and mitigate as with other malware and trojan horse style attacks.
This scam has reportedly led to the infection of over four million computers in over 100 countries and had netted the conspirators over $14 million. The FBI has published a very basic description of the issue and a listing of falsified DNS sever addresses.
So the question arises, could the widespread implementation of DNSSEC have prevented this type of attack? Unfortunately, in this case, no. The attack modified the client (stub) resolver, which inherently trusts its configured recursive server(s) to validate DNSSEC queries on its behalf. The manner in which DNSSEC commonly deployed with validation performed by the recursive server resolver, not the stub resolver, performing DNSSEC validation would not have prevented this. Once the stub resolver issues the query to the attacker's DNS recursive server under this attack, the attacker could have spoofed DNSSEC-validated responses to the client.
If the client stub resolver performed and required DNSSEC validation, and was configured with trusted root keys, it could have detected falsified zone information. Of course, if the DNSChanger was able to modify the resolver's recursive server address settings, it presumably could have modified the trusted key to point to an attacker's public key! So as advertised, DNSSEC helps prevent cache poisoning attacks, but it does not mitigate resolver configuration attacks, which require ongoing vigilance to detect and mitigate as with other malware and trojan horse style attacks.
Comments
Post a Comment