In July 2020 7 Elements discovered a vulnerability in Rackspace that exposed all its global hosted email customers to the potential malicious use of their email domain by unauthorised actors. Malicious actors had the ability to leverage multiple accounts and pass security checks designed to detect spoofed emails. This was utilised in the wild to conduct targeted phishing attacks.

7 Elements has called this the “SMTP Multipass” attack.

The vulnerability was the result of how the SMTP servers for Rackspace (emailsrvr.com) authorised users. When this vulnerability is placed within the context of Rackspace’s guidance on customers specifically authorising these SMTP servers to send email on their behalf via DNS entries (denoting the use of SPF records), it can be used to form a viable attack vector.

This allows an attacker, authenticated under one customer account to send emails as another customer. Those emails would be received by the recipient, pass email security checks and be identified as a legitimate sender. Given this, malicious actors could use this to masquerade as a chosen target domain, potentially causing reputational damage.

The vulnerability was discovered by the 7 Elements team through our incident response service back in July 2020. 7 Elements engaged with Rackspace, through our responsible disclosure process, at the start of August 2020.

The Incident

Whilst supporting a client’s internal investigation into a targeted email compromise incident, our team and the client’s technical team worked together to assess inbound emails. This collaborative approach identified that the malicious actor(s) involved with the business email attack was sending emails using Rackspace customer domains. However, it was noted that when doing so the actor(s) authenticated with a user account under a different domain, successfully spoofing Rackspace hosted email customers, passing SPF controls.

By using this approach, the malicious actor was able to bypass the clients email filters and was free to choose from a large pool of suitable domains that make use of Rackspace’s hosted email offering.

This prompted further investigation by the 7 Elements team, which ultimately identified that any customer of the hosted email service was vulnerable to this issue. This was especially the case if their SPF records were set to pass emails from emailsrvr.com (as recommended by Rackspace). Based upon conversations with Rackspace, our understanding is that all customers of the hosted email service were vulnerable. Clients included US federal agencies, UK local government, military, politicians, financial organisations and high-profile individuals.

Force Multiplier

In this instance, two individual issues combine to have a greater impact. The first is the vulnerability within the Rackspace hosted email service that allows an authenticated user of the platform to send emails as any domain (including those that also use the service). The second is in how DNS entries configured by legitimate customers of Rackspace specifically authorised the affected Rackspace SMTP servers (emailsrvr.com) for the purpose of sending emails on behalf of that domain. So, any email coming from that IP on behalf of that domain is de facto authorised. The following image shows such an email:

In the Wild

As stated earlier, we are already aware of this vulnerability being utilised in the wild. With our internal POC scripts, it was a trivial exercise to identify vulnerable domains and then using a single account, authenticate to the SMTP server and send emails from those other domains. From an investigation point of view, as the email will appear to be legitimated (passing SPF security checks), the email headers would need to be interrogated for specific traits as outlined below:

Date: Thu, 24 Sep 2020 14:02:18 +0000
To: 7 Elements <contact-us@7elements.co.uk>
From: Finance <finance@**redacted**.com>
Reply-To: Finance <finance@**redacted**.com>
Subject: SMTP Multipass

X-Mailer: PHPMailer 6.1.7 (https://github.com/PHPMailer/PHPMailer)
Received-SPF: Pass (protection.outlook.com: domain of **redacted**.com designates
146.20.161.126 as permitted sender) receiver=protection.outlook.com;
client-ip=146.20.161.126; helo=smtp126.iad3b.emailsrvr.com;
X-Auth-ID: john@7ei.cc
Authentication-Results: spf=pass (sender IP is 146.20.161.126)
smtp.mailfrom=**redacted**.com; 7elements.co.uk; dkim=none (message not signed)
header.d=none;7elements.co.uk; dmarc=pass action=none
header.from=**redacted**.com;compauth=pass reason=100
Received: from smtp126.iad3b.emailsrvr.com (146.20.161.126) by
HE1EUR02FT008.mail.protection.outlook.com (10.152.10.77) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.3412.21 via Frontend Transport; Thu, 24 Sep 2020 14:02:20 +0000

Example email header with highlighted fields of interest.

Please note, the sample headers above are from one of our test emails against a live domain (hence the redacted content). The key header fields of interest are highlighted to show the email ‘from’ and ‘to’ as well as various checks being passed. 

Specifically, to identify this exploit we are looking for an X-Auth-ID value that does not match the ‘From’ address (usually at the domain level). In addition, the sending server “emailsrvr.com” indicates Rackspace being the sender. The malicious actors we have found to be using this in the real world also made use of PHPmailer to send the email, although this would not be required to exploit the vulnerability.

For our test, we used a trial account (7ei.cc) within Rackspace to send an email as another domain that had the relevant SPF records. A malicious actor could have done the same or as with the real-life cases we have investigated use compromised accounts.

Summary

As you can see, the main impact of this vulnerability would be with a malicious actor being able to send emails as any domain using the Rackspace hosted email solution, and one we have already seen in use by malicious actors with a focus on business email compromise attacks.

By sending email as another domain, the malicious actor can leverage the trust of that brand to coerce clicking on a link for a phishing style attack or potentially using the domain to send content that could result in reputational damage or even financial fraud though malicious invoicing-based attacks.

Disclosure Timeline

• 20th July 2020 – Client receives phishing email using this technique to achieve business email compromise (with intent to conduct financial fraud).
• ~30th July 2020 – 7 Elements provides assistance to client’s internal team and to collaboratively identify this technique and are able to reproduce it.
• 7th August 2020 – After finishing up our incident response effort we confirmed with the client that they would like us to report the issue to Rackspace. This contact is made to security@rackspace.com.
• 7th August 2020 to 25th August 2020 –  Communication with Rackspace around verifying the issue, the timeline for fixing the issue and ethical considerations of disclosure. Rackspace confirms that internally they are already aware of the exposure. Agreement to follow standard 90-day responsible disclosure window after a commitment by Rackspace to work toward fixing the issue.
• 15th September 2020 – Rackspace provide 7 Elements with an update to advise that another party has also discovered the exploit and notified them.
• 3rd November 2020 – Rackspace provide 7 Elements with an update to advise that customer-specific communications went out on the 29th October to advise of the issue, with a fix planned to start on the 5th November 2020.
• 5th November 2020 – Agreed disclosure date.

Image credit: Waverley Jane Media

The business landscape has undergone a sudden, drastic shift to remote access, in order to cope with the current social isolation requirements. Commensurately, the usage of video conferencing applications has skyrocketed. Perhaps the video conference tool that has most benefited from this change in business model is Zoom. The company has seen a huge boost in popularity, with reports of up to a 535% increase in traffic[1].

Wide adoption can help reduce the burden of continued operations challenges faced by a company, and a simple, reliable and flexible platform is an IT teams dream. In spite of this, a number of security concerns persist within the Zoom platform, which should be taken into account when looking to implement within an organisation’s operations.

Challenges in vulnerability remediations

The core security concerns raised around the Zoom platform to date, related to the ability to perform video-chat hijacking, insufficient end-to-end encryption, and a number of recently discovered vulnerabilities within the client installed on a user’s device. One issue previously identified within the software, related to privilege escalation on Mac OSX device, which may be leveraged to achieve malicious code execution, or in the case of a malicious actor, be used as an entry point into an organisation’s wider infrastructure. Another concern related to sensitive information disclosure that may be allow an attacker to manipulate a user into leaking their user credentials inadvertently[2].

Ever Evolving Threats

While these issues had been previously identified and were obviously a concern for people using the platform, with such a significant increase in user base, this has led to security researchers and malicious actor seeking to identify attack vectors within the software to target users. This has resulted in three Zero-Day vulnerabilities in the software being identified and publicised during the first 3 days of April 2020. The first two vulnerabilities[3] may allow an attacker to inject malicious code within a Zoom installer to achieve privilege escalation. This may be used in tandem with other attack vectors such as a phishing attack to target individuals or organisations.

Another vulnerability identified may allow a malicious actor to perform a malicious code injection attack that would give the attacker equivalent access rights to that of the Zoom application, meaning they would be able to intercept and spy on users via the microphone and web cam used as part of the chat.

The final issue, which was raised publicly on April 3rd 2020[4], related to the use of inadequate data encryption, which appeared to be an in-house implementation. It is highly recommended to avoid ‘rolling your own’ cryptography implementation and to use established and comprehensively reviewed methods that are widely available. The encryption implementation Zoom use was determined to contain flaws which in some instances may allow encrypted data that has been intercepted to be decrypted.

Slow start, but a rapid response

While Zoom have acknowledged the presence of these issues and have announced publicly that they are in the process of resolving them, concerns persist about the nature of their ongoing security activities and processes. Security researchers have been critical previously of the response times between disclosure of bugs and remediation by the company. On March 30th 2020, New York’s attorney General, Letitia James, contacted the company requesting an outline of the security measures that Zoom are undertaking to resolve these issues, as well as safeguard the platform, particularly due to the swell in its user base[5]. Zoom published an open letter on their public blog detailing the steps they have taken already, as well as steps they will be taking over the next 90 days to improve the security posture of the platform as a whole.[6]

The steps highlighted will include a freeze on new features to allocate developers to resolving open security issues and platform hardening. They intend to engage with third parties such as security architects and penetration testing firms to perform audits and security assessments on the platform, enhancing their existing bug bounty platform and employing methods of transparency with users to allow them to understand what is done with their data, and whom it may be shared with. They have also released security fixes for Mac OSX and Microsoft Windows clients to remediate a number of the vulnerabilities publicised.

In reality, while the flaws raised publicly so far are concerning, they should be considered in context. Many of them require at least a low privileged user account on local devices, which may significantly reduce the likelihood of a successful device compromise, unless another attack is successful to gain that initial access. In the matter of the encryption implementation, the significant resources required for a successful attack to be performed make it a fairly low risk attack vector, and the majority of users would be unlikely to be legitimate targets.

Conclusion

As with any adoption of new conferencing technology during this period of change, organisations should ask themselves if they are comfortable with what is being discussed over the conferencing platform and what adverse impact could intentional or unintentional disclosure of that content cause the business.

Further consideration should be given to any risks that the installation of software could bring to the integrity of end point devices. While Zoom are now clearly in the headlights, and will undoubtably take additional steps to assure organisations that they can deliver, so the increased attention is likely to result in further security concerns being identified.

Matthew Linney (Senior Consultant)

References:

[1] https://www.theguardian.com/technology/2020/apr/02/zoom-technology-security-coronavirus-video-conferencing

[2] https://blog.rapid7.com/2020/04/02/dispelling-zoom-bugbears-what-you-need-to-know-about-the-latest-zoom-vulnerabilities/

[3] https://objective-see.com/blog/blog_0x56.html

[4] https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/

[5] https://www.digitaltrends.com/news/new-york-attorney-general-is-latest-to-question-zooms-privacy/

[6] https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/