Multiple WordPress Plugins are vulnerable to Cross-site Scripting (XSS) due to the misuse of the add_query_arg() and remove_query_arg() functions. These are popular functions used by developers to modify and add query strings to URLs within WordPress.

The official WordPress Official Documentation (Codex) for these functions was not very clear and misled many plugin developers to use them in an insecure way. The developers assumed that these functions would escape the user input for them, when it does not. This simple detail, caused many of the most popular plugins to be vulnerable to XSS.

To date, this is the list of affected plugins:

1.  Jetpack
2.  WordPress SEO
3.  Google Analytics by Yoast
4.  All In one SEO
5.  Gravity Forms
6.  Multiple Plugins from Easy Digital Downloads
7.  UpdraftPlus
8.  WP-E-Commerce
9.  WPTouch
10. Download Monitor
11. Related Posts for WordPress
12. My Calendar
13. P3 Profiler
14. Give
15. Multiple iThemes products including Builder and Exchange
16. Broken-Link-Checker
17. Ninja Forms

There are probably a few more that we have not listed. If you use WordPress, we highly recommend that you go to your wp-admindashboard and update any out of date plugins now.

This issue was first identified by Joost from Yoast in one of his plugins (he did a great write up about it as well). We worked together with him to investigate the issue and found that it likely affected a lot more plugins than just that one.

Our research team, along with a few friends (especially Joost from Yoast ) have been going through the WordPress repository for the last few days in an attempt to find and warn as many plugin developers as possible – to warn and help them patch the issue.

Coordinated Disclosure

This vulnerability was initially discovered last week, due to the varying degrees of severity and more importantly, the large volume of plugins affected, we coordinated a joint security release with all developers involved and the WordPress core security team. It was great team work, and a pleasant experience to see so many developers united and working together for the common good. We can happily say that all plugins have been patched, and as of this morning updates should be available to all users. (yes, everyone pushed their updates in unison 2 hours ago).

If you use WordPress, now it is your turn to update your plugins!

If you have automatic updates enabled, your site should already be patched, especially in the most severe cases.

There are more plugins vulnerable

Our team only analyzed the top 300-400 plugins, far from all of them as you might imagine. So there are likely a number of plugins still vulnerable. If you’re a developer, check your code to see how you are use these two functions:

add_query_arg
remove_query_arg

Make sure you are escaping them before use. We recommend using the esc_url() (or esc_url_raw())functions with them. You should not assume that add_query_arg and remove_query_arg will escape user input. The WordPress team is providing more guidelines on how to use them here.

Update Time!

If you use any of these plugins, make sure to update them now! We will continue to investigate and look for more plugins vulnerable and keep our list here current.

This is also a good time to remind everyone that all software will have bugs and some of those bugs will inevitably lead to security vulnerabilities, such is the life we live in. This applies to plugins, themes, webservers, CMS’s and basically anything that is written by people and based on code. As much as developers try to minimize them and deploy secure coding principles, mistakes will inevitably still happen. We just have to be prepared and find ways to minimize the affect of any vulnerability in your environment; a perfect example of such an approach is what you’re seeing today with this coordinate release.

Here are some tips and tricks to remember to help reduce your overall threat risk, helping to improve your individual security posture:

1. Patch. Keep your sites updated.
2. Restrict. Restrictive access control. Restrict your wp-admin directory to only white listed IP Addresses. Only give admin access to users that really need it. Do not log in as admin unless you are really doing admin work. These are some examples of restrictive access control policies that can minimize the impact of vulnerabilities in your site.
3. Monitor. Monitor your logs. They may give you clues to what is happening on your site.
4. Reduce your scope. Only use the plugins (or themes) that your site really needs to function.
5. Detect. Prevention may fail, so we recommend scan your site for indicators of compromise or outdated software. Our plugin and Sitecheck can do that for free for you.
6. Defense in Depth. If you have an Intrusion Prevention System (IPS) or Web Application Firewall (WAF), they can help block most common forms of XSS exploits.

These principles are commonly applied to most secure networks (or on any business that needs to be PCI compliant), but not many website owners think of them for their own site / environment.

These are but a few high level recommendations; we recommend going through our blog for more ideas on how to keep your sites safe and ahead of the threats.

What is “POODLE”?

POODLE is an acronym for a newly discovered vulnerability in a specific version of the SSL protocol. POODLE requires an “active” attacker, meaning there must be another ‘bad’ computer intercepting messages between the client and server. Ultimately, the vulnerability allows the attacker to decode messages encrypted with SSL v3.0 (the specific, and only, version of the protocol affected).

SSL v3.0 is an old version of the SSL protocol, a very old version – from the late 90s. However, almost all servers on the Internet still accept connections using it. Luckily, there is a straightforward way to protect yourself from this attack (see “As An SSL Provider, What Should I Do?” section below). The attack also is fairly complex to perform, because of its reliance on being an “active” attack which affects the client. There are also no known attacks using the POODLE vulnerability (yet). For this reason, it is much less serious than the Heartbleed vulnerability from earlier this year. Security expert Robert Graham said, “If Hearbleed/Shellshock merited a 10, then this attack is only around a 5.

However, this does not mean that POODLE should be ignored, because all servers or clients running SSL v3.0 are vulnerable. (See section, “Who is Affected?” for specific details on this and threat analysis).

The vulnerability is serious enough that Mozilla has declared POODLE “the end of SSL 3.0, and Google said “to achieve secure encryption, SSL 3.0 must be avoided entirely.

Please note that (luckily) this is a flaw in an outdated version of the SSL protocol itself, so no changes to any existing certificates themselves are needed. This vulnerability is the result of some bad math back when this version of the protocol was created back in the late 90s.

Solutions to this vulnerability are most effectively implemented at the server level (even though the attack is on the client, its reliant on the server allowing a connection using SSL v3.0 to occur), so education and awareness of the issue is the best way to mitigate the effects of the POODLE vulnerability.

How does the Attack Work?

The POODLE vulnerability can be implemented by an attacker who has control or influence over the network connection between the client and the server – often called a “Man in the Middle Attack” (MITM).

An attack using POODLE begins with a “downgrade attack” to repeatedly cause the client’s connection to the server to fail. This causes the server to allow an encrypted connection with older versions of the protocol, because it believes a lack of modern protocol support is the cause. This downgrading continues to occur until the connection is downgraded all the way to SSL v3.0, at which point the POODLE attack can be used.

This downgrade attack works because, while almost every server supports a newer version of the SSL protocol which are not affected, they ALSO support SSL v3.0 in order to avoid any incompatibility issues with older (“legacy”) clients. After forcing stronger clients to downgrade to SSL v3.0, they can use a flaw in the protocol to figure out the encryption key for an SSL connection, and read the contents as if they were unencrypted.

If you would like to know more about how the attack works, Google provides some excellent information in their paper which announced the discovery: “This POODLE Bites: Exploiting The SSL 3.0 Fallback.

Who is Affected?

Any browser or server which supports SSL 3.0 can be victim to POODLE. Critically, “any website that supports SSLv3 is vulnerable to POODLE, even if it also supports more recent versions of TLS. This means that sites trying to provide backwards compatibility for older clients are at risk. For this reason, supporting SSL v3.0 at all can make a server or client vulnerable.

SSL Pulse is a website that collects monthly demographic statistics of SSL support of the 150,000 most popular websites. SSL Pulse’s most recent scan, conducted before the disclosure of the POODLE vulnerability, found that 98% of these sites still have SSL v3.0 support, potentially putting them at risk of a POODLE attack. Extrapolating from this, it can be assumed most servers on the Internet still include support for the decrepit SSL v3.0.

However, there is very little client traffic still using SSL v3.0 to justify support of this deprecated and flawed protocol version. The most notable software affected by this attack is Internet Explorer 6 on Windows XP versions WITHOUT Service Pack 3.

Support for this flawed protocol version should not be kept for users still on IE6. On Cloudflare, a major provider of DDoS protection, only 0.65% of their received SSL traffic uses (not relies on) SSL v3.0, and 98% of their Windows XP traffic is properly patched to Service Pack 3 which enables TLS 1.0 (the next version of the SSL protocol after SSL v3.0). Mozilla similarly estimates only 0.3% of traffic actually uses SSL v3.0, yet around 98% of servers allow it! The number of clients still needing SSL v3.0 simply does not justify keeping it on.

As an SSL provider, what should I do?

The SSL Store’s recommendation is to totally disable support for SSL v3.0. This should be disabled on your servers and communicated to your customers. There are solutions to the POODLE attack, mainly the new protocol mechanism “TLS_FALLBACK_SCSV. However, this mechanism relies on server and browser compatibility, which introduces too much uncertainty to its effectiveness. TLS FALLBACK also does not fix the issue for devices that ONLY have SSL v3.0 support, leaving the biggest vulnerable software – IE6, still exposed.

So, to be totally safe from POODLE, and other discovered and undiscovered flaws in SSL v3.0, its best to disable support for it altogether at the server side. This falls in line with what is recommended by Google, Mozilla, Cloudflare, and other major technology companies.

On the client side, Firefox will be disabling SSL v3.0 by default in Firefox 34, which is to be released on Nov 25th. Google will also be removing SSL v3.0 support in client devices, including Chrome, “in [the] coming months. With this pressure on the client-side removing SSL v3.0 support, the tiny number of client’s using SSL v3.0 should tumble even further.

(Also note, if you recently switched to SHA2 certificates, as the SSL industry is encouraging and requiring, you have downgraded the user experience for sluggish clients still on IE6 with Windows XP pre-Service Pack 3. So disabling SSL v3.0 will be the nail in the coffin for them – thats a good thing.)

Does this mean SSL is insecure?

No. SSL, or more accurately, TLS, is fine. While most people use the word “SSL” still, the proper technical term for the encryption protocol we use today is TLS. This stands for Transport Layer Security and has been the official name of the SSL protocol since 1999. The newest version of the TLS protocol, Version 1.2, was released in 2008 and is four versions senior of SSL 3.0. All ‘modern’ browsers and computers, and smartphones should have support for some version of TLS, and the majority of SSL connections are using TLS. TLS 1.0 and 1.1 are not perfect, but they are much improved over SSL v3.0 and are considered suitable by security experts.

SSL v3.0 is over 15 years old! So it’s only reasonable for it to be abandoned at this point.

How Do I Disable SSL v3.0 on my Server? (Already completed on all shared, VPS and Dedicated Servers) on the Host 99 network.

This depends on the type of server you are operating.

For Apache Tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=54691

For Apache, Nginx, and IIS: https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/

For Lighttpd: https://cipherli.st/

If you do not want to drop SSL v3.0 support, you can implement TLS_FALLBACK_SCSV on OpenSSL. However this should just be a stopgap solution and replacements for devices requiring SSL v3.0 should be actively pursued. https://www.openssl.org/news/secadv_20141015.txt

Further Resources:

In addition to the citations on this resource, please see:

The University of Michigan’s data on server support and presence of SSL v3.0: https://zmap.io/sslv3/

For technical details on how the vulnerability works, see Google’s original paper: https://www.openssl.org/~bodo/ssl-poodle.pdf

For the single best understanding of POODLE and what it means as a Internet user concerned with security, or a server operator, see Robert Graham’s notes on POODLE at his personal website: http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEUcTvnF-MJ

Microsoft’s Security Advisory on POODLE: https://technet.microsoft.com/en-us/library/security/3009008.aspx

1. http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEWwk4t4p1-
2. https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
3. https://www.openssl.org/~bodo/ssl-poodle.pdf
4. http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEUcTvnF-MJ
5. http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html
6. Also see Adam Langley’s slightly different explanation on his personal site: https://www.imperialviolet.org/2014/10/14/poodle.html
7. Section: “Issue” https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
8. https://www.trustworthyinternet.org/ssl-pulse/
9. https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
10. https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
11. https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
12. http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Zen Cart Users please read important details here and here

On a day when system administrators were already taxed addressing several security updates released by Microsoft, Oracle, and Adobe, there is now word of a new security hole discovered in a basic protocol used for encrypting web traffic. Its name is POODLE, which stands for Padding Oracle on Downgraded Legacy Encryption, and it was discovered by three Google security researchers—Bodo Moller, Thai Duong, and Krzysztof Kotowicz. They published a paper (.pdf) about it today.

POODLE affects SSLv3 or version 3 of the Secure Sockets Layer protocol, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. It’s not as serious as the recent Heartbleed and Shellshock vulnerabilities, but POODLE could allow an attacker to hijack and decrypt the session cookie that identifies you to a service like Twitter or Google, and then take over your accounts without needing your password.

To exploit the vulnerability, you must be running javascript, and the attacker has to be on the same network as you—for example, on the same Starbucks Wi-Fi network you’re using. This makes it less severe than an attack that can be conducted remotely against any computer on the Internet.

The attack works only on traffic sessions using SSLv3. Although this is an old protocol that has been replaced in many client and server configurations with TLS (Transport Layer Security), many browser clients and web servers that use TLS for connections still support SSLv3. Some products and browsers, like Internet Explorer 6 for Windows XP, only use SSLv3. There are also clients that support SSLv3 as an alternative to use whenever a TLS connection to a web server fails. An attacker could exploit this compatibility to downgrade a connection to SSLv3 and then conduct the POODLE attack to hijack your session.

Google’s security team has recommended that systems administrators simply turn off support for SSLv3 to avoid the problem. But this will mean that some users trying to connect securely to a web server using SSLv3 will have trouble connecting if they’re using a client that only supports this protocol.

“This attack is really against clients—you have to worry about it if you’re in a place like Starbucks,” says Rob Graham, CEO of Erratasec. “If you’re at home there’s probably no one man-in-the-middling you except the NSA. So as a home user, you don’t need to panic. As a server [administrator], you probably don’t need to panic if your customers are coming in over home connections. Only if they’re coming in over [something like] a Starbucks Wi-Fi.”

Heartbleed and Shellshock were vulnerabilities that allowed an attacker to hack a server. POODLE instead targets the clients.

“The fear of rushing to go fix this is very low because of that,” Graham says. “People with servers can’t get hacked, and people with [vulnerable] clients also can’t get hacked unless they’re on an open Wi-Fi.”

Important Note: As of January 1, 2015 Host 99 will no longer support SSLV1, SSLV2, SSLV3. Only TLS V1.1, TLSV1.2 combined with SHA-2 will only be supported. Any current SSL holders can renew their active SSL certificates early or wait until the current SSL expires that may be currently in use. After the mentioned date, only SHA-2 SSL will be used and installed. We urge any SSL holder to upgrade before this date but no interruptions will occur during the current period.

You can click to access the list of all the possibly affected sites. But before signing off any site as ‘vulnerable’, we recommend that you check their respective blogs for the latest updates. There is no way of telling how many sites out of the list were actually attacked as the bug leaves no trace of any attack carried out on the site.

https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt

Thankfully, names like Google, Amazon, and Microsoft have not yet found their way to the list.