Your online success is largely based on perception. The good news is you have control over the image you project to website visitors. The bad news is you may not be putting your best web presence forward. We’re here to change that with a quick non-techie primer on SSL/TLS certificates. Let’s Cover the Basics SSL/TLS…
When a user connects to your Magento store, they connect over HTTPS, a secure protocol that uses an SSL certificate to encrypt data sent between the shopper’s browser and the server that hosts the store. Without HTTPS, it is possible for a third-party to intercept the data, putting the shopper and the store at risk. But shoppers aren’t the only people that might need to access your store and its “front-entrance” isn’t the only way in.
In some cases, making a change to a store may require a developer or other professional to connect using a service like FTP. FTP is an old protocol that is often still used to upload files to a server. It doesn’t have any built-in encryption, so data is sent in the clear. There are several services a dedicated server hosting client might want to make available, but that are inherently insecure. Usually, insecure services like FTP are blocked by a firewall that prevents anyone from accessing them, but that may be inconvenient.
Retailers and publishers often work with third-parties such as design agencies or teams of outside developers. Remote employees may need to connect to the store while they’re in an untrusted location like their home or a coffee shop. Without a VPN, that’s a bad idea because sensitive data is sent over WiFi networks and the internet in the clear. It is trivially easy for a bad actor to intercept it, which is why we make OpenVPN available on dedicated server Magento and WordPress hosting plans.
The “VPN” in OpenVPN stands for virtual private network. A virtual private network provides the same protection as HTTPS to services that aren’t usually encrypted. When someone needs to connect to a store using FTP, they first connect to the virtual private network. You can think of the VPN as a tunnel through which other data is sent. That data is encrypted using similar techniques to the SSL-based encryption that HTTPS uses.
Once connected to the server’s virtual private network, the user can then log in over FTP and upload their files. The data they send will travel over the secure connection managed by the virtual private network. A man-in-the-middle attacker will not be able to intercept or alter the data.
Our WordPress and Magento dedicated server OpenVPN service is certificate-based, rather than credential-based, which means third-party users will need to have the relevant certificate on their machine. They won’t have to remember or use a password.
We make OpenVPN available on select WordPress dedicated server and Magento dedicated server accounts to protect hosting clients and to make it easier for them to grant secure access to third-parties. All users need to connect to the VPN is an OpenVPN client, many of which are available for free.
We instinctively hide the things we find valuable. It makes sense: if thieves and other bad actors can’t find our valuables, how can they take them? In the digital age, we act on the same instinct. A common security precaution taken by WordPress site owners is to move the login page to a different location; if hackers can’t find the login page, they can’t launch a brute force attack against it. Hiding things, moving them, making it difficult to figure them out — these are examples of security by obscurity.
When I talk to WordPress hosting clients about security, the concept of security by obscurity comes up all the time. Among the common misconceptions I hear is the belief that owners of low-traffic sites don’t need to worry about security — their site is obscure, so it’s inherently secure. In fact, automated scanners regularly check through a large proportion of the web’s IP space looking for vulnerable sites. An insecure site is likely to be hacked even if it’s never had a single visitor. Criminals like sites with large audiences, but they also like any vulnerable site with storage and bandwidth.
An example of the application of security by obscurity from more sophisticated WordPress site owners is changing the default Administrator username because they know criminals will target it.
But there’s a problem with relying on security by obscurity: all it takes is for someone to find what you’re hiding and it’s game over. If your website has a security vulnerability, you might reason that because it’s difficult to find, there’s no point putting in the effort to fix it. If few people visit your site, why update it regularly; even if there is a vulnerability, who is going to be looking for it? If your site is a blog and there’s no obvious financial motive to compromise it, can’t you just cross your fingers and hope for the best?
Security by obscurity does nothing to fix the underlying problem. You might want to continue to use an abandoned WordPress plugin, but if you simply hope that no-one notices you’re using a vulnerable plugin, you’ve done nothing to mitigate the underlying issue. It’s a time-bomb that could go off at any moment.
But as renowned security expert Bruce Schneier points out, “security by obscurity sometimes works.” Security by obscurity isn’t bad per se, but it should be a small part of a site’s security processes. Deleting the “admin” user and choosing a less easily guessed username will make your site a little safer from automated attacks and attacks by inexperienced criminals, but implementing two-factor authentication solves the problem.
Moving your WordPress site’s login page to a non-standard location is likely to confuse bots and reduce the number of brute-force attacks your WordPress site has to cope with, but installing a rate limiting plugin will — for the most part — make life much more difficult for brute force attackers while preventing bots from consuming your site’s resources.
Security by obscurity should not be relied on to keep WordPress sites safe. It should be in the mix, but obscurity is no substitute for security best practices.
Open source projects build on the capabilities of other open source projects. WordPress, for example, depends on Linux, Apache, MySQL, and PHP, among many others — all open source projects that WordPress uses to provide functionality that would otherwise have to be re-created from scratch. The web wouldn’t be what it is today without the ability to reuse code in this way.
The truth is that they don’t know. They trust the system to find and fix vulnerabilities. Outside of strict government and corporate software projects, no one has the time or the money to check the security status of every library used by their software.
GitHub’s Security Alerts are an attempt to address this problem automatically. GitHub knows about the dependency graph (the tree of packages a project depends on) and can cross reference that information with vulnerability databases. GitHub’s Security Alerts use the National Vulnerability Database of the National Institute of Standards and Technology.
The feature is turned on by default for public repositories, and will email project administrators when a vulnerability is discovered. It can be turned on by administrators of private repositories if they so desire.
Over the last couple of months, we’ve seen several incidents of previously trusted plugins being infected with malware by malicious developers. Plugin vulnerabilities are nothing new: developers make mistakes and those mistakes have consequences for security. But many of the recent attacks involved the deliberate introduction of malicious code.
Does that mean we can’t trust WordPress plugins? I’d advocate an approach of trust, but verify — and of making sure you keep yourself apprised of the potential risk.
Earlier this month, Wordfence reported that zero-day vulnerabilities in three popular plugins were being exploited to inject SEO spam into WordPress pages. The Display Widgets plugin was sold to a developer who added a backdoor that was also used to inject SEO spam.
Anyone who had installed these plugins from the official repository would have had their site infected. Attacks of this sort are known as supply-chain attacks. Rather than trying to compromise hundreds of thousands of sites, the attackers focus on software they know is installed on those sites. It’s easier to buy a plugin or compromise a download server than it is to attack the sites directly.
It’s worth emphasizing that this is a rare occurrence. Although a cluster of malicious plugins has been discovered in the last few weeks, it’s a problem that only affects a handful of the tens of thousands of free plugins available to WordPress users.
The WordPress Plugin Repository team has a challenging set of responsibilities: there are over 50,000 free WordPress plugins and it is next to impossible to monitor every one for malicious code. In spite of those obstacles, they do a fantastic job. Malicious plugins are quickly removed from the repository when vulnerabilities are discovered. Given the popularity of WordPress, it’s a testament to the team that this doesn’t happen more often.
But that’s not especially comforting to site owners whose WordPress sites start spewing spam. The sad truth is that any popular project will be targeted by criminals. There is always a risk and anyone running a website has to be aware of that risk.
What can site owners do to keep their sites safe? Regular updating is still the best protection against security risks. Without updates, nothing gets fixed. Beyond that, keep an eye on WordPress blogs that report on plugin security vulnerabilities. Among the best are:
The WordPress team is discussing solutions that integrate security warnings into the WordPress dashboard. There is currently no way to inform site owners when a plugin is removed from the repository for security reasons. Until that initiative yields a useful solution, WordPress site owners might want to take a look at Plugin Security Scanner, a plugin that scans for vulnerable plugins and emails the site owner.
A critical weakness in the protocol used to protect WiFi connections can be exploited to decrypt any data traveling between a WiFi client and the router it is connected to. Some variant of the Krack Attack vulnerability is present in nearly every WiFi device in the world. Unlike many vulnerabilities, this one isn’t the result of a bug in a specific implementation of the software, but a flaw in the WPA2 standard that developers base their implementations on.
The immediate consequence of the vulnerability to Krack Attacks is that WiFi networks cannot be trusted. Most of us are familiar with the idea that open WiFi networks we don’t control should be treated with suspicion — sending unencrypted sensitive data from a coffee shop isn’t a good idea. But the new vulnerability means that even WiFi networks we do control can’t be entirely trusted because of the flawed security protocol.
It’s not easy to exploit the vulnerability: the attackers have to be connected to the same WiFi network, but the risk is still significant.
It should be pointed out that WPA2 only handles data that travels between the client — a mobile device or laptop — and the wireless router. If data is also encrypted with a different protocol at a different level of the network stack, that encryption is unaffected. The flaw in WPA2 does not mean that people can intercept and decrypt information sent over SSL-secured connections.
Mitigating The Risk Of Krack Attacks
We expect fixes for routers and client devices and applications will be made available as soon as possible. As ever, updating your devices is the best way to mitigate the impact of this vulnerability.
As I’ve already noted, users of websites and eCommerce stores protected by SSL certificates have an additional layer of protection that will prevent an attacker from reading sensitive information even if they can decrypt the WPA2 connection.
All Magento stores should be protected by SSL certificates — payment gateway services use SSL by default, but without an SSL certificate for your Magento store, other sensitive information can be observed by an attacker. Responsible eCommerce merchants protect their customers with SSL certificates.
One scenario in which both Magento and WordPress site owners are at risk is when carrying out work on a site over an unencrypted connection: FTP is a common example. If an outside contractor or developer is working on your site from a WiFi network vulnerable to a Krack Attack, there’s nothing to protect sensitive data.
We offer OpenVPN virtual private networks for WordPress dedicated server and Magento dedicated server hosting clients to allow site and store owners to grant secure access to third-parties. Once logged in to an OpenVPN network, all communication is encrypted, protecting data even if it travels over a vulnerable WiFi network.
Learn More About Krack Attacks
Krack Attack stands for Key Reinstallation Attack, and it exploits a flaw in the 4-way handshake that takes place between a WiFi client and a router. When your device connects to a wireless router, a conversation between the devices sets up a shared encryption key that is used to encrypt subsequent traffic.
Krack Attacks trick WiFi clients into reinstalling a key that is known to the attacker. A key should only be able to be installed once: if an attacker can force the same key to be reinstalled, they can, along with other information collected from the network, decrypt the connection. You can see the full details of how this works on the Key Reinstallation Attacks website.
In previous articles we’ve talked about why criminals are interested in attacking WordPress sites and some of the methods they use. Today we’re going to look at drive-by downloads, a common category of attack used by criminals to infect site visitors with malware. Drive-by downloads are software downloads made to a device without the permission or knowledge of its owner.
Most such attacks are carried out using the compromised content managements systems of legitimate sites, infecting the site’s visitors with malware that serves the interest of the attacker.
This June, security researchers at Sucuri noticed that a large number of WordPress sites were being used by criminals to infect web users with ransomware, so it’s worth going into some detail about how attacks of this sort work.
When an attacker compromises a WordPress site – usually because the site hasn’t been updated — they’re not necessarily interested in the resources of the site. Instead, they’re interested in the site’s audience. They want to use the site’s popularity to their own advantage, infecting its audience with ransomware, botnet software, software that steals banking and credit card details, and so on.
The code the attacker wants to load is usually part of an exploit kit. Exploit kits like Nuclear and Angler are complex applications that probe the software on a visitor’s device for vulnerabilities, often in PDF reader and Flash player software. If the exploit kit finds a vulnerability, it compromises the visitor’s device and uploads a small piece of malware, which will typically download the main malware payload. The entire process can take place in less than a second and most people never notice that their device is now controlled by criminals.
So what can WordPress site owners do to minimize the chances that their sites will be compromised and used to infect visitors with malware? Most importantly, keep WordPress (and any other internet-facing software) up-to-date. It’s hard to overstate how important this is. If your site is not updated regularly, it’s almost certainly vulnerable. Themes and plugins should also be updated regularly.
While most WordPress sites are exploited because web hosting clients don’t update, a good number are hacked via simple brute-force attacks. Brute-force attacks only work if a site has easily guessed passwords, so the second most important mitigation advice is to use long, random, complex passwords. For extra safety, think about implementing two-factor authentication on your site.
Certificate Authority Authorization records prevent SSL certificates being issued to hackers and online criminals for domains they don’t legitimately control.
When you ask a Certificate Authority to issue an SSL certificate for a domain, you have to prove that you control that domain. For Domain Validated certificates, that often involves uploading a special file to a server connected to the domain. If the file provided by the CA appears on the server, they know you’re in control.
In most cases, that’s a valid way to show who controls the domain. But, if a hacker compromised a WordPress or Magento site, they might be able to upload a verification file. There’s a flaw in the system that can be used by malicious individuals to influence a Certificate Authority to issue a certificate for a domain they don’t have legitmate control over. They have control over the site, but that control isn’t legitimate. Certificate Authority Authorization records are intended to close that loop in the verification process.
Certification Authority Authorization (CAA) records are a “new” (the RFC for the proposed standard was technically released in 2013) DNS record type, which will be used by Certificate Authorities (CAs) to add an additional layer of security for domain holders in regard to SSL certificates being provisioned under their name.
The CA/Browser forum – a voluntary group of companies such as Google, Mozilla, and Comodo – took a vote on making the use of these records mandatory, which passed earlier this year.
This means that major browsers will only trust certificates if they’re issued by a Certificate Authority that checks CAA records as part of its process. If the domain owner sets the CAA DNS record, Certificate Authorities have to respect the contents of that record.
How CAA Records Work
In order to help explain this better I’ve provided an example below:
We’ll presume Acme Company, Inc. controls example.com and only uses Comodo as their CA. The admins for their domain/DNS zone create the following CAA record:
example.com. IN CAA 0 issue "comodoca.com"
When the admins for example.com submit a request to Comodo to create a new SSL certificate for their domain, Comodo then runs a lookup against the domain’s existing CAA records to determine if they are permitted to issue the certificate. Upon seeing that the record exists and references them, they proceed with the creation of the certificate.
It’s worth noting that CAAs don’t take the place of current verification/validation procedures for SSL provisioning, but rather add an additional layer to cover situations that were not handled under the existing processes.
To dive into some specifics on how the records themselves are laid out, I’ve provided examples below for each “property tag” that can be specified:
As shown above, the “issue” property tag specifies a specific CA that is authorized to provision certificates for the domain in question.
example.com. IN CAA 0 issue "comodoca.com"
Exactly the same as issue, however this allows for wildcard certificates to be issued as well
example.com. IN CAA 0 issuewild "comodoca.com"
This property tag currently isn’t fully supported by all CAs, however its purpose is to provide further information such as E-Mail addresses, that can be used by CAs in situations where there’s an issue with the certificate itself or in cases where someone may have made an attempt to request a certificate be created that violates any other CAA record property tag rules.
example.com. IN CAA 0 iodef "mailto:[email protected]"
What Do CAAs Mean For Hostdedi Customers?
This is a good thing. There have been countless events in previous years in which malicious parties have been able to provision certificates for domains that they don’t have control over. This new enforcement tool provides companies and individuals with another layer of security for their domains and the certificates issued under them.
In addition to all of the above, CAs are only enforcing these rules if the records exist. If you’d rather not use them (though I’d highly recommend doing so) your interactions with CAs when purchasing a certificate will be the same as they always have.
We’re proud to announce that we’ve implemented full support for CAA records within Portal and you can log in and get started with creating those today.
As always, if you have any questions regarding these records or need assistance with creating them, you can contact the best Support Team in the world by opening a ticket, E-Mailing [email protected], or by contacting us via phone at any time.
For a business with more than a handful of employees, managing authentication credentials like passwords and usernames can be a huge headache, as Deloitte, a “Big Four” accountancy firm discovered this September. A protracted breach of Deloitte’s networks, which leaked emails and other sensitive information linked to some of the biggest corporations in the world, could have been avoided if Deloitte had protected user accounts with two-factor authentication.
Deloitte boasts revenue in excess of $37 billion and is one of the largest auditing and accountancy firms in the world. It is also a leading provider of cybersecurity services. It appears Deloitte’s networks were compromised when a hacker gained access to log-in credentials for an admin account. There’s some disagreement what was leaked, but Brian Krebs suggests a large amount of highly sensitive data was exfiltrated over many months.
It’s not known how the admin account was compromised, and there could be any number of explanations, from carelessness to brute-force attacks. But one thing is clear: two-factor authentication would almost certainly have prevented the attacker from gaining access, even if they had the admin user’s username and password.
Two-factor authentication uses an additional factor of authentication in combination with a username and password. The TFA most users are familiar with involves a one-time code being sent to a device in the user’s possession — their phone or a dedicated dongle. If the user can demonstrate that they know the number, it proves they have possession of the device. Passwords and usernames leak all the time, but it’s much less likely that an attacker would have access to the password, the username, and a trusted user’s unlocked phone at the same time.
Authentication leaks are among the most dangerous security breaches because they’re so hard to spot. There are few tell-tale signs: it looks as if an authentic user has logged in. In the Deloitte case, it seems the attackers were able to access the network from the fall of 2016 until this March.
eCommerce stores and web sites can more easily be compromised if retailers and publishers make the same mistake one of biggest cybersecurity consultancies in the world made by trusting people to manage passwords properly.
Passwords are a strong form of authentication if they are managed intelligently. Long and random passwords used as part of a well-designed authentication system are next-to-impossible to discover. But most people, including developers and others you’d expect to understand the problem, don’t choose or manage passwords properly. Two-factor authentication provides a second layer of security that can keep a Magento store or WordPress site secure even if a user is careless with their password.
Magento retailers should take a look at Sentry, a Magento two-factor authentication plugin Hostdedi developed in partnership with Human Element. Sentry works with the Google Authenticator and Duo Security services to provide easy-to-use TFA for Magento eCommerce stores. WordPress user should consider WordPress Two-Factor Authentication.
If you’re an online merchant, and your store accepts credit cards as payment, then you’ve probably already heard the term PCI compliance. If you haven’t, then start here, and then come back to this post.
The Payment Card Industry Data Security Standard (PCI DSS) was created by banks and credit card companies to protect their cardholders. Failing compliance can result in fines ranging between $5,000 to $500,000. Add to that the probable loss of consumer confidence, civil litigation, and suspension of credit services, and the inconvenience of maintaining PCI compliance far outweighs the cost of ignoring it.
Here’s four ways to become and stay compliant. We can’t promise they’re easy, but we can promise they’re essential.
1. Read and understand the PCI DSS, or find someone that can
This is no easy task. The PCI DSS requirements document weighs in at a staggering 139 pages. The PCI Quick Reference Guide knocks it down to 40 pages, which is hardly convenient, but does suggest the PCI might have something close to a sense of humor (spoiler alert: they don’t).
So while we urge you to read it and try to understand all of it, many smart and successful people aren’t particularly qualified to do so. As your hosting company, we can provide some assistance, but only you or a third party hired by you can assess your systems. Find a Qualified Security Assessor (QSA), a security firm trained and certified by the PCI, to guide you through the labyrinth.
2. Use a PCI-compliant hosting provider
If you’re already a Hostdedi client, then you’re all set. While using us or another PCI-compliant host can’t alone make you PCI-compliant, we take great care to cover things on our end so you can focus on yours.
3. Make sure your developer is PCI-savvy
A knowledgeable developer can help bake compliance into your site. In addition, any third party with access to your systems should be following established best practices for security.
4. Do a self-assessment every year
Compliance is not a one-time requirement, and the PCI changes them every so often to address emerging threats. Take the time to complete the self-assessment questionnaire (SAQ) every year will help keep you current and committed. You can download a SAQ from the PCI DSS website.
Upon request, we also provide a PCI Responsibility Matrix that outlines exactly which standards are yours, which are ours, and which are shared. The document is available to Hostdedi clients through our Support Team, and makes it easy to answer questions about your web host.
It’s rigorous, but worthwhile – think of it as exercise for your PCI-compliance muscles. Put it on your calendar during your slowest month so you can face your busiest ones with confidence.
Earned, not given
PCI compliance is required by the industries holding the keys to the eCommerce kingdom. Moreover, the holidays are a stressful time for consumers, and their trust in your brand is your greatest asset. Defend it with vigor and vigilance, and you’ll likely never have to learn the cost of regaining that trust.