Latest IE attack brought by same gang that hacked Google

Enlarge / Identical typos in three separate zero-day attacks are one indication they were carried out by the same hacker gang, dubbed Elderwood.

Active attacks targeting a critical vulnerability in older versions of Microsoft's Internet Explorer browser have been carried out by an experienced gang of hackers. And over the past four years, the group has penetrated the defenses of Google and dozens of other companies using similar zero-day exploits.

The latest attack, which works against current IE versions of 6, 7, and 8, was found late last month on the and, according to a variety of researchers (including Eric Romang and those from the FireEye Malware Research Lab). Such "watering hole" attacks get their name because they attempt to plant drive-by exploits into sites frequented by the people the attackers hope to infect, similar to a hunter targeting its prey as it drinks water.

According to a report issued late last week by researchers from antivirus provider Symantec, the attackers are none other than the Elderwood Gang. That's the same group that used a potent zero-day vulnerability in IE in 2010 to breach the defenses of Google and 34 other companies. As Ars reported in September, Elderwood operatives have since wielded a seemingly unlimited number of previously unknown exploits, mainly in an espionage campaign aimed at collecting source code, engineering blueprints, and other forms of intellectual property.

Read 6 remaining paragraphs | Comments

Snapshot of Virut Botnet After Interruption

In the past, we have written about the file infector known as W32.Virut. We have even provided insight into trying to shut the botnet down. Due to a recent judicial proceeding causing a temporary outage of the Virut command-and-control (C&C) server domains, we were able to gather information on the size and demographics of the botnet by predicting and sinkholing the random domain generator backup. Unfortunately the outage was only temporary, and Virut continues to remain active.

Hardcoded servers and domain generation

Among the C&C servers used by W32.Virut, the domains and are used by the threat in order to receive instructions. However, recent versions have also included a domain generator backup that is used if the hardcoded servers cannot be reached. Symantec's monitoring of Virut observed the long-running Virut C&C domains stopped responding to connecting clients around mid-November 2012, and had a corresponding registrar status change:

Figure 1. Status of known Virut C&C servers changed to “undergoing proceeding”

According to the Domain Name Registry in Poland, if a domain contains the status “is undergoing proceeding” then that means the domain is undergoing a judicial proceeding. Similar changes were observed for other Virut domains.

Sinkholing generated domains

As a result of the C&C servers no longer responding to connecting clients, the Virut clients began using the random domain generator backup. Symantec took advantage of this opportunity to research the domain generator used by Virut and begin sinkholing domains in order to get an estimate of the botnet size.

We managed to sinkhole domains for a period of three days and gathered statistics based on the connections made.

Statistics on Virut botnet

Figure 2. Virut global detections, based on sinkhole data

While Virut detections are spread over the globe, the data indicates concentrations in Egypt, the Indian subcontinent, and Indonesia:

Figure 3. Breakdown of Virut botnet by country

Based on the sinkhole data obtained, the Virut botnet is estimated at approximately 308,000 unique compromised computers that are active on a given day. This estimate is conservative since computers turned off or disconnected from the internet for a given day are not included.

Hardcoded domains return

In early December 2012, WHOIS information for the domain showed a status change away from "undergoing proceeding".

Figure 4. Known Virut C&C server domain now parked as

This domain was parked on December 12. A short time later, the status of the both and domains changed again:

Figure 5. Both and domains back online

On December 26, both hardcoded C&C servers were back online and, on December 28, we began seeing new payloads being pushed to clients in the Virut botnet.

Virut has been observed pushing out many payloads with the functionality to send out email spam for advertisements and fraud, to send emails with malicious attachments pretending to be from the U.S. Postal Service, to perform click fraud, to host an Internet proxy service on the compromised machine, and more. This is nasty malware.

In summary, the hardcoded servers used by Virut were taken offline and the fallback domain generation was resorted to. This fallback algorithm allowed us to gather statistics on the botnet and estimate the size as approximately 308,000 unique Virut clients active in a single day. However, the original hardcoded servers were not permanently taken offline—they came back online in late December—and started distributing new payloads once again, meaning that the botnet remains active.

10 Apache Security and Hardening Tips



The Apache web server is a crucial part of the website infrastructure. It has a number of built in features that can improve your website resistance to attacks. The following document covers a number of steps that will help you to achieve this goal. This document is largely based on the knowledge gathered by our security team and by statistics information revealed by security scanner.

Tip No. 1: Disable Apache Signature and/or Apache Banner

Apache Signature or Apache Banner is basically the same thing. It is an application name together with version name that is printed when performing a web request. Nobody actually needs this information at all, but it is enabled by default. You need to alter the Apache configuration file to disable it.

  • ServerSignature Off
  • ServerTokens ProductOnly

In Ubuntu, you need to change the following file: /etc/apache2/apache2.conf

Double check that ServerSignature and ServerTokens configuration settings are not enabled in some other parts of the configuration file.

Tip No. 2: The Trace HTTP Request

HTTP TRACE request is used to echo back all received information. It can be tricked to print HTTP cookies and as a result steal HTTP session. Basically this request can be used as part of the Cross Site Scripting attack, or XSS. It is recommended to disable it as a security precaution.

Add the following to the web-server’s configuration file. For example alter the following file in Ubuntu: /etc/apache2/apache2.conf .

  • TraceEnable off

Tip 3: Remove PHP scripts that print debug info using phpinfo()

The built-in PHP function phpinfo() prints a lot of interesting internal information about the PHP environment. It can include list of which PHP modules are enabled, and the location of various files on the web-server and other sensitive information. Our web security scanner finds a lot of such files. It is recommended to remove these test files from a production website.

Here is a tip hpw to find such files. Look for the files with the following name: test.php, info.php, i.php and phpinfo.php in your website directory and remove them.

Tip 4: Disable directory indexing

Directory indexing is a features found in every web-server by default. When directory indexing is enabled, the web-site prints a list of files found in the website directories when the default page does not exists (for example index.php). Directories reported can be viewed by any visitor. It is vulnerable in the sense that these directories can contain configuration, private and backup files which can be used by the attackers to take your server under control.

You can fix this problem by disabling the Apache autoindex module. In some Apache installations it is called In Ubuntu, you just need to remove the following files:

  • /etc/apache2/mods-enabled/autoindex.load
  • /etc/apache2/mods-enabled/autoindex.conf

So you can do it running the following commands:

  • rm -f /etc/apache2/mods-enabled/autoindex.load
  • rm -f /etc/apache2/mods-enabled/autoindex.conf

Tip 5: Disable WebDAV

WebDAV is a file access protocol created over HTTP protocol. It allows you to upload and download files, and change file contents from the website. This service is required only in very rare cases. From our experience, this feature was only required to run SVN server (link). Make sure that WebDAV is disabled in production websites. When WebDAV is enabled, the following commands are supported by Apache: OPTIONS, PROPFIND, etc. These commands are sensitive from computer security point of view.

You can fix this problem by disabling Apache dav, dav_fs and dav_lock modules. In Ubuntu you just need to remove the following files:

  • /etc/apache2/mods-enabled/dav.load
  • /etc/apache2/mods-enabled/dav_fs.conf
  • /etc/apache2/mods-enabled/dav_fs.load
  • /etc/apache2/mods-enabled/dav_lock.load

So you can do it running the following commands:

  • rm -f /etc/apache2/mods-enabled/dav.load
  • rm -f /etc/apache2/mods-enabled/dav_fs.conf
  • rm -f /etc/apache2/mods-enabled/dav_fs.load
  • rm -f /etc/apache2/mods-enabled/dav_lock.load

Tip 6: Create a chroot’ed Apache environment

Chroot is a kind of virtual environment supported operating systems such as Linux and FreeBSD. When an application is executed in chrooted environment it has no access to the parent disk and to other recources.

This is a good solution if you want to protect your website from malicious users. The action steps required to create chroot Apache was already covered in a number of websites. For example:

The main hidden issue with chrooted environment is that this environment protects the websites from accessing the operating system’s files. It does not protect one site from another. In other words, if a malicious script located in one site it can access files located on other site because they are located on the same chrooted environment.

A solution to this problem is the following. Create a number of apache instances, each one hosting one website running each one if different chrooted directory. These apache instances will not be able to share IP addresses. You will have to configure different IP for each Apache instance you run.

Tip 7: Enable PHP basedir

PHP has built in a kind of chroot environment. It is called “basedir”. You can configure PHP scripts to access files only in specific directory similar to chroot. Basically you can configure each site to access only files located in that site directory which is a very good idea from the security point of view.

You can add the following lines to the website configuration file or to .htaccess file to enable PHP basedir:

  • Php_value open_basedir /var/www/

This will specify that your PHP scripts can access only specified directories.

Tip 8: Web Stats

Some webmasters install open source tools on their website that analyze web requests and create statistical reports. Access to these webstat scrips is almost never secured with a password. So any visitor can basically view such reports. For example some webmasters install in in the /stats directory accessible by .

Statistical reports contain a lot of sensitive information. For example it can contain hidden file names and directory names, full web requests, search engine keywords, etc… All this information can be used by the malicious users and/or your competitors.

Instead of running a statistics script on your website we recommend that you use Google Analytics. It is a free-of-charge and quality service.

Tip 9: Use Google

Most of the webmasters use common web scripts and CMS or blog software. We recommend you to frequently search for security updates using Google and register for security news at your blog/CMS website.

Tip 10: Additional Steps

If your webserver runs together with MySQL server it brings additional potential security problem. MySQL can read any files located on you server including the one located in different chrooted environments. It happens because of the FILE permission. By default only MySQL root has it. For more info about MySQL security take a look at this article ( link to GreenSQL) .

Install a Database Firewall

Download GreenSQL Express which is a free version of the GreenSQL database firewall.

Install a Web Firewall

Mod_security is a good open source product.

Additional links


Nvidia GPU systems purged of critical security bug

Nvidia engineers have released an update fixing a vulnerability that in some cases allows remote attackers to access super-user computers running the company's graphics cards.

The weekend release of the GeForce 310.90 Driver came 11 days after security researcher Peter Winter-Smith released attack code that exploited the vulnerability. The proof-of-concept code allows attackers to create a super-user account on vulnerable systems that is added to a network's Administrator group, according to SecurityWeek. This allows the account to be accessed remotely.

The vulnerability is especially troublesome for networks operated by large corporations or governmental agencies that have machines using GeForce graphics cards. Attackers who gain low-privileged access to a network can use the vulnerability to gain unfettered access to connected computers. Untrusted users could also use it to escalate privileges available on machines they have access to. The attack reportedly worked on fully updated computers running Microsoft's Windows 7 operating system.

Read 1 remaining paragraphs | Comments