Blog|Login|中文Deutsche日本語
3 posts from October 2013
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

 

October 04, 2013
 Score sheet: Testing Some XSS Evasion Techniques Against Our WAF
Pin It

IStock_000016474569SmallA couple of months ago ModSecurity (SpiderLabs) issued an “XSS Evasion Challenge” where they actively asked security experts and hackers to try and bypass their own XSS filters. This is a blessed initiative by a security company, to go and find loopholes in their engines in order to improve on their security posture.

The exercise included two main challenges:

  • Evading the ModSecurity WAF regex (CRS)
  • Evading client side protection “sandbox”

Per the challenge results, ModSecurity filters were updated to add the logic that is required to block these evasion techniques.

With security in mind, we were interested in checking the evasion techniques against our SecureSphere WAF its default configuration. Here are the results:

Evasion Technique #1: - “Nul Bytes” – Blocked out of the box.

Xss1

Evasion Technique #2: Sandbox Evasion (MentalJS) – Blocked out of the box.

Xss2

Bottom line – We were able to block both evasion techniques out of the box. Our customers are protected.

We also agree with SpiderLabs’s conclusions:

  • Blacklisting attacks with signatures is not enough. We agree. Part of the reason that IPS/NGFW and manually configured WAF solutions don’t solve web application attacks is that they rely on blacklists.  Effective protection against application attacks requires a positive security model to understand how the application works. See our Blog on “What the IPS Didn’t See”.
  • SpiderLabs say that Regular Expression matching (Signatures) is not enough. We agree. Imperva’s Technology does not rely on RegExp matching alone, but also incorporates smart engines that are able to understand the attack’s logic.

 

 

 

October 01, 2013
 Trend Watch – DDoS: “We Need a Bigger Boat”
Pin It

IStock_000003953967XSmallIt’s no news that DDoS attacks are growing in frequency and scale. Earlier this year Spamhouse suffered from what security experts have cited as “the largest DDoS attack ever,” peaking at 300+ Gbps. The story recently resurfaced when the attacker was apprehended.

This morning, eWeek reported on a new attack, which will go down as one of the largest DDoS attacks of the year. While the identity of the target remains undisclosed, the attack details are available. This latest DDoS attack started on Sep 24th, lasted for nine hours, and peaked at 100 Gbps.

As reported in the eWeek article, the attacked organization was protected by the Imperva Incapsula DDoS attack mitigation service, and therefore did not suffer service disruption.

One of the lessons that an attack this big teaches us is that attackers are generating a high magnitude of traffic to take down a target. Most companies, even some carriers, don’t own the bandwidth to continue service through such an attack. And attacks are ever growing – one 50 times larger can be right around the corner. DDoS protection companies provide the extra bandwidth when you are under attack – so you have a bigger boat to absorb the load.

Indeed. We build bigger boats.

 

Where can I learn more?

  • Our HII Research Paper on DDoS
  • The Imperva Incapsula DDoS attack mitigation service

 


 

 

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