Antivirus is DEAD!

the problem will always be the user.
big companies stuff there company laptops with tons of security software but always forgot that the user is stupid and clicks on random links.
i disagree about exploits in mac OS being more local exploits.
the exploit shown in a contest a few weeks ago was a remote exploit.
a remote user could take advantage of that exploit and could access anything on that Mac change settings and access any data on it.
lodore

 

Got his paper (PDF)
Thanks.

 

lucas: the point you're missing is that shellcode does not have headers. No MZ, no UPX, no nothing. It's direct CPU opcodes only. You cannot locate shellcode by looking for markers such as those of UPX simply because they don't exist.

 

That´s really evil.

 

The SANS article describes how to find embedded files, which CAN be the case if the exploit/shellcode brings along a file it wants to drop within the word document. But even then it is most likely encrypted and again cannot be found by such an approach. Note that standard embedding mechanisms like OLE used in Word Documents are supported by pretty much every AV out there, but that has usually nothing to do with the type of embedding used by exploits (which can be as simple as just overwriting parts of the real contents of the word document and corrupting it along the way)

 

Lots of things to think about.
So, looking for executables or packers' strings is not reliable.
It's not clear to me if tools like OfficeCat can spot exploit code which isn't present in AV databases.
How many exploits use non-standard embedding mechanisms? Non-standard embedding mechanisms aren't supported by STG: MFC Docfile Viewer, correct?
Thanks FRug

 

Heh. Tell me about it.

You folks still remember what a COM file is, right? Well, a COM file is just like that - no headers, just CPU instructions, smaller than 64 Kb. If the extension is not "COM" do you know what a tremendous nightmare it is for the virus scanner to determine that a file is a COM file? And, of course, moronic testers change the file extensions of the samples in their test sets, and expect our scanners to still be able to scan the files correctly and find the malware inside - for which they usually need to recognize correctly the file type.

There is no fool-proof way of doing it with a program. (A human can disassemble the file and see whether it makes sense - i.e., whether it is a valid program - but that's not something that can be done entirely automatically.) The way our scanner does it is by trying to rule out all other kinds of files it can recognize (usually - by the presence of various headers) and then assume that the file is a COM file.

Really evil, I tell you.

Regards,
Vesselin

 

They are not. Well, I don't know about "tools like that" but OfficeCat isn't. It is a tool for scanning for known Office exploits. They way it does it is by looking for the particular field corruptions used by the known exploits. Our scanner does it the same way. We aren't looking for the shellcode - we're looking for the exploit (i.e., for the data corruption that causes the shellcode to be executed, if present).

Ah, this question doesn't make much sense. There all kinds of exploits - in various applications. Embedding is used mainly by Office. So, a more valid question is "how many Office exploits use non-standard embedding mechanisms".

But that doesn't make much sense, either. First of all, there is no such thing as "standard embedding mechanisms". The various Office programs (and Office-like programs, e.g., WordPad) use more than two dozen different ways for embedding an executable in a document. But the truth is, the exploits practically never use any of them.

To begin with, an exploit doesn't have to drop an executable, as I think I already explained - although most exploits do so, because it's easier. When they do, the executable is usually simply appended to the Office document (often in encrypted form). It's presence can be detected, but it's not easy. There is no field in the OLE2 file (the Office documents are OLE2 files - well, with the exception of Access databases) that says how large the OLE2 file is. You have to compute its physical size from various fields in a horrendously complicated structure and then check whether the computed size is sufficiently smaller than the actual physical size of the file, which would indicate that there is something appended at the end of the OLE2 file. Very, very non-trivial.

In a few cases, the dropped executable is in the middle of one of the streams of the OLE2 file and is even more difficult to spot.

Yet in other (even rarer) cases, the executable has overwritten the OLE2 structures, effectively corrupting them.

If the executable is appended to the OLE2 file, an OLE2 viewer won't see it. If it is in the middle of one of the streams, it will be visible with the tool. If the OLE2 structures are corrupted by being overwritten by the executable, the tool might be unable to even open the file.

Regards,
Vesselin

 

Quite amusing thread, when there has been a web world without an av even several years so far!

Best regards,
Firefighter!