SoylentNews is people
SoylentNews
from the creeping-around-the-back-door dept.
Submitted via IRC for SoyCow2718
Webmin, the open source web-based interface for managing Linux and UNIX systems, contained a remote code execution vulnerability for more than a year and it's believed to be an intentional backdoor.
The vulnerability, tracked as CVE-2019-15107, was disclosed at the recent DEFCON hacker conference, and Webmin developers were not notified of its existence before the details were made public.
The flaw is related to a feature designed for changing expired passwords and it allows a remote, unauthenticated attacker to execute arbitrary commands with root privileges.
The security hole impacts Webmin 1.882 through 1.921, but most versions are not vulnerable in their default configuration as the affected feature is not enabled by default. Version 1.890 is affected in the default configuration. The issue has been addressed with the release of Webmin 1.930 and Usermin version 1.780.
[...] A Shodan search shows over 215,000 internet-exposed Webmin instances, mostly located in the United States, France and Germany. However, there are roughly 15,000 results for searches of version 1.890, which is vulnerable in the default configuration.
Source: https://www.securityweek.com/webmin-backdoored-over-year
(Score: 5, Informative) by FatPhil on Wednesday August 21 2019, @01:12PM (2 children)
The bug was never introduced in the first place.
I just cloned github webmin/webmin, as of right now, and looked at where the exploit is:
https://github.com/webmin/webmin/blame/master/password_change.cgi
according to the exploit write-up:
https://pentest.com.tr/exploits/DEFCON-Webmin-1920-Unauthenticated-Remote-Command-Execution.html
https://pentest.com.tr/images/defwebmin20-4.png
And the exploit isn't in that repo at all. So this must be some forked version.
Bonus points - the guy writing the exploit write-up is either stupid and spouting nonsense, or deliberately deceiving the reader with nonsense. Neither's a particularly desireable state of affairs, and doesn't make him look good at all. Yes AkkuS <Özkan Mustafa Akkuş>, if you google your name to see what people are saying about your vulnerability disclosure (incidentally - irresponsible disclosure, again, that makes you look like a twat), I'm calling you out. The thing he claims is "exactly" the bug *absolutely isn't the bug*. Any perl coder with any experience should immedately be able to detect why/where the code's all qxed up.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 4, Informative) by ThatIrritatingGuy on Wednesday August 21 2019, @05:20PM (1 child)
I strongly disagree that the issue was in a forked version.
It is true, that it did not show up in github source, however uploading to SourceForge was part of the release process for the original team [github.com]. For some reason, head developer recently removed [github.com] release instructions mentioning SourceForge from the github repo.
Additionally, the exploit was based on passing URL query value to a qx function, that executes provided string as system command with root privileges. This qx// function showed up in a github issue 947 [github.com], where previously mentioned developer admitted "there was a local edit to that file on my packaging system" and promptly closed the issue. Anyone, that knows perl, should get suspicious, when an unexpected qx shows up in their code.
I don't like conspiracy theories, but I find it very hard to give this developer the benefit of the doubt.
(Score: 2) by FatPhil on Wednesday August 21 2019, @09:13PM
Dear readers, please upmod parent, he makes a good point.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves