Disabling 3DES (SUGAR32) on the server disables rdesktop 1.8.3
Dear rdesktop,
I really, really need this fixed as soon as possible. It has knocked out my ability to do remote support of several customer's sites.
To shut off the external PCI (credit card security) SUGAR32 warning on Remote Desktop, requires the following:
Windows 7 Pro;
- Registry:
REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168] "Enabled"=dword:00000000
Note: most easily done with IISCrypto.exe: https://www.nartac.com/Products/IISCrypto/Download
- gpedit.msc
--> Computer Configuration --> Policies --> Administrative Templates --> Windows Components --> Remote Desktop Services --> Remote Desktop Session Host --> Security
Specific security layer for remote (rdp) connections
set to "enabled"
set "Security Layer" to "RDP"
Require secure RCP commications
set to "enabled"
- reboot: shutdown /r /f /t 00
How to test for 3DES (Sugar32): nmap -p xxxx -Pn --script +ssl-enum-ciphers aaa.bbb.ccc.ddd --script ssl-cert
nmap -p xxxx -Pn --script +ssl-enum-ciphers aaa.bbb.ccc.ddd --script ssl-cert
Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-07 00:02 PST Nmap scan report for mail.redacted.com (aaa.bbb.ccc.ddd) Host is up (0.060s latency). PORT STATE SERVICE xxxx/tcp open yyyyy | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: indeterminate | cipher preference error: Too few ciphers supported | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Weak certificate signature: SHA1 | TLSv1.1: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: indeterminate | cipher preference error: Too few ciphers supported | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Weak certificate signature: SHA1 | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: indeterminate | cipher preference error: Too few ciphers supported | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Weak certificate signature: SHA1 |_ least strength: C
Unfortunately, doing the above breaks rdesktop-1.8.3 (but not mstsc.exe): $ rdesktop -g 90%% -a 16 -r clipboard:CLIPBOARD aaa.bbb.ccc.ddd:xxxx
Autoselected keyboard map en-us Failed to negotiate protocol, retrying with plain RDP. ERROR: recv: Connection reset by peer
I'm not able to test this myself for now, could you build rdesktop from source and enable debug logging like:
RDESKTOP_DEBUG=All rdesktop <ip>
then post the log on https://gist.github.com/ and link to it and i'll take a look.
On 02/13/2017 12:16 AM, Henrik Andersson wrote:
I'm not able to test this myself for now, could you build rdesktop from source and enable debug logging like:
|RDESKTOP_DEBUG=All rdesktop
| then post the log on https://gist.github.com/ and link to it and i'll take a look.
Unfortunately, this is not something I am able to do at the present. Is there anyone else out there that can do this for Henrik?
@ToddAndMargo I could provide an rdesktop binary for you to test out, if that is you problem ?
On 02/24/2017 12:09 AM, Henrik Andersson wrote:
@ToddAndMargo https://github.com/ToddAndMargo I could provide an rdesktop binary for you to test out, if that is you problem ?
That would work for me, especially since I have four more computer to de-fang 3DES on this week. I could do a before and after test. Be sure to let me know what diagnostics you want to see.
@ToddAndMargo , I assume that you want an x86_64 binary ?
On 02/27/2017 03:22 AM, Henrik Andersson wrote:
@ToddAndMargo https://github.com/ToddAndMargo , i assume that you want an x86_64 binary ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rdesktop/rdesktop/issues/97#issuecomment-282694424, or mute the thread https://github.com/notifications/unsubscribe-auth/AAzdxVd1Z1PAnYMsCjkGWrRJYB-wxQZIks5rgrHsgaJpZM4L-D8L.
yes
--
Computers are like air conditioners.
They malfunction when you open windows
You can download rdesktop binary file here [1], the sha256 checksum for the file is [2]. When downloaded and verified, run rdesktop with debug logging enabled like:
$ RDESKTOP_DEBUG=Protocol rdesktop <servername>
and send us the console log output for investigation.
[1] http://s000.tinyupload.com/download.php?file_id=53544769066141565462&t=5354476906614156546220542 [2] 6ccf4895260a23ed85a5315fc7f4d3abfcc468ff65fbfe537b420af000976523
On 02/27/2017 11:50 PM, Henrik Andersson wrote:
You can download rdesktop binary file here [1], the sha256 checksum for the file is [2]. When downloaded and verified, run rdesktop with debug logging enabled like:
|$ RDESKTOP_DEBUG=Protocol rdesktop
| and send us the console log output for investigation.
[1] http://s000.tinyupload.com/download.php?file_id=53544769066141565462&t=5354476906614156546220542 [2] 6ccf4895260a23ed85a5315fc7f4d3abfcc468ff65fbfe537b420af000976523
You got it!
I first verified I could log in with xfreerdp.
Names and addresses changed to protect the guilty.
$ RDESKTOP_DEBUG=Proto rdesktop -u "yyyyyyy" -g 92%% -a 16 -r printer:B4350='HP LaserJet IIP' -r printer:Cups-PDF -r disk:MyLocalDrive=/home/temp -r clipboard:CLIPBOARD aaa.bbb.ccc.ddd:xxx
PRINTER PRN1 to B4350 driver HP LaserJet IIP PRINTER PRN2 to Cups-PDF driver MS Publisher Imagesetter share name MyLocalDrive truncated to MyLocal Autoselected keyboard map en-us Failed to negotiate protocol, retrying with plain RDP. ERROR: recv: Connection reset by peer
--
Computers are like air conditioners.
They malfunction when you open windows
@ToddAndMargo Could you do that once again but make sure that RDESKTOP_DEBUG is correct, should be: RDESKTOP_DEBUG=Protocol
On 02/28/2017 12:35 AM, Henrik Andersson wrote:
@ToddAndMargo https://github.com/ToddAndMargo Could you do that once again but make sure that RDESKTOP_DEBUG is correct, should be: |RDESKTOP_DEBUG=Protocol|
Hi Henrik,
I misspelled "Protocol" and forgot to use "./" in front of "rdesktop", so try, try again!
Also, it logged straight into the one remaining 3DES computer. The trace is on one of the 3DES disabled computers.
-T
$ RDESKTOP_DEBUG=Protocol /home/temp/rdesktop -u "xxx" -g 92%% -a 16 -r printer:B4350='HP LaserJet IIP' -r disk:MyLocalDrive=/home/temp -r clipboard:CLIPBOARD aaa.bbb.ccc.ddd:yyy
Keyboard(error): xkeymap_read(), failed to open keymap en-us Connecting to server using NLA... Failed to negotiate protocol, retrying with plain RDP. Protocol(debug): sec_out_mcs_data(), g_num_channels is 4 Protocol(debug): sec_out_mcs_data(), requesting channel cliprdr Protocol(debug): sec_out_mcs_data(), requesting channel rdpsnd Protocol(debug): sec_out_mcs_data(), requesting channel snddbg Protocol(debug): sec_out_mcs_data(), requesting channel rdpdr Core(error): tcp_recv(), recv() failed: Connection reset by peer
Ok, there is two problems. The main problem is that SSL connection to the RDP server can't establish a crypto to use. Therefor the connection is downgraded to plain RDP which in it's turn fails.
The SSL problem seems to be that your RDP servers only supports 3DES ciphers and when you disabled it, no ciphers can be used.
About the disconnect problem, you would probably find information in the event log on the RDP server for hints about the problem.
Here is an output of cipihers from a Windows 2008r2 server which shows a more reasonable result than yours:
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Weak certificate signature: SHA1
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Weak certificate signature: SHA1
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Weak certificate signature: SHA1
As I understand Windows 7 should support more ciphers [1] as you can see below when is queried one of my own Windows 7 RDP servers. Seems like something fishy is going on with your Windows 7 server configuration.
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Weak certificate signature: SHA1
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Weak certificate signature: SHA1
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| Weak certificate signature: SHA1
|_ least strength: C
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/mt767780(v=vs.85).aspx
On 03/01/2017 12:29 AM, Henrik Andersson wrote:
|TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C|
The above is the compromised by the sugar32 exploit
On 03/01/2017 12:38 AM, Henrik Andersson wrote:
As I understand Windows 7 should support more ciphers [1] as you can see below when is queried one of my own Windows 7 RDP servers. Seems like something fishy is going on with your Windows 7 server configuration.
Then something is fishy with six separate machines at two separate facilitates.
Also keep in mind that xfreerdp is working with all six.
Disabling 3DES kills rdesktop's ability to log into all six of these machines.
In case you missed my prior postings as to how to disable 3DES and the Sugar 32 exploit, I will repeat it here.
Thank you for all the help trying to track this down!
Note that there is a bug currently riding at nmap (reported by me) that means you have to use a plus sign in front of "+ssl-enum-ciphers", not two minus signs.
Also, extra information. I am unable to reproduce this error between my Linux host and my qemu-kvm virtual machine of Windows 7 Pro x64. But, since I do not have the time or patience to deal with M$ atrocious quality issues with their updates, the virtual machine is raw SP1, without any patches (it has extremely limited Internet access, has to get past and extreme firewall that I personally wrote, and is only used for research and modeling). So this issue occurred from one of M$'s miserable patches.
IISCrypto.exe: https://www.nartac.com/Products/IISCrypto/Download is a cool way to see all your protocols and disable what you want.
-T
How to test for 3DES (Sugar32): nmap -p xxxx -Pn --script +ssl-enum-ciphers aaa.bbb.ccc.ddd --script ssl-cert
How to disable 3DES (Sugar32 exploit) in Windows 7 (possibly other versions):
- Registry:
REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple
DES 168] "Enabled"=dword:00000000
Note: most easily done with IISCrypto.exe: https://www.nartac.com/Products/IISCrypto/Download
- gpedit.msc
--> Computer Configuration --> Policies --> Administrative Templates --> Windows Components --> Remote Desktop Services --> Remote Desktop Session Host --> Security
Require use of specific security layer for
remote (rdp) connections
set to "enabled"
set "Security Layer" to "RDP"
Require secure RCP commications
set to "enabled"
- reboot: shutdown /r /f /t 00
Then something is fishy with six separate machines at two separate facilitates.
As you can see in my output there are support for many more ciphers, it is undesirable to only support one as in your case. Especially if it uses a weak cipher such as 3DES. rdesktop uses openssl which disables the use of 3DES due to it is weak. And your server configuration only supports one which OpenSSL will reject which results in failed handshake.
Also keep in mind that xfreerdp is working with all six.
Are you sure you are using SSL in that case ? Problem two you have is that rdesktop fails to talk plain RDP with your server and as i mentioned, you will find hints about that problem in the event log.
Disabling 3DES kills rdesktop's ability to log into all six of these machines.
explained above..
I can see if i get time to perform the same lockdown steps you did but still, a SSL that only supports one cipher is not sane, which also is indicated by your cipher query on the server cipher preference error: Too few ciphers supported
I dug into OpenSSL if there is a way to enable the use of weak ciphers but couldn't find anything except for configuration flag enable-weak-ssl-ciphers when build OpenSSL. Nothing that seems controllable runtime.