Advanced Plus Security Shmu26 Config in 2018

[509322]

Vendors using kernel-mode software should be taking precautions to keep their work safe against external usage.

For example, when handling IOCTL implementation, the device driver should always check what the caller process is by calling IoGetCurrentProcess routine and ensuring it's their own process via reliable authentication check techniques. For example, file-name, file-path, digital certificate and even custom byte pattern signatures embedded into the user-mode components which communicate with that kernel-mode component. For optimization purposes, the kernel-mode software can intercept process creation via PsSetCreateProcessNotifyRoutineEx and wait until a new process spawns with the process name of their user-mode image which will communicate with the kernel-mode software, and then perform checks and keep track of the right Process Identifiers for their own processes.

This would allow them to only allow requests to their kernel-mode software via techniques like IOCTL for processes with the right Process ID and would be strong against impersonation bypasses. They should also use IoCreateDeviceSecure instead of using the usually used IoCreateDevice routine and restrict IOCTL usage with their symbolic link to elevated processes only as another precaution.

Alternative methods would be secure named pipes implementation from kernel-mode (you can still create named pipes in a normal kernel-mode device driver via IoCreateFile which NtCreateNamedPipeFile calls) or secure ports IPC implementation. And enforce administrator rights to use the IPC method at-least as a minimum and still verify the requester....

All memory allocation should be done with the required and minimal memory protection. I see a lot of vendors setting NonPagedPool in kernel-mode for a unicode-encoded buffer, like what? You don't need executable rights for that for god sake, you only need RW minimum. I doubt Process Hacker does this one though, it's just something I noticed recently with some vendors products. Microsoft themselves even recommend to use NonPagedPoolNx now, they even flag warnings sometimes with WDK. For backwards compatibility when working on a driver for Windows 7 and below, just use a macro. Problem solved.


kprocesshacker.sys

processhacker/processhacker

I don't see any verification of the caller making the IOCTL request in the above source code, unless this is outdated or I am blind and haven't realized where the authentication check is being performed (which is unlikely).

At-least if NtOpenProcess or NtTerminateProcess is hooked in user-mode you could do IOCTL to the device driver with KPH_OPENPROCESS and KPH_TERMINATEPROCESS IOCTL codes instead of bothering to do a direct system call yourself.

I just checked it. They're using the same lousy kprocesshacker.sys. I happen to use Process Hacker because it offers a more convenient networking infos than Process Explorer - which buries the networking infos on a tab buried in a sub-GUI.

 

[Deleted member 65228]

VirtualBox's driver not patched. And people call me a Microsoft-basher -- which I'm not -- as if Microsoft doesn't earn it all by itself.

I don't think it has been, or at-least I haven't heard of it being patched.

The technique works by getting the VirtualBox driver to patch a flag in a module named CI.dll which is a module used by NTOSKRNL. This specific flag used in this module is used by the Windows Kernel to determine if driver signature enforcement is enabled or not, so if you patch the flag... Then you can do whatever you want. On some systems and in some situations, it can cause a BSOD, but to reduce this you can re-patch the flag after getting your unsigned "driver-less" driver loaded and then no one would even know something had gone wrong to identify the patch change.

The VirtualBox driver is exploited because it can access and patch the memory for this. Other drivers out there somewhere will be exploitable to do the same task as well.

It's really ridiculous if they have not patched their driver to stop this. It's just stupid.

Microsoft are being way to lenient with vendors of kernel-mode software, I think they should just start chucking around a ban hammer and lock down rules basically saying, "Patch your insecurities or get lost".

 

[509322]

I don't think it has been, or at-least I haven't heard of it being patched.

The technique works by getting the VirtualBox driver to patch a flag in a module named CI.dll which is a module used by NTOSKRNL. This specific flag used in this module is used by the Windows Kernel to determine if driver signature enforcement is enabled or not, so if you patch the flag... Then you can do whatever you want. On some systems and in some situations, it can cause a BSOD, but to reduce this you can re-patch the flag after getting your unsigned "driver-less" driver loaded and then no one would even know something had gone wrong to identify the patch change.

The VirtualBox driver is exploited because it can access and patch the memory for this. Other drivers out there somewhere will be exploitable to do the same task as well.

It's really ridiculous if they have not patched their driver to stop this. It's just stupid.

Microsoft are being way to lenient with vendors of kernel-mode software, I think they should just start chucking around a ban hammer and lock down rules basically saying, "Patch your insecurities or get lost".

Microsoft has known about this matter for nearly as long as it has existed. Drivers are Microsoft's domain. And that makes Kernel matters and security wholly Microsoft's responsibility. That's all there is to it. I know there are those that would debate me to death on my position, but given Microsoft policies and programs they are the Kernel Police. So Microsoft is responsible to intercede and I will leave it at that.

 

[509322]

We're hijacking @shmu26 's config thread.

 

[shmu26]

We're hijacking @shmu26 's config thread.

Keep on talkin' it doesn't bother me in the least.

 

[Windows_Security]

@Windows_Security I guess this is the place for me to ask you about your configuration for OSArmor, rather than hijacking @Umbra's thread...

This is the question I had posted over there:
@Windows_Security, how would you configure OSA so that it will do the same as NVT ERP?
More specifically, how can you make OSA block signed exe files, like ERP does, but still allow system files etc? Sounds to me like you created some smart blacklist rules?

I am on holiday, will answer second week of April.

 

[shmu26]

Trying out new config:

Windows Defender
Andy Ful Hard_Configurator with SRP
Andy Ful ConfigureDefender
Excubits MemProtect (demo)
Excubits Pumpernickel (demo)

The default/deny SRP policy blocks also a list of vulnerable processes, and dll protection is enabled.
The excubits tools are configured to lock down exploitable apps, such as MS Office and Chrome.

 

[Andy Ful]

I am impressed.
The DLL protection is demanding and not convenient for most users.
Can you print from MS Office? Are there any side effects of locking MS Office via Excubits drivers?

 

[shmu26]

I am impressed.
The DLL protection is demanding and not convenient for most users.
Can you print from MS Office? Are there any side effects of locking MS Office via Excubits drivers?

I don't have any problem with dll protection. I whitelisted three or four appdata and programdata folders using *.dll, for the folders used by my specific apps, and that's it. It does not slow down my apps.

MS Office with Excubits allows regular printing (I have HP officejet), but I can't print to fax unless I whitelist rundll32. That's how how my printer driver works.
I can even use the email command in Word, and email message opens in Outlook. But in fact, I use Outlook only for the calendar, not for email.
There may be some advanced functions that don't work, I can only say about the functions I use regularly.

This is my memprotect demo config. Some items are not relevant to my current config. I whitelisted Outlook because it has no email account associated with it, I use it only for the calendar.

[#INSTALLMODE]
[LETHAL]
[LOGGING]
[#INSTALLMODE]
[DEFAULTALLOW]
[MODULEFILTER]
[WHITELIST]
!*software_reporter_tool.exe>*
!*chrome*>*chrome*
!*chrome.exe>C:\*\System32\rundll32.exe
!*OUTLOOK.EXE>*
!*Office1?\*>*Office1?\*
!*Office1?\*>*MsMpEng.exe
!*chrome*>*MsMpEng.exe
!*TogglDesktop.exe>*TogglDesktop\*
!*tixati.exe>*tixati\*
!*tixati.exe>*Downloads\*
!*WinSCP.exe>*WinSCP\*
!*WinSCP.exe>*Desktop\*
!*MsMpEng.exe>*
!*AppGuard\*>*
!*Blue Ridge Networks\*>*
[BLACKLIST]
$*Chrome\*>*
$*Office1?\*>*
$*TogglDesktop.exe>*
$*\tixati.exe>*
$*WinSCP.exe>*
[MODULEWHITELIST]
*>*
[MODULEBLACKLIST]
*EXCEL.EXE>*flash*.ocx
*EXCEL.EXE>*packager.dll
*EXCEL.EXE>*vbs.dll
*WINWORD.EXE>*flash*.ocx
*WINWORD.EXE>*packager.dll
*WINWORD.EXE>*vbs.dll
*>*system.management.automation.dll
*>*LxssManager.dll

[EOF]

 

[Andy Ful]

I can only say about the functions I use regularly.
...
[MODULEBLACKLIST]
...
*>*system.management.automation.dll
...
[EOF][/QUO

This entry will not work. The above is .NET DLL, and such DLLs are not covered by Excubits drivers (also ignored by SRP) . You can easily test it by running powershell.exe .
When system.management.automation.dll is blocked then powershell.exe cannot be executed.

 

[Sunshine-boy]

Excubits Pumpernickel

You can do the same with Eset hips(or other tools)t!why did you pay for this tool?if tis smth like a DLP system you can do it with any hips!or even windows inbuild stuff.

 

[mekelek]

You can do the same with Eset hips(or other tools)t!why did you pay for this tool?

he has the trial.

 

[Andy Ful]

You can do the same with Eset hips(or other tools)t!why did you pay for this tool?if tis smth like a DLP system you can do it with any hips!or even windows inbuild stuff.

He uses a functional demo version that protects only a few entries.

 

[shmu26]

You can do the same with Eset hips(or other tools)t!why did you pay for this tool?if tis smth like a DLP system you can do it with any hips!or even windows inbuild stuff.

They are right, I use the free demo version.
With a different tool, it is not so easy to configure it like I did.
I have different exploitable apps set up with different rules, depending on what areas they need to read and write to.
For instance, Word needs read/write access to my Dropbox folder, because that is where my docs are. But Chrome does not need this access.

 

[shmu26]

This entry will not work. The above is .NET DLL, and such DLLs are not covered by Excubits drivers (also ignored by SRP) . You can easily test it by running powershell.exe .
When system.management.automation.dll is blocked then powershell.exe cannot be executed.

Thanks. I didn't know that. So here is a case where Appguard has an advantage. And OSArmor has protection for it, too.
Any other way you know to block a dll like this?

 

[Andy Ful]

And OSArmor has protection for it, too.
Any other way you know to block a dll like this?

I think, that OSArmor in actual version is not prepared to block custom DLLs (by name or path). I suggested this feature to Andreas some time ago and he answered that it is possible. Maybe he will add this in the future. The problem with .NET DLLs is that they are compiled on the fly as opposed to the normal DLLs which are already compiled.
I do not know if there is a free application that can block .NET DLLs.

 

[shmu26]

I think, that OSArmor in actual version is not prepared to block custom DLLs (by name or path). I suggested this feature to Andreas some time ago and he answered that it is possible. Maybe he will add this in the future. The problem with .NET DLLs is that they are compiled on the fly as opposed to the normal DLLs which are already compiled.

Right, but over at Wilders, me and Peter kept bugging Andreas about it, until he wrote a specific rule for arguments containing system.management.automation.dll. Actually, I am not sure exactly how he did it, but he says he did it.
NoVirusThanks OSArmor: An Additional Layer of Defense
NoVirusThanks OSArmor: An Additional Layer of Defense
But in general, it does not block dlls.

 

[shmu26]

I think, that OSArmor in actual version is not prepared to block custom DLLs (by name or path). I suggested this feature to Andreas some time ago and he answered that it is possible. Maybe he will add this in the future. The problem with .NET DLLs is that they are compiled on the fly as opposed to the normal DLLs which are already compiled.
I do not know if there is a free application that can block .NET DLLs.

I brought up your point over at Wilders, and they claim that memprotect can block .NET DLLs. Someone posted me a screenshot from Process Hacker, to demonstrate that it was blocked. MemProtect - Support & Discussion

 

[Andy Ful]

Right, but over at Wilders, me and Peter kept bugging Andreas about it, until he wrote a specific rule for arguments containing system.management.automation.dll. Actually, I am not sure exactly how he did it, but he says he did it.
NoVirusThanks OSArmor: An Additional Layer of Defense
NoVirusThanks OSArmor: An Additional Layer of Defense
But in general, it does not block dlls.

It does not work. I ticked all options in OSArmor except 'Block execution of unsigned processes on user space'. Next, I copied powershell.exe to another location and renamed it, then I was able to execute renamed executable.

 

[Andy Ful]

I brought up your point over at Wilders, and they claim that memprotect can block .NET DLLs. Someone posted me a screenshot from Process Hacker, to demonstrate that it was blocked. MemProtect - Support & Discussion

I added your DLL rule to MemProtect MODULEBLACKLIST and still could run powershell.exe. When I added powershell.exe to the BLACKLIST, it was blocked.