Coinapult, a long-running bitcoin wallet service, announced on Monday that its hot wallet had been compromised to the tune of 150 coins – around $42,900.
The post $40k of bitcoin lost in Coinapult hot wallet hack appeared first on We Live Security.
Monthly Archives: March 2015
Apple Patches WebKit Vulnerabilities in Safari
Apple released new versions of Safari that patch a number of WebKit vulnerabilities.
OpenSSL: Patch for secret “high severity†vulnerability
And indeed, in order to avoid being again in the news, the OpenSSL Foundation is set to release later this week several patches for OpenSSL, fixing undisclosed security vulnerabilities, including one that has been rated “high” severity.
Matt Caswell of the OpenSSL Project Team announced that OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf will be released Thursday.
“These releases will be made available on 19th March,” Caswell wrote. “They will fix a number of security defects. The highest severity defect fixed by these releases is classified as “high” severity.”
OpenSSL has been hit hard and the trust in it and in open source in general has been severely shaken in the last 12 months.
Last year in April, Heartbleed (CVE-2014-0160) was discovered in older versions of OpenSSL, but still highly used, which allowed hackers to read the sensitive contents of users’ encrypted data, such as financial transactions, instant messages and even steal SSL keys from Internet servers or client software that were running the affected versions of OpenSSL.
Two month later, in June the same year, a Man-in-the-Middle (MITM) vulnerability (CVE-2014-0224) was discovered and fixed. However, the vulnerability wasn’t quite as severe as the Heartbleed flaw, but serious enough to decrypt, read or manipulate the encrypted data.
In October last year, POODLE (CVE-2014-3566) (Padding Oracle On Downgraded Legacy Encryption) was discovered in the obsolete Secure Sockets Layer (SSL) v3.0 that could allow an attacker to decrypt contents of encrypted connections to websites. When exploited, it allows an attacker to perform a man-in-the-middle attack in order to decrypt HTTP cookies. The POODLE attack can force a connection to “fallback” to SSL 3.0, where it is then possible to steal cookies, which are meant to store personal data, website preferences or even passwords.
Just weeks ago, the latest vulnerability, FREAK (CVE-2015-0204) (Factoring Attack on RSA-EXPORT Keys) was discovered in the SSL protocol that allowed an attacker to force SSL clients, including OpenSSL, to downgrade to weaken ciphers that can be easily broken. Needless to say that such a weak encryption could potentially allow them to eavesdrop on encrypted networks by conducting man-in-the-middle attacks. This time, pretty much every big software vendor was affected: Apple, with its MacOS, iPhone and iPad, Google with Android and Chrome and last but not least, Microsoft with all versions of Windows.
Due to its widespread use, OpenSSL is considered an important software project and is ranked first under the Linux Foundation’s Core Infrastructure Initiative. Because of its complexity, high usage and lack of in-depth security reviews, companies like Google, Facebook and Cisco are heavily sponsoring this project in order to avoid being again affected by long forgotten bugs.
Well, for OpenSSL seems that this is starting to pay off.
The post OpenSSL: Patch for secret “high severity” vulnerability appeared first on Avira Blog.
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.
[visualizer id=”1684″]
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.
[visualizer id=”1700″]
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.
[visualizer id=”1714″]
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.
[visualizer id=”1690″]
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.
[visualizer id=”1716″]
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.
[visualizer id=”1696″]
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.
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.
Kaspersky Lab Survey: Companies Under DDoS Attack Fear Losing Business Opportunities the Most
Apple Releases Security Updates for Safari
Original release date: March 18, 2015
Apple has released security updates for Safari to address multiple vulnerabilities. Exploitation of these vulnerabilities may allow a remote attacker to execute arbitrary code or prevent users from discerning a phishing attack on an affected system.
Updates include:
- Safari 8.0.4 for OS X Mountain Lion v10.8.5
- Safari 7.1.4 for OS X Mavericks v10.9.5
- Safari 6.2.4 for OS X Yosemite v10.10.2
US-CERT encourages users and administrators to review Apple security update HT204560 and apply the necessary updates.
This product is provided subject to this Notification and this Privacy & Use policy.
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:
- Developers should receive a notice once their app was found to be vulnerable.
- Apps that include popular development tools that were found vulnerable should be notified and asked to update the tool/SDK to a safe version.
- 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
Cyber safety: one of the major companies concerns
I’m sure you have read about Sony’s latest leaks, the cyberattacks to Medias like The New York Times and the chaos created when cybercriminals paralyzed some banks payment networks. Nevertheless there are many other silent virtual crimes: both big corporations and small and medium businesses can suffer breaches in their data without anyone noticing anything, not even the workers.
Nowadays most banking transactions are conducted online, and almost every company has a web platform where they manage their documents and emails. That makes me wonder why computer security remains an outstanding issue in many organizations. Are they aware of the risks they are taking? Or, is it just that the new types of malware surpass their security measures?
This is not a trivial issue as we saw in the World Economic Forum (WEF), which took place last January in Davos (Switzerland). Many analysts, politicians and CEOs showed their concern and warned the public about this issue.
John Chambers, Cisco’s CEO, could not have said it better: “There are two types of companies: those who have been hacked, and those who don’t yet know they have been hacked.” Putting into words the issue’s significance at the WEF.
Moreover the situation is echoed by the 2015 Global Risks Report, elaborated by the WEF, and includes the cyberattacks as the futures more pressing dangers. “Innovation is critical to global prosperity, but also creates new risks. We must anticipate the issues that will arise from emerging technologies, and develop the safeguards and governance to prevent avoidable disasters.” said the President of Global Risk and Specialties at Marsh.
Technological Risks according to the Global Risks Report 2015 at the World Economic Forum
Cyber safety is now one of the major companies concerns. The forum had already published another analysis dedicated solely to this issue: “Risk and Responsibility in a Hyperconnected World” in collaboration with McKinsey & Company.
According to the experts, the technology sector, which includes big data analysis and cloud storage, could produce between 9.6 and 21.6 billion dollars of global profits.
Cybersecurity is precisely one of the barriers that ensure the favorable indicators. But if the sophistication of the attacks surprises the defensive capabilities of the equipment, the altercation would cause serious damages. In addition, the implementation of new regulations and limits for the corporations would slow down the economic and technological innovation and progress.
The report states that in order to protect companies and society in general from the negative effects a collaboration framework between public and private sectors should be stablished. Global cooperation from the authorities in order to develop new strategies that replace the traditional obsolete ones is needed.
The cost of the attacks can conceal the possible profits. Stephen Catlin, president of Lloyd (insurance market) recently claimed that the losses caused by cybercriminals can reach so important sums of money that the governments should take responsibility.
Also, companies need funds in order to research new types of malware and develop new methods that prevent cybercrimes. Chambers ended his speech at the forum expressing his fear of what is about to happen: “In 2014 the issues related to cybersecurity have deteriorated, and 2015 would be much worse.”
So, try our corporate antivirus for best corporate endpoint protection!
The post Cyber safety: one of the major companies concerns appeared first on MediaCenter Panda Security.
CVE-2014-6129 (rational_collaborative_lifecycle_management, rational_doors_next_generation, rational_quality_manager, rational_requirements_composer, rational_team_concert)
IBM Rational Jazz Team Server (JTS), as used in Rational Collaborative Lifecycle Management 3.x and 4.x before 4.0.7 iFix4 and 5.x before 5.0.2 iFix2; Rational Quality Manager 2.x and 3.x before 3.0.1.6 iFix5, 4.x before 4.0.7 iFix4, and 5.x before 5.0.2 iFix2; Rational Team Concert 2.x and 3.x before 3.0.1.6 iFix5, 4.x before 4.0.7 iFix4, and 5.x before 5.0.2 iFix2; Rational DOORS Next Generation 4.x before 4.0.7 iFix4 and 5.x before 5.0.2 iFix2; Rational Requirements Composer 2.x and 3.x before 3.0.1.6 iFix5; and other products, allows remote authenticated users to delete the dashboards of arbitrary users via unspecified vectors.