Lockdown.exe: Block unknown apps via Windows software restriction policy
d7xtech.com
d7xtech.com
SRP is enforced in user mode, and it can be circumvented by hooking user mode API calls. Back in 2005 Mark Russinovich blogged about bypassing SRP: https://web.archive.org/web/20061219234012/http://blogs.tech...
AppLocker does the enforcement in kernel-mode, so it can't be bypassed with DLL injection. (The kernel side could be patched by a user with local Administrator rights, but that runs afoul of Kernel Patch Protection and raises the bar significantly for an attacker. Users should be using unprivileged accounts for day-to-day work anyway... >grumble<)
SRP in whitelist mode is more difficult to bypass, but it's still possible to patch it out by using WriteProcessMemory: https://blog.didierstevens.com/2008/06/25/bpmtk-bypassing-sr...
I'm not suggesting that this tool isn't useful, but it's not the same thing as AppLocker or Windows Defender Application Control. If SRP ends up being used significantly as a defense attackers will just incorporate bypassing it into their payloads / strategies (start out w/ getting the user to run a Word macro that patches Word's copy of ADVAPI32.DLL, etc).
Is anyone aware of a tool that simplifies setting up AppLocker? I simply would like to whitelist already installed programs and block everything else, ideally without configuring anything.
That would really simplify things
Microsoft Defender Application Control https://docs.microsoft.com/en-us/mem/intune/protect/endpoint...
Microsoft Defender Application Control https://www.youtube.com/watch?v=r2m156VWg_c
Replacing AppLocker with Microsoft Defender Application Control in Windows 10 1903 and later https://www.theexperienceblog.com/2019/10/24/replacing-applo...
Application-level permissions that aren't enforced by hardware seem like a losing proposition to me. I get that a belt-and-suspenders approach isn't unreasonable, so I guess it's not valueless, but I wouldn't have it as my only line of defense.
What a great idea!
People of requisite cautiousness will vet the shell script – but I suspect most will not.
curl https://potentially-malicious.com/get-infected.sh > get-infected.sh
$EDITOR get-infected.sh
[[ $POST_REVIEW_OPINION -eq happy ]] && bash ./get-infected.sh || rm ./get-infected.sh
The reasons for this are at least twofold: (1) $EDITOR probably has syntax highlighting, which will help you understand the text better. Always do your code reviews with the supportive assistance of tools.
(2) If you intend to review a script before you run it on your computer, it is intrinsic to the task that you review the script you are about to run on the computer. As you observe, a malicious user might detect the User-Agent and give a different script. But completely non-malicious changes could happen too: for instance, there could be an update or you could type in the command wrongly and accidentally review one script but run another.
In any case, it's worth noting that the user who wants to review the install script before they run a potentially malicious installer needs to consider whether they actually trust the software they're about to install. A malware author could easily install a binary of potentially-malicious in a perfectly benign way, and it happens that once it's been running for three hours it reads exfiltrates your aws keys on apparently ordinary API requests it makes.If you don't trust author/distributors (whether it is ad hoc distribution or appstore distribution), it is probably better to rely on third party distributors as found in traditional GNU/Linux distributions. They aren't flawless, but the delays are there partly to help making trusting a random group of independent developers more trustworthy.
If you don't trust first party author/distributors or third party distributors, I guess you have a sufficiently sandboxed setup that means `curl | sh` is actually safe, or else you download the source code, review the whole package, and build it or don't, so you don't want to `curl | sh` anyway.
I actually don't think I have a single piece of non-signed executable on my Windows PC.
Either the author is random or it is not, and the signature is not really going to discriminate much in this area...
It's also an outdated view:
1. Most Windows software is signed with an Authenticode cert which requires the author to prove who they are to the CA and hand over at least $99.
2. Windows these days has SmartScreen running all the time, which checks executable file hashes against a cloud based database and blocks apps with known issues. Doesn't help if it's an unknown but massively reduces the risk.
3. Windows has a policy that can be enforced that blocks the execution of any software that doesn't pass points #1 and #2.
https://www.ssl.com/certificates/code-signing/buy/
That's a yearly cost, but you only need to keep renewing if you are signing and releasing new apps or updates. Existing apps you've signed will remain valid if if you don't renew your cert (unlike websites etc.)
Also, it seems that the LARGE cost for the EV certs is only really needed for things like Windows drivers.
they do have EV for $350/annual or $750/3 year cert so I might try that it is certainly cheaper than digicert.
and yes EV is good for more than drivers, it allows EXEs to bypass smartscreen prompts that would otherwise trigger on standard certs that have to go through reputation checks in smartscreen.
Is there any 'free' Authenticode cert providers out there? Doing the same job as LetsEncrypt but for code?
Basically: Microsoft is irrelevant to the equation.
You are better off not using Microsoft products if you don't trust them, and considering the safety and security of artefacts produced by random unsigned internet developers independently of the safety and security of artefacts produced by Microsoft.
Also, if you're subject to this kind of logical fallacy, you might consider not installing Microsoft products just to avoid the distraction in your reasoning. Every platform will have a different set of trade-offs.
"Lockdown also goes a step further and restricts not only executables, but DLLs and other code libraries as well."
I wasn't sure if this would include batch files, so I tried testing; sure enough, they were blocked if not run from a whitelisted directory.
They were deprecated in 1803.
For a few moments I thought you were being sarcastic about the fact that Software Restriction was deprecated ages ago by mentioning a date two hundred years in the past.
Then I realised it's a Windows 10 version number.
Edit: For reference, 1803 was released in 2018 https://en.wikipedia.org/wiki/Windows_10_version_history#Ver...
Current Windows 2019/Windows 10 offers WDAC, which is more advanced still.
There's a lot of security discussions that really don't give these technologies credit. For example, a WDAC policy can prevent early launch rootkits ever loading, and will be enforced by Secure Boot.
But as I mentioned - I'm not sure how exactly lockdown integrates in this system.
Applications are a bigger problem, use chocolatey and whitelist its dir too
But using a third party tool (unsigned btw) to manage such a sensitive part of the system is a bad idea.
I would use it if it was a PS script I can verify.
Don't generalize my point about openness, I understand that for many unlike me it wouldn't add any benefits.
My recommendation would be for Microsoft to not abandon Applocker, provide it with decent UI and enable it on home editions.
But it's usually the user data that's the problem, and that's shared to all the other users. So don't let users run unauthorised code by using SRP/Applocker