Web Antivirus

Web Services are increasingly becoming an essential part of your everyday life. How much time you spend surfing the internet pages?

To be more specific how much you feel now that Google is too much involved in your daily routine? Can you imagine your life without Google? your search, your Calendar, your email, your blog, ...etc

Well, it seems that you will look for Google to be your web antivirus. Before you access a page, type the url in google search and pray that you won't get "this site may harm your computer".

you have just to obey, otherwise your PC will be affected.

the story begins with researchers from the firm surveyed billions of sites, subjecting 4.5 million pages to "in-depth analysis". Actually they found 450,000 pages guilty.

It is sufficient only one visit from you to make the attacker able to detect and exploit a browser

vulnerability. Therefore, the goal of the attacker becomes identifying web applications with vulnerabilities that enable him to insert small pieces of HTML in web pages.

An example for this is iframes, which can successfully install a malware binary "drive-by-download".
Are the web masters, or the site creators are responsible for this?
The answer is, it is not always the case.

User Contribution

Many web sites feature web applications that allow visitors to contribute their own content. This is often in the form of blogs, profiles, comments, or reviews. they usually support only a limited subset of the hypertext markup language, but in some cases poor sanitization or checking allows users to post or insert arbitrary HTML into web pages.

Advertising
Although web masters have no direct control over the ads themselves, they trust advertisers to show non-malicious content. Sometimes, advertisers rent out part of their advertising space; in this case the web master needs to trust the ads provided from a company that might be trusted by the first advertiser. And so on, you may find nested relations which considered as pitfall in the trust relation by making it a transitive one.

Third-Party Widgets
A third-party widget is an embedded link to an external JavaScript or iframe that a web master uses to provide additional functionality to users. Example for this, Google Analytics :)

Webserver Security

The contents of a web site are only as secure as the set of applications used to deliver the content, including the actual HTTP server, scripting applications (e.g. PHP, ASP etc.) and database backends. If an attacker gains control of a server, he can modify its content to his benefit. For example, he can simply insert the exploit code into the web server’s templating system. As a result, all web pages on that server may start exhibiting malicious behavior. Although we have observed a variety of web server compromises, the most common infection vector is via vulnerable scripting applications. We observed vulnerabilities in phpBB2 or InvisionBoard that enabled an adversary to gain direct access to the underlying operating system. That access can often be escalated to super-user privileges which inturn can be used to compromise any web server running on the compromised host. This type of exploitation is particularly damaging to large virtual hosting farms, turning them into malware distribution centers.

Exploitation Mechanisms
A popular exploit we encountered takes advantage of a vulnerability in Microsoft’s Data Access Components that allows arbitrary code execution on a user’s computer.
Typical steps taken to leverage vulnerability into remote code execution:

• The exploit is delivered to a user’s browser via an iframe on a compromised web page.
• The iframe contains Javascript to instantiate an ActiveX object that is not normally safe for scripting.
• The Javascript makes an XMLHTTP request to retrieve an executable.
• Adodb.stream is used to write the executable to disk.
• A Shell.Application is used to launch the newly written executable.

Another popular exploit is due to a vulnerability in Microsoft’s WebViewFolderIcon. The exploit Javascript uses a technique called "heap spraying" which creates a large number of Javascript string objects on the heap. Each Javascript string contains x86 machine code (shellcode) necessary to download and execute a binary on the exploited system. By spraying the heap, an adversary attempts to create a copy of the shellcode at a known location in memory and then redirects program execution to it.

Detecting Dangerous Pages
Simply, by monitoring the CPU and the processes executed on accessing the page. When some unknown processes are added to the list, this will be a strong sign that a drive-by download has happened.

Google will be more and more involved in our life, it will report to you malicious sites for free....
anyway, it is not a big deal, you can do it yourself for some levels. but there a little bit sophisticated cases when you need multilevel reverse engineering...

source: Google Research Paper

Update: Google online security blog, the latest news and insights from Google on security and safety on the internet.