Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
OpenSSL 'ChangeCipherSpec' MiTM Potential Vulnerability
#1
I am using Intraweb 14.2.1 and the OpenSSL dll libraries 1.0.2u(last modified 21/12/2019). We received below vulnerability on this quarter PT on one of the web application running as standalone. How can resolve this issue please?


[The OpenSSL service on the remote host is potentially vulnerable to aman-in-the-middle (MiTM) attack based on its response to twoconsecutive 'ChangeCipherSpec' messages during the incorrect phase ofan SSL/TLS handshake.This flaw could allow a MiTM attacker to decrypt or forge SSL messagesby telling the service to begin encrypted communications before keymaterial has been exchanged which causes predictable keys to be usedto secure future traffic.OpenSSL 1.0.1 is known to be exploitable. OpenSSL 0.9.8 and 1.0.0 arenot known to be vulnerable; however the OpenSSL team has advised thatusers of these older versions upgrade as a precaution. This checkdetects and reports all versions of OpenSSL that are potentiallyexploitable.Note that Indusface WAS has only tested for an SSL/TLS MiTM vulnerability(CVE-2014-0224). However Indusface WAS has inferred that the OpenSSL serviceon the remote host is also affected by six additional vulnerabilitiesthat were disclosed in OpenSSL's June 5th 2014 security advisory : - An error exists in the 'ssl3_read_bytes' function that permits data to be injected into other sessions or allows denial of service attacks. Note that this issue is exploitable only if SSL_MODE_RELEASE_BUFFERS is enabled. (CVE-2010-5298) - An error exists related to the implementation of the Elliptic Curve Digital Signature Algorithm (ECDSA) that allows nonce disclosure via the 'FLUSH+RELOAD' cache side-channel attack. (CVE-2014-0076) - A buffer overflow error exists related to invalid DTLS fragment handling that permits the execution of arbitrary code or allows denial of service attacks. Note that this issue only affects OpenSSL when used as a DTLS client or server. (CVE-2014-0195) - An error exists in the 'do_ssl3_write' function that permits a NULL pointer to be dereferenced which could allow denial of service attacks. Note that this issue is exploitable only if SSL_MODE_RELEASE_BUFFERS is enabled. (CVE-2014-0198) - An error exists related to DTLS handshake handling that could allow denial of service attacks. Note that this issue only affects OpenSSL when used as a DTLS client. (CVE-2014-0221) - An error exists in the 'dtls1_get_message_fragment' function related to anonymous ECDH cipher suites. This could allow denial of service attacks. Note that this issue only affects OpenSSL TLS clients. (CVE-2014-3470)OpenSSL did not release individual patches for these vulnerabilitiesinstead they were all patched under a single version release. Notethat the service will remain vulnerable after patching until theservice or host is restarted.]
Reply
#2
Hi. In ServerController.SSLOptions.CipherList, try to put only SCH_USE_STRONG_CRYPTO and TLS 1.2 ciphers only. You can check on the link below, all the ciphers used in windows (and in the IW 15 http.sys version). I'm using IW 15 (http.sys) and configured on windows, only TLS 1.2 and STRONG ciphers.
Link: https://docs.microsoft.com/pt-br/windows...s-10-v1607
Reply
#3
Current SA apps are limited to older TLS revisions as well until Indy is updated (in progress) for the newer TLS specs.

If you need newer TLS specs, consider deploying your IntraWeb application on IIS or http.sys (even easier) as they provide the SSL instead of IntraWeb (via Indy) when in SA.

Also IntraWeb 14 is now not being updated except for possibly critical issues and 15.2 is our current development tree so any updates, SSL or other will be applied to that branch not 14.
Reply
#4
(12-17-2020, 01:36 PM)Jose Nilton Pace Wrote: Hi. In ServerController.SSLOptions.CipherList, try to put only SCH_USE_STRONG_CRYPTO and TLS 1.2 ciphers only. You can check on the link below, all the ciphers used in windows (and in the IW 15 http.sys version). I'm using IW 15 (http.sys) and configured on windows, only TLS 1.2 and STRONG ciphers.
Link: https://docs.microsoft.com/pt-br/windows...s-10-v1607

Thanks for the reply Jose.This is what the cipher list what I am using now as per Alexnandre. Just want to add SCH_USE_STRONG_CRYPTO at the end? SSL version what am using is TLSv12

Code:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:
DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:!ADH:!EXP:!RC4:!eNULL@STRENGTH

(12-17-2020, 07:01 PM)kudzu Wrote: Current SA apps are limited to older TLS revisions as well until Indy is updated (in progress) for the newer TLS specs.

If you need newer TLS specs, consider deploying your IntraWeb application on IIS or http.sys (even easier) as they provide the SSL instead of IntraWeb (via Indy) when in SA.

Also IntraWeb 14 is now not being updated except for possibly critical issues and 15.2 is our current development tree so any updates, SSL or other will be applied to that branch not 14.
Thanks for the reply.
I have the 15.2 license also but this application is developed in 14 and it is difficult to move to it on 15 at this stage as this is a banking application and it is running smoothly. There were lots of vulnerabilities in this website and those were fixed by the help of Alexandre at that time. In the last quarter audit got few vulnerabilities and this is one of them. This application was running as a service earlier after it got crashed few times and then changed to SA and working properly in the last 2 years. Is there any other work around to resolve this issue please
Reply
#5
Alexandre is the best one to follow up with this as he worked with your project before.
Reply
#6
Try to use only these 6 Ciphers, in this exact order:
Code:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-SHA384:
ECDHE-RSA-AES128-SHA256

The last two are weak, according to SSLLABs, but they are needed for SAFARI 6, 7, 8 and Windows Phone 8. If you don't need them, you can remove the last 2 Cipher's.
   
There is a list of Clients that will not be able to access, image below:
   
List of Clients that will be able to access using only TLS 1.2 with STRONG CRYPTO
   
Reply
#7
(12-18-2020, 05:21 PM)kudzu Wrote: Alexandre is the best one to follow up with this as he worked with your project before.

I sent couple of mails re this to him last week and he didnt respond. it is possible forwards to him through this please

(12-18-2020, 07:15 PM)Jose Nilton Pace Wrote: Try to use only these 6 Ciphers, in this exact order:
Code:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-SHA384:
ECDHE-RSA-AES128-SHA256

The last two are weak, according to SSLLABs, but they are needed for SAFARI 6, 7, 8 and Windows Phone 8. If you don't need them, you can remove the last 2 Cipher's.

There is a list of Clients that will not be able to access, image below:

List of Clients that will be able to access using only TLS 1.2 with STRONG CRYPTO

Thank you.
this one also not required please?
!ADH:!EXP:!RC4:!eNULL@STRENGTH
Reply
#8
I have forwarded him this forum link to follow up.
Reply
#9
(12-22-2020, 07:46 PM)kudzu Wrote: I have forwarded him this forum link to follow up.

As you advised I done the Cipher list and this got resolved in this quarter PT. Thank you very much.

Code:
TInServerIOHandlerSSLOpenSSL(IOHandler).SSLOptions.CipherList :='ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:' +
'DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:' +
'ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:!ADH:!EXP:!RC4:!eNULL@STRENGTH';

Now getting the vulnerability 'SSL 64-bit Block Size Cipher Suites Supported (SWEET32)'. How can resolve this issue please
Reply
#10
Hi, add this:
Quote:!3DES
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)