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.
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.
What is it?
Chances are, you’ve already heard about the recent discovery of what’s being called the “Heartbleed” bug in OpenSSL. Basically, this is a vulnerability that existed in OpenSSL for around 2+ years. The vulnerability caused by a gap where encrypted information could potentially be leaked out to hackers. It is important to note that this is NOT due to a flaw in SSL, but rather the platform and implementation of the latest batch of OpenSSL updates.
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
Given the widespread use of OpenSSL on the internet as the implementation for SSL, and the fact that the bug has been in the wild for years, this means that it is possible that a lot of sensitive information may have been stolen by hackers.
Am I affected?
For servers running RHEL/CentOS 5, the version of OpenSSL used is not affected. For servers running RHEL/CentOS 6, the bug was patched the same day the bug was made public. For all servers managed and hosted with us, we have automatically patched the bug the day it was made public on affected servers. However this does mean that you are not vulnerable to the issue. The key used for your SSL certificates may have already been stolen in the time the bug is in the wild.
For safety, if you are running RHEL/CentOS 6, you are recommended to rekey your domain and request for a reissue of the certificate. If you ordered the certificate from us, we will be regenerating the keys and reissuing the certificates automatically as well.
Personally if you have changed your passwords on any affected sites over the past 2 years, you are encouraged to confirm that the affected site have updated their certificates and change your passwords again.