The Weekly Ink #1
Hi, everyone! We're excited to announce a new series on our blog called The Weekly Ink.
The Weekly Ink is a summary of the top security content of the week injected with our own pointed opinions, and will be posted to our blog...well, weekly.
The Weekly Ink started as an internal newsletter at Duo, but we figured it would be worthwhile to share our pseudo-intelligence, attempted humor, and snark with everyone. We hope you agree.
The Weekly Ink is brought to you by Duo Labs, the advanced research team at Duo Security. Keep an eye out for more from Duo Labs in the coming weeks!
-Jon Oberheide, CTO, and the Duo Labs team
This week's installment includes stories submitted by Zach Lanier, Senior Security Researcher; and Adam Goodman, Principal Security Architect.
Heartbleed, Cupid and Wireless
*(Zach)*"Heartbleed": the OpenSSL gift that keeps on giving. It doesn't come as any surprise that the abuse cases for this particular vulnerability extend beyond just websites, seeing as how folks have discovered e-mail and directory servers that are affected. Well, a savvy researcher identified that an OpenSSL-based Extensible Authentication Protocol (EAP) stack -- used for authenticating wired and wireless (WiFi) connections -- is subsequently also affected by Heartbleed. In addition to sharing presentation slides and a follow-up post about their findings, this researcher also released a related software patch for the popular open source "hostapd" and "wpa_supplicant" applications. Dubbed "Cupid", this patch adds an exploit capability to these two programs, allowing users to test their EAP-enabled networks or wireless access points.
True Goodbye:'Using TrueCrypt Is Not Secure'
*(Zach)*Riding hot on the heels of a crowdfunded security audit, the popular disk encryption suite TrueCrypt evidently is no more. With a declaration of "Using TrueCrypt is not secure", an otherwise terse explanation, and a set of instructions for migrating to OS-provided disk encryption mechanisms, the TrueCrypt project has totally ceased development. Brian Krebs, in usual style, assembled bits and pieces of information surrounding the whole debacle, including a timeline of TrueCrypt updates and the legitimacy of the announcement (spoiler: it's real). As a former TrueCrypt user, I was happy to see the audit actually happen, and the glimmer of hope it offered for fixing defects in TrueCrypt, so it's definitely a bit of a let down that the project ended so abruptly and unexpectedly.
House Committee Initiates NIST-NSA Separation on Crypto Standards
*(Zach)*And still more crypto-related stories...Dennis Fisher at Threatpost discusses the recent introduction of an amendment by Rep. Alan Grayson (D-FL) that would eliminate a requirement for collaboration between the National Security Agency and the National Institute of Standards and Technology (NIST). Influence by three-letter-agencies and other organizations has been the subject of much controversy, given NIST's role in development of encryption standards. Like many other revelations, this finally came to a head with the release of a Snowden document detailing the manipulation by the NSA of certain NIST-created algorithms. A choice quote by Rep. Grayson sums things up nicely: “If this amendment passes, standards will still be promulgated at the highest levels of quality by NIST, and the NSA will still be consulted when needed...but subversive actions and overreach by one agency into another will not be tolerated.”
US Cybercrime Laws Being Used to Target Security Researchers
*(Zach)*If you're not familiar with the Computer Fraud and Abuse Act (CFAA), here's the tl;dr - old, ambiguous, easily misused law. Despite all of the progress that's been made with regard to vulnerability disclosure, security testing, and researcher/vendor collaboration, it seems there's still a large-enough contingent of prosecutors and vendors ready and willing to whip out the CFAA that it has a serious chilling effect on security research. This is exacerbated by misunderstandings on the part of lawmakers, judges, and up-and-coming vendors, especially those in the burgeoning Internet-of-Things space. Lack of knowledge about security research, its merits, and what truly constitutes criminal intent only fuel the flames. On a brighter note, however, there are efforts underway to help try and change some of this. With Aaron's Law, which aims to reform the CFAA, and initiatives like BuildItSecure.ly, hopefully there will be some progress made in both decriminalizing security research and educating vendors about how security research works, and how it can help them.
Early ChangeCipherSpec Attack in OpenSSL
*(Adam)*If you were hiding under a rock, you might've missed the Internet blowing up again over a new slew of OpenSSL vulnerabilities. Most of them involved Datagram TLS (DTLS), a variant of the TLS protocol that almost no one uses. (Actually, I have seen one use of DTLS in-the-wild; Microsoft uses it for one of their newfangled RD Gateway transport protocols). OpenSSL's DTLS implementation seems to be particularly fraught with severe bugs; fortunately, they're usually of a form where if you're not using DTLS, you're OK.
However, there was one bug in OpenSSL that did have some pretty bad results for regular old TLS connections, which would enable attackers with privileged access to your network traffic to pull off a successful Man-In-The-Middle attack. As usual, Adam Langley gives us a great explanation of the technical details.
GnuTLS Patches Critical Remote Execution Bug
*(Adam)*OpenSSL wasn't the only SSL library to blow up this week, though; GnuTLS was patched against a much worse vulnerability (of the "remote code execution" variety). GnuTLS isn't used as universally as OpenSSL, but a lot of the FOSS components you find packaged with any major Linux distro do rely on it.
So, why are all these vulnerabilities showing up right now? We can be pretty confident that this is simply a by-product of increased scrutiny following Heartbleed. (In fact, the OpenSSL bug almost certainly would've been a much less-hyped story if Heartbleed hadn't happened - this one is rather bad, but not end-of-the-world bad.) A similar thing happened after 'goto fail' came out - some researchers started grep'ing the GnuTLS codebase and found a fairly similar bug in which the exact line 'goto fail' was involved...
Email Encryption in Transit (from Google's Transparency Report)
*(Adam)*If you login to GMail these days, Google forces you to use HTTPS. This is great - the connection between your browser and the GMail web frontends is encrypted, and - as long as TLS and its various implementations aren't broken (wink) - evil attackers intercepting this traffic can't snoop on all the doge meme gifs you're sending to your friends. However, if you're sending email to a friend using something that's not GMail (say, Yahoo!), then your message will get bounced across the internet over a very old protocol called SMTP. GMail's servers will look up the SMTP servers for yahoo.com (using DNS), open an outgoing SMTP connection, and send the message across. In its basic form, SMTP is a clear-text protocol, but it can (and should!) be run over TLS - otherwise, your email will sent unencrypted over some network, somewhere on the internet! Google is tracking how many other providers are enabling TLS support for their SMTP gateways, which is pretty cool.
Google Online Security Blog: Making End-to-End Encryption Easier to Use
*(Adam)*The previous discussion really underscores why we might want to move toward using "end-to-end" email encryption - i.e. a system in which when you send email to me, the message is encrypted before its contents leave your laptop, and I decrypt it only after it's gotten all the way to local storage on my laptop. If we do this, then the message will remain encrypted across all servers/networks as it is in transit from you to me, even in cases where providers failed to turn on TLS (and even if we did reach 100% adoption of SMTP-over-TLS on the Internet, messages would still get decrypted and re-encrypted at the end of each op, so you'd still have to trust an awful lot of SMTP servers to not be evil!)
We also sometimes refer to ideas like this as "host-proof" services - i.e. if some host running a service turns out to be evil, it still can't compromise your data. There are two schemes that have been around ~forever that make this possible: S/MIME and PGP / GPG. However, one more-recent problem with such schemes for email is that they seem to run in direct conflict with web-based email! Some have speculated that Javascript-based crypto might be the happy middle ground in this conundrum, while other crypto/security nerds have a knee-jerk "considered harmful" reaction to anything involving JS Crypto. These Google folks seem cautiously optimistic that this could indeed be viable (in the form of a browser extension), though, so we'll see!
Peek Inside a Professional Carding Shop
*(Adam)*Brian Krebs wrote a really fascinating article in which he spent quite a lot of time following one of the black-market broker websites for stolen credit card info (particularly from the major retailer breaches we keep hearing about!). It's really interesting to see all the mundanities of how they run their "business", communicate with "customers", handle virtual under-the-table payments (yay bitcoin?), and so on. If you ever wondered what happened to all that data after it got exfiltrated from Target, Michaels, etc., then read this!