This last weekend I took a trip up to Montreal for REcon. If you’re unfamiliar with REcon, it’s a small security conference focused on topics most interesting to reverse engineers. As such, the talks are more technical than you will find at other more mainstream conferences like BlackHat or DEFCON, and generally require a certain level of expertise as a baseline. If you don’t understand assembly language, you’ll probably not get much out of at least half of the lectures.
Archive for the ‘infrastructure security’ Category
First let me say that this article is not meant to diminish the work that Alexander Sotirov et. all have been doing for the past 6 months. It’s good work, has brought about some awesome results, and has demonstrated what was once a theoretical attack on PKI certificates based on MD5 hash collisions. What I’m amazed at is that it had the impact that it actually did.
A number of years ago, Microsoft led the charge by moving away from a dynamic patch release schedule to a monthly patch release schedule, essentially creating an imposed monthly patch cycle for their customers. Since then, many other vendors have followed suit. There are opinions and arguments supporting both a release schedule philosophy as well as a release upon completion philosophy, and today I’m going to outline where I stand on the issue.
If someone is selling you a network penetration test, and then running a vulnerability scanner and handing you a report, you’re not getting what you paid for, period.
DNSSEC, which I mentioned in my previous post about mitigation for Kaminsky’s recent DNS cache poisoning flaw, are the SECurity extensions for the Domain Name System (DNS). It essentially adds cryptography to DNS, allowing authoritative nameservers to cryptographically sign their zones and resource records, which in turn allows caching/recursive nameservers to verify them. This prevents attacks against the recent cache poisoning flaw by allowing the nameserver under attack to verify that a record it receives is valid by checking the cryptographic signature against the zone’s public key. Theoretically, an attacker would not be able to forge this signature unless the zone’s keys have been compromised.
I’ve spent a bit of time over the past few days researching DNSSEC, as it’s been standardized for nearly a decade now but there hasn’t been much adoption. It’s most likely The Best™ solution for the recent vulnerability, but I’ve heard time and again that it’s too complicated and has too many controversial issues surrounding it which is why many admins haven’t adopted it into their infrastructure and still don’t plan to.
During this research, I’ve configured all of my nameservers to use DNSSEC, both authoritative and caching/recursive. While it is a bit of a pain on the authoritative side having to deal with signature expiration, key rotation, proving your identity and ownership of the zone to a domain lookaside verification (DLV) registry and providing your DLV records, etc., configuration for caching/recursive nameservers was relatively straight-forward and simple. While this will obviously only protect you from accepting spoofed, poisoned cache entries for records within zones using DNSSEC, why would you not want to at least verify signatures for those zones that do provide them?
Obviously the first thing everyone should be doing is to apply the patches that the major vendors rolled out, and do it quickly. It is no longer the time for debate in regard to whether or not you really do need to patch… the answer to that question is quite clear; Yes. Yes you do. Stop reading this, go to your vendor right now, and get the patches. Then apply them. This will still be here when you get back…
Unfortunately, the existing patch doesn’t really fix the problem, it just makes it much harder to attack, which is a good thing. If you still aren’t patched, you obviously didn’t follow my instructions in the first paragraph, so I’ll reiterate: Stop reading this, go to your vendor right now, and get the patches. Then apply them.
The patches that most major vendors rolled out when this vulnerability was announced, albeit with no technical details, primarily revolves around randomizing the source port that the nameserver makes it’s queries from. Without this randomization, the only other piece of random information in the DNS packet is the transaction ID, which DNS servers use to correlate queries and replies, and also helps prevent reply-spoofing attacks by requiring that the attacker correctly guess this value. Given the randomized hostname exploitation technique used in this attack, the attacker can force the nameserver to do as many queries as they like, which provides a birthday attack scenario for guessing the transaction ID value and succeeding in spoofing the reply. The search space of the transaction ID is 16 bits, which provides possible values of 0-65535 within which the attacker has to guess correctly. Given as many attempts as the attacker likes, this can take anywhere from a few seconds to a couple of minutes. By adding the source port randomization to the picture, this adds around another 16 bits to the equation (minus source ports already used, privileged source port range, etc.), making the time it takes to correctly guess much longer, but still not impossible.