[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.

[gooseleggs]

Any update on another build for WMI? I am hoping to get it sorted before another engagement next week :-)

[immauss]

@gooseleggs

Sorry ... it's been crazy days around here ...

From 25.03.03 pushed just moments ago:

root@b2ff4f715c5f:/# dpkg -l | grep packet 
ii  libnet1:amd64               1.1.6+dfsg-3.2                      amd64        library for the construction and handling of network packets
ii  libpcap0.8:amd64            1.10.3-1                            amd64        system interface for user-level packet capture
root@b2ff4f715c5f:/# 
root@b2ff4f715c5f:/# dpkg -l | grep wmi
root@b2ff4f715c5f:/# wmiquery.py --version
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

usage: wmiquery.py [-h] [-namespace NAMESPACE] [-file FILE] [-debug] [-com-version MAJOR_VERSION:MINOR_VERSION] [-hashes LMHASH:NTHASH] [-no-pass] [-k] [-aesKey hex key]
                   [-dc-ip ip address] [-rpc-auth-level [{integrity,privacy,default}]]
                   target
wmiquery.py: error: the following arguments are required: target
root@b2ff4f715c5f:/# impacket-wmiexec --version 
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

usage: impacket-wmiexec [-h] [-share SHARE] [-nooutput] [-ts] [-silentcommand] [-debug] [-codec CODEC] [-shell-type {cmd,powershell}] [-com-version MAJOR_VERSION:MINOR_VERSION]
                        [-hashes LMHASH:NTHASH] [-no-pass] [-k] [-aesKey hex key] [-dc-ip ip address] [-target-ip ip address] [-A authfile] [-keytab KEYTAB]
                        target [command ...]
impacket-wmiexec: error: the following arguments are required: target

So I'm pretty sure it has the right version it now.

Can you test and let me know.

-Scott

[gooseleggs]

Yes - can confirm it is now using v12 impacket. Unfortunately, there is still something note quite right - probably with the compilation of the WMI components in openvas-smb.

OK - there is a workaround. If I manually build OpenVAS SMB and install in the container, it seems to work. So, steps from the standard 25.03.03 container:

apt update && apt install -y build-essential cmake  gcc-mingw-w64 libbsd-dev libcurl4-openssl-dev libcjson-dev libgcrypt20-dev libglib2.0-dev libgnutls28-dev libgpgme-dev libhiredis-dev  libical-dev libjson-glib-dev libksba-dev libldap2-dev libmicrohttpd-dev libnet1-dev libpaho-mqtt-dev libpcap-dev libpopt-dev  libpq-dev libradcli-dev libsnmp-dev libssh-gcrypt-dev libunistring-dev libxml2-dev postgresql-server-dev-15 uuid-dev  heimdal-dev
wget https://github.com/greenbone/openvas-smb/archive/refs/tags/v22.5.7.tar.gz
tar xvzf v22.5.7.tar.gz
cd openvas-smb-22.5.7
cmake .
make 
make install

I then run the test.nasl script that I wrote and all OK.

So, it appears that you may need to look at this component of the build.

[immauss]

:/
OK .. I'll take look this morning

Thanks!

-Scott

[immauss]

OK ... the only thing missing was heimdal I've added it to the base image and to the build, which is running now.

-Scott

[immauss]

Curiously ....

I was installing the heimdal-dev in the build script. So it would build, but was missing some of the heimdal pieces in the base image.

There should a beta tag in docker hub shortly.
If you could give that a try and let me know if resolves....

Thanks,
Scott

[immauss]

Now that I think about it ... that was intentional. At some point in the past, installing the heimdal bits conflicted with some other kerberos bits that had to be installed too. But now the build is completing with no conflicts ... so ... Hopefully this will take care of it.

Thanks,
Scott