Backdoor Found in Utility for Linux, Unix Servers

backdoor ASUS

Backdoor was intentionally planted in 2018 and found during the DEF CON 2019 security conference when researchers stumbled upon malicious code.

In an unnerving twist, when a critical zero-day vulnerability was reported in a Unix administration tool, called Webmin, it was revealed the flaw was no accident. According to researchers, the vulnerability was a secret backdoor planted in the popular utility nearly a year before its discovery.

The backdoor gave anyone with knowledge of its existence the ability to execute commands as root, meaning an attacker could take control of the targeted endpoint. According to Jamie Cameron, the author of Webmin, the bogus version was 1.890. Two additional versions were found with near identical backdoor code, version 1.900 and 1.920.

An updated version of Webmin 1.930 and Usermin version 1.780 address the vulnerabilities.

“Neither of these were accidental bugs – rather, the Webmin source code had been maliciously modified to add a non-obvious vulnerability,” Cameron wrote in a post outlining the issues.

According to Cameron, the Webmin development build server was compromised on April 2018. He said that’s when a vulnerability was added to the “password_change.cgi” script. Cameron explained, by backdating the file it was reverted to a Github “checked-in” version of code and escaped scrutiny. The code then shipped with the 1.890 version of the Webmin release.

Then in July 2018, the malicious actor behind the vulnerable version of the “password_change.cgi” script updated the file again. This time the change impacted the Webmin 1.900 release. “This time the exploit was added to code that is only executed if changing of expired passwords is enabled,” the author wrote.

Things got interesting in Sept. 2018 when the vulnerable build server was decomissioned and replaced with a newly installed server running CentOS 7. However, the vulnerable code “was copied across from backups made on the original server,” the author explained.

Either way, the bug only impacted systems with a specific configuration. “To exploit the malicious code, your Webmin installation must have Webmin -> Webmin Configuration -> Authentication -> Password expiry policy set to Prompt users with expired passwords to enter a new one. This option is not set by default, but if it is set, it allows remote code execution,” according to a description of the bug.

The bug itself surfaced at DEF CON 2019, when a researcher released zero-day research illustrating a bug (CVE-2019-15107) that made use of the vulnerability. It was this research that shed light on the malicious code injected back in July 2018. “In response (to CVE-2019-15107), the exploit code was removed and Webmin version 1.930 created and released to all users,” Cameron wrote.

In response to the implanted malicious code Webmin said it would adopt new mitigations efforts such as:

  • Updating the build process to use only checked-in code from Github, rather than a local directory that is kept in sync.
  • Rotating all passwords and keys accessible from the old build system.
  • Auditing all Github checkins over the past year to look for commits that may have introduced similar vulnerabilities. 

Interested in more on the internet of things (IoT)? Don’t miss our free Threatpost webinar, “IoT: Implementing Security in a 5G World.” Please join Threatpost senior editor Tara Seals and a panel of experts as they offer enterprises and other organizations insight about how to approach security for the next wave of IoT deployments, which will be enabled by the rollout of 5G networks worldwide. Click here to register.

Suggested articles


  • bruce davidson on

    This is more evidence that "many eyes" is a naive and inadequate strategy for securing open source projects. To start with, you can't even be sure that you can trust each of those set's of eyes, let alone rely on them.
    • yotties on

      What makes you think that paid-for-eyes will do better?
  • J on

    Nice fix but never addressed the who and why in its act of deceptive practices to begin with. For us, we have removed all of their code.
  • AM5 on

    Oh please, it is not. How soon would the vulnerability have been discovered if many eyes weren't looking at it?
  • Anonymous on

    I have no experience with webmin. All you have to do is read the first few dozen lines of features to figure out this system is/was a threat. Any mature admin is going to cast a suspicious eye at anything that wields to power this 'thing' does. From their own splash "Webmin removes the need to manually edit Unix configuration files like /etc/passwd" Bright, Red, Flapping, Snapping flag, right there. Stuff like this is almost necessary anymore considering the scale of websites today but anything that belittles serious threats needs quite a bit of scrutiny.
  • Anonymous on

    Who edits the passwd file manually?
  • j on

    Somewhat to the contrary, I see this as a potential example of "many eyes" working. After all... this sabotage was ultimately discovered and fixed. While I do not know the exact methods the security researcher used in discovering this vulnerability, I feel it's reasonable to assume that the code being easily accessible assisted the research more than it hampered it. Open source, in itself, provides no assurance of security. Rather, it makes it easier to audit/test and in so doing increases the likeliness of security verses closed source solutions (my opinion), given the same internal project constraints/resources. The valid counter argument to this would be the question: "Does increasing the likeliness that bad-actors can also discover vulnerabilities (along with the good-ones) provide an overall detriment to the security of the code?" The answer to that question is quite subjective and will depend on numerous factors. Personally, I like being able to dig my hands into the code if I so choose (and knowing like-minded, curious, individuals can as well). Taking a step back, the problem should be: "How do I secure a system to the best of my abilities with the resources I have, and will that mitigate the risk of that systems failure/compromise sufficiently to justify my use of it?" It's impossible to prove anything beyond all possible doubt. The more beneficial mindset towards security is always going to be based around risk assessment/management. There is no such thing as an absolutely secure application. So design systems with enough mitigations to provide the amount of risk you are willing to except in their failure. I also feel it is also worth pointing out that the correct decision to a company open sourcing (or using open source) software is not ultimately a matter of security, but of profit to the company. Any company's goal is to make money, not secure software and systems (though obviously that is a factor in the equation).

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.