Breaking AV Software

as I said the comments have no argumentation behind other than any software contain bugs, I don't see any proof related with the idea of you are safer without the AV. At this level of paranoia my advice would be to use linux.

Well you are assuming without any proof that there is malware able to bypass dozens of security products at the same time, this would be the only way to "ensure" that a 2-3-4 layer protection approach can be bypass through their vulnerabilities.

 

If I recall correctly, Blue Frog security was attacked out of existence using PCs on which Norton Internet Security was exploited. The attack was so large it knocked the entire country offline for a while.

yes, other software is equally exploitable. Few if any can provide the access to a system that an AV gives. AVs have nearly full access to the entire system and internet access. While firewalls and HIPS can have as much low level access, they're not trying to parse every new file. In effect, the AV does what users should know not to do, attempt to open every file it comes in contact with. AVs do what those who use social engineering can only dream of, open everything using an app with root access. That makes them a very unique target.

 

I didn't believe that I was implying this, it would seem an extreme case, but as long as I am making conclusions, others are welcome to do the same.

My problem with multiple layers is the more than likely possibility for conflicting products. Though they shouldn't, how many AV products conflict with Malwarebytes? A lot of them won't officially claim to conflict, but a lot of them recommend against running them together. If my security solution causes more problems then malware would...

Ultimately, it just seems that the original article drops a bomb and leaves us with nothing actionable. It was an interesting article. I guess I was looking for the "Ok, and?..." but it appears there really isn't one at this time. I'll continue to do what I do and hope that at some point someone comes up with a better alternative. I'm sure this article is somewhat trying to provoke that alternative out of someone, but until then, business as usual.

 

Yes that't true. I wonder why there is not many attacks on AVs? I know that no single vendor has the number of users similar to windows, office, flash or java but I would still expect more attacks happening.

hqsec

 

A lot of your layers fall off when an attacker gains root control over a security process.

As I said, attacks don't happen often because in the best case an AV is going to have maybe 16-30% market share, and a browser plugin will have 70-99%.

 

Computing of all kinds could use a magical answer. Unfortunately there isn't one. If you're looking for alternative solutions, look at the problem from a security policy perspective, not from an application perspective. There are alternatives to default-permit, which in spite of the changes they've made, is the core policy behind AVs. Containment, virtualization, default-deny, and combinations of the these are all viable alternative. Each has their good and bad points. Each has different demands on the user. Pick what best matches your needs and skill level, then configure your system and choose applications that best support that policy.

 

An exploit like that will be extremely effective but only for a short time and then only once. I would think that those who have such exploits are not going to use them trivially. I'd also bet that 3 letter agencies have bought every one of them they could find. The big spammers didn't actively use their Norton exploit until Blue Frog threatened their existence.

There's a couple problems with building layered security packages with AVs and with the example you mentioned. The biggest issue with AVs in this regard is its design. The AV is a direct path from the attack surface to the kernel. It's not really possible to insert other layers into this path.

The example you used, Malwarebytes and an AV isn't layered security. They're duplications of the same layer. In a layered setup, each component performs a different function. The firewall controls what traffic is allowed. The HIPS controls what applications can run and how they can interact with each other. A web filter restricts the content of the allowed web traffic. A script filter speciifies what scripts are allowed and what they're allowed to do. A sandbox confines the activities of the applications to a specific area and restricts their ability to modify system components. Because they're separate, each can defend and support the other. When they're integrated into a combined suite, they share components. Those shared components can also be shared vulnerabilities.

 

Security is always a trade-off and there isnt anything better than AV in the moment for the average user.

I really laugh off from some "security setups" and "experts" that I see here on Wilders, they are not practical at all, just a hobby.

I will not post examples, but some Wilders users seems to have a computer just to play with security; Wake up folks, security needs to be practical and modern antivirus are that.


HIPS + Sandbox + Full Virtualization + Anti Executable + EMET + Max UAC + LUA, the average user simple doesnt know how to use all this stuff, well if someone knows how to use all this than he doesnt need that setup in first place.

About the research, the guy has a point, but in the end it doesnt matter.

 

That is the real problem. There are no good options for the average user. The combination of unskilled user with administrative access is a no-win situation on Windows as it exists now. The real problem behind this is that there's no incentive to build a computing system that's both secure and easy to use. If XP for instance could be made truly secure, there'd be no reason for anyone to buy the next OS. Whether it's an OS or an application, something truly secure would be a one time sale. No corporation will ever release anything that comes close. It's financial suicide.

 

AV software needs system privileges and interacts with untrusted code as part of their design; in order for them to do their job. That's a given. It's a matter of assessing whether that element of risk is worth its weight in terms of what the AV can provide in exchange. On systems where OS hardening and least privilege is the core, that risk becomes a liability. On your average Joe system (more so for those with risky behavior), that risk is offset by the potential for that AV to prevent malware infection. Pick your poison.

What is disappointing is to see AV vendors not adopting security mitigation techniques like ASLR. We are not even talking about bugs...just recommended coding practices. You can probably excuse small-time developers but you would expect much better from AV vendors. Microsoft have written about ISV adoption of these and even provided guidelines.

http://blogs.msdn.com/b/sdl/archive/2010/09/21/isv-adoption-of-mitigation-technologies.aspx
http://msdn.microsoft.com/en-us/library/bb430720.aspx

 

Yes, but it has also been said in the PDF that system privileges can be used much more carefully.

Escaping the Chrome sandbox without even touching it, thanks to a web-av module, comes to my mind here.

 

What is ASLR btw?

AS Limited rights

 

Address Space Layout/Load Randomization

http://en.wikipedia.org/wiki/Address_space_layout_randomization
http://www.insanitybit.com/2012/11/09/windows-8-takes-aslr-to-the-next-level/
http://blogs.msdn.com/b/michael_how...ce-layout-randomization-in-windows-vista.aspx
http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx

Easy analogy: It shuffles the deck of your cards, so nobody can guess what are the orders of those cards.

Not all apps have it enabled, unfortunately.

 

It's probably not an invincible security but at least Microsoft should start to close the holes they have. The problem being Microsoft is such a lazy mustard and they have silly ideas like giving admin rights to any computer users by default and have the ability to remotely modify your registry (!) among other things. We know they are competent enough and financially capable to do that. Look at Android, that's a good OS. Apps are isolated unless you root them.

And here we are left to securing our own computers with anything we can get in the internet. While most of us don't know that some of them actually opening another hole for us to worry about.

What I think is funny, is why are there some of the AV processes which are ASLR enabled, and some aren't? Why making it half-faced? It's something I can't understand at all.

 

Lol, some of the fails from AV vendors are really disturbing..

 

Re-posting link since this is still relevant.

Code:

hxxp://www.blackhat.com/presentations/bh-europe-08/Feng-Xue/Whitepaper/bh-eu-08-xue-WP.pdf

Complete with real-life example.

 

LOL, quite funny comment.

So if I understand it correctly, security tool writers need to code more securely?

How to protect against exploits, I suppose via DEP, ASLR, SEHOP, and Mandatory Integrity Control? Is it possible to protect security tools with EMET?

 

I like this little "Alert when quoted" thing.

The architecture of most AV software is flawed to begin with, since they're all quite old. But yes, DEP,ASLR,SEHOP would be a nice start. You can EMET your AV software.

 

I'm not sure that's a good idea. AV programs don't like being tampered with. One should report to the respective AV vendor and remind them to fix their code. It's not like their programs are legacy apps without upgrades. The vendor can and should fix it...not the end-user. If they don't, and one is concerned about it, it would be better to find alternative AV that employ the mitigations itself. An obvious one would be Microsoft's own. Then again, MSE and WD (Win8.x) comes with its own limitations and problems.

 

Last I checked, MSE is the only AV that packages *only* ASLR enabled binaries.

 

I know. I read it here:
http://www.insanitybit.com/2012/12/13/analyzing-antivirus-security/

Well, I see WSA there

But users can check for themselves.

http://icebuddha.com/slopfinder.htm

 

Damn that profile picture makes me hungry.

 

I thought that doesn't work because most AV softwares' self-protection prevents injection from emet.dll

 

Some can. But I agree with what safeguy said, it's better not to. If one really bothered about this issue then it's better to not using AV at all. If it's too much, then just use OD scanners which have ASLR enabled. IIRC HitmanPro has all of it's components are ASLR enabled.

EDIT: As far as I can tell, most of those so-called self-protection features are nothing but just a Yes/No prompt.

Then that makes you the Hungry Man. =V

 

I don't see anything that states or implies that ASLR enabled components would prevent AVs from being exploited or have any direct effect on the exploit at all. I also wouldn't rule out the possibility that imposing such restrictions on an AV could cause it to crash, leaving you more vulnerable than you were to start with.

In addition to laziness, complacency, and stupidity, there's other potential reasons for this lack of good coding practices. Don't rule out the possibility of government coercion and collaboration. Many of those companies are invested in much more than AVs. McAfee is a prime example. McAfee is also Network Associates. They controlled PGP at one time. Controversies surrounding them resulted in the separate creation of the CKT versions and claims of backdoors in PGP itself. Now McAfee is part of Intel and are involved with adding "security" to the hardware itself with controversies of its own. At one time, many believed that Network Associates was little more than a front for the NSA. While I don't accept that at face value, I've also seen nothing that rules out the possibility. Between different events back then and revelations regarding NSA coercion now, the possibility has to be considered that the exploitability of AVs and the vendors lack of good coding practices is deliberate. McAfee is just one example.