VIPRE: MX-V technology disclosed

Awesome Mike!!

Video available in the Sunbelt blog entry.

 

Interesting and encouraging...

 

Interesting indeed. Would be nice to see more videos of AV experts explaining the technologies. I remember Sunbelt's Eckelberry saying in the VB2008 conference keynote speech that the AV industry has transformed from a secret society into a more open and collaborative industry. I guess this is that kind of openness (be it a marketing video or not).

 

It was rather "difficult" to balance that. I'd loved to be more technical there but it wouldn't have made sense because some people didn't even know what a false positive or polymorphic means. However, it was a great audience and we had lots of fun

 

Interesting presentation. It looks similar to some other virtual environments that have been described in other AV systems (e.g. Norman Sandbox), with the notable exception of the use of dynamic code translation to speed-up the process.

In 2002, Norman published that their sandbox had a speed of ~1MIPS on a Pentium3 700Mhz. That's somewhere between 500 and 2000 times slower than the real CPU, depending on the instruction set considered. In Michael's presentation, he advances a speed of 400MIPS for his Maware eXterminator (talking about decryption loops you comonly find in packers/protectors/anti-emulation systems). I don't know what is the real system corresponding to that figure, but we can guess that it has been measured on modern hardware (on which the 2002 version of Norman's sandbox would have achieved ~10MIPS, i.e. the number given by I.C. as an example), and that it's therefore roughly 20 to 30 times slower than the real CPU. That's a great improvement indeed !

But there's still one open question to which I could not find any answer: is the emulator forwarding at least some of those API calls that have been identified as safe (I mean, those that correspond to "read only operations") to the real operating system ?
Of course, there would be a cost for "merging" the responses of the virtual environment (to which the "write" and "execute" actions of the malware would apply) with those of the real environment (pretty much similar to the fact of adding the name of the simulated process to the process list, as explained by IC in the presentation), but that would make the detection of the emulator "from inside" much more difficult ! The malware would "see" the very true files, processes, etc. without being able to really modify any (although it would think it modified it).

Besides the fact that it requires to identify beforehand those API functions that actually are truly "read only" (i.e. that won't modify the state of the operating system, files, processes, etc, etc. in any way), is there any reason not to use this method ? Is it just to avoid that the malware exploits a potential vulnerability of the OS (e.g. a buffer overflow) from inside the emulator ? Assuming that this is the problem, to what extent (in terms of performance) is it possible to "dynamically translate" or - better in terms of perfs - to "statically translate" the windows API itself inside the emulator ? Aside from the performance issues, Would this make the system potentially exploit-proof (assuming that the translated-API gives control to the real OS when going into kernel-mode) ?

Or is this rather because that technique would (obviously) not work under a non-windows operating system that this technique is not used ?

Now, a "blue sky research" question: will there ever be a use of hardware virtualization (e.g. AMD-V, Intel-VT) for behavior-based antivirus methods ? If a blue-pill can fool anti-viruses, the MatriX-Virtual_machine could probably fool malware, isn't it ?

I'm also interested in the "Conclusion and future views" part of the talk...

 

Amazing, and some of these were supposed to be IT professionals !

Well even though i found it very difficult to understand the accent, i managed to watch the whole thing. Not all at once, as i needed several breaks.

From the general lack of audience response to Inspector Clouseau aka MsN's questions, they where either shy, not usually like Americans, or really didn't know much ! It appeared he was talking over their heads a lot of the time, when delving into the tech. I think a slightly more simpler approach would have been received and understood better.

It's the first time i've seen/heard MsN in action, so it was quite a shock to hear him speak. He seems like a nice guy, and makes the effort to try and ensure it's fairly light hearted as well, which can be good. I noticed he can't help slipping into high tech mode often, but that's cos' he's a very clever coder, and sometimes forgets that we're not.

Vipre itself looks promising, especially as they say it's been written completely from scratch with no legacy code. The main potential innovation i saw was the included VM application to analyse etc potential nasties in real time safely. Of course the analysis needs to be accurate to prevent FP's or misses. Also these days some newer Malware is capable of knowing if it's in a VM and being probed etc. So how does Vipre couteract this ?

I expect it's a work in progress, otherwise Vipre would be up there with best right now. So i'll be keeping my eyes on it to see how it progresses, and i wish them all the best.

 

You answered your own question.... If you want to have that on other OS (Linux, OSX etc) - and we have a linux version too - then you simply can't make use of the real OS API calls because there aren't any when running linux. So yes, everything is custom code in MX-V for those API's.

 

Huh? I did that NOT because i knew it would not be understood there. And honestly... who knows me knows that i simply "refuse" to give sales-pitch speeches. There must be technical backup for everything you can't just flip pages down and say "Look, i don't know myself the facts but believe me it's good". I had a couple of Assembler Listings originally in my presentation (some code that i wrote in the car during driving to Gainsville because the drive was so boring) that i removed on-the-fly during presentation because nobody would have understood that. That actually highlighted with proof why our stuff is different. I only mentioned then the Windows Error Code handling (most of the other emulations just say "Yeah we did this API and there wasn't any error") because i thought that was easy enough to explain and to understand. I skipped the parts when our MX-V directly replaces Anti-Emulation code in the executable... because that was highly technical and would have taken too long.

 

Ve vill dry to emprofe dat. But keep in mind that was a large room, there was echo and it was several times re-encoded. If you watch that live (or as it comes from the camera directly) it's different. Funny thing was all the texas guys didn't have a problem to understand me

 

Well, I think it would make sense to have different versions for servers and gateway (Linux) and for the end-users (Windows), then. I might be wrong but I believe your virtual environment is still very easy to detect from inside (just because it's far from being as complete and complex than a real one). That wouldn't be the case if you were giving the malware a view of the real world.

We had a similar, yet much simpler idea, to get rid of nasty but extremely stubborn people on an web forum. Once reliably identified (e.g. by combination of the use of open proxies, cookies, user-agent, etc) you can silently redirect them their own version of the forum, that contains all the spam and crap they have posted to it. On the other hand, regular users see a clean version in which the spam/offending messages were never posted. Of course, the "trash" version of the forum is also transparently fed by the regular posts as soon as these are submitted (i.e., for them, the "true" environment is read-only, but they can interact only with their own sandbox, which is seemingly embedded in the real environment).

As long as the bad guys think their crap has not been cleaned, they feel they have no reason to disguise (or to change their disguise), in order to post on the forum. And as long as they don't understand the trick, the forum is quiet

 

ROFLMAO @ Malware Extermination - Victory!

Vipre, the Dalek of antiviruses!

The microphone sound is terrible, but it's fun to watch.

(For members not familiar with the series http://www.youtube.com/watch?v=mgZzCrpqT5E&feature=related )

 

So what virus coders are doing when they are still able to bypass latest technologies?

 

More recent update from Inspector Clouseau (about emulation/virtualization technique) here.

 

I just looked for "_AVIRA_21099" string on the norman website. If it is actually the same malware, the first instance of the malware that is accessible has been posted there on the 1rst of October (the number of results returned by the search is apparently limited, so there is no way to check when this malware has actually been seen for the 1rst time), and was detected as W32/Malware. The output log looks actually pretty similar to the one of MX-V.

W32/Malware
NO_VIRUS
[ DetectionInfo ]
* Filename: d:\nad\temp\0\caf4e74871f00e3c367c7b9b7f5f2725.bin.
* Sandbox name: W32/Malware.
* Compressed: NO.
* Signature name: NO_VIRUS
* TLS hooks: NO.
* Executable type: Application.
* Executable file structure: OK.
* Filetype: PE_I386.
[ General information ]
* File length: 459776 bytes.
[ Changes to filesystem ]
* Creates file C:\docume~1\sandbox\APPLIC~1\sdra64.exe.
[ Process/window information ]
* Checks if privilege "SeDebugPrivilege" is available.
* Creates a mutex _AVIRA_21099.
* Enumerates running processes.
* Will automatically restart after boot (I'll be back...).
* Modifies memory in process "explorer.exe".
* Creates a thread in process explorer.exe.
[ Signature Scanning ]
* C:\docume~1\sandbox\APPLIC~1\sdra64.exe (815104 bytes) : no signature detection.


Another interesting log from the sandbox, that shows another ability of these virtual environments (automated interaction with GUI), see elements in bold:


W32/Perfloger.AGR.dropper
NO_VIRUS
[ DetectionInfo ]
* Filename: d:\nad\temp\0\3dfe4c216a2f88a06c5df93e83f204c2.
* Sandbox name: W32/Perfloger.AGR.dropper.
* Compressed: NO.
* Signature name: NO_VIRUS
* TLS hooks: NO.
* Executable type: Application.
* Executable file structure: OK.
* Filetype: PE_I386.
[ General information ]
* File length: 283224 bytes.
* Packer detection: WinRAR 32 bit SFX Module.
[ Changes to filesystem ]
* Creates directory C:.
* Creates directory C:\WINDOWS.
* Creates directory C:\WINDOWS\TEMP.
* Creates directory C:\WINDOWS\TEMP\RarSFX0.
* Creates file C:\WINDOWS\TEMP\RarSFX0\pk.bin.
* Creates file C:\WINDOWS\TEMP\RarSFX0\inst.dat.
* Creates file C:\WINDOWS\TEMP\RarSFX0\bpkhk.dll.
* Creates file C:\WINDOWS\TEMP\RarSFX0\bpk.exe.
* Creates file C:\WINDOWS\TEMP\RarSFX0\NoMoreDc.exe.
* Creates file C:\WINDOWS\TEMP\RarSFX0\rinst.exe.
[ Process/window information ]
* Creates a dialogbox with caption "WinRAR self-extracting archive".
* Buttons found in dialogbox: id102[222,4]"Bro&wse..." id65535[8,35]"" id1[88,169]"Install" id2[148,169]"Cancel" .
* Creates a window with name "".
* Creates a dialogbox with caption "License".
* Buttons found in dialogbox: id65535[5,2]"" id1[91,256]"Accept" id2[151,256]"Decline" .
* Pressing button with id 1 "Accept".
* Pressing button with id 1 "Install".
* Attemps to NULL C:\WINDOWS\TEMP\RarSFX0\rinst.exe NULL.
* Creates process "rinst.exe".
[ Signature Scanning ]
* C:\WINDOWS\TEMP\RarSFX0\pk.bin (7712 bytes) : no signature detection.
* C:\WINDOWS\TEMP\RarSFX0\inst.dat (1376 bytes) : no signature detection.
* C:\WINDOWS\TEMP\RarSFX0\bpkhk.dll (22016 bytes) : no signature detection.
* C:\WINDOWS\TEMP\RarSFX0\bpk.exe (417792 bytes) : no signature detection.
* C:\WINDOWS\TEMP\RarSFX0\NoMoreDc.exe (28672 bytes) : no signature detection.
* C:\WINDOWS\TEMP\RarSFX0\rinst.exe (23040 bytes) : W32/Perfloger.AGR.

Last but not least, the detection of the "type of entry point". Something that can be useful for various tasks (from unpacking to the heuristic - and host dependant - detection of "non entry point obscuring" file infectors, MessageLabs filed a patent on that topic in 2002). I don't know for what purposes it is used by Norman:

[ General information ]
* File length: 311296 bytes.
* Entry-point detection: Microsoft Visual C v7.0.

[ General information ]
* File length: 399872 bytes.
* Entry-point detection: Microsoft Visual C v7.1 EXE

Nice to see that the sandbox is still moving forward...