Is Limited User Account enough? Not really...

No I didn´t forget about that , but malware, either it´s binary code or scripts, have to execute in its initial stage so it´s part of no.2 in SRP's file extension list.

How can any code be malicious and cause damage if it can´t execute, will not execute because some part of the code is crippled or the target for the codeinstruction is missing?

Using Windows own policy restrictions is a very powerful and straightforward way of achieving a high degree of security. However, nothing is 100 percent for certain, but you can at least minimize the damage using this type of damagecontrol since it doesn´t alter the vital areas of your system.

It stops every file extension that you designate, but I don´t know about its capacity of analysing the scripts, in case of injections etc. By the way, these are the extensions I´m currently blocking:

.ADE,.ADP,.BAS,.BAT,.CHM,.CMD,.COM,.CPL,.CRT,.EML,.EXE,.HLP,.HTA,.INF,.INS,.ISP,.JS,.JSE,.MDB,.MDE,.MSC,.MSG,.MSI,.MSP,.MST,.OCX,.PCD,.PIF,
.REG,.SCR,.SCT,.SHB,.SHS,.URL,.VB,.VBE,.VBS,.WSC,.WSF,.WSH,.XLM,.XLS

/C.

 

zopzop,

Obviously you missed my intended point. Malware that falls under category #4 does not exist and never will.

The one loophole I can think of is a DLL trojan that drops itself to your user folders and uses a script to invoke rundll32 to load it, AND then exploits a privilege escalation vulnerability. But in all honesty, if you ever chance upon such a trojan, I highly recommend you start buying the lottery.

 

Very good info.

Good idea, how do you block?

 

What most people seem to forget (or don´t mention that often) is the fact that as soon as you need to install some app, you have no choice but to give it admin rights. Meaning that HIPS (+brain.exe) will be the only thing that might save your ass.

I think LUA is mostly focused on protecting you against drive by attacks and against malicious apps that don´t need to be installed. But some of this can also be achieved on an admin account with DMR/SRP. Of course LUA is the better approach.

But because I´m mostly worried about malware who tries to integrate deeply into the system (via manual launch), I would like my LUA to work in a way that it would have write access only to the needed registry keys and to the "program files" folder (not to the subfolders!). This way most apps would be able to install correctly, and if they tried to act funny and are even able to bypass HIPS, they can´t do any serious damage. Is this possible, or am I missing something?

 

How will LUA be able to stop them from doing "any serious damage" when you've effectively given the app access to the "needed registry keys" and Program Files folder?

 

Solcroft, you might want to fix that qoute, I have edited my post. But to answer your question, if I´m correct, LUA won´t allow any modifications to kernel right? So with my approach, even if you allow apps to be installed, they can´t do any serious damage. Of course, HIPS still comes in handy, because it´s most likely that blocking executables from running will immediately stop a drive by attack. But the question is if it is possible to give write access to only certain regkeys (which are needed by most apps) and to deny access to all other sensitive keys? Probably not, and that´s the problem, which of course can be solved by HIPS, if it monitors the right keys, and if it isn´t bypassed.

 

It depends on your definition of "serious" damage. Not all malware needs kernel access to deliver their payload. I mean, for instance, if you don't consider as "serious" all your executables in %ProgramFiles% being infected, or a keylogger being installed...

It's all in the definition.

Yes you can.

 

And this can´t happen if you install some app yourself? At least a HIPS will be able to notify you if some app has been modified. As a matter of fact, M$ could have implemented a security policy, that wouldn´t allow subfolders in program files to be modified. Something that HIPS can also do.

Perhaps an idea to start a thread about it. To clarify, if you install apps, they will (almost?) always need to modify regkeys in HKLM, but that´s exactly where sensitive keys, who may be abused, are stored, correct?

I forgot to mention that HIPS might also give you valuable clues, even if it´s bypassed. For example, I did get an alert about Rootkit Agent EZ trying to directly access memory (high risk), but the damage should have been stopped by LUA anyway. Still, without HIPS I wouldn´t even have known that I was under attack. So, LUA + HIPS/security tools is the way to go.

 

Not sure what your point is. You asked, and I quote, "even if you allow apps to be executed they can´t do any seriou s damage." I was merely providing an explanation.

Er, they did, actually.

Erm, yes... I suppose that's very helpful...

Well, not for me, sorry. I don't need to be bothered by useless alerts that might possibly mean that I'm "under attack" when that "attack" has been completely defanged and castrated by LUA.

 

I think I´ve started to confuse you. My point is: Where the heck is your defense (in LUA) when you install some app yourself? This app will have admin rights, and will be able to do just about anything. So, it seems like LUA is mainly meant to protect against drive by/remote code execution attacks. And it´s my impression that HIPS will stop most of these attacks anyway, even when running as admin.

Yes, but only in LUA. As admin you can still infect/replace files, no? My point: even as admin there should have been certain restrictions. Of course if needed, you could then give trusted apps "full admin" rights.

This sounds strange to me, then why are you running tools like TF? Oh wait, I forgot, TF isn´t that noisy, I suppose you meant something like that.

 

Scripts are always the loophole in our search for the "bullet-proof" security setup.

Create an account with custom permissions. So, you'll have the admin account, the limited account and the custom account for installing apps which you don't trust completely.
You can fine-tune read/write/execution permissions to your heart's content in XP Pro.

 

Yeah, I guess I should try to do this, but how is the question. I´m not exactly an expert when it comes to permissions and stuff, it all seems so complicated to me. Besides, M$ should have figured this out for me, and they should have build the OS in a smarter way!

 

You can start here

Security in-depth isn't easy.

 

You should probably not need to allow more than what is shown in the screenshot for key directories, such as Windows & its sub-folders. I can tell you that the "Delete Mount" exploit talked about in another thread was unsuccessful with these and similar restrictions on the Program files directory. Others will probably have different opinions, so go with whom you have more faith in Lucas, Cerxes, solcroft and Mrkvonic clearly have an excellent understanding on this subject matter, to name the ones I can think of. Whatever you do, take your time, read up all you can on this and be careful. Don't just impose these restrictions willy-nilly without understanding what you are doing, otherwise you could lock yourself out of your account.

Maybe Surun is your best bet? Others have positive things to say about it.

 

How does HIPS protect you either when you install a new program? How do you know whether it's needed for that new program to install a driver, or register a 32-bit DLL, or installs a program-specific/global hook when you've never seen it before? Either you trust the program and allow, or you don't and you deny. That's not really much different from what a limited account does for you. You elevate privileges if you trust, you don't if otherwise.

But you wouldn't be protected in "full admin"! Omigosh. Shouldn't there still be restrictions in "full admin", and if you really really trust the program you can give it "full full admin" rights? But of course you still wouldn't be protected in "full full admin". Maybe there should be "full full full admin" rights too.

Would you like it to make coffee and fetch slippers for you too?

 

LUA+SRP may not be a perfect solution but it is a fairly good start.


If software is buggy, unstable or limited in functions because of LUA, that is a problem caused entirely by the software developer who does not work (or properly test) from a limited account. Considering that a large chunk of a developers income is likely to come from the corporate sector (which usually uses LUA) this is inexcusable. MS guidelines are clear enough.

If the user is smart enough to avoid trouble then an administrator account then by all means, go for it. However, for most users there is no good reason for it.
Too many times I have heard the line "I own the computer so I am the administrator" from people who do not have the smarts to fix their own broken computer. That's fine, I'll take your money...

Cheers

 

Hello,
Actually, in the corporate sector, I have never ever seen a single computer running LUA - and very few policies...
Mrk

 

Why so?

 

Incompetent network admins, probably.

 

Hello,

aigle, why? Because most users will cut their veins if their precious Outlook / Office does not open their precious emails / ppts - typical corporate worker usage.

We have an IT team answering 100 calls every day along the line - where has my cursor gone, I deleted my icons etc... landing them with a LUA / SRP would obliterate them.

And think of the comptence of IT personnel you need. Not everyone is capable of properly using policies. If you have smart people, you can save millions, but otherwise, it's a nightmare. You might as well land Linux into the desktops.

Mrk

 

Really?! Wow. In all the companies I have worked in LUA is always standard and no one has problems running the software they need for work. The software is thorougly tested to work with restricted accounts.
Ok, I havent worked in that many companies but I find it very scary if a company has a IT department and they allow admin on clients especially if they are connected to internet (and which companies are not connected today?)

 

Hello,

Combine incompetence with rudeness and lack of patience and you get admin accounts or the IT manager gets crucified within a week. But seriously, from what I've seen, it seems the only way that works with masses of computer-uninterested users.

Most people also install crap they are not supposed to - even at work place. And then they wonder why things don't work - and pester the IT to solve their problems.

I'm not in IT, but if I took a dollar for every case of help I provided to my co-workers, just because I know a little more than they, I think I could have earned 675 dollars so far. And imagine that for every one I helped, another 4 phone the IT instantly and whine:

- I erased my desktop shortcut icon (even better, it vanished - like a sentient thing).
- My mails are gone.
- My computer is slow (no ****, the company image on laptops runs 80+ processes).
- I get errors trying to open this webpage.
- Why does WU always trying to restart the computer?

That's my experience in companies.

Mrk

 

The only one to blame is the person who sets policy for the company. The company computer is not an employee's personal computer.

It can be done:

http://www.faronics.com/whitepapers/CaseStudy_LAPD.pdf

“We currently have a policy that prohibits unauthorized installation of non-Department sanctioned/
owned software on any Department computer,” said Mr. Riley. “


----
rich

 

It not only can be done, it should be done. I don't know what corporations Mrkvonic has seen, or whatever their minimum criteria are for hiring network admins, but the problems he describes can be prevented by properly-implemented policies. The issues his IT department faces aren't caused by limited accounts and policies, it's caused by the LACK of them.

 

It's also being done in more educational institutions.

Where I taught, all workstations had Deep Freeze so that no students could make any permanent changes.

This has an interesting added bonus: workstations in computer science classrooms run in Administrative mode so that students can do exercises to configure Networking and make Registry changes.

Upon reboot, the machines revert to previous good state.


----
rich