search

SySS-Research / Seth

Perform a MitM attack and extract clear text credentials from RDP connections
MIT License
1.38k stars 325 forks source link

The Connection Has Been Terminated Because An Unexpected Server Authentication Certificate Was Received From The Remote Computer #20

Open sritify opened 6 years ago

sritify commented 6 years ago

I have tired running the tool recently in an AD environment. ARP spoofing was successful and routed the traffic to my Kali Linux VM. However, after the victim tried to enter the credential, the RDP then returned error message " The Connection Has Been Terminated Because An Unexpected Server Authentication Certificate Was Received From The Remote Computer" and dropped the connection. Any idea to fix this issue?

Here is the output of seth.sh: [] Spoofing arp replies... [] Turning on IP forwarding... [] Set iptables rules for SYN packets... [] Waiting for a SYN packet to the original destination... [+] Got it! Original destination is 10.0.0.87 [] Clone the x509 certificate of the original destination... [] Adjust the iptables rule for all packets... [*] Run RDP proxy... Listening for new connection Connection received from 10.0.0.164:57782 Downgrading authentication options from 11 to 3 Listening for new connection Enable SSL Connection lost

AdrianVollmer commented 6 years ago

Can you please run it with SETH_DEBUG=1 ./seth.sh ... and post the output?

sritify commented 6 years ago

Please have a look, thanks!

[] Spoofing arp replies... [] Turning on IP forwarding... [] Set iptables rules for SYN packets... [] Waiting for a SYN packet to the original destination... [+] Got it! Original destination is 10.0.0.87 [] Clone the x509 certificate of the original destination... [] Adjust the iptables rule for all packets... [*] Run RDP proxy... Warning: The python3 module 'hexdump' is missing. Using hexlify instead. Listening for new connection Connection received from 10.0.0.164:58030 From client: 030000130ee00000000000010008000b000000 Downgrading authentication options from 11 to 3 From client: (modified) 030000130ee000000000000100080003000000 Listening for new connection From server: 030000130ed000001234000209080002000000 Enable SSL From client: 3037a003020105a130302e302ca02a04284e544c4d5353500001000000b78208e2000000000000000000000000000000000601b11d0000000f From server: 30820119a003020105a18201103082010c30820108a0820104048201004e544c4d53535000020000001000100038000000358289e2b331b7424249a4ba0000000000000000b800b800480000000601b11d0000000f560045004e0045005400490041004e0002001000560045004e0045005400490041004e00010014005600490054004400540052004d0037003900320004001e00760065006e0065007400690061006e002e0063006f006d002e006d006f00030034005600490054004400540052004d003700390032002e00760065006e0065007400690061006e002e0063006f006d002e006d006f0005001e00760065006e0065007400690061006e002e0063006f006d002e006d006f0007000800b47e54e5f4f7d30100000000 Connection lost

AdrianVollmer commented 6 years ago

Hmmm everything looks fine. I increased verbosity with the latest commit. You could pull it and try again to see what it says.

Also you may want to redact that last hex string. It contains the host name of your server.

sritify commented 6 years ago

Thanks Adrian. The new version output "Connection lost ([Errno 104] Connection reset by peer)".

Any possibility that the client validate the certificate (although the original is untrusted as well), and find out that the cloned certificate is not valid?

AdrianVollmer commented 6 years ago

No, because the SSL connection is successfully established and data is exchanged after the SSL handshake. For whatever reason the server closes the connection right before authentication. Unfortunately I'm clueless at this point.

You could try running it with SETH_DOWNGRADE=1 ./seth.sh ... or use the fake server mode. To always enable the fake server mode you have to modify seth.sh and replace seth.py with seth.py -f in line 136. However, I haven't tested this. I should implement an easy switch for that.

Anyway, thanks for reporting.

AdrianVollmer commented 6 years ago

Actually, you may have been right. See http://fixmyitsystem.com/2011/08/rdp-rds-unexpected-server.html

I'll have to come up with something

RoseDeSable commented 4 years ago

If I force the SETH_DOWNGRADE=1 or the using of the fake server with "seth.py -f, then a new failure occurs:

Listening for new connection 'NoneType' object has no attribute 'getsockopt' Hiding forged protocol request from client Connection lost on run_fake_server