Advice Request SRP - A practical default allow?

[SHvFl]

This is what this thread is about a default allow SRP that constrains certain apps and also apply WDAC to them ( though WDAC probably merits a separate thread )

If you don’t run malware on purpose and open untrusted docs inside the browser, then browser & email client are the two delivery mechanisms left ( excluding some sort of supply chain malware that I haven’t quite figured out how to prevent )

Your argument doesn't make much sense though as already chrome and maybe whatever email client you use takes into consideration the ability of windows to protect themselves. So you trying to add extra protection from windows without other tools is rather a weak way to go about even if it actually works. Your method puts all your apples in the same basket and someone hungry enough can eat them.
Sure we are talking about a hypothetical scenario but you asked for it. In reality, if you worry you will get infected by visiting sites and your email i would say you are safe and don't need to do anything.

 

[notabot]

Your argument doesn't make much sense though as already chrome and maybe whatever email client you use takes into consideration the ability of windows to protect themselves. So you trying to add extra protection from windows without other tools is rather a weak way to go about even if it actually works. Your method puts all your apples in the same basket and someone hungry enough can eat them.
Sure we are talking about a hypothetical scenario but you asked for it. In reality, if you worry you will get infected by visiting sites and your email i would say you are safe and don't need to do anything.

SRP + WDAC are on top of existing protection, these layers are not there out of the box

I don’t understand what you mean with the basket, why would adding a protection layer to eg visual studio that Never fetches anything but MS signed binaries be useful

 

[SHvFl]

SRP + WDAC are on top of existing protection, these layers are not there out of the box

I don’t understand what you mean with the basket, why would adding a protection layer to eg visual studio that Never fetches anything but MS signed binaries be useful

Chrome is already in appcontainer. Things will not magically start running on your system because you visited a site and in the scenario, an exploit manages to pass chrome it will probably be reported to chrome before it reaches your pc.
Same assuming you have outlook you can change 2 settings and nothing actually loads.
So at the end you are worried if something extreme remotely exploits your browser and email client. So both Srp and wdac are probably not good methods to solve that as you don't know how the exploit will work.
Anw you do you if you think that is the correct approach.

 

[notabot]

Chrome is already in appcontainer. Things will not magically start running on your system because you visited a site and in the scenario, an exploit manages to pass chrome it will probably be reported to chrome before it reaches your pc.
Same assuming you have outlook you can change 2 settings and nothing actually loads.
So at the end you are worried if something extreme remotely exploits your browser and email client. So both Srp and wdac are probably not good methods to solve that as you don't know how the exploit will work.
Anw you do you if you think that is the correct approach.

What you say is correct, effectively it’s about post exploit mitigation - I don’t agree though, restricting what can run & chroot’ing (via SRP) are the two techniques used to avoid privilege escalation, of course nothing is guaranteed to offer 100% protection but I don’t see why not to use the only existing post exploit mechanisms

 

[Andy Ful]

notabot,
The default-allow setup from the post Q&A - SRP - A practical default allow?, is OK. But, SHvFl is right that your concern about Chrome is unnecessary. You will probably never see something escaping the Chrome Sandbox. You can get the malware contained in the sandbox, but this usually cannot be stopped by SRP or WDAC. Furthermore, Chrome works best when left alone.

 

[notabot]

notabot,
The default-allow setup from the post Q&A - SRP - A practical default allow?, is OK. But, SHvFl is right that your concern about Chrome is unnecessary. You will probably never see something escaping the Chrome Sandbox. You can get the malware contained in the sandbox, but this usually cannot be stopped by SRP or WDAC. Furthermore, Chrome works best when left alone.

Neither interferes with Chrome (unlike eg a 3rd party AV), they’re mechanisms provided by the OS, not a hack with callbacks. and both provide different protections to the sandbox.

 

[Windows_Security]

I would suggest adding a basic user SRP (all executables except DLL and all users except Admin). Make sure to use the updated list of SRP enforces file extensions (e.g.Andy's Hard Configurator), but . . . . remove EXE. MSI and LNK from file extensions which SRP enforces. This is a ' hardened' default allow

 

[Andy Ful]

I would suggest adding a basic user SRP (all executables except DLL and all users except Admin). Make sure to use the updated list of SRP enforces file extensions (e.g.Andy's Hard Configurator), but . . . . remove EXE. MSI and LNK from file extensions which SRP enforces. This is a ' hardened' default allow

I think that removing shortcuts (LNK) from file extensions can be OK for @notabot, but generally it opens a very dangerous vector of attack through sponsors. For example, the shortcut can use CMD and Bitsadmin.exe to download/run the malware. It is also easy to make the shortcut with any kind of malware (EXE, DLL, etc.) added to it via Alternate Data Stream (ADS). If the user will run such a shortcut, then the commandline (with sponsor) in the shortcut can run the malware from ADS.

 

[Andy Ful]

The average user can ask a reasonable question. Why one should bother about the EXE or DLL malware executed via shortcuts, when EXE and DLL files are already allowed by SRP (in default-allow setup)?

1. The malware run via shortcuts will be ignored by SmartScreen.
2. The malware run via shortcuts will be usually the 0-day (fresh sample).

Such malware files are much more dangerous than the files downloaded by the user from the Internet.

 

[notabot]

The average user can ask a reasonable question. Why one should bother about the EXE or DLL malware executed via shortcuts, when EXE and DLL files are already allowed by SRP (in default-allow setup)?

1. The malware run via shortcuts will be ignored by SmartScreen.
2. The malware run via shortcuts will be usually the 0-day (fresh sample).

Such malware files are much more dangerous than the files downloaded by the user from the Internet.

You’re correct however to be clear, the proposed default allow here is about hampering the delivery mechanisms, hence their very tight control with 4 layers of defense (SRP+GPO+Exploit Guard+WDAC).

If despite the multiple layers of protection for the delivery mechanisms the malware gets in, then indeed it’s only the AV+Windows native protections left, there’s no further whitelisting that would block the malware.

 

[Andy Ful]

You’re correct however to be clear, the proposed default allow here is about hampering the delivery mechanisms...

Yes, that is why such files like shortcuts & scripts & sponsors & documents & files with dangerous extensions, should be properly blocked/restricted. But, doing this properly for shortcuts via SRP, without losing much usability, requires advanced knowledge about SRP.

 

[notabot]

Yes, that is why such files like shortcuts & scripts & sponsors & documents & files with dangerous extensions, should be properly blocked/restricted. But, doing this properly for shortcuts via SRP, without losing much usability, requires advanced knowledge about SRP.

I don’t see an attack vector with shortcuts.

shortcuts become relevant only when malware has reached the PC and executes, the whole point of the setup is that it doesn’t, Chrome is restricted by GPO (google offers templates) to download only to a specific folder and that’s set to non executable, with WDAC it won’t be able to spawn child processes so even if it’s hijacted to bypass the GPO it won’t be able to execute. In this setup SRP is there for the tail risk that chrome itself becomes the malicious actor and tries eg to delete or upload something (though that’s partly covered by Win 10’s protected folders as well)

It would be needed without WDAC probably but with WDAC I feel it’s redundant

 

[Andy Ful]

I don’t see an attack vector with shortcuts.
...
It would be needed without WDAC probably but with WDAC I feel it’s redundant

As I said before, you will not probably need it, because you will not execute the malicious shortcut by yourself. That will not be true for most people.

But, it does not matter, because you apply SRP and WDAC only to protect Chrome.
There is nothing wrong with it. But, such protection does not fit to the tile of this thread - it would be far from the practical solution for most users.

 

[notabot]

As I said before, you will not probably need it, because you will not execute the malicious shortcut by yourself. That will not be true for most people.

But, it does not matter, because you apply SRP and WDAC only to protect Chrome.
There is nothing wrong with it. But, such protection does not fit to the tile of this thread - it would be far from the practical solution for most users.

To go off topic slightly, with Chrome GPO you can block “potentially harmful downloads”, which is different to “harmful downloads”, potentially harmful is whitelisting of downloads.

It’s quite strict, eg it won’t let me download PDFs from my insurer while it will let me download PDFs from gmail (I assume due to scans in gmail) but for executables, this makes more sense, unless an executable is whitelisted (I presume by ESET?), it won’t download at all.

So a 2 browser setup, chrome with this policy on for browsing and eg FF exclusively for insurance , banking etc is probably the safest for home users as this way they won’t download malware exes while browsing unless their insurer pushes malware. Ofc there’s weaponised docs to worry about too but using web viewers from gmail should again suffice.

 

[Andy Ful]

To go off topic slightly, with Chrome GPO you can block “potentially harmful downloads”, which is different to “harmful downloads”, potentially harmful is whitelisting of downloads.

It’s quite strict, eg it won’t let me download PDFs from my insurer while it will let me download PDFs from gmail (I assume due to scans in gmail) but for executables, this makes more sense, unless an executable is whitelisted (I presume by ESET?), it won’t download at all.

So a 2 browser setup, chrome with this policy on for browsing and eg FF exclusively for insurance , banking etc is probably the safest for home users as this way they won’t download malware exes while browsing unless their insurer pushes malware. Ofc there’s weaponised docs to worry about too but using web viewers from gmail should again suffice.

Two-account setup is much safer: daily work + web browsing on SUA, banking only (no surfing) on Admin.

 

[shmu26]

To my way of thinking, the thing that is really missing from native Windows security policies is proper control of rundll32.exe. It can be used for a lot of mischief.

 

[notabot]

Two-account setup is much safer: daily work + web browsing on SUA, banking only (no surfing) on Admin.

It’s safer as you get more of windows native protections that way

 

[notabot]

To my way of thinking, the thing that is really missing from native Windows security policies is proper control of rundll32.exe. It can be used for a lot of mischief.

Once stuff is in it’s such a mess to contain it, you need complex policies that’s why with this setup I try to harden delivery mechanisms. I’ve setup Exploit Guard and GPO, SRP and WDAC to follow

After that (in the abscence of complete whitelisting) though far from perfect, there’s AV, UAC, Smartscreen - in my view these if any of these flags/asks something unexpected reinstall the OS, it’s too late