Q&A: Behind the Windows Firewall Exploit
News of a Windows vulnerability is hardly a rare event, but word of a zero-day that knocks out the Windows Firewall spread quickly this week. The irony is certainly enough to grab attention, but it is the potential impact on Windows users that is causing alarm.
Tyler Reguly, Security Research Engineer for nCircle Network Security, has been in the thick of things, evaluating both the vulnerability and the code that quickly sprang up to exploit it. Here he shares his thoughts on the vulnerability, including the dangers Windows users face and the blog drama that ensued when a workaround was offered to the masses.
Q: Tell us about the Windows ICS vulnerability. What versions of Windows are affected?
The Windows ICS vulnerability is pretty straightforward. When processing a malformed DNS query, a DoS will occur which will disable the Windows Firewall/Internet Connection Sharing service. This will render the Windows Firewall ineffective. Current testing, which lines up with Microsofts statements, tells us that this only affects Windows XP.
Q: How would an attacker exploit this flaw?
The attacker would have to be on the LAN (the network created behind the target computer which shares the internet connection) to exploit this vulnerability. They would simply have to send a specific malformed DNS packet to the listening pseudo-DNS server. Windows processing of this malformed packet would take it from there.
Q: What are the dangers to users?
The obvious danger is the loss of the Windows Firewall. If you're depending on Windows Firewall to provide your last line of defense and suddenly it's gone, you could find yourself in a lot of trouble.
I should note that this only affects users which have enabled ICS. This would primarily target home users and possibly small businesses that are not implementing a NAT routing solution but are relying on the Windows PC to perform their routing.
Q: There is a zero day in the wild, have you picked it apart?
I performed a good deal of testing with the exploit on Sunday. It is very basic in it's nature; there's nothing to reverse engineer there. Essentially anyone could grab this code and run with it. Being that the proof of concept is written in Python it can be executed from any operating system (Windows, Linux or OS X). Anyone with a working knowledge of Python can easily apply this exploit. To a greater extent, anybody with a basic understanding of DNS could easily turn around and write this exploit in any language, which could then be easily included in malware. It could be a great local exploit to disable the firewall on hosts where the user is running without Administrative permissions.
The targeted instruction is mov dl,byte ptr [eax] which can't handle the null data in the packets and the DoS follows.
Q: What organizations have you been in contact with regarding the discovery?
This isn't actually my discovery, it was posted to milw0rm by h07 and I started my research shortly after it was posted. Soon after my testing began, I contacted SANS ISC as well as the Microsoft Security Research Center. I received positive feedback from ISC and Microsoft, and I spent several hours working with an ISC Handler over the weekend. I also received a follow up email from Microsoft stating that they were looking into the issue.
Q: Describe the controversy surrounding your workaround advice.
A tempest in a teacup. The workaround instructions are well understood by system administrators and are clearly documented on Microsoft's website. The Internet Connection Sharing service (child) is disabled by default on XP SP2; Windows Firewall/Internet Connection Sharing (parent) is enabled by default.
My recommendation was to follow Microsoft documented processes to disable the ICS child, thus leaving the firewall intact. George [Ou] at ZDNet interpreted my workaround as instructions to disable the parent. Our Director of IT has posted clear instructions on how to implement this workaround on our blog. We have performed a lot of testing and ISC has backed us up on our results. Disabling the ICS child while leaving the Windows Firewall (child) and the parent enabled offer protection from this vulnerability. It really is as simple as that.
Article courtesy of Enterprise IT Planet