OpenVAS is identifying all of our iLO cards (HP Lights-Out 100) as having Adobe Reader. The cards are very dumb, and do not even support installing software, let alone something like Adobe Reader. They’re not really even “modern” devices, although we do provide OpenVAS with SSH credentials to them.
They’re hardware version 1.0, firmware version 4.26, and list their description as DL160 G6, if that helps anyone somehow.
We show many medium and high Adobe vulnerabilities on these devices, with obviously bungled “Location” tags, making me think a parsing error has occurred in some CPE lister somewhere.
I know that …800108 is not an oid that carries risk, but I thought its output (two different firings of 800108 in the same scan) might be helpful in diagnosing why this is happening. Its output is below, and the descriptions are given exactly as they appear - mismatched quotes, trailing periods, and all (although indented for this forum):
Thanks for your report and the detailed information provided. There seems to be indeed something uncommon on this iLO device so that the functions trying to find a file and extracting the information from it showns an unexpected behavior.
If you have the possibility and an installation with the openvas-nasl command line tool at hand it would be great if you could provide the output (please use a terminal with unlimited scrolling as it might be a longer output) either as an attachment here or via a direct message to me (if it contains too much sensitive data):
Before running the command you might need to change into the /var/lib/openvas/plugins folder (path depends on your installation and might be adapted on your environment).
Thanks for your reply. Attached is the output of the command you provided. iLO-ov-output (13.4 KB)
Just a bit more background about the device, in case it helps. The prompt for the device is
/./->
and is not configurable. There is no /bin/sh, or any sh or bash anywhere for that matter. It’s a pretty rudimentary command line, and I think the only valid commands are “cd”, “version”, “exit”, “show”, and “help”.
The device does have a web console, which is how one manages it.
Note that the output is the same for all of our iLO devices (except of course the IP).
Just realized stderr did not make it into that file. Attached is the output of that same command, but including stderr. iLO-ov-output-with-stderr (17.6 KB)
Thanks again for your response and for providing such detailed information, this has helped quite a lot to understand whats happening here.
Two changes where made which should solve this seen issue:
Basic detection of such an HP iLO device was implemented (stay tuned for an additional detection and version gathering script in the next few weeks). This also includes setting the internal information within the SSH implementation on NASL side to not launch VTs which requires linux/unix tools like find, cat etc. available on the target system.
The Adobe Reader Detection script was updated to be less error prone once such unexpected responses are received.
Those changes have arrived the feed once the “Determine OS and list of installed packages via SSH login” VT (OID: 1.3.6.1.4.1.25623.1.0.50282) has reached the feed with revision r13537.
It seems this issue may have come up again, on a different class of devices. I’d like to run the command you gave me and post the output for advice, but SSH is running on a nonstandard port (37222). How do I inform openvas-nasl of that?
Basically it should be possible to append the following to the mentioned openvas-nasl call:
--kb="Services/ssh=37222
or replace the existing --kb="Services/ssh=22 to run the check against a non-standard SSH port.
Unfortunately the openvas-scanner function get_ssh_port (used by the NASL function ssh_connect) seems to not use this where it should and is always falling back to use the port 22.
I have raised an internal ticket to check why this is happening. For now the only possibility to use a different SSH port is to update the ssh_func.inc and change:
sess = ssh_connect();
in the function ssh_login_or_reuse_connection() to the following:
I’m slogging my way through trying to figure this out. Looks like OpenVAS is completing scans with this new device (a rudimentary *nix system much like the one from my original post above), and claiming it has Adobe software on it, which it does not. I’m running openvas-nasl with the kludge in ssh_func.inc, and with the arguments you suggested above:
set key Host/runs_unixoide -> 1
No Best matching OS identified. Please see the NVT 'Unknown OS and Service Banner Reporting' (OID: 1.3.6.1.4.1.25623.1.0.108441) for possible ways to identify this OS.
Forgive my lack of understanding here - what am I doing wrong that I get this result, but a full scan gives me much more information?
Besides that, the original problem still remains, that Adobe Reader is falsely identified on this device, at the following “location”, eerily similar to my original post:
Mhhh, this is really strange. The call works for me (after hardcoded the non-default port in the ssh_func.inc) so not sure whats going on here.
As an alternative you could also do a “full” scan to gather the necessary information. For this you need to clone the “Full and Fast” scan config, go to the Network Vulnerability Test Preferences and change the setting “Enable SSH Debug” of the VT “Global variable settings” to “yes”.
Afterwards a full scan with this scan configuration should log the required information to the openvassd.dump (GVM-9 and below) / openvassd.log (GVM-10+). The location depends on your installation but should be somewhere in /var/log/openvas.
Thanks @cfi, that did the trick. I’ve PM’d you the results of the scan. Would you be able to take a look and see why the scan is “finding” Adobe Reader, etc.? Let me know what you find if you don’t mind - I’d love to understand what’s going on as well.
PN received, thanks again for providing this information. Please stay tuned, will review the info next week and give some more background afterwards.
But basically the reason why this is happening was explained in some text in between previously:
The current SSH implementation is working in a way that it requires such systems not having a full linux shell available to be detected as such. As an example you can find the implementation for the HP iLO devices initially reported at around line 400 in the file gather-package-list.nasl.
Something similar is most likely required for this second system as well.
Thank you. Would it also be possible to have the package enumerator parse the return string for bogus values? For example, seems like if the check for Adobe Reader starts with find "/" -maxdepth 7 -mindepth 1 and the response also starts with find "/" -maxdepth 7 -mindepth 1, there might be some way to detect this as not actual evidence of Adobe Reader existing. Maybe some sort of heuristic comparison between the command and the response around line 2476 of ssh_func.inc? There’s other places it occurs, too, like whatever function generates the command
but I’ve not been able to find that one in the code.
This would probably eliminate lots of false positives in cases where the remote device’s operating system has not been correctly identified as lacking a full shell.
So this should be fixed in one of the next feed updates including some additional updates to the handling of such pfSense applications.
The main problem in this case wasn’t the handling of the device itself in the SSH functions but a used “tcsh” shell for that specific user which wasn’t handled correctly (by appending a /bin/sh to each command as usual).
Nevertheless from the above the suggestion on gracefully handle such bogus return values when searching for binaries was implemented as well.
While the outcome might be similar / the same the reason could be a completely different (like seen previously in comment #11 and comment #13).
To check where this newly reported issue is coming from it would be great to get another batch of logs like asked in comment #9.
Please note that those two VTs are checking for issues in web pages / services via an unauthenticated HTTP connection and are unrelated to this topic. These should be reviewed and mitigated accordingly.
