INSERT - Exploiting the Trust Hierarchy among Email Servers

	8th Brazilian Symposium on Information Security Take this chance to visit one of Brazil's most beautiful cities. Paper Submissions still Open!

Exploiting the Trust Hierarchy among Email Systems

Pablo Ximenes, Andr dos Santos
INSERT - Information Security Research Team
University of PR at Mayaguez (UPRM), USA; and State University of Cear (UECE), Brazil
pablo.ximenes@upr.edu, andre@dossantos.org

Introduction

Spam messages have surged to outrageous levels currently representing 95% of all email communications throughout the Internet. Because of that, it is simply not feasible to apply the full power of spam filtering to every single message that is received by email servers. This problem is tackled by the use of blacklists of IP addresses of spam offenders and whitelists of known good sources. This way, messages from blacklisted IP's are reject before even entering the system, and whitelisted addresses are granted 'Carte blanche' to bypass most of the filters. Although the burden on spam filtering systems is certainly lowered by this model, the dynamic it brings generates an ad-hoc trust hierarchy among email providers that might be based on nothing more than mere convenience.

This problem represents a growing risk to email users and providers that needs to be addressed. As part of our ongoing study on the trust hierarchy that exists within the Internet's email system, we came across with a serious security flaw that is directly related to the problem we are currently investigating.
In this sense, we have found a strong example of our argument by uncovering a flaw in Google's free email service, Gmail. In this regard, this document presents a vulnerability report and a proof of concept attack that demonstrate how anyone with no special internet access privileges other than being able to connect to SMTP (TCP port 25) and HTTP (TCP port 80) servers is able to abuse a single Gmail Account in order to be granted nearly unrestricted access to Google’s massive white-listed SMTP relay infrastructure.

The presented vulnerability enables an attacker to bypass blacklist/whitelist based email filters and freely forge all fields in an email message by having Google’s SMTP servers tricked into behaving like open SMTP relays. We were able to confirm that this vulnerability is indeed exploitable by assembling a proof of concept (PoC) attack that allowed us to use one single Gmail account to send bulk messages to more than 4,000 email targets (which surpasses Gmail’s 500 messages limit for bulk messages). Although we have limited the number of messages in our example to 4,000+, no counter measures took place that would have prevented us from sending more messages, and for that matter sending an unlimited number of messages. Additionally, we were able to use this vulnerability to forward messages that originally were classified as spam directly to a victim's inbox effectively bypassing filters. The attack specifically exploits Gmail’s email forwarding functionality. This is possible because no restriction or verification is imposed during the setup process of this option. We were able to write a program that automatically exploits this flaw in a compromised Gmail account to send bulk and forged messages to an unlimited number of email addresses while preserving all of the message’s original fields (legitimate or forged) unaltered, including sender's identity data (From: field).

Since attack messages are carried by Google's own SMTP servers, the blacklist/whitelist based trust hierarchy that exists between Google’s and other Third Parties’ email servers is compromised, effectively converting Gmail’s servers into the perfect spam/phishing aid. With this flaw, spammers need only to compromise one Gmail account in order to obtain results similar to those of a botnet based spam. To our best knowledge this is the first public description of this vulnerability and also the first proof of concept attack. Google has already been notified about this issue and we are waiting to hear from them before releasing further details.

Vulnerability

The vulnerability we present is related to the possibility of abusing the message forwarding option in Gmail accounts which is facilitated by Gmail’s reliance on user input to influence its spam filters. In order to proper describe the problem, we will first review parts of Gmail’s structure that are related to the issue to later expose the complete vulnerability.

Message Forwarding
Gmail’s message forwarding option enables a regular Gmail user to have her email messages forwarded to a different email account. It is important to notice that the receiving account can belong to any email system and not necessarily Gmail’s. Gmail’s email forwarding can be setup up either by activating the global forwarding option or by creating a filtering rule that forwards all messages to a different email address. Figure 1 shows Gmail’s configuration interface for its email forwarding option.

Figure 1. Gmail’s message forwarding feature

It is up to the Gmail user to make sure the email address used in the forwarding configuration actually belongs to her since Gmail will not ask for any proof of ownership. The only verification performed by Gmail concerns the format of the address that must comply with the general guidelines for email addresses.
After message forwarding is enabled and configured, the general behavior of this option is to forward messages that are not marked as spam to the email destination chosen by the user. The underlying technical setup that occurs to an email message during this process happens as follows.

The message is delivered to one of Google’s incoming Mail Transfer Agent (MTA) servers.
Google’s incoming MTA server will route the message to the intended user account. If the message is addressed to an email account that does not belong to Gmail or to a company hosted by Google, a 500 error message will be displayed and the process is aborted. The abortion is done to avoid the use of Google’s MTA servers as SMTP relays by unauthorized external parties.
After reaching the Gmail user account, the message is classified to be forwarded (i.e. matching filtering rule and/or not spam)
Extra headers are added to the message body to account for the forwarding process.
One of Google’s outgoing MTA servers establishes an SMTP connection to the forwarding target’s input MTA server.
Google’s outgoing MTA server will set the return path (‘Mail From:’ SMTP command) to an address that belongs to Gmail’s domain. This address is structured in the form ‘GMAILUSER+caf_=TARGETUSER=TARGETDOMAIN@gmail.com’, where GMAILUSER is the Gmail account’s user name, TARGETUSER is the target’s email domain user name, and TARGETDOMAIN is the domain name (e.g. example.com) of the forwarding target. Considering the Gmail account attacker@gmail.com and the forwarding target target@example.com, the address would be ‘attacker+caf_=target=example.com@gmail.com’.
Google’s outgoing MTA server will issue a “RCPT TO:” command containing the target’s email address as argument.
Google’s outgoing MTA server will issue a “DATA” command after which it will send the original message body almost intact except for the extra headers added in step 3.
The SMTP connection between Google’s outgoing MTA server and the target’s incoming MTA server is terminated and the message is queued for delivery on the target’s system.

Spam Message Whitelisting
An interesting feature found in Gmail is the ability users have to fine tune their spam filtering settings by whitelisting messages that were classified as spam. The whitelisting is done by displaying the message that was classified as spam and clicking the ‘Not Spam’ button. After that, the message will be moved to the inbox. In addition to the original message, Gmail will whitelist any message that follows the same patterns by which the whitelisted message was masked as spam. The consequence of the whitelisting is that if the same message is to be sent again, using the same server, it will no longer be classified as spam. The ability to whitelist (mark as ‘not spam’) and to blacklist (‘mark as spam’) messages for individual accounts is one of the strongest supporting mechanisms of Gmail’s spam filters, since they rely on a collaborative approach that samples the input from all users on blacklisting and whitelisting to correctly identify spam messages.

The Problem
The vulnerability is exploitable due to three features that in an isolated manner can be thought as inoffensive. That proves another well known point that the combination of otherwise inoffensive features can result in an exploitable feature. Systems, particularly complex ones, have to be well analyzed in their totality so security vulnerabilities can be identified. The three features are:

a) No proof of ownership of the email address that is used as target for the message forwarding option in Gmail accounts is required. A Gmail user can easily setup her account to forward messages to any email address in the Internet, since no verification of ownership is done.
b) No limit is imposed on the number of times a Gmail user can change the email address used as target in the message forwarding configuration.
c) Gmail users can whitelist a spam message.

These functionalities just mentioned can be abused by a malicious user and together can be used to assemble a powerful spam attack. The attack can be performed as to be used by spammers in the following fashion:

Whitelist the attack message. Since the attack message will probably originate from a blacklisted IP address and might contain other indicators that will make Gmail flag it as spam, the message needs to first be whitelisted (i.e. marked as ‘not spam’) before it can be forwarded.
Change the email address destination in the message forwarding option.
Deliver the attack message addressed to the compromised Gmail account using one of Google’s MTA servers.
Repeat steps 2 and 3 for every email address in the list of addresses to be spammed effectively sending the attack message to all addresses.

Gmail will deliver the message to the attack targets without modifying any of the SMTP fields, including sender’s identity. This is done so because the attack message is originally disguised as a message that is legitimately destined to the compromised Gmail. Since these messages are normally expected to come from a different domain and the forwarding process inevitably keeps forwarded messages intact as to be faithful to the original delivery, the attack message will be forwarded to each of the victims preserving the same contents it was originally sent, including spoofed sender’s identity. .Since attack messages can be performed at the attacker’s will and can be forwarded any number of times, this vulnerability is both a spam and a phishing threat concern.

Proof of Concept Experiments

To seek proof that the vulnerability described here is indeed exploitable, we have designed a set of experiments that finally led us to the observation that Gmail can be effectively abused by a malicious user almost in the same fashion open relay SMTP servers can be abused.

Assessing Gmail’s Protections against Bulk Messages
Initially, we decided to assess the workings of Gmail's protections against bulk messages related abuse. The first thing we decided to evaluate was the limit of messages Gmail actually would allow one to send in one day using its system the regular way. To test this feature, we have sent messages via the Web Interface and via the authenticated STMP interface until we have reached a point where Gmail started blocking out attempts to send more messages. The experiment consisted of sending the same message several times to different email addresses via SMTP and Web. Gmail has effectively locked our test accounts and prevented us from sending any more messages using the regular interfaces (i.e. SMTP, Web) as soon as we reached the 500 cap. In a related experiment we tried to use the SMTP interface to send a message with spoofed sender information. Even though the message was properly delivered, Gmail had rewritten the sender identity information to reflect that of the account’s owner, thus effectively preventing us from spoofing sender identity using Gmail’s regular interfaces.

Assessing Gmail’s behavior against the described attack
The first test we performed to evaluate Gmail’s reaction to the described attack was to send isolated messages with spoofed (i.e. fraudulent) fields. Particularly we have forged sender identity information and date/time fields. This experiment revealed that indeed Gmail had no protections in place to prevent defrauding the SMTP protocol in this manner.

After we already had been able to effectively send a spoofed message, we needed confirmation to if an attack could be crafted to send a large number of messages. This way, we assembled a program that reads a list of email addresses from a file and sends a forged message to the entire list using the described attack method.
By using a broadband Internet connection and one Gmail account, we were able to use our program to send a bulk message to more than 4,000 email targets (in a domain under our administration) in approximately 6 hours. No measures took place that would have prevented us from keeping sending more messages. Even though the average of 11 messages per minute seems low, it is important to notice that our demonstration exploited only one Gmail account. By exploiting a larger number of accounts the attack could improve its message rate significantly. For instance, by deploying this attack with 100 Gmail accounts simultaneously the message rate would exceed 1,000 messages per minute. This fact shows that by compromising a relatively small number of Gmail accounts it is possible to assemble an attack that would have results similar to those of a botnet based spam, but without the need for thousands of zombie computers.

Assessing the Trust Relationship between Gmail and other systems
The third part of our experiment was designed to assess the trust relationship between Gmail and other third parties' email providers. This way, we have opened test accounts in two of the other major free email providers: Yahoo and Hotmail. The experiment consisted of sending forged messages from blacklisted IP addresses (our computers) directly to Hotmail's and Yahoo's MTA servers directly and sending the same messages using our PoC program (i.e. though Gmail's servers). We were able to confirm that indeed messages sent through Gmail’s infrastructure had special treatment by Hotmail and Yahoo.

Delivered-To: victim@example.com
Return-Path: <attacker+caf_=victim=example.com@gmail.com>
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184])
        by mx.example.com with ESMTP id i5si4683640mue.2.2008.05.12.09.38.07;
        Mon, 12 May 2008 09:38:09 -0700 (PDT)
Received-SPF: pass (example.com: domain of attacker+caf_=victim=example.com@gmail.com designates 209.85.128.184 as permitted sender) client-ip=209.85.128.184;
Authentication-Results: mx.example.com; spf=pass (example.com: domain of attacker+caf_=victim=example.com@gmail.com designates 209.85.128.184 as permitted sender) Received: by fk-out-0910.google.com with SMTP id 18so1981820fks.2
        for <victim@example.com>; Mon, 12 May 2008 09:38:07 -0700 (PDT)
Received: by 10.82.173.1 with SMTP id v1mr831893bue.68.1210610286909;
        Mon, 12 May 2008 09:38:06 -0700 (PDT)
X-Forwarded-To: victim@example.com
X-Forwarded-For: atacker@gmail.com victim@example.com
Delivered-To: attacker@gmail.com
Received: by 10.82.185.4 with SMTP id i4cs82084buf;
        Mon, 12 May 2008 09:38:06 -0700 (PDT)
Received: by 10.100.8.10 with SMTP id 10mr8466460anh.54.1210610285273;
        Mon, 12 May 2008 09:38:05 -0700 (PDT)
Return-Path: <news@reuters.com>
Received: from attacker.domain.name.example.com (attacker.domain.name.example.com [10.20.30.40])
        by mx.google.com with ESMTP id d24si13903701and.24.2008.05.12.09.38.04;
        Mon, 12 May 2008 09:38:05 -0700 (PDT)
Received-SPF: neutral (google.com: 10.20.30.40 is neither permitted nor denied by domain of attacker@badexample.com) client-ip=10.20.30.40;
Authentication-Results: mx.google.com; spf=neutral (google.com: 10.20.30.40 is neither permitted nor denied by domain of attacker@badexample.com) smtp.mail=attacker@badexample.com
Message-Id: <48ee726d.1aae110a.13a8.eeffc9b7SMTPIN_ADDED@mx.google.com>
Date: Fri, 02 May 2008 11:30:46 -0400
From: "Attcker" <attacker@badexample.com>
To: "Happy Victim" <victim@example.com>
Subject: bulk message

Hello,

Help us fighting SPAM! Take part in our experiment and understand where you can improve your security.

Best Regards,

Experiment People

Listing 1. Attack message source code after final delivery

Some messages would not even reach the spam box when sent directly, while when relaying the same messages through Google's servers by using our program the messages were promptly delivered directly in the inbox. We conjecture that this behavior was facilitated by the fact that Gmail changes the return-path email address of forwarded messages to an address belonging to its own domain (as explained previouslty). This will result in an SPF successful check, since the message is delivered by one of Google’s server. This can be observed in listing 1 that shows the contents of one of the messages we have forwarded though Google’s system during our experiments.

The observed behavior for the SPF filter is actually the recommended behavior of RFC4408 for message forwarding which states that in order to avoid failed SPF checks, domains should replace the return-path of forwarded messages by an address belonging to the local domain. Additionally, RFC4408 also states that the “SPF authorization check is a check between border MTAs of different domains”, what makes Yahoo and Hotmail potentially ignore SPF headers with non-successful and/or failed results from previous SPF checks inside the message body.

Assessing the limit on message forwarding setup changes
The way Gmail handles its message forwarding configuration is the main part of the vulnerability we are presenting and the core part of a possible attack. This way, we decided to verify if there was any limit imposed by Gmail on the number of times we would be able to change the email address destination for Gmail’s message forwarding option. The experiment consisted of a procedure that changes the message forwarding address destination to a randomly generated email address and a second procedure that verifies if the change is successful.

In our experiment we were able to successfully change the email address destination in Gmail’s message forwarding option over 10,000 times in a single run. No countermeasures were taken by Google’s systems that would have prevented us from keeping changing addresses.

Impact

By having Gmail's servers relay messages in behalf of an attacker, this flaw compromises the very trust hierarchy among email providers. This way, all email providers that offer Google's SMTP servers any level of trust (e.g. whitelist status) are vulnerable.

Mitigation

The vulnerability in Gmail can be easily mitigated by Google by just requiring proof of ownership of the email target during the setup process of message forwarding. This can be accomplished by means of a simple challenge response mechanism, much like the one Gmail already implements for the personalized sender identity (i.e. 'From:' field) feature.

It is important to notice that although one could propose a solution of limiting the number of changes on the forwarding address, this solution would be incomplete. Solutions that simply limit the number of times a user can change the email destination in Gmail’s message forwarding configuration will only avoid the problem of sending messages in bulk while doing nothing to prevent attacks that spoof message body fields (e.g. phishing). Nevertheless, any solution that might require limiting the daily number of forwarded messages would be inappropriate since this approach would unavoidably impair the legitimate use of Gmail’s message forwarding feature.

Third party email providers might mitigate the presented vulnerability before Google provides a solution by flagging messages from Google’s Servers containing email forwarding message body fields (e.g. “X-Forwarded-For:”, “X-Forwarded-To:”). These fields indicate that a message was delivered by Google’s servers as a result of a forwarding procedure, and since any of such messages are potentially part of an attack, messages containing these fields should be always queued for further verification until Google provides a definite solution.

Acknowledgements

Thanks to Osvaldo Ferrero, Angel Villalain, and Cesar Sandoval for helping with experiments. Thanks to Josh Soref for helping with revision. This work was sponsored in part by the United States Army Research Office (ARO) grant number W911NF-07-1-0271.