Frequently asked questions about WordPress security at Seravo.com

I think I’ve found a security vulnerability. Where can I report it?

Responsible security disclosures can be sent to security@seravo.com (PGP key available). We have paid small security bounties if the information provided has had significant value.

We would like to make a security audit of our site and Seravo’s infrastructure running it. Do we need a permission for it?

Yes, you do need prior permission. We constantly monitor our systems and launch investigations on malicious activity. To be indemnified against criminal charges that scanning and probing our systems without permission could lead to, please contact security@seravo.com to sign our security testing agreement.

Hardening a site before a security audit

While Seravo has many security features by default enabled for all sites in our upkeep, there are also some potentially invasive additional settings that can be enabled on a site if the site developer decides those settings don’t have any limiting side-effects on the site in question.

A developer may also configure site specific HSTS, CSP and other headers which Seravo cannot have for all customers by default, as they also could cause unwanted side effects.

There are also many other measures that can be made to a site. Seravo offers many tools, like the command wp-check-passwordsfor testing that passwords used on the site are not too easy to guess. Seravo offers expert services to audit and harden the WordPress site beyond the default settings and hardening that all sites have automatically in Seravo’s upkeep. Contact us for more information.

Howto interpret Nessus (by Tenable) security scan results?

Nessus is one of the world’s most popular security scanners. We are not aware of any security vulnerabilities affecting systems maintained by Seravo that an external Nessus scan could currently find. There are however some false positives and warnings Nessus might give that do not need to be addressed due to the following reasons:

• Strict Transport Security Not Enforced: HSTS cannot be globally on for all of our customers, as we cannot possibly know if anybody has use cases where non-http traffic should still be allowed. It is very easy for our customers however to enable HSTS simply by enabling one line from their site-specific Nginx configuration. For more information see our Seravo.com/docs developer documentation.
• TLS Version 1.0 Protocol Detection: Our servers still support using TLS 1.0 for backwards compatibility. Among others IE 10 and Android 4.3 need TLS 1.0 as they don’t support never protocol revisions. We plan to drop TLS 1.0 support when major sites like twitter.com and facebook.com have also deemed it suitable to break backwards compatibility. Currently the usage of TLS 1.0 is around 2 % and most of those users are in corporate environments, where they have no influence themselves on getting their browser updated, and thus trying to force users to upgrade is not helpful. Any site at Seravo.com will get on SSLLabs.com rating A by default, and rating A+ when the site has HSTS enabled (see above). All new browsers use TLS 1.3 and having TLS 1.0 still available for backwards compatibility is the smartest thing to do at the time being. Support for all old SSL protocol versions has however been removed.
• SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability (BEAST): BEAST is purely a client-side vulnerability. Since it had been released to the public, most major browsers addressed BEAST. It can be mitigated server-side by turning off TLS 1.0 support, but as explained above, that would break compatiblity with older browsers and mean that a certain percentage of visitors would not be able to access a site, which is unacceptable. Another mitigation technique would be to enable usage of the old RC4 cipher with TLS 1.0, but that would in turn make HTTPS vulnerable to the POODLE attack, so having TLS 1.0 with only strong cipher suites is the best solution for now.
• WordPress Administrative Interface Exposed: This means that logging into WordPress is possible via /wp-login.php, and the implied solution is to move it to another address, like 123login.php. This is purely security by obscurity and does very little to actually help. It might even make the site owner worse off, because it gives false sense of security and will put off real security measures, like login logging, brute force limiting, strong password enforcement and other techniques that actually matter. All of the aforementioned are, of course, in place by default on all Seravo’s customers’ sites thanks to the Seravo Plugin that implements them. Seravo advises against obfuscating the wp-login.php or /wp-admin/ addresses, as it does little to help security but do actually introduce real usability and availability issues to end users. A much better approach would be to deploy recaptchas and two factor authentication instead of ineffective obfuscation.
• WordPress Username Enumeration: Knowing usernames does not constitute a security flaw. The secret is the password, not the username. Due to brute force protection and other measures, knowledge of usernames do not help attackers. Knowledge of usernames does help other users to accomplish daily tasks, and usernames often leak via blog post authorship anyway, so trying to protect them is mostly a wasted effort. Any available resources should be put into enforcing good password hygiene instead.
• Outdated Component: jQuery: This means that a JavaScript library (in this example jQuery 1.x) is not of the latest version (3.x). This does not necessarily mean that all previous versions of that JavaScript library have a security bug and only the latest one would be secure. Also, this only affects the client-side browser and does not constitute a relevant attack vector against the site. The special case here is that WordPress core includes a jQuery version that is of the older 1.x series on purpose, as only the old version is backwards compatible with certain old browsers (IE) that WordPress wants to stay compatible with. Also note that all sites in Seravo’s upkeep have Access-Control-Allow-Orgin headers by default, which prevent this attack avenue.
• Web Server HTTP Header Information Disclosure: Seravo.com proudly runs Nginx! It is no secret and knowing that does not help any attacker in any way.
• PHP mb_send_mail() Function Parameter Security Bypass: PHP versions 4.4.2 and prior and 5.1.2 and prior contain a vulnerability that could allow an attacker to bypass safe_mode and open_basedir restrictions. Seravo.com has never been running anything less than PHP 5.6, so this does not apply, and even for this to apply, the PHP code itself would need to pass visitor input into the fourth parameter of mb_send_mail() or mail() functions, which no known WordPress plugin or theme does, so this is surely a false positive.