Windows Filtering Platform: Persistent state under the hood

[Nytro]

Windows Filtering Platform: Persistent state under the hood

ri 04 March 2016 By Damien Aumaitre Alexandre Gazet 

 

Since Windows XP SP2, the Windows firewall is deployed and enabled by default in every Microsoft Windows operating system. The firewall relies on a set of API and services called the Windows Filtering Platform (WFP). Although used by almost every Windows OS, WFP is still one of the relatively unknown beast that lies in the kernel. In this post we will see how the firewall manages its persistent state.

Disclaimer: this post was written a year ago with Alexandre Gazet, a former colleague. After gathering dust for too long we decided to publish it anyway. All experiments were conducted on a Microsoft Windows 8.1 operating system.

Introduction

The registry is full of unknown binary blobs. Not so long ago, we stumbled upon the registry sub-key of the BFE service.

 

 

On this picture we see a bunch of entries with a name that looks like a GUID and some binary data.

 

So what is this BFE thingy? A quick search on Google points us on the right direction: BFE stands for Base Filtering Engine which is a core part of the Windows Filtering Platform (WFP).

Since Windows XP SP2, the Windows firewall is deployed and enabled by default in every Microsoft Windows operating system. The firewall relies on a set of API and services called the Windows Filtering Platform (WFP). Although used by almost every Windows OS, WFP is still one of the relatively unknown beast that lies in the kernel.

The WFP architecture is well explained on the MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366509(v=vs.85).aspx)

 

 

Amongst the points of high interest we can mention two components: the user-mode Base Filtering Engine (BFE locating in bfe.dll) and its kernel-mode counterpart KM Filter Engine (KMFE located in netio.sys).

WFP can be used by third parties to develop advanced filtering or routing solution (implementing a VPN solution comes to mind). However, this is also the core of the well known Windows firewall which comes by default with a set of pre-configured rules:

 

 

For now let's just say that a filter is a rule that governs classification. It defines a set of conditions, when met, triggers an action (ie: a callout). A filter operates at a certain level: e.g.: FWPM_LAYER_OUTBOUND_TRANSPORT_V4_DISCARD. Rules are grouped into providers that define "logical features" (for example: Microsoft Windows WFP Built-in TCP Templates provider or Windows Firewall IPsec Provider).

Our objective is to discover how the OS interacts with the WFP and how the configuration is persistently stored in the binary format. With this premise in mind, we'll start to examine the WFP objects' lifetime.

A quick look on the documentation tells us that WFP objects can have one of four possible lifetimes:

• Dynamic: An object is dynamic only if it is added using a dynamic session handle. Dynamic objects live until they are deleted or the owning session terminates.
• Static: Objects are static by default. Static objects live until they are deleted, BFE stops, or the system is shutdown.
• Persistent: Persistent objects are created by passing the appropriate FWPM_*_FLAG_PERSISTENT flag to an Fwpm*Add0 function. Persistent objects live until they are deleted.
• Built-in: Built-in objects are predefined by BFE and cannot be added or deleted. They live forever.

Kernel-mode Filters can be marked as boot-time filters by passing the appropriate flag to FwpmFilterAdd0 function. Boot-time filters are added to the system when the TCP/IP driver starts, and removed when BFE finishes initialization.

So how are these persistent objects managed?

It's time to do a bit of reversing.

 

 

Articol complet: http://blog.quarkslab.com/windows-filtering-platform-persistent-state-under-the-hood.html