Authentication: Lessons Learned from Microsoft Exchange and F5 BIG-IP Hacks
The past month has been a very dynamic time in the world of security for hackers and threat researchers, but it has been an extended nightmare for CSOs responsible for securing their enterprise networks.
For starters, on-premise Microsoft Exchange servers were attacked in droves after a set of zero-day vulnerabilities were discovered, resulting in widespread infiltration of hundreds of thousands of organizations. These vulnerabilities allow malicious actors to remotely control machines, read emails, and gain access to internal corporate assets. To illustrate how widespread this attack was, in the two days following the disclosure, Akamai observed over 290,000 unique attempts to scan and/or exploit these vulnerabilities on our global platform. Microsoft rapidly issued patches for the vulnerability, but the breadth and scale of the breaches won't be truly known for some time, with some enterprises experiencing advanced persistent threats as a result of the exploit.
As if this wasn't already bad enough, customers of IT security company F5, which has included almost all of the world's Fortune 50 companies, found themselves rocked with yet another set of highly severe application vulnerabilities, this time for F5's BIG-IP family of load balancing and security products. These vulnerabilities allow for remote execution of system commands, potentially allowing complete control of the server, interception, and redirection of web traffic, decryption of traffic destined for web servers, and infiltration as a jump host to reach other areas of the network. The National Vulnerability Database ranked these vulnerabilities as critical, some with a CVSS rating as high as 9.9 out of 10.
Both of these vulnerabilities, which are actively being exploited by real-world attackers, involve robust highly-utilized systems that have authentication built directly in. So how did this happen?
Application authentication
In both the Microsoft Exchange and F5 BIG-IP products, authentication is required before privileged activities can be performed. While this is an important and required facet of security, many individuals falsely assume that this authentication, which is applied at the application level, provides ample protection.
This is a misconception, however. If an end user can reach an application such that it prompts them to enter credentials, they have already caused code to execute. This is true regardless of the authentication method or prompt. It does not matter whether the application redirects an end user to an IdP or asks for a username and password directly; the very act of asking for credentials means the application was contacted over the network, code was executed, and a response was tendered to the end user.
And this is where the problem lies. Applications are written by human beings, and human beings make mistakes. This is at the heart of the vulnerabilities within Microsoft Exchange and F5 BIG-IP. In both cases, there were incorrect checks against the authentication, which allowed payloads to bypass valid logins and result in exploitation. In other words, the very fact that the systems are reachable is enough to exploit them.
If you can't trust that the application is implemented perfectly, then what can you do?
Network authentication
The right answer to this problem has been known for quite some time: tie the authentication to not only the application but to the network as well. Zero Trust Network Access is one such method to do this. In a Zero Trust environment, a proxy sits between an enterprise's internal network assets and the users who wish to access them. Basic network communication cannot be established until the end user's identity has been established.
The authenticators that can be used in a Zero Trust environment tend to be far richer than a VPN, including user identity, groups, device posture, multi-factor authentication (MFA), time of day, location, user and entity behavior analytics (UEBA), client reputation, and more. Only once the proxy has validated the authentication and determined the user is authorized for access does it allow packets to actually reach the application, where it too can then perform additional authentication and authorization checks.
This has a massive impact on reducing the threat surface of the attacks. In the case of Microsoft Exchange and F5 BIG-IP, it means the vulnerabilities can only be exercised by insiders as opposed to anyone in the world that can reach the machine. This is a drastic improvement.
But is there anything else we can do?
It's all about who and what
Reducing the threat surface from the entire world to insiders only is arguably the most impactful step that an enterprise can take toward protecting itself from the above style of vulnerabilities. However, this does not completely eliminate the threat. It simply restricts who can exercise it.
The problem is that insiders can also be malicious, either directly, or much more often, indirectly through malware installed on their machine or theft of credentials and forged identities by malicious actors. To further protect oneself, a web application firewall (WAF) can help eliminate the risk of what is being sent. Once signatures of the attack are known, a WAF stops even malicious insiders from delivering exploit payloads, further strengthening an enterprise's security posture.
One may wonder why it's worth having a WAF when patches will eventually eliminate the vulnerability altogether. The answer is in the term eventually. Enterprises can be achingly slow to apply critical patches, having experienced crushing downtimes when poorly written patches have caused outages. In other environments, an enterprise may not even have a full inventory of all of their assets that require patching.
In these cases, providing a WAF can safely extend the time to patch. Administrators can test the patch, create a staging environment, and deploy over a timeline that meets the business needs, assured that they are safe from exploitation as the WAF is filtering all communications to the vulnerable services.
A call to action
Fortunately, Akamai provides a comprehensive suite of products, services, and capabilities that can be used to make your organization safer and more secure.
First, our Akamai Enterprise Application Access product is a complete Zero Trust Access solution that allows for the closure of all inbound firewall ports and the removal of DMZ applications. Through our set of proxies and rich authentication and authorization primitives, authorized users and devices have full access to only the set of internal applications they need, without additional access to any other assets on the network.
For employees, these heightened security checks do not mean additional steps or inconvenience when accessing the IT resources they need. In fact, things become simpler and more secure. Native integration with Active Directory, Azure AD, SAML, OIDC, OAuth, and more mean your enterprise can gain the noted security benefits without any changes to your existing application authentication flows.
Additionally, the inclusion of our Akamai MFA product extends the noted protections through the use of patent-pending phish-proof multi-factor authentication, allowing end users to use their smartphones to leverage state-of-the-art FIDO2 authentication, the strongest standards-based method currently available. With other solutions, this still requires the use of physical security keys, which not only come at a cost but are also typically perceived as inconvenient and not very popular among employees.
Finally, Akamai's Kona WAF is designed to block not only the full suite of standard attacks web applications receive but also the specific attacks on unpatched Exchange instances noted earlier; for details, please read How Akamai Can Help You Fight the Latest Exploitation Attempts Against Microsoft Exchange.
Akamai can help you start your Zero Trust security journey and move to a least-privilege application access model. Contact us for more information on how we can help you mitigate similar security incidents!
