fortra / impacket

Impacket is a collection of Python classes for working with network protocols.
https://www.coresecurity.com
Other
13.29k stars 3.54k forks source link

HMAC TypeError: key: expected bytes or bytearray, but got 'int' #966

Open c0d3z3r0 opened 3 years ago

c0d3z3r0 commented 3 years ago

Configuration

impacket version: current master Python version: 3.8 Target OS: Kali Rolling

Debug Output With Command String

root@kali:/opt/impacket/examples# python3 ntlmrelayx.py -debug -t DCSYNC://dc1.test.intern -smb2support                                                                            
Impacket v0.9.22.dev1+20200924.183326.65cf657f - Copyright 2020 SecureAuth Corporation                                                                                                        

[+] Impacket Library Installation Path: /usr/local/lib/python3.8/dist-packages/impacket                                                                                                       
[*] Protocol Client SMTP loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client IMAPS loaded..
[*] Protocol Client IMAP loaded..
[*] Protocol Client DCSYNC loaded..
[*] Protocol Client RPC loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client SMB loaded..
[+] Protocol Attack DCSYNC loaded..
[+] Protocol Attack RPC loaded..
[+] Protocol Attack HTTP loaded..
[+] Protocol Attack HTTPS loaded..
[+] Protocol Attack SMB loaded..
[+] Protocol Attack IMAP loaded..
[+] Protocol Attack IMAPS loaded..
[+] Protocol Attack LDAP loaded..
[+] Protocol Attack LDAPS loaded..
[+] Protocol Attack MSSQL loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server
[*] Setting up HTTP Server

[*] Servers started, waiting for connections
[*] SMBD-Thread-3: Connection from TEST/DC3$@172.16.0.18 controlled, attacking target dcsync://dc1.test.intern
[+] Connecting to ncacn_ip_tcp:dc1.test.intern[135] to determine TSCH stringbinding
[+] TSCH stringbinding is ncacn_ip_tcp:dc1.test.intern[49668]
[*] Connecting to dc1.test.intern NETLOGON service
[+] Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/impacket/examples/ntlmrelayx/clients/dcsyncclient.py", line 321, in netlogonSessionKey
    av_pairs = AV_PAIRS(av_pairs)
  File "/usr/local/lib/python3.8/dist-packages/impacket/ntlm.py", line 206, in __init__
    self.fromString(data)
  File "/usr/local/lib/python3.8/dist-packages/impacket/ntlm.py", line 229, in fromString
    fType = struct.unpack('<H',tInfo[:struct.calcsize('<H')])[0]
struct.error: unpack requires a buffer of 2 bytes
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/impacket/examples/ntlmrelayx/clients/dcsyncclient.py", line 197, in sendAuth
    newmic = ntlm.hmac_md5(signingkey, self.negotiateMessage + self.challenge.getData() + authenticateMessage.getData())
  File "/usr/local/lib/python3.8/dist-packages/impacket/ntlm.py", line 881, in hmac_md5
    h = hmac.new(key, digestmod=hashlib.md5)
  File "/usr/lib/python3.8/hmac.py", line 153, in new
    return HMAC(key, msg, digestmod)
  File "/usr/lib/python3.8/hmac.py", line 48, in __init__
    raise TypeError("key: expected bytes or bytearray, but got %r" % type(key).__name__)
TypeError: key: expected bytes or bytearray, but got 'int'
[*] SMBD-Thread-4: Connection from TEST/DC3$@172.16.0.18 controlled, but there are no more targets left!

This gets triggered after running the printerbug script from krbrelax:

python3 printerbug.py -no-ping test/client:password@dc3.test.intern 172.16.2.240

PCAP

If applicable, add a packet capture to help explain your problem.

Additional context

Space for additional context, investigative results, suspected issue.

0x4d5a-ctf commented 3 years ago

I ran into this exact issue yesterday and investigated a little further. Note that i have basically no clue about NTLM internals, but thats at least how I think what fails. But maybe it helps to narrow down the issue.

Starting with the actual error: The script reads the server name from the ntlm part of the NTLMAuthChallengeResponse():

authenticateMessage = NTLMAuthChallengeResponse()
[...]
av_pairs = authenticateMessage['ntlm'][44:]
av_pairs = AV_PAIRS(av_pairs)

While the in provided pcap in the original blogpost this field is filled with further NTLM related data (server name, domain etc, which is also provided in the "parent" structure of the packet), in my case this ntlm data is filled with the checksum (?) of 24 bytes only. Hence the index 44 can't be read and crashes the script.

I tried to investigate why the DC i used the printerbug on authenticates to my relay server, but does not provide this additional information, but failed to do so. Maybe the DC is configured in such a way that the printer bug is fixed, e.g. that the DC connects to the relay but does not provide the nessecary additional ntlm data. When i tried to hardcode the server name (which is the only value read from this missing structure), the exploit failed at a later stage.

asolino commented 3 years ago

Hey @c0d3z3r0

A network trace would be appreciated to take a look at the NTLM blob and reproduce this issue.

docsewell commented 1 year ago

I'm having this same issue while doing a HTB lab. I get the same result whether I use dementor.py or printerbug.py. I've tried multiple commits of impacket, and I'm still getting the same issue.

dbissell6 commented 1 year ago

Did you ever get this to work?

md6Anonymous commented 12 months ago

Same problem here. Can we provide additional information so this can get fixed?

kmahyyg commented 1 month ago

Same problem here. After a bit investigation, it actually caused by upper-level code threw a ACCESS_DENIED error code and not being handled correctly, thus being taken as integer in this level of code. But the root cause is still pending for analysis.

This could be stably reproduced in HTB lab while trying to exploit PrinterBug via (Dementor & NTLMRelayX for DCSYNC) on Kali Linux with a valid credential.

update: after a few respawn of lab targets, this program works smoothly, I suspect the problem may caused by incomplete configuration of software or network glitch.

viris commented 1 month ago

Same issue is still present it seems, vulnerability was reported as present both with Metasploit, Nessus, PingCastle and PurpleKnight tools however relaying failed with the error mentioned above.