How I killed BT's payphone email service — Improsec

Timeline

October 10, 2022: Vulnerability theorized
November 23, 2022: Vulnerability tested and confirmed
December 2, 2022: Informed BT about the vulnerability
December 2, 2022: BT acknowledged the report
December 7, 2022: BT claims vulnerability is mitigated
January, 2023: Mitigation confirmed in-person
March 2, 2023: Vulnerability disclosed

Introduction

In October I was strolling around London where I saw a payphone with the label "e-mail". What I just stumbled upon was in fact a British Telecom (BT) payphone which could send emails! (for 20 pence per e-mail).

Now some will say: "How lame, who would need this?", but I obviously thought: "20 pence to send a payphone e-mail!? What a deal! This must be tested!"

Later the same day I found the humorous 4-minute video Sending an Email from an old BT Payphone which should give you an idea of how it feels to send a payphone e-mail.

And what about my test? The first e-mail was sent to a recipient address with a domain hosted in Exchange Online. But as shown in the video, BT Payphones do not only require a recipient address, they also require a sender address for which a @protonmail.com` address was used.

The e-mail looked somewhat like this:

To: [email protected]
From: [email protected]

Hello.
This is sent from a payphone.
Goodbye.

... and off it went! (yes, the GIF below is actually the payphone e-mail being sent)

Side note: some BT Payphones got the classic telephone keypad as shown, while others got QWERTY as in the video.

But just as in the video...

... the test e-mail ended in junk. But how come?

BT Payphone e-mails under the hood

The e-mail headers gave the answer to why it was junked; SPF and DMARC failed:

The mail hops were as follows:

Side note: highlighted in yellow is the common e-mail security risk of message headers leaking internal domain names, internal IPs, and software version numbers.

The headers shows that:

The e-mail was submitted from IP 62.239.224.98 (highlighted in red)
The SMTP "MAIL FROM" header was set to use the domain protonmail.com (the domain used in the message sender address)
The e-mail failed SPF because protonmail.com discourages use of 62.239.224.98 for e-mail submission as the domain does not authorize the IP in its SPF record
DMARC failed because SPF failed and DKIM did not pass.

This just shows that Protonmail's SPF and DMARC works as intended - it is not possible to spoof Protonmail's domain from BT Payphones. However, domains which do authorize 62.239.224.98 in SPF should pass SPF, and since either SPF or DKIM passing will result in DMARC passing†, the e-mail would most likely not be junked.

But who would authorize the IP of a BT Payphone in their SPF? Well.. BT's own domain, bt.com, actually does by authorizing 62.239.224.98/31:

Side note: and so do other BT domains which authorize "include:bt.com" in SPF.

The bt.com domain has the strict DMARC policy p=reject set:

So a hypothesis can be made, that spoofing @bt.com addresses is possible from BT Payphones. But what is a hypothesis without an experiment? What actually happens when a BT Payphone sends an e-mail with @bt.com as the sender? For example, by sending from the address of BT's Chief Data-Protection Officer:

Testing spoofing hypothesis

In the name of curiosity, 20 pence was spent once again, this time from the Chief Data-Protection Officer address `[email protected]`:

The e-mail was received, this time not in junk, but in the Inbox:

The headers confirm that both SPF and DMARC passed:

The submitting IP is again 62.239.224.98, which is in the bt.com SPF authorized range 62.239.224.98/31:

From a third BT Payphone the submitting IP was 62.239.224.99, hinting that all BT Payphone e-mails may come from 62.239.224.98/31 - the range found to be authorized in SPF.

The proves the hypothesis: it was possible to spoof @bt.com addresses from BT Payphones and thereby (by)passing BT's SPF and DMARC e-mail security controls.

Risk assessment and recommendation

Now as this was a risk for BT, it suddenly turned into a responsible disclosure. I therefore contacted BT where I included my findings and the risk assessments of this section.

I assessed that the risk of a successful phishing attempt using BT Payphone spoofing against BT was low to medium:

Any e-mail address of BT can be spoofed, even C-levels
A successfully spoofed e-mail will be presented in the mail user agent (e.g. Outlook) with the photo of the "sending" person, thereby adding to the legitimacy of the spoofed e-mail
Abuse requires physical presence at a BT Payphone and costs 20 pence a pop
BT Payphone e-mails contain a footer which likely alerts target users
- Often headers/footers can be removed with CSS, but not in this case as BT Payphones use the e-mail header Content-Type: text/plain
BT Payphone e-mails cannot mimic e-mail signatures which use HTML+CSS, as BT Payphones use the e-mail header Content-Type: text/plain

I recommended one or more of the following (in approximate preferred order):

Decomission the BT Payphone e-mail feature and its infrastructure
- Decomission is justifyable not only to remove the risk of spoofing, but also to remove risks stemming from operating legacy infrastructure: the message header information leak reveals that Exchange 2000 or 2003 components are likely present (the first hop used Microsoft SMTPSVC(5.0.2195.6713)).
- Decomissionin may also include step #3
Send all BT Payphone e-mails from an IP not authorize in any SPF record
Remove 62.239.224.98/31 from SPF of all BT domains and ensure that no BT Payphone can send e-mail from other SPF authorized MTAs
Remove the possibility for customers to set a sender address, or remove the possibility to set a BT domain in the sender address
Reject or junk received e-mails either containing the BT Payphone e-mail footer, or the "Payphones" hostname header
- Can also be implemented to provide immediate risk reduction

Confirmation of mitigation

The reply from BT was swift, less than a week after reporting they informed that the vulnerability was mitigated by disabling the e-mail functionality on their payphones and the underlying systems:

I later again attempted a spoof to test BT's claims; the payphone allowed writing and sending an e-mail. However, no e-mail was received.

BT explained in detail:

The interface was later confirmed to show "Email Prohibited":

For those wondering about BT's bug bounty policy:

In the end I got BT's 'appreciation' ;-)

Conclusion

More domains than ever are secured with SPF, DKIM, and DMARC††. However, with 80 pence (four e-mails) it was proven that e-mail security is not only using these protocols, but also:

Inventorying all e-mail assets (IPs, domains, MTA, MSA, MUA, etc.)
Regularly reviewing all domains for DNS records forming the SPF/DKIM/DMARC triad, including threat analysis for all possible attack vectors (which requires deep technical understanding of the protocols†††).
Implementing secure e-mail server configuration and patching
Assessing implemented controls, e.g. with penetration tests dedicated to e-mail security, such as a technical phishing test

Some of the above controls have already been covered by posts on the Improsec Tech Blog. Read our posts on e-mail security:

...and to the one UK businessperson who was still using this feature: I killed it. I am not sorry.

References

Thanks to Jeffrey Bencteux for technical ping-pong. Find my socials and blog posts here: https://martinsohn.dk/

† https://www.rfc-editor.org/rfc/rfc7489#section-4.1
†† https://dmarc.org/stats/
††† https://www.rfc-editor.org/rfc/rfc7208, https://www.rfc-editor.org/rfc/rfc6376, https://www.rfc-editor.org/rfc/rfc7489