Combat DNS Hijacking
Dark Reading reported this morning that the ufc.com, coach.com and coachfactory.com domains were hijacked using DNS attacks earlier this week. The attack was performed by hacking the DNS servers authoritative for these zones and re-pointing web addresses to the attacker's site. Anyone attempting to access UFC's or Coach's websites was unwittingly directed to the imposter's site. Apparently these domains were targeted due to their organizations' support of SOPA/PIPA anti-piracy bills. The attack was detected by a sudden large influx of web traffic at the attacker's hosting provider. Administrators monitoring the attacked domains' web resources would have noticed a corresponding drop in traffic, which is one way to detect such an attack.
Had these zones been signed via DNSSEC, perhaps this attack impact would have been minimized. This would have been the case if a) the attacker was unable to "re-sign" each zone after modifying it, which would have depended on the depth of the hack to initiate zone signing or not and b) the resolvers performed DNSSEC validation. While it's debatable that an attacker having file access to a zone file also would have had access to run "dnssec-signzone" (or that auto-signing was configured), it's probably more likely that the resolver would not have been configured to validate DNSSEC signatures in the first place and thereby detect that the signature did not match the returned resolution data.
If you aren't already aware, you should know that configuring DNSSEC validation is relatively simple with BIND 9.8 and above. Simply configure your recursive servers with the DNS root public key within a "managed-keys" statement, and set dnssec-enable and dnssec-vailidation to "yes" within the BIND configuration file. BIND supports additional DNSSEC options to configure recursive servers but the beauty of this is that once setup, it runs on "auto-pilot." The managed-keys statement instructs BIND to detect updates to the root zone key (as defined in RFC 5011) and to automatically update its "trust anchor" accordingly.
Of course DNSSEC validation is only useful if queried zones (and parent zones up to the root) are signed. But BIND releases are also progressing towards making the authoritative side of equation easier as well (recursive servers ask, authoritative servers answer). BIND 9.9 promises some improvements in this area with in-line signing but does not yet automate key re-generation for automated rollovers. If you need an automated authoritative solution, check out BT Diamond IP's Sapphire Sx20 appliance, which enables creation of key, signature and rollover policies once, then it runs on "auto-pilot." DNSSEC cryptography technology is a bit foreign to DNS administrators; an automated solution can help provide the security required but minimize associated administrative support.
Had these zones been signed via DNSSEC, perhaps this attack impact would have been minimized. This would have been the case if a) the attacker was unable to "re-sign" each zone after modifying it, which would have depended on the depth of the hack to initiate zone signing or not and b) the resolvers performed DNSSEC validation. While it's debatable that an attacker having file access to a zone file also would have had access to run "dnssec-signzone" (or that auto-signing was configured), it's probably more likely that the resolver would not have been configured to validate DNSSEC signatures in the first place and thereby detect that the signature did not match the returned resolution data.
If you aren't already aware, you should know that configuring DNSSEC validation is relatively simple with BIND 9.8 and above. Simply configure your recursive servers with the DNS root public key within a "managed-keys" statement, and set dnssec-enable and dnssec-vailidation to "yes" within the BIND configuration file. BIND supports additional DNSSEC options to configure recursive servers but the beauty of this is that once setup, it runs on "auto-pilot." The managed-keys statement instructs BIND to detect updates to the root zone key (as defined in RFC 5011) and to automatically update its "trust anchor" accordingly.
Of course DNSSEC validation is only useful if queried zones (and parent zones up to the root) are signed. But BIND releases are also progressing towards making the authoritative side of equation easier as well (recursive servers ask, authoritative servers answer). BIND 9.9 promises some improvements in this area with in-line signing but does not yet automate key re-generation for automated rollovers. If you need an automated authoritative solution, check out BT Diamond IP's Sapphire Sx20 appliance, which enables creation of key, signature and rollover policies once, then it runs on "auto-pilot." DNSSEC cryptography technology is a bit foreign to DNS administrators; an automated solution can help provide the security required but minimize associated administrative support.
Comments
Post a Comment