Windows Firewall Interface Issue in Handling Exceptions

Microsoft has just released an advisory disclosing how a flaw in the Windows Firewall graphical user interface may hide an exception from showing up in the Exceptions list. This unexpected behavior is be triggered by a malformed registry entry.

Windows Firewall is configured to block incoming network connections by default. However, a system administrator can allow incoming network connections by creating an exception in the Windows Firewall configuration. This exception will then allow network services running in the system access to the network.

Note that this issue only affects the Windows Firewall GUI. The command-line “netsh” tool is not affected by this issue.

Microsoft stresses that “this is not a vulnerability.” It cannot be used to compromise a system. Furthermore, administrative privileges are required in order to edit the offending registry entries. Refer to these links for the MS security bulletins.

• Windows Firewall Exception May Not Display in the User Interface
  
  
• An exception may not show up in the Windows Firewall graphical user interface if you create the exception by modifying the registry

What can a malware do?

1. Get installed in the system, hoping that the user who executed the malware has administrative privileges.
   
   
   
2. Edit the affected registry entries to put a certain port number in the exceptions list. The edited registry entry should be able to take advantage of this flaw so that the port number is hidden from the Exceptions list in the Firewall GUI.
   
3. Open the port just added in the Exceptions list.

To get unrestricted network access, the malware no longer needs to terminate the Windows Firewall service (just like what most bots do). All it needs to do is to add the port number it is going to use in the Exceptions list, and hide it.
Just like what Microsoft said, this is not a vulnerability, per se. But it could be leveraged to hide a malware’s presence in the system. But if a user is able to run a malware in his/her system, and is logged-in with administrative privileges, then this issue is the least of your concern.

Some testing

Ports that are in the exceptions list are placed in this registry key (will wrap)

HKLMSystemCurrentControlSetServicesSharedAccessParameteres
FirewallPolicyDomainProfileGloballyOpenPortsList

Since this is located in the HKEY_LOCAL_MACHINE registry hive, only an administrator has the power to edit the entries in this key.

For my PC, for example, I see the following registry entries in the said key.





It means that ports 139 (TCP), 445 (TCP), 137 (UDP), and 138 (UDP) are allowed through the firewall. That’s okay, ’cause I need those ports for file and print sharing.

It is apparent that the format of the registry entries in the exceptions list is the following.




The flaw is in Exception Name. If you’d leave Exception Name blank, then that particular exception is hidden from the Windows Firewall GUI.

As a little test, I created these two registry entries




As is shown in this snapshot.





My Windows Firewall GUI shows this





At this point, you can clearly see that one of the exceptions we entered (port 23456) is not visible. But are we really sure that it is in the exceptions list? However, we know for a fact that the “netsh” command-line tool is not affected. So let’s use it.



As can be clearly seen from the output of the netsh tool, TCP port 23456 is indeed in the Exceptions list, but is not visible in the Windows Firewall GUI.

As an additional test, I set up listening ports on 12345 and 23456, and tried connecting from a remote machine. I was able to connect in both occations.