
Backdoor Found in Webmin - whiteyford
https://decipher.sc/backdoor-found-in-webmin-utility
======
LinuxBender
To my surprise, not only are people using webmin, they still leave it open to
the internet. [1]

[1] -
[https://www.shodan.io/search?query=webmin](https://www.shodan.io/search?query=webmin)

~~~
Carpetsmoker
Webmin probably has a higher than average number of users with limited or no
technical skills, so not that surprising really.

This is why blaming the user isn't very effective, and safe defaults are so
important.

~~~
nineteen999
Interesting that a search for Kubernetes on Shodan returns even more results
than Webmin.

[https://www.shodan.io/search?query=kubernetes](https://www.shodan.io/search?query=kubernetes)

------
opless
Webmin has had many remote vulnerabilities for many years, yet people still
use it/leave it open to the internet.

[https://www.cvedetails.com/vulnerability-
list/vendor_id-358/...](https://www.cvedetails.com/vulnerability-
list/vendor_id-358/Webmin.html)

------
jlgaddis
> _“It appears that a build /test system was compromised some time last year
> and the exploited added to code in the directory from which packages are
> built (and file timestamps modified to make this change not show up in a git
> diff),” Cameron said in an email._

How, exactly, does that happen?

Does git look at timestamps first and, assuming they aren't different, not
hash the file contents to compare the SHA1? This [0] git FAQ makes me think
the answer is "no".

Another FAQ:

> _git diff and other Git operations is optimized so it does not even look at
> files whose status (size, modification time etc) on disk and in Git 's index
> are different. [...] If the file has been touched somehow, git diff has to
> look at the content of and compare it which is a much slower operation even
> when there is in fact no change._

[0]:
[https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Gi...](https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F)

~~~
blackflame7000
I suspect that in addition to modifying the timestamp, the attacker also had
to ensure the filesizes were the same by possibly removing whitespaces or
refactoring other code.

~~~
londons_explore
Is there a 'git verify' or something that will report such tampering?

------
flingo
Make sure to put any of your own personal web services behind some dumb
authentication system to avoid most of these things biting you before you hear
about them.

I use nginx + basic http auth, since I'm using it for https anyway.

------
jlgaddis
Here's the original post from the author of Webmin:
[http://www.webmin.com/exploit.html](http://www.webmin.com/exploit.html)

------
blackflame7000
I hope they are able to find the source control logs and prosecute whoever
embedded that code maliciously.

~~~
jlgaddis
As mentioned (in large print!) in the article:

> _“How the exploit happened is impossible to determine at this point, as the
> machine in question has been decommissioned. "_

~~~
blackflame7000
I understand that, but they also seem to know a lot about what happened with
respect to when things were checked in and with a little forensics perhaps
they can figure out who it was. A deleted hard drive hasn't stopped people
before and they shouldn't just give up that easily.

~~~
londons_explore
I feel like this is probably an inside job...

------
git-man-2000
“and file timestamps modified to make this change not show up in a git diff”

...ok

