Split Tunnel SMTP Exploit Explained

Share This/Follow Us:
LinkedIn77
Instagram0
Email
RSS

Published: May 23, 2017
Security Research By: Vikas SinglaJason Morris

Executive Summary:

Exploit:

The Split Tunnel SMTP Exploit allows an attacker to bypass an organization’s email security gateway and inject messages with malicious payloads directly into the victim’s email server. This exploit targets a newly discovered vulnerability in popular Email Encryption appliances as a backdoor.  Injectable payloads can include anything that supports MIME encoding including:

  • Ransomware
  • Macro Viruses
  • Password Protected ZIP Files
  • Phishing Attacks

Two successful attacks were conducted using this exploit.  Details are included in the Attack Simulations section below.

Vulnerable Products:

Any Email Encryption appliance accepting inbound SMTP connections is vulnerable to this attack.  Our research also found that virtual/hosted appliances were just as exploitable as hardware appliances.

Remediation:

We are unaware of any hotfix or patch that will fully protect against this exploit. At this time we have identified only two solutions.

1. Completely disable transparent gateway-to-gateway encryption on the encryption appliance.
2. Implement a parallel processing solution that can perform email decryption and threat detection at the same time.

There is no “quick fix” to protect against this exploit. Organizations will need to invest time and resources to identify and implement the best solution.

 

Technical Details:

Most email encryption appliances are deployed in 1 of 2 ways:

1. The email security gateway and email encryption appliance both sit behind an organization’s firewall.  Each of these MTAs is assigned a publicly accessible IP address.  An attacker can bypass the email security gateway by connecting directly to the encryption appliance to inject messages.  These messages are then routed straight to the internal mail server for delivery.

2. The email encryption appliance sits in front of the email security gateway, like Microsoft’s Exchange Online Protection (EOP).  Again, each of these MTAs is assigned a publicly accessible IP address.  And again, an attacker can connect directly to the encryption appliance to inject messages.  The email encryption appliance decrypts and forwards all email to the security gateway.  However, when the security gateway analyzes email for threats it does so using the encryption appliance’s IP address instead of the attackers IP address, rendering the threat protection ineffective.

 

Attack Simulations:

NOTE: To protect the target organization from an actual compromise these attacks were directed at an invalid mailbox.  This allowed us to demonstrate the exploit by reaching the internal mail server without risk that a user may execute one of the payloads.

 

Attack #1: Exploit Successful

 

Microsoft Exchange + Onsite Email Encryption appliance

The first attack was designed for a target using Microsoft Exchange and an onsite Email Encryption appliance.  The target we selected was protecting Exchange using a WatchGuard security gateway.

 

Step 1: Select Target

Excelsior Springs Hospital
Excelsior Springs, MO
400 Employees

 

Step 2: Reconnaissance

After selecting our target we used an automated reconnaissance script to collect public information about the target’s email infrastructure.  The script first identified the target’s MX record.  (image-1)  Next, a brute force dictionary attack was employed to find the target’s Email Encryption appliance.  This attack uncovers all subdomains and their respective MX records.  (image-2)  We then used the Securolytics Exploitable IoT Scanner to test if port 25 was open on any of the MTAs we uncovered.  (image-3)  Finally, to quickly find a valid mailbox at the target organization our script used WHOIS to retrieve the target’s public domain registration.  In this example we uncovered a mailbox for Art Gentry, agentry-at-esmc-dot-org.  (image-4)

 

Step 3: Test Email Delivery

We sent a basic email with a benign payload.  This allowed us to learn how the target’s Email Security Gateway and internal mail servers handle messages.  As you can see, the target’s Email Security Gateway accepted our test message.  (image-5)

From: tifr-at-psles.com
To: test-mailbox-123-at-esmc.org
Subject: Hello World
Message: Hello
Server: mail.esmc.org

250 Requested mail action okay, completed

Our email was then delivered to the target’s internal mail server and then to the user’s inbox.  Because we intentionally sent the message to an invalid mailbox, the target’s mail server bounced our message as “undeliverable.”  The dangerous thing about NDRs is they often expose too much information about a company’s internal network.  (image-6)  In this attack, the NDR revealed the following about our target’s internal network:

WatchGuard Email Security Gateway
Microsoft Exchange Server 2010 with IP address 10.2.100.253

List of Microsoft Exchange Build Numbers

 

Step 4: Test Malicious Email Delivery

After verifying our target had a working Email Security Gateway, we created and sent a message with a malicious payload.  We disguised our email to look like it came from DocuSign and instructed the target to click “Review Document.”  The hyperlink in this email pointed to a site that was actively distributing malware.  (image-7)  The name and SHA256 hash of the malware binary along with VirusTotal’s analysis of both the URL and binary are listed below.  As expected, the target’s Email Security solution identified the malicious payload (URL) and rejected the message.  (image-10)

571 Delivery not authorized, message refused

URL: hxxp://LASVEGASTRADESHOWMARKETING.COM/file.php?document=MzM2MGFteUBrb250cm9sZnJlZWsuY29tMjEzNQ==
VirusTotal’s URL Analysis

Binary: Legal_acknowledgement_for_amy.doc
SHA256: 39cb85066f09ece243c60fd192877ef6fa1162ff0b83ac8bec16e6df495ee7af
VirusTotal’s Binary Analysis

 

 

Step 5: Execute Split Tunnel SMTP Exploit

After confirming the target’s Email Security Gateway was properly handling all inbound email (benign and malicious), we tested the Split Tunnel SMTP exploit.  We resent the same message used in the previous step, with the same malicious payload.  However, this time we directed the message at the target’s Email Encryption appliance instead of their Email Security Gateway.  The target’s Email Encryption appliance accepted the malicious email.  (image-11)

250 2.0.0 Ok: queued as 3BE32281A62

Earlier, we demonstrated that when an email makes it through to the target’s Exchange Server it will either (a) be delivered to the user’s inbox or (b) bounced as “undeliverable” if the mailbox does not exist.  As you can see in the image below we received an NDR from Exchange confirming our email made it all the way through and our attack was successful.  Further, the missing “X-WatchGuard” headers in the NDR indicates that our malicious email completely bypassed the target’s Email Security Gateway.  (image-12)  This attack demonstrates how an attacker can use Split Tunnel SMTP to exploit the vulnerability in Email Encryption appliances.

 

 

Attack #2: Exploit Successful

 

Microsoft Office 365 + Hosted Email Encryption

This second attack was designed for a target using Microsoft Office 365.  Unlike the 1st target, this one deployed Office 365 behind their Email Encryption appliance hoping to use Microsoft’s Exchange Online Protection (EOP) to protect against malicious emails that come in through alternate paths such as the Encryption appliance.  Unfortunately, as this attack demonstrates, this architecture is still vulnerable to the Split Tunnel SMTP exploit.

 

Step 1: Select Target

Christiana Care Health System
Wilmington, DE
11,500 Employees

 

Step 2: Reconnaissance

After selecting our target we again used an automated reconnaissance script to collect public information about the target’s email infrastructure.  The script first identified the target’s MX record.  We narrowed the search to Office 365 customers by filtering on records with *.mail.eo.outlook.com.  (image-13)  Next, a brute force dictionary attack was again employed to find the target’s Email Encryption appliance.  To locate hosted appliances we filtered on records where encryption MX record != target’s domain.  (image-14)  And again, we used the Securolytics Exploitable IoT Scanner to test if port 25 was open on the MTAs we uncovered.  (image-15)

Karen KeddaFinally, as a reminder of how easy it is to find a valid mailbox we ran a WHOIS query on the target’s public domain.  We uncovered a mailbox for Karen Kedda, kkedda-at-christianacare-dot-org.  (image-16)  We wanted to learn a little more about Karen so a quick search on Google returned Karen’s LinkedIn profile which confirmed she works as a Systems Analyst at Christiana Care Health System.

 

 

Step 3: Test Email Delivery

We sent a basic email with a benign payload.  This allowed us to learn how the target had configured Office 365 to handle email.  As you can see, the target’s Office 365 instance accepted our test message.  (image-17)  Because we intentionally sent the message to an invalid mailbox, Office 365 bounced our message as “undeliverable.”  You can see the NDR clearly shows Office 365 EOP used our sending IP address (80.82.x.x) to perform its inbound threat analysis and anti-spam.

From: lzgr-at-maildx.com
To: test-mailbox-123-at-christianacare.org
Subject: Hello World
Message: Hello
Server: christianacare-org.mail.eo.outlook.com

250 2.6.0 Queued mail for delivery

 

Step 4: Test Malicious Email Delivery

At this point in the attack we needed to confirm Office 365 Exchange Online Protection (EOP) would actually block our malicious email.  We sent a message with a malicious payload similar to one used in our previous attack, with a few minor changes:  (image-19)

1. Replaced the Docusign branding with generic branding.
2. Replaced the malicious hyperlink with a URL shortener redirecting to the malicious site.
3. Changed the sending IP to one blacklisted by EOP.

Again, the name and SHA256 hash of the malware binary along with VirusTotal’s analysis of both the URL and binary are listed below.  As expected, the target’s email security, EOP, identified and rejected the malicious email.  This time because our sending IP was already blacklisted.  (image-22)

550 5.7.606 Access denied, banned sending IP [185.62.190.188]

New Hyperlink: hxxp://tinyurl.com/m7s5oer
New Sending IP: 185.62.190.188

URL: hxxp://LASVEGASTRADESHOWMARKETING.COM/file.php?document=MzM2MGFteUBrb250cm9sZnJlZWsuY29tMjEzNQ==
VirusTotal’s URL Analysis

Binary: Legal_acknowledgement_for_amy.doc
SHA256: 39cb85066f09ece243c60fd192877ef6fa1162ff0b83ac8bec16e6df495ee7af
VirusTotal’s Binary Analysis

 

Step 5: Execute Split Tunnel SMTP Exploit

After confirming the target’s Office 365 Exchange Online Protection was properly handling all inbound email (benign and malicious), we tested the Split Tunnel SMTP exploit.  We resent the same message used in the previous step, with the same malicious payload, from the same IP address.  However, this time we directed the message at the target’s hosted Email Encryption appliance instead of EOP.  The target’s hosted Email Encryption appliance accepted the malicious email.  (image-23)

250 2.0.0 Ok: queued as F2AF7E082B

 

Earlier, we demonstrated that when an email makes it through the target’s Office 365 instance it will either (a) be delivered to the user’s inbox or (b) bounced as “undeliverable” if the mailbox does not exist.  As you can see in the image below we received an NDR from Office 365 confirming our email made it all the way through and our attack was successful.  (image-24)  The target’s hosted Email Encryption appliance decrypted and forwarded our malicious email to Office 365.  It passed through Office 365 EOP undetected because sending directly to the target’s encryption appliance added two additional Received headers to our message before it was forwarded to Office 365.  When EOP analyzed our email for threats it did so using the hosted Email Encryption appliance’s IP address (199.30.235.81) instead of ours (185.62.190.188).

This attack again demonstrates how an attacker can use Split Tunnel SMTP to also exploit hosted Email Encryption appliances.

CIP: 199.30.235.81View Full Message Headers
Try Microsoft’s Message Header Analyzer Tool

 

Conclusion:

Our security research continues pointing to two major trends:

1. Cyberattacks are becoming more frequent.
2. Cyberattacks are becoming more sophisticated.

In a previous blog post we showed the biggest data breaches of 2016.  As we compiled this list I remember being taken back by the sheer number of attacks.  IBM’s X-Force released a new report which found more than 4-billion records were leaked in 2016.  That’s more than the combined total from the previous two years.  And Experian’s 2017 Data Breach Industry Forecast predicts cyberattacks will continue rising in 2017, with Healthcare as the #1 target.

In the past few months we have also witnessed cybercriminals employ new tactics rendering traditional approaches to cybersecurity all but obsolete.

  • Mirai Botnet: IoT devices used in a massive DDoS attack
  • WannaCry: Government cyber warfare tools used to distribute Ransomware
  • Google Phishing: Trusted URLs used in a massive Phishing attack

NIST Risk Management FrameworkSo how can you protect yourself from the unknown threats of tomorrow?  By taking a disciplined and structured approach to managing information security risk.

NIST’s Risk Management Framework (RMF) offers such an approach built on a core principle of continuous monitoring.  In fact, the recently issued Presidential Executive Order 13800 for “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure” mandates agencies implement NIST’s Framework.

Securolytics offers cloud-based solutions that automate implementation of NIST’s Risk Management Framework. To learn more about our solutions please visit securolytics.io/enforce.

Sincerely,

Vikas Singla
Co-Founder & COO, Securolytics

Jason Morris
Senior Systems Engineer, Securolytics

Share This/Follow Us:
LinkedIn77
Instagram0
Email
RSS

3 Replies to “Split Tunnel SMTP Exploit Explained”

  1. Pingback: InfoSecHotSpot
  2. Sorry, but… Captain obvious is obvious… Just don’t let the later hops have a publicly reachable IP address or only allow connections from trusted sources.

    People should be aware that, if your email server or email appliance is reachable on the internet, one can send emails to it directly. MX records don’t mean anything if you know the public IP of an email server. So people should always filter incoming connections and only allow them from their email security appliance. That’s the solution to this.

  3. I have a few comments regarding this.

    Both examples are against Zix, I’m not familiar with Zix but it seems the recommended settings are to use zixvpm.domain.com so I question the need for the brute force attack.

    Why are these encryption gateways accepting mail from the internet? They should be configured to only accept mail from trusted IPs. Again I’m not familiar with Zix so maybe this isn’t an option for them.

    Encryption gateways that aren’t cloud hosted would typically be behind a corporate firewall and thus internet traffic couldn’t reach it.

    This seems no more an exploit than spammers discovering an open relay mail server.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.