RSS Feed
Latest Updates
Dirty CoW - CVE-2016-5195
Posted by Thomas Foster on 21 October 2016 02:17 PM

A vulnerability has been discovered in the Linux kernel that potentially allows anyone with access to a local user account (either legitimately, or by exploiting e.g. in an insecure web application) to elevate their privileges to root, and thus take over the entire system. The vulnerability has been assigned the CVE (Common Vulnerabilities and Exposures) identifier CVE-2016-5195, and has been nicknamed Dirty CoW (CoW stands for Copy-on-Write, and refers to the part of the kernel in which the vulnerability was discovered). Red Hat have rated this vulnerability as Important, and an exploit has reportedly been seen "in the wild".

More (technical) information about the vulnerability can be found at

CWCS will install updates for managed servers when they become available as part of our usual security patching routine. Unmanaged customers are responsible for keeping their servers up-to-date themselves, however if you feel you're unable to do this will be able to apply patching for Dirty CoW as paid a special request. If this is a service you require please contact our sales department or 0800 1 777 000.

Users of Red Hat Enterprise Linux and CentOS versions 5, 6 and 7 are affected, although exploits that have been seen so far are reported not to affect versions 5 and 6. Red Hat have not yet released fixed versions of their kernel packages. When they do, it will be announced at These packages will be made available to CentOS users shortly thereafter. This will be announced on the CentOS-announce mailing list, which can be viewed at

In the meantime, advanced users may wish to mitigate the vulnerability by disabling ptrace functionality in the kernel as explained at However, please make sure that you have read and understood the caveats mentioned there before doing so.

Once fixed packages have been released, users of these Operating Systems should install them by running 'yum update' via SSH, and then reboot by running 'reboot', or using Tools & Settings -> Server Management -> Restart Server in Plesk, or System Reboot -> Graceful Server Reboot in WHM. Please note that you must update and then reboot; updating alone is not sufficient.

Users of supported Debian or Ubuntu distributions are also affected, unless they are running one of the following kernel versions (or later):

  • Debian 7 (Wheezy) - 3.2.82-1
  • Debian 8 (Jessie) - 3.16.36-1+deb8u2
  • Ubuntu 12.04 LTS (Precise Pangolin) - 3.2.0-113.155 or 3.13.0-100.147~precise1
  • Ubuntu 14.04 LTS (Trusty Tahr) - 3.13.0-100.147 or 4.4.0-45.66~14.04.1
  • Ubuntu 16.04 LTS (Xenial Xerus) - 4.4.0-45.66
  • Ubuntu 16.10 (Yakkety Yak) - 4.8.0-26.28

If your server is not running one of these kernels, you will need to update by running 'apt-get update && apt-get dist-upgrade' via SSH, and then reboot by running 'reboot', or using Tools & Settings -> Server Management -> Restart Server in Plesk. Please note that you must update and then reboot; updating alone is not sufficient.

Ubuntu users who are running an LTS enablement stack will need to ensure that their kernel version is still supported. This can be determined by running the 'hwe-support-status' command (see for more details).

You can determine the version of the currently running kernel on your server by running 'uname -r' via SSH. Alternatively, WHM users can find this information under Server Status -> Server Information -> System Information. For example, the following is from a server running the 2.6.32-642.4.2.el6.x86_64 kernel:

Linux 2.6.32-642.4.2.el6.x86_64 #1 SMP Tue Aug 23 19:58:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

This vulnerability affects all versions of the Linux kernel since 2.6.22 (released in 2007) until it was fixed on 18 October 2016, so if you are running a distribution not mentioned above, then it is almost certainly still vulnerable, but fixes may not be made available. Users of End Of Life distributions (i.e. Red Hat Enterprise Linux or CentOS before version 5, Debian before version 7, or Ubuntu versions other than 12.04, 14.04, 16.04 or 16.10) should contact customer services to discuss migrating to a newer platform as a matter of urgency.

If you have any questions, please do not hesitate to contact our support team on 0808 133 3247, or via

Read more »

Flaw allowed anyone to modify and take control of ANY .as domain
Posted by Thomas Foster on 09 May 2016 08:59 AM

A few days ago a security researcher going by the ominous handle “ISECGUY” posted[1] a bewildering account of incompetence and how he exploited a flaw within the domain registry which allowed him to take over any .as domain because they ( allowed you view not only the entire domain registration information but also the plain-text passwords of domain owners and, administrative and technical contacts but  it does not stop there...

Who cares? Who even uses the .as TLD?

Well, here’s a short list:

Adidas (

Bose (

Flickr (

McDonald’s Australia (

Opera (

Twitter (

Large educational establishments such as the University of Texas (

American Samoa government institutions including the Department of Commerce (, and the Office of the Governor (

If you thought, it ended at just plain-text passwords and domain information then you better buckle up brother because this journey of insecurity has just begun and it’s about to kick into overdrive.

The flaw also allowed you to edit the Domain Name System (DNS) records for the domains too and here’s the best part… the cherry on the top. You could also delete domains for the registry!

But how?!

Now that you’ve recovered from that ride of misery, let MR ISECGUY show us the way…

It turns out by simply Base64[2] encoding a URL of the domain and subsequently a business’s web presence you wanted to control and pasting the string to the URL i.e.[BASE64 HERE]

That would take you straight to the riches as we previously discussed above.

Why base64 was used we do not know, maybe as an early 90s URL obfuscator perhaps?

The fallout

So now we’ve talked about what happened and how, the aftermath of this very responsible disclosure is rather amusing.

It’s fair to say that were not too pleased about being made aware that their domain management system was vulnerable.

Which is laughable as it’s their responsibly to make sure their system is as secure as possible.

To prove that MR ISECGUY did indeed contact them first before disclosing the vulnerability he posted a disclosure Timeline with his original post:

  • 21st January 2016 09:13 – Responsible disclosure to AS Registry
  • 23rd January 2016 07:03 – AS Registry “noted” concern, but dismissed severity
  • 2nd February 2016 17:36 – AS Registry finally acknowledge problem and severity
  • 24th February 2016 19:31 – AS Registry report flaw has been resolved & customers in the process of being notified
  • As of 25th April 2016 09:00 – .as domain owners, technical, administrative, and billing contacts have still not been notified by the AS Registry
  • 25th April 2016 09:00 – Public Disclosure

So the vulnerability has been fixed but the owners of the .as domains still have not been contacted by letting them know that their domains records may have been changed.

I will leave you with this fantastic quote from Stephen Deerhake from the AS Domain Registry commenting on the great work of MR ISECGUY.

Responding to the allegation, Stephen Deerhake, for the AS Domain Registry said today:

"The report is inaccurate, misleading and sexed-up to the max".




Read more »

Maktub - A Love-hate Relationship
Posted by Thomas Foster on 12 April 2016 08:27 AM

Maktub a new nasty ransomware making the rounds that shocked security researchers and also swooned them with its complexity. It’s a love-hate relationship that ensures both ups and downs will be had.

Bring me up to speed

Up until now the vast majority of ransomware has been a mixture of fake FBI/made up law enforce agency [1] warnings about your “questionable” internet history and then encrypting all your files not only on your machine but across network shares and you had to pay to get your files back, at first sending money through a payment processor, but then these crypto savvy crooks demanded Bitcoin and directed their victims to install Tor to where  a .onion addresses [2] awaited their Bitcoins to in-return hand them a decryption key.

This was and still is an extremely successful method for the cyber criminal to profit off; so much so in fact that the real FBI released a statement telling small businesses [3] that “it’s best to pay up” when your small business is hit by ransomware as there’s a “good chance” you’ll get your data back.

What makes Maktub different?  

It knows where you live.  According to the BBC [4] some of its Radio 4 employees were sent personalized phishing emails that included their real home address and demanded they cough up hundreds of British pounds. The emails also included a link to where the recipients of these emails could pay up but… that link included a one-way ticket to crypto-city [5]. Maktub.

Phishing [10] to spread malware isn’t new, but the way these emails are put together and cleverly disguised show that the true senders know what they are doing.

If you imagine Maktub as a sea worthy vessel then it’s got a top-notch crew made up of specialists in their field from Phishing to FUD’ing (Fully UnDectable [7]), to encryption and malware design It really is an impressive extorting machine [6].

Maktub doesn’t just encrypt your files and call it a day. It fully embodies a typical ransom with raising demands such as the amount you have to pay in order to get your data back they add an additional cost for every day you miss a payment [8] it’s one notch of cruelty away from breaking your legs.

That’s what makes Maktub different – spear phishing, a well-written application, annoyingly solid crypto (no third party cut and paste [9]) and a robust payment mechanism with raising demands.












Read more »

End of Life for Debian 6 "Squeeze"
Posted by Julian Harse on 08 March 2016 12:36 PM

As of 29 February 2016, long term support for Debian GNU/Linux version 6 (codename "Squeeze") has come to an end, meaning that security updates will no longer be provided. We therefore recommend that any users of this distribution upgrade to a supported release as soon as possible in order to ensure the continued security of their server(s).

Debian users can check what version they are running by executing the following command via SSH:

# cat /etc/debian_version

If you are not running Plesk, it is possible to upgrade from one Debian release to the next. See for instructions. However, please be aware that software versions will change and any software that has been custom-compiled or installed from third-party repositories may stop working, so we wouldn't recommend this for most users. Customers may also request a format and reinstall of their server with the latest operating system. Alternatively, you can contact our customer services team to arrange a migration to a new server.

Under no circumstances should Plesk users attempt an in-place upgrade, as Plesk does not support this and it will almost certainly cause problems.

Debian 7 "Wheezy" will continue to be supported until 31 May 2018.

However, from 26 April 2016, users of this release will have to enable the wheezy-lts repository in order to continue receiving security updates. See for more details.

Likewise, Debian 8 "Jessie" will be supported until the end of April/May 2020, but users will have to enable the jessie-lts repository from May 2018.

Read more »


A vulnerability has been found in Linux kernels >=3.8 which could allow a local user to gain root access if combined with an exploit that allows an attacker to run arbitrary code (e.g. through a web application like Wordpress or Joomla). See below for a list of affected distributions.

CWCS recommends customers immediately update their systems if a patch is available/required. As this requires an update to the kernel, it will be necessary to reboot the server after patching.

CWCS will apply applicable updates for customers with Gold and Platinum management, customers will be notified when the patches have been applied to schedule rebooting. If you are interested in learning more about our management options, please contact your account manager on 0800 1 777 000 / +44 115 740 1234.

Affected Distributions


CentOS 5 and 6 are not affected, as they run earlier kernels. CentOS 7 is affected, and will be addressed in a future patch. The CentOS-announce mailing list is the place to keep an eye on for when CentOS release their patch:

[Update 26/01/2016]: a patch for CentOS 7 is now available:


Debian 8 (jessie) is affected, and a patch has already been released:

The fixed kernel version is 3.16.7-ckt20-1+deb8u3. Earlier Debian releases are not affected.


For Ubuntu, the situation is complicated by their LTS Enablement Stacks:

( which allow kernels from later releases to be run on earlier ones.

- Anything before 12.04 (precise) is EOL, but is not affected.

- 12.04 may be affected depending on the kernel version:

     * 12.04 without any linux-generic-lts-* package or with linux-generic-lts-quantal is not affected.

     * 12.04 with linux-generic-lts-raring or linux-generic-lts-saucy are affected, but these kernels are EOL, so will need upgrading to linux-generic-lts-trusty.

     * 12.04 with linux-generic-lts-trusty is affected, fixed in version 3.13.0-76.120~precise1 (

- 12.10 is EOL, but not affected.

- 13.04 and 13.10 are affected, but EOL.

- 14.04 is affected:

     * 14.04 without any linux-lts-* package is affected, fixed in version 3.13.0-76.120 (

     * 14.04 with linux-lts-utopic is affected, fixed in version 3.16.0-59.79~14.04.1 (

     * 14.04 with linux-lts-vivid is affected, fixed in version 3.19.0-47.53~14.04.1 (

     * 14.04 with linux-lts-wily is affected, fixed in version 4.2.0-25.30~14.04.1 (

- 14.10 affected, but EOL.

- 15.04 is affected, fixed in version 3.19.0-47.53 (

- 15.10 is affected, fixed in version 4.2.0-25.30 (

Read more »