At 12:00 PM -0600 2/12/07, botnets-request@xxxxxxxxxxxxxxxxxxxxxx wrote:
Message: 1
Date: Mon, 12 Feb 2007 07:34:09 -0600 (CST)
From: Gadi Evron <ge@xxxxxxxxxxxx>
Subject: [botnets] Web Server Botnets and Server Farms as Attack
Platforms
To: botnets@xxxxxxxxxxxxxxxxxxxxxx
Cc: full-disclosure@xxxxxxxxxxxxxxxxx, bugtraq@xxxxxxxxxxxxxxxxx
Message-ID: <Pine.LNX.4.21.0702120719290.14975-100000@xxxxxxxxxxxx>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Are file inclusion vulnerabilitiess equivalent to remote code
execution? Are servers (both Linux and Windows) now the lower hanging
fruit rather than desktop systems?
In the February edition of the Virus Bulletin magazine, we (Kfir
Damari, Noam Rathaus and Gadi Evron (me) of Beyond Security) wrote
an article on cross platform web server malware and their massive use as
botnets, spam bots and generally as attack platforms.
Web security papers deal mostly with secure coding and application
security. In this paper we describe how these are taken to the next level
with live attacks and operational problems service providers deal with
daily.
We discuss how these attacks work using (mainly) file inclusion
vulnerabilities (RFI) and (mainly) PHP shells.
Further, we discuss how ISPs and hosting farms suffer tremendously from
this, and what can be done to combat the threat.
I'd like to write more on this here, and ask for the community's feedback
on what others see in this field and how you deal with similar issues.
Malware is often built to operate within a certain OS environment. Web
server malware is completely cross-platform (as long as a web daemon which
supports scripting can be found such as IIS, Apache, etc.). These malware
attack the web application first, and only then further compromise takes
place platform by platform, using the web server's privileges.
Most web servers are being compromised by these attacks as a result of an
insecure web application written in PHP, although attacks for other
scripting languages such as Perl and ASP are also in-the-wild.
The main reason for this is that many different PHP applications are
available online, and often freely as open source, which makes them a
popular selection for use on many web sites. Another reason for the
popularity of attacks against PHP applications is that writing securely in
PHP is very difficult, which makes most of these PHP applications
vulnerable to multiple attacks, with hundreds of new vulnerabilities
released publicly every month.
While in the past botnets used to be composed of mainly broadband end
users running Windows, today we can see more and more server botnets we
can refer to as "IIS botnets" or "Linux botnets" as a direct result of
these attacks.
One of the conclusions we reached was that although the technologies used
are not new (RFI, PHP shells, etc.) the sheer scale of the problem is
what's interesting.
In our research as detailed in the Virus Bulletin article we recognize
that vulnerabilities such as file inclusion, as simple as they may be, are
equivalent to remote code execution in effect.
Although escalation wars, which are reactive in nature, are a solution we
hate and are stuck with on botnets, spam, fraud and many other fronts,
this front of web server attacks stands completely unopposed and
controlled by the bad guys. In our research we detail how over-time, when
aggregated, most attacks come from the same IP addresses without these
ever getting blocked.
ISPs and hosting farms selling low-cost hosting services can not cope with
this threat, especially where an attack against one user running such an
application can compromise a server running 3000 other sites.
Another issue discussed was
the formation of the Web Honeynet Task Force
( http://www.webhoneynet.net/ renamed from the Web Honeynet Project to
avoid confusion with the honeynet project).
I write more about this and host the paper on my blog at SecuriTeam
( http://blogs.securiteam.com/index.php/archives/815 ). All
rights for the article itself belong to the Virus Bulletin magazine.
Gadi Evron.
In Gadi's email he asks the question, "Are servers now the lower hanging fruit rather than desktop systems?" The real question might have been when were they ever not the low hanging fruit? Servers were the original fruit and were penetrated using open ports and insecure telnet and other applications. Over time these types of exploits have decreased due in increased attention on the part on sever admins to security; however, they still occur as a simple search of the National Vulnerability Database (NVD) will show. As these vulnerabilities decreased, others were on the rise such as web-based, cross platform scripting vulnerabilities that Gadi discussed.
I do not know when web-based, cross platform scripting vulnerabilities actually started. My first run in with this problem was in 1995 with the perl based formmail exploit. This exploit was documented in CVE-1999-0172. Although this was not exactly remote code execution, it did allow a perpetrator to hijack the server to relay spam.
Early examples of server based, cross platform, remote code execution are CVE-1999-0244 and CVE-1999-0260 (CGI exploit), CVE-1999-0279 (shell based), CVE-1999-1053 (perl based), CVE-1999-1293 (webserver exploit) CVE-1999-0067 (authentication buffer overflow exploit) , CVE-1999-0440 (Java Servlet exploit). Unlike desktop systems that require a level of social engineering to infect and require a shotgun approach to infection via spam, malicious websites, and port scan/probes, servers inherently want to be known and accessed which makes them a great static target to be easily analyzed in depth. In his email Gadi states that, " the sheer scale of the problem is what's interesting" and I totally agree. But, it is not surprising. When I hooked my first webserver to the Internet in 1995, it became under attack within 15 minutes of domain registration and the level of probes and attacks have only escalated during the intervening years. WIth the advent of cPanel and other technologies that allow individuals untrained to properly administrate their domain let alone trained to manage security, the number of infected hosts has increased dramatically due to shear volume of server scans and probes against these near unmanaged sites.
However, the point that Gadi made that writing securely in PHP is inherently difficult, I strongly disagree with. For example, NVD shows that the same perl formmail that I identified above continued to have exploited vulnerabilities at least through the end of 2002. Although computer scientists contend that strongly typed languages are better than loosely typed ones, any language can be used insecurely as can be seen by trolling the CVE. Many of the more well know PHP projects have embraced the Open Web Application Security Project (OWASP) Guide to Building Secure Web Applications as well as the OWASP Top Ten and routinely issue patches and updates when security vulnerabilities are identified just like OS and other commercial vendors. However, due to the fact that PHP code does not require cgi-bin access nor execute permissions to run, that PHP code is written be a wide variety of qualified and unqualified people and that a lot of the applications, phpBB for example, are deployed by non programmers, I do agree with Gadi that PHP is certainly one of the principal vectors today. That said, I totally disagree with Gadi's conclusions that, "ISPs and ... hosting services cannot cope with this threat."
Many ISPs do hold their users to their TOS, require patch management, disconnect infected machines until they are cleaned and even terminate clients for repeated breaches and lack security. Some even control their clients' use of communications ports. Others unfortunately do not. This problem is really no different than the problem with commercial spammers associating themselves with particular ISPs as is well documented by SPEWS and ROKSO.
Hosting services could easily hold their clients to strict TOS, perform proper patch and vulnerability management, scan their clients disk space for software versions that have identified vulnerabilities and disable hosts until the software has been updated, monitor httpd logs and block non local IPs in realtime that attempt to access awstats.pl, mambo files when mambo is not installed, and other threat signatures, monitor for irc traffic on webservers, etc.
Unlike desktops owned and used by the technically challenged, servers should be the easy to stop from becoming perpetual attack platforms since they should be controlled by trained admins. Whether the fact that many ISPs and hosting services are not technically equipped to deal with the "server" problem or just don't care is unknown.
Tom -- Tom Shaw - Chief Engineer, OITC <tshaw@xxxxxxxx>, http://www.oitc.com/US Phone Numbers: 321-984-3714, 321-729-6258(fax), 321-258-2475(cell/voice mail,pager)
Text Paging: http://www.oitc.com/Pager/sendmessage.html AIM/iChat: trshaw@xxxxxxx Google Talk: trshaw@xxxxxxxxx skype: trshaw