CAll Us: +1 888-999-8231 Submit Ticket

Certificate Transparency Aims To Make eCommerce Shoppers Safer

Certificate TransparencyThe security of online eCommerce transactions depends on SSL certificates and a system of validation by Certificate Authorities. The math behind SSL / TLS cryptography is sound if used properly, but the entire system depends on Certificate Authorities behaving as expected. They issue certificates, validate the identity of applicants, and make sure the SSL system isn’t abused. Every time a shopper makes a purchase from an eCommerce merchant, they implicitly trust the Certificate Authorities. That’s a problem, because although most Certificate Authorities deserve the trust they’re given, some do not.

Recently it was revealed Certificate Authority WoSign had persistently broken the rules that exist to keep web users safe. Over a period of several years, they had abused the trust placed in them. Browser developers reacted quickly to prevent any further damage, but that’s a case of closing the barn door after the horse has bolted.

What the web really needs is a way to make sure Certificate Authorities are doing their job properly, a monitoring system that would make any malfeasance immediately obvious.

That’s the goal of Certificate Transparency, a project from Google that aims to make Certificate Authorities open to scrutiny. Certificate Transparency is intended to make it difficult for CAs to issue certificates for a domain without the owner of that domain knowing about it. At the moment, any Certificate Authority can issue a certificate for any domain, and there’s no straightforward way for the domain owner to find out.

Certificate Transparency provides a monitoring system for all issued certificates — a log of all certificates that anyone can query. The logs are append-only lists of all certificates issued by CAs. They can be queried by anyone, so if a domain owner wants to know if a CA has maliciously or accidentally issued a certificate for their domain, they can simply send a request to the log.

Certificate Transparency will keep CAs honest by making it easy to find out when they’re behaving dishonestly or incompetently.

It’s possible to dream up any number of systems that would make the web safer and more secure, but it’s a pointless exercise if the major stakeholders, especially browser vendors, don’t act.

The good news is that starting from next year, Google intends to make Certificate Transparency mandatory. If CAs want Google’s Chrome browser to trust their certificates, they’ll have to comply with Chrome’s Certificate Transparency policy. All certificates issued after October 2017 will have to comply.

October 2017 is almost a year away, and there are any number of reasons that deadline might slip, but it’s encouraging that at least one major browser developer is being proactive about the problem of untrustworthy Certificate Authorities.

eCommerce shoppers and retailers — and everyone else who uses the web — must be able to trust that their private data won’t be delivered into the hands of criminals and others who would use it maliciously. Certificate Transparency is a welcome move in that direction.

Posted in:
Security

Source link

Credit Card Scrapers Continue To Be A Risk On Insecure Magento Sites

Credit Card ScrapersDiscovering that an eCommerce store has sent their credit card data to a malicious third party is the worst nightmare of many shoppers. They adopt an eminently sensible “once bitten, twice shy” attitude towards retailers who allow sensitive financial data to fall into the hands of criminals. Leaking credit card data is a great way to lose customers.

In a recent blog article, security company Sucuri discussed a typical credit card scraper attack against a Magento store. Malicious code was injected into the popular SF9 Realex Magento extension. The code was simple: it routed credit card data submitted by customers to the attacker’s email address.

The scraper’s presence was not the fault of the extension. It’s likely the attacker exploited an existing security vulnerability to gain access to the Magento installation.

The best way to avoid having your store infected with credit card scraper malware is to make it difficult for attackers to compromise it in the first place.

First, and most important, keep your Magento store up-to-date. Many eCommerce merchants take the view that if their site is working as intended, updating is more trouble than it’s worth. But updates aren’t just for new features. Updates contain patches that fix vulnerabilities. Once a patch has been released, it’s a good bet criminals know about the vulnerability.

I advise store owners to follow announcements on the Magento Security Center, which publishes details of security vulnerabilities and mitigation guidance.

Magento store owners should also be careful which extensions they install and where they come from. Malware is often found in extensions sourced from unverified locations. Using “pirate” versions of premium Magento extensions is a serious risk because they often include malware. Magento Connect implements strict checks to ensure that malicious software isn’t published.

Finally, store owners should ensure they follow password best practices. The web is teeming with brute force bots that love nothing more than an easily guessed password. Robust password policies that enforce long, random passwords for administrator accounts are essential.

To help you keep criminals out of your Magento installation, Hostdedi developed two open source Magento extensions: Sentry and Alarmbell.

Alarmbell is a security extension that sends notifications whenever a new admin user is created. The creation of a new admin user without the knowledge of existing administrators is a key indicator that a Magento store has been compromised. Alarmbell will also log every change to admin accounts and failed admin login attempts.

Sentry is a two-factor authentication plugin for Magento. As I just mentioned, brute force attacks are a frequent cause of Magento stores being compromised. Sentry allows eCommerce merchants to integrate their store with Google Authenticator or Duo, making it practically impossible for brute force attacks to compromise a store.

These basic security precautions are not onerous or time-consuming, and if you consider the potential impact of a credit card scraper or other malware on your Magento store, they’re well worth the minimal time investment.

Posted in:
Magento, Security

Source link

When Is It Right To Keep WordPress Vulnerabilities Secret?

WordPress VulnerabilitiesBugs are an inevitable part of the software development process. As hard as developers try to avoid them — and they try very hard indeed — mistakes will be made and some of those mistakes will cause security vulnerabilities. What’s important is how developers handle vulnerabilities when they do occur, including how they communicate about them with users.

In the open source and security world, it’s generally agreed that when a vulnerability is discovered, as much information as possible should be provided to users. They need to know about the vulnerability so they can protect themselves. Information is power where security is concerned, and if only criminals and security researchers know about a vulnerability, users are at an unfair disadvantage. As Aaron D. Campbell, WordPress Core Security Team Lead, remarks in a recent blog post,

“Disclosing the vulnerability is best for your users. It builds trust. It’s also the best thing you can do for the future of security. Hopefully other people can learn from your issue and not have to face the same one themselves.”

But sometimes, developers and security researchers choose to keep vulnerability information to themselves, for a short time at least. Secrecy rubs some people up the wrong way, and for good reason. Professionals and other developers need all the information they can get to protect their sites, users, and clients. They don’t trust developers to make sensible decisions about what should be kept secret, an attitude informed by a long history of vulnerabilities that were hidden to benefit developers and their companies rather than users.

This January, WordPress 4.7.2 was released. It included a patch for a serious vulnerability, but there was no mention of the patch in the initial release notes. Details of the vulnerability were released several days later, much to the chagrin of those who demand complete and immediate transparency. In this case, WordPress developers were justified in keeping the vulnerability to themselves.

It’s important to distinguish between secrecy to protect users and secrecy for selfish reasons. There are many selfish reasons a developer might want to keep a vulnerability secret: because it makes them look bad, because it might discourage people from buying their product, and, in the worst cases, because keeping it a secret is less expensive than fixing it. None of those reasons apply to WordPress and most other open source projects.

When a WordPress update is released, it’s installed by millions of site owners in the following days. The release is also scrutinized by criminals who know that many WordPress sites won’t be updated immediately. They use information gleaned from the public disclosure of vulnerabilities to attack WordPress sites that have not been patched.

While there’s nothing to prevent criminals from analyzing the code of an update to discover what is being patched, declining to widely publicize vulnerabilities gives WordPress users a chance to update before criminals begin to exploit a vulnerability.

In good time, all vulnerabilities should be announced and publicized. No one wants to go back to the dark days of security by obscurity. Users and professionals who want to know about vulnerabilities as soon as possible have a good case, but a project’s developers have a difficult decision to make: publicize a vulnerability immediately and put users at risk, or hold off and give them time to update. Vulnerabilities should be kept secret for no more than a few days, but sometimes protecting users is more important than complete transparency.

Posted in:
Security, WordPress

Source link

Clef, The Popular Two-Factor Authentication Service, Is Shutting Down

ClefClef, a popular two-factor authentication service used by Magento eCommerce stores and WordPress sites has announced that its service will cease operation on June 6th 2017. It’s not clear why Clef is shutting down, but the company’s announcement states its employees will be moving to another company. It seems Clef – in spite of its popularity – failed to find a business model that could support its continued existence.

eCommerce merchants and site owners who use Clef should prepare to move to a different TFA provider as soon as possible.

Although there is no shortage of TFA plugins and services, Clef put the user experience front and center, offering an intuitive solution to the perennial problem of poor password management. Clef’s WordPress plugin has been installed over a million times, and its Magento extension has five stars on Magento Connect. The WordPress plugin has already been removed from the WordPress Plugin repository, and other integrations and mobile apps will be withdrawn in the lead-up to the service’s shutdown in three months.

Two-factor authentication is a key security measure for sites and stores that need authentication more robust than a simple username and password combination can offer. Brute force attacks are a constant threat to any online business, and sites with many users struggle to ensure they choose passwords intelligently.

Two-factor authentication services – including Clef – add an extra factor of authentication, often a one-time code generated by a mobile application. Without access to the secrets used to generate these codes, brute-force attacks can’t succeed. Sites are also protected against other password-based vulnerabilities, including leaked password databases and careless users who don’t keep their passwords safe.

It’s advisable for all sites and eCommerce stores to implement two-factor authentication. Those who used Clef have several options to choose from.

Users of Magento 1.X can move to Hostdedi’ Sentry extension, which, once installed, will require two-factor authentication for all administrative logins. Sentry integrates with many of the most popular two-factor authentication services, including Duo and Google Authenticator.

WordPress hosting clients who use the WordPress security plugin Wordfence might consider its built-in 2FA functionality or a dedicated plugin.

  • Two Factor Authentication is a comprehensive TFA solution for WordPress. It can be used with Google Authenticator, Authy, and a number of other TFA services. Two Factor Authentication is thoughtfully designed and includes several features to simplify logging in for WordPress users, including graphical QR codes that can be scanned by mobile devices.
  • The Duo Two-Factor Authentication plugin works with the popular Duo TFA service and offers one-tap authentication and one-time passwords delivered by SMS.

If you don’t use two-factor authentication, you’re missing out on a low-friction strategy that significantly reduces the chances that your site will be compromised.

Posted in:
Security

Source link

What You Need To Know

CloudbleedTowards the end of last month, it was revealed that CloudFlare, a popular CDN provider, suffered a vulnerability that caused its edge servers to leak private data. The vulnerability – discovered by Google researcher Tavis Ormandy – was swiftly mitigated, but because the problem may have existed since September 2016, it’s worth taking some time to understand the potential implications for eCommerce merchants, site owners, and their users.

Cloudflare is a service that – among other things – helps websites achieve better performance. It takes the contents of a website and uploads it to edge servers around the world. When a user requests a page, the request is redirected to the nearest edge server, significantly reducing the latency introduced when server and client are far apart. Because the site’s HTML and other assets travel through Cloudflare, they can be processed in various ways before being passed on to the requester.

To process the HTML, Cloudflare runs pages through an HTML parser. A bug in that parser is what caused private information to be leaked. You can read the full technical details in Cloudflare’s post-mortem, but, in short, a buffer overrun error caused the parser to access parts of the server’s memory that should have been private. In a specific combination of circumstances, the parser would not stop with the HTML it was parsing, but would continue to read data from memory. That data sometimes included sensitive information like login details, keys, and private messages.

When someone requested the page, the private data was sent along with it. Even worse, the private data was also sent when web crawlers made page requests, including search engine crawlers, which resulted in some private data being made available in search engine results.

That all sounds very bad indeed, but it should be understood that the buffer overrun could only happen in a very specific set of circumstance. It’s not the case that every request routed through Cloudflare leaked private data. According to the company:

“The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (thatʼs about 0.00003% of requests).”

Cloudflare is huge, so even 0.00003% is a lot of requests, but there’s no evidence that any criminals were actively exploiting the vulnerability and the problem was fixed less than 8 hours after it was discovered. For large sites using Cloudflare, it’s likely that some user data was leaked, but for each individual user the risk is miniscule. Google and other search engines have attempted to scrub their search indexes of any private data that may have been cached.

Should You Reset Passwords?

At this point, the risks are minimal. If you use Cloudflare with your site or eCommerce store, you may choose to advise users to reset their passwords out of an abundance of caution. Given the extensive publicity the leak received, it may well be wise to communicate with users about the nature of the vulnerability and the risk to their privacy. Some security experts advise that passwords should be reset, but because the risk to individual users is small, some prominent security writers advise against password resets, arguing it will do little to protect users and is likely to add to the security fatigue that causes users to ignore security best practices.

Posted in:
Security

Source link

WordPress Update Fixes Critical PHPMailer Vulnerability

PHPMailer VulnerabilityWordPress 4.7 was released towards the end of last year and brought with it a host of new features, including a new default theme, theme starter content, and REST API content endpoints.

As is usually the case with a major new WordPress version, WordPress 4.7 was closely followed by a minor release with bugfixes. WordPress 4.7.1 also includes a number of fixes for potentially serious vulnerabilities. WordPress users should update at their earliest convenience to ensure that their sites are safe.

The headline vulnerability is one that has caused serious problems for a number of PHP-based applications, but which left WordPress largely unscathed. PHPMailer is an email library used on millions of servers — in fact, it’s billed as the most popular email sending library in the world and almost every major PHP application that includes email functionality uses it, including Drupal, Joomla!, and WordPress.

Late last year it was discovered that PHPMailer contained a serious remote code execution vulnerability. I want to emphasize that there’s no evidence this vulnerability is being (or could be) actively used against WordPress sites. Major plugins have been checked and they’re unaffected too.

Nevertheless, it’s never a good idea to leave known vulnerabilities in play; it’s entirely possible that less-popular plugins aren’t so resilient, so a speedy update is the best course of action.

The vulnerability had the potential to allow anyone to remotely execute code on a server by sending an email. PHPMailer did not properly sanitize input and passed some parts of emails to the shell without making any code it contained inert. By embedding shell script in the sender field of an email, an attacker could cause it to be executed on the server.

In addition to the PHPMailer problem, several other vulnerabilities were fixed, including a couple of cross-site scripting vulnerabilities. Cross-site scripting vulnerabilities could allow an attacker to embed JavaScript code within a web page. When a user opens the page, the code is executed and has access to session information for that user, including their authentication cookie. If an admin user runs the code, the attacker may be able to take control of the site.

Finally, WordPress 4.7.1 fixes a information leak problem with the REST API.

If your site has automatic updates turned on, you don’t have to do anything — minor updates are applied automatically. But if you have automatic updates turned off, be sure to manually update to the most recent version of WordPress.

Posted in:
Security, WordPress

Source link