Simply Hosting!

Main menu

Post navigation

The WannaCry ransomware worm, aka WanaCypt0r aka WCry, today spread rapidly over the internet. The worm targets mainly machines in Russia, Ukraine, India and Taiwan initially. However it has a footprint in about 74 countries. Once infected, a machine will also attempt to infect other clients on the same local network. So if you have a machine infected, isolate it immediately to prevent it from spreading.

WannaCry is installed on Windows computers by a worm that spreads across networks by exploiting a vulnerability in Microsoft’s SMB file-sharing services. It specifically abuses a bug designated MS17-010 that Redmond patched in March for modern versions of Windows – unpatched systems, or ones running legacy versions such as Windows XP, are therefore vulnerable and can be attacked.

This was released back in April as part of a leak regarding NSA that publicize the bug and a tool used to exploit it. Hackers have now made use of the tool and strapped it to ransomware.

Further Details are below:

In March, Microsoft released a security update which addresses the vulnerability that these attacks are exploiting.

For customers using Windows Defender, Microsoft has released an update earlier today which detects this threat as Ransom:Win32/WannaCrypt. Make sure all antivirus / anti-malware software are up to date. Clients running anti-malware software from any number of security companies can confirm with their provider if they are protected.

Clients should consider blocking legacy protocols on their networks such as SMBv1.

Clients who do not need to mount to network shares should considered disabling by default the SMB service. For newer versions of Windows, you can specifically remove SMBv1 by removing the feature.

This impact systems as old as Windows XP. So all your machines including desktops could technically be at risk.

All our Managed Clients running Windows are already protected as we regularly update your system as patches become available.

If you have any questions regarding this exploit or how to implement some of the recommendations above, please feel free to open a ticket with our support: https://www.sprintserve.net/support.

If you are using Apache / Cpanel / WHM, you may have found that recently you are having issues installing certificates from Comodo InstantSSL.

When you order the certificate, you would receive your certificate in a zipped file, together with 3 other certificate files. Comodo do not really explained clearly how to use the files. In order to create the CABundle, you would need to add them in this order in one file:

Late last week, a new SSL bug was discovered by Google Research Labs. Simply put, due to the large number of protocols, clients and servers, most clients will start with the highest supported protocol and downgrade accordingly in order to be compatible to older servers. The weakness happens in SSLv3 which is 18 years old which can allow an attacker with sufficient computing resources to guess the encrypted data. For the more technical reader, here’s a link with more details.

While exploiting this bug is fairly difficult due to the large amount of computing resources needed, once the exploit was known, our team started putting together an action plan within hours. We started off implementing a patched version of OpenSSL on all servers which support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

However we did not stop there. We continue to refine our response and came out with methods to disable SSLv3 on all the main servers on our clients and our own servers. This includes:

Apache Web Server

WHM / Cpanel Control Panel

POP3 / IMAP Mail server

Exim SMTP server

This ensures that SSLv3 is no longer available to be exploited even if there’s some still unknown method to exploit it.

While this may break support for older clients, we estimated this to be of very limited impact. The security advantages also fair outweighs the disadvantages. If in doubt, please feel free to contact our support team.

What is it?

Chances are, you’ve already heard about the recent discovery of what’s being called the “Shellshock” exploit in GNU Bash. This is a vulnerability that existed in Bash through versions that have span 25 years. However as it is a little used function, the exploit did not come into light till this week. The vulnerability can result in remote execution of arbitrary code.

Bash is widely used by many popular Linux distributions and Mac OS X. This means that the exposure surface is extremely large. As the bug has been in the wild for many years, it is unknown if this exploit have been used in the past.

Critical instances where the vulnerability may be exposed include:

Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.

Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities.

Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.

Exploit servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Am I affected?

For servers running RHEL/CentOS 5/6/7, our team was aware of the issue the same day it was made public on 24th September. Our team worked through the night to ensure the patch was applied within hours after it was released. The first patch was incomplete and we applied a 2nd patch the next day, once again within hours after the patch is available.

With respect to the above potential issues, we will like to explain how our managed servers using our default security policies are unaffected. We have kept it general on purpose:

Most of our servers do not have mod_cgi in use. On top of that, we do not run PHP under CGI wrapper. Further to that, we restrict some key functions of PHP that would have made this a more dangerous bug such as system / exec.

Most of our servers do not allow external shell access. For those that do, we do not use Bash as the shell. There are also other policies limiting access to only authorized users.

We disable all unnecessary services including DHCP, etc during setup.

Please refer to response 2 above. Another exposure surface we can foresee is the use of cron which may allow some users to put malicious commands. However, we currently do not run these jobs under Bash as well, but is using a separate shell.

If you have a specific area or question you like to clarify, please feel free to open a ticket with us. We will be happy to address any concerns directly for our clients.

Have you ever wondered how you can check the validity of a certain SSL certificate from shell / SSH? There is an useful script that we typically use on our end. If the location provided below is no longer available, please feel free to contact us as we have a copy.

wget http://prefetch.net/code/ssl-cert-check -O /PATH/TO/SAVE/FILE

Replace “/PATH/TO/SAVE/FILE” wieth your own preferred path of choice e.g. “/usr/local/src/ssl-cert-check”. We will now use this path in our example.

Have you ever run the command “history” in bash and notice how inadequate that seems by default? You have no idea what date or time a particular command is ran. This makes troubleshooting difficult especially if you are trying to track where certain things go wrong.

To correct this, you can simply add this line to your bash configuration. If you wish to make this system wide and implement for all users:

echo "export HISTTIMEFORMAT='%F %X '" >> /etc/bashrc

If you wish to only implement it for the currently logged in user:

echo "export HISTTIMEFORMAT='%F %X '" >> ~/.bash_profile

There’s lots of ways you can customize your shell to be more useful to you, and this should whet your appetite and get you started.

In our work with clients, we do a lot of server management and security hardening on the servers before it’s released to the clients. One of the first things we typically work on is to ensure SSHd is secured. The reason is that any kernel root exploit will be made easier with shell access.

This tutorial is not meant to be all encompassing, although we will cover a few key areas. We will use Redhat / CentOS Linux distribution as an example and file paths will vary depending on the distribution. We will also use “nano” as the text editor in the examples.

Change the SSH port

While security by obscurity is heavily criticized in some quarters, the truth is due to the time taken to scan all the ports, unless it’s a targeted attack, this step should immediately stop scanners dead in their tracks.

nano /etc/ssh/sshd_config

Change:

#Port 22

to (Replace “NEW_PORT” with your port of choice)

Port <NEW_PORT>

Allow only strong protocols

Version 1 of the SSH protocol has many weaknesses, of which it’s out of scope of this article to discuss. But we will be disabling it.
Change:

#Protocol 2,1"

to

Protocol 2

Allow only strong protocols

Version 1 of the SSH protocol has many weaknesses, of which it’s out of scope of this article to discuss. But we will be disabling it.
Change:

#Protocol 2,1"

to

Protocol 2

Disable Password Authentication

We advise that you consider using only key authentication with your server. This means that even if someone someone get your password, your server will continue to be secure. If you are unsure about how to generate a SSH keypair, do refer to our quick tip here.

In our work for our clients, we are commonly asked to help reset the admin password to WordPress. There are numerous ways to do this, but if you do have SSH access, the easiest way is if you simply use the loss password function.

Using the Loss Password Function

If you know your username and the email account in your profile, you can use the “lost password” feature of WordPress.

Sprintserve NET is happy to announce the immediate availability of multiple PHP versions. We will make available PHP 5.2, 5.3, 5.4 and 5.5, with the current default being PHP 5.2. No action is required from you if you are happy with the current version of PHP. However we strongly encourage to test your scripts with one of the newer PHP versions.

What do I need to know:

The current default PHP version 5.2.17 remains the default. No action is needed if you want to continue using this version.

The current alternate versions supported are PHP 5.3.28, 5.4.28 and 5.5.12.

We strongly encourage all clients to upgrade to a newer PHP version as PHP 5.2.17 and 5.3.28 has been deprecated. We expect to change the default version in the near future as it is no longer supported by Cpanel.

Please note that there are major changes between the different versions, and that it is the client’s responsibility to ensure that their scripts are compatible with the various PHP versions.

Upgrading from PHP 5.2 to 5.3: http://php.net/migration53

Upgrading from PHP 5.3 to 5.4: http://php.net/migration54

Upgrading from PHP 5.4 to 5.5: http://php.net/migration55

How do I enable PHP 5.3, 5.4 or 5.5:PHP 5.3
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php53 .php
</IfModule>