INFOCon Green: Heartbleed - on the mend

Published: 2014-04-14. Last Updated: 2014-04-14 14:21:08 UTC
by Kevin Shortt (Version: 1)
9 comment(s)

We are going back to INFOCon Green today.   Things have stabilized and the INFOCon is used to indicate change.  Awareness of Heartbleed is well saturated and Internet teams everywhere appear to be responding appropriately.  

Some points to be aware:

  • Patching will continue and hopefully fill remaining gaps.
  • Certificate Revocation Lists (CRLs) will grow, which may lead to slower load times in some cases. Please let us know if you are observing CRL issues.
  • There is no practical way to identify if a certificate has actually been updated, unless you recorded the certificate serial number.   It is common to check the creation date, BUT a CA can re-issue a new certificate and keep the original creation date. This is silly but should be noted.
  • The client side (wget, curl, etc...) of Heartbleed is mostly a non-issue, but there are a few exceptions. Watch for VPN client updates.
  • Certificates continue to be revoked.  We have taken the liberty to look at the CRL counts of sixteen different CA's since April 1, 2014. 

In summary,  please keep scanning and patching all of your servers and encourage all end users to change their passwords after a site's certificate has been updated.


-Kevin
--
ISC Handler on Duty

Keywords: heartbleed Infocon openssl
9 comment(s)

Comments

Does anyone know if Akamai or other CDNs cache CRLs?

Anonymous

Apr 14th 2014
1 decade ago

See their blog:
- https://blogs.akamai.com/2014/04/heartbleed-update-v3.html
April 13, 2014 7:20 PM

.

Anonymous

Apr 14th 2014
1 decade ago

What's the deal with the CRL counts, guys? Are these the numbers of new entries to the CRL files each day, or the total values of all entries in all CRL files on each date?

I'm assuming the former, as I'm not immediately sure why the numbers would drop unless it just happened that some certificates expired on those dates.

Anonymous

Apr 15th 2014
1 decade ago

There are good reasons for fiddling with certificate issuing dates.
I have seen certificates issued with a start date 1-1-1980, as otherwise PDAs would fail conncting to WiFi, verifying the AP certificate. The PDAs would reset their own date when running out of battery.

Only 2 other solutions would be to let the usrrs get out of the dedicated app, and into the clock setting app, or to disable validation of APs certificate. Both lowering security.

Anonymous

Apr 15th 2014
1 decade ago

There is a Firefox plug-in for pinning/tracking certificates... it can be a bit noisy by times for sites (like Google) that use a lot of different certificates... but its been interesting to watch the changes happen during the recovery from HeartBleed. http://patrol.psyced.org/ Certificate Patrol (version 2.0.14 I think is current)

Anonymous

Apr 15th 2014
1 decade ago

I have the suspicion that many people are renewing certificates by clicking a renew button or just by resending the original signing request (CSR). If they private key has been leaked that is not enough as it is not regenerated in that case. So you really must create a new private key (and csr).

HSM devices could have reduced the impact a lot if used correctly, but no-one actually seems to use those for web related stuff. It would be interesting to read some stories about experiences of those who did use HSM (or TPM) devices to protect their private keys.

Anonymous

Apr 15th 2014
1 decade ago

That's not what I was talking about with Akamai. The blog post is about their own exposure to Heartbleed. But what about CRLs at VeriSign and other CAs? Does Akamai cache them in their local ISP servers to improve client performance and so that the CAs don't get stampeded ?

Anonymous

Apr 15th 2014
1 decade ago

Akamai will/should only cache it if the particular domain the CRL is loaded from is cached. However, the client itself does a lot of caching. The CRL does include a "next update" date so the client knows for how long to cache the CRL.

CRLs are not updated often. For example, one of the Godaddy CRLs is updated every 36 hrs. Let me add that data to the new CRL page we just put together (https://isc.sans.edu/crls.html ). should be there in a couple hours. Right now, I am pulling the CRL data every 5 hrs but should probably start using the "next update" data instead.

Anonymous

Apr 16th 2014
1 decade ago

Firms still hemorrhaging from Heartbleed
August 21, 2014

Although the Heartbleed bug was revealed months ago, it continues to cause security problems for companies.

The most recent example is the data breach at Community Health Systems, which resulted in the largest theft of civilian patient records in U.S. history.

CMS claimed that the theft was carried out by a Chinese hacker group that injected malware into the hospital's computer network and siphoned off the patient data.

Reports are now circulating that the hackers exploited the Heartbleed bug to gain initial access to the CHS network. In a blog posted this week, TrustedSec said analysis it conducted indicates that the "initial attack vector" was through Heartbleed.

"This confirmation of the initial attack vector was obtained from a trusted and anonymous source close to the CHS investigation. Attackers were able to glean user credentials from memory on a CHS Juniper device via the Heartbleed vulnerability (which was vulnerable at the time) and use them to login via a VPN," the blog relates.

Heartbleed continues to pose a grave security risk to firms. According to a study by security firm Venafi release in August, a disturbing "97 percent of Global 2000 organizations remain vulnerable to Heartbleed because they have not replaced vulnerable keys or revoked and replaced digital certificates."

In addition, an advisory issued last month by the Industrial Control Systems Cyber Emergency Response Team warned that critical industrial control systems made by Siemens remain vulnerable to Heartbleed.

It's time for enterprises to take Heartbleed seriously and implement the steps needed to plug the vulnerability--or risk being front-page news for another record-breaking data breach.

Anonymous

Aug 26th 2014
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives