RCMP Alleges Juvenile Cyber Thief Exploited Heartbleed


The RCMP alleges that 19 year old security “enthusiast” Stephen Arthuro Solis-Reyes took advantage of the recently disclosed Heartbleed TLS vulnerability to steal 900 social insurance numbers from a government website. The publication The Financial Post made the aforementioned claims in a recent article on their website. I strongly suspect given the large number of individual records collected that another vulnerability – such as a database with a weak or default password or the lack of input sanitation allowing the alleged attacker access to generate his own queries and that the Heartbleed angle has been tacked on erroneously. Others may disagree but I believe the aforementioned attacks are far more likely when all of the information in the public eye is assessed.

SSL Implementations, Code Quality and Common Sense


The far reaching consequences of the Heartbleed vulnerability have been discussed at length in a thread on Bruce Schneier’s blog. In response to a comment on the code quality I wrote the following:

“I nodded in agreement so hard [at another user's comment on OpenSSL code quality] I might have to see a chiropractor.

OpenSSL’s src is a mess. If cyaSSL can mirror its basic functionality and do such a thing with code that is both legible and importantly it is advertized as 20 times smaller than OpenSSL. Of course it is targeted towards the embedded market but I would rather audit a significantly smaller codebase that a lay sysadmin can likely understand than try and analyze the Pandora’s box that is OpenSSL’s source. It really is a disgrace.

Feature creep is a terrible thing. Security critical libraries should focus on their task. At least move redundant or niche usage extensions and other foolery out of the core and disable them unless uncommented in the Makefile at compile time.”

Now, of course I wouldn’t see a chiropractor. All scientific evidence points to the practice as ineffective folk medicine. But I digress. The point of my post is to highlight the (perhaps obvious) fact that as a library grows and more lines of code are written, so too does the potential for a potentially catastrophic bug to occur.

Good programming in the true style of our BSDite forefathers focuses on a few key laws, and these hold true regardless of what you are coding and what language you happen to be coding in. Essentially these boil down to the KISS principle – write good, well commented code and code with grace. What can be done in five lines may be done in one, but only if this does not negatively affect the readability (and thus the ability of others to audit) of your code. Extending upon this, be sure to separate out any unnecessary fluff from your core code. A feature that is used by perhaps one percent of your users should not be compiled in by default, especially in the case of a security critical library. The final tip is to sanity check everything and always distrust information pulled from external sources (i.e. the foreign host).

Of course all of the above is common sense. Unfortunately this has been lacking in many open source projects, and has been an issue ever since Stallman wanted EMACS to be everything including the kitchen sink.

Updated Warrant Canary

Given the reasonably long hiatus I have taken from actively participating in security blogs I felt that an updated warrant canary wouldn’t be such a bad thing. Here goes.

Hash: SHA1

I - the writer of this blog, identified by the pseudonym "Mike The Crypto Goat" and with PGP key ID B7A04065 (current key, 4096R, expires 2015-10-26 and issued to replace 6054D4D2 on 2014-01-04) state, under penalty of perjury, that I am categorically not in the employment of the United States government, nor do I perform any task for the aforementioned entity in any capacity. Furthermore I state that I am not an agent, employee or intelligent asset of any government. As of this day I have not received an order under FISA or any other secret (or otherwise) court and am under no duress as I write this statement to this effect. While I understand that the mentioned law, while abhorrent and unconstitutonal (and thus invalid) can effectively be used to 'gag' the free expression of this individual, I will not and shall not sign such a declaration if any information contained within it is not truthful, or where the information within it may be misleading. I will comply with this even if it ultimately results in the contravention of a court (an illegal and unconstitional one at that) order.

As I write this declaration it is 19:05 UTC on Friday April 11 2014, and the DOW sits at 16,023.93 and the NASDAQ at 3,994.55 with the markets still open. Yesterday's USA Today reported that "The Nasdaq composite index, prone to big drops lately, tumbled 129.79 points, or 3.1%, to 4,054.11. It was the worst point drop since Aug. 18, 2011, when the index dropped 131.05 points." On reuters, the head news story is "A fresh face on Obamacare" with secondary stories "Detroit closer to exiting bankruptcy after swaps deal approval" and the possibly alarmist "U.S. says Hackers trying to use Heartbleed bug."

Version: GnuPG v2.0.21 (FreeBSD)



CloudFlare recently claimed that although serious the Heartbleed bug could not be used to successfully hoover up the site’s private key. They have put up an intentionally vulnerable site, challenging the security community to prove that key theft via this bug is possible.

UPDATE: within a few hours two people had independently stolen the private key. So much for their contention that the threat posed by Heartbleed was overrated.

Developer Responsible For Heartbleed Speaks


German OpenSSL developer Robin Seggelmann spoke openly and was quoted by several newspapers about his commit which ultimately introduced the bug responsible for Heartbleed, essentially accepting responsibility and offering a mea culpa of sorts – no doubt in an attempt to quell the growing concern that this bug was perhaps planted by the NSA.

At the risk of sounding like a conspiracy theorist (and I will remind readers that prior to the Snowden disclosures most would have accused those speaking of the reach of the NSA’s intercept program as being a nut despite evidence of the existence of such a program being widely accepted as early as the Room 512A documents) I will admit that when news of Heartbleed broke I was immediately suspicious. The simplicity of the error and the ease of which it could be dismissed as an innocent mistake are the alleged hallmarks of the work of the agency and this essentially mirrors the style of the 2003 attempt to backdoor the Linux kernel, the only difference being the latter was caught – minimum modification yet maximum damage to the integrity of the software.

When one considers the number of websites using OpenSSL (not to mention embedded devices and appliances – which will likely remain affected while their vendors slowly push out patches) and the duration that a large portion of the internet was vulnerable it is unsurprising that some are asking questions. I would suspect that even if the NSA were not directly responsible that knowledge of the 0day would have been a very valuable thing and given their resources independent discovery is a possibility.

I wish to add a disclaimer that I am not seriously suggesting that Heartbleed was deliberate and the aforementioned developer responsible, but it is interesting to consider that it is likely now an unfortunate reality that in a post Snowden world any future vulnerabilities discovered in any software will be scrutinized and suspicions cast toward shadowy government spooks. I don’t necessarily think this is a bad thing, especially if it results in more eyes auditing the code that so many came to blindly rely on.

Heartbleed SSL Bug Leaves Many Large Corporations Red Faced

The recent disclosure of the so called  heartbleed bug (CVE-2014-0160) left many organizations who should know better red faced as they demonstrate their ineptitude at rapidly patching their machines.

For those who have yet to hear the news, the so called heartbleed bug is a vulnerability in OpenSSL that can potentially cause a leak of key material. This is obviously very bad mojo and the issue is compounded by the fact that OpenSSL is the most popular implementation used for https on the web.

Astute readers of this blog will know I have an issue with OpenSSL, whose author allegedly coded to learn bignum arithmetic. Of course that’s entirely irrelevant and potentially untrue. My real issue with OpenSSL mirrors that of Sun/Oracle’s Java – unnecessary complexity, terse code often with equally indecipherable comments and a huge history of vulnerabilities to boot. I could go on forever but when there are so many other libraries to use as an alternative then I can’t understand why anyone would bother with it. PolarSSL for example is just a mere fraction of the size of OpenSSL and performs admirably. Mozilla’s TLS implementation exists and is reasonable as is GNUTLS.

I could go on, but I have touched on all of this before. If you are unlucky enough to be affected, go ahead and grab the latest tarball of OpenSSL (1.0.1g) which has the issue patched.

The OpenSSL advisory notes that:

“Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley … and Bodo Moeller … for
preparing the fix.” (Redacted email addresses to reduce UCE to those above)

It is excellent that they are correctly attributing those who worked hard to find the bug, and I commend them for their responsible disclosure.

NullCrew Attack On Klas Telecom Reiterates The Dangers of Legacy Installs

Klas Telecom found out the hard way why organizations must remain ever vigilant throughout the entire life cycle of any service when its legacy help desk interface was owned recently. In an announcement on their blog they reiterated that the software was essentially retired, which really makes you question why on earth you’d leave something essentially redundant live and clearly internet accessible. The public shame of being owned isn’t the only consequence – with the company responsible for some government projects – no doubt the problems for Klax have only just begun.