Dan Greer delivered the following speech at this year's (2014) BlackHat. The video and text are presented below. I have republished the text below but edited from original text format to be a bit more readable and printable.

[ nominal delivery draft, 6 August 2014 ]

Cybersecurity as Realpolitik
Dan Geer

Good morning and thank you for the invitation to speak with you today. The plaintext of this talk has been made available to the organizers. While I will not be taking questions today, you are welcome to contact me later and I will do what I can to reply. For simple clarity, let me repeat the abstract for this talk:

Power exists to be used. Some wish for cyber safety, which they will not get. Others wish for cyber order, which they will not get. Some have the eye to discern cyber policies that are "the least worst thing;" may they fill the vacuum of wishful thinking.

Privacy and security folks rely on encryption as a means to ensure the confidentiality and integrity of information, protecting it at rest and in transit. But what happens when a fundamental control is thoroughly compromised? When a protective control becomes an attack vector? How should we react?

It is critical to note that proof of concept exploit code is already in the wild. This is not a theoretical emergency.

Today, we should be activating Incident Response Plans (or screaming, loudly, with hair on fire) within our organizations to do the following:
  • Identify all external and internal sites using SSL/TLS
    • This could be a website, API interface, e-mail connection, VPN concentrator, etc.
  • Check if they are vulnerable 
    • There are a few sites offering to "check if you're vulnerable" ; however, don't rely on them. They could be actively exploiting you and you wouldn't know it. Keep it in house.
    • Note for above: your client must support 'heartbeat' otherwise you will get false positives.
    • Find one of your system admins and have them conduct a check:
    • The following command (or something similar) can provide quick feedback (replace google.com with the target server)
openssl s_client -connect google.com:443 -tlsextdebug 2>1 | grep 'server extension "heartbeat" (id=15)' || echo safe
  • If the site is not vulnerable, celebrate. You've avoided the heartbleed problem but...
    • Don't celebrate too hard, it likely means you're running a very old OpenSSL version and are vulnerable to many other issues.
  • If the site is vulnerable, do the following:
    • Patching affected systems to OpenSSL 1.0.1g
    • Update any other dependent software/hardware
    • Procure new certificates
    • Revocation of the old keypairs that were just supersceded
    • Changing all passwords
    • nvalidating all session keys and cookies
    • Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly
    • Evaluating any other information that could have been revealed, like memory addresses and security measures
    • Ensure all end-user browsers all check Certificate Revocation Lists, this functionality is generally off by default
Updating certificates will cost you money. However, the risk is that your site has already been compromised before you remediated the risk. If someone has your private key, you're forever compromised until you replace the certificates. Since, as of writing this, you cannot tell if you've been compromised or not, it is much better to err on the side of caution and spend the money replacing your certificates. 

In some cases, hardware based platforms will not have a quick fix for this vulnerability. You should have conversations with your IT, Business, and Security Operations people. Investigate the possibility of unplugging that piece of hardware, depending on how critical it is, until it can be fixed. This is a big decision and trade offs will need to be understood thoroughly. However, the gravity and seriousness of the heartbleed situation should be clearly communicated. This is the fire drill we never really wanted to have.

-------------------------- Background on OpenSSL and vulnerability --------------------------

OpenSSL (wikipedia) is an open-source implementation of the SSL and TLS protocols. The library is supported on multiple OS platforms (Unix, Windows, etc) , multiple connection types (web, email, VPN, XMMP chat, APIs, etc.), and is extensively used. Trust me when I say, it's in your environment. Likely in many places. Specific OpenSSL versions have a vulnerability that can completely compromise all information transmitted over the connection, rendering the protection moot. The vulnerability allows for compromise of the private keys on the server side. The attack, so far, is not detectable. This is very, very, bad.

Questions? Concerns? Comments are welcome below and on twitter @PrivacyWonk.

Security Advisory from OpenSSL - https://www.openssl.org/news/secadv_20140407.txt

OpenSSL Security Advisory [07 Apr 2014]

TLS heartbeat read overrun (CVE-2014-0160)

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.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
Additional Sources:


"We spend our waking hours studying systems of all types. We subvert them. We fix and improve them. We secure them. Do you even wonder why it's then so easy for us to profit from them?" ~@ralphlogan

Adam Shostack (@adamshostack) discusses Threat Modeling on Mozilla Air. Excellent presentation (so far)

Reading up on location based privacy...below are a few articles spanning 7 years that tackle the issues from a few different angles. Brush, Krumm, and Scott's paper is especially interesting as they look specifically at end-user values of location data privacy, what and how they chose to protect that data, and how they share that data.

"It is hardly possible to overrate the value...of placing human beings in contact with persons dissimilar to themselves, and with modes of thought and action unlike those with which they are familiar....Such communication has always been, and is [particularly] in the present age, one of the primary sources of progress."

John Stuart Mill,
Principles of Political Economy, 1848

Generating keys and CSR requests for your Public Key Infrastructure (PKI) needs is tedious and annoying without proper tools. Remembering openssl commands and syntax requires a constant visit to the man page or the googles. So what does any good geek do when faced with a repetitive problem? They write a script or download a tool. I wrote a script because I love reinventing the wheel.

The script below (after the jump) creates a customized openssl config file and generates private keys and CSRs. The input to the script is a flat file with either FQDNs, email addresses, or whatever your want that is plugged into the Common Name field of the key/CSR. The script is nothing more than a glorified for loop that helps reduce errors and ensures consistency across a large key base.

This can be really useful when setting up EAP-TLS for your WiFi or other device authentication.

Please leave any feedback you may have in the comments.

EU Data Breach update

| No Comments | No TrackBacks
EU Commission Regulation No 611/2013 (PDF) outlines measures applicable to data breach notification under the amended 2009 EU e-Privacy Directive 2002/58/EC (PDF) of the European Parliament and of the Council on privacy and electronic communications.

The Chaos Computer Club, a Germany based hacker collective with a rich history of publicly demonstrating security risks, published an article describing how it had broken the new iPhone Biometric authentication service. They used tools and techniques originally developed in 2004 to fool the iPhone fingerprint sensor. 

"The biometrics hacking team of the Chaos Computer Club (CCC) has successfully bypassed the biometric security of Apple's TouchID using easy everyday means. A fingerprint of the phone user, photographed from a glass surface, was enough to create a fake finger that could unlock an iPhone 5s secured with TouchID. This demonstrates - again - that fingerprint biometrics is unsuitable as access control method and should be avoided."

The CCC hacker Starbug, who conducted much of the biometric research, said in 2007, "As we have said now for more than years, fingerprints should not be used to secure anything. You leave them everywhere, and it is far too easy to make fake fingers out of lifted prints."

Recent Comments

  • Tim Lisko: Laurel - Thank you for sharing your excellent write up. read more
  • lpapworth: I had a slightly different take on Department of Justice, read more
  • Tim Lisko: pthread1981 -- It's a valid argument. I would imagine search read more
  • pthread1981: pretty interesting. I've heard the main reason they want this read more
  • rainey.reitman: Hi Tim - thanks so much, this is very helpful! read more
  • https://www.google.com/accounts/o8/id?id=AItOawk_X3_5H2aIcqt8yZ7_Z8HzSQoKgHokb2o: One of the best howto articles I've found on such read more
  • maxxxon.myopenid.com: Cool movie! I guess these issues should be advertised wider. read more
  • maxxxon.myopenid.com: I prefer to delete all the metadata after taking photos, read more
  • maxxxon.myopenid.com: Very useful and clear for related Twitter developments. read more
  • https://www.google.com/accounts/o8/id?id=AItOawl8087vvkMW3X3pwJPpreZ_U7Iz5c4vp28: Hi Tim, The thing I like about this video is read more
OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.01