When the Cloud Turns Dark
Securing Web services. Establishing a presence on the
Web, ranging from simple HTML pages to advanced Web
applications, has become an easy process. Even people
with little technical knowledge can set up a Web service,
but maintaining such a service and keeping it secure are
still difficult. Many Web application frameworks require
programmers to follow strict security practices, such as
sanitizing and escaping user input. Unfortunately, as this
burden is put onto the programmer, many Web applications suffer from vulnerabilities that can be remotely
12, 14 For example, SQL injection attacks are made
possible by a programmer neglecting to escape external
Popular Web applications such as bulletin boards
and blogs release security updates frequently, but many
administrators neglect to update their installations. Even
the Web server software itself, such as Apache or IIS, is
often out of date. We previously found that more than
38 percent of Apache installations and 40 percent of PHP
installations in compromised sites were not secure and
were out of date.
To avoid compromising Web applications, it is important to develop mechanisms to keep Web servers and Web
applications automatically patched. Some Web applications already notify Webmasters about security updates,
but the actual installation of security patches is often still
done manually and is complicated.
It is difficult to be completely safe against drive-by
downloads. All that is required for someone to gain control over your system is a single vulnerability. Any piece
of software that is exposed to Web content and not up to
date can become the weakest link.
Many browser plug-ins and add-ons, such as toolbars,
do not provide automatic updates. Furthermore, system
updates often require a restart after installation, discouraging users from applying the security patches on time.
Even if a system is fully patched, the window of vulnerability for some software is often very large. Major
browsers were unsafe for as long as 284 days in 2006, and
for at least 98 days criminals stole personal and financial
data by using vulnerabilities for which no patches were
5, 6 Although progress is being made on providing
fault isolation in browsers that may prevent vulnerabilities from being exploited,1, 4 a completely secure browser
still needs to be developed.
Detecting social-engineering attacks. Many drive-by downloads can be detected automatically via client
honeypots. When adversaries use social engineering
to trick users into installing malicious software, however, automated detection is significantly complicated.
Although user interactions can be simulated by the client
honeypot, a fundamental problem is the user’s expectation about the functionality of a downloaded application
compared with what it actually does. In the video case
described earlier, the user expected to watch a video.
After downloading and installing such a trojan, nothing
usually happens. This could warn the user that something
is amiss and might result in the user trying to fix the system; but the installed software could just as easily play a
video, leaving the user with no reason to suspect that the
system has been infected.
Similarly, some of the fake anti-virus software actually
has some detection capability for old malware. The question then is how to determine if a piece of software functions as advertised. In general, there is no clear answer.
For example, the popular Google toolbar allows a user to
opt into receiving the page rank of a visited page. This
works by sending the current URL to Google and then
returning the associated page rank and displaying it in
the browser. This is a legitimate feature that is desired by
the user, but a similar piece of software might not disclose
its functionality and send all visited URLs to some ominous third party. In that case, we would label the software
Automated analysis2, 9 is more difficult when malicious
activity is triggered only under certain conditions. For
example, some banking trojans watch the URL in the