web application security

Magento Vulnerability - Check your web sites now

Magento platform is a popular eCommerce framework used by the organisation all over the world to create the Online shops.

The researchers from Check Point discovered the critical security issues, which could potently allow the remote compromise of a Magento based web site and gaining unauthorized access to the customer and credit card information. See the full post here: http://blog.checkpoint.com/2015/04/20/analyzing-magento-vulnerability/ . The vulnerability is currently affecting thousands of online stores. 

Technical Details

Three vulnerabilities were discovered by the Check Point team:

CVE-2015-1398 - An authentication bypass vulnerability was reported in Magento component. The vulnerability is due to a user controlled parameter affecting the login mechanism. A remote attacker can exploit this issue by sending a specially crafted HTTP request to a vulnerable system. Successful exploitation may allow the attacker to gain access to a target system.

CVE-2015-1397 - An SQL injection vulnerability has been reported in Magento component. Successful exploitation of this vulnerability would allow a remote attacker to execute arbitrary SQL commands on the affected system.

CVE-2015-1399 - A remote file inclusion vulnerability has been reported in Magento component. The vulnerability is due to lack of sanitization for user-supplied data. Successful exploitation of this vulnerability could allow a remote attacker to execute arbitrary code on the affected system.

What should you do

Check your Magento implementation using our Trial Web Site Assessment Service  and see if you are vulnerable. If yes, apply the designated patch SUPEE-5344 released by Magento as soon as possible. 

SSL 3 is dead, killed by the POODLE attack

The POODLE Attack (CVE-2014-3566)

Update (8 Dec 2014): Some TLS implementations are also vulnerable to the POODLE attack. More information in thisfollow-up blog post.

After more than a week of persistent rumours, yesterday (Oct 14) we finally learned about the new SSL 3 vulnerability everyone was afraid of. The so-called POODLE attack is a problem in the CBC encryption scheme as implemented in the SSL 3 protocol. (Other protocols are not vulnerable because this area had been strengthened in TLS 1.0.) Conceptually, the vulnerability is very similar to the 2011 BEAST exploit. In order to successfully exploit POODLE the attacker must be able to inject malicious JavaScript into the victim's browser and also be able to observe and manipulate encrypted network traffic on the wire. As far as MITM attacks go, this one is complicated, but easier to execute than BEAST because it doesn't require any special browser plugins. If you care to learn the details, you can find them in the short paper or in Adam Langley's blog post.

 

What Now?

POODLE is a protocol-level vulnerability that can't be easily fixed. Although it might be possible to attempt a BEAST-style mitigation, it seems that browser vendors are not interested in that approach. Adam said Chrome won't pursue that direction. Firefox said they would disable SSL 3 in Firefox 34. And that's great news. Traditionally we struggle with letting go of old protocols. Because SSL 3 is not very widely used and POODLE is serious enough, it seems that we'll be able to retire this old protocol version soon. In fact, some CDNs have already disabled it.

 

What You Should do

You can look at this problem from two perspectives. As a user, you want to protect yourself from attacks, and the best way to do that is to disable SSL 3 in your browser. (Instructions are easy to find online.) The updated SSL Labs Client Test will tell you if your change was successful.

As a web site operator, you should disable SSL 3 on your servers as soon as possible. You need to do this even if you support the most recent TLS version because an active MITM attacker can force browsers to downgrade their connections all the way down to SSL 3, which can then be exploited. In normal operation, SSL 3 shouldn't needed by the vast majority of sites. Although it's likely that there's a long tail of clients that don't support anything better, Internet Explorer 6 on Windows XP is potentially the biggest user segment that still relies on SSL 3. Options are to guide users to manually enable TLS 1.0 (IE6 supports it, but not by default) or upgrade to other browsers. In the short term, it's possible to mitigate POODLE by avoiding using CBC suites with SSL 3, but that involves relying on a certain insecure stream cipher whose name no one wants to mention. I don't recommend this approach.

 

POODLE wouldn't be as serious without the ability of the active network attacker to downgrade modern browsers down to SSL 3. There's a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective. Google implemented this feature in February (in Chrome and in their web sites) and has been successfully using since. Mozilla said Firefox will support the indicator in early 2015. A new version of OpenSSL has just been released, which includes support for the SCSV. The support might be backported to various Linux distributions. For best results, support also needs to be added to other major browsers. Once that happens, the POODLE attack surface will be much smaller; it will affect only the users with older browsers.

 

For detailed guidance on how to disable SSL 3 in various servers and browsers, head to Scott Helme's blog post. Qualys customers should go here to learn how to configure reports to find systems that use SSL 3.