As systems administrators and security folks, we've all had our fill of our users and customers using simple passwords. Most operating systems these days now enforce some level of password complexity by default, with options to "beef up" the password requirements for passwords.
The prevailing wisdom today is to use passphrases - demonstrated nicely by our bud at xkcd - http://xkcd.com/936/
So I routinely have very long pass phrases for public facing accounts. Imagine my surprise when I was creating a new account on major cloud service (the one that starts with an "O" and ends with a "365"), and found that I was limited to a 16 character password.
Needless to say I have a case open to see if that limit can be removed. I'm not looking for no limit / invitation to a buffer overflow status on the password field, but something bigger than 16 would really be appreciated !
Â(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Thursday, April 24th 2014 http://isc.sans.edu/podcastdetail.html?id=3949, (Thu, Apr 24th)
After some fun and games at one customer site in particular, I found that the SSL services on the earlier versions of the HP Proiliant Servers iLo ports (iL01 and iLO2) are not susceptible to heartbleed.
However, their implementation of SSL is fragile enough that scanning them for the Heartbleed vulnerability will render them inoperable. This affects Proliants from G1 all the way up to G6, as well as many of the HP Bladesystems.
A complete power down of the entire system - as in remove both of the AC cables - is required to reset the iLo card and bring it back to life. While this may seem like a quick fix for a single server, if that server is running a Hypervisor, or if it's a bladesystem with Hypervisors running on the blades, this can multiply to be a huge issue. Especially if your client scanned the server subnet, and effectively bricked all their iLO cards before they realized there was a problem (oops)
(And yes, the fact that we worked this out Easter weekend is somewhat ironic.)
Full details are in HP Support Document c04249852
This illustrates that even when scanning for simple things (with NMAP, Nessus or any other scanning tool really), it's best to scan a few test systems first - or if you have a test VLAN that replicates your production systems, even better! This isn't a problem with the scanners, almost always the problem is the fragility of the service being scanned. Many services are only written to deal with "the right" inputs, which is not how most scanners (or most attackers) tend to operate.
Safe Scanning Everyone!
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]
Special Edition of OUCH: Heartbleed - Why Do I Care? http://www.securingthehuman.org/newsletters/ouch/issues/OUCH-2014-special_en.pdf, (Wed, Apr 23rd)
Alex Stanford - GIAC GWEB,
Research Operations Manager,
SANS Internet Storm Center
ISC StormCast for Wednesday, April 23rd 2014 http://isc.sans.edu/podcastdetail.html?id=3947, (Wed, Apr 23rd)
Unlike announced a few month ago, the infamous "Port 32764" backdoor was not fully patched in new routers . As a reminder, the original backdoored allowed unrestricted/unauthenticated root access to a router by connecting to port 32764. The backdoor was traced back to components manufactures by Sercomm. Sercomm delivers parts for a number of name brand routers sold under the brands of Cisco, Linksys, Netgear, Diamond and possibly others.
An analysis of an updates router by Synacktive revealed that the code implementing the backdoor is still present, and can be activated to listen again by sending a specific Ethernet packet. The packet would not be routed, so an attacker has to have access to the local network the router is connected to, which significantly lowers the probability of exploitation, but doesn't eliminate it.
The packet activating the backdoor is identified by an Ethernet type of 0x8888.
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.
ISC StormCast for Tuesday, April 22nd 2014 http://isc.sans.edu/podcastdetail.html?id=3945, (Tue, Apr 22nd)
Here's one yardstick that I use before signing up for any new online service: I first search the Interwebs for stories from users who tried to close their account and to leave same service, and were given a hard time. I understand that commercially it is "rewarding" to show 300 million subscribers, even if 90% of them are stale accounts. But from a privacy and data security point of view, it does NOT make any sense for a user to leave an account behind that he/she knows for sure will never be used again. Some services, also larger ones, are handling this issue professionally, and have a decently findable link on their home page that allows the closing of an account and deletion of stored data. Others .. give you the run-around via six levels of customer "service", and in the end, they basically change your username to username.inactive, but leave everything else as-is. And keep spamming you, too.
If you have stories to share about online services that don't let you leave, please do so below. Keep it PG-13 and factual, please, but if a little ire shines through, we understand ...(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Now that the frantic frenzy around "Heartbleed" has calmed, and most sites are patched, it is time to circle back. For a server at a community college that I knew had been affected, I wanted to see if someone had pulled any data via Heartbleed during the roughly 36 hours between when the vulnerability became widely known, and when IDS signatures and patches were deployed to protect the site.
Problem is, Heartbleed leaves basically no traces in the httpd server log, so checking there for attacks didn't help. After a bit of pondering, we came up with the idea to correlate the firewall log with the web server log. If the firewall had seen a number of tcp/443 (HTTPS) connections to the web server from a certain IP, but these same connections were not in the web server log, chances were that we had found ourselves a bleeder.
The first IP that the correlation script identified as potentially fishy turned out to be owned by SSLlabs, and likely belongs to their public SSL scanner that everyone was using at the height of the panic. So .. the script seemed to be working well, and was pulling out the "right" types of connections.
A bit later, we found another IP, registered to an ISP in Malaysia. Twenty minutes of hits only on the firewall, at a rate of about one every 5 seconds, followed by a 5 minute pause, followed by hits both on the firewall and on the web server. Hmm, peculiar :). Chances are high this was in fact someone who tried to steal cookies of active sessions first, and then tried to re-use the cookies to break in. For the second part of the attack, the web server log shows GET requests to the application, followed by a 302 redirect to the "login" page, so "something" must have gone wrong on the attacker's side in either stealing the cookies, or in splicing them back into his fake requests. After another 20 minutes and about 60 requests which all were answered with a redirect, the attacker gave up.
Which tools or methods did you use to identify "heartbleed" leaks that occurred in the time span where your site was vulnerable, but IDS instrumentation and patching wasn't really available yet? Feel free to let us know via the contact form, or share in the comments below!(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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.
ISC StormCast for Monday, April 21st 2014 http://isc.sans.edu/podcastdetail.html?id=3943, (Mon, Apr 21st)
Yes, I know that by now you are really tired of hear and read about Heartbleed. You probably already got all testing scripts and tools and are looking on your network for vulnerable servers.
I was just playing with the Shodan transformer for Maltego and looking for some specific versions of OpenSSL. The results are not good...
Somethings to keep in mind when checking your network is that the tools may not detect all vulnerable hosts since they may be buggy themselves :)
According some research, one of the first scripts released to test the vulnerability, and that most of people still use to identify vulnerable servers contains some bugs that may not detect correctly the vulnerable servers.
The heartbeat request generated on the proof of concept script is:
18 03 02 00 03 01 40 00 <-- the bold bytes basically tell the server to use TLS 1.1, so if the server only supports TLS 1.0 or TLS 1.2 it won't work. Of course that 1.0 and 1.2 are not widely used, so the chance of you having it on your network is small, but still, there is a chance.
Early last week, while testing different online and offline tools, I also came across different results, so you may want to use different tools on your check.
Network signatures may also provide additional check to help you identify vulnerable hosts. Again there is a chance of False Positives, but it is worth to provide you with more info on your checks.
Snort signatures and network parses for products like Netwitness can also be very effective to detect not only when an exploit was used against your hosts, but most importantly, when your vulnerable host provided information back (the leaked info).
Happy hunting to you because the bad guys are already hunting!
Pedro Bueno (pbueno /%%/ isc. sans. org)
We have received reports by many readers about buggy tools to test for the heartbleed vulnerability. Today I want to show you how easy it is to check for this vulnerability using a reliable tool as nmap.
You just need to trigger a version scan (-sV) along with the script (ssl-heartbleed). The following example with show a command that will scan 192.168.0.107 for this bug:
nmap -sV 192.168.0.107 --script=ssl-heartbleed
This will be the output for a non-vulnerable website. As you can see, no warnings are shown:
If you are vulnerable, you will get the following:
For vulnerability testing, always use reliable tools which won't contain malicious code infecting your computer and won't give you false positive messages.
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?
ISC StormCast for Friday, April 18th 2014 http://isc.sans.edu/podcastdetail.html?id=3941, (Fri, Apr 18th)
ISC StormCast for Friday, April 18th 2014 http://isc.sans.edu/podcastdetail.html?id=3941, (Fri, Apr 18th)
Looking for malicious traffic in electrical SCADA networks - part 2 - solving problems with DNP3 Secure Authentication Version 5, (Thu, Apr 17th)
I received this week a very valuable e-mail from the DNP Technical Committee Chair, Mr. Adrew West, who pointed an excellent observation and it's the very slow adoption of DNP3 Secure Authentication Version 5, which is the latest security enhancement for the DNP3 protocol. I want to talk today about this standard and the advantages of adopting it into your DNP3 SCADA system.
This standard has two specific objectives:
- Help DNP3 outstation to determine beyond any reasonable doubt that it's communicating with an authorized user.
- Help DNP3 master to determine beyound any reasonable doubt that it's communicating to the correct outstation.
This standard minimize the following risks:
- Spoofing to outstation or master: Since the original specification includes only the DNP3 outstation address as the only way for identification, the new standard uses crypto keys to enforce the authentication to each end.
- Modification: The standard includes the concept of Message Authentication Code (MAC) as shown in ISO/IEC 9798-4. This standard allows to determine if a message has been modified before arriving to the destination, ensuring integrity.
- Replay attack: Valid traffic cannot be retransmitted anymore by any third party as authentication information would not be the same.
- Eavesdropping: Crypto keys are securely exchanged. Data being transmitted goes still in clear-text, so confidentiality is not ensured. You need additional gear like crypto-boxes on each end of the communication link.
DNP Application Layer
DNP Secure Authentication
DNP Transport Function
DNP Data Link Layer
Internet Protocol Suite
The following diagram shows the implementation architecture for this standard:
As seen, an additional level before application layer is added, providing the new security features.Unfortunately, there are two specific reasons that is preventing this standard for being widely deployed in the world:
- ICS systems are still being planned to last from 10 to 20 years: Technology has arrived to that world and most ICS people have not noticed that yet. They still think that air gap is enough to protect the ICS systems and won't consider new investements to implement new security features. United States is one of the leaders in regulation for critical infrastructure. However, this does not happen in most countries and unless governments produce new laws for enforcing cybersecurity on critical infrastructure, adoption of such standards will keep slow.
- DNP3 equipment manufacturers do not offer the same references and features in all countries of the world, and most of them even claim that this standard is not yet supported (for example, in south america).
Cybersecurity is not still mature in the ICS industry and has a long way to go. Information Security Professionals working with the ICS world has a really big challenge: We need to demonstrate that Information Security Controls like this standard will have a return of investment to the company and the risk of not having them, if operating a critical infrastructure to a Country, could be catastrophic and impacts incalculable. This standard works, won't put at risk any ICS facility and we all have a responsability of ensuring its implementation to our companies.