how easly is to bypass avira ?

[yaslaw]

Read this topic please: http://forum.antivir.de/thread.php?threadid=22082

I am little bit worried about my safetly right now :(

[C.S.J]

i wouldnt be too worried, all av's can be bypassed in some way if they really wanted to.

"kav and dr.web are unpacking monsters,"

i like that tho :D

[Firecat]

{QUOTE->
"kav and dr.web are unpacking monsters,"

i like that tho :D <-QUOTE}
It is actually true you know :)

[pykko]

that is just a bashing topic there... Read Stefan Kurtzhals answer. ;) There is no need to add dozens of packers because anyway they can be easily bypassed. If you detect the malware after extraction is ok. :)

[RejZoR]

I do know one AV that doesn't do packer/crypter specific detection. Avast! ;D

[lucas1985]

{QUOTE-> I do know one AV that doesn't do packer/crypter specific detection. Avast! ;D <-QUOTE}
I think that you may be wrong. I often see Win32/Trojan.gen (UPX) in MIRT.

[RejZoR]

Thats not generic UPX detection. It just states that some generic malware was detected under UPX packer.

[lucas1985]

Well, I was wrong ;D
What about AVG?

[Firecat]

{QUOTE-> Well, I was wrong ;D
What about AVG? <-QUOTE}
"Virus found Win32/CryptExe". This is the only possible packer detection I have noticed from AVG. There was another called "Win32/PEPatch" but I verified this to be real malware and not just a packer detection. :)

[RejZoR]

It's still a packer dependant detection which was luckily correct on some malware...

[Firecat]

{QUOTE-> It's still a packer dependant detection which was luckily correct on some malware... <-QUOTE}
No, there are many variants of Win32/PEPatch reported by AVG unlike the Win32/CryptExe detection, which was always detected as just "Win32/CryptExe". For example "Win32/PEPatch.I, Win32/PEPatch.Y, Win32/PEPatch.X" etc.

When there is a packer detection from an AV, usually there are no variants - for example "Mal/Packer", not "Mal/Packer.A", "Trojan.NSAnti.Gen" (BitDefender), "TR/Crypt.XPACK.Gen" (Avira)

After searching a little bit about it, I found out that "Win32/PEPatch" is given to malware which modify portable executable files like winlogon.exe (for example) :)

[EraserHW]

What about custom packers? :)

It's clear, if you want you can bypass almost all av based on signatures. That's one point where HIPS/CIPS can really give an help ;)

[C.S.J]

i think they all add them,

drweb: Trojan.Packed.132

[RejZoR]

Firecat, those variant packer detections are most probably just packer detections with dependences. McAfee is using similar (well at least i know they used to in the past). It was like this:

Packer: UPack -> YES
File size treshold: 200KB
+ some extra internal characteristics

If you had UPack packed file taht was 1,1MB in size, McAfee left it out since UPack packed worms/trojans were never this big (because of transportation reasons).
If you had UPack packd executable with size of 55KB, McAfee jumped with name like New malware.u (just example).
So it's not a fully aggressive packer detection that will jump on any packed file but it was more selective, resulting in less false alarms than lets say QuickHeal that jumps on any runtime packed file regardless of ther characteristics. Pack Notepad.exe with more exotic packers and it'll be always flagged as malware.

[Inspector Clouseau]

{QUOTE-> After searching a little bit about it, I found out that "Win32/PEPatch" is given to malware which modify portable executable files like winlogon.exe (for example) :) <-QUOTE}

Wrong. Even total wrong. PE_Patch is a synonym for additional patched files after runtime packing for example. If you pack a file with UPX and redirect the Entrypoint to some strange extra decrypting function (such as decrypting the UPX sections first before calling the UPX Unpacker stub - for example via XOR) it will be flagged as PE_Patch. Basically that means a second or third etc layer before the "real" entrypoint.

[Inspector Clouseau]

And regarding the topic - you can "easily" bypass *ANY* Security Software. And if there are only 2 known and verified options how to do that the next moronish user who has absolutely no idea what hes doing will find a 3rd one by accident.

[RejZoR]

{QUOTE-> Wrong. Even total wrong. PE_Patch is a synonym for additional patched files after runtime packing for example. If you pack a file with UPX and redirect the Entrypoint to some strange extra decrypting function (such as decrypting the UPX sections first before calling the UPX Unpacker stub - for example via XOR) it will be flagged as PE_Patch. Basically that means a second or third etc layer before the "real" entrypoint. <-QUOTE}

Some flag it like this, some like KAV also try to properly decompress PE_Patched stuff (and also clearly show that to user). Thats why we see PE_Patch in the scan logs almost all the time since almost all samples today are obscured one or another way...

[Inspector Clouseau]

{QUOTE-> Some flag it like this, some like KAV also try to properly decompress PE_Patched stuff (and also clearly show that to user). Thats why we see PE_Patch in the scan logs almost all the time since almost all samples today are obscured one or another way... <-QUOTE}

Partly wrong ;D

Others can decompress that too via Emulation. You just have to "collect" the instruction flow from the emulator and you can easily detect such things. There is no particular "signature" for PE_Patch since it can be done in many different ways eg. XOR, ROL, ADD, SUB etc. etc. etc.

[Firecat]

{QUOTE-> Wrong. Even total wrong. PE_Patch is a synonym for additional patched files after runtime packing for example. If you pack a file with UPX and redirect the Entrypoint to some strange extra decrypting function (such as decrypting the UPX sections first before calling the UPX Unpacker stub - for example via XOR) it will be flagged as PE_Patch. Basically that means a second or third etc layer before the "real" entrypoint. <-QUOTE}
I made that conclusion based on searching for the KAV name of it - Trojan.Win32.Patched.something - KAV's viruslist said something like that. :)

But then, is "PEPatch" the same thing as "PE_Patch"? Because the underscore is NOT there in the AVG detections. ???

[Firecat]

{QUOTE-> Firecat, those variant packer detections are most probably just packer detections with dependences. McAfee is using similar (well at least i know they used to in the past). It was like this:

Packer: UPack -> YES
File size treshold: 200KB
+ some extra internal characteristics

If you had UPack packed file taht was 1,1MB in size, McAfee left it out since UPack packed worms/trojans were never this big (because of transportation reasons).
If you had UPack packd executable with size of 55KB, McAfee jumped with name like New malware.u (just example).
So it's not a fully aggressive packer detection that will jump on any packed file but it was more selective, resulting in less false alarms than lets say QuickHeal that jumps on any runtime packed file regardless of ther characteristics. Pack Notepad.exe with more exotic packers and it'll be always flagged as malware. <-QUOTE}
Thanks for this info, I think you are right. In any case, I've noticed those two detections from AVG, and those are packer based detections and thats the point I wanted to make. ;D

[lucas1985]

{QUOTE-> And regarding the topic - you can "easily" bypass *ANY* Security Software. <-QUOTE}
How is it possible to bypass a whitelist, assuming that the whitelist was done on a clean system?

Which name does VBA32 use to flag packers?
And ClamAV? ;D

[RejZoR]

PEPatch or PE_Patch is the same thing. It's just the way how we write it ;)

[FRug]

lucas1985:
For executables that depends on the method used for doing the whitelisting. However whitelisting is by default still vulnerable to exploits, in-memory execution (see i.e Win32/CodeRed http://www.viruslist.com/en/viruses/encyclopedia?virusid=23374), Malware that is not in binary executables like scripts (VBS, Batch etc.), or Macro Viruses for dozens of applications.

Whitelisting isn't the holy grail either, you know. And you can't do it on a corporate gateway.

[solcroft]

{QUOTE-> And regarding the topic - you can "easily" bypass *ANY* Security Software. And if there are only 2 known and verified options how to do that the next moronish user who has absolutely no idea what hes doing will find a 3rd one by accident. <-QUOTE}
And so I think the question is: what are the security vendors doing about it? Other than labeling people who discover loopholes and bring them to attention as "moronish", I mean?

[FRug]

Let us face a few things:

- It is always easier to demand a solution to a problem, than to come up with one.
- It is always easier to come up with a solution to a problem if you do not have to adhere to the laws and boundaries of reality.
- The first and second law of thermodynamics do not apply to the proud citizens of planet Moron.

IT security people are working on edge between ultimate protection and what reality demands concerning usabilty, performance and available ressources. To drive the point home, Microsoft has delivered the ultimate software tools to protect your computer from attacks decades ago with one of its first operating systems. They were, and still are, called FORMAT.COM and FDISK.

Now admittedly these tools have a few drawbacks when it comes to usability, but you can't get any safer than that on a software level.

[solcroft]

{QUOTE-> Let us face a few things:

- It is always easier to demand a solution to a problem, than to come up with one.
- It is always easier to come up with a solution to a problem if you do not have to adhere to the laws and boundaries of reality.
- The first and second law of thermodynamics do not apply to the proud citizens of planet Moron. <-QUOTE}
While true, I don't think it's healthy for any security vendor to dismiss user concerns with pomp and sarcasm. Acknowledging a challenge with fulfilling a duty doesn't mean one is necessarily exempted from doing anything about it.

[FRug]

{QUOTE-> While true, I don't think it's healthy for any security vendor to dismiss user concerns with pomp and sarcasm. Acknowledging a challenge with fulfilling a duty doesn't mean one is necessarily exempted from doing anything about it. <-QUOTE}
Repeatedly stating the obvious is a waste of time. Telling everyone exactly what they're doing every time someone asks about "doing something against random obvious fact" in a random forum is a waste of time AND a security risk since it may show new ways of circumvention. Security by obscurity may by principle be a bad idea, however when you're at war, would you send the enemy your battle plans (i'm a pacifist btw.)? All discussions you see here, or on any other public forum, are only tipping the surface of the pond. People need to realize that they won't be spoonfed personally on a daily basis, this has nothing to do with pomp or arrogance. Look at ClamAVs results in tests, it sucks. It will never have proactive detection, it will never make use of emulation for proactive detection. It has about 3 or 4 poly virus detections. Why? Because making the non-obvious tools of the trade - the battle plans and tactics - public would render them useless to a large proportion of new malware within hours.

[Inspector Clouseau]

{QUOTE-> And so I think the question is: what are the security vendors doing about it? Other than labeling people who discover loopholes and bring them to attention as "moronish", I mean? <-QUOTE}

You don't understand. I never said that they are "moronish" BECAUSE they discovered it. I said they were BEFORE. To underline that a very DUMB user can find one other solution to bypass that by ACCIDENT. That's a big difference so please don't flip the words. Next thing is that AV Vendors *RELYING* also on other companies. Microsoft for instance. So if there is a flaw within the OS it might affect the AV programs as well.

[solcroft]

{QUOTE-> Repeatedly stating the obvious is a waste of time. Telling everyone exactly what they're doing every time someone asks about "doing something against random obvious fact" in a random forum is a waste of time AND a security risk since it may show new ways of circumvention. Security by obscurity may by principle be a bad idea, however when you're at war, would you send the enemy your battle plans (i'm a pacifist btw.)? All discussions you see here, or on any other public forum, are only tipping the surface of the pond. People need to realize that they won't be spoonfed personally on a daily basis, this has nothing to do with pomp or arrogance. Look at ClamAVs results in tests, it sucks. It will never have proactive detection, it will never make use of emulation for proactive detection. It has about 3 or 4 poly virus detections. Why? Because making the non-obvious tools of the trade - the battle plans and tactics - public would render them useless to a large proportion of new malware within hours. <-QUOTE}
Please don't twist my words or put them into my mouth. Show me exactly where I expected security vendors to outline the technical details to the public of how they intend to rectify a specific position. All I can say is that since all you are doing is responding to something I have never said, your post is completely irrelevent in this context and proves nothing.

[solcroft]

{QUOTE-> You don't understand. I never said that they are "moronish" BECAUSE they discovered it. I said they were BEFORE. To underline that a very DUMB user can find one other solution to bypass that by ACCIDENT. That's a big difference so please don't flip the words. Next thing is that AV Vendors *RELYING* also on other companies. Microsoft for instance. So if there is a flaw within the OS it might affect the AV programs as well. <-QUOTE}
If a very smart and technically-inclined person spends hours or days crafting and fine-tuning code in such a way as to evade mainstream scanners, then your response might be justified. If a VERY DUMB user (so to speak) can discover a way to bypass security products, a way that anyone with minimal technical know-how can easily perform as well, then in my point of view what the vendors need to do is to sit up and take notice of that flaw.

Or am I missing something here, and all that security vendors are expected to do is to shrug and say "well, it happens"?

[FRug]

So would an answer along the lines of "Yup, we know. We are working on something." be satisfactory to those asking these questions? What do you think?
My bet is, it would lead to more questions. "When?" "How?" "Why does it take so long?" "Don't you care what happens in the meantime?"

I don't want to attack you personally, nor was it intended as a direct reply to the point you tried making with what i quoted from you (quoting was probably a bad idea, since the reply went off track after a few lines). I am trying to make people aware that if companies chose not to disclose too much information, that may be in the best interest of the user or sometimes because of strict company policies and classified information.

That's not meant as a "mind your own business" or "you're an idiot because this will cause me to do overtime yet again". I just want people to keep in mind that, on the other end are people too. As far as I know all of them have one brain, a set of arms with attached hands and the rest of them doesn't look very much like mutant super powers either.

[solcroft]

{QUOTE-> So would an answer along the lines of "Yup, we know. We are working on something." be satisfactory to those asking these questions? What do you think?
My bet is, it would lead to more questions. "When?" "How?" "Why does it take so long?" "Don't you care what happens in the meantime?" <-QUOTE}
To be brutally honest: I do not care about the tough questions security vendors face, and, I think, neither do most people. It's what they do for a living, and it's how they will be judged. But despite this, suffice to say I have seen vendors who do know how to respond to such issues in a responsible manner; difficult as you try to make it sound, it's far from impossible, and perhaps it's what sets the excellent vendors apart from the mediocre ones.

[Inspector Clouseau]

{QUOTE-> If a very smart and technically-inclined person spends hours or days crafting and fine-tuning code in such a way as to evade mainstream scanners, then your response might be justified. If a VERY DUMB user (so to speak) can discover a way to bypass security products, a way that anyone with minimal technical know-how can easily perform as well, then in my point of view what the vendors need to do is to sit up and take notice of that flaw.

Or am I missing something here, and all that security vendors are expected to do is to shrug and say "well, it happens"? <-QUOTE}

You still don't get it. And i'm not going to explain that again.

[solcroft]

{QUOTE-> You still don't get it. And i'm not going to explain that again. <-QUOTE}
You don't have to. I think I get the picture.

[FRug]

solcroft: I'm still feeling I pissed you off personally, that has not been my intention. I am not sure what cases of reasonable responses you may refer to, so I can't judge their actual merit. I'm certain some people have found kinder words to soothe people's minds than I do, and I am certain that in many cases they have actually been beneficial to both sides. Hell, I am not bashing anyone who's just trying to be helpful and points out something he think is wrong or flawed. However I have the feeling that going in circles has seldom led anyone to his preferred destination (unless the destination was on the path of the circle).

The initial question was how easily AVIRA can be bypassed, and my answer would be: Just as easily as any other security solution, if you know what you're doing. If you don't know what you're doing, you might stumble over something that works for some vendors to remain undetected until they get the sample in their hands, while others may use this very little trick you came up with to actually detect the newly created malware proactively. Thanks to sites like virustotal and jotti it is easier than ever for malware authors to test their creations for detection. Feeling a bit insecure is better than feeling that you are 100% protected. Because the latter is, in reality, always a wrong and dangerous assumption. Being paranoid about your security is a quite reasonable stance nowadays.

Issues like run time packer support always are and always will be problematic for ALL vendors, no matter how many they add (there are thousands of public and private builds of packers, and they get patched, customized, modified and adapted constantly), no matter how generic their unpacking, and no matter how they call their next big Cool Mega Detection Technology (no pun towards panda intended).
There is no "Solution (TM)" in IT Security, and there never will be. Even Trusted Computing with hardwired on chip logic has its limitations.
And there are a good many reasons against Trusted Computing as well.

These are fundamental technical truths, they always will be. And no amount of work, no amount of blood and sweat or marketing will change the fact that they are facing an enemy who is just as ready and willing to counter every effort security vendors make as they are to add new protection technology.

Two industries with conflicting interests are fighting each other. On the one side the security industry who tries to protect users, the other side is the more and more organized fraud and spam mafia who tries to exploit them and to steal whatever information and money they can get their hands on. The importance of closet nerds who write proof of concept viruses for fun has pretty much descended to zero.

There is truth to what you say, the average user does not care about the difficulties vendors face. However I still think some education is required to keep people safe(r) than they are by blindly trusting any security solution. I also believe that knowing the limitations of security software is part of that.

My point is we all have to abide the laws of reality. No amount of ranting, wishful thinking or marketing will change that.

[solcroft]

{QUOTE-> The initial question was how easily AVIRA can be bypassed, and my answer would be: Just as easily as any other security solution, if you know what you're doing. If you don't know what you're doing, you might stumble over something that works for some vendors to remain undetected until they get the sample in their hands, while others may use this very little trick you came up with to actually detect the newly created malware proactively. <-QUOTE}
I think my opinions about this issue have been summarized up quite nicely in post #30. It's all nice and good to be aware of the technical difficulties vendors face, but at the end of the day the important issue is always: what are they doing about it?

And if what some vendors doing about it is to gripe and moan about how "that's just the way things inevitably are", well...

[FRug]

Would you prefer them to lie so you can sleep better? I'm not saying they're not doing anything, I'm saying that the work never ends. There is no ultimate solution to all problems.

I am not sure what kind of response you actually expect to get. Would a standard answer like 'we are working on this and similar issues' be sufficient for you? I mean dealing with these things is their daily business, I'm not sure whether each and every improvement they come up with requires a press-release :)

[solcroft]

{QUOTE-> Would you prefer them to lie so you can sleep better? I'm not saying they're not doing anything, I'm saying that the work never ends. There is no ultimate solution to all problems.

I am not sure what kind of response you actually expect to get. Would a 'we are working on this and similar issues' be sufficient for you? <-QUOTE}
All things considered, I'd expect no less from any self-respecting security vendor. Also, fixing vulnerabilities in their software has little to do with press releases and media coverage, as you seem to be insinuating.

While what you say is true regarding the problems vendors face, it is unfortunately largely irrelevent to the rest of us. Users will switch to and use products that they feel provide the best protection, while malware authors will continue to do what they do, without giving much thought to how tough things must be for those in the anti-malware field.

[FRug]

I think Malware Authors DO give much thought on how hard it is for security vendors. It's part of the problem :)

[solcroft]

{QUOTE-> I think Malware Authors DO give much thought on how hard it is for security vendors. It's part of the problem :) <-QUOTE}
On second thought, maybe they do. I doubt there's a lot of sympathy involved in it, though.

[FRug]

This may be a bit far fetched, but organized crime being on the rise with malware/fraud and the money losses caused to them by security vendors leaves a bit of a bad feeling...

[lucas1985]

{QUOTE-> For executables that depends on the method used for doing the whitelisting. <-QUOTE}
What about Anti-Executable (http://urs2.net/rsj/computing/tests/AE_install/)? Doesn't a HIPS like Process Guard free intercept all execution attempts?
{QUOTE-> However whitelisting is by default still vulnerable to exploits <-QUOTE}
- Good patching policy.
- Hardware-enforced DEP.
- ASLR.
- Hardening.
{QUOTE-> in-memory execution (see i.e Win32/CodeRed http://www.viruslist.com/en/viruses/encyclopedia?virusid=23374) <-QUOTE}
- Firewall.
- Patching.
{QUOTE-> Malware that is not in binary executables like scripts (VBS, Batch etc.), or Macro Viruses for dozens of applications. <-QUOTE}
- Script Defender.
- Document viewers that don't execute macros by default.
- Scanning at Virustotal/Jotti if the documents are small.
- Execution in a VM.
{QUOTE-> Whitelisting isn't the holy grail either, you know. <-QUOTE}
There's no 100 % security.
{QUOTE-> And you can't do it on a corporate gateway. <-QUOTE}
For the corporate gateway, we have Fortinet, eSafe and Webwasher ;D
Thanks FRug :)

[FRug]

Damn I had a long reply on your post, but closed the wrong window. I'm only giving a short comment instead now since it's getting late here....

This is going to be a bit tough anyway :) However if people adhered to each and every advice/technique you have listed they'd probably be fairly safe from random attacks (which is what people mostly are affected by).
Most of my comments below would require very deep knowledge to be used effectively against someone, and I'd not expect more than a few dozen of people in the world would be able to carry them out. I don't count government agencies into that number though, I'm pretty certain they have a bunch of people knowing about this stuff too.

On AntiExecutable/Process Guard:
I haven't tested AE yet, Process Guard has successfully been circumvented in the past, I am not sure about the current state though and whether these issues have been fixed. The previous attacks removed PGs IDT Hooks as far as I can remember.

On DEP:
DEP as implemented by Windows XP SP2 has successfully been bypassed by attacking internal loookaside lists and patching them with faked return addresses. DEP usually causes a slight slowdown for processes that have it enabled as well.

ASLR:
Certainly a good thing, but I know of bypass mechanisms at least for PaX and Windows. One example is that it is possible to get info about the randomized memory layout by using format string attacks. This way you can find out the address of a library that is vulnerable and a stackframe which you can use to bypass the protection. Additionally on windows, binaries have to built for ASLT support, you cannot enable it on your own for random programs. Let's say it like this, ASLR reduces the chance of a successful exploit. Instead your programs will probably 'just crash'.

Firewalls and Patching with regards to CodeRed-Style attacks:
A firewall certainly won't block the service of a server that you actually want to expose to the public, as it usually is the case with IIS or SQL Servers. The most prominent attacks of this type were codered and sql slammer, both of which were only successful due to unapplied but available patches. A zero day exploit using the same techniques would have caused much more destruction than those two did.

ScriptDefender:
Works based on file extensions as far as I can remember.... file extensions usually are smoke and mirrors. I haven'T had a look at it though, so I can't really give a final verdict.

Execution in a VM:
There are ways to break out of VMWare, I am certain there are ways for VirtualPC as well although I can't remember a concrete example for it. Other VMs probably haven't been considered worth breaking out so far.

[solcroft]

{QUOTE-> There are ways to break out of VMWare, I am certain there are ways for VirtualPC as well although I can't remember a concrete example for it. Other VMs probably haven't been considered worth breaking out so far. <-QUOTE}
Either you get your tech news from paranoid sensationalists... or you're one yourself. Either way, I'd be very interested in any further sources on this one.

[lucas1985]

- Yes, Script Defender works based on file extensions, so it's easy to bypass it. Wormguard is smarter and more powerful, see discussion started in this post (http://www.wilderssecurity.com/showpost.php?p=1002610&postcount=49).
- Well, if something can execute without prompts from a HIPS like PG/SSM, lots of people will be worried ;D
Of course, if you give execution permissions and the malware lands in kernel space, you can say goodbye to your HIPS (kick the driver, restore the SSDT, etc)
Thanks FRug, I really appreciate it.
{QUOTE-> Either you get your tech news from paranoid sensationalists... or you're one yourself. Either way, I'd be very interested in any further sources on this one. <-QUOTE}
Peter Ferrie (http://pferrie.tripod.com/) has some material on attacks to VMs.

[solcroft]

{QUOTE-> Peter Ferrie (http://pferrie.tripod.com/) has some material on attacks to VMs. <-QUOTE}
IIRC, the paper discusses methods to detect the presence of VMs. Which is a far cry from breaking out of the VM, which AFAIK is not possible today, yet.

[lucas1985]

You're right.
See this paper (http://taviso.decsystem.org/virtsec.pdf)

[FRug]

Read the following paper as an example:

http://taviso.decsystem.org/virtsec.pdf

There are a few more issues like the ability of the VM Guest OS to enable deactivated network in the VM to gain full network access of the host, do RPC etc. This is done by abusing the internal management virtual hardware "backdoor" VMWare has. I'm not going to post a link on that one though

[Inspector Clouseau]

{QUOTE-> IIRC, the paper discusses methods to detect the presence of VMs. Which is a far cry from breaking out of the VM, which AFAIK is not possible today, yet. <-QUOTE}

Wrong.
http://www.eweek.com/article2/0,1895,1904647,00.asp

[FRug]

Yikes, Lucas was faster than me :)

[Inspector Clouseau]

Well i had that paper also in mind but decided to link to the eweek article ;D

[FRug]

Anywaaay, sleeping time now. Wanna buy some rare books tomorrow early in the morning :) At least those don't contain exploits that endanger the reader :)
Then again, some of them might be dangerous to the gullible too ;)

[solcroft]

I stand corrected. Looks like the exploit was fixed, though.

[lucas1985]

The question is (IMHO):
Will the folks at VMware be able to release patchs before the creation of exploit code?