Fix File Read Operations

[zeroSteiner]

Since commit 6cca27c, the open file operations no longer remove the \ prefix on file paths. This broke file read operations as used by Metasploit. This resulted in execution failures when Metasploit's psexec module was used with the Command target which needs to read the file output. This readds the logic to remove the unnecessary prefix when opening files. This change has been tested using the newly updated read_file example on SMB versions 1, 2, 3 with and without a path with a \ prefix.

• [ ] Use the example read_file to read a file path containing a leading \
• [ ] See the example script work
• [ ] Try it again with different SMB versions
  • Enable SMB 1 by following these instructions: https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3

Demo

This example shows reading a file from the temp directory that was created using psexec. SMB3 is used, but can be disabled using the CLI options on the example. Note that the file path contains a \ prefix.

ruby read_file.rb --username smcintyre --password Password1 192.168.159.96 C$ "\\Windows\\Temp\\uDDauZxRI.txt"
SMB3 : (0x00000000) STATUS_WAIT_0: The caller specified WaitAny for WaitType and one of the dispatcher objects in the Object array has been set to the signaled state.
Connected to \\192.168.159.96\C$ successfully!

User accounts for \\

-------------------------------------------------------------------------------
$431000-ERJAFULIQUSS     Administrator            aliddle                  
Guest                    HealthMailbox0896988     HealthMailbox23c9938     
HealthMailbox256d6c9     HealthMailbox3dd648f     HealthMailbox3ef3d8d     
HealthMailbox8710d04     HealthMailbox8c45655     HealthMailboxa04271a     
HealthMailboxcad83a9     HealthMailboxde93ebe     HealthMailboxf4602f9     
jdoe                     krbtgt                   SM_2e9af84fe4c6473ea     
SM_3879f1f6de9b49818     SM_3c6a2d0a4c8648c9b     SM_5784a59a716948118     
SM_97642fc203314e6f8     SM_9db3f69793764fde9     SM_ac24b3f263bb427f9     
SM_c2d9a2c8d3844cd29     SM_f5faf24b3b1c46efa     smcintyre                
The command completed with one or more errors.

PSexec bug output

Using the "Command" target. ``` [*] 192.168.159.96:445 - Connecting to the server... [*] 192.168.159.96:445 - Authenticating to 192.168.159.96:445 as user 'smcintyre'... [+] 192.168.159.96:445 - Service start timed out, OK if running a command or non-service executable... [-] 192.168.159.96:445 - Unable to get handle: The server responded with an unexpected status code: STATUS_INVALID_PARAMETER [-] 192.168.159.96:445 - Command seems to still be executing. Try increasing RETRY and DELAY [*] 192.168.159.96:445 - Getting the command output... [-] 192.168.159.96:445 - Unable to read file \Windows\Temp\uDDauZxRI.txt. RubySMB::Error::UnexpectedStatusCode: The server responded with an unexpected status code: STATUS_INVALID_PARAMETER. [-] 192.168.159.96:445 - Error getting command output [*] 192.168.159.96:445 - Executing cleanup... [-] 192.168.159.96:445 - Unable to cleanup \Windows\Temp\HvXgAIlbtIRw.bat. Error: The server responded with an unexpected status code: STATUS_INVALID_PARAMETER [+] 192.168.159.96:445 - Cleanup was successful [*] Exploit completed, but no session was created. ```

[cdelafuente-r7]

I tested against multiple SMB servers and found out Samba v3.5.4 and 3.6.6 returned STATUS_OBJECT_NAME_NOT_FOUND when opening a named pipe with SMBv1. Everything else works perfectly while opening files and pipes with SMBv1/2/3.

• List of server I tested (SMB1/2/3 with read_file.rb and net_share_enum_all.rb, with and without leading backslash): Windows Server 2016, Samba v3.5.4, 3.6.6, 4.1.11 and 4.3.11. (Note that Samba v3.5.x versions do not support SMBv3 and v3.5.4 has a known issue with SMBv2 (see https://github.com/rapid7/ruby_smb/issues/161#issuecomment-678332816 - Share Type issue))

• Issue with Samba v3.5.4 and 3.6.6:

  ❯ ruby examples/net_share_enum_all.rb 127.0.0.1 smbuser 123456 1
  SMB1 : (0x00000000) STATUS_SUCCESS: The operation completed successfully.
  failed to enum shares: The server responded with an unexpected status code: STATUS_OBJECT_NAME_NOT_FOUND, ["/Users/cdelafuente/dev/src/ruby_smb/lib/ruby_smb/smb1/tree.rb:152:in `open_file'", "/Users/cdelafuente/dev/src/ruby_smb/lib/ruby_smb/smb1/tree.rb:63:in `open_pipe'", "/Users/cdelafuente/dev/src/ruby_smb/lib/ruby_smb/client.rb:579:in `net_share_enum_all'", "examples/net_share_enum_all.rb:28:in `<main>'"]

It looks like the issue that the https://github.com/rapid7/ruby_smb/commit/6cca27ce3f00d7ea9b5225c2f8143776a80ed45f commit fixed came back. Maybe a keyword argument could be added to SMBv1 open_file that indicates if the leading backslash should be removed? Since open_pipe calls open_file, this flag could be set only for named pipes.

[zeroSteiner]

Oh yeah I see the issue you're referring to. What if instead of adding a new keyword argument though, I moved the bulk of the logic from open_file into a new function that both open_pipe and open_file called? Then open_(file|pipe) could update the filename parameter as appropriate before dispatching to the new function that would contain almost all the code currently in open_file that just wouldn't modify the filename parameter? Maybe a private _open method?

[cdelafuente-r7]

Sounds perfect to me! go for it, please! Also, would it be possible to do it for both SMBv1 and SMBv2? I know there is no issue with SMBv2 and backslashes, but just for consistency.

[cdelafuente-r7]

Thanks for updating this! I retested and everything is working as expected now. Specs will be added in a separate PR, as we discussed offline. I'll go ahead and land it.