Still some confusion out there as to what conditions need to exist for the latest DNS cache poisoning vulnerability. Many people are thinking that once they patch their DNS servers that the risk has been mitigated. However I am finding there are quite a few people that are not aware of the PAT/HideNAT component to this vulnerability. Basically if you have a patched DNS server that is using PAT/HideNAT, you are still vulnerable to CVE-2008-1447 and VU#800113. This is because PAT/HideNAT does not “scramble” the source port. If your security team, sysadmins and networking groups are not all communicating, you might have overlooked this piece. I created a quick flowchart for Check Point users that can give some ideas on how to approach all of this.

Check Point customers are protected from the different combinations of patched DNS servers, unpatched DNS servers, static NAT and PAT/HideNAT, etc. if they simply check a radio button in SmartDefense.

Also, If you are using SmartDefense you can track potential attacks by enabling DNS>Cache Poisoning>Mismatched Replies. This will alert you once a threshold is hit: very handy. Depending on how busy your environment is, you may have to adjust the settings (although I have been hearing that this is for the most part working “out of the box”).

Is your security vendor vulnerable?

Kind of concerning when looking at the vendor list above and seeing “security” companies fail to participate in a serious security event of this magnitude; especially considering they had over a month’s notice to produce some type of protection let alone a communique. If your CIO asks, just tell them that Check Point had something in place over a 1000 days ago.

*Update: Scott P. from Watchguard contacted me to let me know that although for some reason they do not appear on the CERT Vendor list (as of this writing), they have been educating their customers about Watchguard’s workaround on this latest issue via their LiveSecurity alert service and Podcast. The Watchguard Blog contains more information for their customers as well. Thanks Scott!

Mitigating CVE-2008-1447…DNS Cache Poisoning Pt.2

3 thoughts on “Mitigating CVE-2008-1447…DNS Cache Poisoning Pt.2

  • July 28, 2008 at 10:08 am
    Permalink

    Cool. Like the flowchart. Yeah the info out there does focus mainly on upgrading the software side. Very little understanding on how PAT affects the port randomization.

  • July 28, 2008 at 1:05 pm
    Permalink

    Hey, I like your blog, but I have to disagree with you on one point. You list WatchGuard as a company that “failed to participate,” but we have communicated on this issue to our customers via LiveSecurity alert. We’ve also covered it in our podcast, Radio Free Security: Firebox Special, we’ve blogged on recursion issues at https://blogs.watchguard.com, and we have another minor update about the issue coming up in our next podcast. We also have a track record of interviewing Dan Kaminsky on past issues, and we’ll be at the Black Hat talk on August 6 as press. Have we participated? We’re all over it!

  • July 31, 2008 at 8:59 am
    Permalink

    Good stuff, I bet most people have overlooked PAT rendering patches useless when behind vulnerable platforms.

Leave a Reply

Your email address will not be published. Required fields are marked *