News on the problems on Internet security have been very frequent during last 12 months, and there does not seem to be any stop on news on Internet security problems.
The news started with NSA relevations that showed ho much NSA spied on the Internet users and how it has weakened the technologies used to project the user data in Internet. Keeping Your Data Private From the NSA was proven to be quite hard. The biggest NSA details have much been revealed, and you can find them at The NSA Archive. Edward Snowden exposed the NSA’s widespread efforts to eavesdrop on the internet, encryption was the one thing that gave us comfort. Snowden also warned that crypto systems aren’t always properly implemented.
The follow-up was a massive series of hits on the SSL security. SSL stands for Secure Sockets Layer, and it’s what helps ensure secure communication between your browser and your favorite web site. TLS, or Transport Layer Security, is a more recent protocol that does essentially the same. Hypertext Transfer Protocol Secure (HTTPS) is a communications protocol for secure communication over a computer network. HTTPS is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. This is the technology that keeps the Internet communications safe and allows us to access Internet services safely (for example to read your web mail, do credit card payments on web shops and do your on-line banking).
First in this series as was Apple’s epic security flaw in it’s SSL implementation. In February 2014 a mysterious, urgent update began pouring out to iOS devices. From there, the news just got worse. It wasn’t just an iOS bug, but a problem in Apple’s Secure Transport platform, present in OS X 10.9 for desktop and reaching back to iOS 6 on mobile. The vulnerability extended to every application built on Apple’s SSL library and was had gone unnoticed for 18 months. It was a SSL encryption issue that leaves iPhone, iPad and Mac computer users open to a man-in-the-middle (MITM) attack. A man-in-the-middle attack seamlessly intercepts communication between yourself and your intended recipient or website (the one who listens to traffic can read unencrypted user passwords). The security issue was bad and scary, but it now fixed. The actual problem was a pretty small programming error in the Apple SSL/TLS library file called sslKeyExchange.c in version 55741 of the source code. The problem was named “goto fail“.
This was unfortunately only a start, and the thing started getting to much worse direction in April. Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros articled told that a major security bug faces Linux users, akin to the one recently found in Apple’s iOS (and which Apple has since fixed). This GnuTLS bug is worse than the big Apple “goto fail” bug because hundreds of open source packages, including the Red Hat, Ubuntu, and Debian distributions of Linux, are susceptible to attacks. The bug in the GnuTLS library makes it trivial for attackers to bypass secure sockets layer (SSL) and Transport Layer Security (TLS) protections available on websites that depend on the open source package.
As if that was not enough, then comes the Attack of the week: OpenSSL Heartbleed. Heartbleed Is the Ultimate Web Nightmare that I would have not wanted to see. Security expert Bruce Schneier says “‘catastrophic’ is the right word. On the scale of 1 to 10, this is an 11.” That’s about right. This was a very severe two-year-old security hole right in the core of the Internet security.
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This can compromises the secret keys used to identify the service providers, which allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users. Basically, an attacker can grab 64K of memory from a server. The attack leaves normally no trace, and can be done multiple times to grab a different random 64K of memory. Exploitation of this bug leaves no traces of anything abnormal happening to the logs.
You might ask what versions of OpenSSL are affected? OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable. The newest version OpenSSL 1.0.1g is NOT vulnerable. Old OpenSSL versions at OpenSSL 1.0.0 branch and OpenSSL 0.9.8 branch are NOT vulnerable. While Heartbleed only affects OpenSSL’s 1.0.1 and the 1.0.2-beta release, 1.01 is already broadly deployed.Top ten biz software vendors reveal Heartbleed exposure, and so have also many smaller ones. Check the software you use against vulnerable software list.
The flaw was released as zero-day bug for what there was not fix at the moment the details were released. There are views that it have been known to black hats before its public discovery and disclosure. The bug was found some time ago independently by Finnish security testing company Codenomicon and Google researcher Neel Mehta. Some operating system, security companies and OpenSSL developers were already at work at delivering the patched versions. CloudFlare, a Web security company, revealed in a blog posting details about the security hole and that they’ve fixed the bug a bit too early before fixes were ready for broad deployment.
How am I affected as an end user? You are likely to be affected either directly or indirectly. OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Most notable software using OpenSSL are the open source web servers like Apache and nginx,which have a combined market share of over 66% of the active sites on the Internet that use HTTPS. Half a million sites were vulnerable. Situation changes as sites get fixed. Here are some vulnerable site lists: The Heartbleed Hit List: The Passwords You Need to Change Right Now, Heartbleed bug: Check which sites have been patched and Heartbleed Alexa top 10000.
Furthermore OpenSSL is used to protect for example email servers, chat servers, virtual private networks (SSL VPNs), network appliances and wide variety of client side software. OpenSSL is also included in Android, the number one smart phone operating system (over 79% market share). Heartbleed Bug hits at heart of many Cisco, Juniper products. While most attention surrounding OpenSSL’s Heartbleed vulnerability has been given to the server side, the SANS Institute has reminded the world that the client side is also vulnerable and writing code to exploit vulnerabilities in clients is not going to be that difficult as the details are out on the wild.
Is my mobile affected? Yes. Heartbleed Bug Impacts Mobile Devices. Vulnerable OpenSSL is included in many Android version, but in most Android versions the Heartbeats feature was disabled (so not vulnerable). Depending on the source vulnerable Android versions are 4.1.1 and 4.2.2 or only 4.1.1. There are also many Android, iOS, and WP8 apps that are affected by Heartbleed.
The Heartbleed bug is affecting routers, too: Cisco Systems and Juniper Networks have announced that the Heartbleed bug has been found in their networking products. This news isn’t too surprising, as any device using OpenSSL is potentially vulnerable. Many routers and other forms of networking equipment use OpenSSL to secure mini web servers to run admin interface, leaving networking equipment vulnerable as a result. Networking Equipment Makers Scramble to Patch Heartbleed: Networking vendors Cisco, Juniper Networks, F5 Networks and Fortigate have all issued security alerts, disclosing that some of their products are affected by Heartbleed. Cable boxes and home Internet routers are just two of the major classes of devices likely to be affected , and ISPs now have millions of these devices with this bug in them. The same issue likely affects many companies, because plenty of enterprise-grade network hardware and industrial and business automation system also rely on OpenSSL, and those devices are also rarely updated. There are thousands of “shoestring budget” VPN concentrators in smaller businesses that will be vulnerable and probably won’t be updated. On the VPN side also excellent OpenVPN VPN-software is vulnerable if your system has OpenSSL version or your OpenVPN is compiled with vulnerable OpenSSL.
If you administer of any embedded networked device, check your device manufacturer if they have published information on vulnerabilities. To be sure you need to check the OpenSSL version or run vulnerability scanning, but checking these devices for the flaw is a laborious process. This is why many home automation systems and networking equipment vulnerable to a major encryption flaw are unlikely to be fixed. If you have such devices in use, there is also possibility that your devices are not affected by the bug because they can use old enough OpenSSL version that does not have this bug (OpenSSL versions 0.9.8 and 1.0.0 are very widely used even on quite recent embedded systems).
There has been discussion themed like Has the NSA Been Using the Heartbleed Bug as an Internet Peephole? It is hard to say for sure if it has been used or not. You can bet that whatever hackers and government agencies have not done this before, they’re doing it now. Security expert Bruce Schneier says that probability is close to one that every target has had its private keys extracted by multiple intelligence agencies. So far, though, there’s no evidence to suggest this is the case and grabbing the private keys stored on a server’s memory isn’t without problems.
What you can do as an end user? Not very much. The problem is very much on the server end, and the service provider has to fix it first before you can do anything useful as end user. First you wait that your site has been updated (Check which sites have been patched). After the site has been patched, it is a good idea to change the password in case it has leaked. For information on which sited it would be a good idea to change password, check the following lists: The Heartbleed Hit List: The Passwords You Need to Change Right Now, Heartbleed bug: Check which sites have been patched and Heartbleed Alexa top 10000. Do not log into accounts from afflicted sites until you’re sure the company has patched the problem. Keep a close eye on financial statements for the next few days. Because many of the vulnerable sites were well known web shops and attackers could maybe have accessed a server’s memory for credit card information, so it wouldn’t hurt to be on the lookout for unfamiliar charges on your bank statements.
So not only is every password you’ve used at a vulnerable site at risk — the bigger problem is that although major vendors and websites are scurrying to fix this problem now, smaller apps and sites might take more time. Or worse, they might ignore the problem altogether. Remember that a malicious server could easily send a message to vulnerable software on phones, laptops, PCs, home routers and other devices, and retrieve a 64KB block of sensitive data from the targeted system. Security penetration testers are going to find themselves in work a long time with this.
What if you are are a server operator? Test your own site vulnerability here or using one of these tools (use at your own risk). Run the test only against your own site, because It might be ILLEGAL to run Heartbleed health checks against sites without the site owner permission. Check also the software you use against vulnerable software list. If you have this problem, then what to do? The remedy is unfortunately pretty nasty. Having identified a problem, the first step is to patch OpenSSL to 1.0.1g version. If you can’t update library, you can recompile existing version with the -DOPENSSL_NO_HEARTBEATS option. Sadly, this is only the beginning because there’s no way to tell whether a server had been exploited because this bug leaves no traces of anything abnormal happening to the logs. Bruce Schneier advice: After you patch your systems, you have to get a new public/private key pair, update your SSL certificate, and then change every password that could potentially be affected. Have fun. Its a lot of work.
Fortunately IDS/IPS technologies can be used to detect if someone it trying to attack you this way. Although the content of the heartbeat request is encrypted it has its own record type in the protocol, which allows intrusion detection and prevention systems (IDS/IPS) to be trained to detect the use of the heartbeat request. There are now signatures available to detect exploits against Heartbleed, as Dutch security firm Fox-IT points out on its website.
Now the main details of the bug are told. For simple visual explanation of Hearbleed but take look at XKCD Heartbleed Explanation. For more stories on this check out Heartbleed web page and Behind the Scenes: The Crazy 72 Hours Leading Up to the Heartbleed Discovery article.
Deep technical details of the OpenSSL bug
Bug is in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server. Basically, an attacker can grab 64K of memory from a server. This can happen during connection negotiation, which is why the flaw can be exploited by an unauthenticated attacker. Since this is the same memory space where OpenSSL also stores the server’s private key material, an attacker can potentially obtain (a) long-term server private keys, (b) TLS session keys, (c) confidential data like passwords, (d) session ticket keys. It is very likely that it is possible in at least some cases, but it hasn’t been demonstrated to work all the time.There likely difference on what software is run on server. There is even a Heartbleed Challenge to steal the keys from server running vulnerable OpenSSL version.
The problem in the OpenSSL library is fairly simple: there’s a tiny vulnerability — a simple missing bounds check — in the code that handles TLS ‘heartbeat’ messages. By abusing this mechanism, an attacker can request that a running TLS server hand over a relatively large slice (up to 64KB) of its private memory space. But in this case a this tiny problem cause a massive problem, because the software was very widely used and details if the flaw became available widely before most parties had any possibility to fix the issue. Though security vulnerabilities come and go, this one is deemed catastrophic because it’s at the core of SSL.
Bruce Schneier speculates that someone could have intentionally added the Heartbleed bug to OpenSSL, but it’s more likely the case that it got in there by accident. Man who introduced serious ‘Heartbleed’ security flaw denies he inserted it deliberately. And that is quite believable I think. The original bug was introduced in this Git commit. The bug was quite dull. The fix is equally simple. Just add a bounds check. This has been done in the version 1.0.1g. How did this get through? Coding mistakes happen and they are not often detected on code reviews. It happens all the time no matter if you do open source or commercial software. Very many skilled must have looked at the code (this is very widely used open source software so code so many people must have looked at it more or less) can’t find all the bugs . This was a simple C coding bug, but yet it took more than two years to find. Bug was introduced to OpenSSL in December 2011 (submitted just before midnight on New Years Eve) and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.
The small team of OpenSSL developers have had a pretty amazing record of maintaining the world’s most popular TLS library before this. Maintaining OpenSSL is a hard job with essentially no pay, so maybe the companies using OpenSSL tool should contribute financially to its development, maintenance, and evaluation to avoid potential future fiasco! Should there be better bug finding tools or different process? I don’t know the answer to this, but there is no silver bullet to guarantee that this kind of bugs don’t appear in the future here or in some other software. One comment to Attack of the week: OpenSSL Heartbleed article claims hat there seems to be a general problem with open source and crypto: The incentives and rewards for finding and using exploits are much higher than those for finding and publishing exploits. A security researcher revealing bug to developers gets a pat on the shoulder, well done, thanks.
I end my too long security article here…
96 Comments
Tomi Engdahl says:
How to Prevent the next Heartbleed
http://www.dwheeler.com/essays/heartbleed.html
This paper discusses specific tools and techniques that could counter Heartbleed and vulnerabilities like it. I will first briefly examine why many tools and techniques did not find it, since it’s important to understand why many previous techniques didn’t work. I will also briefly cover preconditions, impact reduction, applying these approaches, and conclusions.
Tomi Engdahl says:
Free Can Make You Bleed: the Underresourced Open Source
http://it.slashdot.org/story/14/05/03/0129250/free-can-make-you-bleed-the-underresourced-open-source
“After the Heartbleed fiasco, John Walsh brings attention to the lack of proper manpower and funding to run various open source projects.”
Free Can Make You Bleed
http://www.ssh.com/blog/makesyoubleed
By now anyone concernedwith internet security has heard about the Heartbleed security vulnerability in OpenSSL. What you may not be aware of is how much money and personal information is riding on this “free” security program and others like it (OpenSSH). Free is not usually a bad thing, but it can be when it causes the software your business depends on to be under resourced.
What you might not be aware of is just how under staffed and underfunded some of these “free” open source programs like OpenSSL and OpenSSH (OpenBSD) are. OpenSSL for example is largely staffed by one fulltime developer and a number of part-time volunteer developers. The total labor pool for OpenSSL maybe adds up to two fulltime developers. Think about it, OpenSSL only has two people to write, maintain, test, and review 500,000 lines of business critical code. Half of these developers have other things to do.
OpenSSH, part of the OpenBSD project, isn’t any better off.
It is ridiculous when you think about all of the business capital that depends on such grossly underfunded applications. OpenSSL has never received more than a million dollar yearly budget and OpenSSH can’t pay its electric bill. The OpenSSL foundation’s president, Steve Marquess, said “The mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often.”
When your business critical information is stolen the price of open source products might be free, but the cost could be much higher. There are places to cut costs, but your business security is not one of them.
Tomi Engdahl says:
There are several approaches that could have found Heartbleed, and vulnerabilities like it, before the vulnerable software was released. This is not a ding on the OpenSSL developers; they appear to have worked hard to reduce the number of vulnerabilities, including multi-person review and the use of various tools. Instead, this is an effort to help identify what could be better, so that OpenSSL and other important projects can prevent future similar vulnerabilities.
Source: http://www.dwheeler.com/essays/heartbleed.html
Tomi Engdahl says:
Report on Heartbleed in Finnish:
OpenSSL Heartbleed-haavoittuvuus
https://www.cert.fi/attachments/certtiedostot/ptI5thaom/OpenSSL_Heartbleed_-haavoittuvuuden_raportti.pdf
Tomi Engdahl says:
Heartbleed And The Internet Of Things
http://semiengineering.com/heartbleed-and-the-internet-of-things/
If you think Internet security is complicated, just wait until the IoT gets rolling.
Heartbleed is not a country and western song, but many wish it were. It’s a programming glitch with the potential to cause disastrous and widespread compromises on seemingly secure data.
It simply exploits a somewhat overlooked programming mistake in the “heartbleed” part of certain versions of OpenSSL.
In this case the code vulnerability allows anyone on the Internet to read the memory of the systems running vulnerable versions of the OpenSSL software. The fix, according to Dmitry Bestuzhev, head of the research center, Kaspersky Lab Latin America, is quite simple and is included in the OpenSSL 1.0.1g version.
Extrapolating this to future intelligent objects, which will use the same Internet protocols and platform as today’s hardware, means the same vulnerabilities will exist for them as well. Because the IoT will be have orders of magnitude more objects and vastly varying levels of intelligence, coding mistakes that allow access to memory locations and permit alteration of read/write memory locations code are particularly dangerous.
OpenSSL is an enormously popular method of keeping personal information private on the Internet. Millions, of Web sites use OpenSSL to protect your username, password, credit card information, and other private data. However, tests have shown one can access this data completely anonymously with no sign it was ever accessed. Somewhere along the line that should have been a wakeup call, but obviously, it just slipped by, under the radar, until it was exploited.
While the general concept is that unused computer memory is empty. In reality it generally isn’t.
it may just be garbage. In other cases it might be the previous user’s data, including things like passwords or credit card data.
Therefore, by extrapolation, these and similar types of flaws can be passed to IoT object coding as well. To avert this, and, as the Internet evolves, the next generation of internet objects will have to have both much tighter coding awareness and higher level of autonomous firewalls.
The main difference between objects on the Internet of information vs. the Internet of things is that most objects today are human-interactive devices. Managing them, in whatever fashion, is done via human control – some is constant, some is periodic, but the point is that today, most devices are monitored by humans, most of the time. We make them do what we want, and if there is a security breach, we deal with it with human intelligence.
The Internet of things is envisioned as a network of interconnected objects. Everything from office supplies to private jets will have an online presence. Some will simply report and respond on small cell networks (picocells in the home, for example). Others will have complex, two-way reciprocal communications via the Internet.
With this extremely wide girth of objects and their same wide girth of applications, managing the security of them will present what seems like almost an insurmountable plateau of challenges.
He goes on to say that “all code, even open source, must be audited.”
“Sometimes the cost of an attack may be relatively very low, yet the impact very high, such as in heartbleed.” Even though the end-point are the weakest stage, one has to address all of the layers that have the potential to be exploited, and data compromised – on any platform,”
Tomi Engdahl says:
Cisco experts dish on ‘Heartbleed’ IP security vulnerability
http://www.cablinginstall.com/articles/2014/04/cisco-heartbleed-security-note.html
Tomi Engdahl says:
Silly sysadmins ADDING Heartbleed to servers
‘Heartbroken’ admins add to problem of myriad unpatched boxen
By Darren Pauli, 9 May 2014
http://www.theregister.co.uk/2014/05/09/unpatched_failboxes_see_thousands_join_heartbleed_club/
At least 2500 website administrators have made their previously secure sites vulnerable to Heartbleed more than a month after the bug sent the world into a hacker-fearing frenzy.
Opera Software developer Yngve Pettersen discovered the bungle while probing for Heartbleed vulnerable systems in the weeks after the bug was disclosed on April 7.
“It is difficult to definitely say why this problem developed, but one possibility is that all the media attention led concerned system administrators into believing their system was unsecure [which] combined with administrative pressure and a need to ‘do something’ led them to upgrade an unaffected server to a newer but still buggy version … not yet officially patched,” he said, dubbing the new fail boxes “Heartbroken”.
Affected admins may suffer further heartbreak by footing bills for patching servers, updating certificates and hours of testing.
Petterson also found that two thirds of certificates currently in use on now patched servers still carried Heartbleed-soiled certificates that would place users of those sites at risk of compromise.
In separate research, Rob Graham of Errata Security also found about half of vulnerable servers identified after the Heartbleed disclosure were still exposed.
Tomi Engdahl says:
One Month Later: 300,000 Servers Remain Vulnerable To Heartbleed
http://it.slashdot.org/story/14/05/09/1240238/one-month-later-300000-servers-remain-vulnerable-to-heartbleed
“The Heartbleed Bug cause widespread panic from internet users around the world worried their sensitive information was being targeted. While system administrators were warned to patch their systems, a security researcher notes that 300,000 servers remain vulnerable to the heartbleed flaw a full month later. He said, ‘Last month, I found 1-million systems supporting the “heartbeat” feature (with one third patched). This time, I found 1.5-million systems supporting the “heartbeat” feature, with all but the 300k patched.”
Tomi Engdahl says:
Over 300,000 systems are still leaky due to Heartbleed
Yeah, still
http://www.theinquirer.net/inquirer/news/2344052/over-300-000-systems-are-still-leaky-due-to-heartbleed
WEEKS AFTER the worst thing to happen to the internet since selfies, and web servers are still suffering from the fallout of the Heartbleed vulnerability.
Heartbleed shook the industry like a bear might a salmon. It caused most companies to come forward and issue alerts and patches. Some laggard servers remain though, and according to security research over 300,000 are still vulnerable to exploitation.
“It’s been a month since the Heartbleed bug was announced, so I thought I’d rescan the internet (port 443) to see how many systems remain vulnerable. Whereas my previous scan a month ago found 600,000 vulnerable systems, today’s scan found roughly 300,000 thousand systems (318,239 to be precise),” he said.
“The numbers are a little strange. Last month, I found 28 million systems supporting SSL, but this month I found only 22 million. I suspect the reason is that this time, people detected my Heartbleed ‘attacks’ and automatically firewalled me before the scan completed.”
He suspects that some vulnerabilities persist because of errors during the clean-up process, saying that repeated efforts to tackle Heartbleed could have had the opposite effect.
“Last month, I found [one] million systems supporting the “heartbeat” feature (with one third patched). This time, I found 1.5 million systems supporting the “heartbeat” feature, with all but the [300,000] patched,” he added.
Tomi Engdahl says:
The open source criticism was heavily criticized – ‘ Closed- code gap would not be noticed perhaps ever, ”
Mysql database developer and open source as a defender Michael Widenius well-known , better- known nicknamed Monty does not accept openssl security hole because of the open -source security criticism.
“If this would have been a closed-source , the aperture could not be found , perhaps never. Defect was found just because the code is open ,” explains Monty .
He says that we do not even know how the errors have been closed in the code and hacker use.
” Quite a few commercial program investigates the development of open-source applications, security. Such is not the case closed with the code . ”
Monty , the tests have shown that the code is open from 20 to 30 per cent less bugs , or bugs as a closed code.
” Bug was only there for a couple of months . Problem is that not all upgrade their systems. ”
The vulnerability was HeartBug property of openssl versions of 1.0.1 , 1.0.1f , and fixed in version 1.0.1g .
“Open source is usually so good that programs need to be updated frequently. ”
Monty says that the open application code is seen always at least two people, and usually a lot more later checked it out .
” Closed- code from an external inspection there are no guarantees . ”
Monty admits that in many systems the problem is that driving is up to ten years old buggy programs .
He says that many of the open source project would benefit from more funding to the development community to do what it is supposed to do. Today, for example, well-known Linux distributions are well supported, but smaller projects are more difficult position .
Vulnerability discovery, openssl encryption application has become the new financial backers . The biggest contributor so far has been Nokia’s NSN network unit , which donated the development of 72 000 euros
Source: http://www.tietoviikko.fi/uutisia/avoimen+lahdekoodin+kritiikki+tyrmattiin++quotsuljetun+koodin+aukkoa+ei+olisi+huomattu+ehka+koskaanquot/a988403
Tomi Engdahl says:
OpenSSL to get a security audit and two full-time developers
$5.4M plan to help open source funds OpenSSL, OpenSSH, and Network Time Protocol.
http://arstechnica.com/information-technology/2014/05/openssl-to-get-a-security-audit-and-two-full-time-developers/
A Linux Foundation project inspired by the Heartbleed security flaw announced that it will fund a security audit for the OpenSSL code base and the salaries of two full-time developers.
The Heartbleed flaw shone a spotlight on how poorly funded the OpenSSL cryptographic software library is despite being used by many of the world’s richest technology companies. The Linux Foundation, with support from those tech companies, created the Core Infrastructure Initiative (CII) to boost the security of OpenSSL and other open source projects in need of help.
Tomi Engdahl says:
Heartbleed maliciously exploited to hack network with multifactor authentication
In-the-wild VPN attack using Heartbleed underscores real-world threat of bug.
b Apr 18 2014
http://arstechnica.com/security/2014/04/heartbleed-exploited-to-hack-network-with-multifactor-authentication/
Demonstrating yet another way the catastrophic Heartbleed vulnerability threatens users, malicious hackers were able to exploit the bug to successfully bypass multifactor authentication and fraud detection on an organization’s virtual private network (VPN), security researchers said.
On Friday, researchers with network security firm Mandiant said Heartbleed had been used to subvert a customer’s VPN concentrator, an appliance that typically provides a secure way for people to access a network from outside the organization. The devices frequently require multiple forms of authentication before granting access to an end user. Passwords, previously set authentication cookies, and other types of security tokens are frequently used. That’s where Heartbleed came in handy for the hackers, who went to work exploiting the bug less than a day after it became public knowledge. A separate researcher theorized such an attack was possible the same day.
Instead of probing the client’s VPN for passwords or encryption keys, the attackers looked for session tokens set by the targeted concentrator, which relied on a vulnerable version of OpenSSL.
The Mandiant blog post further underscores a point security experts have repeatedly stated in the past week and a half—OpenSSL is so deeply entrenched in Web, e-mail, networking, and end-user software and firmware that there’s no telling how many different ways blackhats can exploit it against otherwise secure networks.
Tomi Engdahl says:
Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL
IBM, Intel, Microsoft, Facebook, Google, and others pledge millions to open source.
http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/
Tomi Engdahl says:
Your devices Heartbleeding – again
Access points, Android devices fall to Cupid’s arrow
http://www.theregister.co.uk/2014/06/02/your_devices_heartbleeding_again/
Heartbleed is still offering rich pickings for security researchers, and presumably hackers, with Luis Grangeia of Sysvalue demonstrating attacks against wireless (and some wired) networking infrastructure using libraries linked to vulnerable OpenSSL versions.
The Lisbon-based researcher has demonstrated that this affects wireless infrastructure, some Android devices, Radius servers, and possibly reaching as far as iOS, OS X, and VoIP phones.
The basis of the “Cupid” attack tool demonstrated by Grangeia in this slideshow is that the popular EAP-PEAP, EAP-TTLS and EAP-TLS authentication protocols might (depending on the underlying implementation) use the vulnerable version of OpenSSL.
As Grangeia notes: “All these use a TLS tunnel over EAP to secure some part of the authentication process”.
Tomi Engdahl says:
Heartbleed removal scam spies on everything you do
http://www.expertreviews.co.uk/general/1308862/heartbleed-removal-scam-spies-on-everything-you-do
A new scam claiming to be a “removal tool” for the Heartbleed web security vulnerability is targeting unwitting computer users and could steal passwords and online banking details.
The spam email campaign is the latest in a long line attempting to take advantage of major news events, although it is unlikely to fool all but the most gullible of computer users.
The email warns that while users may have changed their passwords in the wake of Heartbleed their computer could still be “infected” with the a bug.
The bogus claim then explains that a Heartbleed bug removal tool, attached to the email, can “clean” the infection from the computer.
According to security firm Symantec the email has the subject line “Looking for Investment Opportunities in Syria”, although the content of the email is about the Heartbleed vulnerability.
Tomi Engdahl says:
GnuTLS Flaw Leaves Many Linux Users Open To Attacks
http://linux.slashdot.org/story/14/06/03/1829251/gnutls-flaw-leaves-many-linux-users-open-to-attacks
A new flaw has been discovered in the GnuTLS cryptographic library that ships with several popular Linux distributions and hundreds of software implementations. According to the bug report, “A malicious server could use this flaw to send an excessively long session id value and trigger a buffer overflow in a connecting TLS/SSL client using GnuTLS, causing it to crash or, possibly, execute arbitrary code.”
Critical new bug in crypto library leaves Linux, apps open to drive-by attacks
Vulnerability in GnuTLS allows malicious sites to execute malicious code.
http://arstechnica.com/security/2014/06/critical-new-bug-in-crypto-library-leaves-linux-apps-open-to-drive-by-attacks/
A recently discovered bug in the GnuTLS cryptographic code library puts users of Linux and hundreds of other open source packages at risk of surreptitious malware attacks until they incorporate a fix developers quietly pushed out late last week.
Maliciously configured servers can exploit the bug by sending malformed data to devices as they establish encrypted HTTPS connections. Devices that rely on an unpatched version of GnuTLS can then be remotely hijacked by malicious code of the attacker’s choosing, security researchers who examined the fix warned. The bug wasn’t patched until Friday, with the release of GnuTLS versions 3.1.25, 3.2.15, and 3.3.4. While the patch has been available for three days, it will protect people only when the GnuTLS-dependent software they use has incorporated it.
“A flaw was found in the way GnuTLS parsed session IDs from ServerHello messages of the TLS/SSL handshake,”
Technical Analysis Of The GnuTLS Hello Vulnerability
2014-06-01
http://radare.today/technical-analysis-of-the-gnutls-hello-vulnerability/
Tomi Engdahl says:
Thanks for nothing OpenSSL, cries stonewalled De Raadt
BSD grumpy it isn’t in the cool kids infosec club
http://www.theregister.co.uk/2014/06/06/thanks_for_nothing_openssl_cries_stonewalled_de_raadt/
OpenBSD founder Theo De Raadt said OpenSSL maintainers appeared to have intentionally not informed it about dangerous vulnerabilities found in the platform and patched today.
The apparent feud stems from the April break away LibreSSL which was forked after developers found the OpenSSL code base to be unacceptably insecure in the wake of the Heartbleed vulnerability.
From an ethical standpoint, developers did not need to inform those dependent on vulnerable code of any bugs found ahead of public disclosure but must inform all critical players if they chose to do so and not “specifically exclude a part of the community”, he said.
His statements were met with some criticism centered on the original decision to fork OpenSSL rather than working with developers to improve its security.
The LibreSSL project aimed to substaintially rewrite the OpenSSL codebase. Thousands of lines of “unneeded” code were deleted while individual source files were rewritten in kernel normal form used by BSD operating systems.
Tomi Engdahl says:
Latest OpenSSL bug ‘may be more dangerous than Heartbleed’
http://www.theguardian.com/technology/2014/jun/06/heartbleed-openssl-bug-security-vulnerabilities
Researcher claims that newly uncovered weakness could be used to directly spy on people’s communications
More critical weaknesses have been uncovered in the OpenSSL web encryption standard, just two months after the disclosure of the notorious Heartbleed vulnerability affecting the same technology.
Tatsuya Hayashi, the researcher who found one of the critical bugs, told the Guardian that the latest flaw “may be more dangerous than Heartbleed” as it could be used to directly spy on people’s communications.
The latest vulnerability was introduced in 1998 and has been missed by both paid and volunteer developers working on the open-source project for 16 years.
Meanwhile, one of the other severe vulnerabilities in OpenSSL detailed this week was introduced by the same man responsible for the Heartbleed flaw, researchers said.
Using the vulnerability found by Hayashi, attackers sitting on the same network as a target, such as on the same public Wi-Fi network, could force weak encryption keys on connections between victims’ PCs and web servers.
With knowledge of those keys, the attacker could intercept data.
“Under the public Wi-Fi network situations, attackers can very easily eavesdrop and make falsifications on encrypted communications,” Hayashi added. “Victims cannot detect any trace of the attacks.”
The vulnerability affects all PC and mobile software using OpenSSL prior to the latest version, believed to include the Chrome browser on Android phones, and servers running OpenSSL 1.0.1 and the beta version for 1.0.2.
Tomi Engdahl says:
Internet fends off Heartbleed 2.0
http://www.bostonglobe.com/business/2014/06/05/internet-fends-off-heartbleed/rjnF4Wbi4RLUt3P9Mds9yN/story.html
Just weeks after cyber-security and other Internet organizations patched a vital piece of software to repair the Heartbleed security bug, another major flaw has turned up in the same program.
The new bug, discovered by a researcher in Japan, compromises the security of software called OpenSSL.
“Anybody on the planet who has OpenSSL on its systems has to update,” said Nick Percoco, vice president of strategic services at Boston-based Internet security firm Rapid7 LLC.
But Percoco added that the new bug isn’t as dangerous as Heartbleed, which made it relatively easy to extract private information, such as bank account numbers, from millions of computer servers. “I don’t think it’s at that level right now,” said Percoco. “It’s not as easy to exploit.”
The new bug may have been discovered because OpenSSL has come under intense scrutiny since Heartbleed was discovered in April.
Many supporters of open-source software say it should be more secure than traditional commercial software from companies such as Microsoft Corp., because the inner workings of the software are accessible to anybody. This means any knowledgeable person can scour the program looking for bugs and fixing them.
But Percoco said it doesn’t always work that way. “The assumption that open-source code is more secure than closed-source code is really rather false,” he said, because few open-source programs are actually inspected for bugs.
Tomi Engdahl says:
Patch NOW: Six new bugs found in OpenSSL – including spying hole
On a scale of 1 to Heartbleed, this is a 7
http://www.theregister.co.uk/2014/06/05/openssl_bug_batch/
The OpenSSL team has pushed out fixes for six security vulnerabilities in the widely used crypto library.
These holes include a flaw that enables man-in-the-middle (MITM) eavesdropping on encrypted connections, and another that allows miscreants to drop malware on at-risk systems.
The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.
“None the less, all OpenSSL users should be updating.”
“This attack is also passive in nature and will may not be detected by the client, server or network-based security controls.”
Prof Green added that unearthing multiple bugs in OpenSSL was essentially a welcome development, even though it may cause some unscheduled overtime for sysadmins in the short term.
“The sudden proliferation of OpenSSL bugs is to be expected and a good thing.”
Tomi Engdahl says:
GnuTLS Patches Critical Remote Code Execution Bug
http://threatpost.com/gnutls-patches-critical-remote-code-execution-bug/106430
GnuTLS, an open source cryptographic library, was a headliner in March because of a critical certificate verification vulnerability that some erroneously put in the same class as Apple’s infamous gotofail bug.
The library, used in a number of Linux distributions including Red Hat, Debian and Ubuntu, is back in the spotlight today after it was revealed that a critical vulnerability was recently patched.
“A flaw was found in the way GnuTLS parsed session IDs from Server Hello packets of the TLS/SSL handshake,” said Tomas Hoger in an advisory posted by Red Hat yesterday. “A malicious server could use this flaw to send an excessively long session ID value and trigger a buffer overflow in a connecting TLS/SSL client using GnuTLS, causing it to crash or, possibly, execute arbitrary code.”
Tomi Engdahl says:
New OpenSSL MITM Flaw Affects All Clients, Some Server Versions
http://threatpost.com/new-openssl-mitm-flaw-affects-all-clients-some-server-versions/106470
There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers.
Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.
“The biggest reason why the bug hasn’t been found for over 16 years is that code reviews were insufficient, especially from experts who had experiences with TLS/SSL implementation. If the reviewers had enough experiences, they should have been verified OpenSSL code in the same way they do their own code. They could have detected the problem,” Kikuchi said in his explanation of the vulnerability and how he discovered it.
“Fuzzing may have worked. However, as the history (see below) shows, knowledge of TLS/SSL implementation seems vital.”
Tomi Engdahl says:
OnePlus One debut stymied by Open SSL bug
http://www.techtimes.com/articles/8332/20140611/oneplus-one-debut-stymied-open-ssl-bug.htm
The Open SSL bug, which some believe could be as worrisome as the Heartbleed Bug, has forced OnePlus to delay the launch of their OnePlus One CyanogenMod-based handset. The reports come even as customers who made pre-purchases of the device were told that they would be shipping in mid to late May. Now in mid-June, no devices have been launched.
Those customers were sent emails from OnePlus over why the smartphone had yet to be shipped, with the company worried about the Open SSL bug hampering the phones functionality and success if the company were to ship the devices immediately.
While most observers argue that the Open SSL bug is not to see the overall concerns that the Heartbleed Bug had on the tech world, as this one doesn’t appear to be as widespread or as invasive as the Heartbleed bug, but it has forced a number of companies to look twice at their software before delivering it to the public.
The Open SSL bug has reportedly been in the coding for 15 years before it was discovered in May.
Tomi Engdahl says:
Google unveils independent “fork” of OpenSSL called “BoringSSL”
Stripped down package means there will be three independent versions of OpenSSL.
http://arstechnica.com/security/2014/06/google-unveils-independent-fork-of-openssl-called-boringssl/
Google is releasing its own independently developed “fork” of OpenSSL, the widely used cryptography library that came to international attention following the Heartbleed vulnerability that threatened hundreds of thousands of websites with catastrophic attacks.
Tomi Engdahl says:
Android 4.4.4 fixes OpenSSL hijacking vulnerability
http://www.pcworld.com/article/2366040/android-444-fixes-openssl-connection-hijacking-flaw.html
Less than three weeks after pushing Android 4.4.3 to users of its Nexus devices, Google released a new version of the OS that incorporates a patch for a serious vulnerability identified in the OpenSSL cryptographic library.
Android 4.4.4 factory images using build version KTU84P were released for Nexus 4, 5, 7 and 10 late Thursday.
According to a recent scan by security vendor Qualys, around 14 percent of the Internet’s most popular 155,000 SSL-enabled websites are vulnerable to possible attacks exploiting CVE-2014-0224.
Tomi Engdahl says:
300k vulnerable to Heartbleed two months later
http://blog.erratasec.com/2014/06/300k-vulnerable-to-heartbleed-two.html#.U6fcs7GHjps
Tomi Engdahl says:
Heartbleed-based BYOD hack pwns insurance giant Aviva’s iPhones
Slabs and mobes moved to BB10 service… yes, you read that right
http://www.theregister.co.uk/2014/06/23/aviva_heartbleed_hack/
Mobile device management systems at insurance giant Aviva UK were last month hit by an attack based on the Heartbleed exploit that allowed hackers to royally screw with workers’ iPhones.
Aviva was using BYOD service MobileIron to mange more than 1,000 smart devices such as iPhones and iPads. On the evening of the 20 May, a hacker compromised the MobileIron admin server and posted a message to those handhelds and the email accounts, according to our source.
The hacker then performed a full wipe of every device and subsequently took out out the MobileIron server itself.
In a statement sent to us, Aviva downplayed the impact of the breach, and moved to reassure clients that customer data was not exposed
Aviva reportedly moved impacted staff onto a new Blackberry 10 service to manage all their Apple devices, and are in discussions with MobileIron reseller Esselar to cancel their contract.
Tomi Engdahl says:
‘I don’t want to go on the cart’ … OpenSSL revived with survival roadmap
Heartbleed-battered crypto library reveals long path back to health
http://www.theregister.co.uk/2014/07/01/openssl_roadmap/
The OpenSSL project, having suffered sharp criticism following the revelation of a string of serious security vulnerabilities, has published a roadmap explaining how it plans to address users’ concerns.
“The OpenSSL project is increasingly perceived as slow-moving and insular,” the intro to the document states. “This roadmap will attempt to address this by setting out some objectives for improvement, along with defined timescales.”
The document begins by identifying a number of known issues with the project, including problems both with processes and with the code itself.
Essentially, the OpenSSL team admits that its current source code tree is a mess. It’s a complex project, but it lacks a consistent coding style and there are no formal processes in place for code review. As a result, its code has grown cluttered and difficult to maintain. Worse, the documentation is described as “patchy at best” and some of it is inaccurate.
It doesn’t help that so far the development team has lacked a long-term game plan.
None of this should come as a surprise to anyone who has been following the fallout from the Heartbleed vulnerability scandal.
The LibreSSL project is ongoing, but OpenSSL may have more resources to throw at a clean-up effort
OpenSSL developers say they are, in fact, evaluating new features – among them IPv6 support
Tomi Engdahl says:
OpenSSL receives nine post-Heartbleed critical bug fixes
The CII coding boys are earning their keep
http://www.theinquirer.net/inquirer/news/2359336/openssl-receives-nine-post-heartbleed-critical-bug-fixes
OPENSSL, the web security layer at the centre of the Heartbleed vulnerability, has been updated with a further nine critical patches.
While none of the flaws are as serious as Heartbleed, patching is recommended for all users according to an advisory released today. The vulnerabilities were found by various security research teams around the web including Google, Logmein and Codenomicom, based on their reports during June and July.
Tomi Engdahl says:
OpenSSL Security Advisory [6 Aug 2014]
https://www.openssl.org/news/secadv_20140806.txt
Tomi Engdahl says:
Tue August 19, 2014
CHS Hacked via Heartbleed Vulnerability
http://www.trustedsec.com/august-2014/chs-hacked-heartbleed-exclusive-trustedsec/
As many of you may have already been aware, a breach at Community Health Systems (CHS) affecting an estimated 4.5 million patients was recently revealed. TrustedSec obtained the first details on how the breach occured and new information relating to this breach. The initial attack vector was through the infamous OpenSSL “heartbleed” vulnerability which led to the compromise of the information.
This confirmation of the initial attack vector was obtained from a trusted and anonymous source close to the CHS investigation. Attackers were able to glean user credentials from memory on a CHS Juniper device via the heartbleed vulnerability (which was vulnerable at the time) and use them to login via a VPN.
From here, the attackers were able to further their access into CHS by working their way through the network
Tomi Engdahl says:
OpenSSL promises devs advance notice of future bugs, slaps if they blab
Future Heartbleeds without the heartache
http://www.theregister.co.uk/2014/09/10/openssl_to_open_up_about_bugs/
In the wake of Heartbleed, the OpenSSL project has decided that *nix distributions that use the popular crypto pack will get advance notice of upcoming security-related bugfixes.
The project has decided that distributions that ship with OpenSSL will get some advance notice of issues ahead of fixes – an announcement on the openssl-announce list but not details of specific issues.
“OpenSSL embargoes should be measured in days and weeks, not months or years”,
Tomi Engdahl says:
The Matter of Heartbleed
https://jhalderm.com/pub/papers/heartbleed-imc14.pdf
The Heartbleed vulnerability took the Internet by surprise in April
2014. The vulnerability, one of the most consequential since the ad-
vent of the commercial Internet, allowed attackers to remotely read
protected memory from an estimated 24–55% of popular HTTPS
sites
Our investigation of the operator community’s response finds
that within the first 24 hours, all but 5 of the Alexa Top 100 sites
were patched, and within 48 hours, all of the vulnerable hosts in the
top 500 were patched. While popular sites responded quickly, we
observe that patching plateaued after about two weeks, and 3% of
HTTPS sites in the Alexa Top 1 Million remained vulnerable almost
two months after disclosure.
In addition to patching, many sites replaced their TLS certificates
due to the possibility that the private keys could have been leaked
The public disclosure of Heartbleed started on April 7, 2014 at
17:49 UTC with the version 1.0.1g release announcement [
53
], fol-
lowed by the public security advisory [
52
] released at 20:37 UTC;
both announcements were sent to the OpenSSL mailing list. Several
parties knew of the vulnerability in advance, including CloudFlare,
Akamai and Facebook. Red Hat, SuSE, Debian, FreeBSD and ALT
Linux were notified less than 24 hours before the public disclosure
We tested for the Heartbleed bug by modifying ZMap to
send Heartbeat requests with no payload nor padding, and the length
field set to zero
We emphasize that this approach does not exploit the vulnerability
or access any private memory—only random padding is sent back
by the server. While it was later found that Heartbleed scanning
caused HP Integrated Lights-Out (iLO) devices to crash
Google, Akamai, and other sites disabled the Heartbeat Exten-
sion prior to public disclosure.
Heartbleed also affected many embedded systems, including print-
ers, firewalls, VPN endpoints, NAS devices, video conferencing
systems, and security cameras.
Mail Servers.
SMTP, IMAP, and POP3 can use TLS for transport
security via use of a StartTLS directive within a plaintext session
Tor Project.
Tor relays and bridges use OpenSSL to provide
TLS-enabled inter-relay communication
Bitcoin Clients.
Heartbleed affected both Bitcoin clients and
exchanges, and in the most severe case, allowed an attacker to
compromise the accounts on a popular exchange, BTCJam
Android.
Heartbleed only affected Android version 4.1.1
Wireless Networks.
Several variants of the Extended Authenti-
cation Protocol, a commonly used framework for wireless network
authentication, use TLS, including EAP-PEAP, EAP-TLS, and EAP-
TTLS.
In addition to tracking vulnerable servers, we analyzed who was
scanning for the Heartbleed vulnerability by examining network
traffic
HTTPS Administration.
Heartbleed revealed important short-
comings in the public key infrastructure that underlies HTTPS. One
set of problems concerns certificate replacement and revocation
One of the ironies of Heartbleed was that using HTTPS, a protocol
intended to provide security and privacy, introduced vulnerabilities
that were in some cases more dangerous than those of unencrypted
HTTP. However, we emphasize that HTTPS is ultimately the more
secure protocol for a wide variety of threat models. Unfortunately,
only 45% of the Top 1 Million websites support HTTPS, despite
efforts by organizations such as the EFF and Google to push for
global HTTPS deployment
Revocation and Scalability.
Even though only a small fraction
of vulnerable sites revoked their certificates, Heartbleed placed an
unprecedented strain on certificate authorities and revocation infras-
tructure.
Tomi Engdahl says:
Bash bug as big as Heartbleed
By Robert Graham
http://blog.erratasec.com/2014/09/bash-bug-as-big-as-heartbleed.html#.VCPp-xZsUik
Today’s bash bug is as big a deal as Heartbleed. That’s for many reasons
The first reason is that the bug interacts with other software in unexpected ways.
An enormous percentage of software interacts with the shell in some fashion. Thus, we’ll never be able to catalogue all the software out there that is vulnerable to the bash bug. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.
Internet-of-things devices like video cameras are especially vulnerable because a lot of their software is built from web-enabled bash scripts. Thus, not only are they less likely to be patched, they are more likely to expose the vulnerability to the outside world.
Unlike Heartbleed, which only affected a specific version of OpenSSL, this bash bug has been around for a long, long time. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won’t be, is much larger than Heartbleed.
Tomi Engdahl says:
Truly scary SSL 3.0 vuln to be revealed soon: sources
So worrying, no one’s breathing a word until patch is out
http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/
Gird your loins, sysadmins: The Register has learned that news of yet another major security vulnerability – this time in SSL 3.0 – is probably imminent.
Maintainers have kept quiet about the vulnerability in the lead-up to a patch release expected in in the late European evening, or not far from high noon Pacific Time.
Details of the problem are under wraps due to the severity of the vulnerability.
To that end it is unknown what platforms were impacted, but as SSL is very widely used any flaw will require plenty of urgent attention … and probably be unwelcome news to a tech community already reeling from the recent Shellshock vulnerability in Bash and the Heartbleed flaw.
androidborn says:
Pretty! This was an incredibly wonderful article. Thank you for supplying this
information.
Tomi Engdahl says:
OpenVPN plugs DoS hole
VPN providers patch! Everyone else relax.
http://www.theregister.co.uk/2014/12/02/openvpn_critical_denial_of_service_vulnerability/
OpenVPN has patched a denial-of-service vulnerability which authenticated users could trigger by sending malicious packets.
The flaw (CVE-2014-8104) is most hurtful to VPN service providers and was reported by researcher Dragana Damjanovic to OpenVPN last month.
Maintainers said in an advisory issued this morning that the flaw affected versions back to at least 2005 and allowed TLS-authenticated clients to crash the server by sending a too-short control channel packet to the server.
“In other words this vulnerability is denial of service only,” they said.
“An OpenVPN server can be easily crashed using this vulnerability by an authenticated client. However, we are not aware of this exploit being in the wild before we released a fixed version.
A fixed version of OpenVPN (2.3.6) was released 1st Dec 2014 at around 18:00 UTC. The fix was also backported to the OpenVPN 2.2 branch and released in OpenVPN 2.2.3, a source-only release.
Tomi Engdahl says:
OpenSSL audit kicks off for post-Heartbleed strengthening program
We can rebuild him. We have the technology. We can make him better…stronger…faster
http://www.theregister.co.uk/2015/03/10/openssl_audit/
A major audit of the ubiquitous OpenSSL web security protocol is set to commence under a US$1.2 million industry commitment to harden open source technologies.
OpenSSL is first off the rank under the Linux Foundation’s Core Infrastructure Initiative given its popularity and lack of in-depth security review.
“OpenSSL has been reviewed and improved by the academic community, commercial static analyser companies, validation organisations, and individual review over the years but this audit may be the largest effort to review it, and is definitely the most public,” says security outfit Cryptography Services in post announcing their involvement in the audit.
“Serious flaws in OpenSSL cause the whole Internet to upgrade, and in the case of flaws like Heartbleed and EarlyCCS, upgrade in a rush.
“We know that with what may be the highest profile audit conducted on an open source piece of software, the internet is watching.”
The audit organised by the Open Crypto Audit Project will first focus on TLS stacks examining protocol flow, state transitions, high-profile cryptographic algorithms, and memory management, the company says.
It will cover a sufficient amount of the codebase to be a “useful component” in the wider effort to secure OpenSSL.
First results of the audit are expected around July. The audit begins on the back of OpenSSL code reviews completed last month launched engineer Matt Caswell says on the realisation that coding was “very unusual”, “inconsistently applied” and not formally defined.
Tomi Engdahl says:
Heartbleed One Year Later: Has Anything Changed?
http://it.slashdot.org/story/15/04/08/040204/heartbleed-one-year-later-has-anything-changed
It was on April 7, 2014 that the CVE-2014-0160 vulnerability titled “TLS heartbeat read overrun” in OpenSSL was first publicly disclosed — but to many its a bug known simply as Heartbleed.
Qualys’ SSL Pulse claims that only 0.3 percent of sites are still at risk. Whatever the risk is today, the bottom line is that Heartbleed did change the security conversation — but did it change it for the better or the worse?
Heartbleed a Year Later: How the Security Conversation Changed
http://www.eweek.com/security/heartbleed-a-year-later-how-the-security-conversation-changed.html
Extraordinary branding, however, is not why Heartbleed was and still remains a non-trivial security issue. OpenSSL is a widely deployed open-source technology that is used on endpoints, mobile devices and servers. The promise of OpenSSL is that it provides the Secure Sockets Layer/Transport Layer Security (SSL/TLS) cryptographic libraries necessary to secure data transport. The danger of Heartbleed is that the SSL/TLS could be decrypted, leaving users at risk.
Since OpenSSL is open-source, many pundits were quick to criticize the open-source model as being at the core of the Heartbleed vulnerability. In response, the open-source community, led by the Linux Foundation, rallied and launched the Core Critical Infrastructure (CCI) effort. CCI raised $5.5 million in funding from Adobe, Bloomberg, Hewlett-Packard, VMware, Rackspace, NetApp, Microsoft, Intel, IBM, Google, Fujitsu, Facebook, Dell, Amazon and Cisco in an effort to secure open-source infrastructure and development. CCI is now providing some funding to OpenSSL developers to help prevent another Heartbleed.
The OpenSSL project itself has released multiple security updates over the course of the past year
Even with 12 months of time, there is still Heartbleed risk today. In a new report, security vendor Venafi claims that 74 percent of the Global 2000 are still at risk from Heartbleed. Venafi’s numbers, however, are not just about servers being updated with the latest OpenSSL milestone, but also about replacing SSL/TLS certificates.
“It’s akin to saying that even though you’ve had heart bypass surgery to mitigate a clot in an artery, you are still in immediate danger of having a heart attack because you haven’t stopped eating fatty and unhealthy foods,” Alperovitch said at the time.
While Venafi claims that the majority of sites it surveyed are still at risk from Heartbleed, the Qualys-sponsored SSL Pulse site currently reports that only 0.3 percent of sites are currently at risk from Heartbleed.
Tomi Engdahl says:
How Heartbleed could’ve been found
https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html
tl;dr With a reasonably simple fuzzing setup I was able to rediscover the Heartbleed bug. This uses state-of-the-art fuzzing and memory protection technology (american fuzzy lop and Address Sanitizer), but it doesn’t require any prior knowledge about specifics of the Heartbleed bug or the TLS Heartbeat extension. We can learn from this to find similar bugs in the future
Fuzzing is a widely used strategy to find security issues and bugs in software. The basic idea is simple: Give the software lots of inputs with small errors and see what happens. If the software crashes you likely found a bug.
When buffer overflows happen an application doesn’t always crash. Often it will just read (or write if it is a write overflow) to the memory that happens to be there. Whether it crashes depends on a lot of circumstances. Most of the time read overflows won’t crash your application. That’s also the case with Heartbleed.
A better tool for our purpose is Address Sanitizer. David A. Wheeler calls it “nothing short of amazing”, and I want to reiterate that. I think it should be a tool that every C/C++ software developer should know and should use for testing.
Address Sanitizer is part of the C compiler and has been included into the two most common compilers in the free software world, gcc and llvm. To use Address Sanitizer one has to recompile the software with the command line parameter -fsanitize=address . It slows down applications, but only by a relatively small amount. According to their own numbers an application using Address Sanitizer is around 1.8 times slower. This makes it feasible for fuzzing tasks.
Conclusion
You may ask now what the point of all this is. Of course we already know where Heartbleed is, it has been patched, fixes have been deployed and it is mostly history. It’s been analyzed thoroughly.
The question has been asked if Heartbleed could’ve been found by fuzzing. I’m confident to say the answer is yes. One thing I should mention here however: American fuzzy lop was already available back then, but it was barely known. It only received major attention later in 2014, after Michal Zalewski used it to find two variants of the Shellshock bug.
Tomi Engdahl says:
Thought Heartbleed was dead? Nope – hundreds of thousands of things still vulnerable to attack
IoT crawler reveals map of at-risk devices and computers
http://www.theregister.co.uk/2015/09/15/still_200k_iot_heartbleed_vulns/
More than a year after its introduction, the notorious HeartBleed security flaw remains a threat to more than 200,000 internet-connected devices.
This according to Shodan, a search tool that (among other things) seeks out internet-of-things (IoT) connected devices. Founder John Matherly posted a map the company built showing where many of the world’s remaining vulnerable devices lay:
Heartbleed caused a minor panic when it was first uncovered in 2014. The flaw allowed an attacker to exploit weaknesses in the OpenSSL software library to extract passwords and other sensitive information from a targeted device.
Of the 200,000-plus vulnerable devices, 57,272 were housed in the United States. Germany was second with 21,060 Heartbleed-prone devices and China had 11,300. France was fourth with 10,094 followed by the UK with 9,125.
“Clearly, some manufacturers and IT teams have dropped the ball, and failed to update vulnerable systems,” noted security consultant Graham Cluley.
“My bet is that there will always be devices attached to the internet which are vulnerable to Heartbleed.”
Tomi Engdahl says:
Megan Geuss / Ars Technica:
US charges three men with widespread hacking whose targets included JP Morgan
US charges three men with widespread hacking whose targets included JP Morgan
Suspects allegedly used Heartbleed to hack into a global financial institution.
http://arstechnica.com/tech-policy/2015/11/us-charges-three-men-with-widespread-hacking-whose-targets-included-jp-morgan/
On Tuesday federal prosecutors unsealed charges against three men, revealing details of a sprawling criminal enterprise that involved hacking some of the US’ biggest financial institutions as well as the theft of personal information pertaining to 100 million customers. With that information, the men allegedly made off with hundreds of millions of dollars.
Although the indictment does not name the hacked financial institutions directly, Reuters reports that JP Morgan Chase, ETrade, and News Corp. (which owns The Wall Street Journal) have confirmed that they were party to the crimes described by the indictment.
The newly unsealed charges (PDF) accuse Gery Shalon, a 31-year-old Israeli, of masterminding the hacks that resulted in the loss of personal information pertaining to some 100 million customers of US financial institutions
Chief among the allegations is that Shalon and Aaron used their unauthorized access to financial institution networks to artificially manipulate certain US stock prices through a “pump-and-dump” scheme.
US authorities also charged that Shalon and his co-conspirators operated illegal gambling websites, processed payments for criminals selling anything from illegal pharmaceuticals to malware, and operated an illegal US-based Bitcoin exchange that ran afoul of US anti-money laundering laws.
These activities apparently earned the group hundreds of millions of dollars between 2007 and July 2015, “of which Shalon concealed at least $100 million in Swiss and other bank accounts,” the indictment says.
Today’s unsealed indictment also paints an interesting picture of how some of the network intrusions allegedly occurred. The US Attorney General claims that Aaron was a customer of many of the hacked companies, and he gave his login credentials to Shalon and an unnamed co-conspirator who performed analysis of the companies’ networks. Shalon and the co-conspirator later accessed the companies’ networks and placed malware on them to allow them to steal information about customers over a period of months
http://www.justice.gov/usao-sdny/file/792506/download
Tomi Engdahl says:
A top-secret document revealed that UK spy agency GCHQ exploited vulnerabilities in Juniper firewalls. Dated February 2011, it also makes clear that the exploitation went on with the knowledge and apparent cooperation of the NSA. The security vulnerabilities in 13 different models of firewalls made by Juniper Networks were disclosed earlier in December and contained a backdoor disguised to look like debug code.
Source: http://arstechnica.co.uk/business/2015/12/europes-top-tech-news-december-2015/
More: https://theintercept.com/2015/12/23/juniper-firewalls-successfully-targeted-by-nsa-and-gchq/
Tomi Engdahl says:
Mozilla Launches Secure Open Source Fund
http://www.securityweek.com/mozilla-launches-secure-open-source-fund
In an effort to help secure open source software, Mozilla this week announced the creation of Secure Open Source (“SOS”) Fund, which kicks off with an initial $500,000 grant.
The SOS Fund was created to support security auditing, remediation, and verification for open source software projects, in an attempt to prevent major vulnerabilities from slipping into them, as Heartbleed and Shellshock have in the past. According to Mozilla, there hasn’t been adequate support for securing open source software until now, and the new initiative aims at changing that.
The Fund is part of the Mozilla Open Source Support program (MOSS), and the initial $500,000 funding should cover audits of a series of widely-used open source libraries and programs, Mozilla said. However, Mozilla challenges the millions of organizations out there that leverage open source software to join the initiative and provide additional financial support.
“Open source software is used by millions of businesses and thousands of educational and government institutions for critical applications and services. From Google and Microsoft to the United Nations, open source code is now tightly woven into the fabric of the software that powers the world. Indeed, much of the Internet – including the network infrastructure that supports it – runs using open source technologies,” Chris Riley, Head of Public Policy, Mozilla, notes in a blog post.
Tomi Engdahl says:
I Got 99 Problems, But SWEET32 Isn’t One
http://www.securityweek.com/i-got-99-problems-sweet32-isnt-one
Where does SWEET32 rank against other SSL vulnerabilities?
Cryptographic attacks with cute names seem to come around every few months; so far in 2016 we have seen BICYCLE, DROWN, and now SWEET32.
A pair of researchers, Karthikeyan Bhargavan and Gaëtan Leurent with the French national research institute for computer science, published a cryptographic attack against older, 64-bit block ciphers such as triple-DES (3DES) and Blowfish. They called their attack SWEET32 (CVE-2016-2183) as the attack starts to become practical after 2^32 cipher blocks.
The attack’s website explains that the basis for the SWEET32 attack involves the birthday paradox from probability theory.
Let’s see where SWEET32 would land in my ranking system, which is similar to the CVSS methodology in that it focuses on impact and exploitability.
Tomi Engdahl says:
CVE-2016-8610: SSL Death Alert: OpenSSL SSL/TLS SSL3_AL_WARNING undefined alert Remote DoS
http://seclists.org/oss-sec/2016/q4/224
In August, Shi Lei from Gear Team, Qihoo 360 Inc., found a Denial of Service issue in OpenSSL while openssl is handling
“SSL3_AL_WARNING” undefined alerts.
This issue has been assigned with CVE number, CVE-2016-8610, and it was called ‘SSL-Death-Alert’.
We reported this issue to OpenSSL team in early September, and they told us they won’t treat it as a security issue,
but they allowed us to discuss it with whomever we wish.
BTW, the issue has been fixed in the official release on September 22nd.
Security researchers write exploits because they like the
truth.
With further research in this flaw, we found that it could easily cause a DoS to those which use OpenSSL to support
SSL(e.g, Nginx). For instance, visitors couldn’t open the website powered by nginx until the attack stops.
Details about the security flaw:
=======
Product: OpenSSL
Affected Versions: 1.1.0, 1.0.2 – 1.0.2h, All 1.0.1, All 0.9.8
Vulnerability Type: DoS
Vendor URL: https://www.openssl.org/
CVE ID: CVE-2016-8610
Name: SSL Death Alert
It was found that function “ssl3_read_bytes” in ssl/s3_pkt.c might lead to higher CPU usage due to improper handling of
warning packets.
An attacker could repeat the undefined plaintext warning packets of “SSL3_AL_WARNING” during the handshake, which will
easily make to consume 100% CPU on the server. It is an implementation problem in OpenSSL that OpenSSL would ignore
undefined warning, and continue dealing with the remaining data(if exist).
A successful exploitation of this vulnerability could easy cause a DoS attack to the server (such as openssl s_server,
nginx, etc).
OpenSSL SSL3_AL_WARNING undefined alert remote DoS (seclists.org)
https://news.ycombinator.com/item?id=12779082
“All versions (SSL3.0, TLS1.0, TLS1.1, TLS1.2) are affected.” according to http://security.360.cn/cve/CVE-2016-8610/
It would be helpful if the researchers clarified how potent this DoS attack vector is. Is sending “a large number of these large records” more efficient at denying availability than a naive flood using e.g. SYNs or UDP?
so far nginx is the only server which is affected by this issue, but the latest version wasnt affected.
CVE-2016-8610: SSL-Death-Alert
OpenSSL SSL/TLS SSL3_AL_WARNING undefined alert flood remote DoS
http://security.360.cn/cve/CVE-2016-8610/
It was found that function “ssl3_read_bytes” in ssl/s3_pkt.c might lead to higher CPU usage due to improper handling of warning packets.
An attacker could repeat the undefined plaintext warning packets of “SSL3_AL_WARNING” during the handshake, which will cause a 100% CPU usage on the server.
Q. What is the impact of the vulnerability?
A. The vulnerability affects most versions of OpenSSL. Any ssl supported server which used OpenSSL may be influenced. Nginx in particularly could be easily made to deny service.
Q. What versions of OpenSSL are affected?
A. Affected Versions:
OpenSSL All 0.9.8
OpenSSL All 1.0.1
OpenSSL 1.0.2 through 1.0.2h
OpenSSL 1.1.0
Not Affected Versions:
OpenSSL 1.0.2i, 1.0.2j
OpenSSL 1.1.0a, 1.1.0b
Q. How to prevent the attacks?
A. Upgrade to the latest version.
. What protocol versions are affected?
A. All versions (SSL3.0, TLS1.0, TLS1.1, TLS1.2) are affected.
Q. What encryption algorithms are affected?
A. All encryption algorithms are affected. This bug is not related to any specific algorithms.
CVE-2016-8610
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8610