ntlmrelayx: SMB to MSSQL just got stuck

[CaledoniaProject]

I have a Linux box (192.168.154.200) and a Windows 2008 R2 + MSSQL 2008 Developer Edition (192.168.154.131)

On the Linux box I started responder and ntlmrelayx like this,

# ./ntlmrelayx.py -socks -t mssql://192.168.154.131 -debug

First verify the mssql port is reachable from the Linux box (Windows firewall completely disabled):

# nc 192.168.154.131 1433 -vv
Connection to 192.168.154.131 1433 port [tcp/ms-sql-s] succeeded!

Get back to the Windows VM and trigger the attack by opening any fake share, e.g \\123123123.

Now in the Linux box I got this:

ntlmrelayx> socks
[*] No Relays Available!
ntlmrelayx> [+] KeepAlive Timer reached. Updating connections
[*] SMBD: Received connection from 192.168.154.131, attacking target mssql://192.168.154.131
[+] Encryption required, switching to TLS
[+] KeepAlive Timer reached. Updating connections
[+] KeepAlive Timer reached. Updating connections
[*] SMBD: Received connection from 192.168.154.131, attacking target mssql://192.168.154.131
[+] Encryption required, switching to TLS

And ntlmrelayx stuck after the "Switching to TLS" .. how should I debug this?

[asolino]

Cannot reproduce in my test env.

Did you try connecting directly using mssqlclient.py to verify the target MSSQL is working?

If you can, then sniffing the traffic on port 1433 could help. Then we will probably need to add some extra debugging info inside the MSSQL Relay Client.

[CaledoniaProject]

mssqlclient.py won't work either.

# ./mssqlclient.py 172.16.177.131 -debug
Impacket v0.9.19-dev - Copyright 2018 SecureAuth Corporation

[*] Encryption required, switching to TLS

Rename this 2.txt to 2.pcap to view the packet.

[asolino]

Ok, so it's not a ntlmrelayx.py issue for something focused on tds.py

Did you try connecting against the target MSSQL database with another tool? Just want to be sure the server is working as expected.

If so, looks like mssqclient.py got stuck in tds.py login method. If you can debug that part of the connection (using a Python debugger or printing debug messages as lines are processed) that could help identifying the issue (if there's any).

[CaledoniaProject]

Navicat works. Added some debug output and tds.py got timed-out at tls.do_handshake(), not sure why.

And finally

[*] Encryption required, switching to TLS
handshake
handshake
handshake
[-] [Errno 104] Connection reset by peer

[CaledoniaProject]

Tested again, It works against MSSQL 2016 (no-domain joined)

[asolino]

Thanks @CaledoniaProject

Is Navicat doing encryption or just plain SQL?

Good to know it works against that 2016 box

[CaledoniaProject]

Yes, it has a TLS exchange as well.

[asolino]

I've received some reports in the past around TLS issues with mssqlclient.py. Haven't found a way to reproduce it. I think this is related with OpenSSL handshake but couldn't dig deeper. Anyone experiencing similar issues help would be appreciated.

[daikerSec]

The same to me.version is Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) .Navicat works. I try to relay. But it didn't word. So I try mssqlclient.py.It shows that

➜  examples git:(master) ✗ python mssqlclient.py sa:admin@172.16.66.128  -debug
Impacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation

[*] Encryption required, switching to TLS

[+] Exception:
Traceback (most recent call last):
  File "mssqlclient.py", line 177, in <module>
    res = ms_sql.login(options.db, username, password, domain, options.hashes, options.windows_auth)
  File "build/bdist.macosx-10.15-x86_64/egg/impacket/tds.py", line 966, in login
    tds = self.recvTDS()
  File "build/bdist.macosx-10.15-x86_64/egg/impacket/tds.py", line 607, in recvTDS
    packet = TDSPacket(self.socketRecv(packetSize))
  File "build/bdist.macosx-10.15-x86_64/egg/impacket/tds.py", line 587, in socketRecv
    data = self.socket.recv(packetSize)
error: [Errno 54] Connection reset by peer
[-] [Errno 54] Connection reset by peer

[daikerSec]

I try to debug it.I found that my mssql server doesn't ask me to Encryption. But in code ,It says that According to the specs, if encryption is not required, we must encrypt just.so I debug it ,when called to recvTDS(),packetSize is 32763, but in packet = TDSPacket(self.socketRecv(packetSize)). It can't pass . block here.

here is the packet tds_debug.txt change the filetype Rename tds_debug.txt to tds_debug.pcapng to view the packet.

[daikerSec]

It block in this recvTDS called, after self.sendTDS(TDS_LOGIN7, login.getData())

        login['Length'] = len(login.getData())

        # Send the NTLMSSP Negotiate or SQL Auth Packet
        print("try to TDS_LOGIN7 before")
        self.sendTDS(TDS_LOGIN7, login.getData())
        print("try to TDS_LOGIN7 after")

        # According to the specs, if encryption is not required, we must encrypt just 
        # the first Login packet :-o 
        # if resp['Encryption'] == TDS_ENCRYPT_OFF:
        #     self.tlsSocket = None
        print("try to recvTDS before")
        tds = self.recvTDS()
        print("try to recvTDS after")

        if useWindowsAuth is True:
            serverChallenge = tds['Data'][3:]

[asolino]

Did you manage to solve this or is this still an issue?

[7MinSec]

Hello @daikerSec thank you for posting this issue as I'm running into it exactly on a pentest. Did you ever get past the Encryption required, switching to TLS hang that happens when the ntlmrelay fires against a SQL victim target?

[Ringx3]

same issue...

[Ringx3]

It works. https://github.com/fortra/impacket/issues/827#issuecomment-652966362