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 https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
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 email@example.com 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 https://access.redhat.com/security/cve/cve-2016-5195. 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 https://lists.centos.org/pipermail/centos-announce/2016-October/thread.html.
In the meantime, advanced users may wish to mitigate the vulnerability by disabling ptrace functionality in the kernel as explained at https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13. 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 '
Users of supported Debian or Ubuntu distributions are also affected, unless they are running one of the following kernel versions (or later):
If your server is not running one of these kernels, you will need to update by running '
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 '
You can determine the version of the currently running kernel on your server by running '
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 https://support.cwcs.co.uk/.
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 a bewildering account of incompetence and how he exploited a flaw within the nic.as domain registry which allowed him to take over any .as domain because they (nic.as) 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:
McDonald’s Australia (macc.as)
Large educational establishments such as the University of Texas (utex.as)
American Samoa government institutions including the Department of Commerce (doc.as), and the Office of the Governor (gov.as)
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!
Now that you’ve recovered from that ride of misery, let MR ISECGUY show us the way…
It turns out by simply Base64 encoding a URL of the domain and subsequently a business’s web presence you wanted to control and pasting the string to the nic.as URL i.e.
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?
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 nic.as 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:
So the vulnerability has been fixed but the owners of the .as domains still have not been contacted by nic.as 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  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  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  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  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 . Maktub.
Phishing  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 ), to encryption and malware design It really is an impressive extorting machine .
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  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 ) 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 https://debian-handbook.info/browse/stable/sect.dist-upgrade.html 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 https://wiki.debian.org/LTS/Using 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 »