[BUG] Unable to get WMI working

[gooseleggs]

Using the 25.01.01 container, and trying to perform a WMI scan against a known machine, I get

Description (Knowledge base entry)                                                              : Value/Content
--------------------------------------------------------------------------------------------------------------------------------
Access to the registry possible (SMB/registry_access)                                           : TRUE
Access via WMI possible (WMI/access_successful)                                                 : FALSE

under the Authenticated Scan / LSC Info Consolidation (Windows SMB Login) report for a scan. Jumping into the container and running the wmic command, or the impacket-wmic command works as expected (I can get a response). However, there is nothing in the scanning logs, other than WMI access is denied or not available.

For comparison, I spun up the Greenbone community containers (that was a mission!!) and did a comparison scan. That scan was successful, and I received

Description (Knowledge base entry)                                                              : Value/Content
--------------------------------------------------------------------------------------------------------------------------------
Access to the registry possible (SMB/registry_access)                                           : TRUE
Access via WMI possible (WMI/access_successful)                                                 : TRUE

So, how would I go about trying to troubleshoot this to provide some valid feedback??

[immauss]

@gooseleggs
Thanks. I'll have to take a look at this.
Do you know if this worked in prior versions? (Can you test a few versions back? )

-Scott

[gooseleggs]

Scott

So today, I enabled Audit logging for all WMI created processes. I ran the Greenbone scanner, and then put the line openvas wmi from here in the audit log file, and then run the Immauss container. Both containers ran the same scan (separate databases between the two). Greenbone succeeded, Immauss did not. Attached is the outputs of the audit log to pour over. The Greenbone scanner seems to start python3 as arg0, and Immauss is /bin/sh. If I go into the container, and try /bin/sh /usr/bin/impacket... it succeeds. However, in the audit log it fails with a -2 error.

As per when did we think it broke - not sure. 22.4.47 had the fault.

wmi.log

[immauss]

OK ...
odd but decipherable.

"-2" means the file was not found.

The audit logs, (Thank you btw) show the failure trying to execute "impacket-wmiexe" .
Which is not on the image.
instead, what is being built is "impacket-wmiexec"

I'm relatively certain this is the binary needed, but no idea why it would be named differently.

Could you try linking it in the container and re-running the scan?

docker exec -it openvas bash -c "ln /usr/bin/impacket-wmiexec /usr/bin/impacket-wmiexe"

If that works, I just need to figure out "why" its different, and either fix the why or add the linking to the startup.

Thanks,
Scott

[gooseleggs]

Interesting...but no success.

So I did what you asked. However /usr/bin/impacket-wmiexec points to a script, which basically gets back what is after the - and calls that using python. So, to set up the impacket-wmiexec file meant that I just needed to copy the script file and hard code the wmiexec.py call. Unfortunately, this does not work. Also make impacket-wmiexe point to the hard coded script as well. No dice.
The error of name from impacket-wmiexec -> impacket-wmiexe seems to occur after a call to basename by the looks of the output.

I thought that it might be because the linking was relative, ie ls -l /usr/bin/impacket-wmiexec --> ../share/impacket/script. So, I changed that to be full path and not relative = no dice.

So, don't have an answer yet

[gooseleggs]

Scott

Done a few more hours into this. Gone down the wrong rabbit hole, and back up. Haven't got an answer, but it must be in the building of the image, as WMI is not an external call.

So, changes to the base image:

First the wrong rabbit hole....
The version of impacket-wmiexec in your image must be the version from the repo. This version is old.

root@3dd467b556a3:/# impacket-wmiexec
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

Doing this in the Greenbone container results in:

root@ospd-openvas:/ospd-openvas# impacket-wmiexec
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies

Looking at the Dockerfile from Greenbone (https://github.com/greenbone/ospd-openvas/blob/main/.docker/prod.Dockerfile), the following lines are used:

# produces the bug ` ‘/usr/share/doc/python3-impacket/examples/wmiexec.py’: [Errno 2] No such file or directory`
RUN apt-get remove -y python3-impacket || true
RUN apt-get autoremove -y
...
# install impacket via pip and not apt-get to get the latest version
RUN python3 -m pip install --break-system-packages impacket 
# openvas is expecting impacket-wmiexec to be in the path although it got renamed
# until openvas is fixed we create a symlink
RUN ln -s /usr/local/bin/wmiexec.py /usr/local/bin/impacket-wmiexec

Next testing WMI...
So, I created a NASL test script to validate the WMI. It is attached. Running this in Immauss container...

test.nasl.txt

root@3dd467b556a3:/# openvas-nasl test.nasl -X -t 10.1.101.243 -i /data/var-lib/openvas/plugins/
lib  nasl-Message: 23:40:27.556: Starting
lib  nasl-Message: 23:40:27.556: 10.1.101.243
lib  nasl-Message: 23:40:27.556: JC-S25\Administrator
lib  nasl-Message: 23:40:27.556: BadPassword123
lib  nasl-Message: 23:40:27.556: Username is not blank
lib  nasl-Message: 23:40:27.556: About to WMI Connect
[/build/openvas-smb-22.5.6/samba/librpc/rpc/dcerpc_connect.c:798:dcerpc_pipe_connect_b_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_b_recv
lib  nasl-Message: 23:41:27.558: nasl_wmi_connect: WMI Connect failed or missing WMI support for the scanner
lib  nasl-Message: 23:41:27.558: Finished connecting

Looking at the audit log file, nothing is called, so this wmi_connect must be an internal function to openvas.

When run inside the Greenbone opsd container

root@ospd-openvas:/ospd-openvas# openvas-nasl test.nasl -X -t 10.1.101.243 -i /var/lib/openvas/plugins
lib  nasl-Message: 23:22:47.620: Starting
lib  nasl-Message: 23:22:47.620: 10.1.101.243
lib  nasl-Message: 23:22:47.620: JC-S25\Administrator
lib  nasl-Message: 23:22:47.620: BadPassword123
lib  nasl-Message: 23:22:47.620: Username is not blank
lib  nasl-Message: 23:22:47.621: About to WMI Connect
lib  nasl-Message: 23:22:47.642: Finished connecting
lib  nasl-Message: 23:22:47.642: Yeeha - we connected

test.nasl.txt

[immauss]

that triggered a memory.
I had moved the install of impacket to pip vs apt sometime ago ...
But somehow, impacket was added back into the list of packages to install in the base image. The command I was using for the pip install was the same as GB:

python3 -m pip install --break-system-packages impacket 

I'm thinking it took that option seriously and broke the system packages. :)

I'm rebuilding again now without the impacket by apt.

the tag will be 25.02.goose

-Scott

[gooseleggs]

Scott

That image still has the 10.0 version of impacket in it. Manually removing the system version and installing the python version is not resolving it either.

I think the openvas-smb needs to be looked at as well as this seems to do the wmi stuff.