RSS Feed
Latest Updates

Remote code execution vulnerabilities have been discovered in the popular PHP mail sending libraries PHPMailer and SwiftMailer. Improper validation of email addresses potentially allows an attacker to execute arbitrary code as the user running PHP. These vulnerabilities could be employed for example to send out spam from the server, or to perform denial of service (DoS) attacks against other internet users. Combined with a local privilege escalation vulnerability or poorly set file permissions, they could also be used as a stepping stone to further compromise the server.

The vulnerabilities are fixed in PHPMailer version 5.2.20 and SwiftMailer version 5.4.5. It is highly recommended that all users upgrade to these or later versions as soon as possible. Note that an initial fix for PHPMailer, released as version 5.2.18, was found to be incomplete, so any server running this or version 5.2.19 is still vulnerable.

PHPMailer is used in many popular web applications, including Wordpress, Drupal and Joomla. If you run these or any other applications that include PHPMailer, you should install any updates as soon as they become available. If in doubt, contact the vendor and ask if they are vulnerable to any of the following CVEs, and if fixes are available:


More technical details of these vulnerabilities can be found
 by clicking on the relevant CVE above, or alternatively if you’d prefer to discuss this or any concerns with our support team, please call 0808 133 3247 or submit a support ticket.


CWCS advisors and support are on hand 24/7 365 days a year to assist with your enquiry.

Read more »

ICANN Domain Transfer Policy Update - 1 Dec 2016
Posted by Julian Harse on 30 November 2016 01:12 PM

On December 1, 2016, ICANN will enforce a new transfer policy that modifies the process of changing domain ownership from one registrant to another. The implementation of the policy is being imposed on all registrars including CWCS.

Up until now, this policy only covered domain transfers between registrars. The new policy now also covers the process of changing ownership of the domain from one entity to another (registrant to registrant). Now, every time a change of registrant takes place, a series of confirmation and approval emails are triggered. I.e. updates to a registrant’s first name, last name, organisation and email address and will require email approval before going into effect.

For more information, please see our FAQ.

Read more »

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 »