" available: No IPv4 address for " 192.168.10.5

[theiamdude]

Hi,

I using testssl.sh for the first time and I am struggling to get to work in batch mode. I just need to run a simple test through a list of server and output it in a JSON file.

a single line command works for me with no issues:

testssl.sh --json 192.168.10.5

Now I have created a file containing all my target IPs (hosts.txt)

192.168.10.5
192.168.10.6
<EOF>

I then execute the following command:

testssl.sh --json --file hosts.txt

It fails with the following out:

root@333efa5a4929:/opt# testssl.sh --json --file hosts.txt

###########################################################
    testssl.sh       2.8rc3 from https://testssl.sh/dev/
    (1.562 2016/11/05 13:55:29)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on 333efa5a4929:/usr/local/bin/testssl/bin/openssl.Linux.x86_64
 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")

====== Running in file batch mode with file="hosts.txt" ======

======================================================================================================================
/usr/local/bin/testssl/testssl.sh --json  --warnings=batch -q --append 192.168.10.5

-20170208-0718.json: Protocol errorline 476: 192.168.10.5
" available: No IPv4 address for "192.168.10.5

======================================================================================================================
/usr/local/bin/testssl/testssl.sh --json  --warnings=batch -q --append 192.168.10.6

-20170208-0718.json: Protocol errorline 476: 192.168.10.6
" available: No IPv4 address for "192.168.10.6

I then try to run the individual command in the output

/usr/local/bin/testssl/testssl.sh --json  --warnings=batch -q --append 192.168.10.5

And works fine as well.

Is there anything I am missing?

Thanks in advance for your help.

PS: I am using docker image for my testing (mvance/testssl)

[drwetter]

works for me (2.8rc3, 1.565). Can you pull the latest 2.8 and check?

[theiamdude]

Is that same as the master branch?

[theiamdude]

I have download the sh file from master branch and the issue seems to persist.

root@931eac20860c:/opt# testssl.sh --version

No mapping file found

###########################################################
    testssl.sh       2.8rc3 from https://testssl.sh/dev/
    (1.565 2016/12/20 13:26:11)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2g  1 Mar 2016" [~125 ciphers]
 on 931eac20860c:/usr/bin/openssl
 (built: "reproducible build, date unspecified", platform: "linux-x86_64")

[bknowles]

I have found that this program is sensitive to being executed from the source directory where it exists (so that it can find all the other files that come with the program), or being explicitly told where the INSTALLDIR is, so that it can find these things.

If I create a symbolic link from ~/bin/testssl.sh to ~/src/testssl.sh/testssl.sh and then try to execute the script from my bin, the program fails. Among other things, it will find the wrong openssl binary and complain about that, but that's not the only problem.

If I execute the script that is found directly in ~/src/testssl.sh/testssl.sh, then that will work because the script will parse the path to itself and find the other files it needs in that same directory structure.

Compare this failure:

$ testssl.sh --json --file ~/src/testssl.sh/hosts.txt 

No engine or GOST support via engine with your /usr/bin/openssl

###########################################################
    testssl.sh       2.9dev from https://testssl.sh/dev/
    ()

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 0.9.8zg 14 July 2015" [~38 ciphers]
 on frobgaiju:/usr/bin/openssl
 (built: "16 2015", platform: "darwin64-x86_64-llvm")

 Your "/usr/bin/openssl" is way too old (<version 1.0) !
 Please use binary provided in $INSTALLDIR/bin/ or from ports/brew or compile from github.com/PeterMosmans/openssl

To this:

$ src/testssl.sh/testssl.sh --json --file src/testssl.sh/hosts.txt 

###########################################################
    testssl.sh       2.9dev from https://testssl.sh/dev/
    ()

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on frobgaiju:src/testssl.sh/bin/openssl.Darwin.x86_64
 (built: "Sep  7 19:34:54 2016", platform: "darwin64-x86_64-cc")

====== Running in file batch mode with file="src/testssl.sh/hosts.txt" ======

==================================================================
src/testssl.sh/testssl.sh --json  --warnings=batch -q --append 192.168.10.5

src/testssl.sh/testssl.sh: connect: Operation timed out
src/testssl.sh/testssl.sh: line 7164: /dev/tcp/192.168.10.5/443: Operation timed out

Unable to open a socket to 192.168.10.5:443. Fatal error: Can't connect to "192.168.10.5:443"
Make sure a firewall is not between you and your scanning target!

==================================================================
src/testssl.sh/testssl.sh --json  --warnings=batch -q --append 192.168.10.6

src/testssl.sh/testssl.sh: connect: Operation timed out
src/testssl.sh/testssl.sh: line 7164: /dev/tcp/192.168.10.6/443: Operation timed out

Unable to open a socket to 192.168.10.6:443. Fatal error: Can't connect to "192.168.10.6:443"
Make sure a firewall is not between you and your scanning target!

[drwetter]

Am 02/10/2017 um 03:12 AM schrieb theiamdude:

I have download the sh file from master branch and the issue seems to persist.

root@931eac20860c:/opt# testssl.sh --version

No mapping file found

That seems to be a different issue. This likely only happens when it is not correctly installed and cannot find the source dir.

We need more input here or you need to ask the project where your container comes from.

Thx, Dirk

[drwetter]

Am 02/10/2017 um 04:59 AM schrieb Brad Knowles:

I have found that this program is sensitive to being executed from the source directory where it exists (so that it can find all the other files that come with the program), or being explicitly told where the INSTALLDIR is, so that it can find these things.

I wouldn't say senstive. It tries hard to find the dir where it has been installed as it needs files within $INSTALLDIR/ and maybe $INSTALLDIR/bin.

If I create a symbolic link from |~/bin/testssl.sh| to |~/src/testssl.sh/testssl.sh| and then try to execute the script from my bin, the program fails. Among other things, it will find the wrong |openssl| binary and complain about that, but that's not the only problem.

Dealing with links has been improved in 2.9ev. From the 2.8 perspective of testssl you tricked testssl.sh to believe that it is being installed someplace else and outsmarted the internal logic.

Standard case is you run testssl.sh from its git dir or make otherwise sure that it find its files. If you do it differently that's cool but then you're on your own.

HTH, Dirk

[theiamdude]

Thank you both for your reply. The only reason I am using the container is the performance issues I am facing with cygwin. But I will try to setup the proposed version on a vanilla container and let you know how it goes.

[drwetter]

any results?

[rdebath]

The original problem (no IPv4) is caused by Control-M characters in the file with the list of IP addresses, they need to be removed. For example edit the file with VIM, turn off textmode (set notextmode) and save it.

Another possible issue is that just found that the MingW environment has two copies of OpenSSL, one compiled as Windows the other complied as Unix. If the Windows variant is run it uses Windows DLLs to do some of the work. BUT it doesn't have access to all the Unix emulation; for example path name in the arguments get mangled and Bash process substitution won't work. And, invoking a Windows executable from bash is a lot slower.

ie: this sometimes works depending on which executable you use: $ openssl enc -a -in <(echo ok)

This seems to work to find the "unix" version:

test_for_windows() {
    # MINGW has two copies of openssl, one compiled for Windows and one
    # compiled for Unix. The Windows version cannot be used with process
    # substitution ( the <(...) stuff ). Check to see if the default is
    # working, if not try to find the other one.
    local pgm

    if [ "$(openssl enc -a -in <(echo ok) 2>/dev/null )" != b2sK ]
    then
        for pgm in $(which -a openssl)
        do
            eval "openssl() { command '$pgm' \"\$@\"; }"

            if [ "$(openssl enc -a -in <(echo ok) 2>/dev/null )" = b2sK ]
            then break
            fi
        done
    fi
}

[drwetter]

The original problem (no IPv4) is caused by Control-M characters in the file with the list of IP addresses, they need to be removed. For example edit the file with VIM, turn off textmode (set notextmode) and save it.

Ok, regarding this I added for now a hint in the documentation/man page I am working on (#130), to be published soon.

Another possible issue is that just found that the MingW environment has two copies of OpenSSL, one compiled as Windows the other complied as Unix. [..] If the Windows variant is run it uses Windows DLLs to do some of the work. BUT it doesn't have access to all the Unix emulation; for example path name in the arguments get mangled and Bash process substitution won't work.

Here I need some help to understand: The incarnations of Linux emulations under Windows IIRC do not have native Linux binaries, maybe with the exception of WSL.

Q: Does the "windows binary" really come from MinGW? Just asking because I was wondering about the use if it doesn't understand Unix specific arguments.

Cheers, Dirk

[rdebath]

Yes, WSL does the system call emulation trick that's been around since iBCS2 and before. Even on Windows coLinux used it on 32bit windows to provide the system call interface of a real "user mode linux kernel" to processes. I'm not referring to this, because usually the emulation is so close that there's no need to make any serious distinctions from a real Unix.

Currently, I'm usually using the small Unix/Linux environment that you get when you download GIT for Windows this appears to be a subset of the full MinGW/msys2 environment. But even this has multiple copies of some commands, for example openssl and curl.

All the commands are real Windows binaries in that they're PE executables that use DLLs. That's where the difference is, I've shown below the output from the ldd against both of the executables.

The Windows like one uses the USER32.DLL, GDI32.DLL and the rest that form the normal interface to the Windows OS layer.

The Unix like one uses the msys DLL to provide it's interfaces to the OS, it uses only the KERNEL and NT DLLs that are rarely used directly by Windows programs.

The bypassing of much of the Windows system means that the Unix like executables have a library level environment that is very unix like but it also bypasses the majority of "extra features" that are added in the Windows layer. The Windows like executable have access to a lot more of the Windows extras (like the Windows certificate store for SSL connections) but the interface between Unix and Windows executables is a lot rougher. For example, the bash "process substitution" feature uses /dev/fd/* to pass pipes to the process that it runs; there is no way of passing such a weird "file" through the Windows executable without completely subverting the system ... like msys does.

So you get the choice ... Unix or Windows?

$ ldd /usr/bin/openssl
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x772b0000)
        kernel32.dll => /c/Windows/system32/kernel32.dll (0x77190000)
        KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefcfc0000)
        msys-crypto-1.0.0.dll => /usr/bin/msys-crypto-1.0.0.dll (0x561730000)
        msys-2.0.dll => /usr/bin/msys-2.0.dll (0x180040000)
        msys-z.dll => /usr/bin/msys-z.dll (0x522fe0000)
        msys-ssl-1.0.0.dll => /usr/bin/msys-ssl-1.0.0.dll (0x4ba5c0000)

$ ldd /mingw64/bin/openssl
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x772b0000)
        kernel32.dll => /c/Windows/system32/kernel32.dll (0x77190000)
        KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefcfc0000)
        tsappcmp.dll => /c/Windows/system32/tsappcmp.dll (0x7fef76e0000)
        msvcrt.dll => /c/Windows/system32/msvcrt.dll (0x7fefd980000)
        USER32.dll => /c/Windows/system32/USER32.dll (0x77090000)
        GDI32.dll => /c/Windows/system32/GDI32.dll (0x7feff2d0000)
        LPK.dll => /c/Windows/system32/LPK.dll (0x7fefef00000)
        USP10.dll => /c/Windows/system32/USP10.dll (0x7feff200000)
        ADVAPI32.dll => /c/Windows/system32/ADVAPI32.dll (0x7fefed20000)
        sechost.dll => /c/Windows/SYSTEM32/sechost.dll (0x7fefef10000)
        RPCRT4.dll => /c/Windows/system32/RPCRT4.dll (0x7feff3c0000)
        ole32.dll => /c/Windows/system32/ole32.dll (0x7fefda20000)
        IMM32.DLL => /c/Windows/system32/IMM32.DLL (0x7feff4f0000)
        MSCTF.dll => /c/Windows/system32/MSCTF.dll (0x7fefdca0000)
        LIBEAY32.dll => /mingw64/bin/LIBEAY32.dll (0x63080000)
        WS2_32.dll => /c/Windows/system32/WS2_32.dll (0x7fefecd0000)
        NSI.dll => /c/Windows/system32/NSI.dll (0x7fefd970000)
        SSLEAY32.dll => /mingw64/bin/SSLEAY32.dll (0x6e400000)