Tag Archives: Vulnerabilities

CWE Vulnerability Assessment Report 2014

Last year is almost three months over and we have been busy completing the CWE statistics of our vulnerabilities. The biggest change from the year before is the scale of the data – CWE report for 2013 was based on 37 classified vulnerabilities, whereas last year we classified 617 vulnerabilities in our bugzilla. Out of them 61 were closed with resolution NOTABUG, which means they were either not a security issues, or did not affect Red Hat products. These still include vulnerabilities which affect Fedora or EPEL packages only – narrowing this down to vulnerabilities affecting at least one supported Red Hat product we end up with 479.

The graph below shows the Top 10 weaknesses in Red Hat software. Note the total sum is bigger than overall number of vulnerabilities, as one vulnerability may be result of multiple weaknesses. The most common case is CWE-190 Integer Overflow or Wraparound causing out-of-bounds buffer access problems.

The top spot is taken by cross site scripting with 36 vulnerabilities last year. However, closer examination reveals that despite the count, it was not very common. In fact, two packages had much more XSS flaws that the average: phpMyAdmin with 13 and Openstack (Horizon and Swift) with 7. The standard recommendation to the developers would immediately be to use one of the modern web frameworks, whether it be Ruby on Rails, Django or others.

The second place is occupied by Out-of-bound Read. Again, the distribution of vulnerabilities is not flat among packages, with xorg-x11-server having 9 and chromium-browser 5 vulnerabilities of this type last year. All of the xorg-x11-server come from a single security advisory released on 2014-12-09, which fixed flaws reported by Ilja van Sprundel. The results of his security research of X, which lead to discovery of the flaws, were presented on CCC in 2013. His presentation is a great intoduction into X security problems and is still available.

From the above we could hypothesize that the statistics are dominated by a smaller set of very vulnerable packages, or that certain packages are be prone to certain kinds of weaknesses. The graph below shows a number of vulnerabilities that affected each of the packages – vulnerabilities which did not affected versions of packages we ship are excluded.

Median value of vulnerabilities per package is 1, however, not all packages are equal. Looking at the top 20, all of the packages contain large codebases, some of which are a separate product of an upstream vendor. We should not make a mistake of misinterpreting this graph as Top 20 most vulnerable projects, as it would be more fair to compare apples with apples e.g. kernel (package) with Openstack (which we ship as a product). More honest interpretation would be to see it as a list of packages that increase the attack surface of the system the most when installed.

If we look at statistics per-product, Red Hat Enterprise Linux dominates just by including vast number of packages. The distribution of weaknesses is therefore very close to the overall one show on the first graph above. However, if we look at the top 5 weaknesses in RHEL 5, 6 and 7, we can see a statistically significant drop in number of use after free types of vulnerabilities.

The root cause of this has been traced back to our source code analysis group and the mass scans performed on the Fedora versions prior to RHEL 7 rebase. These scans were performed using a couple of source code analysis tools including Coverity and cppcheck and the warnings were addressed as normal bugs. This explanation is also supported by the decreasing number of found use-after-frees in Fedora from versions 17 to 19, which served as basis for RHEL 7. Interestingly, other weaknesses like buffer access problems and overflows are unaffected, which is probably combination of a) inherent difficulty of their detection via code analysis and b) large number of false positives, making the developers less inclined to address these types of warnings.

The two most common weaknesses in Openshift Enterprise are Information Exposure and Cross Site Scripting. A closer look tells a different story – 5 out of 6 information exposure vulnerabilities were found in Jenkins, shipped as part of the Openshift product. In fact, surprising 21 out of 60 vulnerabilities that affected Openshift product were present in Jenkins. On the other hand, just 9 vulnerabilities were found in core Openshift components.

Interestingly, the distribution of vulnerable components in Openstack is more flat with no component standing out. CWE-400 Uncontrolled Resource Consumption (‘Resource Exhaustion’) is the most common weakness and all of the vulnerabilities affect core Openstack components. Number of vulnerabilities in Keystone related to session expiration (4) is also surprising, as we haven`t seen many vulnerabilities of that type in other packages last year.

Other products and components also tend to have their specific weaknesses: external entity expansion for Java/JBoss based products, out of bounds reads in Freetype, use after free in Mozilla etc. Overall the depth of the data is much bigger and provides new possibilities for the proactive research. Having more precise data for the feedback loop allowing us to both evaluate past measures and propose future ones is next step towards more efficient proactive security. Unfortunately, the time it takes for any countermeasures to make a dent in statistics is measured in releases, so this data will become much more interesting as they change in time.

Vulnerable Mobile Apps are just waiting to be exploited

The Apple AppStore and Google Play are doing a great job in guarding their mobile users from downloading and installing malicious apps.

By centralizing App distribution, mobile platform owners can prevent hackers from uploading malicious apps and potentially infecting millions of users. This is a great lesson that we learned from the PC days where a decentralized distribution system, and open platform, made it easy for malware to spread.

Can we claim a victory on the hackers?  Not quite yet.

The fact that the AppStore and Google Play managed to control the distribution of malicious apps does not mean there are no vulnerable apps out there.

Hackers are clever; they have found ways to get around stringent app store controls by exploiting existing non-malicious apps that are vulnerable. This can be done either via a different app, by inspecting data on transit or even via the web, while you browse from your mobile browser.

 

How can an app be vulnerable?

There are three main ways that an app can be vulnerable to hackers.

Data transmission

Almost all mobile apps transmit and receive data between our devices and remote servers. This allows apps to update, send statistics, check licenses, monitor analytics and so on. There are two ways that this leaves app vulnerable:

  • No encryption – if data leaving your device is unencrypted, hackers can ‘look inside’ it and get your passwords, credit card number or any other personal details you many not want to share. This is most common on public Wi-Fi hotspots like those found in airports, malls or coffee shops.
  • Certificate validation – when apps send data to a remote server, it’s important that it is the correct one and not one owned by a hacker. The use of digital certificates on the server can help the app validate the server’s identity. Without these digital certificates, data can be at risk.

Data storage

As we use mobile apps, most of them store data locally on our devices. These often take the form of log files, which record our activities within an app, the strings we typed in it, cached data/reports and more. There are two ways that these files can leave apps vulnerable:

  • No encryption – storing data on the device can greatly improve app performance and user experience. However, leaving private data unencrypted on the device can be dangerous. A separate app installed on the device can potentially have a permission to access such file, ‘look inside’ and retrieve personal data.
  • Files left after uninstall – when we uninstall apps from our devices, many of us expect that all related files (with our private data in them) are also removed. However, this is no always the case. Apps often have permission to create files in various locations on our devices, these can be left behind when apps are removed. Such fragments can later be accesses by other apps to retrieve data.

3rd party components

It’s quite common for app developers to release their products out to the market very quickly. As time is short, developers reuse components (SDKs) from 3rd parties to support the functionality they need. Example of popular development tools and components can be found here – http://www.appbrain.com/stats/libraries/dev

The issue with these toolkits is that they are not always secure. Here are a few examples:

  • Android WebView – many mobile apps display web content. In order to download and render such content on a mobile device, most Android developers use the WebView component. However this component was identified to be vulnerable to remote attacks – CVE-2012-6636.
  • Dropbox Android SDK – when mobile apps would like to integrate its functionality with cloud storage (like photo apps, wallets, vaults etc.) they integrate SDKs from cloud storage providers. The Dropbox Android SDK was found to be vulnerable – CVE-2014-8889. This vulnerability may enable theft of sensitive information from apps that use the vulnerable Dropbox SDK both locally by malware and also remotely by using drive-by exploitation techniques.
  • Configuration and development errors – as long as humans will continue to code software, vulnerabilities will exist. The increasing complexity of operating systems, databases, app logic and platforms, compounded by short development windows makes it very difficult for developers to catch each and every error in their code. Unfortunately this leaves large volumes of untested code that are potentially vulnerable.

 

Why do apps have these vulnerabilities?

Now that we have identified the main types of vulnerability found within mobile apps, it’s important to understand the root causes behind them. It’s not simply a question of bad coding.

Awareness

Just as with any problem, if you unaware of a risk you won’t pay attention to it. Most developers are trained to deliver functionality, not security.

Small development teams

Unlike PC products, most mobile apps require relatively small development teams. With the ever increasing functionality required and short time to market, the available time to spend on finding vulnerabilities is getting shorter and shorter.

Abandoned apps

Developers have abandoned thousands of apps due to low monetization. These abandoned apps are no longer supported and any vulnerabilities remain indefinitely.

Rush to market

The mobile world is moving faster than ever. Developers need to code and release their apps in almost ‘no time’. While the business demand functionality, that leaves almost no-time to security scanning and audits.

 

What can developers do to secure their Apps?

It’s not all bad news though, there are several things that app developers can do to improve the security of their apps.

  • Learn about secure coding and vulnerable SDKs to avoid common mistakes and deliver a secure app to your users.
  • Embed security testing in the general quality assurance procedures; from unit testing to continuous integration.
  • Use automated tools to statically and dynamically scan and test for vulnerabilities
  • Remove unneeded functionality from your code or stop the distribution of an app that is no longer supported.

 

What can App Store and Google Play do?

Still, developers are not entirely responsible for eradicating vulnerable apps. Official mobile stores employ automatic security scanners to identify malicious apps. These can often be very difficult to detect and it requires lots of resources and attention.

However, a lot of improvements can be made to help prevent the distribution of vulnerable apps.  I believe the most progress can be made in improving communication between the app stores and developers when issues arise:

  1. Developers should receive a notice once their app was found to be vulnerable.
  2. Apps that include popular development tools that were found vulnerable should be notified and asked to update the tool/SDK to a safe version.
  3. Developers should have sufficient time to release a fix, otherwise their app should be unlisted.
Reference: A list of top 10 Mobile Risks was published by OWASP group during 2014 : https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_10_Mobile_Risks
 

BlackBerry Warns Many Products Vulnerable to FREAK Attack

BlackBerry is warning customers that a large portion of the company’s product portfolio is vulnerable to the FREAK SSL attack. Many versions of the BlackBerry OS and BlackBerry Enterprise Server are vulnerable to FREAK, as are a number of versions of BlackBerry Messenger. The advisory from BlackBerry says that there are no workarounds for the […]