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

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

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.

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.

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.

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

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.

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

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.

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

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.

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.

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

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

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

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.

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.

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.

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

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

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

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.

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:

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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

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

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.

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.

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

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

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

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.