Join the CASC Wednesday April 30 for a Google+ hangout on the Heartbleed Bug. We’ll cover everything from what the bug does to how to tell if your site is at risk and how certificate authorities are responding.
Panel of CASC members:
• Robin Alden- Comodo
• Jeremy Rowley- DigiCert
• Bruce Morton- Entrust
• Rick Andrews- Symantec
• Wayne Thayer- Go Daddy
Watch the recording: http://bit.ly/1jAQCtk
2. The Experts
Rick Andrews
Senior Technical Director, Symantec
CASC Member Jeremy Rowley
VP of Business Development, DigiCert
CASC Member
Bruce Morton
Director, Certificate Services, Entrust
CASC Member Robin Alden
Chief Technology Officer, Comodo
CASC Member
Wayne Thayer
VP & GM, Security Products, GoDaddy
CASC Member
4. About the CA Security Council
• Comprised of 7 leading global Certificate Authorities
• Committed to the exploration and promotion of best
practices that advance trusted SSL deployment and CA
operations
• The CASC works collaboratively to improve
understanding of critical policies and their potential
impact on the internet infrastructure
• https://casecurity.org/
5. Topics
• What is Heartbleed?
• Who is/was affected?
• How can I tell if I’m at risk?
• What steps should I take?
• How have Certificate Authorities responded?
• Conclusions
6. What is Heartbleed?
• Technical description
• Origin of the name
• Protocol bug or Implementation Error?
• Did the NSA create this or exploit this?
7. Technical description
• TLS Protocol extension ‘Heartbeat’ (RFC6520)
• Heartbeat messages used to check a TLS server is reachable
and alive
• Message says ‘Send me these N(=5) bytes “#CASC” if you’re
there’. Server replies “#CASC”
• The vulnerability (Heartbleed) occurs when the ‘N’ doesn’t
match the length of the message.
E.g. ‘Send me these N(=500) bytes “#CASC”’
• A vulnerable server sends back “#CASC” followed by 495
bytes of internal information, which could include the servers
private key, someone else’s password and credit card
number.
• The bad guy gets to try for as many chunks (of 495 bytes) as
he likes.
8. Origin of the name Heartbleed
• The vulnerability was discovered at around
the same time by Google (1st
April) and
Codenomicon (3rd
April)
• Codenomicon gave Heartbleed its name and
logo in order to contribute to public
awareness of the issue.
• It worked!
9. Protocol bug or Implementation Error?
• RFC6520 specifies the Heartbeat message to
have separate length and payload fields. This is
not unusual in such protocols.
• The implementation doesn’t check that the
length of data it is to return is the same as the
length of the data that was supplied to it in the
first place (i.e. 500 <> length("Hello")).
• It accepts the (short) inbound message ("Hello"),
and then replies with 500 bytes inadvertently
revealing some of its internal state.
• It is an implementation error.
10. Did the NSA create this or exploit this?
• We don’t know!
• A couple of reports of logs showing abuse of
Heartbleed before its announcement, but none of
these seem to have been substantiated.
• There is currently no public evidence that the NSA (or
anyone else) created this vulnerability.
• Human error seems the most likely explanation for it.
• Although we don't think Heartbleed was exploited
before it was discovered (around 1st
April 2014), to be
safe we are acting as if it may have been exploited and
that leads us to some of the recommendations we will
be presenting later in this hangout.
12. Who is/was affected?
• Web sites large and small
• Smart phones
• CDNs
• Internet Routers
• Apps and Games
• Wifi Routers
• Embedded devices
13. Web sites large and small
• Netcraft reports ~17% of all web sites
• Google
– Search, Gmail, YouTube, Wallet, Play, Apps, App
Engine, AdWords, DoubleClick, Maps, Maps
Engine and Earth
• Yahoo
• Dropbox
• Wikimedia (including Wikipedia)
• Intuit TurboTax
14. Web sites large and small
Social Networking:
•Facebook
•Twitter
•Tumblr
•Pinterest
•Reddit
•Instagram
Tech sites:
•Amazon Web Services
•Ars Technica
•GitHub
•Sourceforge
15. Smart phones and tablets
• Android version 4.1.1 (Jelly Bean)
– ~34% of Android installed base
– Requires updates from device manufacturers and
carriers
– Mostly HTC Evo, One S and One X
• Mobile apps
– Bank, payment and shopping apps
– Blackberry Secure Work Space and BBM Chat for
iOS and Android
17. Internet Routers
• Cisco:
– Unified Communication Manager (UCM) 10.0
– MS200X Ethernet Access Switch
• F5
• Juniper’s SSL VPN software
• OpenVPN
• Tor Project
18. Apps
• Password Managers including LastPass
• LibreOffice
• LogMeIn
• McAfee anti-virus
• Blackberry Link for Windows and Mac OS
• Webex Messenger Service
• Cisco Registered Envelope Service (CRES)
• Games: Steam, Minecraft, Wargaming, League of
Legends, etc.
19. Wifi Routers
• Apple AirPort Extreme and AirPort Time
Capsule base stations, only if they have Back
to My Mac or Send Diagnostics enabled (Mac
OS X, iPhone, iPad not directly affected)
22. How do I tell if I’m at risk?
• Check your website: https://sslcheck.casecurity.org
• Was my website ever at risk?
– Check with you hosting provider
– Is it running Apache or Nginx?
• If so, is it still at risk?
– Did you rekey your certificate after the site was patched?
23. How do I tell if I’m at risk?
• Your Certificate Authority:
– Since Heartbleed is a vulnerability in the protocol, it did not directly
affect CA’s certificate issuing systems or their root certificates
– Some CA’s websites were affected
• Check your CA’s website for information
• If affected, they will have patched and rekeyed the certificate used on the site
• If their website was affected, they may ask you to change your password
• Browsers and other Clients:
– Mainstream browser not affected
– Check with your vendors
– Scrutinize any in-house software that uses OpenSSL
– Test at https://reverseheartbleed.com
24. Does PFS Prevent Heartbleed?
• Perfect Forward Secrecy
– Attribute of ECDHE cipher suites
• Session keys never sent across the network with PFS
– Archives of encrypted traffic can’t be recovered
• But
– Not all clients support PFS ciphers!
– A compromised private key can still be used to intercept
traffic in real time!
26. What steps should I take to address the
bug?
If you are running a web server, then inform, fix, rekey,
reissue, revoke, re-inform
•Inform users of your status
•Fix the OpenSSL problem
•Rekey server
•Reissue install new certificate, revoke old certificate
•Re-inform users and request passwords be changed
•Perfect Forward Secrecy, Second–factor authentication,
end-to-end encryption, hardening
27. What steps should I take to address the
bug?
If you are a client (application or browser user)
•Does your client software need an update?
•Check for updates of software
•Change passwords on sites that have been
patched
•Check for Heartbleed
• CASC - https://sslcheck.casecurity.org
• Netcraft plugin -
http://news.netcraft.com/archives/2014/04/17/netcraft-
releases-heartbleed-indicator-for-chrome-firefox-and-
opera.html
28. What steps should I take to address the
bug?
Configure your browser to check for revoked certs
29. Response
• CAs received same-day notice of the vulnerability
as customers (April 7, 2014)
– CA keys are stored offline and not subject to
Heartbleed
• Support increase to cover the extra volume
• Outreach program to assist in corrective action
• Most CAs offered a free revoke and replace plan
to account for the vulnerability
• A lot of over-time with double the volume
30. Updates
• Updated documentation, knowledge base
articles, etc
• Email blast and telephone calls to customers
• Enhanced tools to detect vulnerabilities
– https://www.digicert.com/heartbleed-bug-
vulnerability.htm#getaccess
– https://ssltools.websecurity.symantec.com/checker/v
iews/certCheck.jsp
– https://sslcheck.globalsign.com/en_US
– https://sslanalyzer.comodoca.com/heartbleed.html
31. Noteworthy
• No Internet Slow Down
– CRLs v. OCSP
– Edge-based delivery
• Importance of Revocation
– http://bit.ly/1kq1GNd
– http://twit.tv/show/security-now/453
– Coordinated Effort among Community
– Accurate information
– Remediation assistance
– Positive feedback
32. Looking Ahead
• Work with remaining web server operators
• Push for MUST-STAPLE and turn on revocation
• Continued outreach with device makers and
others
33. Conclusions
• Heartbleed is not an issue with the SSL/TLS trust
system, but a problem of trust in a single software
source
• OpenSSL has since received additional funding, but
no software system is ever 100% secure
• Guidance on password policy still stands: don’t reuse
passwords, change them often, etc.
• Revocation is a critical part of the SSL/TLS
infrastructure
First a word about the protocol extension that has the vulnerability, then I&apos;ll mention the vulnerability itself.
The TLS protocol has an extension called &apos;Heartbeat&apos;, defined in RFC6520, designed to allow the use of a keep-alive function for TLS (or DTLS) without performing a
costly renegotiation where no session exists (TLS) or could exist (DTLS).
Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive.
Put simply the nature of the request is:
&apos;Hey server, shout the 5 bytes &quot;#CASC&quot; back to me if you&apos;re up and listening&apos;
A server that is up would send back &quot;#CASC&quot;.
The Heartbeat extension is actually pretty rarely used and (until recently) rarely mentioned.
Now to the Heartbleed vulnerability, and it is the vulnerability we are interested in here.
The nature of the Heartbleed vulnerability is that the server will send back more in the reply than it was given in the request in the first place.
E.g.
&apos;Hey server, shout the 500 bytes &quot;#CASC&quot; back to me if you&apos;re up and listening&apos;
A vulnerable server up would send back &quot;#CASC&quot; followed by 495 bytes of values from its internal memory.
It is those extra bytes (495 in my example) which can reveal private information which might contain the server certificate&apos;s private key, or might contain data from another user&apos;s session such as their username and password and credit card number.
An attacker gets to try again as often as he likes, each time fetching bytes (up to 64k at a time) from the server.
Google and Codenomicon
both discovered the vulnerability independantly at around the same time.
Google were actually first (April 1st), but Codenomicon (April 3rd)
(http://www.codenomicon.com) gave the name Heartbleed (and the logo) to the vulnerability as an aide to promote public awareness.
It worked.
The idea of a &apos;branded&apos; exploit is not entirely new, but in this case getting the name and a logo early helped make the vulnerability addressable as a topic of discussion by a wide audience, even those who understood little about its technical nature.
The vulnerability was picked up by news agencies across the world - and not just the technical press - and at its peak there was a tweet every second on the subject from regular users - not just from nerds like us.
That&apos;s great because, as you will hear later, many internet users will be affected directly or indirectly by this vulnerability.
RFC6520 specifies the Heartbeat message to have separate length and payload fields. This is not unusual in such protocols.
The nature of the bug is that the implementation does not check, when it receives a Heartbeat message, that the length of data it is to return is the same as the length of the data that was supplied to it in the first place (i.e. 500 &lt;&gt; length(&quot;Hello&quot;)).
It accepts the (short) inbound message (&quot;Hello&quot;), and then replies with (e.g.) 500 bytes inadvertently revealing some of its internal state.
It is an error in the implementation, not the protocol definition.
We don&apos;t know!
There were some suggestions that examples of logs existed showing misuse of the heartbleed vulnerability, but none of these seem to have been substantiated.
It seems likely there is currently no evidence that the NSA (or any other US or foreign agency) created this vulnerability.
Human error seems the most likely explanation for it.
Nonetheless, while we don&apos;t think Heartbleed has been exploited before the time it was announced publicly to be safe we are acting as if it may have been exploited and that leads us to some of the recommendations we will be presenting later in this hangout.
Also HP System Management software, procurement software, Canada Revenue Agency (CRA) , VMware series of Horizon products, emulators and cloud computing suites, Western Digital My Cloud product family firmware, HP&apos;s BladeSystems, IBM&apos;s AIX servers, Dell&apos;s appliances and networking equipment
Nearly all browsers do not use OpenSSL (exception is Chrome on Android 4.1.1)
You’re not secure if you’re using older versions of OpenSSL!
http://www.forbes.com/sites/bobegan/2014/04/11/a-billion-smartphones-users-may-be-affected-by-the-heartbleed-security-flaw/:
Trend Micro scanned a mere 390,000 of some one million apps in Google Play. They found about 1,300 apps
connected to vulnerable servers, including 15 bank-related apps, 39 online payment-related and 10 online
shopping-related.
http://gadgets.ndtv.com/internet/news/android-411-devices-vulnerable-to-heartbleed-bug-says-google-508262
http://thehackernews.com/2014/04/billions-of-smartphone-users-affected_13.html
http://www.fiercemobileit.com/story/htc-tops-list-manufacturers-heartbleed-vulnerable-smartphones-says-lookout/2014-04-21
http://btsc.webapps.blackberry.com/btsc/viewdocument.do?noCount=true&externalId=KB35882&sliceId=1&cmd=displayKC&docType=kc&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
May not introduce new vulnerability if CDN is just serving static content, but cookies might be sent to CDN
If you are running a web sever, then you need to: Inform, fix, rekey, reissue, revoke, re-inform
Inform users of your status. Are you broken, are you shut down, when you will be fixed. Communication is key.
Fix the OpenSSL problem. It is likely that your vendor will have a patch. Follow your vendor and install the patch.
Rekey your web server. Your private key may have been compromised, so you need a new private key with a corresponding public key.
Reissue and install a new certificate with the new public key. Revoke old certificate to mitigate any compromise.
Re-inform your users of your status and request passwords be change
You may also want to consider mitigating future bugs/attacks by implementing: Perfect Forward Secrecy, Second–factor authentication, end-to-end encryption, or just hardening your server
If you are a client
As the Heartbleed bug can be used on both a server and a client, does your client software need an update?
You shouldn’t have any problems with a browser, but an application may be using OpenSSL
As such, check the status or updates to software that you use for secure communications
If your web service has told you that they are vulnerable, stop using their service until it is fixed.
Once your web service is fixed, change your password
If you want to know if a service is vulnerable use a checker to find out; such as the SSLchecker at our CASC
Or you can also install the Netcraft app to your browser which will check for you.
Since fixing Heartbleed will mean that certificates will be revoked, you want to ensure your browser is checking certificate status.
In Windows use Internet Options, select the Advanced tab, and select “Check for server certificate revocation” under Security.
There are some debates as to whether users should waste time checking certificate status.
We recommend checking status as we don’t believe that you should let Perfect be the enemy of Good.