Earlier this year, commercial email solutions like Microsoft Exchange made security headlines with “ProxyLogon” vulnerabilities. Now the open-source world has entered its own window of exposure, with newly disclosed vulnerabilities in an email application called “Exim.” Exim is what is known as a Mail Transfer Agent (MTA), and it is included with many common Linux distributions to provide inbound and outbound email services. Its adoption is extremely widespread—in fact, some estimate that Exim represents 60% of the MTAs on the internet. Qualys security researchers released findings this week that identified 21 unique vulnerabilities in the code that make up the Exim server application and assigned a name to describe them: 21Nails.
When chained together, these vulnerabilities could, in theory, allow an attacker to deliver the deathblow of unauthorized remote code execution (RCE). The attacker does not need to log in or authenticate and can run commands on the exposed server. Fortunately, the Qualys team has been analyzing Exim for vulnerabilities since at least October of last year and coordinated with the developers and maintainers of the Exim project to develop patches and fixes for the flaws. While there are not yet any known examples of malicious actors exploiting these flaws, the longer they remain unremediated, the greater the likelihood that an attacker will take advantage of them.
This vulnerability is yet another example of how important it is for organizations to understand their own security posture—after all, you cannot fix problems you are not aware of—and the impact of an exposure of this type depends in large part on how quickly administrators are able to update and patch their servers. So far, patch rates among Exim users compare favorably to those that followed the Microsoft Exchange revelation, highlighting the value of public trust in open-source applications and the critical role open-source users play in remediating vulnerabilities quickly and efficiently.
Open-Source Proves its Resilience
While Exim’s vulnerabilities were revealed hot on the heels of the Microsoft Exchange hack, the difference in uptake by admins has been notable. Even as Microsoft Exchange admins struggle to push security updates, Exim users are already deploying the fix en masse, highlighting the inherent resilience of open-source software communities and the value of public trust in the testing and automated approach to applying security updates.
Timely Patching Remediates Vulnerabilities
SecurityScorecard’s analysis indicates that the Exim vulnerabilities are difficult to exploit, and there is little evidence that malicious actors have succeeded in taking advantage of them in the wild at this time. Following established responsible disclosure practice, the Qualys team worked closely with Exim’s developers and maintainers to develop patches and updates to the software, which is already available. Quickly patching these vulnerabilities will keep Exim servers secure before malicious actors have a chance to weaponize them.
Potential for Third-Party Exposure Remains
Even if an organization has patched its own systems, a strong possibility still exists that vendors, partners, or other third parties have not. The SecurityScorecard platform allows users to identify which third-party systems may still be vulnerable, so they can take the appropriate precautions to prevent becoming the victim of ransomware or phishing attacks.
How Widespread are the Vulnerabilities?
SecurityScorecard has the capability to non-intrusively detect this and other vulnerabilities using in-house tools which continuously monitor for security exposures, giving us and our customers near real-time insights. Our preliminary analysis shows that the vulnerability is widespread, both by geography and by industry (note that our estimates may increase as more data becomes available).
Geographically, we can identify vulnerable Exim servers running in at least 63 countries (see diagram below). The vulnerability is present in servers in every major world economy and across business sectors
The SecurityScorecard Investigations & Analysis team examined the 21 vulnerabilities in detail, with the aim of understanding how impactful they truly are. The security research community has developed “proof of concept” (POC) exploits that provide valuable insight regarding how to exploit the vulnerabilities. The SecurityScorecard team sought to further understand how difficult they might be to exploit, as well as what level of access an attacker might reasonably be expected to obtain.
Our findings were mixed. While many have reported that these vulnerabilities can result in an attacker obtaining unauthenticated root access on a target system, our analysis indicates that only one of the 21 vulnerabilities could lead to that result. Most of the 21Nails lead to the attacker gaining access as the “Exim” user. Since the Exim service by default does not run as root, the attacker would have limited access to the underlying operating system. This is in part due to the best practices of open source operating systems and security by design practiced by software developers. Still, the Exim user is trusted by the Exim software, which means the attackers could likely send email messages with a sender address and recipient address of their choice. Further privilege escalation is required for the attacker to obtain more significant administrative access to the target system; however, one of the 10 remote code execution vulnerabilities can be combined with any of the 11 local privilege escalation vulnerabilities to gain root privileges.
With that in mind, the root level access vulnerability has yet to be successfully demonstrated and remains a theoretical risk at this point. Furthermore, the analysis indicates that exploiting these vulnerabilities can range significantly in difficulty, with some requiring extreme effort and specific conditions to exist. While these vulnerabilities are concerning and will inevitably be weaponized by threat actors, our analysis indicates that it would require a well-resourced threat actor—such as a nation state-funded APT—to undertake a successful attack designed to extract useful information or compromise significant numbers of systems at scale. The Investigation & Analysis team has not uncovered evidence of any exploitation by malicious actors in the wild—though we will continue to monitor the situation.
Next Steps/Recommended Actions
System administrators need to immediately upgrade Exim to version 4.94.2 (or the fixed/patched version from your upstream package repository, depending upon the version of Linux that is being used). Many of the most widely used Linux distributions, including CentOS, RHEL, and SuSE, have already prepared their package manager repositories with the required fixes.
Although the patch is only a few days old, we have already observed a significant rate of adoption among affected systems—including within the initial 24-hour period. This indicates that many of the machines potentially affected by the Exim vulnerabilities are on an automatic update cycle, highlighting one of the strengths of open-source software. Users trust open-source applications because they are thoroughly tested by the community, giving them the confidence to update their servers without waiting to further vet patches and critical security updates. An open-source product like Exim may have vulnerabilities, but users know they can trust the fixes when they are issued. Contrast this with the Microsoft Exchange patch, where the adoption and deployment of which has largely plateaued.
Security teams and developers can also use SecurityScorecard’s platform to see every system affected by the vulnerability—including their own systems, as well as those of their vendors and service providers. It is important to remember that even if your own system is not affected, that does not necessarily mean you can sleep easy. A vulnerable vendor represents a very real security risk. Even without root access, an attacker able to send email using a “trusted” vendor’s email server can cause significant damage. Email addresses build up reputations over time, and macros/malware might slip through undetected if they originate from a previously trusted address. Organizations can use the insight they gain through SecurityScorecard’s platform to place unpatched vendors in a different email category, subjecting them to greater scrutiny. When the time to awareness of security risks matters most, having a platform that delivers automation at scale is invaluable.