Quoted in USA today on Microsoft’s workaround for the zero-day vulnerability in Internet Explorer:

Read More...

Tags: Microsoft, Vulnerabilities, Windows XP, Zero Days

The IE vulnerability that has been released (CVE-2014-1776) follows a fairly typical pattern we have seen before. Internet Explorer and Flash have a long track record of nasty vulnerabilities (along with Java and Adobe Reader). These vulnerabilities are useful for attackers who can set up web sites to exploit the vulnerability and then direct victims to those web sites via phishing emails, manipulating search engines, buying ads, or compromising legitimate popular web sites (so called “drive-by download attacks”). These types of attacks have been reported to be exploiting this vulnerability in the wild. Internet Explorer versions 6 though 11 are affected. Microsoft has issued an advisory with a number of workarounds that can be put into place while a patch is developed that can be found here: https://technet.microsoft.com/library/security/2963983

This vulnerability also factors into the recent news that Windows XP is no longer supported by Microsoft: This represents the first major vulnerability released for Windows XP since it went out of support earlier this month and, according to early reports, a patch will not be released for that platform. This means that the risk posed by any remaining Windows XP systems has just moved from theoretical to actual. Organizations should be moving off of the XP platform as soon as possible and taking extraordinary steps to protect any remaining XP systems in the interim.

Relying on basic vulnerability scans to detect this sort of vulnerability can lead to a false sense of security if the results come back clean: Most vulnerability scans are conducted from the perspective of an attacking coming in across a network and focus on making inbound connections to network services in order to identify vulnerabilities. In most cases these types of scans will not detect client-side vulnerabilities like this one as client side vulnerabilities are based on outbound connections. Most scanning tools can be configured to connect to target systems with a valid username and password in order to analyze the installed software versions and this type of scan should be effective in identifying this and other client-side vulnerabilities. Organizations that do not typically conduct this type of scan may be shocked at how many client-side vulnerabilities they actually have the first time they run it.

The broader issue here is that any installed software may include vulnerabilities that increases the "attack surface" an attacker has to work with. A core security concept is that any unnecessary software should be removed or disabled whenever possible to reduce the attack surface. Unfortunately (for security at least) most software vendors and IT organizations often choose ease-of-use over security and have default installations that tend to include many potentially unnecessary enabled features and plugins, including Flash, whether or not they are actually needed for business purposes. As system and network administrators have gotten better at disabling or firewalling unnecessary server software the attackers have shifted to attacking client software in order to gain a foothold inside a target network. Flash along with Java, Adobe¹s Reader software, and Internet Explorer itself are the most common client-side targets likely due to both their ubiquity and complexity (more complexity usually means more likely vulnerabilities).

Preventing this and future drive-by attacks will require IT to rethink how they deploy software. Rather than installing everything by default "in case someone needs it" IT should be creating workstations and servers with as little software as possible and then deciding what software to add based on the use-case for each system. For example if a workstation’s only business purpose is to enter credit card numbers into a processor’s web site and that web site does not require Flash then there is no reason to install Flash and add more potential vulnerabilities to the workstation. Most businesses will find that vulnerable plugins like Flash and Java are only needed for business purposes by a very small subset of their users. Of course many users are likely using these plugins for non-business purposes, like watching YouTube videos during downtime, and the organization will have to weigh the tradeoff of security versus the users’s desire to use their workstation just like they would use their home computer.

Apple in particular is already taking action along these lines: After years of having Java enabled by default Apple released a patch for Mac OS X that disabled Java due to a rash of zero-day vulnerabilities, users who actually need to use Java are provided with instructions on how to re-enable it when they reach a web site that requires it. Apple also added a feature to Safari that allows for the Flash and other plugins to be allowed or disallowed on a site-by-site basis. This feature in particular would provide the sort of granular control an IT organization would need in order to effectively manage client-side plugins like Flash: allow them for sites with a legitimate business need and disallow them everywhere else. The web does seem to be making a move to HTML version 5 which is an open standard that has the capability to replace most of Flash’s functionality. There is some hope that this transition will lead to less vulnerabilities than we’ve seen from Adobe’s proprietary software in the past.

Ultimately the choice is to keep scrambling with tactical fixes like workarounds and patches whenever these zero day vulnerabilities come out or making strategic decisions about how systems are deployed to reduce the overall risk to the organization.

Tags: Microsoft, Vulnerabilities, Windows XP, Zero Days, Flash, Java

Quoted in CRN on a new zero-day vulnerability in Internet Explorer:

Read More...

Tags: Microsoft, Vulnerabilities, Windows XP, Zero Days, Flash

Quoted in CSO on techniques to more accurately simulate real-world attacks including combining network and application hacking with phishing, social engineering, and physical infiltration:

Read More...

Tags: Penetration Testing, Social Engineering, Phishing, Physical Infiltration

Quoted in Wall Street and Tech on the increasing use of dating sites for phishing, spam, fraud, and other attacks:

Read More...

Tags: Malware, Social Engineering, Phishing, Fraud

A very nasty vulnerability has been discovered in the OpenSSL encryption software that powers the TLS/SSL* encryption behind many web sites, email servers, VPNs, and other solutions that require the confidentiality or integrity of information. OpenSSL is very widely used (coming standard with most Linux distributions and open source web servers like Apache) and most organizations will likely have vulnerable systems. This should be taken very seriously and remediated immediately, it has already been said that this vulnerability is worse than not having encryption at all.

*SSL and TLS are essentially the same thing: the encryption protocol used to be called “SSL” but was renamed to “TLS” a few years ago. Essentially what is TLS version 1.0 would have been SSL version 4.0 had it not been renamed. Although most implementations now primarily use the newer TLS version of the protocol people still commonly refer to it as SSL so I use “SSL/TLS” throughout this text to avoid confusion. Also note that OpenSSL is just one implementation of the open SSL/TLS protocol, there are other implementations of SSL/TLS that do not contain this vulnerability. To be clear: this is a bug in certain versions of the widely used OpenSSL software that implements the SSL/TLS encryption protocol, not a problem with the SSL/TLS protocol itself.

What it is
The gist of this vulnerability is that back in 2011 a bug slipped into the OpenSSL software that would allow any attacker who can connect to a service protected by SSL/TLS encryption to take a snapshot of a small 64 kilobyte chunk of the target server’s memory. Such a small amount of memory may not seem like much of a big deal but there is nothing preventing an attacker from making repeated requests for different memory addresses in order to reconstruct larger swaths of memory. The risk is exacerbated by the fact that OpenSSL by its very nature as an encryption product is often used to protect sensitive services, almost guaranteeing that an attack on an SSL/TLS service will result in something of use to an attacker. This could include usernames, passwords, session IDs, credit card numbers, or the encryption and decryption keys that protect the communication channel itself. Anyone who can connect to a server running a vulnerable version of OpenSSL can exploit this vulnerability whether they are logged into the protected service or not.

The vulnerability and the method of exploiting it is now well known. Attackers may already be using this techniques to capture information from vulnerable servers and the attack does not leave any evidence in logs so there is no way to know if a particular server has or has not been attacked. We must assume that any system found to have a vulnerable version of OpenSSL may have had data compromised and act accordingly. Because SSL/TLS connections are encrypted it would be very difficult to detect attacks using an Intrusion Detection System and this should not be seen as a reliable way of mitigating the threat.

How to fix it
The first step that an organization should take to mitigate this threat is to immediately patch any vulnerable systems. Anything running OpenSSL version 1.0.1 through 1.0.1f should be considered vulnerable and be patched to the latest version that includes a fix, currently 1.0.1g. Older versions of OpenSSL in the 1.0.0 branch and 0.9.8 branch are not vulnerable to this particular issue although they are older branches and may have other vulnerabilities of their own. It should be kept in mind that OpenSSL is used for more than just web servers: SSL/TLS encrypted email services, SSL/TLS VPN solutions, and just about anything else that uses an encrypted communication channel could be based on OpenSSL. Embedded devices and “Appliance” systems are areas that are often overlooked when it comes to patching and should be considered as potentially vulnerable.

Unfortunately patching alone is not enough to fully remediate this issue: An attacker can use the vulnerability to get SSL/TLS secret keys from the server and what seems to be overlooked in most reports about this flaw is that an attacker who gets those keys before the SSL/TLS service is patched can potentially continue to use the keys to decrypt data long after the patch has been applied. The same is true for login credentials or other sensitive data (social security numbers, credit card numbers, etc.) that an attacker gathers either from memory directly via the vulnerability or via decrypting traffic with stolen keys later on. As a result the complete guidance should be to patch OpenSSL and then immediately generate new encryption keys, revoke the old keys, and force users to change their potentially compromised passwords. Steps to address other potentially compromised data such as credit card numbers would have to be decided on a case-by-case basis depending on how likely it was that the data could have been affected.

What should I do?
The risk to an Internet user is that their information (access credentials, credit card numbers, etc.) might be captured by a malicious individual using the method described above. There isn’t much anyone can do to protect themselves if a service they use, such as an SSL encrypted web site or email account, is vulnerable beyond simply not using that service until the vulnerability is patched by the service provider. Even determining whether or not a service provider is vulnerable could be difficult, a tool does exist to check services for the vulnerability but running it against a service could potentially attract unwanted legal attention (there are unfortunately cases where individuals have ended up in prison for independently investigating services in web sites and other services). The possibility that the service’s encryption keys might have been stolen by an attacker while a service was vulnerable, as described above, also presents a risk to individual users even after the provider has patched the service: this would allow an attacker to decrypt traffic, a particular concern for users of public WiFi services where eavesdropping on others’ traffic is simple. Perhaps the easiest way to check if a site has taken steps to mitigate the vulnerability (and done it properly by generating new keys) is to check the certificate presented by the service. If the service provider was known to be vulnerable and the issue date of the certificate is prior to the release of the fix for this vulnerability then the keys likely have not been changed. On the other hand if the certificate was issued shortly after the fix was released it would indicate that the provider has taken steps to remediate the issue.

Tags: Vulnerabilities, Heartbleed