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

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.

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.

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/

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

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.”

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.

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.

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.

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.