search

immauss / openvas

Containers for running the Greenbone Vulnerability Manager. Run as a single container with all services or separate single applications containers via docker-compose.
GNU Affero General Public License v3.0
360 stars 102 forks source link

Unable to scan with WMI on latest image... #125

Closed gooseleggs closed 1 year ago

gooseleggs commented 2 years ago

Hello

When I try and scan with the latest docker image, and scan WMI, I am getting an error that I have asked on the OpenVas forum: https://community.greenbone.net/t/wmi-failing-to-scan-machines/12406/2

However, I am not sure if I am using the latest openvas-smb executable or not. Can you please advise.

gooseleggs commented 2 years ago

I have downloaded the openvas-smb and compiled it. I can connect with wmic, but when I run the scan, I now get "nasl_wmi_connect: WMI Connect failed or missing WMI support for the scanner". The impacket-wmiexec is able to run, at least as root. I am not seeing a "not found in path" issue.

immauss commented 2 years ago

If you are using the “latest” or “21.04.09” tag, then yes. That is the most recent release from Greenbone.

gooseleggs commented 2 years ago

Thanks.

gooseleggs commented 2 years ago

I have done some more research into my problem. With the latest version of the image (21.04.09), I get this:

root@a4fd765abf0d:/# wmic -U administrator%missile //192.168.9.26 "select * from Win32_ComputerSystem"
[/build/openvas-smb-21.4.0/wmi/wmic.c:196:main()] ERROR: Login to remote object.
NTSTATUS: NT code 0x80010111 - NT code 0x80010111

There is an open ticket on openvas-smb that describes this issue. When I download, apply the fix, and compile the update with the code, it is working correctly, ie wmic returns data, and WMI authenticated scans work. The fix is just waiting on someone to validate that it works in that I can use the wmic function to successfully get results.

Might pay to keep an eye on the issue and update when checked into upstream?

immauss commented 2 years ago

Ooooh .... How difficult was it to apply the patch? Is it something I could script into the build?

-Scott

gooseleggs commented 2 years ago

Easy to script in. Haven’t looked at your build. But a git clone, sed to alter the line then a cmake, make, make install. I can write up some instructions if that helps.

Sent from my iPhone

On 20/06/2022, at 5:41 AM, GE Scott Knauss @.***> wrote:

 Ooooh .... How difficult was it to apply the patch? Is it something I could script into the build?

-Scott

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.

immauss commented 2 years ago

That would be awesome. Thanks, Scott

immauss commented 2 years ago

@gooseleggs Let's see if 22.4 resolves this!

-Scott

immauss commented 2 years ago

@gooseleggs If you get a chance, could you test this with the 22.4.01 image?

-Scott

gooseleggs commented 2 years ago

Hello I have finally got around to testing this. While the pull request from the original issue has gone in upstream, it still caused issues. There was another comment which seems to get it going. Here is some code that works when run manually in the container. I have tried to make it docker friendly, but may need some tweaks

\# Fix for WMI Scan issue.  Install dependances - build as per openvas-smb document after fixing file
RUN apt update  && \
    apt install -y gcc cmake pkg-config gcc-mingw-w64 libgnutls28-dev perl-base heimdal-dev libpopt-dev libglib2.0-dev libunistring-dev git  && \
    cd /root && \
    git clone https://github.com/greenbone/openvas-smb.git  && \
    mkdir openvas-smb/build && \
    sed -i 's/ncacn_ip_tcp:%s/ncacn_ip_tcp:%s[sign]/' /root/openvas-smb/samba/lib/com/dcom/main.c && \
    cd openvas-smb/build && \
    cmake .. && \
    make && \
    make install
immauss commented 2 years ago

@gooseleggs Have you had a chance to test the latest 22.4 image ?

Thanks, Scott

gooseleggs commented 1 year ago

Hey @immauss

Still no joy, and I need to run the commands above to get it too work inside the container, or build another container with the updates

immauss commented 1 year ago

Looking at your update process, it looks like you are pulling from the main branch from Greenbone. That can be dangerous as they tend to make changes there that break things.

Do you know if that change works with the latest published code too? I'm going to give it a shot, and see, but don't know if I have a good way to test.

Can you give me some detail on the hosts you are scanning and how to see the failure so I can more readily test my attempts?

Thanks, Scott

immauss commented 1 year ago

OK ... I think I managed to get your mod into the base build.

Can you give a try on tag 22.4.05 ?

-Scott

gooseleggs commented 1 year ago

The easy way to tell is to use the wmic command (against a windows host). Running it without the patch shows as access denied (Event log on host tells you it is denying as the level needs to be raised). Running it after doing the commands above will return the result of the query.

Just running wmic by itself will return an example query.

Maybe have an environment variable that switches one out for the other during startup? Not many others are complaining of this issue.

immauss commented 1 year ago

my problem at the moment is ... I don't have any windows boxes to test with ... :/

immauss commented 1 year ago

@gooseleggs Any chance you have tested with the latest builds ? They should include the fix you came up with.

-Scott

gooseleggs commented 1 year ago

Sorry for the delay. I have used the 22.4.06 image from 6 weeks ago, and fix is not in there. It is only in the .5 version of the container?

immauss commented 1 year ago

22.4.05 ?

immauss commented 1 year ago

Strange ... the same fix you suggested that I added at 22.4.05 is still in the code.

https://github.com/immauss/openvas/blob/a7b772d1362f52e2908f0b573ae87bb6be72d15d/build.d/openvas-smb.sh#L10

-Scott

immauss commented 1 year ago

And the Greenbone source has not changed ....

gooseleggs commented 1 year ago

I see that you are pulling from Greenbone-archive, and I am pulling from most likely the active source. Maybe that is the difference?

immauss commented 1 year ago

Ah ... yes. That will make a big difference. Pulling from the main branch has broken things badly in the past ... so I've stuck with the latest release.

When I trace back through the comments I came to this fix implemented by GB.

https://github.com/greenbone/openvas-smb/pull/46/files/8fca44a2bac6a20f604ba25bd277661f06d6e4ae

Which is different.

Can you point me to the fix you found ...

And I hope you could test a new build? tag: 22.4.gooseleggs.

I added a sed for the version bit referenced above.

It's building now, but I won't be able to baby sit it, if you don't find it on docker hub, then the build likely failed, and I'll have to look at it later.

Thanks, Scott

gooseleggs commented 1 year ago

Scott - here is the reference here: https://github.com/greenbone/openvas-smb/issues/41. I think I found it elsewhere as well. Not sure how you specify the options through so that is why I forced it by changing the source code. I also did originally only do the change in that PR referenced (changing the number from 1 to 7), then that seemed to stop working as well, which is why I did the second one (change of the DCOM version is in the mainstream download now).

gooseleggs commented 1 year ago

I have downloaded 22.4.gooseleggs and that seems to be working in my lab. I have just completed some scanning at another site which definitely had the problem, so if the gooseleggs image does not have the sed -i 's/ncacn_ip_tcp:%s/ncacn_ip_tcp:%s[sign]/' openvas-smb*/samba/lib/com/dcom/main.c then it might break and that will be a good test. I wont be able to do this until Monday.

immauss commented 1 year ago

This should be resolved now with the latest tag as well. Please let me know if it is not.

Thanks, Scott