When I got an alert about Microsoft Exchange’s zero-day vulnerabilities CVE-2021-26855, 26857, 26858, and 26865, I immediately checked the logs of attempted access to our standard exchange servers’ ports. I usually find thousands of unsuccessful attempts to connect by various bots, port scanners, and similar players. I scanned these ports with well-known script http-vuln-exchange:

Starting Nmap 7.70 ( https://nmap.org ) at 2021-03-04 00:59 UTC
Nmap scan report for mx1.XXXXXXX.net (XXX.XXX.XXX.XXX)
Host is up (0.15s latency).
Not shown: 994 filtered ports

PORT    STATE  SERVICE
25/tcp  open   smtp
80/tcp  open   http
|_http-vuln-exchange: Error nil for /owa
443/tcp open   https
|_http-vuln-exchange: Error nil for /owa
465/tcp open   smtps
587/tcp open submission
993/tcp closed imaps

To explore these vulnerabilities, a malicious JS code must gain access to port 443 (which is possible if you use the default OWA authentication page):

But in our network, all access to web resources is controlled by WWPass authentication, where any requests to url /owa/ or /ecp/ are redirected to WWPass’ authentication page with a QR code.

Our Exchange does not get a chance to respond until an authorized user scans a QR code with the WWPass Key app, our mobile multi-factor authenticator app.

As you can see from the script above, the attackers just got Error nil for /owa

It means that despite our Exchange servers having these vulnerabilities, due to properly established access control, they could not be exploited. So our Exchange servers were protected even before Microsoft announced these vulnerabilities and released the patches.

To test my hypothesis, I used the same script to see how it would work with the Exchange server with the username/password login that was exposed to the internet and not protected by WWPass login.

xxxxxxx@dke:~/temp$ nmap --script http-vuln-exchange remote.xxxxxxxx.xxx

Starting Nmap 7.70 ( https://nmap.org ) at 2021-03-04 01:06 UTC
Nmap scan report for remote.XXXXXXXX.xx (XXX.XXX.XXX.XXX)
Host is up (0.067s latency).
rDNS record for XXX.XXX.XXX.XX: XXX.XXX.XXX.XXX.xxxxxxx.xxxx.xxx.xxx.xxxxxxxxxx.xxx
Not shown: 992 filtered ports

PORT    STATE   SERVICE
80/tcp  open
http |_http-vuln-exchange: Error 307 for /owa
113/tcp closed  ident
443/tcp open    https
|_http-vuln-exchange: (15.0.1497) Exchange 2013 potentially vulnerable,
check latest security update is applied (15.0.1497 Exchange 2013 CU23 installed)

You can immediately see the potential vulnerability, which can easily be exploited by hackers:

443/tcp open https

What can we learn from this accident? More importantly, why are our servers not a part of the ever-growing list of compromised ones?

IT security and aviation safety have a lot in common, so IT professionals can learn from the history of aviation accidents (and catastrophes). It’s well known that in most cases, mishaps are attributed not to a single breakdown or human error (an IT security accident in our industry), but to a combination of factors. That’s why to stay safe flying in the air (and in your datacenter), one must have multiple measures preventing potential issues.

Volexity, a Washington DC-based security firm, said the Hafnium attacks started as early as January 6, 2021, but the vulnerability was officially announced in early March. It is not unusual that there is a gap between when hackers start their activity and when affected organizations learn about it. That means that companies should be proactive in their security measures.

Zero-day vulnerabilities like theMicrosoft Exchange one can usually be exploited through gaining access to systems through channels reserved for humans to legitimately get there. Unfortunately, most companies still use rudimentary username/password logins, which provide virtually no protection against serious attacks — sometimes augmenting them with OTP “second factors” (SMS texts, Google Authenticator type generators, and such) which somehow improve security, although hardly dramatically.

WWPass login improves resilience against attacks, including those that exploit zero-day vulnerabilities. An additional layer of protection like this would definitely help not only keep user accounts safe, but also in most cases, mitigate other risks, like the one caused by the Exchange vulnerability.

Get Started

To learn more about WWPass multi-factor authentication for Exchange and other services, contact us today.