beans and a nice Chianti: August 2016

22 August 2016

SSL is mostly just a false sense of security

Unless you live in a cave somewhere, you’ll be aware that SSL (and by extension TLS) has had a rough life. For a start, there has been a long series of critical flaws in the various incarnations of the protocol, as well as the common implementations, like OpenSSL.

However, it doesn’t stop there. Even on the rare occasions where we are passing through the eye of the storm, and there are no known protocol and implementation flaws, SSL still consistently fails to offer any kind of real-world security due to the way it has been configured. Being as it is, complex and fiddly, there are literally dozens of bad choices that can be made when selecting SSL features at development or configuration time. And what’s worse, many common products are shipped with insecure features enabled by default, or a quick look through their support forums will show recommended settings that actively disable key parts of the SSL security model.

For example, one of those key components is the way that SSL uses certificates to authenticate one or both ends of a connection. Now, assuming the trust model with the certificate authority isn’t compromised in some way (which happens far too frequently) each end of the connection will use the certificate to ensure that it is communicating with who it intends. That is of course if the developer or systems administrator didn’t switch this functionality off because it was fiddly to make work reliably. Ooops.

The truth of the matter is that with certificate validation switched off, SSL is pretty much worthless, as anyone who can eavesdrop on your connection can now also use a man-in-the-middle approach to gain access to the data inside.

How much of a problem are misconfigurations really? A couple of stats for you:

as of today, the Trustworthy Internet Movement shows that of the top 1m web sites, 57% have inadequate SSL security [1], most of which is down to misconfiguration;
a google search for “disable ssl certificate check” shows 500k hits from sysadmins and developers busily looking for ways to switch the functionality off [2].

The truth of the matter is that the biggest threat to your SSL isn’t a bunch of faceless hackers, but is instead sitting right now in your IT department. And what’s worse is that you probably think they’re doing a great job.

References

16 August 2016

Call me, maybe?

There’s one thing to be said for the world of Information Security, and it’s that it rarely stands still for a moment. New products and technologies are released with relentless regularity, each with its own particular set of security challenges to first understand, then protect. Never a quiet moment.

But as new technologies are introduced, old ones are often superseded; relegated to the “legacy” bucket. But just because they are no longer the latest hot topic, it doesn’t mean that they don’t still pose a significant risk to the organisation.

One such technology is the traditional telephone, or as it likes to be formally addressed at black-tie events, the Public Switched Telephone Network (PSTN). Back in the day, the media was awash with stories of hacking attacks that were launched over the telephone network. In fact, the high-profile hack that led to the drafting of the UK Computer Misuse Act (CMA) was itself delivered over the telephone, using a modem.

The Internet has changed all of this though, as in most cases it rightly takes the majority of the focus when it comes to security. But in this shift, a lot of organisations seem to have forgotten about the PSTN. Which can be a bit of a problem, as unfortunately the attackers haven’t!

The fact is that the legacy telephone system remains a rich target for an attacker. Dozens of critical devices are still installed with a remote administrative interface connected to an old-school telephone line. Systems like the burglar alarm, door entry systems, the PBX itself, video conferencing, SANs, and heavy machinery such as lifts, etc. Any one of these could be available, and all that is often required is for an attacker to connect to the right telephone number, then enter the default credentials for the device.

There was a time when most organisations would include their external telephone connectivity as part of their security testing programme (a “war dialling” exercise), but this seems to be a rarity these days.

Maybe it’s time for you to get a bit more old-school.

15 August 2016

Isolate the stupid

A while back, I wandered straight into the middle of a conversation between colleagues and overhead one of them say the wonderful phrase “isolate the stupid”. To be fair, I have taken it completely out of context of the original conversation, but I liked the phrase so much I thought I would use it for my own nefarious ends. Muhaha.

Over the years, I have regularly been called upon to provide help to organisations that have suffered a breach, and need to quickly find out what happened so that they can retrospectively bolt the door (so no more horses can escape).

A common contributing factor I often see in this kind of situation is a huge, flat internal network structure. One that mixes all classes of device together on the same logical wire: servers, desktops, peripherals and (horror-of-horrors) bring-your-own devices. In this situation, all it takes is one stupid mistake, such as a user clicking on a misleading phishing email, and the attacker suddenly has unrestricted access to the whole internal network. Game over.

In security parlance, compartmentalisation is the concept of breaking environments into discrete, logical components, whereby a failure is contained from spreading. In almost all these situations a modicum of compartmentalisation would have either prevented, or greatly reduced, the impact of the breach.

So there you have your top tip for the day: isolate the stupid.

12 August 2016

Begin at the begining

It is a rare week that passes without someone asking me, “What is the best way to get started as a security consultant?”.

However, before I give you my answer, I feel I should first point out that everything I’m about to write is obviously just my personal opinion, which you are of course entitled to take with the appropriate pinch of salt. I would expect that if you asked someone else who was recruiting the same question, they might have very different things that they are looking for. L’acheteur se méfiera!

Onward to my own particular answer though. For the last twenty years, I have personally read thousands of CVs and interview hundreds of people that are looking to make a start in the security industry. An industry which is unusually demanding of its consultants: requiring both extreme breadth and depth of knowledge. Knowledge that is built up in layers, one upon another, with each new layer intimately dependent on the previous one.

Many of the people I interviewed have incredibly polished and impressive CVs, complete with long lists of skills, credentials and training courses. Alas though, once the interview starts it is common to find that there is no substance behind the polish. The skills lists are just an aspiration; no real knowledge underpins the claims.

For someone starting out, I would say the most important thing to do is to make sure you understand the basics really well, and if you don’t know it really well, leave it off your CV. There is no point learning about XSS if you don’t understand HTML. No point in learning HTML if you don’t know HTTP. No point in learning HTTP if you don’t know IP. No point in learning IP if you don’t understand basic maths and technology concepts like modulus, endian-ness, and non-decimal radix.

Don’t attempt to run before you have mastered walking. Begin at the beginning…

4 August 2016

Cisco ASN.1 vulnerability (cisco-sa-20160721-asn1c)

Just in case you missed it, Cisco has recently announced a critical flaw with their code that affects a range of products [1]. However, whilst there will undoubtedly be a lot of discussion around the detail of the vulnerability specifics in the coming weeks (especially if someone turns it into a working exploit), I think that it actually raises a few broader questions that are worth exploring too.

Firstly, is the use of language in the advisory itself. The headline says it all really: Cisco is clearly placing the blame at the feet of Objective Systems, the supplier of the third-party code (who has also released their own advisory too [2]). This is a bit like a car manufacturer blaming the gearbox subcontractor if there’s a recall. Now, it is true that it might be due to a flaw in the third-party code, but as with the car analogy, the ultimate responsibility for ensuring that a product is fit for purpose, lays with the car manufacturer. Even a half-arsed root cause analysis for how the flaw made it through to a finished product (then remained undetected through four major product releases), should quickly show that it is ultimately nothing to do with the third-party code at all, but instead lays with failures in quality assurance.

Secondly, although the word compiler is used liberally in the Cisco advisory, the original advisory released by Lucas Molas [3] (the researcher who found the flaw), is very clear that the root cause is in a runtime library. So it is just another TP code issue, rather than an esoteric compiler bug that is being hinted at.

Thirdly, this is a common library that is used in a number of products, so don’t expect the fallout to be limited to Cisco. The CERT advisory [4] already lists a number of vendors who are likely to be affected, so it would be wise to expect this one to have the potential of snowballing in the coming weeks. You can almost feel the hushed silence, as the ambulance-chasers dust off their reverse-engineering toolkits and get ready to go to work.

Fourthly, speaking from the perspective of someone who has written an ASN.1 interpreter from scratch, it is complex and fiddly; which means easy to get wrong. So it comes as no surprise that this isn’t the first time that there has been a critical issue that has been found in third-party ASN.1 code which is common across a range of platforms. Does anyone remember the huge batch of ASN.1 issues about 15-years back that were discovered by the University of Oulu Secure Programming Group [5]? Déjà vu baby!

Finally, and most importantly, the description of the vulnerability provided by the researcher shows that the root cause lays in parameters that are used without being first sanity checked. In fact, it’s a straightforward boundary condition that overflows a 32bit integer, which really is pretty much the lowest of-the-low-hanging-fruit when it comes to unit testing. So I would have to wag my chubby finger at both Cisco and Objective Systems and question their approach to QA in their development cycle. This isn’t rocket science people!