How do security vendors differentiate between various malware?

Infected site percentage rates in real life might be different (higher or lower) than this, for several reasons. The Google study used browsers with apparently no plugins. In real life, most users have Flash, Java, etc, thus increasing the attack surface. The Google study used virtual machines, but some malware detects the presence of virtual machines and avoids behaving maliciously in the presence of one. Finally, the Google study uses random URLS. In real life, some sites are much more popular than others, and thus URL usage is not random.

It's important to mention that this number is not the same as the infection rate, because landing on an infected site does not necessarily lead to an infection, due to the operating environment and types of security measures used.

 

Ironically, my testing period occurred during their time frame:

Regarding my comment:

You said,

I wasn't implying overstating. The study itself is problematic, in my view.
Their data is impressive, and no one doubts the existence of malicious URLs.

Here is the pertinent criteria:

More relevant, it seems to me, would be to set up control groups and monitor what users do during their browsing sessions, noting what search topics yield what results, and the frequency with which the user does indeed click on a malicious URL. This would give readers a look at real-life browsing, and not just a laboratory study.

This is not to discount the millions (by some analyst's data) of computers hooked up to a botnet.
But note the Google Study method:

As I indicated in my above post, this is what I have to do, when testing, in order to get these drive-by thingies to work. In real life, not everyone runs this way. Many I know use another browser, and those using IE7 keep things up-to-date.

Not only that, as I've stated in other places, malware downloaded by remote code execution (drive-by download) is the easiest to defend against with some White List protection in place.

Their definition of drive-by (note that it does not differentiate between various types of malware):

For those with such protection, this is a no-threat.

While these types of Studies are academically impressive, if that amount of time (10 months) to create such a study was spent in educating people as to the "more elaborate defense mechanisms to curtail this rapidly increasing threat," to quote part of their conclusion, it would certainly be time better spent.

Why waste time talking up the statistics of a danger that becomes irrelevant with proper security?
Why not a study showing how Remote Code Execution exploits can be effectively blocked, neutralized?

And, by the way, the defense mechanisms don't have to be elaborate!

----
rich

 

UAC in Vista and SuRun in every NT-based OS have made LUA an option to be considered. The concept of the least privilege is better implemented on Unix-based system, though.

Rich,
Your analysis is biased to your browsing patterns.

So, do you think that the malware gangs serve exploits to Chinese/Russian/Brazilian/Indian poeple running pirated/unpatched systems and they use social engineering tricks to Westerners who happen to be fairly protected thanks to Automatic Updates?
Interesting.

 

Hi, Lucas,

You noticed!

Shouldn't everyone approach security based on their habits and patterns?

Most of the time, notices about this and that exploit are so generically described that the user has no idea how it might affect her/him. When given the opportunity to examine more closely, a better analysis can be gained.


----
rich

 

I think so. However, I think that it's difficult for a novice to know his/her habits and patterns and it's even more difficult for the one trying to help with the setup.
That's why we need statistical data about "trends" on malware spreading to get a "complete picture" of the malware landscape (which I attempted to do in my recent thread). This way, we can know if safe surfing still works (to some extent), if execution control still works, if patching policies are effective at dealing with drive-by downloads, etc.

Agreed. You need to dig a bit to find the real useful information

 

I agree. The Google paper did address this, at least for the population as a whole. On pps. 8-9 the following excerpt is found:

"To study the potential impact of malicious web sites on the end-users, we first examine the fraction of incoming search queries to Google’s search engine that return at least one URL labeled as malicious in the results page. Figure 3 provides a running average of this fraction. The graph shows an increasing trend in the search queries that return at least one malicious result, with an average approaching 1.3% of the overall incoming search queries. This finding is troubling as it shows that a significant fraction of search queries return results that may expose the end-user to exploitation attempts."

"To further understand the importance of this finding, we inspect the prevalence of malicious sites among the links that appear most often in Google search results. From the top one million URLs appearing in the search engine results, about 6,000 belong to sites that have been verified as malicious at some point during our data collection. Upon closer inspection, we found that these sites appear at uniformly distributed ranks within the top million web sites—with the most popular landing page having a rank of 1,588. These results further highlight the significance of the web malware threat as they show the extent of the malware problem; in essence, about 0.6% of the top million URLs that appeared most frequently in Google’s search results led to exposure to malicious activity at some point."

By the way, as of when you did your tests about a year ago, April 2007, approximately 0.35% of Google search queries resulted in at least one malicious URL. As of January 2008, the percentage had more than tripled, to approximately 1.3%.

 

I agree. For the sake of completeness, however, I'd like to point out again that whitelisting protects against the downstream effects of a buffer overflow exploit, but doesn't stop the buffer overflow exploit initial code (called shellcode) from running. If the shellcode directly deleted all of your mp3 files, for example, your whitelist product would not prevent this.

 

Or the shellcode could have a script made to terminate/delete your execution control solution. Once the whitelisting solution is down, the gate is open for malicious binaries.

 

This is true (hopefully one has all mp3 files backed up!)

One who is concerned about such things needs to take other measures, of course. The buffer overflow thread has suggestions.


----
rich

 

That is an interesting scenario indeed!

Can you give an example of how this could be done, and how the person writing the exploit could cover all of the numerous white list solutions available?


----
rich

 

I will agree that this true in a general sense.

However, if you are in a position to work with others, you can help to instill good habits. For example, I suggest to families that they become involved with their kid's school library, and local public library for lists of safe web sites for children's games, educational materials, etc. And to interact with other familes in a like manner.

The parents monitor the on-line activities of the younger children and teach them good habits. Will the children continue in a like manner when they get older and have their own computer? Who knows, but at least the parents have done their part.

Other habits such as "Don't agree to popup notices about computer infections, etc." are better explained with examples, and I like to use real examples when possible. The recent banner ad - flash exploit is a great one. I posted a screen shot of the page in post #26. Meanwhile, I downloaded the page and the .swf file. I've shown this to a few people, letting the .swf file run : it's a very convincing, realistic real-time, but fake, scan. Screen shot:


____________________________________________________________

Then I click on the download button to show the download prompt:


____________________________________________________________

I think that seeing an example of the types of social engineering tricks makes the idea stick better, rather than just a list of "Thou shalt nots..."

I do this with a lot of different types of exploits.

BTW - relating this to the topic of this thread: In using examples such as the above, I never differentiate between malware types with most people. Malware is malware. The goal is prevention, no matter what you call it. What does it matter if you are preventing a virus, trojan, worm, etc? Or spyware, adware? I have found that the terminology tends to confuse people, and certainly instill fear.



----
rich

 

That's a great point. Thus the advisability of making sure your buffer overflow protection is sufficient. I posted advise about this at https://www.wilderssecurity.com/showthread.php?t=207074&page=3.

 

I thought they made dykes for over flow.

 

I was hoping one of you would elaborate on this.

I can think right off hand of 6 whitelisting, or execution protection, solutions, and am curious how such an exploit could terminate all of them.

For example, many have benefited from the discussions on SRP, and I think anyone who uses this protection would be concerned that it could be disabled/terminated by a buffer overflow attack, leaving "the gate open for malicious binaries."


----
rich

 

It would need a very skilled malware writer writing a very targeted exploit. The attacker would need to know your vulnerable apps and the whitelisting/execution control solution you're using. It would be next to impossible if you have a good patching policy and buffer overflow protection (hardware-DEP)
So, I'd say that the possibility of this type of attack (shellcode designed to disable your whitelisting solution and transported in a data filetype exploiting a buffer overflow vulnerability) is very low.

 

I agree. Brilliant malware writers are rare, the majority of malware writers copy malware and make changes to create a variant, these fools only provide the quantity.

 

How about if the buffer overflow initial code (the shellcode) restores the kernel-mode hooks that your security products use to detect changes on the system, thus possibly neutralizing your security products? This is a general method. See http://membres.lycos.fr/nicmtests/Unhookers/unhooking_tests.htm for more information. According to the DefenseWall creator, this is possible to do without needing to load a driver first - see https://www.wilderssecurity.com/showpost.php?p=1050955&postcount=94. Maybe your security products can defend against this, or maybe they cannot.

I see that lucas1985 also spoke of this possibility already at https://www.wilderssecurity.com/showthread.php?t=171576&page=17.

 

It is my understanding that nicM used binary executables, and not shell code.
See https://www.wilderssecurity.com/showthread.php?t=180969

Post #8 by Peter2150:

and Post #14 response by nicM:

And he did add to his test page:

So, he is in fact tesing HIPS action after an executable is allowed to run.

The impetus for this was a couple of months earlier in this thread by nicM:

Process Guard Rootkit prevention - in need of an update?
https://www.wilderssecurity.com/showthread.php?t=174012

The misunderstanding was whether PG's blocking of the executable from running counted as Rootkit Prevention, thus passing the test. See post #4 by fcukdat:

But since nicM is testing HIPS action after a malicious executable is launched, PG clearly fails the test. However, the definition of "prevention" was never agreed upon in the thread.

..................

Back to buffer overflow: I would like to see a current exploit which can disable execution prevention in both OS protection, such as LUA and SRP, and also the many HIPS and other products which do the same.

Meanwhile, we seem to have gotten off topic in this thread, so if we can go to the buffer overflow thread:

https://www.wilderssecurity.com/showthread.php?t=207074&page=4

I've responded to your last post, and asked if anyone can add to the list of browser addons in my post #86.

thanks,


----
rich

 

Things are changing. From http://ddanchev.blogspot.com/2008/03/massive-iframe-seo-poisoning-attack.html, we find out some high-profile Western sites recently infected: "USAToday.com, ABCNews.com, News.com, Target.com, Packard Bell.com, Walmart.com, Rediff.com, MiamiHerald.com, Bloomingdales.com, PatentStorm.us, WebShots.com, Sears.com, Forbes.com, Ugo.com, Bartleby.com, Linkedwords.com, Circuitcity.com, Allwords.com, Blogdigger.com, Epinions.com, Buyersindex.com, Jcpenney.com, Nakido.com, Uvm.edu, hobbes.nmsu.edu, jurist.law.pitt.edu, boisestate.edu."

From Sophos 2008 first quarter security report (http://www.sophos.com/pressoffice/news/articles/2008/04/secrep08q1.html):

 

I didn't see CNN News site added but i got Iframed to pieces one day just trying to check the latest news article. Ended up having to reboot my machine, IE of course was the target since i use it. CNN was definitely exploited. This happened the very next day after the Tornado had hit the CNN building and the rest of Atlanta Georgia during the SEC Playoffs.

Surprised me i'll say.

 

There's even an automated way now to generate the exploit from the patch. The exploit applies to the old version though, not the new one, unless the issues weren't properly fixed in the new version.

 

EASTER, your anti-Microsoft-ism is sometimes amusing. At other times it defies plain logic and common sense. You will accept anything at face value as long as it perpetuates your beliefs, without pausing and thinking, "Now just wait a minute, this doesn't make any sense at all."

Suffice to say that it is very unlikely indeed for the events, as you interpret them, to happen. What Fly was referring to, was that hackers reverse-engineered security patches to find out what the patches fixed, and wrote targeted exploits for that flaw in hopes of catching people who still hadn't yet applied the patch. In which case it becomes even more crucial to keep oneself patched, instead of avoiding them in the belief that they harbor some sort of bogeyman.

 

Too bad you didn't conduct your test this past week. 500,000 legitimate sites were hacked to serve malware. See https://www.wilderssecurity.com/showthread.php?t=207455 for discussion, including the specific browser-based exploits used. If you're using Internet Explorer, think about setting Internet Zone security to High to turn off ActiveX.

 

Your false accusations are purely full of sh*t solcroft and you are in sore need of professional correction.

All you seem to do consistently is stalk not just my post with negative connotations and downplaying others experiences but personally like them i about had it up to here with your relentless lame kiddish behaviors and foolish nonsense false accusations, others might praise your so-called knowledge regarding various products and your own interpretations which are your own personal opinions by the way, and not always as right as you might like to think they are, and although you do prove skilled at convincing others in an effort to persuade them that your opinion is oddly without error, but everybody else who constructively challenges your BELIEFS or corrects your wrong impressions you find it easy to dismiss them as lacking something you think you have that they don't.

So if you have any reasonable bone left anymore it would do you much better to be more civil and less confrontational and hop off that horse because everyone is entitled to their own opinions of the products they use and are completely justified in either their approval or disapproval of them, including Operating Systems. If you want to spout off about anti-microsoft find Linux and Unbuntu etc. users to write your disputes to, because as i said too many times before like a broken record, while i myself harbor many disagreements with MS policy i still support their O/S NT Systems or i wouldn't be using them. Does that not sink in at all?

 

Which have been misguided, incorrect, and unfair on more than a few occassions...

Without resorting to your froth-at-the-mouth, spittle-flying fury, I'll just present the facts as they are:

http://www.cs.cmu.edu/~dbrumley/pubs/apeg.pdf
http://erratasec.blogspot.com/2008/04/automatic-patch-based-exploit.html
http://www.securityfocus.com/news/11514

There are a few other interesting papers, but since they contain intimate details on how to accomplish the feat they describe, I think they're not suitable for public posting here. Suffice to say that it's a good idea to keep up with patches regularly, since some groups of black-hat hackers target the demographic that doesn't do so.