Support xrdp hosts

[tcpiplab]

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:

$ cat /etc/hosts
192.168.0.1     router
192.168.0.16    victim
192.168.0.33    attacker
██.██.██.205   rdp-server

Attacker Output

$ sudo SETH_DEBUG=1 ./seth.sh eth0 192.168.0.33 192.168.0.16 192.168.0.1
...
[*] 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 ██.██.██.205
[*] Clone the x509 certificate of the original destination...
unable to load certificate
140347480601664:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
[!] Failed to clone certificate, create bogus self-signed certificate...
[*] Adjust the iptables rule for all packets...
[*] Run RDP proxy...
Listening for new connection

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.

$ openssl x509 -inform DER -in ../Pentests/███████████████.com/Files/rdpcert.der -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b0:1f:99:b5:7e:8f:05:cd
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = XRDP
        Validity
            Not Before: Feb  1 00:37:16 2019 GMT
            Not After : Jan 31 00:37:16 2029 GMT
        Subject: CN = XRDP
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:d2:50:65:e0:bb:87:1e:a6:ab:66:c3:bb:52:03:
                    f5:f8:78:a4:4c:f8:03:7c:7d:90:c9:6a:e8:11:5f:
                    93:96:f1:7b:33:11:36:e1:f5:1c:b3:0c:02:59:34:
                    4a:70:2a:49:39:11:90:1e:7c:f9:fb:7e:ea:1b:5e:
                    40:03:da:c3:9f:9d:5e:63:8c:79:f9:b5:e5:4e:85:
                    7d:7d:4b:b2:ce:9d:ab:bc:92:f5:61:4a:0a:09:d7:
                    47:2a:12:8d:e4:16:3e:96:bb:51:e3:59:c0:db:88:
                    ad:f3:dd:20:f2:a3:94:52:93:97:19:ec:91:06:85:
                    7c:d9:eb:12:ee:01:19:c2:57:b9:44:e1:26:4d:02:
                    0f:f0:2f:21:2f:05:43:01:f1:8e:6c:4f:54:20:9d:
                    cf:7f:85:7d:55:43:4d:a6:36:aa:5f:2c:6a:0a:77:
                    08:da:2b:be:96:6a:54:8d:03:94:7a:10:f2:87:2c:
                    35:8c:36:c2:df:7f:4e:55:f6:31:21:7d:4f:c8:dc:
                    d0:dc:22:10:41:f2:32:23:6e:b9:95:4b:8f:59:d1:
                    ca:64:4f:76:15:c5:69:52:73:a8:90:64:36:f8:d1:
                    44:f5:54:7b:de:66:68:68:a2:98:0a:3e:40:63:90:
                    95:48:b3:b8:b3:31:9a:2d:ec:35:81:61:57:a2:d7:
                    f0:45
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                5D:AC:95:A3:4B:6C:67:2C:E1:77:8C:C6:42:E3:7E:A7:65:42:8D:82
            X509v3 Authority Key Identifier: 
                keyid:5D:AC:95:A3:4B:6C:67:2C:E1:77:8C:C6:42:E3:7E:A7:65:42:8D:82

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         a8:f7:47:ff:cc:e3:db:f2:fa:a1:d3:58:e1:9b:88:cb:e7:f0:
         13:b8:78:dc:a9:62:1f:c7:a7:ad:c7:c4:86:ed:cd:49:7a:0b:
         27:c7:c2:4a:11:d2:27:a5:4c:0c:17:20:38:72:6f:9f:fa:10:
         ea:ab:50:8a:2b:8c:a8:d9:fa:d9:a0:4f:fe:3f:8d:40:cc:a7:
         20:2a:fd:2e:61:58:b0:f0:71:c5:0e:a5:74:2f:5f:20:7e:8c:
         16:5b:5b:1f:10:7e:90:22:0a:5f:8a:65:74:1c:1c:aa:1e:e1:
         2d:37:7f:80:a1:de:b2:db:57:de:e2:d2:cf:06:2e:1c:1c:77:
         a7:1b:6c:da:dc:0e:58:fe:94:a1:4f:d4:02:48:64:7d:f8:b7:
         e1:a8:5a:38:c1:e9:c2:80:8b:36:c7:25:0a:06:57:3a:35:fb:
         0d:a6:20:5f:7a:c0:2c:af:ad:52:c4:e0:8b:40:11:dd:7d:94:
         fc:23:51:5d:89:ee:59:c4:85:e3:7c:64:3e:32:64:02:37:ac:
         31:44:31:e3:e6:33:a7:78:27:60:59:98:b5:e4:36:16:dd:b5:
         1f:e9:17:ae:06:ec:dc:5b:52:41:8d:df:88:32:0c:59:cc:74:
         b4:61:8a:77:16:1e:af:b4:74:89:27:90:12:fa:8b:6f:c6:a7:
         15:6d:72:9d
-----BEGIN CERTIFICATE-----
MIIC8TCCAdmgAwIBAgIJALAfmbV+jwXNMA0GCSqGSIb3DQEBCwUAMA8xDTALBgNV
BAMMBFhSRFAwHhcNMTkwMjAxMDAzNzE2WhcNMjkwMTMxMDAzNzE2WjAPMQ0wCwYD
VQQDDARYUkRQMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0lBl4LuH
HqarZsO7UgP1+HikTPgDfH2QyWroEV+TlvF7MxE24fUcswwCWTRKcCpJORGQHnz5
+37qG15AA9rDn51eY4x5+bXlToV9fUuyzp2rvJL1YUoKCddHKhKN5BY+lrtR41nA
24it890g8qOUUpOXGeyRBoV82esS7gEZwle5ROEmTQIP8C8hLwVDAfGObE9UIJ3P
f4V9VUNNpjaqXyxqCncI2iu+lmpUjQOUehDyhyw1jDbC339OVfYxIX1PyNzQ3CIQ
QfIyI265lUuPWdHKZE92FcVpUnOokGQ2+NFE9VR73mZoaKKYCj5AY5CVSLO4szGa
Lew1gWFXotfwRQIDAQABo1AwTjAdBgNVHQ4EFgQUXayVo0tsZyzhd4zGQuN+p2VC
jYIwHwYDVR0jBBgwFoAUXayVo0tsZyzhd4zGQuN+p2VCjYIwDAYDVR0TBAUwAwEB
/zANBgkqhkiG9w0BAQsFAAOCAQEAqPdH/8zj2/L6odNY4ZuIy+fwE7h43KliH8en
rcfEhu3NSXoLJ8fCShHSJ6VMDBcgOHJvn/oQ6qtQiiuMqNn62aBP/j+NQMynICr9
LmFYsPBxxQ6ldC9fIH6MFltbHxB+kCIKX4pldBwcqh7hLTd/gKHesttX3uLSzwYu
HBx3pxts2twOWP6UoU/UAkhkffi34ahaOMHpwoCLNsclCgZXOjX7DaYgX3rALK+t
UsTgi0AR3X2U/CNRXYnuWcSF43xkPjJkAjesMUQx4+Yzp3gnYFmYteQ2Ft21H+kX
rgbs3FtSQY3fiDIMWcx0tGGKdxYer7R0iSeQEvqLb8anFW1ynQ==
-----END CERTIFICATE-----

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:

openssl s_client -servername "$SERVER" \
    -connect "$HOST" < /dev/null 2>&1 | \
    openssl x509 -outform PEM -out "$ORIG_CERT_FILE"

And I assume that the error is the reason for seth.sh to choose the OR option at line 123, thereby creating a self-signed cert.

CERT_KEY="$($SCRIPT_DIR/clone-cert.sh "$ORIGINAL_DEST:3389" || \ 
    create_self_signed_cert "$ORIGINAL_DEST")"

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:

$ openssl s_client -connect ██.██.██.205:3389 < /dev/null
CONNECTED(00000003)
139739288069184:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

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 and krdc. The latter is one of the many clients that is built on top of xfreerdp. 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!

[AdrianVollmer]

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.