Parental Controls as an SRP for Windows 7 Home users

I see on http://www.mechbgon.com/srp/ that he suggests using Parental Controls as an alternative to SRP for Windows 7 Home users. What do people think of this? Is it as strong as 'proper' SRP? Has it got any usability flaws? Thx.

Scoobs72 wrote:I see on http://www.mechbgon.com/srp/ that he suggests using Parental Controls as an alternative to SRP for Windows 7 Home users. What do people think of this? Is it as strong as 'proper' SRP? Has it got any usability flaws? Thx.

I use it myself on Vista Home Basic and am very satisfied with it. It not only blocks .exe and .bat files, but also unknown .dll, .bin, etc. I don't know how good it will be against the dll-shortcut-test that was done here, but since I have Web Client service disabled, this isn't much of a threat anyway.

Of course, you should take care of cmd and script hosts (rename them is an option), because by default they are allowed, and when you white-list, there is no way to block them with Parental Control only.

Parental Control can only be used on limited accounts, depends on UAC to work and may not work if you activate it when you have already some kind of HIPS or behavior blocker installed. I had this problem when I was playing with Sunbelt's firewall. You should first activate Parental Control and then install other blockers. If you like, I can post some screenshots that show its reaction to all kinds of 'threats'. Some of those may show notifications in Russian, but I think you'll be able to evaluate what you see anyway.

Paul

p2u wrote:
I use it myself on Vista Home Basic and am very satisfied with it. It not only blocks .exe and .bat files, but also unknown .dll, .bin, etc. I don't know how good it will be against the dll-shortcut-test that was done here, but since I have Web Client service disabled, this isn't much of a threat anyway.

Of course, you should take care of cmd and script hosts (rename them is an option), because by default they are allowed, and when you white-list, there is no way to block them with Parental Control only.

Parental Control can only be used on limited accounts, depends on UAC to work and may not work if you activate it when you have already some kind of HIPS or behavior blocker installed. I had this problem when I was playing with Sunbelt's firewall. You should first activate Parental Control and then install other blockers. If you like, I can post some screenshots that show its reaction to all kinds of 'threats'. Some of those may show notifications in Russian, but I think you'll be able to evaluate what you see anyway.

Paul

Yes, that would be interesting to see. How exactly do you deal with cmd and scripts hosts?

Scoobs72 wrote:How exactly do you deal with cmd and scripts hosts?

There are several ways of disabling them. You can find them through Google. Cmd, for example:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
"DisableCMD" = "1" (that's a DWORD parameter)
I'll be back tomorrow with some screenshots and some more info. I have to go and kill some rootkits on my neighbor's system right now. See you later!

Paul

SSJ, could you give the parental controls approach the 'once-over' and let us know what you think?

Hi Scoobs, I think I might leave it to p2u for this one. Why? Well, simply because I'm not that familiar with Windows Vista/7 (I'm still very happy running Windows XP on my personal computer, and have no intention of upgrading to Windows 7 until the year 2014 when Microsoft ceases updating XP) and I'm certainly not familiar with "Parental Controls".

However, I will most likely be reading more into this in the near future, and perhaps I can then contribute a bit. Cheers.

p2u wrote:I'll be back tomorrow with some screenshots

As promised: a little boring, just like AE and similar anti-executables.
TDSS Rootkit blocked: imagepost.ru/images/379/TDSSRootkit.png
Trojan Fake Flashplayer (1) blocked: imagepost.ru/?v=379/TrojFlash1.png
Trojan Fake Flashplayer (2) blocked: imagepost.ru/images/379/TrojFlash2.png
Trojan Fake Flashplayer (3) blocked: imagepost.ru/images/379/TrojFlash3.png
Winlocker Flashplayer: imagepost.ru/images/379/WinlockFlash.png (this is one of a huge series, which terrorized Russia last year, written especially against a flaw in KIS. It locks you out of Windows until you pay the ransom, and even after that... )
Keylogger blocked: imagepost.ru/images/379/keylog.png
Jumper leaktest (already allowed) trying to create a dll - blocked: imagepost.ru/images/379/Jumper.jpg
Wallbreaker leaktest (already allowed; third leaktest from the set) trying to create a random bat file - blocked: imagepost.ru/images/379/Wallbreaker3.jpg

When you have OpenOffice installed and you allow all of its executables, that's still not enough to work with it:
Program Files/OpenOffice.org 3.1\program\soffice.bin is blocked at startup in a limited account, so you'll have to allow that one too.

P.S.1: Weaknesses:
1) Parental Control uses paths, not hashes
2) The allowed programs can be found in the registry for anybody to read.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Parental Controls\Users\User-ID\App Restrictions
P.S.2: Setting all security zones in IE to 'High' gives you additional protection against exploits. Local scripting (on the computer itself, not browser scripting), for example, will be virtually impossible or very limited. The same goes for .bat-execution.

Paul

Thanks Paul, very interesting. While quite not as bullet-proof as a properly configured SRP (with scripting, command prompt execution etc prevented as well as blocking access to the writable c:\windows folders), Parental Controls does appear to cover 99%+ of the requirements. SRP for free without upgrading to Pro versions of Windows!

Scoobs72 wrote:Parental Controls does appear to cover 99%+ of the requirements.

The configuration of your browser and all other programs that connect actively to the Internet should be your main concern. I will show later in another topic how I configured my browser - Firefox. From my signature you can probably guess that I take these things very seriously. When I go to domain A, I really don't want ANYTHING unexpectedly loading from domain B etc.

Paul

All my browsing and email is run under Sandboxie, so I don't need to be concerned about exploits, drive-by's etc

Interesting stuff p2u - showing us that we're all wasting money paying for security software haha. Happily for me (and others), Sandboxie's license is life-time!

p2u, could you elaborate on why "path" is weaker than "hash"? My own SRP rules are based on path rules and on the concept that where you can write, you can't execute, and where you can execute, you can't write. I feel this is stronger than "hash" rules, as it's not impossible (although it virtually is) to code a malicious file with the same hash.

On the other hand, it's impossible to bypass the path rules unless you use a privilege escalation exploit (or a macro etc). But then this would bypass hash rules (and publisher rules etc) too.

What do you think?

ssj100 wrote:What do you think?

Sorry for the delay. I was just too busy.

Of course your are right when the block strategy is 'Default Deny'.

Parental Controls is even better than I thought. I've been playing with it a little more, and all the tricks from the 'bypass book' fail. As a matter of fact and without checking first, I made the assumption that since the blocking feature is advertised as SRP, the whole Windows folder would be included in the whitelist, but that doesn't seem to be the case. When I launch something with the Runas trustlevel-"unrestricted" switch, it shows me the usual Parental Control notification that Runas.exe is not in the whitelist and that I should contact the Administrator, which is v-e-e-e-r-y good news. For now, I think that the only tools available from the Windows folder are the standard ones from the All Users Start menu folder. I have not found a complete list of exemptions on the policy.

PS.1: Readers should keep in mind, that my comments are based on what I see on Vista.

PS.2: A strong password for the admin account is a must, since by default there is an overriding feature in the "blocked" notification ("contact the admin"). When you click on it, you get the usual UAC pop-up to enter the Admin password. The overriding feature can be disabled through the registry though:

Code:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Parental Controls\Users\User-ID

"Override requests on" to "0".

Paul

Sounds great for those who can't use SRP/AppLocker.

p2u wrote:For now, I think that the only tools available from the Windows folder are the standard ones from the All Users Start menu folder. I have not found a complete list of exemptions on the policy.

There certainly seems to be something going on that is a bit more complex than a simple "allow everything from C:\Windows to execute. The c:\windows\ehome and c:\windows\speech\common folders are specifically whitelisted in Win 7. However regedit.exe can be launched, which is not in the Start Menu folder....so it's a bit of a mystery at the moment. Why whitelist ehome and the speech recognition app but nothing else in c:\windows?

Edit: Just tried Runas.exe and as you say, it cannot execute. However apps like calc.exe in the same System32 folder launch fine. The permissions appear to be the same between these two .exe's, so do we have a selective blacklisting of files within the policy?

Scoobs72 wrote:Why whitelist ehome and the speech recognition app but nothing else in c:\windows?

I'll contact David Benett from the MS Parental Control Team. I was mistaken when I only mentioned the startup menu. There is also some stuff in the Control Panel with access for basic users (also links to the Windows folder). There must be some kind of mysterious combination that can be executed but with the 'Basic User' parameter. I have a hunch that it is impossible to elevate some of those...
Additionally (from what I read), the default DOCUMENTED exemption list seems to be as follows:

Code:

App Exmemption list:
C:\Program Files\Windows Media Player\Wmpconfig.exe
C:\Program Files\Windows Media Player\Wmpshare.exe
C:\Program Files\Windows Media Player\Wmpnetwk.exe
C:\Program Files\Windows Media Player\Wmpsideshowgadget.exe
C:\Program Files\Windows Media Player\wmplayer.exe
C:\Program Files\Windows Media Player\Wmpenc.exe
C:\Program Files\Windows Media Player\Wmlaunch.exe
C:\Program Files\Windows Media Player\Wmpnscfg.exe
C:\Program Files\Windows Media Player\Wmprph.exe

Windows (readonly) App Exmemption list:
C:\Windows\eHome\MCUpdate.exe
C:\Windows\HelpPane.exe
C:\Windows\eHome\ehrec.exe

Paul

Found some info over at MSDN:
- Also referred to as General Application Restrictions (GAR).
- Off by default. If turned on, it only allows a controlled user to run applications approved by an administrator, with reasonable exceptions.
- UI provides a list of program names with corresponding paths, each with an allow checkbox. A browse button is also provided.
- Implemented using Software Restriction Policies (SRP), also known as SAFER:
- Prevents execution from all media (USB keys, floppy disks, and so on).
- Uses path rules to specify programs allowed to run.
- NTFS ACL write permissions are revoked from anything allowed for the controlled user to run.
- If blocked and subsequently overridden to allow, the application must be relaunched manually.
- Exceptions include:
- All binaries required for a basic subset of Windows to function.
- All executable files that register by using an API are to be allowed for a given user.
- Games specified as being allowed under Games Restrictions.
- Note that the RunAs command is blocked by design for a user when GAR is on.

Scoobs72 wrote:Found some info over at MSDN

This? Parental Controls In-Box Restrictions and User Interfaces
Unfortunately, it's not very explicit; I'd rather say: it's a bit obscure...

Paul

p2u wrote:

Scoobs72 wrote:Found some info over at MSDN

This? Parental Controls In-Box Restrictions and User Interfaces
Unfortunately, it's not very explicit; I'd rather say: it's a bit obscure...

Paul

Yes, that's the one. Not particularly useful. There's some testing in an old post over at Wilders which finds that Parental Controls is basically SRP with the Enforcement Properties Setting of "All software files except libraries (such as DLLs)". So for example an infected USB stick could use Autorun.inf to launch Rundll32.exe to load a malware-infested DLL.

Scoobs72 wrote: So for example an infected USB stick could use Autorun.inf to launch Rundll32.exe to load a malware-infested DLL.

...which means that Parental Controls SRP could be bypassed quite easily?????

Scoobs72 wrote:

Scoobs72 wrote: So for example an infected USB stick could use Autorun.inf to launch Rundll32.exe to load a malware-infested DLL.

...which means that Parental Controls SRP could be bypassed quite easily?????

I don't think so really, but I disabled all autoplay handlers in the Control Panel and applied the following reg key:

Code:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

which gets rid of any autorun.inf threats. Besides, the service Shell Hardware Detection (responsible for any autoplay events) is disabled. If you don't have any printers or scanners that depend on this service to work, I would advise you to do the same.
P.S.: Actually I was told, that autorun is disabled on Win7. Isn't that true anymore?

Paul

p2u wrote:
I don't think so really, but I disabled all autoplay handlers in the Control Panel and applied the following reg key:

Code:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

which gets rid of any autorun.inf threats. Besides, the service Shell Hardware Detection (responsible for any autoplay events) is disabled. If you don't have any printers or scanners that depend on this service to work, I would advise you to do the same.

Paul

Yes, disabling the infection vector would be the way to tackle this. Currently I have autorun enabled but force run any removable drives in Sandboxie with start/run restrictions, but it would be just as easy to do what you've posted. It's a shame there isn't a way to include DLLs as part of the the SRP...but I guess that would be Microsoft giving away a key feature of Professional for the price of Home Premium

Scoobs72 wrote:Yes, disabling the infection vector would be the way to tackle this. Currently I have autorun enabled but force run any removable drives in Sandboxie with start/run restrictions, but it would be just as easy to do what you've posted. It's a shame there isn't a way to include DLLs as part of the the SRP...but I guess that would be Microsoft giving away a key feature of Professional for the price of Home Premium

1) As you could see in one of my screenshots earlier, Vista's Parental Controls blocks (or at least hampers) NEWLY CREATED, unknown dll's. I think the same applies to Win7. The trick bktII shows with user32.dll doesn't prove much, since (as far as I know) system dlls have a hash rule, so you can use them in any path. If he showed me a real dll exploit with an infection following, I would be convinced, but I think you need admin rights to accomplish that. On my machine, if the admin (that's me) installs something and puts it in autostart, but forgets to allow me to use it, it is blocked when I log in (I've seen that more than once).
2) I just inserted an infected flash drive. As a limited user, I couldn't even install the device itself. I had to switch to my admin account, but you should remember that Parental Controls cannot be blamed for what happens there; it just won't work for administrators. I installed the device. No nasties of any kind launched (checked with Process Explorer). I went back to the limited user account and opened the drive. Nothing happened and I was able to examine the contents of the device.

Paul

p2u wrote:
1) As you could see in one of my screenshots earlier, Vista's Parental Controls blocks (or at least hampers) NEWLY CREATED, unknown dll's. I think the same applies to Win7. The trick bktII shows with user32.dll doesn't prove much, since (as far as I know) system dlls have a hash rule, so you can use them in any path. If he showed me a real dll exploit with an infection following, I would be convinced, but I think you need admin rights to accomplish that. On my machine, if the admin (that's me) installs something and puts it in autostart, but forgets to allow me to use it, it is blocked when I log in (I've seen that more than once).
2) I just inserted an infected flash drive. As a limited user, I couldn't even install the device itself. I had to switch to my admin account, but you should remember that Parental Controls cannot be blamed for what happens there; it just won't work for administrators. I installed the device. No nasties of any kind launched (checked with Process Explorer). I went back to the limited user account and opened the drive. Nothing happened and I was able to examine the contents of the device.

Paul

I still can't fully get my head round this. There's an old thread on Wilders here: http://www.wilderssecurity.com/showthread.php?t=231106 which tests out Conficker.b. Haven't read through it all yet, but there's some testing against SRP in there.

Scoobs72 wrote:I still can't fully get my head round this. There's an old thread on Wilders here: http://www.wilderssecurity.com/showthread.php?t=231106 which tests out Conficker.b. Haven't read through it all yet, but there's some testing against SRP in there.

Yes, I know that thread. I didn't manage to infect my system, so sorry. I think they were testing SRP on an admin account right? Conficker won't run in a limited account (can't write to system32). If you have autorun completely disabled then this is a no-threat, even in an admin account. Besides, you should keep in mind that this is not 2006 anymore. Even SRP has gone through some drastic changes on Vista and Win7. I'll have to find something in English on that topic, but I read a Russian discussion, where the author stated that numerous things on Vista/Win7 can't even be elevated from a limited account, even if you know the admin password.

[Off-topic]: When I tested it, Executable Lockdown (which is mentioned in that topic) blocked executables that were not on the whitelist as long as the name of the folder used standard latin characters. It didn't block those same executables, however, if you put them in a Russian folder. [End of off-topic]

Paul

Scoobs72 wrote:I still can't fully get my head round this. There's an old thread on Wilders here: http://www.wilderssecurity.com/showthread.php?t=231106 which tests out Conficker.b. Haven't read through it all yet, but there's some testing against SRP in there.

I would throw caution at what you read on any forum discussing SRP (including this one haha) - there is simply so much mis-understanding about it (hence the thread solely on it), and I'm not blaming or looking down at anyone - I've personally struggled in the past too (and perhaps present haha).

When I was implementing SRP (and I'm talking about a "proper" SRP here) for the first time, I spent hours reading about potential bypasses and came across similar threads - at one stage, I was almost convinced that SRP was next to useless! After analysing things myself and further reading, I realised that this was simply not true. The only thing that can bypass LUA + SRP (as far as I'm aware) are those "macro" POC's demonstrated by Didier Stevens. All other claimed "bypasses" are the result of mis-understanding and/or mis-configuration.

Anyway, the Wilders thread Scoobs has quoted has some significant mis-information in it (or at least mis-direction?), especially when it comes to SRP. Here's an example:
http://www.wilderssecurity.com/showpost.php?p=1390330&postcount=74
Unfortunately, Kees1958 confuses the issue here (perhaps unintentionally?) and borders on revealing that he does not understand the LUA + SRP concept. As you can see, because of this, Reimer starts doubting the power of LUA + SRP. However, the fact is that while you can generally write to USB drive folders, you certainly cannot execute from them with LUA + SRP applied, as zopzop discovered here:
http://www.wilderssecurity.com/showpost.php?p=1390373&postcount=77
Therefore, it's a bit odd/confusing to suggest adding "a No execute SRP to RECYCLER and TEMP dirs". What would be the point of this? Thankfully, posters like tlu rescue the thread at this point:
http://www.wilderssecurity.com/showpost.php?p=1390382&postcount=79