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:

Humor:

"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


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




Brian Owsley, former United States Magistrate Judge for the Southern District of Texas and current professor at Texas Tech University School of Law, published an article in the University of Pennsylvania Journal of Constitutional Law, Vol. 16, 2013 titled "The Fourth Amendment Implications of the Government's Use of Cell Tower Dumps in its Electronic Surveillance (PDF)". The paper addresses novel issues about electronic surveillance using cell tower dumps. 

Abstract:      
Privacy concerns resonate with the American people. Although the right to privacy is not explicitly protected in the United States Constitution, the Supreme Court has found the right to privacy rooted within the Constitution based on various amendments. In the modern era, with rapid advances in technology, threats to privacy abound including new surveillance methods by law enforcement. There is a growing tension between an individual's right to privacy and our collective right to public safety. This latter right is often protected by law enforcement's use of electronic surveillance as an investigative tool, but may be done at times inconsistent with constitutional rights. 

Recently, the American Civil Liberties Union brought to light the popular use of government surveillance of cell phones, including the gathering of all cell phone numbers utilizing a specific cell site location. Known as a "cell tower dump," such procedures essentially obtain all of the telephone number records from a particular cell site tower for a given time period: "A tower dump allows police to request the phone numbers of all phones that connected to a specific tower within a given period of time." State and federal courts have barely addressed cell tower dumps. However, the actions by most of the largest cell phone providers, as well as personal experience and conversations with other magistrate judges, strongly suggest "that it has become a relatively routine investigative technique" for law enforcement officials. 

No federal statute directly addresses whether and how law enforcement officers may seek a cell tower dump from cellular telephone providers. Assistant United States Attorneys, with the encouragement of the United States Department of Justice, apply for court orders authorizing cell tower dumps pursuant to a provision in the Electronic Communications Privacy Act of 1986. The pertinent provision poses a procedural hurdle less stringent than a warrant based on probable cause, which in turn raises significant constitutional concerns. 

This article provides a brief description of cellular telephone and cell-site technology in Part I. Next, Part II addresses the evolution of Fourth Amendment jurisprudence and argues that the reasonable expectation of privacy standard applies to electronic surveillance such as cell tower dumps. In Part III, the discussion follows the development of statutes addressing electronic surveillance and argues that cell tower dumps request more information than simply just telephone numbers. Part IV analyzes records from both cellular service providers and the federal government to conclude that cell tower dumps routinely occur. Part V assesses the few decisions that even discuss cell tower dumps and argues that the analysis is either non-existent or flawed regarding the use of the Stored Communications Act to permit cell tower dumps. Next, Part VI asserts that cell tower dumps cannot be analyzed pursuant to the Stored Communications Act because the language of the statute is inapplicable and the amount of information sought requires a warrant based on probable cause and concludes by proposing some protocols to safeguard individual privacy rights.


Interesting article from microsoft with views from three past CPOs.

http://www.microsoft.com/presspass/features/2012/mar12/03-083CPOs.mspx

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