NordVPN Promotion

Home / Blogs

Web Server Botnets and Server Farms as Attack Platforms

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 (renamed from the Web Honeynet Project to avoid confusion with the honeynet project).

The paper can be found here:
Web Server Botnets and Server Farms as Attack Platforms [PDF] (all rights reserved to Virus Bulletin)

By Gadi Evron, Security Strategist

Filed Under

Comments

Matthew Elvey  –  Feb 15, 2007 11:36 PM

Thanks for not sugar-coating things and updating us on the state of the art.

Here’s how I’ve dealt with two similar issues, as you asked:

I had an unpleasant experience when a system I help manage was infected via a vulnerability I was able to trace to a PHP script written by a contracted third party.  Unable to definitively disinfect the system, we did a restore from backup (yes, this resulted in data loss).  Sent the third party information on best practices for PHP coding.  Involved and educated the client about the issue.  System was reinfected shortly, again via PHP.

I found that TD Ameritrade core personal customer information systems were compromised and reported it.  Ameritrade’s responses and direct evidence indicate, respectively, that they still haven’t detected, let alone resolved, the security breach. details.

I’ve also joined the ranks of the millions dealing with being an Identity Theft victim.  It is really as bad as you’ve heard.  Frustrating as hell.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

DNS

Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

Cybersecurity

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

NordVPN Promotion