- Monthly Newsletter - April 2014

Welcome to the newsletter by Richard Hicks (MCSE, MCITP:EA, Enterprise Security MVP), Technical Services Director for Celestix Networks. Each month we will bring you interesting and helpful information pertaining to Windows Security. We want to know what all of *you* are interested in hearing about, so please send your questions and suggestions for future newsletter content to

Editor's Corner

As the focus of this newsletter is on Windows security, I tend to emphasize Microsoft security when writing it each month. This month, however, is a little different. As I prepare to write this, a major security vulnerability, dubbed "Heartbleed", was recently discovered in the popular open source cryptography library – OpenSSL. I'll get to the details and implications of this bug shortly, but suffice it to say that this is easily one of the most devastating vulnerabilities in the history of the public Internet, in my opinion. Yes, worse than any of the infamous Microsoft vulnerabilities of the late 1990's and early 2000's. Why? Because this vulnerability affects the main privacy mechanism used by many popular web sites and myriad security solutions - SSL and TLS. Microsoft products and services are unaffected by this, as they don't rely on OpenSSL. Not surprisingly, this has re-ignited the debate in some circles about the security of open source compared to closed source technologies such as Microsoft. There has been a long standing myth that open source software is inherently more secure than closed source, simply because the source code is available freely for all to see. The theory goes that because it is open, everyone can look at it and vulnerabilities will be found quickly. The "strength in numbers" argument is purely theoretical, however. Just because many people can look at the code, doesn't mean they do. Also, it doesn't mean they are necessarily qualified to do so, especially from a security perspective. If you don't believe me, then why did it take a full two years to discover this bug? The argument for open source software being more secure fails miserably here. Even with the source code freely available for all to see, a serious vulnerability in a critical security library was reviewed, approved, went unnoticed (or unreported!) for many years. The open nature means that anyone can contribute code. But who is vetting these developers? Many open source projects are developed and maintained by unpaid volunteers. Are they following secure coding practices? Is a Security Development Lifecycle being followed? Are there assurances that some of these volunteers aren't working for the NSA or any other government? You might accuse me of wearing a tin-foil hat, but given what we now know about the pervasiveness of NSA intrusions, I'm probably closer to right than wrong here.

To be clear, I'm not stating that closed source software is more secure than open source. Nothing is ever completely secure. All software is developed by humans, and humans are fallible. However, the myth that open source is more secure than closed source has been thoroughly disproven.



On 7 April 2014, security researches announced a bug in the popular open source cryptographic library OpenSSL. The bug introduces a vulnerability in the SSL/TLS heartbeat extension that allows an attacker to read arbitrary blocks of data from the server or device running the vulnerable code. The vulnerability was first introduced on 31 December 2011 and has been in widespread use since OpenSSL version 1.01 was released on 12 March 2012. The vulnerability exists in OpenSSL versions 1.01 through 1.01f. The vulnerability was fixed in OpenSSL version 1.01g. Administrators are encouraged to update to the latest version of OpenSSL immediately, and to re-key their SSL certificates. If for any reason you cannot upgrade, it is recommended that you recompile OpenSSL using -DOPENSSL_NO_HEARTBEATS, which disables the vulnerable heartbeat feature. Another option is to use an SSL/TLS proxy, which can be effective for systems that cannot be easily updated (e.g. embedded devices, industrial control systems, etc.).

By exploiting the Heartbleed vulnerability, an attacker is able to retrieve memory from the affected server or device. This includes unencrypted information such as user request and responses, which might contain usernames, passwords, session cookies, or other types of sensitive information. Initially it was thought that retrieving the private key from the server's SSL certificate would be impossible. Sadly, that was disproven. Two security researches were able to produce attack code and successfully compromise the private key of a vulnerable web server – the worst case scenario for this vulnerability. The ramifications of this are staggering. By some estimates, nearly 20% of web sites on the public Internet are running vulnerable versions of OpenSSL. Some of the most popular sites on the Internet are affected. Not only will all of these sites need to be updated, each one will need to revoke and re-issue/re-key their SSL certificates. What's worse is that OpenSSL is in use in many security solutions, including popular and widely deployed SSL VPNs from numerous vendors. In addition, OpenSSL is included in millions of Android mobile phones. The affects of this vulnerability are sure to be widespread and catastrophic.

To determine if your web server or security solution is affected by the Heartbleed vulnerability, there are many tools available on the Internet that can perform this assessment. My favorite tool for this is the Qualys SSL Labs SSL Server test site available at Visit this site and enter the URL you wish to test. Make sure to check the box that says "do not show the results on the board" if you don't want the world to know you are vulnerable. 

With the demonstrated full compromise of a server running a vulnerable release of OpenSSL, users will be encouraged to change their passwords for many sites in the coming weeks. It would be a good idea to wait until the site in question has updated their servers and revoked and reissued their SSL certificates before doing so, however.

Practical IPv6 for Windows Administrators

With the rapid depletion of the global IPv4 address pool, the adoption of IPv6 is growing significantly. The total exhaustion of public IPv4 addresses is inevitable, making IPv6 knowledge an important and essential skill that network engineers and systems administrators will need to have to be successful. While there are some excellent IPv6 references available today, until now there has been a lack of practical, real-world implementation guidance for IPv6. Until now! Practical IPv6 for Windows Administrators provides detailed information necessary for network engineers and systems administrators planning to deploy IPv6 on their corporate networks. It covers important topics such as IPv6 address assignment and name resolution, along with specific IPv6 integration information for Microsoft services such as Exchange, SQL, SharePoint, Hyper-V, and more.

IPv4 is a dead man walking. IPv6 is the way of the future; in fact, it is here now! Order your copy of Practical IPv6 for Windows Administrators today.


Click here to order your copy today!

Microsoft Security Bulletins for April 2014

For the month of April, Microsoft released 4 security bulletins addressing 11 vulnerabilities. 2 bulletins are rated as critical and 2 are rated as important. Affected software includes all supported versions of Windows, Internet Explorer, and Microsoft Office. For more information about April's security bulletins click here. Please note that support for Windows XP ended on 8 April 2014. This month's security bulletin release includes the last updates for XP and Office 2003.

Security Articles of Interest

  1. The recently discovered security vulnerability in OpenSSL is obviously dominating the news this month. Here are a few links to help you learn more about this catastrophic vulnerability.

  2. The Heartbleed security vulnerability explained in graphical format.

  3. Microsoft products and services are not affected by the OpenSSL security vulnerability.

  4. When Heartbleed was first announced, it was thought that retrieving an affected server's private key would not be possible. Sadly, that was proven to be wrong. After issuing a challenge to the security community, CloudFlare announced that two researchers had successfully retrieved the private key from a vulnerable web server. Obviously this represents a worst-case scenario for anyone affected by this vulnerability, necessitating the revocation and re-keying/re-issuance of all SSL certificates.

  5. Given the recent revelations of widespread U.S. government spying, it's not surprising to think that perhaps this bug has been known for quite some time, perhaps even since it was first introduced. There have been reports that the NSA was aware of and was actively exploiting the vulnerability for nearly two years.

  6. It's not out of the realm of possibility to think that perhaps the developer responsible for the vulnerable code did so maliciously. Perhaps not, but it is still unfathomable to me that something as trivial as a simple bounds check was left out of the code and then overlooked during the code review process. Also, how did a serious vulnerability in such a critical security component go unnoticed for so long? The author of the code denies any malicious intent and insists it was an accident.

  7. Although primarily affecting web servers, the Heartbleed vulnerability in OpenSSL will also affect security products like SSL VPNs and mobile devices like Android. As you are going through your discovery process, don't overlook these important areas where OpenSSL may also be deployed.

  8. Although Heartbleed and OpenSSL are dominating the news this month, Microsoft isn't immune to security vulnerabilities by any stretch of the imagination. In late March, Microsoft announced security advisory 2953095 to address a vulnerability in Microsoft Word that could allow remote code execution. The vulnerability was patched with security bulletin MS14-017, released this month.

  9. The popular and long-running Full Disclosure security mailing list was shuttered by its owner in March. However, a new Full Disclosure security mailing list was quickly established by another security researcher eager to continue the sharing of security research information.
  10. Microsoft recently announced the beta release of security baseline information for Windows 8.1, Windows Server 2012 R2, and Internet Explorer 11. This new documentation includes guidance for protection against Pass-the-Hash attacks, blocking the use of web browsers on domain controllers, and various other pertinent security configuration information. Articles of Interest

  1. Securing Active Directory with PowerShell
  2. Web Browser Security Revisited – Part 5
  3. Netwrix Auditor voted Reader's Choice Award Winner – Event Log Monitoring
  4. Auditing vs. Advanced Auditing Configurations – Part 1
  5. Web Browser Security Revisited – Part 6

Windows Security Tip of the Month

Although no Microsoft products or services are affected by the Heartbleed OpenSSL vulnerability, the default configuration of SSL in many Microsoft solutions often can be improved. For example, Microsoft's venerable Forefront Threat Management Gateway (TMG) 2010, in its default configuration, receives a failing grade by the Qualys SSL Labs Test server. However, after a few simple changes to the configuration, the security posture of SSL on the TMG firewall can be improved greatly, and in fact receives an A grade once these changes have been made. In addition, these same changes can be made on the Forefront Unified Access Gateway (UAG) 2010 remote access server to improve protection for published applications. For more information on how to make these changes, click here.