* 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 taht 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.

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 hones – 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.

Why does this matter?

Businesses rely on 3^rd 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.

What can an organization do to protect itself?

This hack could have been probably prevented by either constantly patching of all the 3^rd 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 3^rd party service that got compromised, however the security implications are the same.

 

Earlier 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.

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.

 

Sharing 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.

Oracle has released its Critical Patch Update, which is focused on fixing a major Java exploit. Java vulnerabilities are clearly on the rise. Currently, they represent more than 10 percent of all reported vulnerabilities this year (see Nist.gov) and are reported to be the root cause of some of the high profile compromised insider incidents.

What can I do to protect my organization?

In a perfect world, we would advise administrators to disable Java on all browsers, but generally speaking, having IT administratively disable ANY software component on “all user machines” is nearly impossible, especially in today’s bring your own device (BYOD) IT environment. The current case of disabling Java components is no different.

The lesson the world should have already learned from incidents such as the Stuxnet attacks is that protection should be around data rather than around devices. Closely monitoring and controlling data at the source is one part of the solution. Another solution is to look for abusive access patterns to data or patterns that reflect the behavior of an outsider within our perimeter. Coupled with data encapsulation, organizations can achieve true mitigation of such risks.

Additionally, individual users should turn off Java 7 browser plug-ins and only enable them specifically to trusted site (such as the mentioned “Java-powered line of business applications”). See the following link for instruction on how to do so in Google’s Chrome browser here.

Yesterday, the Iranian CERT made an announcement about a new piece of malware that was designed to corrupt data. This malware joins the list of data corruption malware discovered in April, November and December 2012 – Wiper, Narilam and now GrooveMonitor respectively.  They wrote:

Latest investigation have been done by Maher center in cyber space identified a new targeted data wiping malware. Primitive analysis revealed that this malware wipes files on different drives in various predefined times. Despite its simplicity in design, the malware is efficient and can wipe disk partitions and user profile directories without being recognized by anti-virus software. However, it is not considered to be widely distributed. This targeted attack is simple in design and it is not any similarity to the other sophisticated targeted attacks.

GrooveMonitor does not pose a real threat to companies since it attack local files only and not the datacenter (databases or file shares) nor the datacenter backup. However, the Narilam malware discovered last month is a database sabotage malware. Its purpose is to corrupt databases of three financial applications from TarrahSystem used for banking, loans, retails and industrial applications.  But it is not a technical beauty pageant. When all of your data gets wiped and your antivirus proves to be worthless , do you take comfort in the fact the malware was simplistic?

Indeed, this new malware raises the question – are these just singular incidents or do we witness a trend of malware designed to corrupt data rather than steal it? While all three malware attacks originated in Iran, a country of great interest for several espionage agencies around the world, only Wiper is believed to be state-sponsored. The authors of the other two were probably inspired by Wiper to some extent. As Microsoft’s director of trustworthy computing Tim Rains stated nicely this week: “Unintended consequence of operating a sophisticated cyber espionage activity is that criminal groups are essentially given free research on how to infect systems and little-known vulnerabilities are brought to the forefront.”

This is just as true for method of operation. It is easier to hurt a competitor’s business by sabotaging its production systems by corrupting data rather than operating a complicated long term espionage campaign for stealing data. Roel from Kaspersky security blog sums it up: “If it wasn't clear already - the era of cyber-sabotage has arrived. Be prepared.”

 

Our anti-antivirus study got a lot of attention (you could say it went viral).  Most interestingly, people called our methodology “flawed.” 

While our report acknowledged the limitations of our methodology, we believe that, fundamentally, the model for antivirus—and not our methodology—is flawed.  Antivirus was built years ago during an age when mass infections was the name of the game.   Today, malware is deployed to target SPECIFIC individuals—CEOs, researchers, politicians, executives—and not everyone’s mom. 

One reaction to our study asserted that a virus can be blocked based on source IP:  “email with the malware attached, or the included URL… could have been blocked based on its source IP.”   This approach, however, addresses an old threat model in which the attacker would try to infect as many as possible targets with a single campaign – that included reusing URLs to hoax the malware and IP addresses to send an email. Reusing IPs allowed security companies to have blacklists for both IPs and URLs. However, in today’s threat scape, where we consider attackers that are specifically targeting a specific victim, they create a dedicated URL to host the malware and use a dedicated IP address to send malicious mail, easily overcoming blacklists.

Our study concluded that antivirus solutions are very effective in fighting widespread malware, and slightly less effective for older malware (2-3 month old).  But for a new malware, there is a good chance it will evade the antivirus.  In fact, our results are consistent with other studies.    For example, let’s look at the AV-TEST Institute’s results.  

The AV-TEST Institute, according to their site, is a “leading international and independent service provider in the fields of IT security and anti-virus research.”  According to AV-TEST’s website, in order to test the protective effect of a security solution, AV-TEST researchers simulate a variety of realistic attack scenarios such as the threat of e-mail attachments, infected websites or malicious files that have been transferred from external storage devices. When carrying out these tests, AV-TEST takes the entire functionality of the protection program into account. But even when all of the Anti-virus functionality enabled, the results reveal a worrisome security gap:

 

While antivirus solutions are very effective in fighting widespread malware and slightly less effective for older malware, for a new malware, there is a good chance it will evade the antivirus solutions.  That’s exactly what we found.

Finally, one should ask a question CEOs are asking CISOs worldwide:   if antivirus software is so good, how come we see so many successful attacks based on infected computers (Coca-Cola, South Carolina DoR to name a few)? And the obvious answer is that antivirus is not perfect and needs to be augmented with data security solutions, as was honestly acknowledged by antivirus veteran researcher, Mikko Hypponen “Antivirus systems need to strike a balance between detecting all possible attacks without causing any false alarms. And while we try to improve on this all the time, there will never be a solution that is 100 percent perfect. The best available protection against serious targeted attacks requires a layered defense.”

A new attack makes some password cracking faster, easier than ever.  A researcher has devised a method that reduces the time and resources required to crack passwords that are protected by the SHA1 cryptographic algorithm.

First, some context. One of the main use cases for hashing function, such as the SHA-1 function, is to store passwords securely. When attackers obtain such hashed password, they need to launch a “brute force” attack against it, in order to reveal the password. “Brute force” means, they need to repeatedly guess the password, apply the hashing function on it and compare the result with their hash password they have. The security researcher has found an algorithmic shortcut in SHA-1 calculation that makes the computation easier, thus reducing the time needed to successfully “brute force” an attack.

But it should not surprise the security community, as the writing was on the wall. When a crypto hash is weakened (i.e., discovered to be less secured than perceived), it usually marks the start of its downfall and SHA 1 has been weakened since 2004.  This chart of the state of popular crypto hashes from 2009 (http://valerieaurora.org/monkey.html) shows just that:

 

The corollary?  In case the hashing is done for security (e.g. hash user passwords, verify data integrity, etc.):

• MD5 is dead and should never be used.
• SHA-1 is going in the same direction.  Consider an upgrade of existing systems and definitely don't use it for new systems.

A smart choice would be to follow the U.S. National Institute of Standards and Technology (NIST) recommendation for federal agencies: "Federal agencies should stop using SHA-1 for generating digital signatures, generating time stamps and for other applications that require collision resistance." 

Best option? Use a hash function from SHA-2 family, such as the SHA256.

 

 

Recently, US banks were warned about automated attacks coming from Havij, a SQL injection attack tool. While we've blogged on stopping SQL injection in the past, it is a topic always worth revisiting. 

First, let's make clear what WON'T help.  Earlier this month, Kevin Mitnick gave a talk at the US Naval Academy.  The first lesson?

All the firewalls and intrusion detection systems in the world won’t be a guarantee that networks won’t be breached.  There’s no such thing as an impenetrable system, and no such thing as bugless software. Kevin’s demonstration of exploiting vulnerabilities in widely used commercial software proves this. Moreover, this isn’t just software being used in the private sector.  Many of the exploits he demonstrated take advantage of software that’s become an integral part of the way the military handles its information.

Havij exploits vulnerabilities in software and is totally invisible to network firewalls/IPS.  Havij relies on a blind SQL injection vector, so if you protect against it you are safe.  Here's how:

1. Negative security model:  Protect against SQL Injection by blacklisting certain known SQL injection manifestations.
2. Positive security model:  Every injection violates the normal application usage profile.
3. Identifying automated interactions:  Havij is not human and behaves like a robot.  You can detect it by merely detecting the specific user agent string but also more subtle details such as constant values within the SQL attack itself.
4. Clean code.

From a technology standpoint, only three types of products will help defeat Havij:

1. Vulnerability scanners
2. Code scanners
3. Web application firewalls

Often, we see companies using vulnerability scanners and, to a much lesser extent, code scanning.  These technologies are very important but they only find issues.  Scanners tell you have problems but you have to figure out where they may be.  Code review gives you a specific line to remediate, but this takes time.  If you are under an imminent Havij attack, these products won't help with immediate risk. 

OWASP has argued in the past that technologies focused on finding vulnerabilities are useful but have one major problem:  they don't block attacks.  This is why they recommend a web application firewall.  (Full disclosure:  we are a WAF vendor.)  WAFs do provide a shield against immediate attack and--at least in our case--we can recognize Havij and stop it.  Havij does come with some WAF evasion functionality--but it only works on Web Knight and ModSecurity.

Firefox is leaking URLs data across domain, by not restricting javascript’s “location” method.  How does it work?

A “proof of concept” exploit for the vulnerability exists (for more, check this out).

1. A user browses to the attacker site.
2. That attacker opens a new window in Twitter from attacker site.
3. If the victim is signed in to twitter, then the user gets redirected to a URL that contains a personal twitter ID.
4. The attacker can now query the new window on the URL and obtain the victim’s personal twitter ID.

On previous versions of Firefox, this attack would fail:

There was a regression in Firefox 16 that allowed this attack to work:

 

 

 

Great perspective from our own Tal Be'ery on managing Java vulnerabilities.