Parental Controls as an SRP for Windows 7 Home users

Could someone test the LNK POC against Parental Controls? (on an unpatched Windows of course)

ssj100 wrote:

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).

Yeh, I'm with you on that. I've read enough over the years to know how strong LUA+SRP is, and I've seen a lot of threads like that full of misinformation. The only doubt in my mind about the Parental Controls approach is how DLL's are handled. That's the bit I can't get to grips with fully. I need to sleep on it

Since there is a bit of interest now, I've decided to make an effort to test this Parental Controls mechanism. If/When I get it running, I'll make sure to test it against the "LNK POC" (which would once and for all put the DLL issue to rest).

Anyway, more later, but I suspect I'll need some guidance regarding "tweaking/optimising" the Parental Control configuration so it can provide stronger protection.

Sadeghi85 wrote:Could someone test the LNK POC against Parental Controls? (on an unpatched Windows of course)

I would if I could, but at this time, this laptop is the only machine I have at hand and I need it for my work.
P.S.: If I understand what you are talking about, then disabling the Web Client service would be preferable to any anti-executable and/or behavior blocker, right? As far as I know, WebDAV (Web Distributed Authoring and Versioning) is mainly to blame for this vulnerability. When MS gives a workaround, I usually stick to it, even when a patch has already been issued. My link icons are still blank and I actually like it that way. From what I understand, the patch hasn't really solved the problem and people are still at risk. I'll try to find confirmation for that statement.

Paul

p2u wrote:

Sadeghi85 wrote:Could someone test the LNK POC against Parental Controls? (on an unpatched Windows of course)

I would if I could, but at this time, this laptop is the only machine I have at hand and I need it for my work.
P.S.: If I understand what you are talking about, then disabling the Web Client service would be preferable to any anti-executable and/or behavior blocker, right? As far as I know, WebDAV (Web Distributed Authoring and Versioning) is mainly to blame for this vulnerability. When MS gives a workaround, I usually stick to it, even when a patch has already been issued. My link icons are still blank and I actually like it that way. From what I understand, the patch hasn't really solved the problem and people are still at risk. I'll try to find confirmation for that statement.

Paul

I'm installing Windows 7 (Professional) back into my VM as we speak! So hopefully I'll be able to do some testing soon.

With regards to the "patching" of the LNK exploit:

A: "explorer.exe" method (browsing the files)
B: "rundll32.exe" method (manually executing the shortcut)

As far as I understand it, Method A was patched, but Method B wasn't, so I suppose you're right.

ssj100 wrote:
I'm installing Windows 7 (Professional) back into my VM as we speak! So hopefully I'll be able to do some testing soon.

Great stuff! Looking forward to your findings

Okay, it appears that Parental Controls (default configuration) is bypassed by the LNK POC (both methods). Are there any specific configurations that could mitigate this?

However, I can confirm that Parental Controls blocks ".bat" and ".exe" execution. I'm not sure if it directly blocks ".msi" execution (since the error message I received also occurs by simply running as a Limited User).

ssj100 wrote:Okay, it appears that Parental Controls (default configuration) is bypassed by the LNK POC (both methods). Are there any specific configurations that could mitigate this?

I think that's part of the problem - you can't really configure it. I need to read up again on the LNK POC to understand precisely how it works. Are there any other POCs that you think are worthy of testing against it?

Basically the LNK POC exploits a Windows vulnerability which allows a DLL to be loaded spontaneously. As you already suggested, Parental Controls does not block DLL loading.

The only other exploit worth testing that I can think of right now is this:
https://ssj100.forumotion.com/t257-dll-exploit-testing#2011

However, it's pretty much the same as the LNK POC exploit - I'm fairly sure it will bypass Parental Controls too.

Thanks for testing, SSJ. Perhaps there is a setting or registry key to enable DLL blocking in Parental Controls? I've heard Sully's PGS doesn't work on Windows 7, Parental Controls would be a good alternative if it could block DLL loading.

Yes, I wouldn't be surprised if there was some registry tweak that allowed DLL blocking to take effect.

Regardless, this is another reason why I'm glad to be using Windows XP Professional as my primary OS - there are so many variables and undiscovered/unclarified issues with Windows 7's built-in security mechanisms at this stage. It's nice to be an observer and experiment around with it, while knowing that my XP system is tried and true. No wonder Microsoft are supporting XP until 2014 (and ceasing support for Windows 7 Ultimate a few months after that haha).

Anyway, let's wait and see what p2u finds with regards to this DLL blocking with Parental Controls.

ssj100 wrote:Anyway, let's wait and see what p2u finds with regards to this DLL blocking with Parental Controls.

Please don't forget that I'm on Vista Home Basic. UAC (Parental Control depends on it) is more rigid on Vista than it is on Win7, for example.

With Parental Controls I didn't do anything special. The trouble in evaluating the situation is in all my settings (not Parental Control settings, but system settings). I disabled and removed so much (from the 124 services only 20 or so run, for example) that I don't even remember myself what exactly. I remember the mitigation of the .lnk problem was to remove the reg key

Code:

HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler

but this means that all .lnk icons will be blank. You should also disable the Web Client service and block outgoing SMB in your firewall. That's all I remember right now. I'll be back with some more news soon.
P.S.: All the details about this vulnerability (binary planting) can be found here.
And here are the attack vectors, most of which have been either removed or disabled on my system. Also: it's important to realize that not the loading of some dll itself is the problem (that's something the system is supposed to do when asked), but its payload, i.e.: what will happen after it gets into memory? Probably my settings are such that the effect is zero. Might even be my Default Deny firewall settings when I come to think of it...
P.S.2: It is also important to note that with all those FUD-"threats" most of the time you are 1) being lied to or 2) not given the whole truth. From my experience I can say that most threats can be handled with very simple measures and for free. Setting all security zones in IE to 'high' for example (especially if you don't use that browser yourself) is a very effective measure. And probably disabling cmd for the limited user makes sense anyway, huh?

Paul

One little test with Parental Controls. It seems to check not only file headers in files you want to launch, but also pure extensions, even if the file is void. Besides, when you check with Process Explorer, the process doesn't even start, as you can see so often in many security solutions; the file is just blocked from launching.

First I created this really dreadful Trojan:



Then renamed it, but even if there is no code, the file is still blocked as an "executable" not in the whitelist:



But then I suddenly thought: "Oh no, this can't be true. It only monitors file extensions". Then I decided to launch leaktest, but with the file extension renamed to .jpg launched by cmd (temporarily allowed):



Successfully blocked.

Paul

Thanks p2u. I think that pretty much confirms that Parental Controls is the equivalent of SRP without library/DLL blocking.

ssj100 wrote:Thanks p2u. I think that pretty much confirms that Parental Controls is the equivalent of SRP without library/DLL blocking.

Ok I was reading at wilderssecurity and post #66 by LUCY said you can enable DLL blocking in Parental controls.

http://www.wilderssecurity.com/showthread.php?t=290083&page=3

Quote from LUCY:

"SRP... Minus DLL restriction.
To get this further restriction, it is necessary to get into the registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers, and modfy the TransparentEnabled string to 2 (include all files in elevation - 1 indicates that DLL are excluded)."

Troy45 wrote:To get this further restriction, it is necessary to get into the registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers, and modfy the TransparentEnabled string to 2 (include all files in elevation - 1 indicates that DLL are excluded)."

Thank you for reminding me; mine was actually set up like this, but I forgot about it.

Paul

Excellent. This means there is no excuse not to use "SRP" with Home (and below) editions of Windows haha.

It's a real pity I didn't have this information in an exchange with a member on the COMODO forums about a year ago - he kept using the argument of Windows Vista/7 Home Premium users not having the option to use LUA + SRP. Clearly he was wrong.

I was right though!

Sadeghi85 wrote:Perhaps there is a setting or registry key to enable DLL blocking in Parental Controls?

ssj100 wrote:Excellent. This means there is no excuse not to use "SRP" with Home (and below) editions of Windows

By the way, this policy also applies to shortcuts (.lnk) that point to already allowed executables; they should be manually overridden because they are in a different location.

Paul

p2u wrote:By the way, this policy also applies to shortcuts (.lnk) that point to already allowed executables; they should be manually overridden because they are in a different location.

Good point. How would one do this?

ssj100 wrote:

p2u wrote:By the way, this policy also applies to shortcuts (.lnk) that point to already allowed executables; they should be manually overridden because they are in a different location.

Good point. How would one do this?

When you double-click such a shortcut and you get the "Not allowed" alert, there is an override link to contact the admin. There you enter the admin password. You'll get a notification that this executable is already in the white list. Click "OK" and that's it.
P.S.: This doesn't happen with all shortcuts by the way. I only had it with regedit32 and sigverif from the Windows folder (I have schortcuts to those in a special "Security" folder on my desktop). It's just something to keep in mind. If it happens, one should not panic or disable Parental Controls.

Paul

Well I did some testing when I have SRP enabled like http://www.mechbgon.com/srp/index.html . The registry value at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers TransparentEnabled is set at 2. But if I turn off SRP it will change to a 0. If I turn on Parental Controls that TransparentEnabled will still be at 0. So to enable you need to change that value to a 2. So just to be clear for dll checking 2 is ON and 0 is OFF.

Just want to tell you what i have found.

Using Windows 7 Professional 32 bit

Troy45 wrote:if I turn off SRP [...] If I turn on Parental Controls [...]

Hmm... So you have both SRP and Parental Controls? Parental Controls seems to be more rigid; a lot of stuff from the Windows folder is not allowed by default. For example, I had to allow sigverif.exe (for a signature check of installed programs) from the System32 folder separately. I still don't have a clear idea of what exactly is allowed from the Windows folder, and what not...

Paul

Yes Windows 7 Professional has both. I'm not using both at the same time. I was just testing to see that if registry "TransparentEnabled" value changes when using SRP. It does.

It seems the C:\Windows\Tasks directory will let you execute programs such as Process Explorer. It's not restricted. hmm

I'm real new to SRP . Just started using it. Was just using a LUA and Sandboxie.

Troy45 wrote:It seems the C:\Windows\Tasks directory will let you execute programs such as Process Explorer. It's not restricted. hmm

EDIT: C:\Windows\Tasks directory will of course allow you to execute programs - you've white-listed the entire C:\Windows directory. However, keep this in mind:
http://www.wilderssecurity.com/showpost.php?p=1658981&postcount=31

Those 14 exceptions are allowed to be written to. Therefore, malware could potentially write to either of those directories and be free to execute.