Show error when getting timeout during share enumeration

[exploide]

Under bad network conditions, or when the server is too slow, it may happen that smbclient runs into a timeout. Currently, this leads to the message "Could not parse result of smbclient command, please open a GitHub issue".

This PR changes this to return a proper error message: "Could not check share: STATUS_IO_TIMEOUT".

This is what I see when running smbclient manually:

$ smbclient -W domain -U user%pass -s /tmp/tmp6opu33mz -t 5 -c dir //10.10.11.236/NETLOGON
do_connect: Connection to 10.10.11.236 failed (Error NT_STATUS_IO_TIMEOUT)

Note that a comparison similar to the others (if "NT_STATUS_IO_TIMEOUT" in result.retmsg) did not work, because for some reason, result.retmsg is just "timed out" instead of the NT_ code. So I check for string equality here.

[cddmp]

Thanks for another pull request! I think what happens is this:

With the -t parameter you can specify a timeout. The default is 5 seconds. Because of the slow connection you have, the smbclient command does not return before a TimeoutExpired exception is thrown (the smbclient process is then actually killed). So you end up here in the code:
https://github.com/cddmp/enum4linux-ng/blob/master/enum4linux-ng.py#L650-L651.

Because of that "timed out" is then passed to the point where you process it.

Can you add the following code to line 2451:

if not result.retval:
    return Result(None, f"Could not check share:  {result.retmsg}")

And change line 2477 from

if result.retmsg == "timed out":

to

if "NT_STATUS_IO_TIMEOUT" in result.retmsg:

I think that should handle things correctly.

Could you then test those changes for me, with the following "test cases"?

1. Run the tool with "-t 2" it should print out:
   Could not check share: timed out

2. Run it with a very large timeout, like "-t 599" it should print
   Could not check share: NT_STATUS_IO_TIMEOUT.

(This only works if you still have the slow network connection.)

I think I will unify the two error messages at some point.

I will then happily merge this!

[exploide]

Thanks for the fast review. I incorporated the proposed changes and checked that your two test cases work as expected.

(The "bad network conditions" were actually a HackTheBox machine responding too slow. This was better today, so I needed to simulate the second test case by interrupting my network connection. Maybe the guy who threw rockyou.txt against the SMB service yesterday finally gave up 🙈 )

[cddmp]

Thanks for the fast review. I incorporated the proposed changes and checked that your two test cases work as expected.
(The "bad network conditions" were actually a HackTheBox machine responding too slow. This was better today, so I needed to simulate the second test case by interrupting my network connection. Maybe the guy who threw rockyou.txt against the SMB service yesterday finally gave up 🙈 )

A classic one :D. Thanks you for the effort!