Ghost Emails: Hacking Gmail’s UX to Hide the Sender

Faking the Appearance of a System Message in Gmail

This article complements my previous identification of flaws in the way Gmail’s UX interprets the From field in email headers. By tailoring a malicious input in a certain way the Gmail app leaves the sender display completely blank both in the list view and in the detailed email view. This could be further weaponized for phishing attacks based on faking the appearance of official warnings or system messages.

Updated 2018–12–11: Google has resolved this issue and issued me a $1,337 bughunter reward through Google’s Vulnerability Reward Program. (I appreciated the “Leet” reference!)

A Man is No One

Hot off of discussions with other security-minded folk like Eli Grey who had previously reported critical Gmail UX bugs to Google with mixed results, I decided to try a few more derivatives of the initial attack vector identified in my previous article about forging the From field: here.

I decided to substitute a portion of text from the From: "name, recipient_email_here" <sender_email_here> test case with something large and arbitrary, like an <object> or <script> or <img> tag.

The result shocked me:

A completely blank sender.

Surely You Can’t Be Serious

“OK”, I thought, “No doubt it will show at least the sender email address itself inside the email, right?”

Wrong. The section of the Gmail UX that would show the sender is missing — there’s nothing to hover over.

“What if I click the Reply button,” I reasoned, “That will at least read the original email headers and populate the return address, right?”

Wrong again! Gmail is at a complete loss at what to do!

Are the email headers broken? Did Google’s mail server somehow accept my test email but stripped out the From field?

Under the Hood: Headers are Fine, UX is Not

Here’s what Google displays when you click on the “Show original” option.

Notice how the From field summary up top is blank. However, further down in the actual text you can see my fuzzing test case using the <img> tag:

To: tim@cotten.io
Subject: A completely innocent email header
From: "Tima <img src='data:imaige/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZ",
        <root@myserverhere.com>

Did I get you?

It was the combination of the quoted alias, a preceding word, space, and the long base64 badly encoded img tag (note the misspelling).

As you can see, the header itself was preserved and parsed by Google, but the UX simply can’t handle it.

A normal HTML snippet when displaying the From field in an email on the Gmail app looks like this:

<span class="qu" role="gridcell" tabindex="-1">
  <span email="root@myserverhere.com" name="root@myserverhere.com" data-hovercard-id="root@myserverhere.com" class="gD" data-hovercard-owner-id="21">root@myserverhere.com</span>
</span>

But ours looks like this:

<span class="qu" role="gridcell" tabindex="-1">
  <span email="" name="" data-hovercard-id="" class="gD"></span>
</span>

Yet Another Phishing Vector

Now, imagine, if you will, a more malicious email arriving in the average Gmail user’s inbox that looked a bit more like this:

Without the sender information there this looks completely legitimate and a well-educated user could easily be suckered into compromising their own account.

What Else Could They Have Done?

Admittedly, the fact that the HTML tags were empty was a good approach to finding arbitrarily bad data when constructing the UX.

However, an email with this kind of crazy forged From field should never have been accepted by the Gmail server in the first place. The fact that it may not trip on the RFC 2822 specifications isn’t an excuse not to do strict checking of the header fields themselves.

Rather, it would be better that a solution like Joran Greef’s project ronomon were employed to prevent these issues at the time the email hits the mail server boundary in the first place.

Summary

• It’s worse than the last one.
• I reported it.
• Google resolved the bug and issued me a $1,337 reward as part of Google’s Vulnerability Reward Program.