Online Services

Category: Security

  • Vulnerability in Yoast SEO 3.2.4 for WordPress

    One of our security researchers, Panagiotis Vagenas, discovered a vulnerability in Yoast SEO version 3.2.4 and earlier that allows any user with ‘subscriber’ level access to download your Yoast SEO settings. For sites that have open registration, this means that anyone can register and download your Yoast SEO settings by simply creating an account and running the exploit.

    We reported this vulnerability to Yoast Tuesday May 3rd and their team has released a fix today, Friday May 6th. We recommend that you upgrade immediately if you are using Yoast SEO. This vulnerability is fixed in Yoast SEO version 3.2.5.

    If you are using Wordfence Premium, you have been protected against this vulnerability being exploited from the moment we notified the plugin author which was on Tuesday. We released a firewall rule via the Threat Defense Feed on Tuesday that is already protecting your site. This is per our standard disclosure procedure. See below for details.

    Details of the Vulnerability

    Yoast SEO plugin has a Sensitive Data Exposure vulnerability. Plugin registers the following AJAX actions:

    wpseo_export
    get_focus_keyword_usage
    get_term_keyword_usage

    These actions are privileged therefore are available only to registered users, but no special capabilities are required to perform them. Any user with a valid account to the target website can exploit those actions to get information about Yoast SEO settings and post metadata relative to focus and terms keywords.

    This kind of information should be available only to users with administrative capabilities. To be more precise, to users that have the manage_options capability, because the plugin’s option pages require this capability by default.

    We will not be releasing an exploit proof of concept at this stage but we shared a PoC with the Yoast team on Tuesday to help them confirm and fix the vulnerability.

    Wordfence Standard Disclosure Procedure

    At Wordfence the security of our customers and the greater WordPress community is of paramount importance to us. With this in mind we have developed standard disclosure procedures when we discover a vulnerability that are as follows:

    1. One of our research team discovers a vulnerability and shares it with the rest of the team who verifies the vulnerability.
    2. We develop a Firewall rule to protect our customers. This rule is obfuscated to prevent reverse engineering.
    3. We notify the vendor and simultaneously release a firewall rule to protect our premium customers via the Threat Defense Feed. Customer sites are updated immediately with the rule and no customer action is required.
    4. Vendor releases a fix, usually after several days and we announce the existence of the vulnerability at the same time to encourage the community to upgrade.
    5. Wordfence community (free) customers receive the firewall rule 30 days after the initial release to Premium customers.
    6. At a future date we may release a PoC so that other firewall providers can create rules to protect their customers too.

    The post Vulnerability in Yoast SEO 3.2.4 for WordPress appeared first on Wordfence.

  • Ninja Forms Shell Upload Vulnerability – Very High Risk

    A few times a year we see very bad vulnerabilities come along. This is, unfortunately, one of those times.

    Ninja Forms versions 2.9.36 to 2.9.42 contain multiple vulnerabilities. One of the vulnerabilities results in an attacker being able to upload and execute a shell on WordPress sites using Ninja Forms. We have developed a working exploit for internal use at Wordfence. The only information the exploit needs is a URL on the target site that has a form powered by Ninja Forms version 2.9.36 to 2.9.42.

    Wordfence Firewall already protects against uploading of malicious PHP files, so you were already protected against this attack while it was still a 0 day. As an additional precaution, this morning we have released three additional rules via the Wordfence Threat Defense Feed which are already active on our Wordfence Premium customer sites.

    Ninja Forms has over 500,000 active installs, so the impact of this vulnerability is going to be fairly wide-spread.

    We are monitoring attacks in real-time and are not yet seeing this being widely exploited yet. We suspect this is because an exploit has not shown up yet on exploit-db or other public exploit databases (as of 9am Pacific time on May 5th). We expect this to happen within 48 hours and there will almost immediately be widespread attacks that exploit this vulnerability.

    It’s not often that attackers are provided with a fresh vulnerability in a popular plugin that lets them drop shells or execute code on a large number of WordPress sites. This only happens a few times a year.

    WordPress.org has already released an automated forced plugin update. This happened on May 3rd which was 48 hours ago. We’ve confirmed that this forced update is taking effect on our test sites. This vulnerability will continue to affect sites that have not been updated by their owners and where forced plugin update is disabled or not feasible.

    What to Do

    1. Update Ninja Forms immediately to at least version 2.9.45 if you haven’t already.
    2. If you are running the free version of Wordfence you already have fairly good protection against this vulnerability.
    3. If you are running our Premium version, we have already released new rules that give you full protection against this vulnerability even if your site has not been updated yet.
    4. If you aren’t using our firewall but are using a competing product, verify that they protect against this specific exploit. This is a new vulnerability and they may not have added rules to protect against it yet.
    5. If you weren’t using a firewall before you updated you should also verify that your site has not already been compromised. We recommend you install Wordfence and run a scan.

    You can find the full disclosure of the vulnerability by James Golovich on pritect.net. This was published yesterday and contains more technical detail of the vulnerability.

    You can find Ninja Forms changelog here which will help you keep abreast of any additional security updates they may release in the next few days.

     

    The post Ninja Forms Shell Upload Vulnerability – Very High Risk appeared first on Wordfence.

  • WordPress Redirect Hack via Test0.com/Default7.com

    WordPress Redirect Hack via Test0.com/Default7.com

    We’ve been working on a few WordPress sites with the same infection that randomly redirects visitors to malicious sites via the default7 .com / test0 .com / test246 .com domains. In this post, we’ll provide you with a review of this attack, investigated by our malware analyst, John Castro. Header.php Injection In all cases, the
    Read More

    The post WordPress Redirect Hack via Test0.com/Default7.com appeared first on Sucuri Blog.

  • Major Vulnerability in Freshdesk – Results from a recent Wordfence Red Team Exercise

    Wordfence recently conducted a red team exercise on our own network. That means that two of my team members secretly conducted a simulated attack on our network and a passive attack on our SaaS providers. We were careful in limiting the scope of this attack, and so our attack on external providers was limited to passive activity like source code analysis and passive analysis of web services.

    We turned up several items during the red team exercise that helped make our systems and services more secure. Sean Murphy, the lead on this exercise made a startling discovery during the exercise: Freshdesk, our customer service portal provider, had a single sign-on (SSO) implementation that allowed a user to create an account in the support system with ordinary privileges and then promote themselves to administrator level.

    This security hole did not just affect Wordfence. It also affected any Freshdesk customer using simple SSO. Customers using SAML SSO were not affected by this issue.

    The SSO vulnerability we discovered in Freshdesk affects Freshdesk customers using single sign-on via their WordPress plugin and any other integration that uses their simple SSO mechanism – so it goes beyond just WordPress SSO integration with Freshdesk.

    Freshdesk has over 70,000 customers and their customers include many recognizable Fortune 500 companies. If any of these companies were using simple SSO in Freshdesk, they were at risk.

    Contact, Fix and Disclosure

    We contacted Freshdesk via their security contact information with encrypted details of the vulnerability on April 20th and unfortunately did not receive a response. So I personally reached out to their CEO via LinkedIn’s InMail on Friday, April 22nd and received an immediate response.

    He initially suspected I might be trying to sell him something, but once he understood the magnitude of the problem we had discovered, the team became responsive and we started moving towards getting a fix into production.

    Freshdesk released a fix to production on April 26th. This fix required that their customers upgrade their software locally. We suspected that they might get push-back from their customers because of the very short upgrade window, so we held off on disclosing this vulnerability. As it turns out, that is what happened and Freshdesk wanted to extend support for the old SSO mechanism until May 3rd.

    Someone on Freshdesk’s forums reverse engineered the fix that Freshdesk had released, figured out that a vulnerability had been fixed and decided to publicly disclose the existence of the vulnerability on the forums. This forced Freshdesk to terminate support for the old SSO mechanism early and they stopped supporting the old mechanism on May 1st, shortening the upgrade time for their customers by 2 days.

    We have verified that, at least for our account, the old Freshdesk SSO mechanism is no longer supported. Freshdesk have posted a full incident report here.

    Comments about Red Team Exercises

    At Wordfence we are required to be PCI compliant and as part of that process we conduct regular PCI scans of our network to ensure it stays secure. We find that the scans provided are not enough to ensure that our network stays as secure as possible so we take the additional step of conducting our own external and internal security scans which go deeper than our regular PCI scan and we fix any vulnerabilities we find.

    In addition to PCI compliance and our own manual scanning, it is Wordfence policy to regularly conduct red team exercises on our network. We do this to ensure that our customer data, source code, infrastructure and intellectual property is protected.

    A red team exercise is a simulated attack that we conduct on our network. The attackers are a small group – one or two people. The team is not given any notification that the attack is going to occur and they are not told when it is in progress. The attackers take care to not impact production systems and their goal is to demonstrate as conclusively as possible vulnerabilities in our security posture. The Freshdesk vulnerability we disclosed today is an example of the product of this kind of exercise.

    The benefit of a red team exercise is that it involves human intelligence and a real life attacker that is analyzing, probing and attacking a network in the same way that a real attack would occur.

    If you are a larger company and have the resources to conduct a red team exercise, I would encourage you to do so on a regular basis and you may be surprised what turns up. Here are a few suggestions to help you conduct an effective red team exercise:

    • The only people who should know about the exercise should be a single top level exec (preferably the CEO) and the attackers.
    • Clearly define what the scope is of the exercise e.g. Define an IP block and the kinds of attacks and applications that may be targeted. Make it clear if external SaaS providers are targets and the kind of targeting that can be done on them.
    • Make it clear that production applications and services should not be put at risk. Customer data should also never be put at risk or removed from site (exfiltrated).
    • Avoid any mention of the exercise to other team members until it is complete.
    • Try to limit the time frame of the exercise as tightly as possible. The reason this is important is because if a vulnerability is found that is serious, it becomes very difficult to fix it while simultaneously keeping the red team exercise a secret.
    • Once the exercise is complete, a comprehensive report should be shared with the whole organization and should result in action items for the decision makers which are prioritized by level of urgency and level of effort.

    Details of the Freshdesk Vulnerability

    We are including the full details of the vulnerability we sent Freshdesk below. If you are a Freshdesk customer, you should have already been contacted by Freshdesk about this vulnerability and should have already upgraded.

    Dear Freshdesk,

    The Wordfence Research Team has discovered a serious vulnerability in Freshdesk. The vulnerability details are below. Please note that we use this product and the impact on the security of our customers and our business is severe.

    As a cloud provider to Wordfence, we require that you respond to this immediately. We require notification that you have received this notice and a timeline of when a fix will be released. We expect this to be given the highest priority in your organization because it impacts your other customers too.

    As per our standard disclosure process, we will notify our customers and the general public about this vulnerability within 30 days or on the day you release a fix, whichever is soonest. [Editor’s note: We decided to hold off on this aggressive schedule to allow the Freshdesk’s customers time to update]

    The vulnerability details are as follows:

    Vendor name: Freshdesk Inc
    Product name: Freshdesk
    Vulnerability type: Horizontal and Vertical Privilege Escalation in Single Sign On
    Date discovered: April 14, 2016
    Vulnerability technical details:

    The Single Sign On/Remote Authentication process described in this article is insecure: https://support.freshdesk.com/support/solutions/articles/31166-single-sign-on-remote-authentication-in-freshdesk

    A user in a third-party system can choose a name and email that, when combined and hashed, matches the hash of another user.

    For example, assume the following user is an administrator of https://example.freshdesk.com:
    Name: John
    Email: john@example.com

    An attacker could create a user account in the third-party system with these values:
    Name: Johnj
    Email: ohn@example.com

    When attempting to use SSO to access https://example.freshdesk.com the attacker can authenticate with the third-party system and capture the SSO login URL:

    https://example.freshdesk.com/login/sso?name=Johnj&email=ohn%40example.com&timestamp=1461184750&hash=ee94aced3a4c27deaa578c88844af418

    The attacker can then edit the name and email parameters to match the admin user (the hash already matches):

    https://example.freshdesk.com/login/sso?name=John&email=john%40example.com&timestamp=1461184750&hash=ee94aced3a4c27deaa578c88844af418

    Re-submitting the request will give the attacker access to the administrator’s account.

    This vulnerability has been successfully exploited using https://wordpress.org/plugins/freshdesk-support/ and https://wordpress.org/plugins/freshdesk/.

    We may confidentially notify interested parties both inside and outside our organization before the announcement date.

    You should be aware that other researchers may discover this vulnerability and announce it prematurely. You should also note that this vulnerability may be exploited in the wild already. For these reasons we encourage you to release a fix as soon as possible to help protect your customers.

    Please notify us as soon as this issue is resolved.

    Kind regards,

    Sean Murphy / Senior Developer / Wordfence
    4948 DD81 CF99 3510 DFF0 44A6 A6D8 401E D683 98F5

    The post Major Vulnerability in Freshdesk – Results from a recent Wordfence Red Team Exercise appeared first on Wordfence.