Advice Request SRP - A practical default allow?

[notabot]

Default deny has the issue that it may become impractical.

I was thinking of a default allow with the below applications tightly controlled:

1) browsers
2) pdf reader
3) Office/anything that opens a document
4) email client
5) chat clients, Skype , messengers

So basically anything that connects to the internet and opens & parses input.

This way someone can develop in Visual Studio , node etc without hinderance and have a tightly controlled set of applications that can be exploited from the web/PDFs/spreadsheets etc.

Does the above miss any significant attack vector ? I’d find this way more practical than a default deny setup

 

[shmu26]

Basically, this is ReHIPS in permissive mode, or Sandboxie properly configured.

 

[notabot]

Basically, this is ReHIPS in permissive mode, or Sandboxie properly configured.

But it’s with native mechanisms that won’t conflict with the OS updates and more likely than not it won’t conflict with the said application updates ( sandboxe had broken FF in the past )

 

[shmu26]

But it’s with native mechanisms that won’t conflict with the OS updates and more likely than not it won’t conflict with the said application updates ( sandboxe had broken FF in the past )

Right. Sandboxie is pretty good at breaking applications. ReHIPS is not, though. It's pretty safe with updates.
But I like you idea. @Andy Ful already did part of the work with his "anti-document exploit" tool. And I understand he is working on rules to harden browsers. And ConfigureDefender already has some ASR rules to harden email clients.

 

[notabot]

Right. Sandboxie is pretty good at breaking applications. ReHIPS is not, though. It's pretty safe with updates.
But I like you idea. @Andy Ful already did part of the work with his "anti-document exploit" tool. And I understand he is working on rules to harden browsers. And ConfigureDefender already has some ASR rules to harden email clients.

ASR & exploit guard for browsers I’ve setup (though some ASR rules are buggy on my machine), I’ve also completely locked down Office via MS’s downloadable GPO template which blocks things before ASR can be triggered

Even if ReHIPS is good regarding compatibility , to prefer the OS’s mechanisms. I’m basically locking down Windows the same way I’d lock down a Linux machine, relying exclusively on what the OS provides, so far I see little reason for 3rd party security, the above default-allow SRP and WDAC are the two pieces I haven’t done yet

 

[Andy Ful]

Default deny has the issue that it may become impractical.

I was thinking of a default allow with the below applications tightly controlled:

1) browsers
2) pdf reader
3) Office/anything that opens a document
4) email client
5) chat clients, Skype , messengers

So basically anything that connects to the internet and opens & parses input.

This way someone can develop in Visual Studio , node etc without hinderance and have a tightly controlled set of applications that can be exploited from the web/PDFs/spreadsheets etc.

Does the above miss any significant attack vector ? I’d find this way more practical than a default deny setup

The default-allow setup + AV can be very effective, just protect the attack vectors covered by SysHardener. You can drop some of them if you are a cautious user.

The setup which is close to your idea can be also made (for some users) without GPO:

1. Browser, chat clients, Skype , messengers - in AppContainer.
2. Ads & malware filtering via DNS or web browser extension.
3. WD + WD Network Protection.
4. PDF viewer in AppContainer with blocked active content.
5. Office Online.
6. VLC from Microsoft Store (watching films).
7. etc. - generally use applications in AppContainer from Microsoft Store (Universal Apps).
8. Gmail (Google) - do not open spam attachments; open other attachments via the above applications.
9. Do not open the files, which cannot be opened by the above applications.

The built-in AppContainer restrictions for Universal Apps are often stronger than GPO policies for desktop applications. Furthermore, the AppContainer environment can hardly be exploited (so far).
The con of the above setup is that applications from Microsoft Store are rather simplistic. You can also like to install some games and probably some applications for productivity (not available as Universal Applications in Microsoft Store).

You are wrong when thinking that MS Office or Adobe applications can be tightly controlled by Windows built-in policies. Those policies can prevent only the known & popular attack techniques, and M$ template can do even less (far away from locking down MS Office).

If you are cautious enough and can avoid the risky activities, then you do not need anything else except the standard Windows 10 protection with SUA, on the well updated system and well updated software. The chances to be infected are probably as little, as chances to be robbed of the computer.

If you are applying Windows Policies, then you probably think that something on your system can be exploited, or you are afraid of running something malicious (script, file with dangerous extension, installer, etc.). You can apply default-allow setup for installers and restrict scripts, block files with dangerous extensions, block some popular sponsors, etc. The chances of infection will drop significantly.

You can use the recommended H_C default-deny setup (also based on SRP and some Windows Policies) with forced SmartScreen, and then the chances of infection in the home environment will be very little. Doing this via GPO is possible (requires deep knowledge of SRP and much work), but will be uncomfortable in daily work.

You can use H_C default-deny (max settings) + no elevation on SUA profile, and then the chances of the infection will be close to 0.

Simply, the user have to decide what level of security will be enough. For most users, the default-allow setup similar to SysHardener settings + AV will be OK.

 

[notabot]

The default-allow setup + AV can be very effective, just protect the attack vectors covered by SysHardener. You can drop some of them if you are a cautious user.

The setup which is close to your idea can be also made (for some users) without GPO:

1. Browser, chat clients, Skype , messengers - in AppContainer.
2. Ads & malware filtering via DNS or web browser extension.
3. WD + WD Network Protection.
4. PDF viewer in AppContainer with blocked active content.
5. Office Online.
6. VLC from Microsoft Store (watching films).
7. etc. - generally use applications in AppContainer from Microsoft Store (Universal Apps).
8. Gmail (Google) - do not open spam attachments; open other attachments via the above applications.
9. Do not open the files, which cannot be opened by the above applications.

The built-in AppContainer restrictions for Universal Apps are often stronger than GPO policies for desktop applications. Furthermore, the AppContainer environment can hardly be exploited (so far).
The con of the above setup is that applications from Microsoft Store are rather simplistic. You can also like to install some games and probably some applications for productivity (not available as Universal Applications in Microsoft Store).

You are wrong when thinking that MS Office or Adobe applications can be tightly controlled by Windows built-in policies. Those policies can prevent only the known & popular attack techniques, and M$ template can do even less (far away from locking down MS Office).

If you are cautious enough and can avoid the risky activities, then you do not need anything else except the standard Windows 10 protection with SUA, on the well updated system and well updated software. The chances to be infected are probably as little, as chances to be robbed of the computer.

If you are applying Windows Policies, then you probably think that something on your system can be exploited, or you are afraid of running something malicious (script, file with dangerous extension, installer, etc.). You can apply default-allow setup for installers and restrict scripts, block files with dangerous extensions, block some popular sponsors, etc. The chances of infection will drop significantly.

You can use the recommended H_C default-deny setup (also based on SRP and some Windows Policies) with forced SmartScreen, and then the chances of infection in the home environment will be very little. Doing this via GPO is possible (requires deep knowledge of SRP and much work), but will be uncomfortable in daily work.

You can use H_C default-deny (max settings) + no elevation on SUA profile, and then the chances of the infection will be close to 0.

Simply, the user have to decide what level of security will be enough. For most users, the default-allow setup similar to SysHardener settings + AV will be OK.

Thanks @ Andy, I plan to block sponsors via WDAC when I get a free evening do you have a list of sponsors ?

I can’t agree regarding GPO and Office, it eg lets you block downloaded active content ( or active content altogether). If you refer to exploitation of office without active content by eg buffer overflows , these are complex, big apps and probably to have undiscovered exploits. But this is not a commodity attack.
To cover these Exploit Guard ( to reduce the probability of exploit succeeding ) + WDAC for sponsors ( to reduce chances of privilege escalation ) + SRP ( to reduce what an exploited app can do from user space ). This lockdown is probably as good as it gets. We also have to consider that a document that’s meant to do a 0day without active content and also bypasses the other 3 mitigation layers, while entirely possible, is probably something that us home users don’t need to be worried about and I don’t believe there’s anything that can block an attack that’s so elaborate

 

[shmu26]

Thanks @ Andy, I plan to block sponsors via WDAC when I get a free evening do you have a list of sponsors ?

I can’t agree regarding GPO and Office, it eg lets you block downloaded active content ( or active content altogether). If you refer to exploitation of office without active content by eg buffer overflows , these are complex, big apps and probably to have undiscovered exploits. But this is not a commodity attack.
To cover these Exploit Guard ( to reduce the probability of exploit succeeding ) + WDAC for sponsors ( to reduce chances of privilege escalation ) + SRP ( to reduce what an exploited app can do from user space ). This lockdown is probably as good as it gets. We also have to consider that a document that’s meant to do a 0day without active content and also bypasses the other 3 mitigation layers, while entirely possible, is probably something that us home users don’t need to be worried about and I don’t believe there’s anything that can block an attack that’s so elaborate

It actually sounds to me like you and Andy are in agreement about how much MS Office can be locked down by means of native Windows policies.

 

[JM Safe]

Sometimes it's recommended to use Sandboxie Beta versions to reduce the possibility to encounter crashes and problems.

 

[Andy Ful]

Thanks @ Andy, I plan to block sponsors via WDAC when I get a free evening do you have a list of sponsors ?

I can’t agree regarding GPO and Office, it eg lets you block downloaded active content ( or active content altogether). If you refer to exploitation of office without active content by eg buffer overflows , these are complex, big apps and probably to have undiscovered exploits. But this is not a commodity attack.
To cover these Exploit Guard ( to reduce the probability of exploit succeeding ) + WDAC for sponsors ( to reduce chances of privilege escalation ) + SRP ( to reduce what an exploited app can do from user space ). This lockdown is probably as good as it gets. We also have to consider that a document that’s meant to do a 0day without active content and also bypasses the other 3 mitigation layers, while entirely possible, is probably something that us home users don’t need to be worried about and I don’t believe there’s anything that can block an attack that’s so elaborate

I think so. If you will add the above to the MS Office policies, then it will be OK. The dangerous attack vectors are also scripting attacks (JScript, VBScript, PowerShell, etc.), because they can use MS Office Application objects (Word.Application, Excel.Application) which are available when MS Office is installed on the system.

 

[davisd]

Sometimes it's recommended to use Sandboxie Beta versions to reduce the possibility to encounter crashes and problems.

Using beta versions of security software is ill-advised - security software should only be used as stable versions on production machines and the whole point of a beta is to find issues with a lesser-tested version, which should be run in testing environment e.g. virtual machine

 

[shmu26]

Using beta versions of security software is ill-advised - security software should only be used as stable versions on production machines and the whole point of a beta is to find issues with a lesser-tested version, which should be run in testing environment e.g. virtual machine

With Sandboxie, you often need to use the betas. They usually work better than the stable versions.

 

[davisd]

With Sandboxie, you often need to use the betas. They usually work better than the stable versions.

If one is going to use unreliable security software, then it beats the point of having any at all, period.

 

[Andy Ful]

If one is going to use unreliable security software, then it beats the point of having any at all, period.

You are right (generally). But, there are more software which has this issue. For example, Windows 10 is, in fact, a perpetual beta. The Sandboxie betas are usually better than the stable versions of many other applications. It is a kind of exception from the general rule.
Yet, you cannot be wrong if you avoid betas (even for Sandboxie).
Anyway, let's go back to the topic - Sandboxie is far away from SRP.

 

[notabot]

I think so. If you will add the above to the MS Office policies, then it will be OK. The dangerous attack vectors are also scripting attacks (JScript, VBScript, PowerShell, etc.), because they can use MS Office Application objects (Word.Application, Excel.Application) which are available when MS Office is installed on the system.

For these my plan was to block the scripting runtimes via WDAC but I want to think some more details so that it doesn’t hinder the software development experience

 

[notabot]

The nice thing with WDAC is that you can say block powershell execution when parent is chrome.exe . So the ideal setup for me is to run powershell unconstrained when developing but don’t allow an exploited instance of Chrome to run it.

Of course it gets more complex because exploited chrome may invoke powershell indirectly via other executables or services and sorting out this dependency graph requires the only thing life was not kind enough to give to me, free time </rant> But some point during February I should find the time to write a reasonable starting point for a WDAC policy

 

[Andy Ful]

The nice thing with WDAC is that you can say block powershell execution when parent is chrome.exe ...

I do not want to know which websites you dare to visit, If you are afraid of the malware escaping from the Chrome Sandbox.

 

[notabot]

I do not want to know which websites you dare to visit, If you are afraid of the malware escaping from the Chrome Sandbox.

Chrome has had remote exploits, it’s not invincible.

Chrome and email client are pretty much the only ways in. If I don’t trust a pdf I open it in Chrome so even for docs we go back to Chrome, it makes sense to seal the gates.

It’s mostly a paranoia exercise , I haven’t had an infection for 17 years or so if we exclude a Trojan planted by someone I gave my laptop to but this was not really security issue, this was a misplaced trust issue.

 

[SHvFl]

Chrome has had remote exploits, it’s not invincible.

Chrome and email client are pretty much the only ways in. If I don’t trust a pdf I open it in Chrome so even for docs we go back to Chrome, it makes sense to seal the gates.

It’s mostly a paranoia exercise , I haven’t had an infection for 17 years or so if we exclude a Trojan planted by someone I gave my laptop to but this was not really security issue, this was a misplaced trust issue.

If you believe that you can only be infected by chrome or the email client then isolate them with your prefered software and you are done. You already did 99.99% of the work.

 

[notabot]

If you believe that you can only be infected by chrome or the email client then isolate them with your prefered software and you are done. You already did 99.99% of the work.

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 )