Blog|Login|中文Deutsche日本語
5 posts categorized "Nadav Avital"
March 18, 2014
 Threat Advisory: PHP-CGI At Your Command
Pin It

For a long time, PHP has been the dominant server side framework for companies to write their web applications with. In fact, ~82% of all websites today are written in PHP. And while PHP’s power by numbers creates an appetite with security researchers to look for flaws leading to maturity, documentation, and security best practices– the numbers drive hackers to focus on it as well.

Php1

On October 2013, a public exploit in PHP was disclosed. The exploit uses a vulnerability found in May 2012 and was categorized as CVE-2012-1823. The exploit suggests that PHP, in conjunction with Apache, suffers from command injection vulnerability.

Soon after the exploit was released, Imperva honeypots detected web servers being attacked with this exploit in different flavors. In the three first weeks following the publication we were able to record as many as 30,000 attack campaigns using the exploit. As this was an interesting surge in attack activity, we decided to look deeper into the attack.

Later on, we picked up intelligence showing that different botnets have picked up the vulnerability per its effectiveness, and have also captured samples of bot clients that have embedded this vulnerability exploitation in them.

One of the interesting points is that despite the fact that this vulnerability is somewhat dated, cybercriminals are still using it, understanding that a major part of the install base of PHP does not update on a regular basis – thus creating the window of opportunity.

In this threat advisory, we will cover the following:

  • The technical background and analysis of the vulnerability and exploitation techniques
  • Samples of the attack vectors captured in the wild
  • Industrialized cybercrime aspects of this vulnerability
  • Mitigation techniques

 

A first look into the vulnerability

The vulnerability first appeared in the different vulnerability databases on 10-29-2013, and was identified with the CVE code 2012-1823. The exploitation code was soon available via different exploit websites

Php2

The vulnerability enables a remote attacker to execute arbitrary commands on a web server with PHP versions 5.4.x, 5.3.x before 5.4.2 or 5.3.12. These versions account for 16% of all public websites in the Internet.

Php3

 

The honeypot trail…

After having analyzed the attacks recorded by our honeypot, we learned few interesting facts:

  • The overall count of attackers (different source IP) was 324 while the overall count of targeted web server was 272. Most of the attacks originated from the US (35%), France (21%) and Germany (15%).

Php4

  • The most common URL used in the attacks was by far //cgi-bin/php (chart 1). Later on we will explain why the attack requires the exact location of the PHP CGI executable in order to succeed.

Php5

  • The biggest attacks in terms of volume were carried out in half a day or a day period.

Php6

  • The vast majority of the attackers (86 different attackers IPs) executed their attack in half a day or a one day period attacking a single target. As the attack period and the number of targets grew bigger, the number of attackers dropped significantly.

Php7

Technical Background and Analysis         

The vulnerability official (and somewhat confusing) description is: 

Php8

The simple, straightforward explanation is that an external attacker can set command line options for the PHP execution engine. Such command line options eventually allow the attacker to execute arbitrary PHP code on the server.

You might scratch your head and ask – haven’t we seen this before? The answer is YES! This vulnerability is not new and had previous public exploits published. 

Php9

In previous cases, the attack relied on the server configuration to redirect all PHP files to PHP CGI and thus making it vulnerable to code leakage, code execution and more. The new attack however, tries to access the PHP CGI directly and hence must use the exact location of the PHP CGI executable.

Before we move on, it is essential to understand what PHP CGI is and how it works. Common Gateway Interface (CGI) is a standard method used to generate dynamic content on web pages and web applications. PHP CGI means using the PHP interpreter through CGI mode. The web server will pass the data from the request to PHP (an external program); its input is a PHP file (usually on the server) and its output is HTML code (usually rendered in the client’s browser). PHP CGI configuration is set via PHP INI directives files.

The vulnerability allows remote attackers to place PHP command line options in the query string, including the “-d” option. This option defines PHP INI directive before running the PHPinterpreter. In this attack, the “-d” option is used to manipulate PHP security settings in order to bypass security checks and allow remote code execution.

Looking at sapi/cgi/cgi_main.c file from the vulnerable PHP code tree, we can find out which directives are used for the security checks:

Php10

The code indicates two PHP CGI settings - cgi.force_redirect and cgi.redirect_status_env

PHP configuration directive cgi.force_redirect prevents anyone from calling PHP directly with a URL. Since PHP turns this directive on by default, a direct access to PHP via http://example.com/cgi-bin/php will produce HTTP error code and the following error message

The PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled.  This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive.

Controlling cgi.force_redirectand cgi.redirect_status_env values enables the attacker to bypass PHP CGI security check.

Another crucial directive that is set using the “-d” option in the attack is auto_prepend_file. This directive specifies the name of a file that is automatically parsed before the main file; php://input isa read-only stream which in our case is the raw data from the request body.

By setting auto_prepend_file to php://input the payload of the attack (arbitrary PHP code) is introduced in the request body.

Attack vectors captured in the wild

Let’s take a look at an example attack vector that was captured in the wild

Php11

Which is translated to -

Php18

Not surprisingly, in the example attack vector above, the HTTP request body contained PHP code that downloaded and installed a botnet malware client –

Php12

Payloads analysis

We have managed to identify 43 different types of payload data in the attacks registered in our honeypot. The payloads appear to be botnet malware client constructed in the following pattern:

Php19

The PHP payload is designed to download a malware executable file from a remote server to an unsuspicious directory (/tmp, /dev/shm, /var/lock, /var/tmp), run it and hide it ever existed by removing it from the file system. The servers that host these files are usually legit, however compromised, servers and the file names are disguised as image files or text files.

The malware files are usually written in PHP, Python or C and vary from simple reverse shell backdoors, to IRC clients that connect to C&C servers. We also notice that some malwares have different functionality according to the kernel versions and the processor architecture of the infected server.

Php13

Php14

Our experience shows that this level of sophistication is linked with industrialized crime, also known as bot herding. The attackers in this case, scan for servers that are exposed to the vulnerability (using PHP CGI from vulnerable versions) to infect them with their bot clients, thus transforming them into zombies which receive commands from a C&C server under their control. These botnets are then sold or rented to the highest bidder.

A surprising fact is that even today, this vulnerability can be used successfully as companies don’t take the appropriate measures to secure their servers. Evidence to this fact can be found in active drop down sites that are still hosting the botnet clients, as shown in the following example:

Php15

 

Some of the botnets that we have been looking into are still active, some of them are relatively new and activity can be witnessed with commands being sent to their zombie servers that operate under their control.

 

It is a very intriguing point to show that cybercriminals understand the serious gap that exists between the time that a vulnerability is found in the wild, to the time it gets reported and patched (if third party software/framework is in the loop, such as PHP). Finally, there is a time lag until  a company becomes aware of both the issues and the fix – and implements it. This creates a window of opportunity for hackers to act on, as they know that the window will be open for a long time.

Php16

 

PHP Patch

PHP offers a patch (here) to mitigate the vulnerability. The code snippet below shows that PHP added a verification to ensure that the query string does not include command line options.

Php17

 

Mitigation Recommendations

  • Verify your PHP version is not vulnerable (i.e., PHP 5.3.12 and up, PHP 5.4.2 and up); if you still use a vulnerable PHP version, make sure it is patched
  • If it is possible, do not use PHP in CGI mode
  • Place your web application behind a web application security solution (such as a WAF) to protect it from web attacks such as this one

 

November 18, 2013
 Threat Advisory: A JBoss AS Exploit, Web Shell code Injection.
Pin It

IStock_000007435099SmallJBoss Application Server (or JBoss AS) is an open-source Java EE-based application server. JBoss AS was developed by JBoss, now a division of Red Hat. On late 2012, JBoss AS was named as WildFly.

Recently, Imperva’s ADC had detected a surge in the exploitation of web servers powered by the JBoss AS, probably as a result of the public disclosure of an exploit code that abuse this vulnerability.

The vulnerability allows an attacker to abuse the management interface of the JBoss AS in order to deploy additional functionality into the web server. Once the attackers deploy that additional functionality, they gain full control over the exploited JBoss infrastructure, and therefore the site powered by that Application Server.

While the vulnerability is not new by itself and is known for at least two years, it is amazing to realize that during these years the attack surface had not decayed, but in fact had grown in terms of the number of the vulnerable web application.

The Incident Timeline

On 2011, a JBoss AS vulnerability had been presented in security conventions. Researchers showed that JBoss AS is vulnerable to remote command execution via the ‘HTTP Invoker’ service that provides Remote Method Invocation (RMI) /HTTP access to Enterprise Java Beans (EJB).

On September 2013, NIST had assigned a code execution vulnerability in certain HP products that utilized JBoss AS with a Common Vulnerability Enumeration (CVE-2013-4810).

On the 4th of October 2013, a security researcher, have made the exploit publicly available. Immediately thereafter, we had witnessed a surge in Jboss AS hacking, which manifested in malicious traffic originated from the infected servers and observed in Imperva’s honey pots array. 

The Exploit’s Technical Analysis

Jboss AS is vulnerable to remote command execution via the ‘HTTP Invoker’ service that provides Remote Method Invocation (RMI) /HTTP access to Enterprise Java Beans (EJB).

Java Beans are reusable software components for Java represented as a serializable Java Object. MBean, which stands for Managed Bean, is a type of Java Bean.  javax.management.ObjectName represents the object name of an MBean.  Mbeans are usually used in Java Management Extensions (JMX) technology. Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices and service oriented networks. Those resources are represented by MBeans.

JMX uses a 3-level architecture:

  1. The Probe level contains MBeans
  2. The Agent level, or MBeanServer, is the core of JMX. It acts as an intermediary between the MBean and the applications.
  3. The Remote Management level enables remote applications to access the MBeanServer through connectors and adaptors. A connector provides full remote access to the MBeanServer API while an adaptor translates requests between a given protocol (e.g. HTTP, RMI) and a specific JMX functionality. The Invoker invokes the proper MBean service based on the actual JMX request.

J1
 

Figure 1 JMX architecture

The detached Invoker allows MBean services to expose functional interfaces via arbitrary protocols for remote access by clients. The HTTP Invoker service, including EJBInvoker and JMXInvoker, includes a servlet that processes posts of marshaled (serialized) org.jboss.invocation.Invocation objects that represent invocations that should be dispatched onto the MBeanServer. Effectively this allows access to MBeans that support the detached invoker operation via HTTP POST requests.

The Vulnerability is composed of public HTTP access to EJBInvokerServlet or JMXInvokerServlet servlets, represented as URL /invoker/EJBInvokerServlet and /invoker/JMXInvokerServlet respectively, and invocation of the MainDeployer MBean. The MainDeplyoer MBean is responsible to deploy a WAR from a remote location.

The recently published exploit, abuses invoker/EJBInvokerServlet to deploy a web shell code that enables the hacker to execute arbitrary Operating System commands on the victim sever’s  system.

  J2

Figure 2 Exploit code

The exploit consists of a two steps process:

On the first step, the exploit abuses the EJBInvokerServlet to deploy the malicious Web application ARchive (WAR) from the remote URL http://retrogod.altervista.org/a.war that includes the ”a/pwn.jsp” shell code

  J3

Figure 3 A network capture of the malicious web shell injection as reproduced in Imperva's lab

On the Second step, the exploit sends an operating system command to the injected web shell

J4

Figure 4 A network capture of the commands sent to the malicious web shell injection as reproduced in Imperva's lab

In The Wild Exploitation 

Although this specific JBoss AS security issue has been known to the security community for a few years, it is amazing to realize that during these years the attack surface had not decayed, but in fact had grown in terms of the number of the vulnerable web application.

The number of server exposing their JBoss management interfaces had more than tripled itself (7,000 to 23,000) since the vulnerability was presented on 2011. 

 J5

Figure 5 Exposed JBoss' Management interfaces - October 2013 (Google Dork here)

J6

Figure 6 Exposed JBoss' Management interfaces - 2011

The list of the exposed sites contains some governmental and educational sites. We had identified some of them to be actually infected with a web shell code.

Many of the deployed web shells utilize the original pwn.jsp shell code that was presented with the original exploit, as can be seen in a blog entry posted by one of the attack’s victims.

Figure 5 Blog entry on a server infected with pwn.jsp

On other cases a more powerful web shell was deployed. In these cases, the attackers had used the JspSpy web shell which includes a richer User Interface, enabling the attackers to easily browse through the infected files and databases, connect with a remote command and control server and other modern malware capabilities.

J7
 

Figure 6 JspSpy User Interface

Recommendations and Mitigation

  • JBoss users should harden their web application according to JBoss manual
  • Imperva’s customers have been updated with a signature to prevent unwanted access to the vulnerable JBoss AS servlet via our regular content updates.

Where can I learn more?

 

November 05, 2013
 The rise and rise of ColdFusion-driven breaches
Pin It

IStock_000004850249SmallYesterday, Brian Krebs wrote an article on how several high end car/limousine service companies were breached and customer information was stolen. This resonated very strongly since some of the victims were celebrities, lawmakers and top executives. Krebs notes that the vulnerable component in those sites is identified as the ColdFusion web application platform.

Some of you may remember an article by SC Magazine from May this year, where a ColdFusion vulnerability was the breach vector that resulted in 160,000 Social Security Numbers (SSN) being stolen from Washington state Administrative Office of the Courts (AOC).

Also, an article on InformationWeek from August this year covered a data breach with the Department of Energy (DOE) where personal information of 14,000 employees was compromised. The system breached was written in ColdFusion and was developed by a third party company.

Why this matters?

ColdFusion induced breaches are definetly on the rise, which teaches us that hackers and security researchers are looking into this platform more and more as a green field for hacking endeavors.

As more companies are becoming security aware, we would like to believe that the trivial security gaps become  harder to find and easier to deal with. However this breeds an uprising technique within the hacking community, which is – finding an auxiliary functionality that is supposed to be used indirectly only by an administrator of the specific system, but in fact can be used by a hacker.

If we look into one of the more interesting ColdFusion vulnerabilities (can be found here) that is exactly the case. It is a vulnerability that uses administrative function that isn’t properly hardened within the platform. 

What can companies do?

  1. Patch. Although difficult in production, patching to latest versions and latest security patches usually will help fix the problem sooner rather than later
  2. Educate yourself. Knowing the platforms that you have, the platforms that are used by third party companies/solutions that you work with – is key in understanding your security posture
  3. Install a Web Application Firewall. As we believe that these types of attacks are up and coming, we invest lots of our security research efforts into identifying them and blocking them before they hit the servers

 

October 08, 2013
 Threat Advisory: A vBulletin Exploit, Administrator Injection.
Pin It

IStock_000009353255SmallvBulletin is a popular proprietary CMS (content management system) that was recently reported to be vulnerable to an unspecified attack vector. vBulletin is currently positioned 4th in the list of installed CMS sites on the internet. Hence, the threat potential is huge.

Although vBulletin has not disclosed the root cause of the vulnerability or its impact, the Imperva Application Defense Center (ADC) has determined the attacker’s methods.

The identified vulnerability allows an attacker to abuse the vBulletin configuration mechanism in order to create a secondary administrative account. Once the attacker creates the account, they will have full control over the exploited vBulletin application, and subsequently the site supported by its CMS (vBulletin). 

Initial Analysis

Although vBulletin has not disclosed the root cause of the vulnerability or the impact on customers, they did provide a workaround in a blog post encouraging customers to delete the /install, /core/install in vBulleting 4.x and 5.x respectively.

Vb1

Additionally, on vBulletin internal forums a victimized user shared his server’s Apache log, providing some visibility into the attacker’s procedure: 

Vb2

This log indicates that the attacker continuously scans, using “GET” requests, for the “/install/upgrade.php” vulnerable resource. Once successful , indicated by the “200”response code, as opposed to “404” response code for non-existing resources, the attacker issues a “POST” request to the same resource with the attack payload. Since the Apache logger does not log the parameters of POST requests, the details of the attack are not yet revealed.

Into the Weeds

Once we had access to some concrete technical details on the vulnerability, we were able to effectively scan hacker forums in search of an exploit code. Soon after, we found PHP code that implements the attack.

Vb3

Next, we carefully installed the code in our lab. The interface clearly states the goal of the attack: injecting a new admin. In order to exploit the vulnerability and inject a new Admin user, the attacker needs to provide the following details:

  1. The vulnerable vBulletin upgrade.php exact URL
  2. The customer ID

In order to get these details, hackers had created an additional auxiliary PHP script. The script scans a site for the vulnerable path, exactly as shown above in the reported Apache log, and extracts the customer ID from the vulnerable upgrade.php page, as it’s embedded within the page’s source code. 

Consequently, the attacker now knows both the vBulletin’s upgarde.php vulnerable URL and the customer ID. With this information, the attack can be launched.

Here is an example of the POST request with the attack payload (the red fields match to the information the attacker needed to enter in the PHP interface above).

Vb4

The result of the attack was exactly what the exploit package described. A new admin user was created (“eviladmin”) that is under the control of the attacker. The site has been successfully compromised.

Recommendations

  1. vBulletin has advised its customers to delete /install and /core/install directories in versions  4.x and 5.x respectively.
  2. For vBulletin users not able to delete these directories – it is advised to block access or redirect requests that hit upgrade.php through via either a WAF, or via web server access configuration.

SecureSphere WAF Mitigation

Imperva customers have been updated with a signature to prevent unwanted access to the vulnerable php code via our regular content updates.

Where Can I learn More?

  • Imperva CMS Hacking webinar
  • An Article on CMS Hacking published on ITProPortal
  • vBulletin usage statistics and analysis can be found on w3techs.com
  • Comparative CMS distribution analysis could be found here

 

July 03, 2013
 Community Defense in the Wild
Pin It

With the announcement of SecureSphere version 10.0, Imperva added a crowd-sourced threat intelligence service that aggregates and validates attack data from WAFs to protect against hackers, automated clients, and zero-day attacks. We can then validate the data and stop attack campaigns in almost real-time. The “Community Defense” service has already proven successful in deterring new and original attacks when they strike the first time.

In a spirit of collaboration, our ADC team wants to share an example of a threat we have analyzed, researched and mitigated for the entire community.

This is an interesting case where the second that the vulnerability got announced, we were able to identify exploitation attempts coming from attackers around the world. Community Defense was able to mitigate the threat early on and keep our clients safe.

A Wild CVE is on the Prowl

On June 6 the “Parallels Plesk Panel phppath/php vulnerability” was publicly disclosed. According to Parallels and The Vulnerability Notes Database:

“Parallels Plesk Panel versions 9.0–9.2.3 on Linux platforms may be exploited by a combination of CVE-2012-1823 and the Plesk phppath script alias usage. There have been reports that this vulnerability is being exploited in the wild.”

In case you don’t know, CVE-2012-1823 is a vulnerability in php-cgi, enabling remote attackers to execute arbitrary code by placing command-line options in the query string. For example, if the URL http://www.example.com/index.php is requested and php is configured to work in cgi mode, then a remote attacker can set php.ini security directives and execute arbitrary PHP code.

The “Plesk phppath script alias” relates to a php-cgi configuration directive on the web server — namely, ScriptAlias /phppath/ "/usr/bin/" — which tells the web server that any request for a resource beginning with /phppath/ should be served from the directory /usr/bin/ and treated as a CGI program.

Now if the URL http://www.example.com/phppath/php is requested, the web server will attempt to execute the file /usr/bin/php and return the output. And since /usr/bin/php is a default PHP path and the file is executable, the php interpreter is called directly.

By exploiting the combination of these two vulnerabilities, a remote unauthenticated attacker can run arbitrary code under the context of the web server user.

Capturing the CVE in action

Imperva has seen this vulnerability exploited in the wild. An example is shown below in Figure 1. The attacker sends a specially crafted HTTP request to the URL /phppath/php of the vulnerable web application. Here are the names of the parameters in the request’s body:

  • Set PHP environment flags, as described in CVE-2012-1823
  • Execute shell commands on the attacked server via PHP (using the PHP security bypass created by the environment flags). The shell commands can, for example, download and install a shell environment controlled by the attacker.


The attacks we observed very nearly coincided with the disclosure of the vulnerability, as can be seen in Figure 2. Many web applications were repeatedly attacked every few hours using this vulnerability over a long period of time (Figure 4).

As we’ve seen before, a single web application can be targeted by multiple attack sources (according to their IP addresses). At the same time, a single attack source can target multiple potentially vulnerable applications. Figure 4 illustrates the complex relationship between attackers and targets.

A similar relationship exists between attackers and injected shell URLs (Figure 5). A successful exploit of the vulnerability downloads a malicious shell code and executes it on the web server. ADC has also seen that URLs from which malicious shell codes are downloaded are used by more than one attacker and originating in more than one geo location.

As is often the case for this type of malware, it’s written in Perl and remotely controlled by the attacker using an IRC channel.  One of the commands the controller can issue to the shell that runs on a compromised server is to look for other vulnerable web applications, in order to virally spread itself on the web.

Cve1

Figure 1: Sample of attack exploiting the vulnerability

Cve2
Figure 2: HTTP traffic exploiting the vulnerability (each target application marked with a different color)

Cve3_updated

Figure 3: HTTP traffic exploiting the vulnerability targeting 4 sample web applications

Cve4

Figure 4: Attackers (in red) and targets (web applications, in green) during 23/6-30/6

Cve5

Figure 5: Sample of attackers and injected URLs during 23-29/6

 



 

 

Find Us Online
RSS Feed - Subscribe Twitter Facebook iTunes LinkedIn YouTube
Authors
Monthly Archives
Email Subscription
Sign up here to receive our blog: