HIPS = band-aid for Windows

If M$ Windows had the security architecture that Linux has, i.e., running as standard user and requiring a password to borrow from root to perform administrative tasks, there would have been no need for HIPS software. The first account that M$ Windows creates is a Computer Administrator account, equivalent to root in Linux. That is why HIPS software, e.g., Comodo Defense+, acts as a band-aid to protect critical Windows resources. Had M$ Windows set the first account as Limited/Standard User and required a password to borrow from Computer Administrator, there would have been no need for third-party HIPS because IMHO requiring a password to borrow from Computer Administrator/root is an internal HIPS, i.e., intrusions are prevented until the password is entered. Sure, Windows Vista and Windows 7 have UAC to mimic what Linux is doing, but what about those folks still on Windows XP? To upgrade to Windows Vista or Windows 7, you have to actually buy the software to perform the upgrade. Getting Comodo Defense+ OTOH is absolutely free. M$ should have implemented UAC right from the start. That way, no one would have gotten infected with malware and everyone would understand and be accustomed to the security afforded by UAC. Now, folks on Vista and 7 who turn off UAC are doing so because they are not accustomed to always confirming admin tasks and are skeptical about the security afforded by UAC.

 

There is truth to your post, but some rather important parts are just... well, not quite right.

Certainly it's true that making the default account a superuser account is the more insecure option, and MS chose that for "ease of use" and "compatibility with software developed for DOS-based systems" reasons, which really don't help security but occasionally help the sales. Personally, I would've chosen differently, but then, I'm not MS, and haven't made a metric fton of money selling software.

Folks on XP (and Vista and 7, too, since using an admin account with UAC is nowhere near the same as really using a limited user account, as the UAC protected admin account is still a highly privileged account and UAC is relatively easy to bypass, by design, and it is not meant to be a security boundary) can create a new limited user account for themselves and use that instead of the default admin account to get better security. That's what I've been recommending since a small eternity. Sure, that's not as easy as having the default account be a limited user. But such is life. Let's not hold our breaths waiting for MS to change the defaults...

But then to the "not quite right" parts...

As for limited user accounts being HIPS, though, the answer to that is just plain no. HIPS is more comparable to mandatory access control systems than non-privileged user accounts. There's a lot of stuff that a decent HIPS can do that limited user accounts just can't do. Whether that's stuff that most people would want or need is a different issue. Personally, I'm no big fan of HIPS, and I do consider them sort of a band-aid, but not so much a band-aid to any imaginary faults in the core Windows NT security model but a band-aid to bad user habits (hey, let's execute random files of suspicious origin without knowing what they will do and hey, let's not install security patches to our vulnerable software).

This part is just entirely incorrect: "No one would have gotten infected with malware.." I'm afraid that's not how it works. If you can execute something in a given user account, then you can also execute malware. Right now, there's Windows malware out in the wild (mostly rogue AVs) that works perfectly well even with UAC enabled on an admin account, or when executed in a real limited user account. Even without admin privileges, the malware can still do a lot of stuff without any user interaction: hide so that the current user cannot easily detect it, send spam mail or perform DDoS attacks, steal important files the user has read access to (such as browser password manager files or business documents), delete any file the user has write access to (like possibly important documents and images the user may be working on) or modify (=infect) any executable file the user has write access to (like some software installer they just downloaded in their limited user account and later intend to execute as admin to install it on their system for all users). Oh, and the present favourite: throw annoying pop-ups that tell the user they're infected and need to surrender their credit card details to be free of the malware. And then there's always social engineering: most people don't know what they're doing, and it's certainly not difficult to fool them into executing something bad as root. So, malware will continue to be an issue even if everyone uses a limited user account. Limited user accounts would prevent the malware - unless there are privilege escalation exploits used - from making system-wide changes like installing kernel rootkits and damaging the files of other user accounts, but the financially motivated malware of our day really doesn't need that stuff to work. And that's not just true for Windows. It's the same for all other modern general purpose operating systems as well. You don't need root to do evil stuff. You only need root to do system-wide evil stuff, evil stuff to every user of the system at the same time.

 

I think:

1. Malware card in Windows is overplayed.

2. You can use surun on XP, problem solved.

3. HIPS is unnecessary any which way.

4. Nothing can prevent users from doing harm if they know the root or admin password, because if they like to click, they will login as admin and click. And if you don't click, then it does not matter any way.

Mrk

 

The problem with HIPS is the user themselves. Most users don't have the knowledge to know wether to allow or deny when prompted by a good HIPS program. The average user will allow Malware to install all day when all they had to do is click deny. I do like HIPS programs if they have a very good white listing of good programs. I don't want to be prompted all day when i'm trying to get my work done. HIPS like other programs have to be updated as well when someone finds a workaround to get around them. I believe the best answer for the average user is a good anti-executable program with password protection. I run all my machines with a HIPS program or an anti-executable program while running in a virtual environment with something like Deep Freeze, Shadow Defender or Returnil Virtual System. If users are running in a virtual environment some exceptions may have to be defined so users can save their work in a local folder depending on what their work functions are.

 

LUA+DEP+good AV keeps Windows quite secure, I ran XPx64 in a public environment for years like that without getting infected or loosing my data. There is no way any rogue stuff can embedd itself in the registry under Limited account.

 

Agree with most of this. I've not run a realtime security app in XP or vista for a couple of years and nothing has been found with on-demand scanning. There's no substitute for common sense.

 

I don't like the "HIPS" acronym, as it really doesn't describe anything and has a different definition depending on whom is asked. More appropriate is Mandatory Access Controls (as you mentioned), which is a well understood term in computer security. A MAC's role is to do what DAC cannot (both NT and *nix use DAC as the "standard" security model). MAC's, on the other hand, make it "mandatory" that access restrictions are enforced (as opposed to leaving it up to the user) and can even jail a user who has root access. Now, it might be true that most Windows "HIPS" don't operate exactly like a MAC, so it could be that I am comparing apples to oranges. But it seems to me, from my reading, that these HIPS are trying to accomplish what a MAC does. (I realize you probably are aware of all of this, Windchild, so I am really just putting it out there for everyone else).

However, I disagree with you and Mrkvonic on this issue; I don't think MAC's are worthless at all -- they are indeed a very powerful tool against remote exploitation. If an application is exploited (even an app with root privilege) the MAC will confine the intruder to what the MAC policy says the exploited program is allowed. So, even if the exploit is successful, it wont do the attacker a bit of good as he will be effectively "jailed" to those locations. Really the only way to defeat a MAC is for the attacker to find a code path to the kernel itself and then exploit it. From there he can turn the MAC off. But the idea of a MAC (and a firewall) is to not let those kernel services be exploited in the first place. If the kernel level service is locked down with the MAC, it will contain any damage from a successful exploit.

There used to be a guy who had an open root shell on a spare box where he allowed anyone to login and toy around with it. The only thing is he had it locked down with SELinux MAC policies. It was up for years and never once exploited.

The rest of your post about user-accounts I pretty much agree with. Just because one is a limited user doesn't mean one cannot execute a malicious file. And there is really no way of knowing if a file is malicious before it is executed unless one looks at the code. Therefore, an attacker can indeed gain some benefit of taking over a user account, either from social engineering the user into executing a file or exploiting a listening user-level application (the browser for instance). The attacker will be limited in what he can do, but he will be able to send spam, etc. if he so desires. Perhaps only a nuisance, but bad enough.

 

Oh, I don't think MAC is worthless at all. Perhaps I expressed myself a little poorly. (Wouldn't be the first time!) I don't even think those "classic" HIPS products are worthless. What I do think is that the "classic HIPS" type that asks the user a whole lot of complicated technical questions in order to protect the user are pretty much a band-aid, and only semi-effective, requiring a lot of expertise from the user - their protection depends largely on how smart the user is. But obviously MAC doesn't have to work in the "let's ask a lot of questions" way, and even HIPS products don't have to work that way as shown by some "policy-based" HIPS products that aim to ask very little from the user and just simply apply restrictions to whatever's running that deals with potentially untrusted content. MAC, when done right, is just great. Still, it can also be overkill for many scenarios, and setting it up can be more than a little difficult (except when someone else does it for you, like the developers of your chosen OS distro).

Most HIPS products I would consider "kind-of MAC", and only "kind-of", because their "let's ask the user a million questions and make him decide whether to allow some potentially bad thing or block it" behaviour doesn't exactly sound like mandatory access control to me.

So I think we pretty much agree on this stuff.

On many if not even most systems, the attacker may be able to be much more than just a nuisance even if he only gains limited user privileges. As I've shown to a couple of companies in penetration testing, it's great that your R&D and accounting guys are running limited user accounts, but that doesn't mean I can't use the latest in an endlessly long line of Acrobat exploits to get malware executed in those accounts and then upload your financial data and the schematics of your latest unreleased model to my server using IE and regular http traffic that you let through your firewall just fine. (AppLocker/SRP to the rescue, though, but then, not even that is bullet-proof.) The same goes for the average home user. Maybe I can't install a kernel rootkit, but I sure can steal their PayPal passwords, credit card data and whatever else important they might be inclined to enter in the system using their limited account - oh, and their questionable pictures of themselves that they wouldn't want to share. Granted, this stuff is easier to detect when the entire system isn't rooted, and even AVs might actually notice something and perhaps even block the malware since they won't get immediately disabled by it, but your average guy at home or in a business environment probably won't notice, and by the time someone smarter does, it may well be far too late to do anything but watch the fireworks and count the damages.

 

MACs are not useless - they are redundant for home use.

Furthermore, we're talking about a transparent set of policies set by experts rather than an interactive tool that lets user have 50% chance of making a wrong answer each time it asks.

You can have basic MAC by creating a chrooted environment. But that's only relevant for services. And who runs services listening to the wide world? Only really important machines. Not a case for most users.

Mrk

 

In the case of rogue av's, the two I've encountered the last several months were very easy to stop dead in their tracks, and that was done in a limited account using common sense. If you don't execute them, they're a non-factor, at least the two that popped up on me.

 

Yeah, that's what I was trying to say in a short and sweet form.

Indeed, most LUA-compatible malware I've seen is primitive. But there's nothing that prevents making much better malware, much more difficult to detect and remove. Except for the malware guys knowing that the primitive malware works just fine for their purposes currently. Recently I saw one case where a Firefox user managed to get infected in LUA - their browser was up to date, but sadly their Adobe Reader was not and they unwisely had Firefox automatically open PDFs (the default setting, I imagine). They got some rogue AV running on the limited account for that, without any user interaction to execute the malware. The malware was very easy to remove, though - kill one process, remove its HKCU run key and delete the executable from the temp folder and that was it. It just goes to show that stuff happens. Of course, they would have been infected much sooner, with far worse stuff, if they had been browsing as admin. From what I discovered in their Firefox history, they'd been browsing infected sites (without knowing it) for a while, and would've gotten owned by PDF exploits serving more evil stuff like the TDL rootkits, but the droppers for those assumed they had admin privileges and didn't do anything in LUA. Still found some remnants of said droppers on the system, inactive and broken. But to be perfectly unbiased, pretty much any HIPS product would have helped here: they're a somewhat advanced user (intermediate, perhaps), and would have realized something was wrong when the HIPS says "somefile.exe in your temp folder wants to execute" all of a sudden after browsing some site and they would've said no, avoiding even the easily removed infection in their limited account. On the other hand, just not letting the browser automatically open PDFs would have done the same, except better (the actual exploit code would not have been executed, since the malicious PDF would not have been loaded at all).

 

Right, as member Rmus has often posted proof that this easy to implement browser defense mechanism (same with java script, I think) will stop the majority of these exploits. I've also seen a rogue AV infection in a limited (though power user) account, but it was very easy to remove, maybe because it could not embed itself deeply into the system. I remember it was a few years ago, and some here had expressed doubt towards my claim. Oh well.

Yes, agreed. So many seem to focus on what abominations the malware can hurl at the system, but fail to focus on how easy it is to prevent the malware in the first place.