Pumpernickel (FIDES)

Now that Pumpernickel (FIDES), a FileSystem level driver, has been released commercially, it would be nice to have some discussion on its capability.

I've seen some comments under the "Bouncer" thread but its missing what I'm looking for.

I've been testing during the BETA cycle and things have worked well but just noticed an anomaly which I surely am not familiar with. When the System hosting my FIDES protected folders are offered for sharing across a HomeGroup (with full rights offered the HomeGroup members), any of those Systems are capable of not only copying new files into those folders but also deleting them as well. It seems that the type of Network access offered those Systems does not go through the server's FileSystem... is that true?

I guess I need a bit more understanding in the network access path to understand that FIDES will not help me at all under this scenario. Any help, greatly appreciated.

 

Network requests doesn't seem to trigger the driver. This can be seen with some "Folder Protection"-programs too:

It's not a problem of Fides, but i guess that's the way how sharing of folders/Network access work in Windows.
It's like accessing folders directly (raw access) on a drive. In this case the kernel doesn't "notice" that there is an access to a specific file (=ACL's or kernel drivers can't protect), and files can be accessed.
In the case of a Network Access it's maybe similar.

As Fides doesn't intercept/monitor network requests, it can't protect these folders accordingly.

 

I think Mood may have touched on the issue although I don't believe RAW access is the basis of the "anomaly."

Here's a li'l something from the Devs that may shed some light on the issue...

From the Excubits Developers...

the server does not know of the application on client-side that wants to
access the file system. All the server knows it that e.g. a system service
wants to access a specific directory or file. This system service manages
the communication between your client and the server. I can give you
another example to clear things up:

Assume you have installed Apache Web Server on the Server than the server
executable has the right to access your file system. Now if a client
connects to the server the client accesses content on the server through
the Apache process. If you use e.g. PHP than it is also possible that the
Apache application (PHP) could make changes on the drive of the server,
hence the user is able to do changes. There is no way to block this,
because blocking php or Apache would result in blocking all attempts.

For network drives you need AD rights and permissions. You shall specify tight
rules depending on user groups and the rights you'd like to permit.
Pumpernickel would be too generic here.

Basically, from the description above, the design of FIDES (where it's located in the access chain) cannot attempt to inhibit network access... that's the job of the System Admin through Rights Mgmt and access privs.

 

I would enjoy seeing your config for FIDES, Pete. I always like the community effort when it comes to learning and sharing and I don't believe that too many FIDES configs have been shared recently and if so, they would likely be buried within the Bouncer thread. So it is probably a great idea to have this separate thread here now.

With the rise in ransomware in current times, a tiny yet solid and efficient kernel driver such as FIDES would have the potential to save users data. Even some of these large organizations (or also smaller businesses) would not have to fork over tens of thousands of dollars to these organized criminal groups. Although, as you and Froggie have noted, FIDES would need to be configured on each workstation and as always, application whitelisting to prevent execution is always crucial in a layered setup.

That makes me think. I wonder what it would be like if Florian were to create a pre-made setup with a well design GUI that contained each components of Bouncer, MemProtect, FIDES, MZWriteScanner, etc. That would be an absolute killer setup. Each of those in their own right and proper config can keep a system safe. But each has their upsides and downsides, which is why each driver was developer to compliment eachother's downsides. As many of us know, those downsides are very minimal anyway and would likely only be bypassed in a targeted scenario. Nevertheless, one can always dream.

 

Thanks for the explanation from the developer.

Yes, i don't need a GUI too. Notepad for editing rules is all what is needed

 

In a subtle discussion with Florian, the developer, it sounds like they may make an attempt at extending FIDES to include not only resident System sources but also System Services as well... possibly sometime in 2017, more research is definitely needed. There was no commitment to do so... so a roadmap to do this is not in place.

 

If RawDisk (commercial software) can do this:

Just imagine what ransomware could do...

FIDES has NTFS and Windows OSes security mechanisms covered and in place to protect folders/drives.
Still pending the raw access. Or maybe another sort of driver, dunno.

 

This can already be done
a) Elevated applications can access the disk directly (Raw access)
b) after a special kernel-driver is installed, non-elevated applications can communicate with the kernel-driver to access the disk directly.

What they are doing is: (b)

To mitigate (a):
* With other security-solutions you can monitor if applications (administrator-rights are needed) want RAW-access and you can block it (for example with SpyShelter)
* block it with an Anti-Executable
To mitigate (b):
* You can simply block the kernel-driver from loading (with DRP for example).
* block the application which is installing the driver with an Anti-Executable

If an application wants to install the driver:

But if the driver is installed, even non-elevated applications have access to all files or can write to disk sector by sector.

In both cases administrator-rights are needed.
(a) only elevated applications can access the disk directly
(b) the kernel-driver can only be installed with administrator-rights.

 

I believe that Bouncer also can filter/block kernel-mode drivers (.sys) by default as well. Although to be quite honest, I have never put much thought into specific rulesets targeting the blockage of .sys activity. But with the ever evolving state of malware, whitelisting kernel-mode drivers and blocking all other unknown kernel drivers might be something to consider one of these days.

Solid point, indeed. Once someone can install a kernel-mode driver (or gain Admin rights for that matter) it is game over at that point. You always make fantastic points and I appreciate how well you are able to detail and explain the points that you make in ways that are easy to understand.

 

Thanks @mood and @WildByDesign

Your explanations are great as usual, but at any given time depending upon malware advanced techniques and security setup, a kernel driver and/or privileges elevation can occur.

I understand a bit more how any program could potentially get raw direct access bypassing Windows and NTFS sec features.

Let's assume those countermeasures fail, still remains in my mind if there's the possibility to create a driver which can monitor and effectively block such raw access. Look, I don't want/like to plug and unplug my USB drives repeatedly, I just want to insert my USB drive and put a strong barrier between it and my OS.

 

Pumpernickel, what a great name ...

 

This tweak works on my Windows 8.1 home version. It denies execution access to removable (USB) drives

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}]
"Deny_Execute"=dword:00000001

 

Thanks. I already did but no noticeable change. Does this reg change needs reboot? Haven't reboot as I am on shadow mode a bit busy for the moment.

Btw, does "deny execution" really blocks raw direct access? Does this reg key really prevents malware from encrypt files?

 

N

I guess it is OS enforced, but You need to install driver to give userland programs direct access, sk I don't worry about that risk.

The tweak uses a GUID (name between brackets), so you might need to reboot and it might not work on all configs, that is why I said it might be an extra layer

 

Ok, i see that blocking kernel-mode drivers was also mentioned in #1644 in the Bouncer-Thread.
Yes, with whitelisting existing drivers and blocking all other drivers Bouncer can mitigate this.
But, if the drivers have a different extension than .sys it will be not easy to block them. For example Virtualbox is loading kernel drivers with an extension of .r0
C:\Program Files\Oracle\VirtualBox\VMMR0.r0
C:\Program Files\Oracle\VirtualBox\VBoxDDR0.r0
One more example:
AIDA - system information tool - kerneld.x64
It seems that kernel-drivers doesn't need to have a .sys-extension. So, if we now focus on *.sys for drivers, a driver can slip through (it depends on the rules) if it is named "malware.abc"
Regarding this it can help if Bouncer could differentiate between executables and drivers.
SOB for example does differentiate between them, you can whitelist drivers and block all other drivers (*) without affecting executables. No matter what the path/extension of a driver is, the driver will be blocked.

If we assume that the drivers of Virtualbox and AIDA are only rare exceptions with its "non-standard extension (x64 + .r0)", whitelisting drivers and blocking all unknown drivers *.sys with Bouncer (or other solutions) should be sufficient.

Thanks. I'll try to do my best

We know, in it's current state the kernel-driver of pumpernickel doesn't "notice" the raw-access. It is monitoring the filesystem-level.
But yes, to protect against raw-acess a program has to "monitor" the modification of sectors.

The driver MBR Filter for example is monitoring the first sector of the disk and is protecting it (HMP.A can block the MBR too)
If the MBR (one sector) can be protected, then this protection can be extended to more sectors/or even whole partitions.
I don't know of other solutions "out there" (driver/program) for blocking raw-access, but i'm sure a driver can be created for this.

But there is one solution for blocking raw-access (see next quote)
Sidenote: If you block the raw-access, it always blocks the access "completely". You can't define "exceptions".
If you want to let your backup-program write to your "raw-access-protected" backup-drive, you'll have to remove the protection first.

You can try to add "Deny_Write" (Deny Write access to Removable Devices)

Code:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}]
"Deny_Execute"=dword:00000001
"Deny_Write"=dword:00000001

If you edit the registry it's maybe better to reboot after a change. Or disconnect the drive, make the change in the registry and connect the drive again.
But at least the driver has to be reloaded.
Users with access to the group policy doesn't need to reboot after they changed it within the group policy.

After a quick test i couldn't modify sectors anymore on the removable drive
I opened the removable drive as a logical volume, modified a file = blocked
Now i opened it as a partition, wanted to modify a sector = blocked


The good thing is, write-access is completely blocked now.
Group-Policy users doesn't need to reboot after each change.
Home users without access to the Group Policy maybe need to reboot, i'm not sure about this.
Edit: small fixes

 

@mood @Windows_Security @WildByDesign

Thanks a lot! It worked.

Now either PartitionGuru or WinHex can't raw access my USB drives at all.





Did a little research and found this document about Registry Keys Related to USB Storage Devices, if anyone needs:
https://arsenalrecon.com/downloads/resources/Registry_Keys_Related_to_USB_Storage_Devices.ods

Only problem (and also advantage?) I see is the reg key affects all USB drives already connected. It would be great a driver to have selective functionality to protect per USB drive.

 

@Mister X good to know it worked

 

It works, you filled the "write-access hole". Now you can be sure that no program can write to your USB drives.
Little disadvantage: All removable devices are protected.

Btw.: You can also use:
"Deny_Read"=dword:00000001
Edit: If someone needs Read Access to USB-devices, this entry doesn't make sense. But for people who want to prevent that someone plugin an USB drive and copy files to the hard disk for example.

 

Thanks again.

Yes I was playing a while with this reg file, adding deny read value:

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}]
"Deny_Execute"=dword:00000001
"Deny_Write"=dword:00000001
"Deny_Read"=dword:00000001

However, USB drives won't come up again correctly, at least USB Safely Remove shows those USB sticks as hidden, on File Explorer they are seen and blocked though.

Oddly, PartitionGuru is still able to read the sticks but not able to write.

 

With Winhex i can access the partition too but access to the logical volume is blocked.
Regular programs (file-manager, explorer) are "showing" the drive (and the overall size) but have no further access to the filesystem.
Now with no access to the filesystem it would be very hard to copy files from the usb-stick.

It's nice to have an additional security-layer for protecting external media which are always connected (Deny Write + Execute).
But i think in general the protection of Pumpernickel is sufficient enough.
This may change if ransomware is implementing the raw access to hard disks - see #10

 

Rest assured it will. No doubts of me about that. That's why I'm anticipating to the scenario.
FIDES could step up to another level if it implements raw access blockage, per USB stick separately.

 

A real nightmare come true if it falls into the wrong hands. And I bet it will.