Software vulnerabilities exist – it’s a fact of life that we all have to live with, and if we’re both lucky and diligent enough, we can patch it before any cybercriminals can exploit it. That isn’t always the case, but thankfully that’s the exception, not the rule.

However, news broke out recently of a vulnerability in the Heartbeat extension of OpenSSL, an open-source toolkit that helps webmasters and developers make transactions safer and more secure. This vulnerability, if taken advantage of – and there’s no way of knowing if cybercriminals already have, due to the nature of the vulnerability itself – could mean the compromise of a lot of transactions on websites and applications that use OpenSSL.

What is the Heartbeat OpenSSL Extension?

OpenSSL introduced an extension called Heartbeat around December 2011, with its 1.0.1 build release as defined in the RFC 6520 TLS/DTLS Heartbeat Extension. This extension’s function was to help avoid reestablishing sessions and allow for a mechanism by which SSL sessions could be kept alive for longer. The RFC proposed a HeartbeatRequest which must be answered with a HeartbeatResponse message. This results in a conservation of network resources, resources that would generally be used for full session renegotiation.

It’s to note here that OpenSSL is used by many websites and software, from open source servers such as Apache and nginx to email servers, chat servers, virtual private networks (VPNs) and even network appliances.

As such, it’s reasonable to assume that the Heartbeat extension is very widely used, thus making the scope of this vulnerability quite wide indeed.

Understanding The Heartbleed Bug

The vulnerability, dubbed as the Heartbleed Bug, exists on all OpenSSL implementations that use the Heartbeat extension. When exploited on a vulnerable server, it can allow an attacker to read a portion — up to 64 KB’s worth — of the computer’s memory at a time, without leaving any traces.

This small chunk of memory could contain user-critical personal information — private keys, usernames, passwords (in cleartext in a lot of cases), credit card information, and confidential documents for example. The attacker could request this chunk again and again in order to get as much information as they want – and this bug could be exploited by anyone on the Internet, anywhere.

A major Internet content provider was also affected by this bug and they fixed it quickly and diligently. But before it was fixed, some malicious actors had already stolen sensitive information.

At its core, the Heartbleed bug is a simple and usual programming error, the kind of which leads to security issues. In simplified terms, it returns memory contents without checking on how much it actually reads and returns.

As such, the user can ask for more information, and it gives the user more from the memory without checking to see if the user is in fact authorized to see that information. There is a payload length field that can be manipulated to grab the memory contents by tricking the server.

Figure 1. Payload Length of the Heartbleed Bug

This vulnerability has been assigned with the identifier CVE-2014-0160.

Since this attack leaves no traces at all – it is an abuse of a bug in the code – it is hard to say if it’s being exploited in the wild. We will be monitoring our sensors for any such behavior.

Which versions of OpenSSL are affected? Am I affected?

As per the OpenSSL advisory:

“Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.”

Any other versions of OpenSSL are NOT affected by this bug. If you compiled your applications with any of these versions, then you may be affected.

Users can also check if their server is affected by the Heartbleed vulnerability with this website.

The fixed version is 1.0.1g, which was released on April 7, 2014.

What should I do if I am affected?

Affected users must upgrade to OpenSSL version 1.0.1g which has the Heartbleed bug fixed.

If an upgrade is not possible you must recompile your applications to turn off the Heartbeat extension. This can be accomplished by using the -DOPENSSL_NO_HEARTBEATS flag.

SSL certificates must also be revoked and replaced with new ones. With SSL certificates installed with the affected version of OpenSSL, the private keys could be potentially exposed. With no specific method of knowing which existing certificates are affected, new SSL certificates must be generated.

End-users should also consider changing their passwords for their online accounts as the Heartbleed bug exposes sensitive information such as usernames and passwords. To avoid compromised accounts, users must reset all their passwords as soon as they are prompted to do so. They should also monitor for any suspicious activity involving their accounts, especially those financially related.

Trend Micro Solution

Trend Micro Deep Security customers should upgrade to DSRU-14-009 and assign the following rules:

• 1006010 – Restrict OpenSSL TLS/DTLS Heartbeat Request
• 1006011 – OpenSSL TLS/DTLS Heartbeat Information Disclosure Vulnerability
• 1006012 – Identified Suspicious OpenSSL TLS/DTLS Heartbeat Request

It is also possible to check for attempts to exploit the vulnerability through visibility and control of what goes on within a network. Through Deep Discovery, it is possible to monitor a web server and check for SSL/TLS-related traffic through the rule CVE-2014-0160-SSL_HEARTBEAT_EXPLOIT. Once found, Deep Discovery searches for Heartbeat message responses and checks for characteristics that indicate an exploit, specifically those related to the number of consecutive responses, the amount of information being echoed back, and others. This makes it possible to detect: attacks against a monitored server, as well as attempts to exploit the Heartbleed vulnerability from within a monitored network. This new Deep Discovery rule is released and automatically applied as part of the automatic update process for Deep Discovery.

Update as of April 14, 2014, 7:41 A.M. PDT

Client applications are also vulnerable to the Heartbleed vulnerability. If they connect to a malicious server, the Heartbleed bug can be exploited to read the client system’s memory. Last April 11th, Trend Micro released the following rules to protect customers using Deep Security and IDF from this exploit:

• 1006016 – OpenSSL TLS/DTLS Heartbeat Message Information Disclosure Vulnerability
• 1006017 – Restrict OpenSSL TLS/DTLS Heartbeat Message

For other posts discussing the Heartbleed bug, check these other posts:

• Trend Micro Heartbleed Detector Now Available
• Bundled OpenSSL Library Also Makes Apps and Android 4.1.1 Vulnerable to Heartbleed
• Heartbleed Bug—Mobile Apps are Affected Too
• Heartbleed Vulnerability Affects 5% of Select Top Level Domains from Top 1M

There are now less than two weeks left until Microsoft terminates support for the incredibly long-lived Windows XP. Rarely has a tech product lasted as long as XP has – from XP’s launch on  October 25, 2001 to its last Patch Tuesday on April 8, 2014 a total of 12 years, 5 months, and two weeks will have passed. Despite that, as of the month of February, StatCounter data indicated that almost one in five PCs still used Windows XP.

There has been plenty of concern—and in some quarters, hysteria—over this event. When it would happen has been known for some time. Informed users also know that Windows XP was developed in very different circumstances—the famous Bill Gates trustworthy computing memo was sent after Windows XP had been developed and released to the public.

The end of support for Windows XP concretely means two things: newly discovered vulnerabilities in Windows XP will not be patched anymore, nor will they be documented and acknowledged by Microsoft. This represents an increase in the risk of using Windows XP. Over time, this risk will increase as more issues are found and exploited –  although it may also fall, as the ever-decreasing numbers of Windows XP users means it will no longer be worthwhile to create exploits for an aging operating system.

However, managing and mitigating risks is what security is all about. We will continue to provide our customers with the necessary tools to help manage the risks facing Windows XP systems. The most valuable tool in managing these risks is virtual patching/vulnerability shielding; products like Deep Security and OfficeScan with the Intrusion Defense  Firewall (IDF) module  scan and inspect network traffic before they reach the user’s applications, providing an opportunity to protect servers and endpoints from vulnerabilities.

Another solution can be in hardening the endpoints. Endpoint security software will still protect users, if the security software vendor provides continued support for their products. (Trend Micro will continue to provide support for our endpoint software on Windows XP until 2017.) In addition, locking down these systems may be even more appropriate. For example, Trend Micro Endpoint Application Control can help lock down systems by preventing unwanted and unknown applications and processes from running.

The underlying point is this: yes, Windows XP’s end of support is something that people should worry about—but it  is something that can be planned and prepared for. The tools and expertise are available for users to help protect their systems and networks as needed. We have prepared a primer titled Managing Your Legacy Systems to go into this topic in more detail.

About two weeks ago, Oracle published a blog post describing – and promising – to improve the security of Java. Since then, I’ve been asked a few times: what exactly did they say, and what does it mean for end users?

First, Oracle talked about how they’re now handling security patches. They pointed out how recent patches had, in fact, solved more security holes than previous patches. What’s more important to take away is that Java’s update schedule has been brought in line with other Oracle products: it will receive patches every three months, starting in October of this year. This should help get potential problems fixed more quickly before they are exploited by attackers. Of course, Oracle will continue to deliver out-of-band updates as needed for critical vulnerabilities.

Java has also been brought under Oracle’s Software Security Assurance policies. As part of this, for example, Oracle will now use automated security testing tools to prevent regressions and new issues from showing up when a bug is fixed. This is welcome news, as it means that bugs will be patched more quickly in the future.

Next, they discussed how they had been working to improve the security of Java as it is used in browsers. More important than the discussion of what was done in the past is what Oracle will implement soon: future Java versions will no longer allow unsigned or self-signed apps to run. It’s not clear when this will happen, but if it does, it will be a significant increase in Java security. It means that attackers will have to acquire or compromise a code signing key to get their Java applets to run: while this will not stop a truly determined attacker, less targeted attacks will fail.  In addition, Oracle is also working to improve how Java processes revoked signing signatures, so that this process can be turned on by default at a later time.

For enterprise users, there’s good news too. Future versions will add support for security policies enforced by Windows itself, so that system administrators can set network-wide policies that can restrict or relax Java usage without having to set these per system. In addition, a new type of Java distribution – Server JRE – is being created specifically for servers running Java apps. This distribution will have several libraries removed to reduce the potential attack surfaces.

All of these changes are for the better – Oracle is acknowledging that there have been challenges when it comes to Java security in the past, and they’re working hard to improve it moving forward. We appreciate these efforts and hope that they succeed in reducing the threat from Java exploits, which is completely in line with Trend Micro’s goal of creating a world safe for exchanging digital information.

In the meantime, we strongly urge that users do their part to keep their Java installs safe: update to the latest version of Java. We earlier discussed how to secure Java in the blog post How to Use Java – If You Must.

In my previous blog post, I discussed some key takeaways that I got from the talks I attended in the recently concluded RSA 2013 in San Francisco, California. This time around, I want to share in length, some of these noteworthy sessions.

Innovation Sandbox

Innovation Sandbox was a packed session that Hugh Thompson ran quite deftly. Ten startups were selected and given three minutes to explain their technology, followed by a two-minute question-and-answer session, with questions coming from the judging panel, made up of industry experts.

All the company representatives talked about what they were doing and had to prove why their solution would work and generate revenue in the future. A white board session followed where thoughts from the audience were taken and put on an online whiteboard. 

The participants also had the opportunity to meet (or “date”, as they put it) with potential investors in an igloo-styled hut. Winners from previous years were also present to share their experiences and mingle with the participants.

Panel discussion on future of end point security

This panel discussed how changes in end-points are changing the security landscape. Bring Your Own Device (BYOD) and Virtual Desktop Infrastucture (VDI) are ensuring that enterprises no longer have the same control over theirs networks and devices that they had in the past. Solutions such as traffic filtering, network access control (NAC), software defined security (SDS) vs. traditional solutions were discussed. There was no definitive answer  - each technology has its uses, pros, and cons – but the points that came out from these discussions were quite insightful.

Awareness Doesn’t Matter: A Behavior Design Approach to Securing Users

This session talked about how user behavior could be used to trigger potential security alerts. This is an interesting area for research, but in actual usage is prone to false positives. However, in situations where security is an absolute must and false positives can be tolerated, this may be of use.

Malware Hunting with Sysinternals

Mark Russinovich, the author of the Sysinternals tools suite,  gave a brilliant talk about what’s new with Sysinternals tools and how these can used for malware analysis. His aim was to show how to carry out a quick analysis if there are any suspicious files on a system. He also discussed future developments, like more color coding for faster visualization of event. Russinovich kept the tone of his talk light, thanks to his wit and sense of humor.

Read the rest of this entry »

The annual RSA Conference is perhaps the biggest gathering of information security professionals from around the world. The topics that were discussed this year ranged from cloud security, mobile security to behavior based solutions.

With 22,000 participants, this year’s conference had a huge turnout. RSA 2013 was the perfect venue to pick-up the latest information about varied security topics, gather thought-provoking insights, and network with other experts and colleagues.

During the conference, I attended several interesting talks, which I will discuss in detail my next blog post. For now, I will share with you my high-level takeaways from these discussions:

• There is an increased involvement and interest from the government, which was evident from the buzz generated by the recent White House executive order on cybersecurity. Both the government and security industry expressed the desire for tightening cybercrime laws. The government encouraged more participation from the private sector and work as one. The Department of Homeland Security (DHS) also announced its initiative to share real time classified threat information with security vendors.
• Cloud Security was well discussed and generated a lot of interest from users.  A good part of the first day was dedicated to the Cloud Security Alliance Summit. There were some interesting keynotes from Mark Weatherford of DHS,  former American Express CEO Jim Robinson, and Trend Micro Vice President of Cloud Security Dave Asprey. Some of the key issues of cloud security were highlighted and best practices were discussed.

Read the rest of this entry »