Bryson Medlock
on August 19, 2021

Multiple Mail Maladies, Vulnerabilities in STARTTLS and Exchange

40 Vulnerabilities Discovered in Various STARTTLS Implementations

The first electronic mail, later dubbed email, was sent to users of MIT’s Compatible Time-Sharing System in 1965. Standardized protocols for delivery of email came later, with Simple Mail Transfer Protocol (SMTP) defined in RFC 772 in September 1980 as the primary means to transfer email between mail servers. The Post Office Protocol (POP) came next with the current version, POP3, originally defined in RFC 1081 in November of 1988 and then extended in RFC 1939 in May of 1996. Then came the Internet Message Access Protocol (IMAP) with the latest version (v4) defined by RFC 3501 in March 2003. While SMTP handles the transfer of email between mail servers, POP3 and IMAP are protocols that define how a user can access the mail in their mailbox.

Email and the protocols that define how we send and receive email have been around for a long time. Like most technology that has been around for a long time, security was an afterthought added after the technology was widely used. In the case of SMTP, POP3, and IMAPv4, all of these protocols by default do not use any encryption so any traffic transmitted with these protocols can be observed by anyone watching your traffic. Which means without extra steps, anyone watching you download your email to your mail client can read your email.

All modern mail clients and servers now have extra steps that have been added on to these protocols to allow for encrypted communication. In the case of SMTP, POP3, and IMAPv4 those extra steps come from something known as Opportunistic TLS, or STARTTLS. STARTTLS is an extension to these protocols RFC 2595 and RFC3207 that allows the client and server to encapsulate encrypted TLS traffic inside the normally clear text protocols.

This past week some researchers published recent findings that document 40 vulnerabilities in various STARTTLS implementations. The full list of vulnerabilities is available at https://nostarttls.secvuln.info and includes common mail clients such as Outlook for Android, Thunderbird, and more as well as vulnerabilities in mail servers such as Courier and Dovecot as well as some services such as Yahoo and Gmail. They do not list any vulnerabilities for Microsoft 365, Exchange, or the desktop Outlook client. This does not represent an overall vulnerability in the STARTTLS protocol extensions but vulnerabilities in specific implementations of STARTTLS in various servers and clients.

It’s also worth noting that STARTTLS is not your only option for adding encryption to your email traffic. Most modern email clients support implicit TLS communication as opposed to STARTTLS which begins with a normal unencrypted connection and then issues the STARTTLS command to upgrade the connection to then being using TLS or SSL. The vulnerabilities listed specifically deal with that upgrade and how it’s implemented.

We recommend you review the list at https://nostarttls.secvuln.info to see if any of the products you use are listed. Some of the issues described have been fixed and some have not. We strongly urge you to review the list and apply patches where necessary and where a patch isn’t available reconfigure your clients and servers to use implicit TLS rather than STARTTLS.

More Exchange Nightmares

The CRU team recently visited Vegas for Defcon and Blackhat. One of the most anticipated presentations we were looking forward to was Orange Tsai’s “ProxyLogon Just the Tip of the Iceberg, New Attack Surface on Exchange Server,”. Orange Tsai is the security researcher on the DEVCORE team that originally discovered and reported the Proxylogon Exchange vulnerability that led to webshells being dropped on servers around the world. In Tsai’s video, and the related blog post, he provides a detailed technical explanation of the attack surface he’s been researching, specifically the Client Access Service, or CAS.

Besides ProxyLogon, there are two additional attack chains described, ProxyOracle and ProxyShell. According to Tsai, these have all been patched by Microsoft as of July’s Patch Tuesday. However, there have been a couple of new Proof of Concepts (PoCs) released by different researchers that are capable of exploiting ProxyShell.

Since coming back from Vegas, we’ve started seeing new webshells on some of our customers’ Exchange servers though nowhere near as prolific as earlier this year. Below is a screenshot of a webshell we found on an Exchange server:

findings on exchange server

Based on what we’ve observed, adversaries are going back through Exchange servers that have not yet been patched and using both ProxyLogon and ProxyShell vulnerabilities to write files to the server with the above line included in a location that can be accessed over the public Internet. This line of code will allow an adversary to then issue HTTP requests to the webshell that will execute commands as if they had command-line access to the server and it will execute that code with SYSTEM level permissions. We’ve primarily found these files in the following locations:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\auth\

C:\inetpub\wwwroot\aspnet_client\system_web\

We’re not the only ones who have observed this recent behavior. Some of our contacts in other organizations have shared similar intelligence with us. Rapid7 has also reported seeing similar activity. The good news is that there is no evidence that these vulnerabilities apply to fully patched systems. The bad news is that there are still plenty of unpatched systems out there and adversaries are taking advantage of it. According to security researcher Kevin Beaumont, “just under 50% of Internet facing Exchange servers” are currently vulnerable to ProxyShell or ProxyLogon. In March we mostly saw various adversary groups dropping webshells but they did little with that access except some coin mining. In these more recent attacks, we have observed adversaries stealing password hashes with Mimikatz.

We strongly recommend you patch your Exchange servers as soon as possible to avoid being compromised. If you are a Perch SIEM customer, we also recommend you install the “ConnectWise CRU” collection in the Perch Marketplace so you have the latest detection capabilities we’ve assembled for the activity we’ve observed.

References:

We'd love to hear your thoughts. Find us on Twitter, LinkedIn or write in to hello@perchsecurity.com

Next: Malware Analysis - Infinity Gauntlet

Share this on:

Bryson Medlock
on August 19, 2021