Antivirus is DEAD!

Discussion in 'other anti-virus software' started by farmerlee, Feb 10, 2007.

Thread Status:
Not open for further replies.
  1. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Then Mike's other points still stand. :) There is no easy way of preventing execution of malicious code without making the system unusable (e.g., by preventing access to documents and pictures). And the average user is not qualified to maintain a local WhiteList.

    Well, that's precisely the technique, isn't it? An exploit launching an external executable - it doesn't really matter whether it is calc.exe or a Trojan. That's easy to block. But there are alternative ways. The shellcode can cause damage all by itsellf (e.g., delete your files) - without launching any external executables.

    Yes, a combination of the two is viable - provided that the whitelist part can be tolerated or enforced. Sadly, in many environments this isn't the case.

    The bad guys use this approach because it works well against the AV programs most people are using. If most people start using whitelisting, the bad guys will switch to methods of attack that work well against them.

    Regards,
    Vesselin
     
  2. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    False. An MZ header identifies only EXE files, it has to be at the very beginning and it can be "ZM" too. There are many other kinds of executables.

    False. Detecting that an executable is encrypted (or packed) is actually pretty trivial most of the time. Just ZIP it. If the compression ratio is small (i.e., the executable doesn't compress well), then it is either encrypted or compressed (or both).

    The real difficulty is in determining what is executable and in finding the shellcode in a data file that contains an exploit. The first is impossible in the general case (due to the von Neumann principle) and the second requires a lot of knowledge and experience.

    Regards,
    Vesselin
     
  3. Inspector Clouseau

    Inspector Clouseau AV Expert

    Joined:
    Apr 2, 2006
    Posts:
    1,329
    Location:
    Maidenhead, UK
    Yub. There we go. It's similar to the question why is there less malware for OSX than for Windows. Is it because it's more difficult to develop malware for OSX? Certainly not. Is it because malware wouldn't run under OSX? That's also bullshit. So why is it like this? Because OSX is a minor, not so widely used operating system as windows (yet). Keep in mind that a lot of malware is nowdays MONEY-FOCUSED! If it's money focused they make sure that it's as much as effective as it could be. Let's assume that OSX would hold around 50 percent market share of OS. Then you would have *PRETTY FAST* new malware daily for OSX as well. Because they know they would have lot's of new "customers" for their malware creations and develop them also for this platform (because it makes then sense!)

    What do i want to say with this? That there is *ALWAYS* at least one weak point in a security solution. And if one solution (not speaking about a single product here, but about a technology) has a primary market share then they're "exploiting" this technologies weak points. Same as chess. Attack the opponent at his weak points first and don't try to enter fully defended castle-edge straight. And exactly this will happen with whitelist also. It is A FACT that it can't fully protect against all malware! The malware will not stop, they will only become "focused" on bypassing whitelist with the above stated tricks. Of course nobody from the amateurish magazine writers takes this into consideration. And especially Bloor of course not. Because he would have to admit that he's a moron.
     
  4. Inspector Clouseau

    Inspector Clouseau AV Expert

    Joined:
    Apr 2, 2006
    Posts:
    1,329
    Location:
    Maidenhead, UK
    He was speaking about detecting shellcode INSIDE files and not how to detect encrypted files. Encrypted files you can easily determine with several methods. One is for example to have a look in the section headers for RAW size vs. Virtual Size. Or to check for imports. If it's basically only using GetProcAddress / LoadLibrary and very few kernel functions then it's a sign that a file could be runtime compressed etc.
     
  5. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Do you really understand how it does that? If yes, explain it here and I'll explain you how it can be bypassed. If not, then the argument is worthless, because you don't really understand how the program works and what its flaws are.

    When the JPG exploit was discovered, I expected to see scores of viruses based on it. Didn't happen - there was only one virus using it and even it didn't rely mainly on it. However, after the WMF exploit was discovered, I saw HUNDREDS of malicious WMF files. So, trust me, malicious image files are used in the real world.

    Regards,
    Vesselin
     
  6. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Yes, but how are you going to achie ve that? There are only two ways. One is, you get that list built by somebody else (a security software provider). Since, sadly, you aren't the only computer user in the world and that security software provider would like to sell his products to more than just you, they will have to build a global white list of all known good software - i.e., we're back to square one.

    The other way is, you build that list yourself. Which assumes that you have the competence to do so - i.e., to decide which executables are malicious and which are not. If you're one of the few people who can do that - more power to you. Unfortunately, that puts you in a vanishingly small minority of users.

    The above presumes that (a) you can determine which objects can contain executable code and (b) you can afford to deny access to all such unknown objects, even if they only extremely rarely contain executable code.

    Sadly, in the real world neither of the above presumptions is reallistic.

    That's pretty easy to do. Unfortunately, it's not worth the effort doing, since you're probably the only one who will be buying (and willing to use) such a product.

    Yes, access to that Word document the boss just sent by e-mail about the next urgent meeting will be denied silently. Very useful.

    Regards,
    Vesselin
     
  7. FRug

    FRug Registered Member

    Joined:
    Feb 7, 2006
    Posts:
    309
    Actually the email itself will be blocked not only the word document attached to it since it too could contain an exploit... hooray.
     
  8. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    "Signature" is such an ugly and imprecise term. :( Most anti-virus programs stopped replying exclusively on scan trings (which is the slightly more correct term) a couple of decades ago. So, your question doesn't really make sense - a virus scanner doesn't "need a sig to detect an exploit", if that virus scanner doesn't use any signatures to begin with.

    The proper thing to ask is: does a known-malware scanner need to be updated, in order to start detecting a new exploit? The answer to that question is YES. Depending on how exactly the detection is implemented in the particular AV product, it might, or might not need further updating in order to detect other files that contain the same exploit (even if they use different shellcode, drop different executables, etc.).

    It depends what the exploit does. If it does direct damage (e.g., file deletion) then the answer is probably NO. But it might record keystrokes and send them elsewhere instead. Then the answer boils down to what exactly the sandbox allows the applications that run in it to do, and on whether it is possible to bypass it. (For instance, there are ways to "escape" VMWare.)

    Regards,
    Vesselin
     
  9. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    I don't think that anyone claimed that they can't be stopped. The claim was only that they can't be stopped by software that blocks unauthorized executables. There are many ways to stop exploits - hey, even our known-malware scanner stops some of them. (Mostly - Office-related exploits but also some popular ones like the JPG, WMF and ANI exploits.)

    Define "many". I've seen hundreds. That might be "many" to some but it's "few" compared to the half a million of known malware programs.

    Also, exploits are usually (although not exclusively) used by Trojans and less often by viruses. This is because once you implement generic detection of the exploit, any virus relying on it drops dead (i.e., can't infect any more hosts) - while a Trojan author doesn't care; Trojans are usually one-shot weapons anyway.

    Regards,
    Vesselin
     
  10. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Behavior blockers, just like integrity checkers, are a generic anti-malware tool. They have similar strengths and weaknesses with the other generic malware tools. That is, they provide a better protection than a known-malware scanner, but are less easy to use correctly by the average user. Emphasis on "correctly" and "average user". ;)

    Regards,
    Vesselin
     
  11. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Because, although testing known-malware scanners properly is immensely hard, testing properly generic anti-malware tools like behavior blockers and integrity checkers is immensely harder.

    Regards,
    Vesselin
     
  12. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Because by then your precious private data might have disappeared too - or be on its way to Moldova.

    Regards,
    Vesselin
     
  13. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Heh. You don't have to tell me about the deficiencies of the integrity checkers, man, I wrote the book (ok, the paper) on this subject.:D

    And, yes, I do have Peter's book. Personally signed. I was one of the reviewers. The structure of its first part is roughly based on my Ph.D. thesis.:cool:

    Regards,
    Vesselin
     
  14. Inspector Clouseau

    Inspector Clouseau AV Expert

    Joined:
    Apr 2, 2006
    Posts:
    1,329
    Location:
    Maidenhead, UK
    Just a side comment.... Vesselin's post counter goes faster from 0-60 than a sports car... :D
     
  15. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    Nothing is fool-proof, because the fool is always bigger than the proof.:D Besides, the fools are so ingenious!

    But, seriously, which particular proposal of his do you mean?

    Regards,
    Vesselin
     
  16. Inspector Clouseau

    Inspector Clouseau AV Expert

    Joined:
    Apr 2, 2006
    Posts:
    1,329
    Location:
    Maidenhead, UK
    LOL :D If somebody is going to write a historical book, please include this sentence :D
     
  17. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,213
    Hello,

    I'm gonna raise hell now by a little provocative statement:

    Inspector, you mentioned OSX being secure - because it has a minor market share. And that it would sprout tons of malware daily if it got more share.

    I disagree.

    There are technologies and there are technologies.

    There's no doubt that there would be malware - but to far lesser extent, both in quality and quality (severity). One of the reasons is the way the systems were designed.

    Windows exploits are almost exclusively remote. NIX exploits are almost exclusively local. This is the backbone of the doctrines behind each OS, hence the differences.

    There is and cannot be one-to-one translation of Windows problems to OSX or Linux or any NIX-based OS. It's the question of modularity and permissions.

    The greatest hazard for OSX users will be manual downloads and execution. But this is a social problem - not software. Then again, it will be more difficult still due to centralized approach.

    In Windows, you have 50 sources of update for your system. With most NIXs, it's a single centralized source. You would have far less chance of being tempted to download something manually and screw things up.

    It's like saying that helicopters and aircraft suffer from same problems. Yes, both fly, but the way they do it ... that's the whole difference.

    Cheers,
    Mrk
     
  18. FanJ

    FanJ Updates Team

    Joined:
    Feb 9, 2002
    Posts:
    4,638
    Big thanks to Vesselin for this link:
    http://www.people.frisk-software.com/~bontchev/papers/attacks.html

    I will have to find the time to fully read it.

    This part caught my eye (is that the right expression?):
    "2.5. Deleting the Database of Checksums".

    What about this: not deleting the whole database of checksums, but only change a stored checksum of a certain file along with changing that file itself too.
    I posted years ago about it ;)

    =====

    Let’s say program P uses a checksum algorithm (like CRC32 or MD5) to check whether files have been changed.
    Let’s say you want file F to be checked.
    The first time you run program P on file F there will be a checksum C generated.
    Then, after a while, you will check whether file F is changed.
    So you run a second time program P on file F;
    the algorithm used in program P makes a new checksum – let’s say C2 - ;
    the checksums C and C2 are compared;
    and then program P tells you whether file F has been changed or not, depending on whether C and C2 are the same or not.

    So far so good, but the only way program P can perform this, is that it must compare these two checksums C and C2. That means that it after the generation of the first checksum C must store it somewhere….

    Now I have a malicious program M (like some kind of a Trojan).
    Malicious program M looks specific for file F and want to replace it with malicious file MF.
    And malicious program M is made in that way that it already knows that changes in file F are being checked with program P. So it brings together with malicious file MF it’s checksum MC.
    The only thing that malicious program M now has to do is to replace file F with file MF and replace checksum C with checksum MC.
    And there is no way that program P ever can tell you that file F is changed…
    Conclusion: the security that program P with its checksum algorithm can give you, depends heavily on the way how safe it stores checksums.
     
  19. BlueZannetti

    BlueZannetti Registered Member

    Joined:
    Oct 19, 2003
    Posts:
    6,590
    The key operational question would therefore seem to be whether this controlled centralized approach would be scaleable if OSX had the market share, user base, and application base of Windows. I could see pragmatic constraints leading to relaxation of this level of control, which quickly puts you in a Windows-like scenario.

    Blue
     
  20. dan_maran

    dan_maran Registered Member

    Joined:
    Aug 30, 2004
    Posts:
    1,053
    Location:
    98031
    I agee with you here, It would be interesting to see if someone did a malware% versus user base scenario in these respects, I feel percentage wise they would be the same. I thought one was done before but I couldn't find it again. A bit off-topic sorry!
     
    Last edited: Jun 27, 2007
  21. Inspector Clouseau

    Inspector Clouseau AV Expert

    Joined:
    Apr 2, 2006
    Posts:
    1,329
    Location:
    Maidenhead, UK
    I disagree with your disagreement. :D
    I'm using Mac's since they were invented. I *KNOW* how the MacOS / OSX works.

    We're not speaking about exploits only, we're speaking about Malware. Doesn't matter HOW it will reach the system.

    What are you going to do with script based malware? Sure, you cannot so easily erase files or format the HDD, but the stuff it allows is by all means more than enough to do malicious activity.

    Quite funny. What do you think is becoming more and more a serious problem in the windows world? Exactly this! ZLOBS for instance. Manual Download because it claims you have to have it in order to play vidoes. There we go again. You see what i mean with "if it becomes more popular"? Then you would have that crap also for OSX.
     
  22. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    I think it matters a whole deal. I don't think an OS will ever prevent the user of installing software. Since malware is software (or something of the sort), the OS cannot tell the difference. It can however prevent unauthorized installation of malware. That is defense.

    Would an AV still have a function once that OS reach enough market? I think so, for all the other reasons mentioned.
    But if data could not do malicious activities, only programs (data here is docs, etc.), i see a point where a corporation would not need an AV. Maybe :D
     
  23. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,213
    Hello,

    OK then, Inspector, then the problem is ... users. People who download zlobs because they think they need codecs? What can I say more?

    As long as:

    - people are not required to undergo a 'driving test' like with cars.
    - people are not fined with real money for their stupidities with computers.

    There will be people doing things like that.

    Imagine. All the money harvested from people getting infected going to computer education, promotion of anti-malware campaigns, anti-malware warfare - special units that crash into houses / offices and crack down on malware cells and organizations - Jay and Silent Bob style.

    After you get fined several times, you get points - and then you have to undertake the exam again.

    Mrk
     
  24. bontchev

    bontchev AV Expert

    Joined:
    Nov 13, 2005
    Posts:
    38
    This is... not so simple. Well, a detailed treatement of the subject could fill a whole paper.:D

    Basically, in order to do what you propose, the attacker must have two things: the checksumming algorithm and access to the database of checksums. However, if he has even one of these two things, other attacks are possible - so why bother with this one (that requires two)?

    For instance most people are big fans of crypto checksums (MD5 and so on). This is a big mistake. First of all, they are slow. Second, they don't grant additional security. If the attacker has access to the database of checksums, he can put there the checksum of the modified infected object (i.e., the attack you propose) - because the checksum algorithm is already known. OK, some say, we'll deny write access to the database of checksums. But that's not good enough, either. An active malware can go stealth, intercept read access to the database of checksums and replace the results of the read operation with the checksum expected by the integrity checker.

    It is much better to use a simple CRC with an unknown generator polynomial (i.e., one which is different for each instrallation of the integrity checker). True, if the attacker can gather enough file/CRC pairs, he can deduce the generator polynomial. But for that, he has to have at least read access to the database of checksums - and, as we already saw, if this is the case, a crypto checksum ain't gonna help you, either. And CRCs are much faster to compute (i.e., lead to a much more usable program).

    To summarize, the attacker must be given neither the checksum computation algorithm, nor any access (read or write) to the database of checksums. But if these conditions are met, the attack you propose isn't feasible, either.

    It was the late Yisrael Radai who first figured this out. Most of you people here probably haven't even heard his name. It's only dinosaurs like me who've had the pleasure of knowing him personally... He was a great man... The first to analyze and describe the Jerusalem (Friday the 13th) virus - if you remember that one... He had lengthy discussions with the opponents of the "CRC instead of crypto checksums for virus detection purposes" idea - maybe some of them can still be found by Google... Gosh, those were the days...

    Regards,
    Vesselin
     
  25. lucas1985

    lucas1985 Retired Moderator

    Joined:
    Nov 9, 2006
    Posts:
    4,047
    Location:
    France, May 1968
    I've created a thread (Handling of suspicious Office files) where I compiled the procedures given in a SANS.org discussion to deal with Office exploits. I would appreciate if you may find what's wrong with this approach.
    I know that it's useless for the average user, but it may work for the average Wilders member who practices safe hex but doesn't want to attach a debugger to every running app :D
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.