Thanks to Gebhard for letting us know about a new vulnerability in Apache Struts.
If you recall the classloader vulnerability of few months ago, the fix for that seems to be case and punctuation sensitive (using  instead of "." was not accounted for)
In any case, they have posted a mitigation how-to here: http://struts.apache.org/announce.html#a20140424
This affects all versions up to 22.214.171.124
Find more information on this here:
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
In IPv6, DHCP is taking somewhat a back seat to router advertisements. Many smaller networks are unlikely to use DHCP. However, in particular for Enterprise/larger networks, DHCPv6 still offers a lot of advantages when it comes to managing hosts and accounting for IP addresses in use.
One of the big differences when it comes to DHCPv6 is that a host identifies itself with a DUID (DHCP Unique Identifier) which can be different from a MAC address. There are essentially three ways to come up with a DUID:
Link Layer + Time: In this case, the host will on first boot create a DUID using one interfaces link layer address (MAC address for Ethernet), as well as the timestamp (seconds since Epoch) to derive a DUID. This DUID will be saved to disk and remain constant even if the network card is swapped later.
Link Layer: Some hosts may not be able to retain a DUID between reboots in this case, the link layer address is used.
Vendor Assigned: You can also just assign an arbitrary DUID, maybe a host name, to identify the host.
Regardless which method you use, the sad part is that each operating system, and in some cases different software on the same operating system, chooses to display the DUID differently, making correlation hard.
Here are a few examples:
Linux seems to like a mix of octal and ASCII characters (if the value represents a printable character). For example:
However, in Linux configuration files for DHCPv6 servers and clients, you may find a simpler hex format:
option dhcp6.client-id 0:1:0:1:1a:de:c6:fb:0:c:29:67:cf:2;
OS X on the other hand displays the time part in decimal, and the MAC address part in hexadecimal:
ipconfig getv6packet en0
CLIENTID (1) Length 14 DUID LLT HW 1 Time 389824106 Addr 40:6c:8f:11:d7:5c
Windows prefers to display the hexadecimal version as output for "ipconfig /all"
DHCPv6 Client DUID. . . : 00-01-00-01-13-0D-1E-A2-00-0C-29-A3-D3-30
To help myself a bit with this confusion, I started a little script that will convert DUIDs from different formats. It isn't quite done yet, but good enough to see if anybody finds it helpful and would like to test it. You can download the script from https://isc.sans.edu/diaryimages/duidconvert.pl
[To learn more about IPv6 Security, check out my class IPv6 Security Essentials]
Apple today released patches for OS X, iOS and Apple TV. The OS X patches apply for versions of OS X back to Lion (10.7.5). Vulnerabilities fixed by these patches can lead to remote code execution by visiting malicious web sites.
For more details, see Apples security update page . Links to the actual update details should become available shortly.
OpenSSL, in spite of its name, isn't really a part of the OpenBSD project. But as one of the more positive results of the recent Heartbleed fiasco, the OpenBSD developers, who are known for their focus on readable and secure code, have now started a full-scale review and cleanup of the OpenSSL codebase.
If you are interested in writing secure code in C (not necessarily a contradiction in terms), I recommend you take a look at http://opensslrampage.org/archive/2014/4, where the OpenBSD-OpenSSL diffs and code changes are coming in fast, and are often accompanied by cynical but instructive comments. As one poster put it, "I don't know if I should laugh or cry". The good news though definitely is that the OpenSSL code is being looked at, carefully and expertly, and everyone will be better off for it.(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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?