Re: Web Server Botnets and Server Farms as Attack Platforms

[Tom <dshield () oitc com>]

At 12:00 PM -0600 2/12/07, botnets-request () whitestar linuxbox org wrote:
> Message: 1
> Date: Mon, 12 Feb 2007 07:34:09 -0600 (CST)
> From: Gadi Evron <ge () linuxbox org>
> Subject: [botnets] Web Server Botnets and Server Farms as Attack
>         Platforms
> To: botnets () whitestar linuxbox org
> Cc: full-disclosure () lists grok org uk, bugtraq () securityfocus com
> Message-ID: <Pine.LNX.4.21.0702120719290.14975-100000 () linuxbox org>
> 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 () oitc com>, 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 () mac com
Google Talk: trshaw () gmail com
skype: trshaw