False result on Microsoft Windows 2012

[users21]

Did run the script against an unpatched Microsoft Windows 2012 Server with IIS8.5 and got the following result:

Testing xxxx:443 for ciphers added in MS14-066...
Testing cipher DHE-RSA-AES256-GCM-SHA384: PASS
Testing cipher DHE-RSA-AES128-GCM-SHA256: PASS
Testing cipher AES256-GCM-SHA384: PASS
Testing cipher AES128-GCM-SHA256: PASS
System at xxxx:443 seems to be patched: YES

So the test will give you a false positive on MSW2012 which could be interpreted that the machine would have been patched.

[aaronkaplan]

Also please note that the test does NOT confirm that it is 100% not patched!
The result of "seems to be patched: NO" should rather be "seems to be patched: DONTKNOW"

[azet]

+1. This test is bullshit. Just because these ciphersuites are now enabled does not mean the actual vulnerability is patched.

That is NOT how you write vulnerability test-scripts. Since there is - to date - no further information available on the vulnerability, it's rather hard to test for it. I'd recommend to remove this repository because admins might use it for testing production systems and get false-positives. Questionable at best.

For reference: http://nmap.org/nsedoc/categories/vuln.html

[speijnik]

Let me comment on that as well.

@azet Those cipher suites have been added with the patch set that fixes the vulnerability, according to Microsoft. In a default configuration those newly added ciphers will be enabled, so these are new features/behavior the script is checking for.
It is not a vulnerability test, but a behavior analysis. If you modified the available cipher suites via the registry or "IIS Crypto" and tools alike I assume you know what you are doing (you should, at least) and you do fully understand what the script does.

Also, the script says "seems to be patched", not "is patched", subtle difference.
I added a few changes to both README.md (which already documented exactly how the check works) and the script itself, so we are now carrying prominent warnings about modifications of cipher suites and non-direct connections.

[speijnik]

@users21

Any chance this server is behind some sort of SSL offloading mechanism? Did you try checking against the default RDP port yet (3389)?
A false-negative looks weird, especially as Microsoft added those ciphers only now. Any chance there's a service running on port 443/tcp that does not use SChannel?

[users21]

@speijnik the machines are behind a loadbalancer, but the SSL is handled by the IIS server.
When looking at result from older SSLScan of some machines in the local network, I can see that the newly added ciphers has been among those supported in MSWin2012.

I know that the result isn't mangled by the loadbalancers as they support some other ciphers which do not come in the SSLScan.

[speijnik]

@users21 Could not reproduce that here.

Are you sure those cipher names are exactly the same?

ie. DHE-RSA-AES256-GCM-SHA384 (which was added by the security fixes) is not the same cipher as DHE-DSS-AES256-GCM-SHA384

I would be interested in the complete cipher list of your unpatched systems though, if you were to share those.
Also, could you please check if the fix/patch 2992611 is present on those systems? If so, they have been updated already, which would explain the false-negative you encountered.
It strikes me as odd that your systems seem to have some ciphers available that, according to Microsoft, were only added to the SChannel subsystem with the security patch.

[users21]

From a scan made 2014-10-28 on a MSWin2012:
Accepted TLSv12 256 bits DHE-RSA-AES256-GCM-SHA384

One of the patches which hasn't yet been applied is the 2992611, so the machine hasn't been yet patched and all automatic updates or pre-fetching has been disabled.

As far as I know, following ciphers are supported (limited by what my desktop machine supports):
AES128-GCM-SHA256 AES128-SHA AES128-SHA256 AES256-GCM-SHA384 AES256-SHA AES256-SHA256 DES-CBC3-SHA DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384 RC4-MD5 RC4-SHA

This is identical to what I get scanning a MSWin2012 machine which has the 2992611 applied

[speijnik]

You were right in the first place. Windows Server 2012 R2 does support those ciphers regardless of whether 2992611 is applied or not. Seems like the documentation of that patch was wrong.

I just pushed an update of the script which takes that into account and report that the result is "UNKNOWN" if either Windows Server 2012 or later is detected.
Detection is carried out by either testing the IIS version if the test is conducted against port 443 and IIS is found there or against EC ciphers that seem to have been added in Windows Server 2012.

Also, I've added a few more warnings and notes that should finally make clear how the test works, that it can be inconclusive in some cases and that this test saying the system is patched does not mean one does not have to check manually.

As for the EC ciphers: this is a long-shot right now, but those ciphers seem to be supported by Windows Server 2012 or later.
I'd be more than happy if someone could quickly verify that the detection is correct, because 4 eyes see more than two.

[users21]

The script seems to detect the correct version of server, I feel like it's way too much text, maybe a flag which makes you skip the "do you understand" question, if you want to make this more automated test.

But on the other hand, everyone should have patched by now...