IE - A Single Point of Failure

The news this weekend of yet another Microsoft Internet Explorer Zero Day vulnerability and working exploit has been met by the IT community with the usual disdain.

It was followed on Monday morning and much of Tuesday by frantic activity to update or completely remove Adobe Flash Player (needed by the current exploit to prepare memory prior to the installation of drive-by-Malware), and by the unregistering of VGX.DLL which provides support for Vector Markup Language (VML). Combined these activities are believed to thwart would-be attackers using the currently known exploit, until such times that Redmond can come up with an official patch.

The known exploit can be executed by Remote Code Execution. A user need not do anything more risky than simply visit a booby-trapped web page or view an image file that has been compromised to trick Internet Explorer into installing Malware or other executable code from the Internet. No dialog, no warning, no sign what-so-ever that a system has just been infiltrated!

The issue is not just that this is another zero day exploit - (one for which there is no readily available patch which with to remediate and protect), although that’s bad enough in itself.

The issue is not just that the vulnerability affects every current version of Microsoft Internet Explorer from version 6 to the latest release of Version 11. Or that it affects nearly every current computer operating system that runs Windows - PCs, laptops, AND more worryingly servers.

The issue is not even that a large number of Windows systems will never be patched by Microsoft since Redmond just withdrew support for Windows XP, which by some estimates still accounts for nearly 40% of computers in use globally.

The issue is with corporate IT and a double dependency with the computer systems that run business enterprises and much of industry the world over, nearly all of which have built a reliance upon Windows and its virtually uninstallable web browser, Internet Explorer.

After a series of lawsuits and hefty fines in the late 1990s and early 2000s from the European Community and other countries for anti-competitive behavior following Microsoft’s bundling of its web browser with copies of Windows and the subsequent ridding of competition, Microsoft tightly bound Internet Explorer into the core of its operating systems as a defense against future law suits, claiming that it was vital to the operating system, furthermore that is was in fact PART of the operating system and therefore inseparable. With the demise of competition (until recently), the result has been a near total dominance of Internet Explorer in the workplace and on enterprise managed PCs despite the rise in use of other browsers at home.

The trouble with this is that IT departments along with many of the world’s leading business software vendors, have written their applications to run solely on Internet Explorer, using proprietary functionality built by Microsoft into its web browser rather than following WC3 cross browser standards - an international body setup to govern the growth of the World Wide Web.

Many internal applications written by IT departments along with the customized implementation of leading ERP systems and other business applications such as SAP, simply won’t work on Firefox, Chrome, Safari, Opera or any non-Microsoft web browser. Many IT departments don’t even give their users a choice of web browser so everyone is stuck with the company approved version of Internet Explorer. A web browser as we have already noted that is at present, totally open to drive-by attacks. This in turn could infect and severely impact, (or totally impede), corporate networks just as other vulnerabilities have done in the past. Corporate IT now finds itself up the preverbal creek and without a paddle!

The dilemma for corporate IT is how does it engineer its way out of the single point of failure currently holding company application infrastructure hostage via an unhealthy dependance on Internet Explorer? It will no doubt take time, lots of money and effective governance to ensure that all current and future applications are (re)written to cross-browser W3C standards - something that they should be been written to all along. At least then, business users will have a choice and IT will be able to either disable vulnerable applications like Internet Explorer till safe, or request that users employ other web browsers till patches can be applied to remove risks.

The dilemma for others however is less clear-cut, particularly the further you get away from Redmond, WA and those who for whatever reason have not upgraded hardware and operating systems to support a currently accepted patch-receiving Windows platform.

With so many millions of Windows systems now unlikely to ever receive another patch, the prospect for future safe and efficient Internet usage for the rest of us is very much in doubt.

There is a very real and present danger of a Zombie computer army consisting of up to 40% of the world’s computer systems managed by command and control centers owned by nefarious players that could hold the entire Internet to ransom or bring everything to its knees. That includes business and business applications as well as the web surfing public.

An ethical and political question should be raised to Microsoft. Is it really acceptable to the rest of us for Microsoft to withdraw the patching of vulnerabilities in its code of older and still very popular Windows XP systems, when failure to patch known vulnerabilities could have such far-reaching impact on everyone, including those who have paid for Microsoft’s latest systems?

Many companies can not afford to upgrade tens of thousands of workstations running Windows XP and the associated work involved in re-writing hundreds of applications to run on newer operating systems from Redmond or elsewhere.

Many poorer countries have no intention of purchasing new computer hardware to support Microsoft’s current and more demanding operating systems. Nor do they have the money to purchase new versions of Windows even at hugely discounted local prices. These systems will remain unpatched and unprotected for years to come not just against this critical threat, but also against the no doubt hundreds or thousands of other vulnerabilities and potential exploits which will be discovered in Microsoft code over the next decade.

With so many of its users excluded from support, what responsibility should Microsoft bear to ensure that common shared resources such as the Internet are not negatively impacted by computers running its abandoned operating systems?

Governments and most individuals widely consider there to be an economic utility in population health. If the person next to me on a crowded plane, train, office or school is sick with a communicable disease then the chances are I may be infected, so its in my best interest to ensure that everyone is as healthy as possible. Should not the same rules of population health and economic utility then apply to communicable diseases (viruses, Malware, etc.) in computer systems?

Read More

Healthcare's Continuing Heartbleed

It has been nearly two weeks since the Heartbleed vulnerability shook the global e-commerce industry with the realization that Web servers around the world were open to a vulnerability in OpenSSL’s heartbeat feature — and they’d been that way for the past two years. Fortunately, a large number of vulnerable systems have been fixed by now, and most healthcare websites across North America and Europe have been patched and use new server certificates and keys.

It’s still unknown at this stage just how many sites and systems were exploited and what data was compromised, but at least a few large organizations appear to have suffered breaches and, as investigations continue, more will likely join the list. It also remains to be seen whether any significant breaches of personal health information have occurred as a result of Heartbleed and whether regulatory agencies will conduct (expensive) onsite investigations of entities unfortunate enough to be hit.

Healthcare providers have reviewed and patched most of their primary systems, portals and websites that rely on OpenSSL. However, most providers have not considered the vulnerabilities that may exist still in secondary and tertiary systems, many of which include embedded versions of OpenSSL.

Secondary systems, such as hospital VPNs that provide remote access to patients, visitors, partners and business associates, use OpenSSL. Most enterprise routers, firewalls, switches and other key networking components contain a Web server for setup and management. Smaller networking devices, such as cable modems, DSL routers, etc., that provide network access from branch clinics and physician offices to their local hospitals, also contain embedded Web servers, and most also leverage OpenSSL.

If a hacker can use Heartbleed to compromise the router in a small clinic, for example, he or she can obtain the encryption keys or certificates used to secure remote access to hospital networks and information systems. Those keys and certificates may not be unique to that particular clinic and could be common to all VPNs of a particular hospital supporting literally hundreds of other clinics and physician offices.

A multi-million-dollar hospital operation is only as secure as its weakest link and, in this case, could be compromised easily by a $30 consumer router left forgotten and unpatched in a remote clinic. Of course, keys and certificates should be unique to each connection, but best security practices are not always followed in healthcare.

Lesser-known building management systems (BMS) used to manage hospital infrastructure —HVAC, power, water and a heap of other services vital to the successful delivery of healthcare — are now managed by offsite, third-party service providers. Most of these remotely access systems via the devices’ Web interface, often secured only by an SSL connection.

Most hospital security and IT leaders have little or no understanding of these potentially vulnerable BMS devices scattered around various sites, nor do they have access to or an inventory of most of them. Many have been in place for years and may have been installed by outside electrical or HVAC contractors and never documented. Only the facilities department would have the slightest idea of their whereabouts or functionality.

All of these ancillary systems will need to be discovered, documented, carefully investigated and patched if vulnerable. This gargantuan task will take weeks of investigative work and examination, and require security staff to visit all kinds of locations to verify that their core network is not likely to be compromised.

Any devices or services — and the systems accessed by them — that are found to be vulnerable and accessible will need further investigation for unauthorized data access.

Unfortunately, as much as we would like to think that Heartbleed is behind us now, the fact is that for most of us in the healthcare industry, it has only just begun.

Read More

What is Heartbleed and why is it different from just another cybersecurity vulnerability?

We have all, to a large degree, become numb to the constant stream of cybersecurity vulnerabilities and mass of patches forced upon us each month. As our IT systems become ever more complex and the code behind them ever longer, so too does the likelihood that the code will contain an unknown security vulnerability that could be exploited by hackers.

If a security vulnerability is discovered in the operating system of your Windows laptop for example, it's a simple case of Microsoft creating a patch and making it available for download so that you can fix the vulnerability before someone creates an exploit and turns your laptop into a zombie machine used for some nefarious purpose.

The theory is that if you patch quickly and you run anti-virus/anti-malware software you should be fairly safe. Systems running other operating systems, Apple OS X or Linux for example, are much newer than Windows, have less legacy code and less vulnerabilities, and by and large are smaller targets for hackers. Vulnerabilities are usually unique to an operating system or application, and therefore only affect a subset of Internet users.

Heartbleed is a little different. It's a vulnerability in the server security component designed to protect web-based traffic and a heap of other communications by encrypting and protecting the data going back and forth. The security is provided by Secure Sockets Layer/Transport Layer Security (SSL/TLS), which makes the difference between an HTTP and HTTPS address in the URL or address bar of your web browser. It also provides the green padlock on some browsers to signify that it's safe to enter confidential information, such as your name, address or credit card number. As mentioned earlier, SSL/TLS is also used several other ways, but its use in securing web traffic and e-commerce is ubiquitous and global.

A sudden and protracted widespread loss of confidence in the ability of users to interact securely with websites would have far reaching impact to Internet commerce, online banking, auction and travel websites and, perhaps topical for this time of year, in the United States and Canada, tax returns. In fact on Friday the Canadian government turned off the ability to submit tax return information online until it had a chance to assess the security of its systems.

Governments and commercial business now rely heavily on the ability to conduct business via the Internet so reluctance by consumers to also conduct business this way could have a massive impact on national and potentially global economies. This is why Heartbleed is SO significant above all other recent bugs and why a small error in the code behind TLS could possibly slow the world economy.

Of course this is a bit of a doomsayer view and in all likelihood, vulnerabilities will be patched within days the world over and security restored to the web and e-commerce. Two issues remain, however. First, the vulnerability in question has existed in certain versions of OpenSSL for two years.‘Should’ anyone have discovered this and exploited it to their own nefarious purposes, then there ‘could’ be all kinds of identity theft, and credit card and banking fraud, in addition to a heap of other problems related to the theft of Personal Identity Information, Protected Health Information and other confidential information.

The second issue is that consumers have been lulled and courted into using the Internet for the past 25 years on the promise that it was secure and that their information and finances were protected. This has allowed companies and governments to adopt more efficient and cost effective models of doing business that could now be challenged by a loss of confidence amongst their consumers. Depending upon media hype and whether anyone really was compromised, this could have a long-standing impact on the growth of business in this area.

What is the Heartbleed bug exactly?

It's a bug in certain versions of the ‘heartbeat’ feature of the TLS protocol used by OpenSSL that affects roughly two-thirds of the web servers that power the Internet. Hence the “Heartbleed” name. It's programming error was pushed to web servers over the past two years as they were upgraded to newer versions of OpenSSL and could affect the protection of the encryption keys and certificates used to identify users and to validate websites. It affects OpenSSL versions 1.0.1 released in December 2011 through 1.0.1f, which was until very recently the current version, along with certain beta versions of 1.02.

It doesn't affect Microsoft or Apple web servers, but it does affect a very large number of Apache web servers, which run mainly on Linux or Unix.

The heartbeat vulnerability was discovered a month ago and kept quiet while a patch was written and provided to systems administrators. Widespread publication of the Heartbleed vulnerability took place April 7th, and ever since there has been frantic activity by systems administrators and security professionals to patch systems before they could be compromised.

The OpenSSL 'Heartbeat' feature is used to maintain state and session information on users while they read, process or fill out web pages. It avoids a nasty time-out message and the need for the user to re-enter information again. Essentially it sends a 'heartbeat' back and forth to the web browser to see if the user is still there or not.

Instead of validating the advertised size of the heartbeat payload that OpenSSL writes to its memory, buggy versions of OpenSSL read back the payload from its first byte in memory to the length advertised for the heartbeat payload. Thus non-heartbeat information stored in memory is released if the advertised size of the payload is falsely provided. This is dangerous because that memory could contain confidential information posted by a user: passwords, account information, credit card numbers or , much worse, the encryption keys used to protect the entire server.

A simple exploit of the vulnerability thus works on the basis on passing false heartbeat information to a web server in order to retrieve information stored in its memory. It does this 64Kb at a time. 64Kb might not sound like a lot of memory but its more than enough to capture all the information a hacker could want and what’s more, the exploit can be run time and time again pulling information from affected web servers.

Even more worrying, it appears that exploiting this bug leaves no trace in the server’s logs, so there’s no easy way for a system administrator to know if servers have been compromised.

Rather than try to explain the technical details behind the vulnerability let me show you a video blackboard explanation of the vulnerability and potential attack by Zulfikar Ramzan, MIT Ph.D. and CTO of cloud security firm Elastica, this video does a great job of explaining things in easy to understand graphical terms.

So what should you do to protect yourself?

First, don't panic. Systems administrators and cybersecurity professionals have spent the last few days reviewing and patching their web servers and other systems reliant upon TLS to remove this vulnerability. They have also changed the encryption keys used on these servers. Some web sites that have been exposed have instituted a password reset, so that any passwords that users were using can no longer be used to access secure content, just in case these have been compromised.

It may take a few more days or even a another week or so for systems administrators to patch the majority of vulnerable systems - particularly those overseas where the message may take longer to reach. Many systems - those not running the vulnerable OpenSSL code - of course do not need patching as they were never at risk.

When the time is right, users should change their passwords for websites they use that may have been compromised. A fairly good list has been published by the folks at Mashable.

If a website or email service provider isn't listed, then you should look on the provider's website for information on Heartbleed for direction, and if none is provided, change your password anyway.

Of course if you rush out and change your password today, before the server vulnerability has been patched, then you run the risk of having to repeat the exercise again once it has been!

Once you've found that a website has been updated with the fix, change your password. Use a different password for each website on which you have an account. This keeps a hacker from potentially getting access to all of the accounts where you used the same password.

Systems administrators have a lot more work to do. The Heartbleed vulnerability may have exposed a lot more than user information and passwords. Not only will OpenSSL libraries need to be updated, but server certificates also will need regenerating, passwords changed and other vulnerable services using TLS updated. This includes services like FTP and VPN and even home network appliances like routers and firewalls most of which use TLS.

Systems Administrators should act quickly to patch all vulnerable systems and test patched systems to ensure that security vulnerabilities do not still exist.

Only then will user confidence be restored and our love relationship with conducting business from the comfort of our homes and workplaces reinstated - albeit more securely than it has been for the past two years!

Read More

New Guidelines for Securing Medical Devices and Networks

Medical Device Security

The increased use of technology in healthcare over the past decade has resulted in greatly improved patient outcomes. However, the addition of IP-enabled devices has elevated concerns about security. The U.S. Food and Drug Administration recently published an advisory on Cybersecurity for Medical Devices and Hospital Networks and a new draft guidance document, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.

It’s likely that the FDA’s guidance responds to a presidential Executive Order and Policy Directive aimed at reducing critical infrastructure risk and a Department of Homeland Security bulletin about the vulnerability of health system LANs due to unsecured medical devices connected to them.

As things stand, medical devices, which include everything from intravenous pumps and pharmacy robots to implanted pacemakers, can represent a huge vulnerability to the security of networks used to deliver healthcare. Many networks connect to hospital LANs via older, insecure wireless technology. Furthermore, many still retain their default security settings, making them easy targets for hackers. Medical devices have become, therefore, a potentially unsecured backdoor to vast amounts of highly valuable, personally identifiable health information stored on healthcare networks.

Not all providers have firewalled and segmented their networks to isolate these insecure medical devices, or implemented “bent-pipe” application security to encapsulate all communications to and from endpoints. As the black market price of a medical record continues to soar, cybercriminals are directed increasingly to the easy pickings of poorly secured healthcare networks, making the risks all the more apparent.

While the FDA’s guidance to medical device manufacturers has been a long time coming, in its current form it directs manufacturers to evaluate and address cybersecurity risks and vulnerabilities for current and planned devices. It does not necessarily address the millions of devices that may no longer be supported by manufacturers, but that still dominate hospitals and healthcare systems.

Despite an increased awareness about the vulnerability of these older devices, financial pressure on healthcare delivery makes it challenging for health providers to rip and replace them. Alternative security controls need to be considered to protect these devices and the networks to which they are attached.

While the new FDA guidelines and DHS bulletin stress the risks that medical devices pose to hospital networks, we also need to take into account the reverse situation. If hospital networks can be compromised via wireless medical devices, it stands to reason that life-sustaining medical devices can be compromised through poorly secured hospital networks. While some healthcare providers have state-of-the-art networks with high levels of performance, reliability and security, others have yet to make this investment in people, process and technology.

With ever-growing numbers of medical devices used in critical patient care, the risks that one or more will be compromised should be a huge concern to all of us. As they stand currently, these life-sustaining devices could be targets for cyberassassins or cyberterrorists seeking to extort or hold for ransom patients, medical device manufacturers and healthcare providers.

While attacks of this sort are not yet common, some have already occurred. A real possibility exists that more attacks of this type will take place in the not-too-distant future unless better security controls are used to protect these devices and the networks to which they are connected.

This post was co-authored with Sam Visner, who leads CSC’s global company‐wide cyber strategy.

Read More

The King is dead. Long live the King

Welcome to the new site. I retired and archived the old blog site in favour of the enhanced functionality of this new presentation template. I hope you agree that it presents information in a much cleaner format.

Read More