Blog|Login|中文Deutsche日本語
5 posts from November 2013
November 27, 2013
 1.2M Loyaltybuild Customers' Data Breached - Why?
Pin It

IStock_000008861249SmallLast week Ireland’s Office of the Data Protection Commissioner (ODPC) reported that loyalty marketing company, Loyaltybuild had been hit with a major data breach. The breach, affecting at least 1.2 million customers, resulted in loss of customer names, addresses, phone numbers and email addresses in addition to 376,000 credit card numbers (CCN).

 In statement on their website, Loyaltybuild wrote:

           "We have ceased taking bookings on our website and over the phone" 

According to their website, Loyaltybuild was established in 1999 and is “backed by sophisticated web, booking engine and database technologies, designed for large-scale campaigns in one or more languages.” 

Unfortunately, Loyaltybuild was also storing unencrypted sensitive information, and too much of it at that. As if CCN data is not enough, CVV numbers (PCI-DSS requirements prohibit the storage of these) were also compromised. There is very little reason for Loyaltybuild to hold CCN information (especially unencrypted) and no reason to store CVV numbers.

Let’s talk about the numbers: hundreds of thousands of credit card records and more than a million records of additional information (email, addresses, etc.) is a lot to exfiltrate. Data monitoring should have alerted to such a large number of records being read or moved - especially when it was moved outside of the organization.

According to reports, some of the data was historical (from 2011 - 2012). Historical records - that are less frequently accessed - should have raised an even bigger flag.

As 'sophisticated' as this breach might prove to be, a simple monitoring of data records could have alerted security personal and might have prevented this breach. Most would agree that copying a million records is worth opening a ticket to IT Security team.

Another recent security event, the MongoHQ breach, revealed the dangers of attacks on service providers: ‘hack one hack them all.’ The service provider is not the only one on the receiving end of these attacks - their customers are as well. 

After the MongoHQ breach we advised that customers take responsibility for their sensitive data and know how their business partners are securing it. In the Loyaltybuild case, customers agreed to share too much, in plaintext, with no guarantees. When using third party services businesses should share the bare minimum of information with their partners. This is particularly true of sensitive information.

In both cases, simple encryption of the sensitive data might have minimized the fallout. Moreover, in both cases customers were way too trusting with their service provider.  Whether  a cloud-based startup or an established business like Loyaltybuild, customers need to protect themselves and not assume their service providers will do the job for them.

Security is based on trust; however, given these recent breaches, trust is increasingly difficult to come by.

 

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 14, 2013
 A Look Into The MongoHQ Breach – Protect Your (Big) Data
Pin It

IStock_000020541258SmallA recent security breach in MongoHQ (a MongoDB cloud services provider) left the company working hard to patch up security holes. Unfortunately common, this breach was only detected when one of MongoHQ’s customers (Buffer) realized they had been hacked.

Following the attack, MongoHQ did the right thing: they apologized to their customers, detailed their security flaws (some are quite staggering) and laid out what actions they are taking to mitigate security. 

Although the actions that MongoHQ took do improve security, data service providers and customers should ask themselves if their data is ever secure enough.

Once the data provider is breached, its customers are the first to suffer. And when discussing service providers, “small” hacks have a potentially exponential effect. Once a single server has been breached, all of the databases and the customers that own them are breached.

You’re the weakest link!

If you’re a data service provider with hundreds or even thousands of customers, getting hacked is only a matter of when – and when will it happen again.

Targeted attacks look for the weakest link in terms of security. When the weakest link is the data service provider and not the customer, the attackers might get greedy and not settle for just one target. A quote from MongoHQ :

“Currently, it appears that the unauthorized user was scanning for social media authentication information for spamming purposes, and probing for financial information in customer database”

Here are some of the issues that made the MongoHQ hack possible:

  • A support application was accessible through the web and not behind a VPN
  • Customer data was visible to users of this support application (what if the compromise was of an employee?)
  • Two factor authentication was not implemented
  • There was no User Rights Management

Securing data requires, well, some data security

Even Though many factors were responsible for this breach (such as “Excessive and Unused Privileges”, “Privilege Abuse” and “Unmanaged Sensitive Data”), MongoHQ breach root cause is an example of one of Top Ten Database Threats: “Limited Security Expertise and Education”:

“Internal security controls are not keeping pace with data growth and many organizations are ill-equipped to deal with a security breach. Often this is due to the lack of expertise required to implement security controls, policies, and training.”

This means that organizations should rely on the security expertise of 3rd party businesses instead of inventing the wheel or simply closing their eyes. Data security is a business of its own; Data service providers shouldn’t be surprised when breaches occur to non-secured data, and their security learning curve - and their customers (the ones that are left) - can be quite long and painful.

Since the breach, MongoHQ took very significant security measures, but mainly they utilized third-party validation of their security.

With Big Data Comes Big Responsibility

Limited security expertise and education is not only the service provider’s problem, it is also a real concern for its consumers. Were MongoHQ customers aware that their sensitive data was visible to the MongoHQ support application? Do you know who can access your data? How is it stored? Can it be copied?

These are all questions that are all too often forgotten, especially for young startup companies eager to build applications and avoid dealing with security and management costs.

Customers need to know what their service providers are doing to protect their data. This has recently become a new mandate with the rise of PCI-DSS v3.0, where service providers are now accountable for protecting the data of their customers. Data center security needs to be out in the open, especially “up in the cloud”.

While making your data somebody else’s problem is a nice fantasy, you are still accountable when it’s stolen or corrupted. You can’t guarantee your data availability when using a data service provider, but you can at least improve its integrity and confidentiality.

Joel Gascoigne from Buffer also realized this when he wrote on Hacker News:

“I want to be clear that this is still our fault. If access tokens were encrypted (which they are now) then this would have been avoided”.

You as a customer would be smart to take responsibly of your own data. Recognize where your sensitive data is and prepare for the inevitable day when it is compromised.    Additionally, we as customers need to hold our service providers accountable for security instead of just “taking their word.”

 

November 07, 2013
 Incapsula Pen-Test – Part Deux!
Pin It

IStock_000011598938SmallIn 2013, we have been fortunate enough to receive a lot of positive attention for Incapsula product line.  In addition major news coverage garnered by stopping one of the internet’s largest unamplified DDoS attacks, and being ranked by TopTenReviews as the #1 DDoS mitigation service in head-to-head bake off against 9 of our competitors, Incapsula has recently passed a 3rd party pen test with flying colors.

Last week, a new and comprehensive WAF pentest was published, comparing Incapsula’s WAF to CloudFlare’s new Rule-based WAF, the analysis can be downloaded here

The effort was made by Zero Science Lab, who also conducted the last penetration test comparison back in February this year. Zero Science Lab decided to run a “Round 2” penetration test after CloudFlare announced the launch of a new Rule-based WAF in August.  

Excerpts from Zero Science Lab’s Conclusion:

“From the results tables, we can see that Incapsula's WAF continues to have an advantage over CloudFlare's WAF. We should also mention that only Incapsula's WAF is PCI-Certified, which is an advantage for certain types of online businesses.

While CloudFlare's new WAF solution showed substantial improvement since the first penetration test, it still does not provide the comprehensive level of security against certain types of web application attacks (e.g., SQL injection, Remote File Inclusion) that many online businesses today require.

We noticed the high block ratio of XSS attacks, but from all the types of attacks, main focus was on Cross-Site Scripting. The SQL Injection, Local and Remote File Inclusion, and Remote Code/Command Execution attacks had very low detection rate by the CloudFlare WAF.

Incapsula, on the other hand, has shown consistent security performance in both tests, with a high block ratio and few false-positives.”

It was also great to see that our the Incapsula fingerprinting engine triumphed:

"What’s also important to note is that Incapsula can recognize an ongoing attack and block attacker's session. We specifically noticed this during the test using automated tools such as ZAP and Burp. Their blocking mechanism seems to be based on recognizing the fingerprint of the tool being used, so even if you try to trick it by changing the default User-Agent or manipulating other header fields, the WAF will still block your session. We didn't notice such mechanism on CloudFlare's WAF. CloudFlare blocks a session only if an attacker tries to manipulate and send invalid headers"

Our Followup

We have worked through the findings of this report, and patched and adapted to the tests that originally went through. The Incapsula cloud WAF now stops all vectors specified. 

 

 

 

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

 

 

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