Contact

Subscribe via Email

Subscribe via RSS

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

After Windows Update KB 3061518 many websites stop working in IE

At work every time some of our IT staff would access the BES server web console, IE would fail. Not with a 404 Page not found error but with a web site cannot be found error (with helpful hints to check your Internet connection, DNS, etc). 

The web console worked fine on my machine. I could ping the server from all machines and telnet to port 443 (HTTPS port) from all machines. The IE security, SSL, and certificate related settings were the same across all machines (including mine). Firefox gave the same error on all the machines – something about cipher suites – this was odd, but at least consistent across all machines (and we use IE with the console usually so wasn’t sure if Firefox always gave this error or it was just a recent occurrence). 

Since it didn’t seem to be a browser specific setting, and the Firefox cipher error was odd, I felt it must be something at the machine level. Unlike Firefox (and Chrome) which use their own SSL suite IE uses the Windows Secure Channel provider so there must be something different between my install of Windows and the problematic users. I had a look at the Event Viewer when opening the site in IE and found the following error: 

image001Couldn’t find much hits for that error The internal error state is 808 but at least it was Schannel related like I suspected. 

Time to find out if there were any difference in the Windows updates between my machine and the users. The following command gives a list of Windows Updates and the installed date:

The result was something along these lines (these are updates that were installed in the last two weeks on the problematic machine but not on my machine):

Since the problem started recently it must be one of the updates installed on the 20th. Going through each of the KB articles I finally hit gold with the last one – KB 3061518. Here’s what the update does:

This security update resolves a vulnerability in Windows. The vulnerability could allow information disclosure when Secure Channel (Schannel) allows the use of a weak Diffie-Hellman ephemeral (DHE) key length of 512 bits in an encrypted Transport Layer Security (TLS) session. Allowing 512-bit DHE keys makes DHE key exchanges weak and vulnerable to various attacks. For an attack to be successful, a server has to support 512-bit DHE key lengths. Windows TLS servers send a default DHE key length of 1,024 bits. After you install this security update, the minimum allowed DHE key length on client computers is changed to 1,024 bits by default, instead of the previous minimum allowed key length of 512 bits.

The workaround is simple. Either fix TLS on the webserver so its key length is 1024 bits or make a registry change on client computers so a key length of 512 bits is acceptable. I tested the latter on the user machine and that got the web console working, thus confirming the problem. Save the following as a .reg file and double click:

Reading more about the update I learnt that it’s a response to the logjam vulnerability against the Diffie-Hellman Key Exchange. I had forgotten about the Diffie-Hellman Key Exchange but thankfully I had written a blog post about this just a few months ago so I can go back and refresh my memory. 

Basically the Diffie-Hellman is an algorithm that helps two parties derive a shared secret key in public, such that anyone snooping on the conversation between these two parties has no idea what the shared secret key is. This secret key can then be used to encrypt further communication between these parties (using symmetric encryption, which is way faster). A good thing about Diffie-Hellman is that you can have an ephemeral version too in which every time the two parties talk to each other they generate a new shared secret to encrypt that conversation. This ephemeral Diffie-Hellman version is generally considered pretty secure and recommended (because if someone does ever break the encryption of one conversation, they still have no way of knowing what was talked about in other conversations). The ephemeral version can also use elliptic curves to generate the shared secret, this has the advantage of also being computationally faster. 

Anyways, ephemeral Diffie-Hellman is still a secure algorithm but there’s an unexpected problem with it. You see, back in the old days the US had export restrictions on crypto, and so web servers had this mode wherein they could be asked to use export ciphers and they will intentionally weaken security. A while back this “feature” was in the news thanks to the FREAK attack. Now it’s in the limelight again thanks to the logjam attack (which is what Microsoft’s KB fix above aims to fix). Unlike FREAK, though, which was an implementation bug, logjam is just expected behavior – just that no one still remembered this is how the system is supposed to behave now!

Here’s what happens. As usual the two parties (client and web server) will talk to each other in the open and come up with a shared secret key using the (ephemeral) Diffie-Hellman Key Exchange. In practice this should be foolproof but what could happen is that if the web server supports these export ciphers mode I mentioned above, someone could come in between the client-server conversation and ask the server to switch to this export mode (all that’s required is that the client – or rather someone pretending to be the client – ask the server for export grade ciphers). When the server gets this request it will intentionally choose weak parameters from its end as part of the Diffie-Hellman Key Exchange (specifically it will choose a 512 bits key that will be used to generate the ephmeral key later). The server won’t tell the client it’s choosing weaker parameters because it thinks the client asked, so the client is none the wiser that someone is playing mischief in between. The client will use these weaker parameters with the result that now the third party can try and decrypt the conversation between the client-server because the key they agree upon is a weaker key. 

Note that this has nothing to do with the key size of the certificate. And it has nothing to do with Diffie-Hellman Key Exchange being weak. It is only about servers still supporting this export mode and so the possibility that someone could get a server to use weaker parameters during the Key Exchange. 

The fix is simple really. You, the client, don’t have much of a say on what the server does. But you can insist that if a server could choose a 512 bits key as part of the Key Exchange process then you will simply refuse to deal with said server. And that’s what the KB fix above does. Once installed, if Schannel (on the client) notices that the web server it is talking to allows for 512 bits Diffie-Hellman keys it will simply refuse to talk to that web server. Period! (Note the emphasis here: even if the server only allows for 512 bits, i.e. it is not actually offering a weaker Diffie-Hellman parameter but merely supports export ciphers, the client will stop talking to it!). 

On the server side, the fix is again simple. You have two options – (1) disable export ciphers (see this and this articles for how to on Windows servers) and/ or (2) use Elliptic Curve Diffie-Hellman Key Exchange algorithms (because they don’t have the problems of a regular Diffie-Hellman Key Exchange). Do either of these and you are safe. (In our case I’ll have to get our admins looking after this BES console to implement one of these fixes on the server side). 

And that’s it! After a long time I had something fun to do. A simple problem of a website not opening turned out to be an interesting exercise in troubleshooting and offered some learning afterwards. :) Before I conclude here’s two links that are worth reading for more info on logjam:  CloudFlare postwebsite of the team who discovered logjam, with their recommendations for various web servers.

Cheers.

Update: This post by Matthew Green is a must read on logjam. Key takeaways (in case you weren’t already aware):

  • Logjam only applies to the non-Elliptic Curve variants of DHE. Regular DHE depends on the difficulty of solving the Discrete Logarithm problem. ECDHE depends on difficulty of solving Elliptic Curves.
  • Discrete Logarithm is still difficult to solve, but for small values of its parameters (e.g. 512 bits) it is relatively easier. 
  • Things are also made easier by the fact that most web servers use a common set of prime numbers. So attackers can precompute a table of prime numbers and use these to degrade the connection so it uses one of these weaker set of prime numbers (whose attack tables are already with them) and use these to quickly decrypt. 
  • Read the rest of that post for lots more interesting details. Thanks to Bruce Schneier’s blog for pointing to the post. 

Also, remember: this is about the key exchange. Not about server identity. The server can use an RSA certificate to verify its identity but use Diffie-Hellman for key exchange (and that is the preferred scenario in fact as Diffie-Hellman is better). Here’s RFC 4492 which lists five different key exchange algorithms. Moral of the story is, use Diffie-Hellman as usual but either disable the export grade stuff (so there’s no chance of using weaker parameters) or switch to the better Elliptic Curve Diffie-Hellman. This has nothing to do with the RSA or DSA certificates that the server might otherwise use

Notes on Windows LSA, Secure Channel, NTLM, etc.

These are some notes to myself on the Windows security subsystem. 

On Windows, the Local Security Authority (LSA) is a subsystem that is responsible for security of the system. The LSA runs as a process called the LSA Subsystem Service (LSASS; you can find it as c:\Windows\System32\lsass.exe) and takes care of two tasks: (1) authentication and (2) enforcing local security policies on system.

For authentication the LSA makes uses of Security Support Providers (SSPs) that provide various authentication protocols. SSPs are Dynamic Link Libraries (DLLs) that offer the authentication protocol to applications that wish to make use of it. They expose a Security Service Provider Interface (SSPI) API which applications can make use of without knowing about the underlying protocol. (Generic Security Service Application Program Interface (GSSAPI or GSS-API) is an IETF standard that defines an API for programs to access security services. SSPI is is a proprietary variant of GSSAPI). 

In a way this post ties in with other things I have been reading about and posted recently. Stuff like encryption ciphers and Active Directory. On domain joined machines for instance, LSA uses Active Directory, while on non-domain joined machines LSA uses Security Accounts Manager (SAM). Either case the LSA is a critical component. 

It is possible to create custom SSPs to support new protocols. Microsoft includes the following SSPs (may not be an exhaustive list).

Kerberos (Kerberos.dll)

  • Provides the Kerberos authentication protocol. This is the protocol of choice in Windows. 
  • Kerberos cannot be used with non-domain joined systems. 
  • More about Kerberos in a later post. I plan to cover it as part of Active Directory. 

NTLM — LM, NTLM, and NTLMv2 (Msv1_0.dll)

  • Provides the NTLM authentication protocol.
    • LM == LAN Manager (also called as LAN MAN). It’s an old way of authentication – from pre Windows NT days. Not recommended any more. 
    • NTLM == NT LAN Manager. Is a successor to LM. Introduced with Windows NT. Is backward compatible to LAN MAN. It too is not recommended any more. It’s worth pointing out that NTLM uses RC4 for encryption (which is insecure as I previously pointed out).
    • NTLMv2 == NT LAN Manager version 2. Is a successor to NTLM. Introduced in Windows 2000 (and in Windows NT as part of SP4). It is the current recommended alternative to LM and NTLM and is the default since Windows Vista.
  • Although Kerberos is the preferred protocol NTLM is still supported by Windows.
  • Also, NTLM must be used on standalone systems as these don’t support Kerberos. 
  • NTLM is a challenge/ response type of authentication protocol. Here’s how it works roughly:
    • The client sends its username to the server. This could be a domain user or a local user (i.e. stored in the server SAM database). Notice that the password isn’t sent. 
    • To authenticate, the server sends some random data to the client – the challenge
    • The client encrypts this data with a hash of its password – the response. Notice that the hash of the password is used as a key to encrypt the data. 
    • If the username is stored in the server SAM database, the hash of the password will be present with the username. The server simply uses this hash to encrypt its challenge, compares the result with the response from the client, and if the two match authenticates the client. 
    • If the username is not stored in the server SAM database, it sends the username, the challenge, and response to a Domain Controller. The Domain Controller will have the password hash along with the username, so it looks these up and performs similar steps as above, compares the two results, and if they match authenticates the client.  
  • Here are some interesting blog posts on NTLM security:
    • NTLM Challenge Response is 100% Broken – talks about vulnerabilities in NTLM & LM, and why it’s better to use NTLMv2.
    • The Most Misunderstood Windows Security Setting of All Time – about the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel registry key (mentioned in the above blog post too) which affects how Windows uses NTLMv2. By default Vista and above only send NTLMv2 reponses but accept LM, NTLM, and NTLMv2 challenges. This post also goes into how NTLMv2 performs the challenge/ response I mention above differently.
      • NTLMv2 uses a different hash function (HMAC-MD5 instead of MD4).
      • NTLMv2 also includes a challenge from the client to the server. 
      • It is also possible to use NTLM for authentication with NTLMv2 for session security.
    • Rehashing Pass the Hash – a blog post of Pass the Hash (PtH) which is about stealing the stored password hash (in memory) from the client and using that to authenticate as the client elsewhere (since the hash is equivalent to the password, getting hold of the hash is sufficient). This post also made me realize that LM/ NTLM/ NTLMv2 hashes are unsalted – i.e. the password is hashed and stored, there’s no extra bit added to the password before salting just to make it difficult for attackers to guess the password. (Very briefly: if my password is “Password” and its hashed as it is to “12345”, all any attacker needs to do is try a large number of passwords and compare their hash with “12345”. Whichever one matches is what my password would be! Attackers can create “hash tables” that contain words and their hashes, so they don’t even have to compute the hash to guess my password. To work around this most systems salt the hash. That is, the add some random text – which varies for each user – to the password, so instead of hashing “Password” the system would hash “xxxPassword”. Now an attacker can’t simply reuse any existing hashtables, thus improving security).
      • A good blog post that illustrates Pass the Hash.
      • A PDF presentation that talks about Pass the Hash.
      • Windows 8.1 makes it difficult to do Pass-the-Hash. As the post says, you cannot eliminate Pass-the-Hash attacks as long as the hash is not in some way tied to the hardware machine.
    • When you login to the domain, your computer caches a hash of the password so that you can login even if your Domain Controller is down/ unreachable. This cache stores an MD4 hash of the “MD4 hash of the password + plus the username”.
    • If all the above isn’t enough and you want to know even more about how NTLM works look no further than this page by Eric Glass. :)

Negotiate (secur32.dll)

  • This is a psuedo-SSP. Also called the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO). 
  • It lets clients and servers negotiate a protocol to use for further authentication – NTLM or Kerberos. That’s why it is a psuedo-SSP, it doesn’t provide any authentication of its own. 
  • Kerberos is always selected unless one of the parties cannot use it. 
  • Also, if an SPN (Service Principal Name), NetBIOS name, or UPN (User Principal Name) is not given then Kerberos will not be used. Thus if you connect to a server via IP address then NTLM will be used. 

CredSSP (credssp.dll)

  • Provides the Credential Security Support Provider (CredSSP) protocol. 
  • This allows for user credentials from a client to be delegated to a server for remote authentication from there on. CredSSP was introduced in Windows Vista.
  • Some day I’ll write a blog post on CredSSP and PowerShell :) but for now I’ll point to this Scripting Guy blog post that gives an example of how CredSSP is used. If I connect remotely to some machine – meaning I have authenticated with it – and now I want to connect to some other machine from this machine (maybe I want to open a shared folder), there must be some way for my credentials to be passed to this first machine I am connected to so it can authenticate me with the second machine. That’s where CredSSP comes into play. 
  • CredSSP uses TLS/SSL and the Negotiate/SPNGO SSP to delegate credentials. 
  • More about CredSSP at this MSDN article

Digest (Wdigest.dll)

  • Provides the Digest protocol. See these TechNet articles for more on Digest authentication and how it works
  • Like NTLM, this is a challenge/ response type of authentication protocol. Mostly used with HTTP or LDAP. 
  • There is no encryption involved, only hashing. Can be used in conjunction with SSL/TLS for encryption.

SChannel (Schannel.dll)

  • Provides the SSL/ TLS authentication protocols and support for Public Key Infrastructure (PKI). 
  • Different versions of Windows have different support for TLS/SSL/ DTLS because the SChannel SSP in that version of Windows only supports certain features. For instance:
  • More about SChannel at this TechNet page
  • Used when visiting websites via HTTPS.
  • Used by domain joined machines when talking to Domain Controllers – for validation, changing machine account password, NTLM authentication pass-through, SID look-up, group policies etc.
    • Used between domain machines and Domain Controllers, as well as between Domain Controllers. In case of the latter secure channel is also used for replication. Secure channels also exist between DCs in different trusted domain. 
    • Upon boot up every domain machine will discover a DC, authenticate its machine password with the DC, and create a secure channel to the DC. The Netlogon service maintains the secure channel. 
    • Every machine account in the domain has a password. This password is used to create the secure channel with the domain. 
      • Upon boot up every domain machine will discover a DC, authenticate its machine password with the DC, and create a secure channel to the DC. 
    • This is a good post to read on how to find if secure channel is broken. It shows three methods to identify a problem – NLTest, PowerShell, WMI – and if the secure channel is broken because the machine password is different from what AD has then the NLTest /SC_RESET:<DomainName> command can reset it.
      • A note on the machine password: machine account passwords do not expire in AD (unlike user account passwords). Every 30 days (configurable via a registry key) the Netlogon service of the machine will initiate a password change. Before changing the password it will test whether a secure channel exists. Only after creating a secure channel will it change the password. This post is worth reading for more info. These password changes can be disable via a registry key/ group policy
  • More on how SSL/TLS is implemented in SChannel can be found at this TechNet page.