Compromising the email supply chain of 190 Australian organisations through a single IT Managed Service Provider

A week prior to writing this article I decided to run an experiment... I would do a one-time scan on a few hundred Australian organisations to see if any of the IP addresses listed in their SPF records overlapped with the public IP ranges offered by AWS and Azure. I would then check to see if any of the IPs had been released and were available for re-use. The outcome would be to see if I can send SPF authenticated emails from the scanned domains and ultimately report the vulnerabilities back to those organisations affected.

So that's exactly what I did. I ran the scan and began filtering through the results.

What is SPF? The Senders Policy Framework (SPF) is a public record that organisations publish on their Domain Name Server (DNS) and it typically contains a list of IP addresses that tell receiving organisations where they can expect legitimate and authorised emails to originate from.

Snagging the first IP address

Upon first inspection I found something that stood out... A local city council had added a bunch of /16 address blocks to their SPF record that overlapped with the AWS IP ranges allocated to Virtual Machines (i.e. EC2 instances).

This particular city council had an SPF record so extremely over-permissive, I found myself wondering... what were they thinking? They included every IP address that AWS reserves for EC2 instances in Australia - 1,048,544 IP addresses.

What's the problem with this? If an IP address in AWS isn't actively being used or reserved by a customer, another customer can come in and snag that IP. Since this particular city council had included every IP, effectively any EC2 instance spun up in AWS' ap-southeast-2 region (Sydney Australia) would include an IP address that was authorised to send on behalf of this domain.

I decided to test this out and as suspected... the first EC2 instance I spun up had an authorised IP address and I was able to send myself an SPF authenticated email from this particular city council which went straight into my inbox - passing all SPF and DMARC checks.

Doing some open-source intelligence

I had a hard time wrapping my head around why someone would configure an SPF record like this, so I decided to try and investigate the reason.

Enumerating the Managed Service Provider

Almost immediately upon visiting the Precedence Group website I was greeted with a navbar that included a Portfolio link. At this point I'm thinking, maybe there's 5 or 10 reference companies at most...

But no... Precedence Group decided it was a good idea to include nearly every organisation they do business with... and not just a company name or logo but also the customers domain name.

After clicking through a few websites I also noticed that Precedence Group includes a snippet of text at the bottom of each website they design that says "web design by precedence".

I then decided to scrape Google for all websites with the keyword "web design by precedence" and also scrape the Precedence Group Portfolio page for all customer domains. I ultimately landed on a list of 329 customer domains.

Jackpot!!!

Reeling from the shock that I was able to scrape 329 customer domains (225 from the website, 27 from google and 77 through other means), I decided to reinitiate the same scan that led me down this path to begin with... except this time I would focus solely on Precedence Group customers.

After a few minutes I had the result... This same 'pre.net.au' SPF lookup was present on 190 of the 329 customers that Precedence Group provided IT services towards. These 190 customers are far ranging and include organisations from City Councils, Financial Advisors, Freight Services, Financial Lenders, Law Firms, Construction Companies and much more...

How long has this been going on!?!

The next question I found myself asking was how long have these organisations and their down-stream customers been at risk?

To discover this, I had to run a historical DNS lookup and track when the vulnerable SPF record was originally created. Fortunately I found the domain had been getting tracked by an online tool called SecurityTrails. It was then highlighted that this extremely overpermissive SPF record was created nearly 3 years ago, with organisations potentially being vulnerable since then.

What's the risk?

Each of the affected 190 organisations and their downstream customers are at an extreme risk to business email compromise and phishing-related attacks. Anyone with a credit card can sign-up for an AWS account, spin-up an EC2 instance, request AWS to remove any SMTP restrictions and begin sending SPF authenticated emails as though they are any of these organisations.

Wrapping up

Controlling your mail sender supply chain is absolutely critical to ensuring your organisation and customers aren't introduced to unnecessary risks relating to email-based threats. By utilising the free domain scan tooling created here at CanIPhish, you can visualise the full extent of your email sender and receiver supply chains.

The research conducted to identify these vulnerable organisations is still in it's early stages. Over the coming weeks/months I fully expect more organisations will be identified as I begin expanding the scope of these scans and refine the approach. Should you have any questions, please feel free to reach out and contact the team by email.

Note: The vulnerabilities highlighted as part of this blog post have since been remedied by the MSP.