CSIS study lists the major programs and vulnerabilities targeted by web exploit kits

Discussion in 'other security issues & news' started by MrBrian, Oct 4, 2011.

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

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    From http://www.csis.dk/en/csis/news/3321 (via):
     
  2. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    So basically, use Windows 7, browse with either Chrome, Opera or Safari, and get rid of Java :D
     
  3. SweX

    SweX Registered Member

    Joined:
    Apr 21, 2007
    Posts:
    6,429
    Then I just need to upgrade my OS and get rid of Java and I am good to go, fantastic :D
     
  4. 1chaoticadult

    1chaoticadult Registered Member

    Joined:
    Oct 28, 2010
    Posts:
    2,248
    Location:
    Chaotic Land
    Well get to it :p
     
  5. The Hammer

    The Hammer Registered Member

    Joined:
    May 12, 2005
    Posts:
    5,619
    Location:
    Toronto Canada
    I thought this was about the Canadian Security Intelligence Service.:D
     
  6. SweX

    SweX Registered Member

    Joined:
    Apr 21, 2007
    Posts:
    6,429
    Soon, not yet :D
     
  7. 1chaoticadult

    1chaoticadult Registered Member

    Joined:
    Oct 28, 2010
    Posts:
    2,248
    Location:
    Chaotic Land
    Hehe OK then :D
     
  8. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    Interesting article.

    Yet, Ho hum... another research study with pretty graphs. (Just subsitute the vulnerable software/browser du jour). You may remember about a year ago this month, a research lab provided similar statistics:

    BLADE MALWARE URL ANALYSIS RESULTS
    http://www.blade-defender.org/eval-lab/

    Which leads to another conclusion, that not much has changed:

    • Users do not keep track of updates

    • Users do not have proper protection in place to block these exploits in the kits, which are remote code execution, that is, they are triggered automatically when the victim is led to a compromised web site.

    Several things are always conveniently missing from articles like this. For example, not all vendors have patches/updates readily available upon the appearance of an exploit in the wild (think Adobe in the past), thus creating a window of opportunity (0-day) whereby the user is is vulnerable without other protection in place,

    Zero-Day Attack On Adobe Acrobat And Reader Under Way, But Patch Is Weeks Away
    http://www.darkreading.com/security/attacks-breaches/214502130/index.html
    How many would even know there was an exploit in the wild, unless they read security blogs daily?

    That isn't to say that patching is not necessary, but I don't know anyone who helps others with security, that depends on a program being "patched" as a sure-fire means of protection. There are just too many 0-day occurrences out there to be patch-dependent.

    So, how else to protect?

    Web filtering and Data Execution Prevention (DEP) have been shown to be not reliable in all cases.

    Controlling scripting on web pages works for certain exploits, but is dependent on the user being careful with which web pages are permitted to run scripts.

    While Antivirus products have become very good in many cases, in an article in The Register CSIS research Peter Kruse noted:

    Java, Adobe vulns blamed for Windows malware mayhem
    http://www.theregister.co.uk/2011/09/28/window_malware_infection_exposed/
    The "payload" refers to the executable file that the exploit attempts to install.

    So, I'll paraphrase the opening of the article, which states:

    to:

    "Protection" can come in many ways. One example:

    I'll always remember this from almost 7 years ago, by SecureWave, who advocated (ahead of the times) that systems should be protected from allowing unauthorized executables from installing without permission:

    (Only Microsoft with Software Restriction Policies in WinXP said anything about this earlier)

    Here is an example using an exploit listed in the study.

    CVE-2006-0003 IE MDAC
    This targets IE6, long since patched (2006). Why is this exploit still included 5 years later in the current Exploit Kits? I'll leave that for you to answer!

    The code downloads an executable file, often with a spoofed file extension, then renames the file with the .exe extension and attempts to run it:

    [​IMG]

    Here, the old ProcessGuard blocks, because this svchost.exe is not the correct file, nor is it in its proper location:

    pg.jpg

    and, Software Restriction Policies in action (now AppLocker):

    [​IMG]

    All of the other exploits listed in the article serve up a similar trojan executable file.

    ______________________________________________________________________________

    This article presents excellent research, but:

    • falls short of informing the reader of the potential hazards of depending on patching.

    • does not present any discussion of other preventative measures to protect against the 0-day window of opportunity.


    regards,

    -rich
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Don't they always? :blink:
     
  10. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I don't think the purpose was to show people how to protect against 0-days. Just to show statistics.
     
  11. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Last edited: Oct 5, 2011
  12. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    Very true, but they took the opportunity to mention their own product, so why not reference other articles, sites that go into discussions of prevention?


    regards,

    -rich
     
  13. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,851
    The best you can take from this is keep your software up-to-date. That includes your browser (get off of IE6 already), flash, and yes even Java too.
     
  14. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    You make a good point. Most often, zero-day exploits surface first in targeted attacks. Stuxnet is a good example, which used 3 Windows unpatched vulnerabilities.

    So, I can let CSIS off the hook (a little bit) since they confine their statistics to exploit kits.

    I guess what always irks me about articles like this is that security organizations, like this Danish CSIS, blog about the current security scene, yet, do not offer much in the way of discussion on prevention.

    Yet #2, are often self-serving in mentioning their own product.

    Regards,

    -rich
     
  15. x942

    x942 Guest

    Same here :D I was very confused for a second.
     
  16. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Drive by downloads in Chrome?

    So by drive by downlaods they mean a download is initiated and the user accepts?...
     
  17. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543

    I personally don't see that as a drive by download, but as social engineering.
     
  18. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Me either. But that's what they seem to consider one. I don't know of any drive by downloads that work with Chrome unless they're including plugins.
     
  19. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    It's unfortunate that there is no longer a strict adherence to termininology.

    If you look in the Microsoft Advisories and Bulletins, you don't see the term "drive-by," rather, "remote code execution."

    Strictly speaking, remote code execution means that once the user has gone to a compromised web page, the payload is installed "remotely" -- without any user confirmation.

    Thus, some of the early fake AV exploits fell into this category, and the user was automatically infected unless some protection intervened:

    remote_1.gif

    However, later ones required the user to be tricked and allow the installation.

    Here, javascript code starts the fake scan. Then, a prompt to install eventually comes up, a social engineering situation trying to trick the user:

    remote_2.gif

    Both of the above are commonly termed "drive-by" attacks, but are really quite different.

    All of the exploit kits have PDF exploits remotely (automatically) triggered when the user lands on a compromised web site.

    However, the results of the exploit are vastly different, depending on the user's browser configuration.

    If the PDF plugin is enabled, the PDF file will open in the browser window and execute the code to install the payload executable (barring other protection in place), a true remote code execution exploit:

    [​IMG]

    However, if the plug-in is not enabled, a prompt window will appear, and if the user chooses to open the file, infection will occur, barring other protection in place.

    [​IMG]


    The CSIS study lists three PDF exploits, each a different way of triggering the PDF file to open in a browser.

    How can we know from the statistics in the report, which of the two ways shown above was the means of infection?

    They are all classified as "drive-by" attacks, but we can't really know what actually happened, unless I'm missing something in the report.

    Hungry Man notes that exploits against browsers are often really targeting a plugin. This fact may slip by the casual reader who sees this statement in the report:

    Since the report focuses on exploits against 3rd party software, should we assume that these are not exploits against the browser?

    It's not clear, because this exploit,

    CVE-2006-0003 IE MDAC

    targets the IE6 browser, and not a plugin or other software.



    regards,

    -rich
     
    Last edited by a moderator: Oct 5, 2011
  20. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    Always learning from you, Rmus :thumb: I agree that articles ought not to focus on the browser in these attacks, but what the attack was actually targeting. If it's attacking Java or another common plugin, it's not going to matter what browser you use. Hmm, actually, wouldn't Chrome users get nailed that way too? As far as I know, Java is still not sandboxed like Flash and PDF's are.
     
  21. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Last edited: Oct 5, 2011
  22. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Thank you MrBrian. As far as I know Java breaks at LowIL. I'll give that a read.

    Thank you Rmus. I think they must be talking about plugins. That or they should really make it clear that drive-by exploits include those that need user interaction.
     
  23. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    Thanks for this reminder.

    Browser configuration is becoming more complex with each new generation of versions. Not always easy for the general user to understand.

    regards,

    -rich
     
  24. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,272
    Nice thread. Thanks, Rmus for the explanations in plain language and for the screen shots, which seem to be your trademark here and in many old posts :)
     
  25. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Yes, it squeals like a pig... :argh:
     
Loading...
Thread Status:
Not open for further replies.