Check for MS14-066 / CVE-2014-6321

[drwetter]

... aka Winshock.

Preferably use something better than check for four ciphers and TLS 1.2.

[drwetter]

Hi,

thx to Sebastian (hello!) I compiled a version of openssl which potentially can trigger this bug -- according to http://www.securitysift.com/exploiting-ms14-066-cve-2014-6321-aka-winshock/ , See https://testssl.sh/openssl-ms14-066.Linux.x86_64 , source diff see below #331 (comment)

ATM I can't test it as I don't have a potentially vulnerable machine handy. Also the test would kill lsass,exe, so it's not easy to test. Anybody can help here with a private machine ? (further instructions, see blog above).

Another non-invasive way might be like Nessus is doing it. In the plugin dir there's is a file=blob named ms14-066.nbin . I am not suggesting to copy it but Nessus seems to have a less intrusive way of checking this vulnerability. Any idea how that could work?

Cheers, Dirk

[drwetter]

See also Canvas tool: http://www.theregister.co.uk/2014/11/17/ms_schannel_crypto_poc/

[drwetter]

Another piece of information: http://researchcenter.paloaltonetworks.com/2014/12/code-trigger-ms14-066-ecdsa-server-bof-vulnerability/

[VoidSec]

@drwetter I'm currently working on it! I've vulnerable Windows 7 x86 and x64 VM in kernel debug mode. I tried your compiled OpenSSL version but I'm unable to crash lssas nor to hit the breakpoint (especially cause of the old: #1117). Would you mind sending me the source? I'll recompile it from scratch and try to generate some "detection" mechanism.

[drwetter]

Hi @VoidSec, that sounds cool!

I have the source on a machine I currently have limited access to. That'll take a bit. Please ping me if I forget this.

Or, @ Sebastian: Are you listening?

[VoidSec]

Sure, I'll ping you in a week. Regarding Nessus (I'm also working on understanding how they made the detection) plugins appears to be PID:79127 & 79638 (uncredentialed check)
ms14-066.nbin and smb_nt_ms14-066.nasl

[drwetter]

Good would be also a packet capture of the NSE plugin's ClientHello, maybe side by side by a regular TLS ClientHello of Nessus Edit: NSE --> NASL

[drwetter]

Found the diff which was sent to me in my mail, see here:

ms14-66.diff.txt

[VoidSec]

I've recovered the right OpenSSL version on which the diff is based of; made changes in order to define setChar function and some other variables but I'm still not able to hit the crash. @drwetter that's all you have?

Anyway, I've approached it from another POV. It seems that the patch for ms14-066 introduced 3/4 new cyphers. We should be able to detect those cyphers and consider the host patched if it has support. I'm still testing it on w7/win server but tomorrow I should be able to post more info.

[drwetter]

Yes, that's all. The cipher method is probably not the right thing to do as it leads to false positives. The nessus method was reliable. I had that once in a consulting 'gig' where the windows guys insisted that was a false positive as all patches were applied according to SCCM but in fact SP1 was missing... IIRC that was unauthenticated scan over the network.

[VoidSec]

Yep, it leads to false positives because the OS version should be checked too as appears that for Windows Server 2012 some of the ciphers were already present.

Leaving the cyphers list here as a reference:

• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256
• AES256-GCM-SHA384
• AES128-GCM-SHA256

I'll switch back on the nessus method

[VoidSec]

I finally had time to perform some checks. I’ve enabled Nessus PID 79638 and changed the port configuration until the plugin was not anymore able to perform the detection.
I’ve started with ports 80,139,443,445,3389 and firewalled one by one.
Minimum configuration for the Plugin to works is port 443 IIS or 3389 RDP.
I can confirm that PID 79638 only checks for cyphers.

Note that this plugin sends a client Certificate TLS handshake message followed by a CertificateVerify message.

I'm now trying filtering out cyphers to detect the minimum checks needed to lower false positives. Is that useful? Because if you do not like to use cyphers method to check for this vuln I do not have any more ideas.

PS: credentialed ms14-066 plugin, directly checks for schannell.dll version and compare it with known vulnerable versions.

[drwetter]

I can confirm that PID 79638 only checks for cyphers.

how can you tell? That plugin ("uncredentialed check") seems to be a binary (--> ms14-066.nbin) not a NASL script (https://www.tenable.com/plugins/nessus/79638).

Because if you do not like to use cyphers method to check for this vuln I do not have any more ideas.

as said above: Look into the ClientHello(s) when running the plugin against the server.

Ciphers only (s/y/i/) is prone to false positive and will be at best included when running experimental flag (EXPERIMENTAL=true ./testssl.sh ...). But I rather would not do that. Also there might be false negatives as using the registry one can change ciphers on windows.