As an introduction, read our blog article on Protecting Internet-facing Systems.
As an exercise in real-life observation of how adam:ONE® Zero Trust Network Access for egress control can protect vulnerable systems, we decided to setup an unpatched Exchange Server 2019 that is vulnerable to ProxyLogon. This post is to offer the design and technical details as well as the outcome of remaining online with a known vulnerability that is only a matter of time before it is discovered and then attacked.
The setup
- Dedicated single network segment with all virtual machines running on a single hypervisor
- Dedicated Internet gateway running pfSense 2.5
- adam:ONE® version 4 running with DTTS® enabled
- Strict whitelist/allowlist policy applied to Domain Controller (single controller)
- Strict whitelist/allowlist policy applied to Exchange Server (single instance for all Exchange roles)
- Exchange Server outbound SMTP traffic denied by firewall
- Exchange Server outbound SMTP traffic sent via relay
- Debian 10 instance for outgoing SMTP relay
- Permissive outbound (SMTP traffic only) for relay, since it needs to be able to send outgoing SMTP traffic anywhere
- Inbound TCP port 443 forwarded to Exchange Server’s TCP port 443 for Client and OWA access from anywhere
- Inbound TCP port 25 forwarded to Exchange Server’s TCP port 25 for SMTP for email delivery from anywhere
- MX record setup for direct delivery, no cloud MX filtering services utilized
With that basic setup, we tested to make sure that Exchange 2019 CU7 as deployed is, in fact, ProxyLogon vulnerable via this script:
https://github.com/microsoft/CSS-Exchange/releases/latest/download/http-vuln-cve2021-26855.nse
With that script handy, we ran the following:
nmap -p 443 --script http-vuln-cve2021-26855 [honeypot_host]
and received the following:
% nmap -p 443 --script http-vuln-cve2021-26855 [honeypot_host]
Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-22 00:18 EDT
Nmap scan report for [honeypot_host] ([w]..[y].[z])
Host is up (0.019s latency).
PORT STATE SERVICE
443/tcp open https
| http-vuln-cve2021-26855:
| VULNERABLE:
| Exchange Server SSRF Vulnerability
| State: VULNERABLE
| IDs: CVE:CVE-2021-26855
| Exchange 2013 Versions < 15.00.1497.012, Exchange 2016 CU18 < 15.01.2106.013, Exchange 2016 CU19 < 15.01.2176.009, Exchange 2019 CU7 < 15.02.0721.013, Exchange 2019 CU8 < 15.02.0792.010 are vulnerable to a SSRF via the X-AnonResource-Backend and X-BEResource cookies.
|
| Disclosure date: 2021-03-02
| References:
| CVE - CVE-2021-26855
|_ http://aka.ms/exchangevulns
Nmap done: 1 IP address (1 host up) scanned in 0.77 seconds
From the time Exchange was visible from the public internet via HTTPS and SMTP, it was less than an hour that it was scanned for vulnerabilities.
Since then, there are many events per hour from known-malicious IPs to connect over TCP port 443.
Update 2021-04-07
The most notable event so far has been a failed attempt by an attacker at a script to utilize burpcollaborator.net. However, since DNS services aren’t available except via adam:ONE® on the gateway, the Exchange Server continues to function without disruption. We’re often asked, how do you prevent other DNS from being used? Here’s how:
- TCP/UDP port 53 traffic outbound is simply hit by an outgoing NAT (in pfSense® this is a “Port Forward” on the LAN interface) rule so that legacy DNS queries land on adam:ONE® even if they used 8.8.8.8, for example
- DNS-over-TLS (DoT) operates at a standard port which is simply disallowed
- DNS-over-HTTPS (DoH) runs over TCP port 443, none of which destinations are allowed unless opened by an allow-listed DNS query first (dns.google, one.one.one.one and its various alternatives are simply not on any allowlist)
Malicious actors ultimately rely on their attack code being able to reach outbound, and may use TCP port 80, 443, 8080, 8443 as well, but any/all ports and destinations are denied until the destination is resolved by an allowed query via adam:ONE®. DTTS® is also the mechanism that prevents TOR or any other obfuscation protocols from reaching out. This is how all C2 is prevented.
Feel free to return here as this post will be updated continuously.