by guest blogger Steve Carlin, Bold Senior QA Engineer
“The Problem with SSL jokes is that you must get someone else to vouch for you before you can tell the joke.” ~Kai Engert
Do you remember the good old days when Netscape Navigator was the browser du jour? Back when the elite looked down on those lowly AOL users? If so, you might also remember the creation of SSL 3.0 which was devised and released by Netscape in 1996 (The same year that Windows NT 4.0 and Internet Explorer 3.0 were released). This changed everything for those of us who wanted desperately to securely buy and sell over the internet. It was a brand new world. This lead to the creation of TLS 1.0 in 1999.
As IT professional spent more time focusing on securing the session, the bad guys (and some good guys) were busy trying to find ways to exploit it for their own gain. So TLS 1.1 and 1.2 were eventually created. In 2006, TLS 1.1 was defined and in 2008, internet industries adopted TLS 1.2 standards. Each change made us more secure, but those who would choose to engage in nefarious endeavors continued to find weaknesses and exploits.
It took only three years (2011) for researchers to demonstrate a proof of concept called BEAST (Browser Exploit Against SSL/TLS) which capitalizes on a weakness in the cipher block chaining (CBC) to exploit the Secure Socket Layer (SSL) protocol. Another couple years and 2013 brought us the BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) attack against HTTP compression. 2014 opened the door to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack which led to completely disabling SSL 3.0 on the client and server side to prevent hackers from making use of this man-in-the-middle attack. 2014 also brought us the Heartbleed bug, BERserk, and FREAK exploits.
In 2016 the DROWN attack took advantage of support for SSLv2 protocol and exposed the weakness in more than 81,000 of the top 1 million most popular websites. [1] As we get closer to 2017, the odds are in favor of more exploits rather than less.
BoldnetNEO and our forthcoming ManitouNEO utilize HTML 5 coding and SSL certificates for all communication between the client and the server. This scenario is at risk if your IIS Server isn’t properly secured. And it’s not just our current generation of software offerings: BoldNet Silverlight, BoldNet PDA, and BoldNet Mobile all utilize Microsoft Internet Information Server (IIS) and can be exposed and potentially exploited if you aren’t doing your part to keep them secure.
We are not alone. Hundreds of enterprise level software suites have similar issues if IIS isn’t secured and administered by a proper security professional. These include software products like SedonaOffice and even Microsoft Exchange.
To keep your environment secure you must first remain vigilant about software updates. If you aren’t accepting regular Windows Updates, you are putting your network at risk. If you aren’t regularly patching issues with your software you are also potentially placing your network at risk.
When considering the best course of action for ensuring a secure IIS environment we recommend running the Qualys© SSL Labs SSL Server Test on ALL of your internet facing servers to make sure that you are not unreasonably exposed.
https://www.ssllabs.com/ssltest/index.html
Once you have your SSL report you might find that there are some weaknesses in your defenses. In fact, if you get less than an A rating you really should take the time to address any weaknesses reported. The most efficient way that we’ve found to correct this is to run the Nartac IIS Crypto tool to quickly, cleanly, and effectively remove those protocols which put your environment at risk. The Nartac IIS Crypto tool also has a security scanner built in which can be especially useful for those systems which aren’t currently exposed to the internet.
https://www.nartac.com/Products/IISCrypto
Our Best Practices template can be downloaded here:
https://www.dropbox.com/s/pzop7cakl0r0u3g/NeoBestPractices.ictpl?dl=0
Once you’ve secured your environment you may find that your Microsoft SQL Server is no longer accepting requests from the Manitou System Manager (MSM). This is likely due to TLS 1.0 being removed in favor of TLS 1.2. Microsoft understands the security implications of TLS 1.0 and they’ve addressed this with a patch: https://support.microsoft.com/en-us/kb/3135244
Further Recommended Reading
Vulnerability in Schannel Could Allow Security Feature Bypass (3046049): https://technet.microsoft.com/en-us/library/security/ms15-031.aspx
TLS/SSL Security Considerations: https://technet.microsoft.com/en-us/library/dn786446(v=ws.11).aspx
Exchange TLS & SSL Best Practices: https://blogs.technet.microsoft.com/exchange/2015/07/27/exchange-tls-ssl-best-practices/
Taming the Beast (Browser Exploit Against SSL/TLS): https://blogs.msdn.microsoft.com/kaushal/2011/10/03/taming-the-beast-browser-exploit-against-ssltls/
Disabling Browser Support for the SSL 3.0 Protocol: https://www.digicert.com/ssl-support/disabling-browser-support-ssl-v3.htm
“A Jedi uses the Force for knowledge and defense, never for attack.” ~ Frank Oz
[1] https://en.wikipedia.org/wiki/Transport_Layer_Security#Cross-protocol_attacks:_DROWN