{"id":14943,"date":"2014-04-09T18:07:43","date_gmt":"2014-04-09T18:07:43","guid":{"rendered":"http:\/\/kasperskydaily.com\/b2b\/?p=1648"},"modified":"2020-02-26T10:49:03","modified_gmt":"2020-02-26T15:49:03","slug":"the-heartbleed-bug-averting-a-doomsday","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/the-heartbleed-bug-averting-a-doomsday\/14943\/","title":{"rendered":"The Heartbleed Bug: averting a doomsday"},"content":{"rendered":"

As reported yesterday<\/a>, security researchers have found a nasty bug in OpenSSL, which allows reading the memory of systems protected by the vulnerable versions of the OpenSSL software. This effectively makes the privacy mechanisms relying on this implementation of encryption protocols non-existent. It doesn\u2019t mean that there is no encryption at all thoughs. It merely means that whoever knew about the bug in OpenSSL 1.0.1 released in 2012, could have exploited its flaw since then, codenamed \u2018Heartbleed bug<\/a>,<\/span>\u2018 to eavesdrop on any encrypted communication.<\/p>\n

The news has been met with steadily growing panic. On the day after initial exposure, the Heartbleed Bug looks pretty much apocalyptic. But is it really that bad?<\/p>\n

The short answer: Yes. Potentially.<\/p>\n

The longer answer<\/b><\/p>\n

First of all, it is <\/i>really really<\/i> bad. As BBC News put it<\/a>, \u201ca bug in software used by millions of web servers could have exposed anyone visiting sites they hosted to spying and eavesdropping\u2026<\/i>\u201d<\/p>\n

In other words, it looks like one of the biggest information security breaches ever. One of the longest too. For now, nobody can tell how widely the breach has been exploited, but the hole has been open for two years \u2013 OpenSSL 1.0.1 was released in March 2012.<\/p>\n

David Chartier, CEO of Codenomicon security firm, told to Associated Press<\/a>: \u201cI don\u2019t think anyone that had been using this technology is in a position to definitively say they weren\u2019t compromised.<\/i>\u201d<\/p>\n

That\u2019s right. The potential scale of the problem is vast<\/i>. Paradoxically or not, but it may become much worse now, after the flaw has been widely publicized: it\u2019ll surely take time for all of the OpenSSL users to update their systems, which opens a \u2018window of possibilities\u2019 for potential attackers.<\/p>\n

By the way, a list of the proof-of-concept exploits for the Heartbleed Bug is already in place<\/a>. It\u2019s not hard to guess how soon it will take these POCs to turn into working malware.<\/p>\n

In detail<\/b><\/p>\n

OpenSSL<\/b> is an open-source implementation of the TSL (Transport Layer Security) and its predecessor SSL (Secure Socket Layer) protocols. They both use X.509<\/a> standard certificates and hence asymmetric cryptography<\/a>, also known as public-key cryptography: an algorithm which requires two separate keys \u2013 pieces of information or parameters those determine, functional output of a cryptographic algorithm or cipher \u2013 one of which is secret<\/i> (or private<\/i>) and one of which is public<\/i>.<\/p>\n

The key used to encrypt a message is not the same as the key used to decrypt it. Each user has a pair of cryptographic keys \u2013 a public encryption key and a private decryption key. Similarly, a key pair used for digital signatures consists of a private signing key and a public verification key. The public key is widely distributed, while the private key is known only to its proprietor. The keys are related mathematically, but the parameters are chosen so that calculating the public key from a private one is quite easy, while the reverse process is either impossible, i.e. computationally unfeasible or prohibitively expensive.<\/p>\n

Thus the public key may be published without compromising security, whereas the private key must not be revealed to anyone not authorized to read messages or perform digital signatures.<\/p>\n

There is, however, another problem: confidence and proof that a particular public key is authentic, i.e. that it is correct and belongs to the person or entity claimed, and has not been tampered with or replaced by a malicious third party.<\/p>\n

The usual approach to this problem is to use so-called public-key infrastructure<\/a> (PKI), in which one or more trusted third parties \u2013 known as certificate authorities<\/a> \u2013 certify ownership of key pairs. In other words, the certificate authority is responsible for saying \u201cyes, this person is who they say they are, and we, the CA, certify that\u201d. That is, by the way, the exact reason why cybercriminals attempt to compromise CAs all the time: a successful attack allows them to steal valid certificates or a issue false one, which will be recognized as valid (by browsers, for instance).<\/p>\n

Well, with the Heartbleed Bug all the precautions regarding cryptographic keys appear to make little sense. A missing bounds check in the handling of the TLS Heartbeat Extension can be used to reveal up to 64k of memory to a connected client or server. As explained by Codenomicon<\/a>, \u201cThe Heartbleed <\/i>bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.\u201d<\/i><\/p>\n

More to the point, a 64k limit applies only to a single \u2018heartbeat\u2019: an attacker can either keep reconnecting or, during an active TLS connection, keep requesting the arbitrary number of 64 kilobyte chunks of memory content until they get enough of the information required.<\/p>\n

At the time of the Heartbleed\u2019s disclosure, some 17%, or half a million of the Internet\u2019s secure web servers certified by trusted authorities, were believed to have been vulnerable to the attack. At the same time Apache and nginx web server software together hold 66% of shares in the world, and they are both affected by the bug.<\/p>\n

Clearly, it\u2019s a security sinkhole, as large as the Yellowstone Caldera<\/a>, but unlike the natural geological formation, it can be and must be covered by sod promptly. Until then, everyone everywhere is in jeopardy.<\/p>\n

What businesses are recommended to do (ASAP)<\/b><\/p>\n

The first recommendation issued yesterday stated that if one needs secure communications and privacy, it\u2019s time to get off the grid until the dust settles. But this time, dust won\u2019t settle on its own: with the amount of people potentially affected, everyone should make their own moves. First \u2013 update your OpenSSL to 1.0.1g (released on April 7th) wherever it is used: web server software, open source operating systems; then change all<\/i> your passwords. Especially those used to access sensitive data.<\/p>\n

If you are an owner of a web service that uses a vulnerable OpenSSL implementation, there is a reason to go offline just like, according<\/a> to BBC, Mojang did, the maker of the hugely popular Minecraft game. It took all its services down while Amazon, which it used to host games, did the necessary bug-busting. It does mean possible losses and users\u2019 discontent, but then again: if the risks persist and a possible attack is successful, discontent would be much worse.<\/p>\n

Unfortunately, for businesses working with other people\u2019s data it is also imperative to notify users about possible leaks and the immediate need to change passwords.<\/p>\n

The world\u2019s largest news media have already reported on the bug, so public awareness is growing, but people still need to be informed.<\/p>\n

In addition to changing passwords, new digital certificates should be requested from CAs ASAP and new encryption keys should be generated. Without this, simply updating OpenSSL in your servers will do nothing: if attackers have already exploited the vulnerability, they could steal encryption keys, passwords or other credentials required to access a server, so they just can come in and get out with any critical information, without leaving a trace.<\/p>\n

Ladies and gentlemen, have you changed your passwords already?<\/p>\n","protected":false},"excerpt":{"rendered":"

As reported yesterday, security researchers have found a nasty bug in OpenSSL, which allows reading the memory of systems protected by the vulnerable versions of the OpenSSL software. This effectively<\/p>\n","protected":false},"author":209,"featured_media":16223,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3052],"tags":[2081,590,195],"class_list":{"0":"post-14943","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-heartbleed-bug","10":"tag-openssl","11":"tag-security-threat"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/the-heartbleed-bug-averting-a-doomsday\/14943\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/the-heartbleed-bug-averting-a-doomsday\/14943\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/the-heartbleed-bug-averting-a-doomsday\/14943\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/heartbleed-bug\/","name":"Heartbleed Bug"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/14943","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/209"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=14943"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/14943\/revisions"}],"predecessor-version":[{"id":33096,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/14943\/revisions\/33096"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/16223"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=14943"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=14943"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=14943"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}