The "Ronald Reagan" Attack Allows Hackers to Bypass Gmail's Anti-phishing Security

By Yoav Nathaniel, ‎Customer Success Manager, Avanan

We started tracking a new method hackers use to bypass Gmail's SPF check for spear-phishing. The hackers send from an external server, the user sees an internal user (For example, your CEO) and Gmail's SPF-check, designed to indicate the validity of the sender, shows "SPF-OK."

Why are we calling this "The Ronald Reagan Attack"? Several of these attacks originated from reagan.com, a website that offers a private email with the domain name of Ronald Reagan, the 40th president of the United States, encouraging its users to "be a cowboy."

If you are a Gmail for Business customer and suffer from phishing attacks, you might find some comfort in knowing that the lives of Office 365 users are much worse. Maybe it's because hackers target Office 365 more, maybe because Google does a better job in filtering phishing attacks, but the end result is that Gmail users get less phishing.

How The Ronald Reagan Attack Works

At the core of the attack is the fact that when Gmail's anti-phishing layer scans the email for impersonation and performs an SPF check, it looks at one "sender" field in the email header but the sender name presented to the human receiver of the email in the Gmail web interface, is taken from another field in the email header.

There are two fields in the email header that play a role here:

1. X-Sender-Id: This is the field that Gmail uses in its SPF-check and and is used for spear phishing and impersonation analysis

2. From: This is the field that is actually presented to the Gmail user

The result is that the machine that tests for phishing finds this email completely legitimate and passes it to the recipient with no warning. But for the recipient, this shows up as an email from someone else, presumably someone in the organization that they know. The recipient has no practical way to find the actual value of the X-Sender-Id field.

Here's an example of a real such attack and why it was effective:

(1) X-Sender-Id - This is the real sender. It is the most important part of the attack because in fact it is not spoofed. It is well aligned with the server that sent the email.

(2) The "Reply To" header is presented to the end-user but the actual reply goes to a field called "Return-Path" (Field 5 below). This is also spoofed - it uses the impersonated victim name in a domain that doesn't exist (And indicates the usage of a mobile phone)

(3,4) Authentication-Results, Received-SPF and Arc-Authentication-Results: These are the fields that indicates the receiver's (Gmail) calculated authenticity of the email. Note that in all tests, the email address from the X-Sender-ID is selected as the identity to test with (As indicated in the X-Auth-Id field) and that all tests pass successfully - the email is 'authentic'

(5) Return Path: This field is what the mail server would use if the end-user chooses to reply to sender. The hackers spoofed the "Reply To" field with an address that is presented to the end-user but does not exist, however any actual reply from the recipient will be routed to the attacker.

(6) From: This is the actual attack - the email address of the impersonated sender. The field was used nowhere aside from when it is presented to the recipient!

What Is Google Doing About It?

A quick search in Google's reporting system reveals that they don't see SPF vulnerabilities as critical. Therefore, not prioritized to be fixed. If we hear differently, we will update this blog.

What Can I Do?

In many phishing attacks we described, we started by the regular 'educate your users', 'suspect every email', 'look at the links', etc. etc. But this is one examples when the end-users can do nothing. Their email client shows an authentic email of an internal sender and there's no warning in the email to indicate anything is wrong with it. In this case, you do need another layer of security on top of the default security from Google.