BluePoint Security product Q&A

Very soon, we'll have password protection shortly, they self protection has been less of a priority just because of the fact that nothing is going to execute and shut our processes down without permission, it will be there soon either way.

 

thanks,it sounds good

 

The videos posted above or the old videos?

Exiting out of our notification results in a denial (denial has already occurred by then).

It's certainly possible to click allow and or override anything you execute. In the case of the keylogger, they would receive a fairly ominous "high risk" warning, requiring them to click "override and allow". Hopefully they wouldn't override things and allow it but as with all security products they can be overridden. Our AV engine also backs up the default deny system, meaning you're not given an option to allow a known in the wild virus, it's simply taken care of. We've done away with the allow/deny notifications and moved to "override and allow" for high risk items to help with user confusion. You'll still see allow/deny, but only on items that appear to be somewhat safe.

 

Same file

http://www.bluepointsecurity.com/imgs/screenie.jpg

 

BluePointSecurity

Great videos, but I am running PGS (Pretty Good Security), so I can set a Software Restriction Policy for Vista Home. SRP denies execution outside Windows and Program Files directories. All the browsers run with low rights (IE and Iron), all other internet facing programs as limited user. See https://www.wilderssecurity.com/showthread.php?t=250748

SO SRP does exactly the same as Blue point does, deny execution.

So what is the added value of your product, why should I buy when I run UAC with SRP deny execute.

 

I realized BluePoint is a HIPS .

 

just tested blue point againts 3 malware samples 1 braviax.exe 2 antivirus pro 2010 and MacroVirus and delete them all,it cleans the house

 

I have the same question as Kees1958 above. If you run with SRP and lower privileged accounts, what benefit does BPS over this configuration?

 

The lower priv accounts will help only marginally, see video above. SRP however has piqued my interest and it's a great question.



http://support.microsoft.com/kb/324036

Per Microsoft:

Interesting ways to bypass SRP (I haven't tested these):

http://requinix.blogspot.com/2009/01/bypass-software-restriction-policy.html

In theory, SRP performs in a similar way to BluePoint. It also heavily depends on how you have configured SRP. Are you locking down to known hashes? Are you allowing any folders to change? I'll try and find time to test out SRP in the lab and see how it goes, I suspect it's fairly weak when it comes to actual exploits.

 

Thanks for quick reply...

I will have a look at this also in the next few days.

 

I've always enjoyed Marcus Ranum's articles, it's a bit dated but still applies for the most part:

http://www.ranum.com/security/computer_security/editorials/antivirus/index.html


SRP appears to be a cumbersome beast, especially if you're looking to achieve a true lockdown (as BluePoint does), how are you configuring SRP? As a complete lockdown or other?

 

lol, I truly do find the defintion of 'cumbersome beast' to apply to HIPS not SRP. SRP offers no popup, no evidence of itself at all. You only apply the restrictilon.

Technically speaking, the whole CreateProcess() method, which is invoked on execution, is written to check for SAFER values before allowed the process creation. If a valid SAFER rule is found, then the values the SAFER rule has are applied. It might be to deny execution. If this is so, it is denied plain and simple. It is true that if you are admin, and you have the option to 'exclude admins', then the rule will not apply.

If the SAFER value is to restrict aka Basic User, then the security token of the process is replaced with one of a Basic User instead of admin/power user. The process is allowed to be created, but at dimished rights. Again, it just happens. There are no hooks or other stuff going on. The actual method is designed to look for SAFER values before creating the process.

While POC's exist, I have not seen or heard yet of the exploit in use.

Suffice to say that if you choose to employ a default-deny scenario using SRP, things will be denied. You are correct, the effectiveness of SRP is only as good as it's configuration. Regarding hashes, these are not needed. Indeed, even using a path is not the ideal way to mitigate. Based upon name alone, such as FireFox.exe, it matters not where the executable lives. SAFER rules state to the process, IF the process is NAMED FireFox.exe, then apply the denoted rule (deny, allow, restrict, contrain, untrust).

For something already built into the OS one would wonder why it is not employed more. I personally believe it is because there is no way to really know it is working. You can create a process and examine its properties or actions and see what is going on, but for the average home user, it really is too transparent. However, for geeks like myself, it is a gem.

Sul.

 

Yikes

That's why I was curious as to how you were configuring it. Feeding SRP 10k file fingerprints is unfeasible and unmanageable in my opinion, although that's the only way it would be considered even remotely secure.

What about a virus named svchost.exe or mspaint.exe!

Major hole there

That'd be the first question out of a CSO, they ask us that all of the time, it wouldn't go well.

Configured that way, there would be a huge advantage to using BluePoint, we lock things down to fingerprints meaning renaming files isn't going to bypass our system as would be the case with SRP.

 

this is very interesting

 

jmonge

How's your system running with Prevx and BluePoint on the same machine? Any issues?

 

That's why certainly at the enterprise level, you need an easy to use management console


http://www.bluepointsecurity.com/products/enterprise


http://www.bluepointsecurity.com/imgs/screenshots/3ApplicationControl.png

 

Yes, it is true, SRP is not the holy grail. But then, nothing is or will be.

There are 2 different viewpoints from which one has to stand (at least).

First you have the advanced user. This user is A) smart enough to fix problems B) smart enough to steer clear of problems and C) smart enough to employ methods of differing types to fill in the gaps (called security ).

The less advanced user A) probably does not know how to fix problems, so any problem is truly a problem B) does not know what the threats/problems really are, so does not even know how to avoid them C) employs no method at all, employs the 'most advertised' method or employs a method he/she does not understand. All of these resolutions likely lead to someone like myself helping them out.

Now examine SRP in the hands of a knowledgable user. This user employs SRP from Admin. He sets SRP to apply to all users including Admin. He sets his browsers and all internet facing apps (because he understands where the threats come from) to start up restricted to Basic User. He understands that a User is restricted. He can then browse, whether the browser is more secure like Rmus does or not it up to him. Either way, he knows in typical situations root, windir and programfiles will be restricted by the process running as user. He is smart enough to close down the rights of the user group to create/modify autostart areas in the file system and the registry. He is smart enough to realize when he downloads a file, it is put into a directory that itself has a software restriction policy that says any executable within this directory will start as a user only. This user now knows that his browser is retricted, and where he downloads files to is restricted. It is now feasible how for svchost.exe to be created to windir? Because of users restrictions, programs running as user (the threat gates) are not allowed to do so. By default the download directory restricts any new files (executed within it) to be demoted to user, so they also cannot create/modify svchost.exe in windir.

It is up to this user to understand when they remove a new downloaded file to some un-restricted directory, and execute it, that without some HIPS or AV or other aid, they run it and take thier chances. Now the new file CAN modify svchost.exe, or create svchost.exe in program files. Then svchost.exe can run from one of these directories. Assume then that a payload has been dropped, that svchost.exe is created in windir/malware directory. Assume that a homepage has been changed in the default browser to go to the payload homesite. The next time the user starts the browser, it should go to homesite, and it in turn is coded to start windir/malware/svchost.exe and do some bad things. However, when the browser starts it will start via SRP as a Basic User. Whatever the rogue svchost.exe was designed to do will now be limited to whatever a Basic User can do. While this does not provide any effects of data/key logging etc, it does still provide an amount of restriction.

It is not perfect, to be sure. In the hands of a knowledgable user however, it can be very very secure. This does not even approach the default-deny method of using SRP. SRP has its limitations.

This is exactly why I can use it with great success and comfort, but also employ SBIE or vmWare if needed. I use ShadowDefender as well, 24/7. I could use an AV to scan a downloaded file. I could put a HIPS in place and the know for sure what is happening. But enough about me, lol.

The problem is finding a solution for the user that is not as knowledgable. If we want others to be as safe as we are, or feel we are, we must provide some method that compromises ease of use with security. It is not an easy thing honestly. How can it be. The nature of itself precludes that you must understand security to be secure, yet we ask security to be effective for novice users without novice users understanding security.

I fear it is a catch-22.

Sul.

 

I don't know, the whole no fingerprint checking and relying on exe names seems a bit weak to me, I certainly wouldn't feel comfortable with it (as a standalone). Most of the malware samples I see aren't named virus.exe and in fact there have been many examples named svchost.exe, which configured that way would run unchecked (albeit with low rights, watch earlier posted vid about the effectiveness of low rights).

As a real world and very common example:

I imagine a threat combined with a zero day IE bug being placed on a web page, if the threat just so happened to be named the same as one of the 1000's of Microsoft executables on an a system configured with SRP, it's over.

Drive by's are probably the most common infection vector, over the past decade or so I would say anytime I've ever been infected it was completely behind the scenes and without my knowledge, I only found out after the fact via noticeable system problems. Certainly I knew better than to be fooled by rogues etc, but simply visiting an infected page is tough to prevent by remaining vigilant.

 

Personally, I would not call it "marginal" that limited user accounts prevent system-wide infection that affects all user accounts, or that they prevent the installation of malicious drivers and direct hard disk access (kernel-mode rootkits, MBR rootkits...), or that they prevent modification of system files and services. If that's marginal, then I'd really like to hear what counts as substantial! Limited user accounts can help a whole lot: they protect security software from termination attacks, for example, protect other user accounts from being infected by mistakes made by one limited user, and make cleanup extremely easy (just delete the user profile, and that's that, assuming properly configured file permissions). It's certainly true that limited user accounts don't prevent people from executing files, even malicious ones, but their impact to the system can be limited. The user account itself, though, remains vulnerable to infection. That's where other measures should come in, from AVs to anti-executables and such.

Since SRP does not tell the user whether some file is safe or not (nor does any other pure/bare anti-executable type measure), Microsoft suggests that users at least use AVs to get some kind of idea on whether the file is known bad. That recommendation, though, tells nothing of the effectiveness of SRP.

And yes, making SRP rules based on filename alone is not secure. Convenient, maybe, but not secure in any way. But then again, there's no reason why you would have to make filename rules, when SRP allows much more secure options like hash, path (assuming you're smart and give your users only limited user accounts where they can't write into any and every location), publisher etc rules...

None of those are actual bypasses. All of them require there to be huge gaping rules left in the SRP rules by whoever created the software restriction policy, that is to say, misconfiguration. Holes such as leaving temp folders "unrestricted" when they certainly should be "disallowed" if SRP is being used to default-deny. When the SRP is created by someone who knows what they're doing, none of those supposed bypasses will ever work. Now, there are entirely valid methods to bypass SRP that cannot be stopped with making tighter rules. They're just methods a whole lot more sophisticated than the ones in that blog.


As for the malware problem in general, unfortunately nothing we currently have, and I do mean nothing, would solve anywhere near 95 % of the problem. And that's because a vast group of people get infected through social engineering, and the only security products that help against that are blacklisting products, and even they offer only very partial aid. No anti-executable whitelist, no limited user account, no software restriction policy, no HIPS, no sandbox, nothing will be able to reliably protect a system where the user has been fooled into wanting to execute a malicious file that pretends to be good. Once the user has his mind set on executing the file, he will ignore warnings from security software, give the admin password (if he knows it), turn off security products, anything he can, to get that file executed. And once the file is executed, then it's game over. So, while user education may be difficult, it is absolutely required if we ever desire to get anywhere near 90 or even high 70 % area of eradicating the malware problem. There's no dancing around that, unless we want to move to using computer systems where even the owner of the system cannot decide to execute code of their choice, or in other words a completely Orwellian environment.

 

Substantial would stopping it from executing in the first place

As I've stated many times, once you start allowing code to execute your playing with fire. I'm quite sure I could do massive system damage simply by executing code under the same circumstances as that video. Allowing the foothold is where the downfall starts. I'm not trying to say people should be running as admins, low rights is a great step in the right direction, I just here far to often that "well I don't run as an admin so I'm perfectly safe", in real world threat testing scenarios, it doesn't hold true whatsoever.

Agreed, is anyone actually running a hashed based SRP setup? It would be quite secure in theory, I just don't see how you could manage it or set it up in a way that your system wouldn't be useless.

I would venture to say that social engineering is more in the minority of the way people are infected, more commonly it's drive bys (no data just my experience). Certainly you can't control the human element completely, however you can warn them that they are about to execute something potentially harmful. The problem here is that users often times AREN'T being notified of infection or even warned, many times infection is silent and behind the scenes. I've infected countless vm's in the lab with no warning whatsoever from the security product and that's just terrible.

A properly engineered AE/AV security solution easily achieves 95%+ prevention, as many exploit testers have confirmed on these very forums, something no other security model can claim with honesty. The solution is right there guys, it's in the security model and grasping the deny the unknown methodology. Firewalls have been applying this methodology to network traffic for 15+ years very effectively. Long ago, networking equipment used to rely on large lists of "bad" ip's, until manufactures realized it's just not effective and moved to implicit deny all except known/trusted traffic. It's the same idea, applied to endpoint security.

 

A pretty high requirement to set, considering that the user still needs to be able to run some software...

Sure, executing malicious code is most often a very bad idea. So, stopping it from executing is a great idea. But as far as doing massive damage in a limited user account, you'd be able to do damage limited to that account and its user, damage such as deleting personal files or stealing passwords or other important data, serious issues to be sure, but you wouldn't be able to damage the actual system or other accounts without privilege escalation exploits.

But if anyone is saying they're perfectly safe because they don't run as admin, they're simply wrong. Not running as admin is a good idea, but it's not a panacea. Then again, nothing is.

Most users of SRP aren't using only hash rules, because path rules work just as well and for all practical purposes as securely as long as your users are running with limited user accounts. For example, if you allow C:\Windows\System32, and limited user accounts can't write there, that's a pretty secure rule that is easy to make (indeed, it's made by default) that allows a whole lot of critical system executables at once without allowing the user to execute arbitrary files in that path.

Sure, remote code execution is nasty. Blocking most of it is great. But social engineering attacks are a vast problem, and while I don't have any studies of the actual percentages, I would bet my entire fortune that social engineering attacks most certainly account for more than just 5 % of all malware attacks!

Actually, it achieves that only against remote code execution. Which is, of course, the only thing that people test here. (No-one is going to be able to test being fooled by some malware to execute it. To do that, they'd have to be able to deceive themselves somehow.) Against social engineering, it does not reliably achieve any percentage, since the user will just execute the malware in spite of the AE/AV. And if the AE blocks by default, then the user will just turn it off, just like they would do if the user was installing an entirely legit software.

Default-deny is a great idea. But it's not fool-proof (as fools are incredibly powerful creatures). If there remains any way for the user to install software, and there must remain a way, or the user will be really furious, then the user can just use that way to execute malware that attacks him through social engineering, and the AE can't do a thing to stop it.

As I've said: you can stop most remote code execution attacks easily, no matter how unwise the user is, by using whitelisting. But whitelisting can't stop a social engineering attack against a user who has administrative access to the system and is able to disable security software or log in as admin. That's simply an undeniable fact of life. While anyone who bothers to look can easily find remote code execution attacks in the web, it's equally easy, if not even much easier, to find social engineering attacks. There's a ton of those out there, and default-deny doesn't reliably stop them, because if the user wants to run that bad exe, he will run it, and disable security software that tries to stop him. Personally, I've seen targeted email attacks where the bad guy even warns the target that the attachment causes some AVs to give a "false positive" detection but the user should just ignore that to run the cool game/watch the cool vid/etc. Of course, the "false positive" actually isn't false, but some users are fooled, and even whitelisting security software is defeated.

So, yes, user education is absolutely required if there is to be any hope of reaching anywhere near 70+ % prevention against all malware attacks, including social engineering.

 

I agree on the social engineering point, you can always go back to that and anything will fail against a user that is determined to run things.

My point is, when a friend brings me an infested laptop they weren't socially engineering into being infected. A few files were dropped silently while they were browsing, executed through an exploit and they had no idea what happened, they just know their system is destroyed. That's not social engineering, that's security model failure. If you stopped the silent attacks, you'd stop the vast majority of the spread of malware. Think about it, conficker even code red (the list is endless) they aren't social engineering attacks. Server admins weren't sitting at their sql servers clicking on pictures of Brittany, again no user interaction here. Many of them spread through exploits and if there isn't a properly built wall there to stop and prevent them, malware writers will continue to release threats that are very effective without any kind of user interaction.

 

And indeed that is why it's hard to create a security system that can provide anywhere near perfect prevention. Because the user is often the weakest link, and as long as he has the admin password and control over the system, he can always just turn security off if he is fooled by some attack and wants to execute some bad file.

Oh, I understand. On the other hand, quite often people bring me computers that were infected through social engineering (run this exe to view a cool video). Social engineering is a big problem. But that certainly doesn't change the fact that remote code execution is a bad thing and we should work to prevent such attacks, as they're much easier to prevent than social engineering: it's hard to teach Joe User to know what not to run, and get him to actually remember that, but easy to install some whitelist product on his system to block most remote code execution attacks.

My main point here is this: as long as users continue to fall for social engineering attacks, and aren't educated enough to avoid them reliably, then we're not going to achieve anywhere near 95 % prevention against all malware attacks. Remote code execution, sure. But all attacks, no. That's just to say that even with a sound security policy and all kinds of blacklisting and whitelisting protecting a system, the system remains vulnerable as long as there are uneducated users who have full control over it.

 

the real truth is no instalation of any kind of software no infections my 2 cents

 

@BluePointSecurity

Sorry to have some critical notes regarding your thought out promo campaign regarding your product.

You started the campaign with the innocent words:

Like the thread title describe, indeed an BluePoint Security product Q&A starting post. Straight and to the point. But with incredible fast motion you turn the thread into a never ending promo campaign for your product. Your product is the best/superb, all other products are worthless, crap, ready to trash.
Taking a look at what you claim about the competition it underline what I write: your product is simply the best and have factual no serious competition, and all established vendors are doing a lousy job and their products are lousy too.

Another sign of your promo strategy: your signature. A billboard lookalike, my regards..

Also noteworthy: your endowment to circumvent nasty questions regarding your product, promo campaign and faithful helpers, and (free) alternatives for BPS. Direct nasty (but valid) questions and remarks pointed at you are ignored by you anyway.

<S>