Pumpernickel (FIDES)

Yes. That's another challenge for the driver to handle internal drives indeed.

 

A line or lines are written in the log file. You can always clear the log file and it will turn green once again.

 

You are welcome.

 

This is my Pumpernickel.ini but the red lines are missing in [WIHITELISTMODIFY], is that correct?

[LETHAL]
[LOGGING]
[WHITELISTMODIFY]
!C:\Program Files (x86)\2BrightSparks\SyncBackFree\SyncBackFree.exe>T:*
!C:\Program Files\Jotta\jotta.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheck.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheckB.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheckS.exe>T:*
missing *>T:*
[BLACKLISTMODIFY]
$!*SearchIndexer.exe>T:*
*>T:*
[WHITELISTREAD]
!C:\Program Files (x86)\2BrightSparks\SyncBackFree\SyncBackFree.exe>T:*
!C:\Program Files\Jotta\jotta.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheck.exe>T:*
!C:\Program Files (x86)\Blue Ridge Networks\AppGuard\AppGuardAgent.exe>T:*
!C:\Program Files (x86)\Blue Ridge Networks\AppGuard\AppGuardGUI.exe>T:*
*>T:*
[BLACKLISTREAD]
$!*explorer.exe>T:*
$!*wininit.exe>T:*
$!*svchost.exe>T:*
$!*SearchIndexer.exe>T:*
$!*Cloud.exe>T:*
$!*chrome.exe>T:*
$!*HDSentinel.exe>T:*
*>T:*
[EOF]

It looks exactly like this:

Spoiler: Pumpernickel.ini

Code:

[LETHAL]
[LOGGING]
[LETHAL]
[LOGGING]
[WHITELISTMODIFY]
!C:\Program Files (x86)\2BrightSparks\SyncBackFree\SyncBackFree.exe>T:*
!C:\Program Files\Jotta\jotta.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheck.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheckB.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheckS.exe>T:*

[BLACKLISTMODIFY]
$!*SearchIndexer.exe>T:*
*>T:*
[WHITELISTREAD]
!C:\Program Files (x86)\2BrightSparks\SyncBackFree\SyncBackFree.exe>T:*
!C:\Program Files\Jotta\jotta.exe>T:*
!C:\Program Files\CheckMAL\AppCheck\AppCheck.exe>T:*
!C:\Program Files (x86)\Blue Ridge Networks\AppGuard\AppGuardAgent.exe>T:*
!C:\Program Files (x86)\Blue Ridge Networks\AppGuard\AppGuardGUI.exe>T:*
*>T:*
[BLACKLISTREAD]
$!*explorer.exe>T:*
$!*wininit.exe>T:*
$!*svchost.exe>T:*
$!*SearchIndexer.exe>T:*
$!*Cloud.exe>T:*
$!*chrome.exe>T:*
$!*HDSentinel.exe>T:*
$!*EXERadar.exe>T:*
*>T:*
[EOF]

 

missing *>T:* is not needed in you [WHITELISTMODIFY] because you blacklisted *>T:* in your [BLACKLISTMODIFY]
which blacklistmodify have priority over whitelist
same goes for WHITELISTREAD rules

 

Thank you.

 

I've issued a feature request to the FIDES developers to allow for the use of a GUID rather than a MOUNT POINT with the Pumpernickel.INI directives.

This will allow unmounted drives to remain protected if mounted to different mount points for possible nefarious purposes.

If I hear anything, I'll pass it on...

 

Excellent suggestion. Since this is something that can improve security and configuration granularity even more then I am certain that the lead developer, Florian, will have a look into this. As long as GUID's are managed within the kernel then I am sure that he will have interest in implementing this feature. For my own curiosity sake, I did a quick Google search for "GUID kernel mode" and came up with some good information:
Using GUIDs in Drivers (https://msdn.microsoft.com/en-us/library/windows/hardware/ff565392(v=vs.85).aspx)
Kernel-Mode Interfaces Implemented By the Display Miniport Driver (https://msdn.microsoft.com/en-us/library/windows/hardware/hh451569(v=vs.85).aspx)
Including GUIDs in Driver Code (https://msdn.microsoft.com/en-us/library/windows/hardware/ff547786(v=vs.85).aspx)

So that definitely seems feasible from a development perspective. As long as he can contain that feature code entirely within kernel-mode, then it is a good possibility. There have been certain features in the past (at least with Bouncer anyway) where Florian would not implement specific features because they required a user-mode to/from kernel-mode mechanism and he was not willing to sacrifice opening greater attack surface for certain features. He is usually quite good at doing further research into feature requests and seeing different methods to implement such features and then getting back to the user who requested the feature. Please do let us know if you hear back from him on this because it is quite interesting, indeed.

This a good to see, Pete. Thanks for sharing.

 

Pete, which RansomeWare variant were you testing with?

 

Sideeffect is, the cfg will be much harder to maintain for the user with hundreds of lines and nearly each line a different GUID.
To distinguish between D:, E:, F:, G: is easy and D: means D:
but with a long GUID like {1930cb72-2600-22e8-cbad-776e6b6e4972}
Which GUID is which partition?

So the user maybe need to make a list of all GUIDS which he is using in his cfg at the beginning and write down the partition:

Code:

// {1930cb72-2600-11e8-cbad-126e6b6e4972} = D:
// {1930cb72-2600-21e8-cbad-456e6b6e4977} = E:
// {1930cb72-2600-22e8-cbad-906e6b6e4979} = F:
// {1930cb72-2600-22e8-cbad-906e6b6e5080} = G:

If the user now encounters the following line, he scrolls up and then he knows that it's partition D:

Code:

C:\Program Files\WinRAR\*>{1930cb72-2600-11e8-cbad-126e6b6e4972}

But with hundreds of lines and a lot of GUID's it will be a time-consuming task.

If variables can be used it will be much easier. But i'm not sure if this will be possible.
Something like this:

Code:

[VARIABLES]
D = {1930cb72-2600-11e8-cbad-126e6b6e4972}
E = {1930cb72-2600-21e8-cbad-456e6b6e4977}
[/VARIABLES]
[WHITELISTMODIFY]
C:\Program Files\WinRAR\*>$D$
C:\Program Files\WinRAR\*>$E$

= Bouncer is using the GUID for more security and the user can see $D$ instead of the cryptic GUID and knows immediately what partition this is (D:)

Edit: My initial thought was:
After the user has replaced all partitions with a GUID, isn't is much harder to maintain the list, If the user has a lot of rules with 15-20 different partitions/GUID's in the cfg?
If the user looks now at the rules, how does the user easily know which GUID is pointing to which partition?

 

On my System, at least, the GUID doesn't change for a given device once it's been mounted on the System. The GUID is established and always assigned to that same partition/volume wherever it's mounted. If this is the normal case, then a simple 1-time multiple edit of the INI file will replace the DRIVE LETTER my volume is normally used at with the GUID instead. With this capability, if the unMounted volume is discovered and mounted elsewhere, the originally established GUID follows the volume to the new mount point and the protection stays in place. Without the GUID, the newly mounted volume at a different mount point is now fully vulnerable.

For me, that's a simple edit to change the existing protected mount point to a protected GUID no matter where it winds up mounted. Am I missing something obvious here...?

 

I think i painted a worst-case scenario above but in reality it's much easier.

They are usually quick in responding.
Keep us informed

 

Plus Pumpernickel Tray right-click is greatly improved.

 

re @mood

Totally agree

 

Good to know about SF, as I still use it on my second machine. I still think SF interface is nice, but at least FIDES is in development, and the logging feature allows one to see what is going on and configure.

 

Just heard back from Florian on my GUID request...

Thanks for your comment and suggestion. Well, yes we could take it into
consideration and try to add GUID qualifiers to the ini file, if possible.
Sounds interesting, so we will check on it.

 

First i wondered because i could only see one option: "Show Log" and Exit Application.
I had to execute "Tray.exe" and not "PumpernickelSignalCheck.exe", a leftover from previous versions
But yes, a lot of options were added if i compare both Tray-icon executables.

 

As much as I luv FIDES (Pumpernickel), it didn't stop the paranoid me from installing the Pumpernickel driver under a different name other than Pumpernickel. Although it still works well, one of the additional features, with its options, does not work... "Tray.exe." That app appears to be wired for a driver named Pumpernickel.

As such, I've asked Florian (FIDES developer) if he would consider a CommandLine switch for "Tray.exe" that would allow for a name change of the driver being managed by that program.

I'll pass on any feedback I get concerning that request.

 

Feedback from Florian on the above request...

This would be possible. We need change some minor things in the Tray-Tool.
I will follow up, if I have any news regarding this "add-on feature".

 

Nice.