Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sritify opened this issue May 30, 2018 · 7 comments

Comments

@sritify
Copy link

sritify commented May 30, 2018

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
Copy link
Member

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

@sritify
Copy link
Author

sritify commented May 30, 2018

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
Copy link
Member

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
Copy link
Author

sritify commented May 30, 2018

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
Copy link
Member

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
Copy link
Member

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants