First of all I should state that as with any vulnerability, particularly one which has a potential remote vector, you should ensure your systems are patched – and keep eyes out for further patches coming down the line as the first few patches were only partial fixes as they were rushed out of the door.

However to read websites like BBC News, which have headlines like “‘Deadly serious’ new vulnerability found”, suggesting that half a billion computers could be affected, you would think the world was about to cave in.

In short it’s not. Its a serious vulnerability, but to my mind at least it’s not “a bigger deal than Heartbleed” as some researchers are saying.

Here is why:

A quick recap. The Heartbleed bug essentially rendered useless the encryption between end users and any website or VPN using OpenSSL derived encryption. This included Google, Amazon, Apple, Twitter, Facebook, Yahoo and tens of thousands of others. These are the websites which store personal data, emails, credit card numbers, payment history and other information for hundreds of millions of users. Users in WiFi hotspots around the world were at risk of compromise, as well as any GCHQ and NSA  or other wiretaps that may exist.

The bash “shellshock” vulnerability has 4 main attack vectors:

1. Internet server based remote attack
2. Rogue DHCP server based attack
3. SSH “Forced Command” environment escalation
4. Local privilege escalation

Taking each in turn, I will explain them, and what the impact would be.

Internet Server based remote attack: This could be a web server using a “Common Gateway Interface” (CGI) to run scripts on a website, or could be a mail server running a spam checker. Additionally the default shell on the server would need to be “bash”. This is not the default for Solaris, BSD systems, nor Debian or Ubuntu Linux based systems. Additionally websites using CGI via libraries like FastCGI  or executing scripts via mod_php/mod_wsgi are not vulnerable as environment variables are not passed through to the end scripts. Typical websites that would fit into this category would be web forums, and simple websites with an email submission form.

For a web server that is vulnerable, it is trivially easy to exploit it, and there are hundreds of thousands if not millions of websites which are vulnerable. However the vast majority of these will be low traffic websites. For example according to wikipedia there are only a handful of web forums which have more than a million users, of which only a few if any will have been vulnerable to “shellshock”. So the impact of any single website being exploited would be low to moderate.

Rogue DHCP server based attack: The DHCP client that is commonly used for automatic IP configuration on Linux based systems has proven vulnerable to shellshock, as it shells out to configure the network, it is possible for a rogue DHCP server to be used to gain remote root access to a client. An example of where this could happen is on an open WIFI hotspot – however as only Linux systems which have bash as their default shell are vulnerable, only a small fraction of users would be at risk – i.e. OSX, Windows, and Debian/Ubuntu users would all be safe in this case.

It could also happen in a data centre, if shared networks were not properly segregated between customers, however the impact of such an exploit would be limited to that network, and the source could be relatively easily traced, this meaning the significance of this is also low.

SSH “Forced Command” environment escalation and Local Privilege Escalation: Whilst there are differences, the net result of both of these vectors is an authorised user obtaining additional privileges to those they have been granted. These are serious as they could result in data breaches, however as they require a user to have access in the first place, they are not of the same severity as one which can be exploited remotely.

In summary: whilst the “shellshock” vulnerability provides a trivial method to exploit a vulnerable web server, the impact of any vulnerability is not high as few websites still using CGI scripts in a vulnerable manner will have significant traffic. The other attack vectors are interesting, but do not place large parts of the internet at significant risk.

However the more serious concern is the hundreds of other exploits which do not hit the spot light in the media, as these are less likely to be patched so quickly. Examples include recent exploits in tomcat and apache httpd which like “shellshock” allow arbitrary code to be executed on remote systems, and are more likely to be in use at large web sites.

I think there needs to be a balance found between raising awareness of serious issues, and overhyping an issue. Some of the claims made for the “shellshock” exploit definitely fall into the sensationalist, overhype book for me.

I don’t have inside knowledge to the ins and outs of each breach, but can talk to my experiences. In the case of Betfair, we were audited to PCI DSS regulations, we had a top team of InfoSec professionals, and we were on top of security patching – contributing useful fixes back to the community.

However a number of config mishaps coincided leaving a window of opportunity of just a few days. That was enough for someone skilled to get inside and gain access to data. Following that incident processes and procedures were updated to prevent a recurrence of that type of breach and action was taken to further improve security.

However as long as companies are home to interesting data they will be targets.

A typical online retailer holds the following information about a customer:

• Name
• One or more addresses
• Payment details for one or more cards
• Possibly data of birth, mothers maiden name or other data as extra security questions.

The question is, how much of the data that they hold do they actually need to?

I spent some time thinking about this toward the end of last year, after attending a TTI/Vanguard regional meeting hosted by Peter Cochrane entitled “The cloud can be inherently more secure than anything that has gone before“. The title was a deliberate provocation, designed to inspire debate amongst the attendees.

The meeting was exciting and enthralling with lively discussion throughout. An interesting highlight was Peter talking about one his actions as CTO for British Telecom, which was to hire a team based outside of BT’s offices, whose sole purpose was to try to break into BT. They wouldn’t provide forewarning, wouldn’t pause during system maintenance, wouldn’t share details of what they would be trying in advance. All they’d do is provide details of how they got in afterwards. The point of this being, to protect against the baddies out there, you need to think like them.

The major takeaway for me on the day though was that how we shop online today is utterly insecure by design.

To buy something online today requires entrusting to a third party all the details which are required to take money from us time and again.

We trust that the encrypted connection between them and us is secure, and cannot be breached. The Snowden leaks and Heartbleed, show us that this is not always the case.

We also trust that the party we are interacting with is careful with the data. The countless breaches over the years, show this not to be always the case.

We rationalise it because we’ll get the money back if our cards are stolen and yet often forget its our identity being taken too.

The chart below shows the number of accounts being exposed through data breaches over the years is on a definite trend upwards, with the disclosures so far this year indicating that 2013 was unfortunately no anomaly.

So what can be done? Do online retailers really need to know everything about me? Do they need to store data which thieves will target? Most of the time I have deliveries from online retailers sent to my office, so why do they need to know my home address? Equally do they really need to know my credit card number?

The answer most will give, is “Of course, they need your home address, as its your billing address, so they need to prove you are who say you are, and they need your credit card number to take payment.” However that is just how the systems are designed today. To take a popular variant of a Grace Hopper quote:

“The most damaging phrase in the language is: ‘We’ve always done it that way’ “

Her actual words were slightly different but the intent is the same as the popularised variant. Humans are allergic to change and so just keep trying to refine an existing system rather than thinking about ways of changing the system. After Peter Cochrane’s talk I spent some time thinking about how the system could be changed. The premise is fairly simple although lack of time since then hasn’t provided the opportunity to expand it beyond the idea phase.

What is required for online merchants is a secure, definite way to verify the identity of a customer and receive payment. They might like to have more data for analytical and marketing purposes, but fundamentally to conduct a transaction that is all which is required.

There are some partial solutions to this problem available such as PayPal which abstract your billing address from a merchant and allows you to control the funds that get sent. However it’s not ubiquitous and when faced with an additional step in the checkout phase, and being charged additional fees for using PayPal many customers don’t bother. They want the convenience of saving their payment details with a vendor and having one step checkouts.

Attempts at offering Virtual Debit Cards – one time use credit cards – have also not reached significant usage volumes. This is primarily due to falling down on the ease of use hurdle once more and doesn’t address the concern of protecting the customer’s identity.

What is required is something which is both easy to use and ubiquitous. What I’ve been thinking about on this front is some form of distributed escrow to be developed as a secure payment standard, which gets built into web browsers, as an extension to a HTML standard.

To have some global payment services hosts, which act as proxies to banks payment gateways. In my vision these would be hosted by a number of relatively trusted parties, such as Wikimedia, ISC, Apple, Microsoft, Google, Amazon, Paypal etc. They would receive a fraction of a penny per transaction, thus ensuring that it would worthwhile to host without pushing up the cost of transactions for the consumer.

Then for a online transaction, rather than a customer entering their credit card details into a webpage, and submitting that to a single website, instead they’d enter the details into their facet of their web browser with the website providing a transaction ID, and merchant ID too.

The browser would then encrypt and shard these details across transmissions to three or more of the global payment services hosts. These hosts would then forward the shard they received to your bank who would assemble, verify and process the data and send back an affirmative or negative response for the transaction.

The merchant would also be connected a global payment services host, and would receive a message with the transaction ID detailing whether to proceed with the transaction or not. For orders requiring shipping a delivery address could then be submitted to the merchant.

With careful browser design and integration the above could be just as easy to use as current systems and would truly limit the impact of a security breach at your favourite online retailer.

This way to conduct widespread theft of identity and or payment details either your bank needs to be hacked; multiple providers need to be concurrently hacked; or a widespread glut of malware needs to take hold. Of these the most likely one – malware – is a threat we already live on today. The others whilst still possible are significantly less likely, so the end result should be significantly boosted online security for no additional user inconvenience.

It seems like a plausible solution to me. Could it work?

Edit to add: The Apple announcement on Sep 9th with regard to ApplePay addresses many of the concerns I raised – taking a similar approach with regard to ensuring that the merchant doesn’t require to store your name and payment details. No doubt an Apple solution will tick the box of being easy to use – the two caveats I see are that it’ll only work for Apple customers – a sizeable chunk of the population for sure – and that it requires trusting Apple implicitly, and whilst they will be taking the security of this very seriously, it will be quite a big basket of eggs…