New to LUA + SRP

I've never had a chance until recently to try SRP. Now, my current Laptop has Win XP PRO.

I was surprised how easy it is to configure - just two clicks to set:

• Enforcement
  
  
• Security Levels

I've tested using numerous attack vectors encountered in the wild, and nothing gets through because

• nothing can execute from within User Space
  
  
• nothing can write to System Space

regards,

-rich

 

Try demoting an admin account to user level, then try if certain directories being owned by the now demoted user have any bearing on your results. I believe many people downgrade thier admin to user level when setting up this way.

Sul.

 

I see no reason to do that.

-rich

 

+1

It befuddles me to this day why there are people who even consider this absurd approach. It's so simple: once an administrator account is created as part of the Windows installation, it should be left alone as administrator, never to be converted to anything less.

 

Welcome to the first-party security club.

 

I wouldn't say there are more and more people using SRP, but I am pretty sure that most people who are eligible to such a security strategy would be amazed how restrictive, yet simple it is to maintain and use.

There is a whole group of users who would beg for it if they knew what it does OR who wouldn't mind having it set from purchase.

Little companies of few computers, people not really computer knowledgeable...

It might seem complex at first sight, but what a relief when it comes to manage a network set up with SRP.

It's time to link to a Mechbgon's webpage I "rediscovered" lately:
http://www.mechbgon.com/build/security2.html
Everything is in there.

 

Welcome Rmus.

Maybe someday you'll also have the opportunity to take AppLocker for a test drive.

 

aigle is doing some neat tests of Stuxnet against HIPS products, and the topic of spoofed file extensions came up. So I thought I would test SRP.

One common use of this technique has been seen in USB exploits back to Conficker in 2008, where spoofing a DLL was one trick.

So I used EXE, DLL, VBS both with the normal file extension and a spoofed one, running a command prompt from the USB drive. This is a better test than clicking on a file, such as VBS or EXE, in which case Windows File Associations regulate the action, whereas in a command prompt, Windows Files Associations don't come into play.

This highlights the weakness of products like ScriptSentry, ScriptDefender, and the old WormGuard, which are easily bypassed when using wscript.exe to run a VBS file, for example.

Not so with SRP. I have no special configurations - just checking "All Software Files" in the Enforcement Properties.

EXE

SRP Off -- First the real extension, then the spoof:




SRP On


DLL -- Starts the Microsoft HTTP Mail Simple MAPI

SRP Off




SRP On


VBS -- Finjan VBS test file

SRP Off




SRP On


I also did the VBS test using an autorun.inf file:

Code:

[autorun]
shellexecute=wscript /e:vbscript "finjan.vbs"

Code:

[autorun]
shellexecute=wscript /e:vbscript "finjan.dfg"

SRP On


The best part of this security is that it is Default-Deny. If an exploit attempts to run, I don't want the user to have the option to Permit!

regards,

-rich

 

@ Rmus

Default-Deny =

I've had ScriptDefender installed since 98SE days & it works At the same time i also renamed ALL copies of wscript.exe so that vector won't work either

 

Applocker should work just as well but with added flexibility...

What features have changed from Software Restriction Policies?

That said, if only SRP is available, I would highly recommend using it in place of any HIPS software available.

 

Why?

regards,

-rich

 

Because it's already built into the O/S, so no possible instability or conflict issues, as well as no (possibly confusing) pop-ups to answer.

 

Unfortunately, SRP requires the PRO edition of the OS, which a lot of people do not have.

regards,

-rich

 

but it is available via Parental Control for Home Premium edition and below.

https://www.wilderssecurity.com/showthread.php?t=297834

 

Thanks, I forgot about that, but not available on Win XP or I might have tried that on my old laptop!

regards,

-rich

 

Re SRP & XP Home etc.

Found some info that "might" be useful ?

 

Here is something SRP won't do:



Anti-Executable's Copy Prevention blocks extracting from a ZIP file (copying to disk) unauthorized executables (non-white listed).
Useful in some environments. Now, the executable couldn't run anyway, even if extracted, but an Administrator
might not know that another user had extracted some executable that just sits wherever it was extracted.
AE's use in corporate situations might find that feature attractive.

More practical, is this scenario where a drive-by exploit downloads (copies) a spoofed executable to disk, then renames it and puts it in a temp directory, then executes it.

This is the code:



1) test.htm, a spoofed EXE file is cached to disk

2) it's renamed to svchost.exe and copied to the temp directory

3)then executed

Here is SRP's alert: it has blocked svchost.exe from executing from the temp directory:



Here is AE2's alert - it has blocked the file, test.htm, from writing (copying) to disk in the first place:



While both prevent the malware from executing, I think AE2's Copy protection is rather neat! There are no files to clean up afterward.

Having said that, in all the years I've used AE, I've never gotten an alert (except when testing in-house, or knowingly going to malware sites using IE6, which I've kept unpatched so it will run exploits.)

Reasons why no alerts:

1) Alternate browsers (I use Opera) don't have exploits in the wild against a browser vulnerability, which tends to be quickly patched

2) Disabling of Plugins prevents the browser from triggering exploits against PDF,Java, and Flash, for example

3) Policies and Procedures in place prevent USB exploits

4) Properly configured firewall prevents exploits such as Conficker.A

There's really not much else to consider in my own situation (as far as remote code execution exploits).

Which makes me wonder whether anti-execution protection is even necessary here...

regards,

-rich

 

Thanks. I followed for a while the various threads here at Wilders in the past, but soon lost interest.

I didn't want to have to do so much configuration and tweaking on my XP HOME edition. AE is set-and-forget! That's for me (I'm lazy!)

That's why I'm pleasantly surprised how easy and simple the full-blown SRP is to use and work with, now that I have a XP PRO edition!


regards,

-rich

 

On XP Home it is much easier to implement using Sully's PrettyGoodSecurity, it adds SRP in a fashion which will be very familiar for those having used XP Pro (also works on Vista) http://mrwoojoo.com/PGS/PGS_index.htm

To add the security tab of XP Pro on XP Home also, use Fajo's extention, download from http://www.fajo.de/main/en/software/fajo-xp-fse You can add an extra layer to for instance your data directories to add an deny execute, see picture.

RMUS when you use the 1806 trick, the deny execute starts even earlier (with IE9 no executables are allowed to download, with Chrome you are allowed to download but not execute). The nice thing when you use windows ZIP, it will not extract executables from downloaded zip-files when 1806 has value '3', see these post for 1806 reg files

- use the reg files Drive_by_deny and Drive_by_warn ( https://www.wilderssecurity.com/showpost.php?p=1852024&postcount=5 )
- message (the blue one https://www.wilderssecurity.com/showpost.php?p=1852018&postcount=3 )
- how to unblock (https://www.wilderssecurity.com/showpost.php?p=1852017&postcount=2 )

Now why would you want the additional layers?
I have some friends who want to run admin and refuse to use LUA, so I add:
a) Sully's PGS and let all their internet facing software run as basic user
b) set a hard default deny through XP FSE (take away the rights to traverse folders and execute to My documents), this is more robust solution than SRP. I also do this for the download directory of Chrome.
c) add the 1806 trick, so malware moved to Temp directories in User Profile still have a second level block
d) decent freeware AV ( prefer Avast)

Now they can run as admin, but all internet facing software runs as LUA (PGS), they are protected from drive by's (XP FSE) and accidental execution of malware (1806 block). The 1806 trick also closes the non-protected directories gap of XP, Vista and Windows7 when running programs with medium rights on an admin account (so it would also should help people who converted an admin account to LUA, to close the ownership gap)

It is not as easy and straight forward, but a lot more safe than running Admin.

Why not use Surun instead?
All of the (program or reg file supported) changes are registry hacks, so it offers best compatibility. I used Surun before and personally like it very much. Only one friend said he messed up his operating system with surun. I personally think it was his fault not Surun, but the combi PGS + Fajo XP FSE + 1806 has proven to be monkey proof. I still lean to advising Surun in stead of the registry hacks I outlined, when someon has normal PC skills (e.g. have the common sense to maintain an image and data back up)

 

Rmus,

if you simply use a default SRP, you can use a reg file as shown here for example:
https://www.wilderssecurity.com/showthread.php?t=200772
There should be an update from Tlu near the end providing a by-default reg file for Xp.

This is a one time shoot and forget

 

Thanks, but I've got XP PRO.

Kees, Kees! -- I don't know what 1806 is, and I get dizzy trying to follow all of your explanations!

A bit tongue-in-cheek, but seriously, if I had to implement all of that to be safe, I would rather run with nothing and do a re-image avery night!

You say, the "deny-execute" starts earlier. How much earlier than what I've shown in my post #8? I used all of the common exploit attack vectors and SRP with no fancy tweaks blocks everything Default-Deny. Why do anything more!

regards,

-rich

 

Old to LUA

After testing with SRP and observing that nothing can intrude (see my post #8 ), I no longer see it necessary to run as LUA, since all it seems to provide is denying write access to System directories, which can't be accessed unless something intrudes, which SRP prevents (see my post #8 ).

(That paragraph is called a loop-around!)

There is another reason -- one of status!

I see that LUA is used to describe "Limited User Account" and "Least-privileged User Account."

Well, I don't think of myself as a Limited or Least-privileged User.

So, unless I've missed something, I'm back to my regular account which is an Administrator account.

(I'm the only user on my computer)

regards,

-rich

 

Re: Old to LUA

Unless you have some sort of UAC in place, make sure SRP is applied to all users, not excluding admins.

 

But, if admins are also prevented from executing... then how would they execute anything?

It would be like denying myself (as an admin) in AppLocker, and use UAC to install/execute. It wouldn't work.

Or, am I missing something

The beauty of SRP/AppLocker is to use a limited user account/standard user account and allow the administrator account to do its thing. That's my opinion, anyway.

 

If you don't apply it to admin, then there is no protection. You can still execute by moving files to whitelisted directories, and/or changing the rules.