How IP Reputation Blocks Zero Day Vulnerabilities: Privilege Escalation Exploits Blocked Before Patching

Figure1-cJoomlaAttacks

Joomla! CVE-2016-8870 & CVE-2016-8869

This blog analyzes the privilege escalation vulnerability in Joomla! CMS and its exploitation in the wild.

Based on the attack traffic, we show the statistics of the attack including a spike in its volume right after the security patch publication and repeated patterns that match the characteristics of automated attacks including fixed HTTP headers and Parameters values.

We analyze the malicious tool believed to be partly responsible for the attack and use this date to infer the alleged attackers’ origin.

Using a combination of several security protection techniques, including reputation services provided by Imperva Threat Radar, we were able to track attacks even before issuing the zero-day patch and block them from exploiting applications protected by the Imperva Web Application Firewalls (WAFs).

Lastly, based on the Imperva Community Defense technology and the security research team, we show a global phenomenon that usually remains hidden to application owners.

Timeline

Sept 27, 2016

Imperva ThreatRadar Community Defense detects the beginnings of the attacks that exploit the vulnerabilities CVE-2016-8870 and CVE-2016-8869. In the figure below, red nodes are the attacker and white lines are the attack paths. Eighty percent of the attack activity is generated by just 20% of the red attack nodes. The same nodes are mounting other kinds of attacks and are triggering the IP Reputation rules to block these attacks on the Imperva WAFs.

sept26joomlaattacks

Figure 1-a Visualization of the attack traffic (red nodes represent the Attackers) as of Sept 26, 2016

October 25, 2016

A new security patch was released by the Joomla! team on Oct. 25. Figure 1-b shows that 59%  of the total attacks, from Sept. 26 through Nov. 4, have already been launched. The patch addresses two critical security vulnerabilities affecting Joomla! versions 3.4.4 through 3.6.3. The patch enabled users to 1) register and create user accounts on a site when the registration feature has been disabled (CVE-2016-8870); and 2) gain escalated privileges on newly created accounts or already existing ones (CVE-2016-8869).

 

fig12joomlaattacksoct26-nov4

Figure 1-b – Cumulative Percentage of Attacks Overall from Sept 26 through Nov 4

Oct 26, 2016

The Imperva Defense Center (IDC) releases a dedicated virtual patch to address the two CVEs, less than 24 hours from the time of discovery. The virtual patch mitigates these vulnerabilities, regardless of the Joomla! version. Once the patch is released, script kiddies get active, and you can see the number of attack nodes (in red) exploding in figure 1-c.

Furthermore, to evaluate the volume, characteristics, and implications of the newly exposed vulnerabilities, our research team has initiated a security analysis. The results of the analysis are detailed in this report.

Click here for the complete visualization of the attack timeline. The red nodes are the attack nodes, white lines are attacks, green nodes the targets, the size of the node depicts attack volume.

The Vulnerabilities

The vulnerabilities in question suffer from a similar issue – insufficient input checks in during the site registration process, which were fixed in the latest patch.

More specifically, the first vulnerability, CVE- 2016-8870, refers to a missing sanity check that may allow a user to register to the system when they are not supposed to. The second vulnerability, CVE-2016-8869, refers to improper filtering of the user’s input data during the registration process, where unintended parameters, which should not be accessed directly by the users during registration, can potentially be overwritten. This bug may enable a malicious user to register to a site with higher privileges than intended or modify user’s attributes, such as the related user group in which the user is registered to (See Attacks section below).

As an initial phase, the escalated privileges obtained by the attacker provide an excellent springboard for a secondary attack in which a backdoor or custom web shells is uploaded to take full control of the server.

The Attacks

Analyzing the attack, traffic following the patch release provided us with a more solid understanding regarding the malicious requests, which started to pile up.

During two weeks, we monitored 937 attacks from 97 different attackers, directed to 627 targets. The directed graph in figure 1-c illustrates the attack traffic with red nodes representing the attackers and green nodes the targets.

figure1-cjoomlaattacks

Figure 1-c – Visualization of the attack traffic, where red nodes represent the Attackers (sized by their outgoing attack volume)

Traction

Most of the attacks occurred the day after the implementation of the Joomla! Security patch and then fell back to a lower but fairly steady cadence.

oct26-nov4joomlaattacks

Figure 2 – Number of Attacks following disclosure

The malicious requests included HTTP parameters that were out of the user’s intended registration input scope, in addition to parameters which are expected to be found as part of a legitimate registration request (i.e., username, password, name and email).
The parameters include the user-group (i.e., “groups”), which effectively determines the user’s privileges, and the user-ID (i.e., “id”), which enables an override of an existing user’s credentials and may hold administrative privileges.

Below is a partial view of a typical HTTP request carrying the attack vector, as witness in the traffic:

figure3joomlaattackshttprequest

Figure 3 – partial view of a typical HTTP Request carrying the attack vector

The problem is the assignment of the “groups” parameter, which should not be submitted when used properly through the registration page.

While we registered attacks from various sources and flavors, we believe that vast majority of the attacks come from an automated tool or scanner. This assumption is based on an analysis of the attacks’ characteristics.

First Lead – Attack Traffic

We found more than 80% of the attacks originated from only 20% of the total IPs (20) generating malicious traffic.

This finding can be observed in both the IPs distribution in the chart below where the most significant IPs are marked in red and by the enlarged, red nodes in figure 1 which represent significant attackers with numerous outgoing attacks.

figure3joomlaattacksregistrationattemptsperip

Figure 4 – Joomla! Registration Attempts per IP

Attributing these provided additional knowledge regarding the nature of the attack:

  1. All the IPs are currently blacklisted or marked as spammers by various known online Reputation services.
  2. Three-quarters of the machines(15 out of 20) were compromised web servers, while the others were unreachable at the time of the investigation.

Second Lead – Registered Usernames

While analyzing the data, we came across multiple repeated patterns. The first pattern referred to the input data used by the attackers and specifically the username used for registering the Joomla! sites. As observed in the next figure, three usernames account for more the 80% of the attacks (VULLS J00ML4, ARDMIN, ADMIN).

figure5joomlaattacksusernamedistribution

Figure 5 – Top three Usernames distribution

Third Lead – HTTP Headers

Repeated patterns also stood out while observing different HTTP headers used by attackers, including the User-Agent and the Referer headers, where about 90% of the attacks used the same headers’ values.

The most significant User-Agent recorded during the attack accounted for 92.27% of the requests:

  • Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
    figure6joomlaattacksuseragentdistribution

Figure 6 – User-Agent Headers Distribution

The most significant Referer recorded during the attack accounted for 93.86% of the requests:

  • http://www.guiando.com.br/index.php?optionu003dcom_usersu0026viewu003dregistration

figure7joomlaattacksrefererheaderdistribution

Figure 7 – Referer Headers distribution

It is worth noting that the most significant Referer value used is pointing to an Apache web server (guiando.com.br) with a Brazilian subdomain (br).

This result and its correlation with the User-Agents distribution findings is yet another indication of the malicious intention and operation of the attacker who used an automated tool with predefined input to efficiently carry the attack.

Attribution

Regarding the HTTP Headers uneven distribution, we found that only four countries were responsible for more than 60% of the malicious Joomla! registration traffic, Brazil (18%), Great Britain (16%), Italy (14%), and the U.S. (12%).

figure8joomlaattacksgeodistribution

Figure 8 – Attack traffic Geo distribution

The fact that most of the attacks originated from it, with conjunction with the frequent, fixed, Brazilian DNS referrer, brought us to the conclusion in which it is highly likely that the initial automated tool intended to efficiently exploit these recent vulnerabilities developed in Brazil.

The Tool – “Joomla Ejector”

Based on the information above, we were able to track a malicious script corresponding to the characteristics of the attacks:

figure9joomlaattacksejector

Figure 9 – “Joomla Ejector”

 

As observed in lines 8-9 of the source code, the script enables the attacker to insert a list of website addresses to attack. In line 14, it enumerates each website and performs the registration task, with escalated privileges utilizing the new vulnerability, i.e., setting the user’s group to 7, in lines 27 and 29.

In lines 31-37 if registration is successful, the target’s details are sent to the attacker, through a remote script, “posting.php,” located in a Brazilian web server which is most likely compromised.

It is also worth noting that the abnormality observed during the attack traffic analysis, with regards to the HTTP headers and registration input data, could be explicitly explained by the script logic. Let’s take a closer look at the “Post” function in line 56 responsible for sending the malicious payload to the target:

figure10joomlaattackspostfunction

Figure 10 – The “Post” function

As can be observed in lines 64 and 73, both headers’ values are hard coded in the function’s logic and are similar to the values which stood-up most in our security analysis.

Lastly, if we had any doubts regarding the attribution of the attackers, the source code lead us back to Brazil, as Portuguese is prominent as noted in the language of the successful registration attempt:

figure11joomlaattackssamplecode

Figure 11 – Sample of the Attacker’s language used along the code

Which means “CONGRATULATIONS, USER ADDED SUCCESSFULLY. . .”

Zooming Out…

Detecting new attacks, before the realization of their existence is not a trivial task.

Using a combination of security protection techniques, including reputation services provided by the Imperva ThreatRadar, we were able to track and analyze attacks even before the 0day patch.

As illustrated in figure 12, analyzing the full picture provided significant insight regarding the attack timing. More concretely, we tracked the first attack a month before Joomla! released the security patch, and found 58% of the attacks occurred before the patch release.

fig12joomlaattacksoct26-nov4

Figure 12 – Cumulative Percentage of Attacks Overall

Moreover, based on the analysis of these attacks, we found that most of the targets (64%) received only one malicious request, while the others only a few (12 max) (see Figure 13).

This fact is particularly intriguing, since this kind of attacks produce very little traffic on the target side, and therefore can easily go under the victim’s radar unless observing in a wider spectrum.

fig13joomlaattacksnumberofattacksperip

Figure 13 – Number of Attacks per Target

Mitigation

The vulnerabilities above provide severe security risk to web servers running the Joomla! framework. We urge all Joomla! users to immediately implement the latest security patch.

A better solution is to deploy a web application firewall (WAF) to provide zero-day protection through reputation services and also with virtual patching. Virtual patch is available for Imperva SecureSphere WAF customers, providing continuous out of the box protection for the above vulnerabilities, regardless of the web application version used by the customer.