Open tcpiplab opened 5 years ago
Hi, thanks for the very detailed bug report. I wish it was this detailed every time ;)
So first of all, I never tested Seth with a non-Windows host, so we are on uncharted territory here. Next, if clone-cert.sh
fails, it's not a big deal. The attack should still work, but the victim might be more reluctant to ignore the warning because the certificate will look like an obvious fake.
In this case, it fails because openssl is not printing the certificate. It actually looks like your RDP host is not using SSL at all, which is possible if the host is using the 'plain rdp' security setting. During the development I made sure Seth can handle plain RDP as well, but I've never tried it in the wild, so it might not always work after all.
OR, since you see a certificate in wireshark, it is just behaving a bit differently. Windows RDP hosts can do both: they can perform the SSL handshake immediately if the client requests it, or they can perform it a bit later in the connection after some clear text data has been transmitted. Maybe your RDP host only can do the latter, in which case openssl would never see the certificate because it performs the handshake right away. However, in that case I would expect Seth to work except for the certificate spoofing.
I'd have to test this myself when I can find some time.
I'm using Seth for a pentest I'm doing and I'm getting an error similar to what was reported in #1. But I wonder if the RDP server (xrdp running on CentOS) is causing the problem. In my case there is no MS Windows; every host is running Linux:
Attacker Output
The Original XRDP Certificate
I used Wireshark to extract the raw bytes of the certificate that is being served by the RDP server. It looks OK to me. But it is causing the above error.
Where the error comes from
I assume that the certificate is causing
clone-cert.sh
to error out after the received certificate is piped to line 60:And I assume that the error is the reason for
seth.sh
to choose theOR
option at line 123, thereby creating a self-signed cert.Output you might ask for
Unfortunately I can't trace the problem beyond those two lines. Below is the output of the command you asked for in issue #1. Mine seems rather different than what the OP received from his server:
One problem or two?
In addition to the error described above, my 'victim' RDP client is not able to connect to the RDP server. On the victim host I've tried using
rdesktop
andkrdc
. The latter is one of the many clients that is built on top ofxfreerdp
. I would expect the latter to validate the (forged) certificate, as you mentioned in your excellent paper. But neither RDP client is able to establish a connection to the RDP server.By the way, thank you for this very cool and useful tool!