Re: Web Server Botnets and Server Farms as Attack Platforms

["James Matthews" <nytrokiss () gmail com>]

This is crazy but somewhat true!

On 2/16/07, Tom <dshield () oitc com> wrote:
> 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
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/



--
http://www.goldwatches.com/watches.asp?Brand=39
http://www.wazoozle.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/