This research was conducted on behalf of and exclusively for F5 Labs by graduate students at the University of Washington Tacoma as part of their Masters in Cybersecurity and Leadership Capstone Research Project.
Introduction
Electronic mail is perhaps the most widely used system for communicating business information over the Internet. Email is now so ubiquitous that we often assume someone else has taken care of the appropriate security protocols at some point in the past; we take this attitude at our peril.
Research emphasis was placed on threats that pertain to email’s core application, function, and service, including mailbox storage, mail services (SMTP), mail retrieval (Pop3, IMAP), mail transport encryption (TLS), and mail authenticity. This segmented approach will analyze exploits and vulnerabilities that exist within the email infrastructure.
Mailbox Storage Attacks
Mailbox storage refers to the data-at-rest kinds of vulnerabilities that still exist even after files systems have been encrypted. Attacks such as malware can penetrate their way into a systems files even when encryption is in place.
Email messages are generally sent over untrusted networks—external networks that are outside the organization’s security boundary. When these messages lack appropriate security safeguards, they are like postcards that can be read, copied, and modified at any point along these paths. Because email is widely deployed, well understood, and used to communicate with untrusted, external organizations, it is frequently the target of attacks. Attackers can exploit email to gain control over an organization, access confidential information, or disrupt IT access to resources.1
Specific vulnerabilities that can target mailbox storage include a Firewire direct memory access (DMA) attack, which relies on using direct hardware access to read or write directly to main memory without any operating system supervision or interaction.2 Without direct hardware access, a buffer overflow attack known as “Ghost” has been shown by researchers to be capable of targeting mail servers on some Linux operating systems.3
Email Services (SMTP) Attacks
The protocol responsible for the transmission or sending of electronic mail is Simple Mail Transfer Protocol (SMTP). Servers running SMTP are enhanced by authentication (AUTH) to verify and confirm the identity of a sender. SMTP was not initially designed for verifying, or encrypting or otherwise protecting emails in transit. However, there are specific protocol extensions in addition to AUTH: STARTTLS (Transport Layer Security), Secure/Multipurpose Internet Mail Extensions (S/MIME) and Domain-based Message Authentication, Reporting and Conformance (DMARC) to name a few that carry out protective functions, albeit optionally, on organizations’ servers. Also, some organizations use their own proprietary protocols on their internal networks and/or may not employ the aforementioned protocols.
Some organizations use Email Encryption Appliance (EEA), physically or virtually, as part of their email architecture. If an EEA has a publicly accessible IP address and an attacker discovers it, a split-tunnel attack could be launched. This attack bypasses any email security gateways by hitting the EEA first. Since the EEA decrypts and routes emails to the organization’s server without inspecting for malware by design.
Figure 1: Demonstration of a split-tunnel attack4
Email Retrieval attacks
The two major protocols associated with email retrieval are Post Office Protocol 3 (POP3) and Internet Message Access Protocol (IMAP). Both protocols connect to an email server to download new messages over a TCP/IP connection.5POP3 is much simpler and easier to implement, but only allows one client to be connected at a time and usually deletes messages from the server after forwarding to the local machine. IMAP, however, provides storage of email messages on the server which allows mail retrieval from various workstations. With these advantages, IMAP has become the replacement for POP3 in use with many email servers.6
One major flaw with IMAP and POP3 is the login process which allows the user to connect via unencrypted pathways resulting in login credentials being sent across the network as clear text.7 Recent hacking tools exposed by the Shadow Brokers earlier this year provide techniques to gain control of hotel Wi-Fi, and once control is established, the attacker can collect user credentials in a manner that doesn’t even require the user to enter the data when signed on to a hotel network.8
There are network-delivered attacks against the listening IMAP and POP3 services, such as the stack buffer overflow IBM Domino Server exploit “EMPHASISMINE” which grants privileged access to execute code on the Domino Server.9
Email Transport Encryption Attacks
SMTP servers and clients normally communicate in the clear over the Internet. In many cases, this communication goes through one or more routers that is not controlled or trusted by either party. Such an untrusted router might allow a third party to monitor or alter the communications between the server and client. Transport Layer Security (TLS) is an encryption protocol used to encrypt sessions.
When the mail servers are going through the cypher suite negotiations, a man-in-the-middle attack (MITM) can be exploited against this negotiation. For example, the destination server will state that it supports 256-bit encryption. Meanwhile, the MITM will not pass this information to the client server. Likewise, the MITM will pass to the destination server that it does support its high-level encryption, when this is not true. So essentially, we have a falsely encrypted tunnel on the destination side with no secure cypher suite on the source side. This will cause the email to be transmitted in the clear.
There are also cross-protocol attacks on servers supporting SSLv2 and EXPORT cipher suites resulting in TLS sessions being decrypted. Sharing of the same RSA private keys for both TLS and SSLv2 servers further extends the attack surface to “non-vulnerable” servers. Note: this attack is independent from the client making an SSLv2 connection.10
Fraudulent Email
Most email systems are not adequately configured to successfully distinguish between authentic email and fraudulent email.11 According to a report from PhishMe in 2016, 91% of cyber-attacks were started with an email. In a sample of 13 million fraudulent emails, more than 100,000 included malicious attachments, and nearly 1.4M contained malicious web links.12
There are many different tools to create fraudulent emails. Attackers can spoof legitimate email addresses many ways. A common usage of fraudulent email is to lead the recipient of the email to click on a malicious link, execute a malicious file (or macro), follow fraudulent directions (make a wire transfer payment, add a vendor for payment) or give out confidential information (PII, trade secrets, accounting information, username, passwords).
One of the most prevalent and easy to execute fraudulent email is to use a SendMail SMTP server and configure the server to spoof the domain name of the target. Using this method, you can send an email to an accounts payable clerk spoofing the CEOs email address and ask the clerk to bypass normal processes to immediately pay a bill via wire transfer.
Spoofbox.com and Anonymailer.net are websites that advertise they will spoof email and change the sender field. They also allow the users to designate any sender email and add HTML, text and file attachments.
Email Spoofer is a tool available at SourceForge that is advertised as a tool for pentesters. It is able to send emails to a single recipient or a list, it supports plain text/html email formats, and attachments. It also enables the sender to specify that replies go to a different email located in the header.
Comparison
Conclusion
The research conducted here is not intended to be all inclusive but rather an overview of attack vectors related to major email components. To reduce the chance that mail systems are vulnerable to these attacks, we recommend:
- Applying all security patches issued for mail services.
- Maintaining physical security of devices, and restricting sensitive data from being stored at rest in RAM unencrypted.
- In general, disabling transparent encryption for emails; if transparent encryption is needed for ease of access, ensuring that both ends of the transmission are properly set up.
- Never allowing transmission without an established TLS session.
- Disabling SSLv2 protocol in all SSL/TLS servers as well as SSLv2 ciphers.
- Encrypting email prior to transmission, if feasible.
- Reducing fraudulent email with DNS verification methods such as Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), Domain-Based Message Authenticating Reporting and Conformance (DMARC).
- Training users on how to identify and deal with fraudulent email.
- Writing policies and procedures regarding email exposure of PII, conducting financial transactions, or revealing organizations’ trade secrets.
3 
