Why wrong? Well I think wrong because I said it posses a huge problem, well I retract myself and rephrase: I believe for ME it posses a problem for a very TIGHT security setup, in my particular case. Then I'm not wrong, if I was then why the invention of SOB & Bouncer, for granular control and very strong security, no?
The risk is not that big because ERP checks if apps launched from the system folders are legit system files or not. So this means that if malware copies itself to the system folders, it will still be blocked, even with the "allow protected system files" option enabled. Of course it's not advisable to whitelist the C:\Windows folder yourself, but I don't think you meant this. If so, sorry for the confusion.
No no no, never to whitelist full C:\Windows folder whatsoever. I meant to say only Windows system protected processes and Program Files folder processes which ERP announce with pop-ups on a clean install.
All this does is determine privilege status; not that it is a system file; i.e. stored in %Windows%\System32 or SysWow6432 directories: function IsSystemProcess(const hProcess: THandle): BOOL; stdcall; // Arg1 specified target process handle to determine whether the process is owned by SYSTEM Ref.: http://www.dllinjection.com/APIs/IsSystemProcess.htm
This API will tell you if the file is a system protected one; SfcIsFileProtected function. This will validate against the system catalog. So I guess if this was called for each file executed from the system directories, you would know if it was a system file or not. But like I said previously, there are valid signed files in those directories that are not protected system files. -EDIT- Actually, this is how it can be done: There is an internal list of protected files. SfcIsFileProtected calls IsLuaCdfFile which calls LuaCdfLookupFileEntry. There is a function named LuaCdfpFetchFileTable. Ref: http://forum.sysinternals.com/get-system-protected-files-list-on-windows_topic18284.html The LUA APIs shown are actually C language API calls: Ref.: http://simion.com/info/lua_capi.html Note: The above only is in ref. to WIN 7. Don't know about later Win versions. A HIPS rule that monitors who and what is written to %Windows%\System32 and SysWow6432 directories is a better solution in my opinion.
I'm not sure what you mean, I got this info from Andreas, and you can clearly read that this API is used to check if it's a protected system file. I guess that's why not all Windows files have to be signed by MS.
SfcIsFileProtected function will let you know if the file is a windows protected file. It can be called prior to file being accessed or written to %Windows%\System32 and SysWow6432 directories. Another approach would be using what I wrote in reply #32 to access the entire table of windows protected file entries and store it in memory for reference. Again, there are non-system files in these directories that are installed and are legit entries. So, an exception for these would have to be created by the anti-exec. SFC was created to verify that critical Windows system files have not been replaced by malware versions; not as a mechanism to protect access to %Windows%\System32 and SysWow6432 directories.
Another point to note is that Windows File Protection was changed starting with Vista and is called Windows Resource Protection: https://msdn.microsoft.com/en-us/library/windows/desktop/aa382503(v=vs.85).aspx A key element of WRP is Protected Resource List. Below are a couple of excerpts from the link I will post on same: Permission for full access to modify WRP-protected resources is restricted to TrustedInstaller. WRP-protected resources can be changed only using the Supported Resource Replacement Mechanisms with the Windows Modules Installer service. WRP protects critical folders. A folder containing only WRP-protected files may be locked so that only the Windows trusted installer is able to create files or subfolders in the folder. A folder may be partially locked to enable Administrators to create files and subfolders in the folder. WRP protects essential registry keys installed by Windows Server 2008 and Windows Vista. If a key is protected by WRP, all its subkeys and values can be protected. https://msdn.microsoft.com/en-us/library/windows/desktop/aa382503(v=vs.85).aspx I have not been able to find any reference on how to access directly the Protected Resource List. -EDIT- Came across this additional WRP excellent ref.: http://resources.infosecinstitute.com/windows-resource-protection/ . From the below excerpt; WRP does not copy those critical files that are not needed to restart Windows to the cache directory, unlike Windows File Protection, which cached the entire set of protected file types in the Dllcache folder. It appears that anti-exec's do not have direct access to a source that contains all system protected files references for any OS ver. after WIN XP.
Yes I know, but you're misunderstanding. The discussion was mainly about if it makes sense to enable a certain feature in EXE Radar. For convenience and not having to worry about breaking your system, I think it's best for anti-exe and HIPS to trust C:\Windows, except for non system files and system apps that can be used in attacks like cmd.exe, bcdedit.exe, bitsadmin.exe, and powershell.exe et cetera. It gets trickier with system apps like dllhost.exe and rundll32.exe, I'm not sure if it makes sense to monitor them with HIPS. Thanks for the info, so you would think that WFP also protects against malware, like file infectors.
I think you meant WRP versus WFP? The answer is no since WRP allows admins write access to folders like %Windows% + System32 or SysWow6426 as noted previously. So malware with admin privileges could create a malicious file in those directories.
Yes I meant WRP, but file infectors actually modify system files, this should be blocked. Creating a malicious .exe file in system folders is not a problem since it will still be blocked or monitored by anti-exe and HIPS. Of course other tricks, like DLL hijacking is harder to combat. So it's indeed best not to allow any non system files be placed inside system space.
The article states it will be installed from the %Temp% folder as a .tmp file. So can't the most basic of properly configured HIPS or anti-executables prevent this from taking a foothold in the first place? Not sure about Win 8 and beyond, but in Win 7 the vulnerable directories that I keep a watch on are in the uploaded picture...
If you're referring to physical disk modification i.e. file replacement, WRP will prevent that. If you're referring to runtime modification, we have covered that in other discussions such as disk and memory based .dll injection, etc.. It is impossible to create HIPS rules to prevent the above activity for all system files. Instead you concentrate on protecting system processes that normally execute such as explorer, svchost, etc. that are targeted by malware. Additionally, a good behavior blocker should detect any like activity from malicious processes against executing system files. I will add that two system processes, wuacuclt.exe and trustedinstaller.exe should be protected against runtime process modification since these are critical to WRP protection.
Refer to my #19 reply. It is possible to start a non-system process in "system space" as you refer to it.
Also worth mentioning is system folders can't be modified unless at least Admin privileges exist. Came across an interesting article here: https://www.greyhathacker.net/?p=738 that shows how malware can escalate privileges due to vulnerable paths with weak folder permissions. Author also provides a link in the article to download a Powershell script that will test your current configuration. I did so on my WIN 7 installation and below are the results. Do note how easy how easy it was to override Powershell's default no script execution policy. Of course, I had to "allow" execution for my existing Powershell HIPS "ask" rules. Note: If "access granted" is displayed for any folder, it can be used to escalate privledges. Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\xxxx>PowerShell.exe -ExecutionPolicy Bypass -File C:\Users\xxxx\Downloads \folderperm\folderperm.ps1 Number of folder paths : 5 Copying and removing test file to path folders where access is granted Access denied : C:\Windows\system32 Access denied : C:\Windows Access denied : C:\Windows\System32\Wbem Access denied : C:\Windows\System32\WindowsPowerShell\v1.0\ Access denied : C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
Yes correct, if exploits drop "file-based" payloads then any decent anti-exe will block them. If you want to block the exploit in an earlier face, you need anti-exploit. But most of the discussion was about what if malware copies itself into system folders to remain stealth. End conclusion is that HIPS and anti-exe should still be capable to monitor them. About the screenshot, why do all of those folders need to be monitored? I mean, if apps are not on the white-list, they will not be able to run anyway, isn't that the whole point of anti-exe?
Yes correct. I'm not sure if I understood. But of course, trusted apps should be allowed to install files into system space, if you don't trust them, then block it. Of course, not all HIPS offer this feature.
You referring to the screenshot in reply #38? You would have to asked the OP on why he is monitoring all those directories.
Right, with a strict white-list approach, those non-protected directories don't necessarily require monitoring, but if some legitimate action is required to take place in any one of them, the end user will probably want to know what it is, then, if necessary, allow it and even create rules for future, similar actions. This, as you know, happens so often in the %temp% directory.
Yes I did, I quoted him. OK I see, but to be honest, I've never seen anything being blocked from these folders. Except from C:\Users\*, but that is obvious.
This command can be used to run anything with System privileges; i.e. that is what the "-s " option means. The "0" parameter means it's running in session 0; the same level system services run at. psexec.exe -s -i 0 cmd.exe
Same here, but the fact they're no less vulnerable than the path you stated makes them, at least in my humble opinion, candidates for monitoring.
