[<prev] [next>] [day] [month] [year] [list]
Message-Id: <p06230956c1fb89d23e21@[10.0.2.120]>
Date: Fri, 16 Feb 2007 11:20:47 -0500
From: Tom <dshield@...c.com>
To: botnets@...testar.linuxbox.org
Cc: ge@...uxbox.org, full-disclosure@...ts.grok.org.uk,
bugtraq@...urityfocus.com
Subject: Re: Web Server Botnets and Server Farms as Attack Platforms
At 12:00 PM -0600 2/12/07, botnets-request@...testar.linuxbox.org wrote:
>Message: 1
>Date: Mon, 12 Feb 2007 07:34:09 -0600 (CST)
>From: Gadi Evron <ge@...uxbox.org>
>Subject: [botnets] Web Server Botnets and Server Farms as Attack
> Platforms
>To: botnets@...testar.linuxbox.org
>Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
>Message-ID: <Pine.LNX.4.21.0702120719290.14975-100000@...uxbox.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@...c.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@....com
Google Talk: trshaw@...il.com
skype: trshaw
Powered by blists - more mailing lists