fware

Ransomware On Your Website – Is It Possible?

fware ransomware

Ransomware on a website?

Ransomware is popularly thought to affect only PCs, mainly containing older versions of Microsoft Windows, through phishing of login details. Actually, nothing is farther than the truth.

In fact, ransomware can be introduced even into Linux-based web servers / websites without using any phishing techniques, and even if they are behind a firewall.

The above image displays the new homepage of a website on cPanel shared hosting recently locked by ransomware. The image below is a listing of the ransomware-encrypted website files as seen via an FTP client.

fware ransomware file listing

How did the ransomware get in?

Servers are computers available on the public Internet and are required to serve information via multiple protocols such as HTTP/HTTPS, FTP, SSH, etc. This also creates multiple points of entry for attackers in addition to poorly secured entry points in web apps.

In this case, the website had allowed file uploads into directories that (carelessly) had execute file permissions enabled for everyone. In Linux this is the 777 permission. This allowed an attacker to upload the fware encryption PHP code to the website and then cause the code to execute via a web browser call.

What would you do if this happened to you?

How would you be affected if you woke up one morning to see your website that wasn’t available anymore? Even after paying the ransom there is no guarantee of receiving the decryption key and getting back your website files and data.

Luckily, in this case, the webmaster (website manager) for this website had already enabled automated website backups and was able to restore the website quickly. Most webmasters agree frequent automated backups are the best defense against total website loss. So does your website have automated backups?

 

DROWN logo

DROWN Attack – 33% HTTPS servers at risk

DROWN stands for “Decrypting RSA with Obsolete and Weakened eNcryption”

Websites, mail servers, and other TLS-dependent services are all at risk for this kind of attack, including many popular websites. It allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data.

drown attack scenarios

Next Steps For Server Admins

Learn more and check if your servers are affected.

New PCI Standard: Disable SSL 3.0 & TLS 1.0 by June 2016

PCI DSS 3.1 SSL TLS

Image courtesy Security Metrics blog

New guidelines dictating the requirements for PCI Compliance, version 3.1 of PCI Data Security Standards (PCI DSS), were released in April. These guidelines must be followed for all companies who take payments over the Internet. A key part of the new PCI DSS are stricter requirements around the use of TLS (SSL).

PCI DSS v3.1 states that SSL 3.0 and TLS 1.0 “can no longer be used as a security control after June 30th, 2016.” This means that disabling these protocol versions is required in order to be compliant with handling sensitive cardholder data.

Any time we discuss protocols, we like to remind our readers that the true name of the modern protocol is Transport Layer Security (TLS), not SSL. The most recent version of the protocol is TLS 1.2, and the last version to be released under the name “SSL”, was SSL 3.0 way back in 1996.

After the POODLE attack discovered late last year, SSL 3.0 was effectively retired. The newest versions of most modern browsers no longer support SSL 3.0, and everyone should check their servers to make sure they have disabled support for that insecure protocol.

Disabling protocol versions is easy – once you locate where your server stores the configuration settings for SSL, it takes less than a few minutes to update. The hard part of meeting these requirements will be to make a risk assessment of your user base to determine if removing TLS 1.0 support will be problematic.

Remember that PCI DSS dictates technical requirements and procedures for servers that are directly handling user payment information, personal records, and administrative access. So if you do not take payments directly – but instead use a provider such as Paypal, Authorize.net, or Square, you may not have to be PCI Compliant. For companies who do handle payments directly, it’s not necessarily required to make these changes network wide. For many networks and companies this will ease compliance.

So, if you are affected by these changes, how much time do you have?

The deadline for ending support for SSL 3.0 and TLS 1.0 is June 30th, 2016, just about a year from now. However this comes with some caveats. “Effective immediately, new implementations must not use SSL or [TLS 1.1],” and existing implementations must have a “formal Risk Mitigation and Migration Plan in place.”

So while the hard deadline on abandoning these old SSL protocols is about 12 months away, the easiest option will be to migrate from these protocol versions now.

The PCI Security Standards Council suggests you only support TLS 1.2 for optimal configuration. This is because all protocol versions except for TLS 1.2 are vulnerable, though you may find users’ devices do not support this version so for practical versions this may not be possible. If you do keep TLS 1.1 enabled, make sure you optimize your configuration to avoid potential security flaws.

If you or your clients handle user data which requires PCI compliance, you will want to consult directly with their new PCI DSS v3.1 Standards, available here:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

A summary of the changes specifically affecting SSL are available here:
https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf