Cover Stories

Attackers have an easy time on today's Internet. Intruders of the past needed to circumvent troublesome firewalls and other protective devices, but today, they only need to entice an unsuspecting user into accessing a web server prepared with malware or send a malicious link through email, text, or an instant messaging service. Contact details for reaching the potential victims can usually be retrieved from social networks such as Xing. And QR codes are ideal for distributing malware links: The reader has no way to even guess where the code might by pointing.

Many of these attack methods exploit the fact that Web 2.0 tools are installed on nearly every workstation and mobile device, including a web browser and plugins such as Flash Player, Java, and Adobe Reader. Browsers or plugins almost always contain vulnerabilities that are then exploitable using special attack tools installed on the web server. The goal of these attacks is to infect the client with malware and then misuse the client system by adding it to a botnet or using it as a bridgehead for access to other resources on the network. The attack is usually completely transparent and goes unnoticed by the user. This style of attack is often called a drive-by download (see the "How a Drive-By Attack Works" box). In the opinion of ENISA (European Network and Information Security Agency), drive-by downloads are currently the biggest threat on the Internet [1].

Figure 1: The typical sequence of a drive-by infection.

One reason this new generation of attack techniques is flourishing is because the old generation of tools is so hopelessly underprepared for today's threats. Vulnerabilities in the Java Runtime Environment, for example (and thus for the Java plugin for your web browser), are now almost legendary: For nearly a year, Java has not been out of the headlines. As soon as a security update appears, the next vulnerability is already known – and immediately used.

A March 2013 study by Websense concluded that about 94 percent of all installed Java plugins are out of date [2]. Some government groups, such as Germany's Federal Office for Information Security (BSI), have even recommended disabling Java in the browser, or even better completely uninstalling Java. Exploits based on Flash, Acrobat, and .NET tools are also quite common, and more are appearing every day. To make matters worse, many attacks are launched from ordinary web servers that have fallen under the control of intruders – without the knowledge of the site owner, who continues to operate the site for some otherwise legitimate purpose.

Few users understand the risk of being infected with malicious code at a well-known site. The Websense Threat Report 2012 [3] reports that 82 percent of malicious websites are now run on compromised hosts – the risk of catching malicious code on a reputable site is thus very high. Additionally, web applications often contain well-documented vulnerabilities. A vulnerable web server is easy to find, and attackers find them every day. Preferred targets are outdated versions of PHP or content management systems like WordPress, Joomla, and Typo3. A complete solution to this complex set of problems is not even possible with present technologies, so careful admins must piece together a collection of assorted tools and techniques to keep drive-by intruders off the premises.

Attack Tools

Attackers have plenty of freely available tools to help prepare a web server attack. Hacking toolboxes such as Live CDs of BackTrack [4] or Kali Linux [5] offer a number of programs capable of identifying the type and vulnerabilities of various content management systems (CMSs) in their web application sections. Tools such as sqlninja, which are available from the same sources, then execute the attack on the CMS or its database.

For many years, commercial exploit kits have also been available from various underground markets on the Internet. These commercial kits are kept up to date through standard software maintenance, and some even guarantee the availability of zero-day exploits (i.e., exploits for vulnerabilities about which the software vendor currently still does not even know). The kits that dominated the market years ago, MPack, NeoSploit, Zeus, and Eleonore have now been replaced by second-generation exploit kits.

The new generation includes the Phoenix exploit kit and, especially, the Blackhole exploit kit (BHEK2). Interested parties can rent instances of these attack tools on underground forums on a daily basis (US$ 50 per day, which includes 50,000 hits) or per month (US$ 500 with 70,000 hits) or per year (US$ 1,500 with an unlimited number of domains). A good overview of the state of exploit kit development is given by the Common Exploit Kits 2012 poster [6] and by the Exploit Table 2013 by blogger Mila, which is available as a Google Apps table [7]. The table lists the functions of the different malware kits, with reference to the corresponding CVE ID. (CVE stands for Common Vulnerabilities and Exposures, an industry standard maintained by MITRE Corporation [8] for the unambiguous designation of vulnerabilities in computer systems and software.)

What To Do?

The admin's defense against drive-by attacks falls into three categories:

• Harden web services against exploit kits and drive-by downloads.
• Keep browsers and plugins up to date and educate users about the importance of maintaining security policies.
• Offer safety measures at the border to the Internet (e.g., through the use of URL filtering and virus scanners on the Internet gateway).

You'll learn more about some of these techniques later in this article. However, the entire defense cannot rest on the shoulders of the system administrator. Security should be considered at the beginning of any process, and the most important step is to exercise appropriate care during the development of web applications. The German BSI, in cooperation with security service provider SecureNet, created a catalog of measures and best practices for web application security in 2006 [9]; this catalog provides the information necessary for developers. For prebuilt web applications, appropriate tools for automatic source code security analysis are readily available on the market; examples to be mentioned here include Fortify [10] or IBM's Security AppScan [11].

Of course, most companies and organizations do not develop their own content management systems, stores, and other web applications themselves; rather, they rely on commercial or open source systems. In this case, penetration testing with the appropriate tools can reveal the security status of the web server and the web applications it runs. Google has released the Skipfish [12] security scanner for web applications under Apache License 2.0.

Additionally, the Google Safe Browsing API [13] provides a programming interface for browser makers that checks URLs against Google's constantly updated list of suspicious phishing and malware sites (Figure 2). It pays to check regularly to see whether your own website is blocked. Currently, Chrome, Safari, and Firefox use the Safe Browsing API [14]. You can simply replace mysite.com with your own domain name, or use a known malware domain from the malware domain list [15] for test purposes.

Figure 2: Example output from the Safe Browsing service. This page is identified as a malware propagator.

InitiativeS and the industry association of the Internet industry, eco, offer an online platform that enables companies to check their website security regularly and automatically. Registration is free [16] and only requires access to a specific email address up front for verifying the request (info@domain, webmaster@domain, abuse@domain, or initiative-s@domain). The University of California has developed an analysis tool called Wepawet [17] that handles JavaScript, Flash, and PDF files.

Web Application Firewalls

Although source code analysis and penetration testing might have shown no evidence of vulnerabilities on your systems, this does not mean your own web server will remain permanently free from attack. For active hardening of web servers and web applications, it is a good idea to install a web application firewall (WAF). WAFs examine communication between the web server and the browser at the application level (HTTP, HTTPS) and in this way provide protection against typical attacks such as cross-site scripting (XSS), SQL injection, and other known web application vulnerabilities.

A WAF operates either as a reverse proxy in front of the web server or as a plugin directly on the web server. The most famous WAF from the open source camp is ModSecurity [18], which is available as a plugin for Apache, IIS, and Nginx. You can install ModSecurity using your distribution's package manager. To install the ModSecurity package on Debian/Ubuntu, type:

sudo apt-get install libapache2-modsecurity modsecurity-crs

Also, some manufacturers of UTM firewalls (e.g., Sophos UTM) or load balancers (e.g., Riverbed and F5) offer products with an integrated WAF.