After some openvas scan, I found a report on one of my host:
Linux Home Folder Accessible (HTTP)
An httpd binary was running on my system and exporting my /root folder.
We have lot of time trying to find how we were compromise but in fact it was openvas which bring up this.
The httpd binary is the busybox httpd version and is present on a docker image. (So reachable via a long /var/lib/docker/xxx path)
One openvas plugin seems to “find” all httpd binary everywhere and grab their version by running httpd -v.
BUT busybox httpd do not print version via -v, -v enabling -verbose in that case.
Since openvas is logging as root for the local vuln scan, the httpd is ran from /root exposing publicly .bash_history, .ssh etc…
For verifying this theory, I created a fake /usr/bin/httpd shell script which dump arguments and parent process.
I started an openvas scan on this machine and saw that soon after, my binary was ran.
The /proc/x/cmdline of the parent is /bin/sh-cLANG=C; LC_ALL=C; /usr/bin/httpd -v
Funny that scanning for vulnerabilities lead to starting a new one.
The plugin doing this is probably gb_apache_http_server_ssh_login_detect
So I search the NVT repository URL to made an official bug, I didnt found any information about it.
It seems you are using Greenbone as a malware scanner rather than a vulnerability scanner. Vulnerability scanning with Greenbone is a proactive measure to detect vulnerabilities before a system can be exploited by attackers. So, using Greenbone to detect and quarantine malware or executing local security checks on an already compromised system could of course lead to executing attacker code.
For example, if the attacker has already placed the busybox httpd binary on your system, they don’t need a Greenbone NASL plugin to execute their malware. Greenbone has to execute files on the host to do local security checks and any system that has been compromised by an attacker could have binaries replaced if the file permissions are already weak.
Greenbone does have local security checks that can detect local file permission weaknesses such as global write permissions to any program that executes with root/admin permissions. Your system has a security weakness and has been exploited, therefore you need to revert to a backed-up secure baseline without the malware and run Greenbone again to secure the permissions of privileged files.
No I dont use it as a malware scanner.
BUT my goal and the way I use it is orthogonal to the issue.
The server was and is safe AND NOT compromised.
The busybox httpd is a valid binary.
The problem is: A simple scan, with some default LEAD to a vulnerable host.
The plugin should not try to execute httpd -v since, if it is a busybox, it will start it hosting /root on public interface.
Sorry, I didn’t quite understand your explanation of what was happening. I thought you were referring to a trojanized httpd. Now I understand what you mean when you say this:
BUT busybox httpd do not print version via -v, -v enabling -verbose in that case.
Trusting and executing any command - not only httpd -v - that is present locally on the scan target could have unintended consequences. There are other options for identifying the version of a service binary, such as analyzing the file hash instead of executing it to check the version, and it would be more secure to import custom scanning tools rather than trusting the programs on the target host.
I think the vulnerability you are pointing to is that when conducting an authenticated scan as a privileged user, the scanner will execute any file named httpd as root, which could be placed there by an unprivileged user right?
generally it is strongly discouraged to use the root user for authenticated SSH login-based scans due to various (security relevant) reasons which could have a wide range of (security) implications like seen e.g. here.
While the documentation is not that explicit on this there is still the following mentioned there:
For authenticated scans on Linux or Unix systems, regular user access is usually enough.
which is more wide spread then the Busybox binary having the same name.
Changing the detection methodology to e.g. analyzing the file hash is (at least currently) not feasible and won’t happen anytime soon (at least not on a short to mid-term basis) as the detection needs to work “out of the box” for hundreds of different versions and operating systems.
The problem discussed here will be gone once a low-privileged user is used for authenticated scanning as that user is not allowed to bind on the “low” port 80.
But we will also try to see if we can e.g. change the detection routine (to e.g. not call httpd -v if a Busybox binary has been found) as time permits.