Closed bellum07 closed 1 year ago
The crucial difference between the not working wmic
call on the docker container seems to be:
[/source/samba/lib/com/dcom/main.c:527:dcom_determine_rpc_binding()] Using binding ncacn_ip_tcp:m
[/source/samba/librpc/rpc/dcerpc_connect.c:513:continue_map_binding()] Mapped to DCERPC endpoint 135
[/source/samba/lib/util/util.c:334:interpret_addr()] sys_gethostbyname: Unknown host. m
vs. the working one on the VM:
[/home/greenbone/source/openvas-smb-22.5.3/samba/lib/com/dcom/main.c:527:dcom_determine_rpc_binding()] Using binding ncacn_ip_tcp:10.10.10.10
[/home/greenbone/source/openvas-smb-22.5.3/samba/librpc/rpc/dcerpc_connect.c:513:continue_map_binding()] Mapped to DCERPC endpoint 135
Note the difference between the IP in Using binding ncacn_ip_tcp:10.10.10.10
vs. the m
in Using binding ncacn_ip_tcp:m
.
Not sure though if this is actually an issue in the way wmic
is build in the docker container, an issue in wmic
itself (which is part of https://github.com/greenbone/openvas-smb) or something completely different.
But it doesn't look like an issue in the scanner itself so this is probably better moved over to https://github.com/greenbone/openvas-smb/issues
But it doesn't look like an issue in the scanner itself so this is probably better moved over to https://github.com/greenbone/openvas-smb/issues
O.K. I thought this is the section for the openvas-scanner docker container itself ... Can you move this issue ticket over or do I have to create it new in https://github.com/greenbone/openvas-smb/issues ?
Moving the issue can be done by the team / maintainers responsible for this repository (i don't have any permissions) and i would leave it up to them to decide where this issue belongs so IMHO no action required from your side :+1:
O.K. Thank you very much 👍
To me it seems that wmic can’t connect to outside of the container but I don’t know the root cause. But I think this is a bug …
I was able to reproduce the issue and I agree. It is like wmic can't connect from the container.
Since it worked with my dev environment (Debian Bullseye - oldstable) but not in docker (Debian Bookworm - stable), I have checked the linked libraries in both systems and compared them.
ldd /usr/local/bin/wmic | wc -l
I found that wmic in the docker container links against 33 libraries, while in my system links against 34 libs. The missing lib is
libresolv.so
Also, I tried this in another system with Debian testing (no docker container). It didn't work and also the link to libresolv.so is missing.
Finally, I locally built new ospd-openvas images but this time based on openvas-smb::oldstable-edge
and openvas-scanner:oldstable-edge
and running wmic from inside the container, it worked as expected.
root@bbb8610ce883:/# ldd /usr/local/bin/wmic |grep resolv
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f571c337000)
root@bbb8610ce883:/# wmic -U DOMAIN/USER%PASS //<TARGET IP>[sign] "SELECT name FROM Win32_ComputerSystem"
CLASS: Win32_ComputerSystem
Name
WIN-U17FD12U4H6
So it is not a docker configuration issue (some missing capability, security option, etc) but a problem with the new base system.
For openvas-smb new stable image, beside the new Debian stable, a new library has been updated: libroken from v18 to v19. I am still not sure if this is the source. Not sure if this is the source of the problem, or the missing link to libresolv.so (included in glibc)
I have wildly replace libroken.so.19 symlink to point against to a copy/paste libroken.so.18 from my Debian Bullseye. Fortunatelly, it was not an issue, but the problem still persists. So, I can discard that the issue comes from libroken19_heimdal
$ sudo grep libroken.so /proc/*/maps
/proc/136848/maps:7f869f260000-7f869f265000 r--p 00000000 00:1a 15842576 /tmp/libroken.so.18.1.0
/proc/136848/maps:7f869f265000-7f869f272000 r-xp 00005000 00:1a 15842576 /tmp/libroken.so.18.1.0
/proc/136848/maps:7f869f272000-7f869f276000 r--p 00012000 00:1a 15842576 /tmp/libroken.so.18.1.0
/proc/136848/maps:7f869f276000-7f869f277000 ---p 00016000 00:1a 15842576 /tmp/libroken.so.18.1.0
/proc/136848/maps:7f869f277000-7f869f278000 r--p 00016000 00:1a 15842576 /tmp/libroken.so.18.1.0
/proc/136848/maps:7f869f278000-7f869f279000 rw-p 00017000 00:1a 15842576 /tmp/libroken.so.18.1.0
I can't realize why wmic is not linking against libresolv.so
@bellum07 could you provide please, version of libc you have installed in your system? (in the one it works)
e.g.:
$ dpkg -l |grep "GNU C L"
ii glibc-source 2.31-13+deb11u6 all GNU C Library: sources
ii libc-bin 2.31-13+deb11u6 amd64 GNU C Library: Binaries
ii libc-dev-bin 2.31-13+deb11u6 amd64 GNU C Library: Developme
Sure 😃
root@vmgreenbone:~# dpkg -l |grep "GNU C L"
ii libc-bin 2.35-0ubuntu3.1 amd64 GNU C Library: Binaries
ii libc-dev-bin 2.35-0ubuntu3.1 amd64 GNU C Library: Development binaries
ii libc6:amd64 2.35-0ubuntu3.1 amd64 GNU C Library: Shared libraries
ii libc6-dev:amd64 2.35-0ubuntu3.1 amd64 GNU C Library: Development Libraries and Header Files
ii libc6-i386 2.35-0ubuntu3.1 amd64 GNU C Library: 32-bit shared libraries for AMD64
ii locales 2.35-0ubuntu3.1 all GNU C Library: National Language (locale) data [support]
Source compiled GVM on a Ubuntu 22.04.3 LTS VM
There is a recent greenbone/openvas-smb#77 which seems to include some info that this might be originating from a different popt
(libpopt
) library version.
Hello,
it seems that the ospd-openvas docker container has a problem with wmi access to the scan target. In the openvas.log of the ospd-openvas container I see:
lib nasl:MESSAGE:2023-08-11 13h19.59 utc:8012: nasl_wmi_connect: WMI Connect failed or missing WMI support for the scanner
When I launch
root@ospd-openvas:/ospd-openvas# /usr/local/bin/wmic -d 7 -U DOMAIN/myScanUser%myPassword //10.10.10.10 "SELECT * FROM Win32_OperatingSystem"
in the docker container I get:When I launch the same
greenbone@vmgreenbone:~$ /usr/local/bin/wmic -d 7 -U DOMAIN/myScanUser%myPassword //10.10.10.10 "SELECT * FROM Win32_OperatingSystem"
on a VM with openvas built from source I get:The difference is:
Docker:
vs.
Native:
To me it seems that wmic can’t connect to outside of the container but I don’t know the root cause. But I think this is a bug …