Blog|Login|中文Deutsche日本語
45 posts categorized "Tal Be'ery"
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

 

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.

 

 

 

August 19, 2013
 Our take on the NSA’s decision to cut back on sys admins
Pin It

NavalA couple of weeks ago, the NSA Director, General Alexander was quoted in a Reuters article saying that in order to limit data access and potential leakage, they will cut back on 90% of NSA system admin staff.

This statement drove lots of criticism, since it makes no sense to cut back on critical staff in a very disproportionate way, which makes us believe that there is something else there…

"At the end of the day it's about people and trust," Alexander said.

Maybe he should have phrased things a little differently: "At the end of the day it's about people and trust, plus monitoring the people you trust."

It seems like the real issue is not the number of people, but rather the number of people who hold administrative privileges. What you really need to cut is administrative privileges from 90% of the people.

Administrators should not be immune to scrutiny. In order to refrain from the next Snowden-like issue, segregation of control should be implemented, necessitating a collusion of at least two individuals of different teams to leak the data.

To do so, the security team should be supplied with a compensating monitoring system over files and database access which:

  • The administrator has no control of
  • Can only monitor access to the data rather than actually accessing the data(eliminating another potential backdoor)

”In God We Trust, All Others We Monitor”

 

August 13, 2013
 TIME and again: an SSL breach before BREACH
Pin It

Img_https_failLast week at Black Hat 2013, one of the briefings that garnered a lot of attention was ‘SSL, GONE IN 30 SECONDS – A BREACH BEYOND CRIME.’. The briefing detailed an extension of 2012’s CRIME attack.  While the original CRIME attack targeted a compression information leakage vulnerability in order to expose secrets contained in compressed and encrypted HTTP requests, the new BREACH attack exposed secrets in HTTP responses.  The briefing and accompanying paper successfully explain a complex subject that involves different domains (compression, encryption, web protocols, etc.) in a very clear way.

At Black Hat Europe earlier this year, I presented on a similar topic. The briefing, called “A PERFECT CRIME? ONLY TIME WILL TELL,“ discusses this extension of the CRIME attack as well as some timing based attacks on SSL. The abstract includes some specific mentions on “the relevancy of compression ratio information leakage for HTTP responses,” which is discussed in detail in the publicly available white paper .

Our work did not stop at applying the CRIME attack to responses. Digging deeper, we were able to determine that the compression vulnerability can be exploited even if the attacker does not have any eavesdropping capability, by using timing inference.

This is one of the reasons why conferences like Black Hat is so important. We have been in touch with the authors of the BREACH paper, who have added a note about it in their website and will mention our work in their paper. We hope that the renewed interest in the attack will motivate browser’ and server vendors to find a solution for it, including the grave, additional timing issues which our TIME attack had exposed.

For more information, follow these links:

 

June 18, 2013
 Data Leakage In A Google World
Pin It

Gg3In the past, information leakage conjured images of securing data from physical theft (remember the alleged FBI laptop?) but thanks to the web, organizations need to secure information from growing “search giants”. In short, data leakage has taken on a whole new meaning in the Google age.

The causes of data leakage range from simple misconfiguration or improper classification of data, which makes it possible for Web servers to publish private and/or sensitive information, to users unwittingly (or not) storing sensitive data where they shouldn’t, Even best business practices such as site scraping -- a known method for gathering competitive intelligence in which company A automatically reads company B’s website for available data like price tables, and uses it to cut its own prices and remain on top – can lead to leakage of information.

Search Engines

By their very nature, search engines are the Internet’s biggest and most public Indexers. Search engines analyze websites, indexing them for the benefit of everyone who has ever done an Internet search. One urban legend even states that Google has a complete copy of the entire public Internet on file for data mining and analysis purposes.

As consumers and users of the Internet, we like to believe that most organizations do their best to remove sensitive information from their websites, FTP sites and other front facing business applications, As it turns out, however, this is not always the case.

Google Tables Search

Google has always been a pioneer of search algorithms, search visibility and advanced indexing, remaining one step ahead of other search engines, and introducing news ways to tag images by context, and even FTP sites for content. Their recently added Table Search capabilities, however, really brings to surface the idea of impact of data leakage in an indexed world.

This is not to say that Google is causing data leakage, but abilities like “Indexed FTP”,”Sesrch by image”, and now “Table Search” offer new ways to discover and extract data, which would otherwise have remained undiscovered.

Here’s one scary example (you can think of other interesting tables: PII, salaries,CC,…)

We used: http://research.google.com/tables?hl=en&q=username+password

Gg1

Which is a structured representation of -

Gg2

What is the Security takeaway?

The takeaway here is that Web security is more important now than ever before. Obviously, it doesn’t make sense to block Google from indexing your site (a business driver), but you should be aware of what content you are allowing access to, and who is accessing it.

Companies should:

  1. Implement web application security to mitigate hacker risk.
  2. Validate the content that is accessible via your web servers on a regular basis and/or implement policies to check for outgoing data.
  3. Implement policies to mitigate Bots that may scrape your website for available content.

The bottom line is that no one really wants to block Google from indexing your website, however controlling the content that your website serves is important. Organizations should note that once content is up there, the “search giants” will index it and with ever-evolving mechanisms it will become easier to get around leaked information.

 

May 16, 2013
 CMS Hacking
Pin It

* The blog was updated on the 5/20/2013 to make corrections with respect to the target of the analyzed hacked server screenshot  *

Yesterday, EC Council was reported to have been compromised by a hacker called “Godzilla”. based on published materials in seems that the hacker got access to training course material of several certification programs.

This is not the first time that EC council related sites have been reported to be hacked. Two years ago hackers breached the academy site of the EC Council eccouncilacademy.org. here is the analysis of the EC council academy  hack:   

Looking into the published content by the hacker analyzing the screenshot from shows that the server was hacked by the upload of the WSO web shell code.

10

The malicious shell was probably uploaded due to an exploit of a known vulnerability in the Joomla CMS (Content Management System) used by the site – judging by the file date in the screenshot the system has not been updated since 2010.

What is the takeaway here?

While we can take the provocative approach of looking into a company that its revenue is mostly based on teaching professionals about security and gets hacked, lets be honest – this can happen to any company and history has proved this point valid. In this case, we would rather show the interesting direction around CMS exploitation becoming more and more popular.

The CMS Exploitation vector of attack is very common and in fact a simple search on one specific flavor (Joomla) resulted in 629 CVEs. Thousands exist in the CVE database and hundreds exist in 0day databases.

11

Why does this matter?

Businesses rely on 3rd party software and platforms to conduct their online business, and it is very common to use a CMS such as Joomla or similar and even Sharepoint to simplify delivering a rich website. However by doing so the website is exposed to vulnerabilities found within that CMS.

This brings up an interesting playfield for hackers, which can use Dork techniques and others to fingerprint many websites who use the specific CMS, easily locate many targets and exploit them with either a known (if the system is not up to date as it seems to have been the case here) or a 0day exploit, and have lots of surface covered.

Here is an example of a search term that looks for a specific function in a known CMS which is known to be vulnerable, in order to identify potential targets, the result is astounding. ~263,000 potential targets.

12

What can an organization do to protect itself?

This hack could have been probably prevented by either constantly patching of all the 3rd party code of the application and/or by implementing a web application firewall in front of the application.

Where can I learn more?

Going back to our HII report from January (“Lessons learned from the Yahoo hack”). We have shown how third party code may contain vulnerabilities and security holes that could result in a hack, this is of course not the same case, as the HII spoken of talks about a 3rd party service that got compromised, however the security implications are the same.

 

 

May 09, 2013
 Why Hosters Should Care About Web Security
Pin It

4Earlier this week, the “Moroccan Ghosts” published a list of 52 defaced Israeli sites, replacing site
content with political propaganda pages (and some cool Moroccan music).

Looking into the hacked domain list, we noticed that most of the domains in the disclosed list are hosted on the same server. In this case, a large hosting company in Israel. It was relatively easy to see that the server itself runs PHP v5.

3

Although this is merely educated speculation, it seems that the hackers were able to exploit a configuration mistake in the server rather than individual vulnerabilities in the hosted applications or taking over the entire server through a vulnerability in a single application.In a shared hosting environment “one rotten apple spoils the barrel” – so a single vulnerability may result in owning the entire server and the database that holds data for all applications.

In other words, when an application is hosted on a shared hosting server, even if one application owned by company A is secured, if a second application owned by company B is not so secure and is being hacked, the end result may be a breach to both. This is also true to a secured application on an insecure platform.

What can hosters do to prevent incidents like this?

  • Proper server administration should enable creating silos in terms of database servers, virtual directories and permissions per customer. This reduces the risk in some ways but does not remove it.
  • Hosters should offer the same compartmentalization services they offer to physical customers, to the digital and hosted customers by adding web application controls that will reduce the risk of such hacks.
  • Make sure that the management platform is secure, since lots of the hoster hacks are breached via an insecure management console that allows file changes and DNS changes per user provisioning, or globally.
  • Offer web vulnerability scans to your customers, because most companies do not have the experience that hosters have dealing with web applications and the security required around them. It makes sense that customers that outsource hosting their applications will appreciate outsourcing the security around them. However, to complete the cycle scanning is not enough! Once vulnerabilities are found it is critical to use controls such as Web Application Firewalls to remediate the findings.

 

 

March 19, 2013
 A Perfect CRIME ? Only TIME Will Tell
Pin It

TimeSharing security research and intelligence makes the community as a whole safer. By uncovering and sharing information on weaknesses in the Internet, common vulnerabilities and new attack techniques, our customers and the industry learn specific ways to improve their risk posture and gain deeper insight into how cybercriminals operate.

Once upon a Time…

In 2012, a new attack against SSL named “CRIME” (Compression Ratio Info-leak Made Easy) was introduced.  The attack uses an inherent information leakage vulnerability resulting from the HTTP compression usage to defeat SSL’s encryption.

Despite the very interesting find, the CRIME attack suffered from two major practical drawbacks:

  1. The attack threat model: for a CRIME attack to work, the attacker must control the plaintext AND to be able to intercept the encrypted message. This attack model limits the attack to mostly MITM (Man in the Middle) situation, you must use eavesdropping.
  2. The CRIME attack was solely aimed at HTTP requests. However, most of the current web does not compress HTTP requests.

Last week at BlackHat 2013 in Amsterdam, Imperva’s Tal Be’ery, a Web Research Team Leader in the ADC Group, presented a new analysis of the CRIME attack, advising that the discovered cyber threat may be more serious than previously believed.

The analysis showed the potential for a new attack technique, which we’ve dubbed TIME (Timing Info-leak Made Easy), that could overcome the two limitations of the original CRIME attack, specifically removing the eavesdropping requirement and making the attack surface broader by focusing on HTTPS Response instead of HTTP request compression.

In Layman’s Terms

The TIME attack, which mainly affects Web Browsers, shows that all the hacker needs to do is redirect an innocent victim to the malicious web server, apply certain JavaScript and get the victim's secret data; the barrier of the eavesdropping requirement is removed.

Diving into the Research

First and foremost, SSL is NOT broken and your online bank accounts are pretty much as safe as they were before this research. Attackers will still try to get your data by infecting your machines with malware and attacking the server with SQL injection or other web application attacks to get the data within the database. Tal’s research focused on being one step ahead of the hackers - understanding how they could evolve the attack to make it easier and more effective – so that the security industry becomes aware of the potential problem.

The main focus areas of the research:

  • Show that the CRIME attack could be extended to HTTP responses – The original CRIME attack had shown that the interaction between compression and encryption may leak data. However, the attack was limited to discovering secret data on the HTTP request only, namely the cookie. Therefore it was easily mitigated by disabling the compression of cookie header. Tal showed that CRIME attack techniques can be extended to attack any secret data on the HTTP response.
  • The eavesdropping requirement of the CRIME attack is one of the main reasons that the attack vector was considered impractical, since it required the attacker to be located either on the same network or have some control already of the victim, which renders the vector ineffective. 

Key Takeaway

Using the extended TIME techniques, our research show that an attacker can infer on the data size from timing measurements taken by a JavaScript, allowing the attack to be carried out by a remote attacker, this elevates the severity of the attack vector for the first time as it removes the need for eavesdropping from the game. Second, the extension of the attack to HTTP Response grows the attack surface as most applications allow HTTP Response compression for performance reasons (unlike HTTP Request where compression is sometimes redundant) therefor making the vulnerable potential attack surface larger.

Where can I learn more ?

You are invited to download Tal’s BlackHat Presentation, Further information and relation to other research work could be found at ArsTechnica at This link.


 

 

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