BluePoint Security bypassed

I just tested BluePoint Security 1.0.35.99 against an old killdisk malware (presumably in its original form), and it went right through it. Here's the file in its original form (last modified April 2006):


What's interesting is that if I rename the file to a readable one (eg. "1.exe"), BluePoint Security will analyse and block/delete it when I try to execute it:


Presumably the original file name consists of chinese characters (I didn't install the East Asian Language pack for Windows in my VM, hence the reason for the "box representations"), and for some reason, BluePoint Security fails to scan it.

I think Zero_One needs to look at this. The way I see it, it's a critical vulnerability in BluePoint Security.

I agree with you. I dont instal these packs either,as I disable ctfmon.exe,
and they will not work without it.
I cant display my first language in a readable form,but I hate ctfmon.exe
running as a process.

I would never have imagined these tweaks would lead to a by-pass of a security product.
noor

I've been at DefCon/BlackHat all week, just caught this thread, will look into shortly.

Any thoughts? If you want the original real malware file that I used in the test, please ask and I'll PM it. It's actually accessible (somewhere) on this forum, but I'd rather communicate these things via PM haha.

Issue corrected in 1.0.38.99, thanks to ssj100 for reporting it.

We take confirmed reported issues very seriously and we patch them without attempting to explain why the issue is 'ok'.

PowerShell scripts are now default denied as well.

Thanks again ssj100!

Zero_One wrote:Issue corrected in 1.0.38.99, thanks to ssj100 for reporting it.

We take confirmed reported issues very seriously and we patch them without attempting to explain why the issue is 'ok'.

PowerShell scripts are now default denied as well.

Thanks again ssj100!

Good work Zero_One! And glad I could be of some help.

By the way, when you say Powershell scripts are default denied, how exactly does BluePoint Security identify a Powershell script? Does it block it by file extension? Would it block it if it was some how executed inside eg. browser space?

I think Powershell scripts are similar to JavaScript, as I discussed here:
https://ssj100.forumotion.com/security-f7/zero-day-powershell-attacks-heading-your-way-t239-15.htm#1891

However, note that I also identified that JavaScript can also be blocked when executed within a browser by blocking jscript.dll (and java.exe).

Clearly, default denying jscript.dll would not be practical for a security product like BluePoint Security (which aims at a wide audience). Therefore, would it be fair to suggest that BluePoint Security cannot do anything about malicious JavaScript, Powershell scripts etc when they are executed within the browser space (or similar)?

If so, would BluePoint Security consider developing a "sandboxing" type component to combat these types of malware? Or are these types of malware considered too rare to be worth protecting against?

Thanks.

Can't discuss in detail the how part, as most of our competitors aren't doing this yet, which is nothing new!

I'm not aware of 'in browser PowerShell execution'. If that's going on it's news to me. Most of the news surrounding powershell issues are the result of a script being executed, since we block them by default that mitigates 99% of the issues right out of the gate.

We don't usually bother with sandboxing for two simple reasons: A). very difficult to implement without breaking apps left and right B). It can be easy to get around/bypass them.

Default deny is the only way, everything else is just well...

There was a good demonstration at defcon, relies upon script execution of course.
http://www.secmaniac.com/july-2010/blackhat-and-defcon-poc-code-released/

Javascript running in browser runs differently than Javascript files executed directly from your desktop (less rights). Javascript is not usually the end game for an attacker, it's usually the delivery mechanism for launching further into the system (binaries/executables), which end up neutered by bluepoint anyway. That's not to say that we don't have in memory protection capabilities, we do.

McAfee believes the internal name attackers gave to the operation was "Aurora," which the code indicated was the directory name on the computer where the code was compiled into an executable file, said Dmitri Alperovitch, vice president of threat research at McAfee.
The attack was notable for its level of sophistication, using obfuscation techniques not typically seen in attacks on corporations, he said. It dropped about 10 different malicious files with different capabilities that were used at different stages of the infection and used crypto and other techniques to avoid detection, he added.
"The exploit itself was a piece of JavaScript code that encrypted itself and had multiple layers of encryption that got you to the executable binary code, which phoned home and then pulled an encrypted file from an external server," Alperovitch said. "That file used multiple keys for encryption and once it was decrypted it turned into an executable that dropped various modules onto the infected system."

http://news.cnet.com/8301-27080_3-10435232-245.html

All that complexity and at the end of the day, Aurora was an executable that was running that should have never been allowed to execute. If they had something like say BluePoint Enterprise to manage their environment centrally, the incident would have never happened. Forgive the shameless plug.

I constantly hear about how "advanced" such and such incident was. The delivery is advanced, yes. The executable running is just the same old thing that's been going on with these incidents for 25 years (atleast).

People need to learn that default deny is the only effective security mechanism. Everything else is a waste of time.

Zero_One wrote:I'm not aware of 'in browser PowerShell execution'. If that's going on it's news to me. Most of the news surrounding powershell issues are the result of a script being executed, since we block them by default that mitigates 99% of the issues right out of the gate.

I'm also not aware, but I think it's theoretically possible if what Wiki says is true (although I'm no expert when it comes to interpreting such statements):
http://en.wikipedia.org/wiki/Windows_PowerShell

Windows PowerShell is Microsoft's task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with, the .NET Framework.

Zero_One wrote:We don't usually bother with sandboxing for two simple reasons: A). very difficult to implement without breaking apps left and right B). It can be easy to get around/bypass them.

Have you used Sandboxie? I've been using it for over a year with no major issues at all. Most of the minor issues I had were fixed fairly quickly. I'm pretty sure there are thousands (probably more) of people using Sandboxie without any problems. If you look at various forums which poll "What is your most favourite security application", if Sandboxie is an option, it tends to always come up near the top (or at the top). This is impressive, considering Sandboxie is not that well known (compared to eg. Norton Antivirus) and is probably not very appealing to the average user. I guess what I'm saying is that "breaking apps left and right" doesn't sound like a problem with Sandboxie (particularly since you can choose exactly which app to use it with). We probably all agree that the web browser is the most common source of infection - therefore, sandboxing the web browser would make a lot of sense.

As for easy to bypass? I would say Sandboxie is the application that has been bypassed the least out of all security products out there, period. Therefore, combining anti-execution with Sandboxie makes for an extremely powerful security setup. Don't forget that Sandboxie has an anti-execution ability within itself too. With the right security setup/approach, Sandboxie is arguably all one would need (this obviously doesn't apply to the average user), together with something like NoScript in the web browser. Anyway, I'd have to disagree that they are easily bypassed unless you can PM me a sample (POC or live malware) that can bypass Sandboxie (preferably on 32-bit).

Zero_One wrote:Javascript running in browser runs differently than Javascript files executed directly from your desktop (less rights). Javascript is not usually the end game for an attacker, it's usually the delivery mechanism for launching further into the system (binaries/executables), which end up neutered by bluepoint anyway. That's not to say that we don't have in memory protection capabilities, we do.

Note what I underlined above. If you told me instead that it's always, then I would be more convinced haha. Without a sandbox function (like Sandboxie), I would not label BluePoint Security as "100%" protection. And yes, I know there is no such thing as 100% protection etc etc, but hopefully you get my point.

Zero_One wrote:People need to learn that default deny is the only effective security mechanism. Everything else is a waste of time.

I completely agree that default deny is a very effective security mechanism - I've been promoting it for a long time (mostly SRP haha), but again, I wouldn't say it's the ONLY effective one. I still feel that sandboxing is an extremely powerful security mechanism. The only reliable sandboxing mechanism that I would recommend is of course Sandboxie. By the way, I was reading some of your comments on Wilders the other day, and was surprised that you were suggesting SRP could be easily bypassed. It might be worth reading through these posts if you still think that way (there are probably other relevant posts on this forum, but these are the ones that initially come to mind):
https://ssj100.forumotion.com/windows-hardening-f5/mis-understandings-about-software-restriction-policies-srp-t22.htm#105
https://ssj100.forumotion.com/windows-hardening-f5/mis-understandings-about-privilege-escalation-exploits-t226.htm#1675

There is a lot of mis-understanding regarding SRP out there (heck, even I mis-understood it haha). A lot of the mis-understanding comes about because of poorly configured SRP's. At the end of the day, I only know of 2 ways to bypass it (even when properly configured):
1. As demonstrated by Didier Stevens, SRP can be disabled by eg. running a specially crafted Excel macro. However, eg. Microsoft Excel does not allow untrusted macros to run by default, thus this is easily mitigated etc. Do note that blocking other similar bypass vectors is very simple to do, and highly recommended by me (particularly since 99.99999% of home users never use these functions anyway) - eg. blocking cmd.exe, powershell.exe etc.
2. Privilege escalation exploits + eg. subsequent remote code execution. This would require many things to come together, including the specific vulnerability being on your system, as well as the specific malware code to get on to your system. And I'd just like to add that I've never come across anything like this (not even a POC), although I would really like to!

As you can see, the probability of SRP being bypassed is very remote. Evidence of this lies with "in-the-wild" malware - there just isn't any out there that bypasses SRP.

If you do come across a POC and/or live malware that can bypass either Sandboxie or SRP, please PM me! Keep in mind that I am aware that eg. Buffer overflow exploits can bypass SRP, but I would prefer a POC and/or live malware that actually does something malicious to you or your system.

Anyway, enough of my ranting for now haha. I'd just like to finish by saying that BluePoint Security is definitely on the right track in terms of providing "100%" protection. I personally think that adding a sandboxing function would raise the level of protection provided even higher. Of course, this sandboxing function would need to be comparable to Sandboxie. Otherwise, a combination of BluePoint Security and Sandboxie would be formidable indeed.

(Admin post)
Hi ssj100,
I must have missed that one, could you please pm me a link to the post if it's available so that I can modify it. Thanks

Just a note to members please do not post direct links to malware...use pm

ssj100 wrote:Any thoughts? If you want the original real malware file that I used in the test, please ask and I'll PM it. It's actually accessible (somewhere) on this forum, but I'd rather communicate these things via PM haha.

Regarding SRP, it's only useful if you are locking things down to hashes/fingerprints rather than filenames. I believe someone there had it locked down to filenames, I was trying to explain why that's not really protecting anything when I see malware coming across as svchost.exe on a daily basis. It's wilders, explaining anything rational to some of them can be difficult.

Not a huge believer in sandboxes, that's not to say that we won't do more with them at some point. Most of what keeps us away from them is the incompatibility issues that arise from them. As one example one of the sandboxing/av/firewall all in one apps (not sandboxie) broke the vmware esx client I use everyday due to it being sandboxed. Of course I could change the settings, but that's too much to ask of an average user / the masses which is our target market.

Most people just want to use their computer and be protected without fiddling with fickle settings all day. Our designs always work towards that, maximum protection, minimum hassle to the end user.

How about

Code:

runas /trustlevel:"Unrestricted" virus.exe

SRP is far better than most AV products, the problem is, if you have 1000 computers across a diverse enterprise, SRP + Hash would be an unusable nightmare. The centralized management/reporting/ease of use just isn't there.

Zero_One wrote:Regarding SRP, it's only useful if you are locking things down to hashes/fingerprints rather than filenames. I believe someone there had it locked down to filenames, I was trying to explain why that's not really protecting anything when I see malware coming across as svchost.exe on a daily basis. It's wilders, explaining anything rational to some of them can be difficult.

Locking things down by path is also a very powerful method, and very simple. There's a guide here that people often quote:
http://www.mechbgon.com/srp/
The concept is basically (as the site writes, it's a "Catch-22 for the bad guys"):
1. Where you can write, you can't execute.
2. Where you can execute, you can't write.

I've been running like this as a home user for nearly a year, and have been very pleased with it. And as I said, I'm yet to come across any in-the-wild malware (or even POC's) that can bypass it and do harm.

Zero_One wrote:Not a huge believer in sandboxes, that's not to say that we won't do more with them at some point. Most of what keeps us away from them is the incompatibility issues that arise from them. As one example one of the sandboxing/av/firewall all in one apps (not sandboxie) broke the vmware esx client I use everyday due to it being sandboxed. Of course I could change the settings, but that's too much to ask of an average user / the masses which is our target market.

Most people just want to use their computer and be protected without fiddling with fickle settings all day. Our designs always work towards that, maximum protection, minimum hassle to the end user.

That's very true. Most home users wouldn't dream of fiddling with ANY settings all day. However, perhaps this is why you can create a sandbox which doesn't require any fiddling (eg. Sandboxie) and still provides excellent protection, but allows the option to fidde till your heart's content for above average/expert users. Also, I haven't had to fiddle with any Sandboxie settings for months - once it's all setup, it's all setup (unlike eg. Classical HIPS, which require new rules for every program update).

Zero_One wrote:How about

Code:

runas /trustlevel:"Unrestricted" virus.exe

That's easily mitigated - simply block runas.exe (as I recommend in my setup/approach post under SRP here:
https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16 )

Zero_One wrote:SRP is far better than most AV products, the problem is, if you have 1000 computers across a diverse enterprise, SRP + Hash would be an unusable nightmare. The centralized management/reporting/ease of use just isn't there.

For me, the beauty of SRP was that I already had it in my Windows (keep in mind that not all Windows versions have this - therefore, BluePoint Security may be a good alternative!), it was already built-in, didn't cause conflicts, didn't require updates, didn't use up resources etc etc. So when I discovered it, I was rather pleased with it.

Yes, catering for 1000 computers is always going to be a struggle, no matter what security software you have installed. I know a lot of corporate facilities in my country that use some form of LUA + SRP (and maybe a simple antivirus), and they've been successfully doing so for years/decades. However, I'm thankful that I'm not responsible for running a network/server of this magnitude. In fact (like millions of people out there), all I run is a single home computer connected to a NAT Router haha. LUA + SRP (path) fits in perfectly.