This post was originally published on this site

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.

Share This