SMTP Multipass

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