Tag Archives: security

Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see my previous blog). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three in its top 10 list of mobile security problems of 2014.

One recent study found that thousands of mobile apps still used an old version of the OpenSSL library that was vulnerable to the FREAK attack. A similar problem was revealed by the creators of a popular mobile networking library called AFNetworking, when they disclosed a serious bug in their library that bypassed all SSL/TLS security checks. Although this bug and the one in OpenSSL were quickly corrected, thousands of mobile apps remain vulnerable until their developers recompile with the fixed version of AFNetworking or OpenSSL, and users upgrade to the fixed version of each app. Because these bugs were in application libraries and not in the operating system, phone vendors cannot automatically apply a patch. Given the slow rate at which users upgrade mobile apps, these vulnerable apps are likely to be with us for a long time.

Failure to properly write and test SSL/TLS-related code might be due to ignorance or an assumption that the platform or library will “get it right”.  Sometimes SSL/TLS checks are disabled during development and debugging. App creators intend to re-enable the checks before the app is shipped, but they forget. That’s apparently what happened with Fandango and Credit Karma, who were cited last year by the FTC for SSL/TLS failures in their mobile apps.

Developers don’t have to use blind faith; some good tools are now available for testing how an app works in the presence of a Man-in-the-Middle (MITM) like CERT’s Tapioca.

In addition to the SSL/TLS certificate validation tests described in the white paper linked by my earlier blog, developers might also consider Public Key Pinning, defined in a relatively new RFC from the Web Security working group at the Internet Engineering Task Force (IETF). Developers need to apply caution, however, since one study pointed out the difficulty of building it correctly and the consequences of mistakes.

This post uses information taken from the Symantec Website Security Threat Report 2014 Part One.

2014 saw a change in tactics for those attempting to attack websites and their users. While the number of websites infected with malware decreased almost 50% (from 1 in 566 to 1 in 1126), the number of web attacks decreased by just 13%. This means that each infected website was responsible for many more attacks compared to 2013.

The reason is a huge change of tactics by cyber criminals, who are now using web attack toolkits that are designed to be used in the cloud as Software-as-a-Service (SaaS). These SaaS toolkits use a HTML iframe tag or some obfuscated JavaScript in order to inject malicious code from the SaaS-based exploit toolkit rather than launch the malicious attack directly from exploit code hosted on the compromised website itself.

In terms of the most exploited categories of websites, the attackers are also keeping up with the tech trends. We have seen ‘anonymizer’ websites – which are used to increase web users’ online privacy – break into the top 10 for the first time while automotive sites have dropped out of the top 10.

For much more information on the website security landscape and how you can keep your website visitors safe download the first part of the WSTR here.

The first part of the WSTR 2015 is finally available, and dedicates a chapter to 2014 vulnerabilities and how they have changed our vision of threat response. You can read the first part of the WSTR here.

The good news is that we have discovered fewer vulnerabilities in 2014 than in 2013 (we have observed a 3.6% decrease). However, the bad news is that it doesn’t mean the discovered vulnerabilities were less dangerous. Three words are enough to make any IT manager shiver to the thought of what they have had to endure in 2014: Heartbleed, Shellshock, and Poodle.

Heartbleed is by far the vulnerability we have heard the most about. Discovered in April 2014, this bug received quite a lot of media attention as it impacted both users and servers, and didn’t require a man-in-the-middle position to exploit the vulnerability. It has been a year since the discovery of Heartbleed, and this bug is still raising concerns as it seems that many organizations didn’t remediate properly to the situation.             
 

Shellshock and POODLE were discovered later in 2014 – POODLE got a second round of attention in December when we discovered the vulnerability could affect TLS connections as well. Although less dangerous than Heartbleed, these vulnerabilities remained critical for website security and required immediate attention.

The 3 vulnerabilities shared a key similarity: they were related to technologies and software which have been widely accepted and used around the world, leading to serious and potentially dramatic data breaches if no action was taken to fix them.

This should, however, not be a reason to start panicking and foreseeing the end of website security as we know it today. Although its implementation has revealed critical flaws last year, the SSL/TLS protocol itself remains trusted and secure.

Furthermore, what the first part of the WSTR highlights here is:

1. No matter what, we remain in a very fast-paced, rapidly-evolving sector with numerous third-parties – including hackers – and constant changes in norms and standards. To be realistic, these vulnerabilities discovered in 2014 are not the first and not the last we will hear about.
2. We have learned from these vulnerabilities, and we are moving forward to a new type of management of our infrastructures. We can notably mention the faster response time of Microsoft and other major actors of the sector during such critical times, as well as the rise in awareness about the lack of funding for some Open-source projects and the dangers of re-using code as a general practice. What Tim Gallo jokingly refers as the “dirty secrets of application development” in pages 19-20 of the WSTR, part 1.  

Reusing code is indeed a well-known but deliberately concealed risk of Open-source projects. It is a convenient habit that no one really wanted to bring out from the shadow until Heartbleed put it under the spotlight. Yet instead of blaming each other for not having detected such a fatal flaw in OpenSSL, the website security industry didn’t stay inactive, and tried its best to learn and evolve. As Tim Galo underlined in the report, it had made everyone realize how we need a better organization of our network infrastructures. “Better enforcement of configuration, policy, and patching across entire infrastructures will help. The moving of infrastructure to the cloud also helps an overworked IT professional manage these issues as well”. The Core Infrastructure Initiative is, for example, a very positive result of the industry leaders’ reaction to Heartbleed.

Symantec strongly encourages such initiatives. We believe it is vital to react quickly, develop threat intelligence, document previous vulnerabilities and share as much data as possible in order to fight against the ever-evolving threat landscape. The WSTR we publish every year belongs to such initiatives and we would like not only every IT manager and application developer to read it, but also employees and individuals. Because we’re all concerned by the security of our data at some point – even if at different levels.