Tag Archives: XTM

DROWN Vulnerability – Daily Security Byte EP. 225

Researchers disclosed a critical new SSL vulnerability during one of the biggest security conferences in the world, RSA. DROWN, or Decrypting RSA with Obsolete and Weakened eNcryption, is an vulnerability that allows attackers to gain the public key of servers that still use SSLv2.0. Watch today’s video to learn more about it, and make sure to disable SSLv2.0 on all your servers, and to update OpenSSL.

(Episode Runtime: 5:25)

Direct YouTube Link: https://www.youtube.com/watch?v=TLMLw2sDB3E

EPISODE REFERENCES:

— Corey Nachreiner, CISSP (@SecAdept)

Network Security: Mining the Alphabet Soup for What Matters

The security industry likes to create acronyms – IAM, UTM, NGFW, MFA, EDR, etc. Perhaps it comes from the general human tendency of wanting to simply define complex topics. In an ever-changing industry, like information security, these acronyms and groupings create major challenges over time. Each year there are new threats, and with that comes more innovation and different approaches to security – all of which we try to initially force into predefined groupings – often diluting the value of the evolving technologies and confusing end-users. One such example is the ongoing attempt to force network security platforms into two distinct groups: Next-Generation Firewall (NGFW) and Unified Threat Management (UTM) appliances. The confusion between the two has become so apparent that analysts at last year’s Gartner’s Security and Risk Management Summit held a roundtable discussion on the very topic. The fact is that most end customers just want good security that solves their network security threats – they care less about NGFW and UTM. Today, I hope to both clear up some of that confusion, and share some data that quantitatively illustrates why UTM protections measurably increase your security efficacy.

UTM vs. NGFW; What’s the Difference?

At one point in time, when analysts first defined these two product segments, they had clear feature delineations in mind. At the highest level, NGFW appliances were firewalls with Intrusion prevention systems (IPS) and application control, whereas UTM appliances were firewalls with IPS, antivirus (AV), URL filtering, and anti-spam capabilities. However, over time both markets have organically evolved and changed. Now both solutions share a similar core set of capabilities. For instance, some NGFW solutions have added new security controls (like malware detection), which used to fall into the UTM camp. Meanwhile, UTMs have adopted all of the security features that helped define the NGFW market—such as application control—and have even added additional new security services to the mix.

This melding of feature sets between NGFW and UTM has made it a bit more difficult to differentiate products, but I think one high level description holds true. UTM solutions focus on unifying as many security controls as possible in one place, making them easier and more cost effective to manage, whereas NGFW solutions focus on only consolidating a limited subset of controls; specifically, ones that make the most sense in certain use cases, such as in a big data center environment. In plain English, UTM solutions tend to include more types of security controls than NGFWs.

How Layered UTM Security Improves Overall Defense

In essence, UTM’s core value proposition is that it combines many security controls in one place, increasing your overall security efficacy, and making layered security attainable for some organizations that couldn’t implement it otherwise. To really appreciate this, you need to understand why layered security improves your overall defense efficacy.

Ultimately, there are two reasons UTM layered security offers the best defense:

  1. No single security control is infallible – History has proven that information security is a constant arms race. The good guys invent a new security control that blocks an attack at first, but the bad guys react and find new ways to evade those defenses. Antivirus (AV) is a great example of this. The industry started with signature-based solutions that originally did a good job, but eventually the bad guys evolved, and reacted with new evasion techniques that bypassed reactive signature-based solutions. Today, we have more advanced, behavioral-based AV solutions, but already attackers are exploring ways to trick these new solutions. The point is, no matter how great a security control might seem, attackers will find ways around it, which is why it’s important to have the additional layers of security a UTM appliance provides to pick up the slack.
  2. There are different stages to a modern, blended attacks – You can break down modern network attacks into multiple stages. For example, the initial attack delivery, the exploit portion of the attack, the payload or malware delivery, the call home to the attacker, and so on. Security experts often refer to these stages as the Kill Chain. The importance of these stages is twofold; First, each stage is an additional opportunity for you to catch the attack. If you miss the first stage, you might still stop the second. Also, each of these stages requires a different type of defense. For instance, IPS isn’t intended to catch malware, but rather block software exploits. WatchGuard’s UTM appliances break the Kill Chain by incorporating all the different types of defenses necessary for each stage of an attack, and by layering them together so that a miss at one stage doesn’t rule out a block at another stage. Simply put, the more stages of an attack you protect against, the more effective your overall defense is, even when new threats bypass one defense.

At WatchGuard we care less about what you call what we do – UTM, multi-layered security, NGFW – we care more for the fact that we have created a mechanism to catch all the various stages of a modern network attack, and by layering these protections together, we give you multiple opportunities to block the threat even when one defense fails.

 

Don’t Just Take My Word for It!

On a theoretical level, it’s pretty easy to understand the value that WatchGuard’s layered UTM solutions provide, but analytical, scientific-minded people require quantifiable proof before they believe in any theory. Fortunately, NSS Labs, one of the world’s leading independent security product testing laboratories, has recently released a new threat warning service and testing methodology that proves the value of layered UTM security.

NSS Labs’ Cyber Advanced Warning System (CAWS)  enables vendors and end-users alike to view how effectively a variety of network security solutions are blocking real-time security threats. The system enables subscribers to view the efficacy of different solutions operating under different profiles: the base profile only enables specific so-called NGFW features as defined earlier in this blog, as well as the advanced profile, where a vendor can enable value-added UTM services such as I described in the example above, and which we provide at WatchGuard.

WatchGuard has actively participated in the CAWS service for the past few months, and it not only has helped us increase our security efficacy, but has also provided a very quantifiably measure of why UTM defenses works. Here’s a chart showing WatchGuard’s “block rate” results for about a month of new CAWS attacks:

Figure 1: Image courtesy of NSS Labs CAWS system

Figure 1: Image courtesy of NSS Labs CAWS system

In the chart above, the lower, orange line represents a traditional NGFW, that primarily only uses IPS to catch threats. However, the upper, muddy-yellow line represents our product using the full UTM feature set, which includes antimalware services like GAV and APT Blocker, as well as all our URL filtering services.

What’s important to note is the drop in our IPS only block rate during January 31st. While there could be a few reasons for this, it’s typically indicative of a new attack that our IPS didn’t catch. So why would I highlight this IPS miss? Well, looks at the yellow, UTM line… its block rate stays relatively high, despite the fact that IPS might have temporarily missed something new. Whether or not our daily IPS efficacy goes up or down, our full UTM defenses still catch well over 90% of the new threats each day, this further reinforces the importance of a layered approach to security as dips in IPS efficacy is not unique to WatchGuard.

Some have claimed, defense-in-depth, or layered security is dead. They make this declaration out of frustration, because lately we’ve seen so many organizations get compromised despite some defenses. However, I believe layered security is still the most effective way to prevent the majority of attacks. Breaches will still happen because no defense is infallible, but WatchGuard’s NSS Labs’ CAWS testing proves that having the layered security of a UTM appliance increases your overall security efficacy, and can even successfully block an attack when one layer of security misses. — Corey Nachreiner, CISSP (@SecAdept)

Locky Ransomware- Daily Security Byte EP. 222

If you only watch the Daily Security Bytes, but don’t read the blog, you may have missed our recent written post on the Locky ransomware. Today’s episode quickly summarizes this post and why you should read it to make sure you’ve configured the WatchGuard defenses that can keep this kind of threat off your network.

(Episode Runtime: 2:24)

Direct YouTube Link: https://www.youtube.com/watch?v=zJcM3CrZV6s

EPISODE REFERENCES:

— Corey Nachreiner, CISSP (@SecAdept)

Glibc Helps Hackers Pop Linux – Daily Security Byte EP. 217

Glibc is the standard C library that ships with mosts version of Linux. It includes many functions that handle the common tasks programs might need, such as looking up IP addresses associated with domain names. This week, Google and Red Hat researchers disclosed a serious vulnerability in this common library, which could allow remote attackers to execute code on your Linux machines. Watch today’s Byte to learn more about this issue, and what computers or devices it might affect.

(Episode Runtime: 3:26)

Direct YouTube Link: https://www.youtube.com/watch?v=j72tvt2Pfjk

EPISODE REFERENCES:

— Corey Nachreiner, CISSP (@SecAdept)

OpenSSL DSA Vulnerability – Daily Security Byte EP. 209

Last week, the OpenSSL team fixed a vulnerability that could allow attackers to get the key used to encrypt your HTTPS or SSL connections. Watch today’s video to learn a bit more about this vulnerability, the update, and how WatchGuard products are affected.

(Episode Runtime: 3:17)

Direct YouTube Link: https://www.youtube.com/watch?v=I8yBGcTGtqM

EPISODE REFERENCES:

— Corey Nachreiner, CISSP (@SecAdept)

Don’t Be ‘fraid of No GHOST; Glibc Vulnerability

GHOST VulnerabilityDuring the blog downtime, observant security practitioners probably read about a serious new vulnerabilities called GHOST, which affects all Linux-based systems to some extent. I actually covered GHOST already, in one of my Daily Security Bytes, but you may have missed it during the downtime. Let me recap the issue here.

GHOST is the name Qualys gave to a newly reported security vulnerability in the very common glibc component that ships with almost all Linux-based software and hardware. If you haven’t heard of glibc, it’s the common GNU C library which contains functions that many Linux program rely on to do common task (such as looking up IP addresses). In a routine audit, Qualys researchers found that part of the gethostbyname() function suffers from a buffer overflow flaw that attackers can use to execute code on your Linux systems.

Because many different Linux application may (or may not) use this glibc function to look up IP addresses, this flaw might get exposed through almost any network service or package. Qualys specifically designed a Proof-of-Concept (PoC) exploit against the Exim email server, which attackers can exploit just by sending email, but they warn that many other Linux packages use the vulnerable function. Some potentially affected packages include:

  • apache
  • cups
  • dovecot
  • gnupg
  • isc-dhcp
  • lighttpd
  • mariadb/mysql
  • nfs-utils
  • nginx
  • nodejs
  • openldap
  • openssh
  • postfix
  • proftpd
  • pure-ftpd
  • rsyslog
  • samba
  • sendmail
  • sysklogd
  • syslog-ng
  • tcp_wrappers
  • vsftpd
  • xinetd
  • WordPress

That said, the  size of the buffer being overwritten is very limited; at only four to eight bytes. This makes it very challenging to actually exploit this flaw in many cases. So while quite a few packages may use the vulnerable function, not all of them actually pose a real-world risk.

It turns out that this particular glibc flaw was discovered and patched over two years ago. If you have glibc 2.18 or higher, you’re not affected. However, at the time it was patched the flaw was considered a bug rather than a security vulnerability, so many Linux distributions didn’t port the glibc update to their distro.

A quick way to check the glibc version on your Linux systems is to type the following command:

ldd --version

If that reports a version lower than 2.18, you need to upgrade. If you’re interested, this blog post has a lot more good information about testing for the flaw. The good news is every major Linux distribution has since updated. If you run Linux systems (especially public servers), I recommend you get your distro’s latest updates to fix this vulnerability.

Also, keep in mind that many hardware devices (often known as the Internet of Things) are actually embedded linux systems, which may need updates as well. Not to mention, some administrators may run Linux software ports on Windows and OS X systems as well. In these cases, it’s possible you might have vulnerable versions of glibc on those non-Linux systems.

Does GHOST Affect WatchGuard Products?

You may know that many WatchGuard product are Linux-based systems, and wonder how this flaw affects them. For the most part, this flaw has little to no impact to most of our products, with a few exceptions. Here are the details:

  • WatchGuard XCS appliances – Not Affected.
  • WatchGuard Wireless Access Points – Not Affected.
  • Dimension v1.3 and higher – Not Affected.
  • Dimension v1.2 and lower – Affected, but Dimension should have already auto-updated. The version of Ubuntu shipping with Dimension v1.2 does use a vulnerable glibc package. However, Dimension auto-updates, and downloads Ubuntu’s latest patches. Since Ubuntu released a patch long ago, your Dimension server should already be patched (as long as you didn’t disable auto-updates).
  • WatchGuard XTM appliances – Affected, but not likely exploitable. XTM Fireware does contain the vulnerable version of glibc. HOWEVER, you are only vulnerable to this issue if a Linux service uses the gethostbyname() funtion. For better security, and IPv6 interoperability, our engineers use the newer getaddrinfo() to resolve hostnames, which is not affected by this vulnerability. We have not found any packages using the vulnerable function, so we believe this flaw has little to no real-world impact on our XTM devices. That said, we have already patched our glibc library, and XTM owners will receive this update in the next scheduled Fireware release. If you’d like to know more about the difference between these functions, I recommend you read this post.
  • WatchGuard SSL VPN appliances – AffectedOur SSL VPN appliance does use the vulnerable library, and is affected by this flaw. We have already patched the flaw internally, and are currently scheduling a release vehicle for the update. I’ll update this post when we know a solid date.

So to summarize. If you use Linux systems, be sure to patch them as soon as you can. Most WatchGuard products aren’t really impacted by this flaw, but we recommend you install firmware updates when we release them. If you want to know more about this interesting and wide-spread issue, I’ve included a few references below. — Corey Nachreiner, CISSP (@SecAdept)

GHOST Vulnerability References:

How to Neuter POODLE (New SSL Vulnerability)

Surprise, surprise… Researcher’s have found yet another OpenSSL vulnerability. They’ve named this one POODLE. Silly name, I know, but at least it stands for something—Padding Oracle On Downgraded Legacy Encryption.

Attack POODLE

In short, POODLE is a protocol level cryptography flaw in Secure Sockets Layer version 3 (SSLv3), which is one of the many encryption protocols available to SSL/TLS implementations like OpenSSL, used to encrypt network traffic. While SSL can encrypt any traffic, it’s most commonly associated with secure web communications (HTTPS). SSLv3 is one of the older encryption protocols in OpenSSL’s library, having been around for 18 years or so. Newer protocols like TLS 1.0-1.2 are much more secure, but we’ve kept SSLv3 around for legacy interoperability reasons. Since this new vulnerability allows attackers to decrypt SSLv3 traffic, it’s time we get rid of SSLv3 for good.

The POODLE flaw is fairly complex, and hard to understand without a deeper comprehension of cryptography. If you’d really like to dive into the details, I recommend you read the paper [PDF] by the Google researchers who found the flaw, or check out this detailed explanation. However, here are the basics:

  1. First, this vulnerability requires a Man-in-the-Middle (MitM) attack to succeed. An attacker can only perform it if he can intercept traffic between you and the SSL server. Performing MitM attacks can range from extremely difficult to trivial, depending on the circumstances. For instance, if you join an unsecured WiFi network, attackers on the same network can quite easily intercept your traffic, whereas intercepting Internet traffic is exceptionally more difficult, and typically requires ISP level interception (or at least DNS poisoning) to pull off.
  2. Next, this attack only works against SSLv3 encrypted traffic, so the attacker needs to somehow force you to use it. This is a much easier hurdle for attackers to overcome. The SSL/TLS protocol includes a “downgrade” feature that allows SSL clients and servers to negotiate which encryption protocol they agree on, depending on what they both support. With a MitM attack, the attacker can intercept and manipulated the negotiations to ensure your browser and the server settle on SSLv3 encryption.
  3. At this point, an attacker can take advantage of the SSLv3 flaw (which is essentially a vulnerability in how SSLv3’s CBC cipher suites use padding) to decrypt certain bytes of your secured traffic. Again, see the paper if you are interested in the technical and mathematical detail. However, there are some caveats here. Basically, the educated guesses used in this attack will only work 1 in 256 times.  So this attack requires the same data be sent over newly created SSLv3 connection hundreds of times. Forcing hundreds of requests is easy when targeting web browsers, since the MitM attack allows the attacker to inject malicious javascript into your web session. This javascript allows the attacker to silently force your browser to do what he needs. However, there are many other clients that use SSL/TLS to encrypt communications, including VPN clients, and apps on your mobile device. Since this attack relies on malicious javascript, attackers can’t easily exploit it against non-browser SSL clients. In any case, once this attack succeeds in decrypting one byte, it’s trivial for the attacker to decrypt the rest of your secure message.
  4.  So what can attackers do by decrypting SSL encrypted web sessions? Most likely, they’d leverage this flaw to try to intercept your encrypted HTTP session cookie. This essentially allows them to hijack your secure web sessions, and do anything you could do on the particular secure site you’re visiting. They wouldn’t obtain your passwords, but they’d have access to your secure web account.

While this sounds pretty bad, and it can be when the attack succeeds, the mitigating factors mentioned above really lessen the severity of this flaw. MitM attacks are not trivial to pull off in most cases, and this exploit’s javascript requirement means it can only easily target web browsers, not other SSL-based clients. Furthermore, if either end (client or server) disables SSLv3, the attack is dead in the water. In fact, NIST only assigns this vulnerability (CVE-2014-3566) a CVSS severity rating of 4.3, which is on the lower medium range of their severity scale. Though many of the media outlet reporting on this flaw have made it sound extremely dangerous, I would only give it a medium severity. It’s definitely something you want to mitigate, but it is not nearly as dangerous as the Heartbleed and Shellshock flaws the media has compared it to.

How to Protect Yourself from POODLE:

Simply put, disable SSLv3!

SSLv3 is an antiquated and broken encryption protocol. Every modern browser and SSL client supports much more recent encryption options. Disabling SSLv3 is the only way to completely protect yourself.

That said, some organizations may still use some legacy web applications, especially ones that require Internet Explorer (IE) 6 running on XP, which depend on SSLv3. Frankly, it’s time you get rid of those applications. In order to quantify today’s minimal SSLv3 usage, CloudFlare monitored all their customers’ traffic and found only 0.09% of it was SSLv3. When monitoring only secure web (HTTPS) traffic, SSLv3 usage jumped to 0.65%, but that’s still a tiny fraction of web traffic. We recommend you help bring this number to zero by getting rid of SSLv3 in your organization

So how do you disable SSLv3? There are two sides to the equation—the server and the client. You only have to disable one side for the attack to fail.

Since this attack targets clients, and seems to primarily affect web browsers, I recommend you disable SSLv3 in your browsers first. All popular web browsers have configuration settings that allow you to do so. The folks at Zmap.io have kindly provided an instruction page detailing how to disable SSLv3 in the popular browsers; check it out. Furthermore, most browser vendors have promised to disable SSLv3 by default in their next software release. Once you have disabled SSLv3 in your browser, attackers cannot leverage this flaw to decrypt your traffic, even if you connect to a web server that still has SSLv3 enabled.

That said, you also should disable SSLv3 on any servers you run, just to help protect the rest of the world against this flaw. The creators of OpenSSL have released an update that fixes this vulnerability (and three others). Besides allowing you to disable SSLv3 on your server, the latest version of OpenSSL supports a feature called TLS_FALLBACK_SCSC, which essentially prevents MitM attackers from forcing clients to downgrade to a certain encryption protocol. Many other Linux distributions and SSL implementations have also released updates. Go get them.

As an aside, once you’ve disabled SSLv3 in your browsers and servers, you can check the results using the following sites:

Are WatchGuard Products Affected by POODLE?

In short, yes.

WatchGuard appliances use OpenSSL and are affected by this vulnerability to varying degrees. The impacted products include:

  • XTM appliances – WatchGuard’s web-based user interfaces (UI), whether the administrative interface or the VPN client portal, do support SSLv3, and are vulnerable to this. However, you can mitigate this flaw by limiting exposure to the Web UI. There is no reason to allow Internet users to access that administrative interface. Also, our SSL VPN clients do NOT support SSLv3. So mobile VPN connections are not affected. We are making updates to our XTM firmware to disable SSLv3 by default.
  • XCS appliances – The XCS’s Web UI does support SSLv3 by default. However, you can disable it for the Web UI, and should do so. Our mail engine does also support SSLv3, and you can’t currently disabled it in the mail engine. That said, this exploit primarily targets web browsers, so the exposure in the mail engine should be low. In any case, we are making changes to the XCS firmware to disable SSLv3.
  • SSL VPN appliances – The SSL VPN appliances administrative Web UI uses SSLv3, and your currently can’t disable it. However, you can limit exposure simply by not allowing external access to the Web UI. As far as client VPN connections, you can disable SSLv3 in the Manage System => Device Setting page. Doing so ensures attackers can’t exploit this flaw to intercept and decrypt mobile SSL VPN traffic. We will release and update to disable SSLv3 in the Web UI.

This vulnerability’s impact to our appliances is relatively low. Nonetheless, WatchGuard will release updated versions for all affected software and devices that are under support. We are currently planning all these releases, and we will update this post as the dates and releases become available. In any case, if you limit access to the web-based administration interfaces on your WatchGuard appliances, the vulnerability poses you little risk. Furthermore, if you disable SSLv3 in your browser, attackers can’t even leverage it against you, whether or not the appliance uses SSLv3.

To summarize, POODLE is a big enough issue that you should definitely disable SSLv3 in all your browsers and servers as soon as you can. However, despite the wide and alarming coverage of this issue, it does not pose a huge, real-world risk to most users. If you update your browsers, and avoid unsecured WiFi connections, POODLE will likely not bite, and is easy to neuter. — Corey Nachreiner, CISSP (@SecAdept)

 

How to Neuter POODLE (New SSL Vulnerability)

Surprise, surprise… Researcher’s have found yet another OpenSSL vulnerability. They’ve named this one POODLE. Silly name, I know, but at least it stands for something—Padding Oracle On Downgraded Legacy Encryption.

Attack POODLE

In short, POODLE is a protocol level cryptography flaw in Secure Sockets Layer version 3 (SSLv3), which is one of the many encryption protocols available to SSL/TLS implementations like OpenSSL, used to encrypt network traffic. While SSL can encrypt any traffic, it’s most commonly associated with secure web communications (HTTPS). SSLv3 is one of the older encryption protocols in OpenSSL’s library, having been around for 18 years or so. Newer protocols like TLS 1.0-1.2 are much more secure, but we’ve kept SSLv3 around for legacy interoperability reasons. Since this new vulnerability allows attackers to decrypt SSLv3 traffic, it’s time we get rid of SSLv3 for good.

The POODLE flaw is fairly complex, and hard to understand without a deeper comprehension of cryptography. If you’d really like to dive into the details, I recommend you read the paper [PDF] by the Google researchers who found the flaw, or check out this detailed explanation. However, here are the basics:

  1. First, this vulnerability requires a Man-in-the-Middle (MitM) attack to succeed. An attacker can only perform it if he can intercept traffic between you and the SSL server. Performing MitM attacks can range from extremely difficult to trivial, depending on the circumstances. For instance, if you join an unsecured WiFi network, attackers on the same network can quite easily intercept your traffic, whereas intercepting Internet traffic is exceptionally more difficult, and typically requires ISP level interception (or at least DNS poisoning) to pull off.
  2. Next, this attack only works against SSLv3 encrypted traffic, so the attacker needs to somehow force you to use it. This is a much easier hurdle for attackers to overcome. The SSL/TLS protocol includes a “downgrade” feature that allows SSL clients and servers to negotiate which encryption protocol they agree on, depending on what they both support. With a MitM attack, the attacker can intercept and manipulated the negotiations to ensure your browser and the server settle on SSLv3 encryption.
  3. At this point, an attacker can take advantage of the SSLv3 flaw (which is essentially a vulnerability in how SSLv3’s CBC cipher suites use padding) to decrypt certain bytes of your secured traffic. Again, see the paper if you are interested in the technical and mathematical detail. However, there are some caveats here. Basically, the educated guesses used in this attack will only work 1 in 256 times.  So this attack requires the same data be sent over newly created SSLv3 connection hundreds of times. Forcing hundreds of requests is easy when targeting web browsers, since the MitM attack allows the attacker to inject malicious javascript into your web session. This javascript allows the attacker to silently force your browser to do what he needs. However, there are many other clients that use SSL/TLS to encrypt communications, including VPN clients, and apps on your mobile device. Since this attack relies on malicious javascript, attackers can’t easily exploit it against non-browser SSL clients. In any case, once this attack succeeds in decrypting one byte, it’s trivial for the attacker to decrypt the rest of your secure message.
  4.  So what can attackers do by decrypting SSL encrypted web sessions? Most likely, they’d leverage this flaw to try to intercept your encrypted HTTP session cookie. This essentially allows them to hijack your secure web sessions, and do anything you could do on the particular secure site you’re visiting. They wouldn’t obtain your passwords, but they’d have access to your secure web account.

While this sounds pretty bad, and it can be when the attack succeeds, the mitigating factors mentioned above really lessen the severity of this flaw. MitM attacks are not trivial to pull off in most cases, and this exploit’s javascript requirement means it can only easily target web browsers, not other SSL-based clients. Furthermore, if either end (client or server) disables SSLv3, the attack is dead in the water. In fact, NIST only assigns this vulnerability (CVE-2014-3566) a CVSS severity rating of 4.3, which is on the lower medium range of their severity scale. Though many of the media outlet reporting on this flaw have made it sound extremely dangerous, I would only give it a medium severity. It’s definitely something you want to mitigate, but it is not nearly as dangerous as the Heartbleed and Shellshock flaws the media has compared it to.

How to Protect Yourself from POODLE:

Simply put, disable SSLv3!

SSLv3 is an antiquated and broken encryption protocol. Every modern browser and SSL client supports much more recent encryption options. Disabling SSLv3 is the only way to completely protect yourself.

That said, some organizations may still use some legacy web applications, especially ones that require Internet Explorer (IE) 6 running on XP, which depend on SSLv3. Frankly, it’s time you get rid of those applications. In order to quantify today’s minimal SSLv3 usage, CloudFlare monitored all their customers’ traffic and found only 0.09% of it was SSLv3. When monitoring only secure web (HTTPS) traffic, SSLv3 usage jumped to 0.65%, but that’s still a tiny fraction of web traffic. We recommend you help bring this number to zero by getting rid of SSLv3 in your organization

So how do you disable SSLv3? There are two sides to the equation—the server and the client. You only have to disable one side for the attack to fail.

Since this attack targets clients, and seems to primarily affect web browsers, I recommend you disable SSLv3 in your browsers first. All popular web browsers have configuration settings that allow you to do so. The folks at Zmap.io have kindly provided an instruction page detailing how to disable SSLv3 in the popular browsers; check it out. Furthermore, most browser vendors have promised to disable SSLv3 by default in their next software release. Once you have disabled SSLv3 in your browser, attackers cannot leverage this flaw to decrypt your traffic, even if you connect to a web server that still has SSLv3 enabled.

That said, you also should disable SSLv3 on any servers you run, just to help protect the rest of the world against this flaw. The creators of OpenSSL have released an update that fixes this vulnerability (and three others). Besides allowing you to disable SSLv3 on your server, the latest version of OpenSSL supports a feature called TLS_FALLBACK_SCSC, which essentially prevents MitM attackers from forcing clients to downgrade to a certain encryption protocol. Many other Linux distributions and SSL implementations have also released updates. Go get them.

As an aside, once you’ve disabled SSLv3 in your browsers and servers, you can check the results using the following sites:

Are WatchGuard Products Affected by POODLE?

In short, yes.

WatchGuard appliances use OpenSSL and are affected by this vulnerability to varying degrees. The impacted products include:

  • XTM appliances – WatchGuard’s web-based user interfaces (UI), whether the administrative interface or the VPN client portal, do support SSLv3, and are vulnerable to this. However, you can mitigate this flaw by limiting exposure to the Web UI. There is no reason to allow Internet users to access that administrative interface. Also, our SSL VPN clients do NOT support SSLv3. So mobile VPN connections are not affected. We are making updates to our XTM firmware to disable SSLv3 by default.
  • XCS appliances – The XCS’s Web UI does support SSLv3 by default. However, you can disable it for the Web UI, and should do so. Our mail engine does also support SSLv3, and you can’t currently disabled it in the mail engine. That said, this exploit primarily targets web browsers, so the exposure in the mail engine should be low. In any case, we are making changes to the XCS firmware to disable SSLv3.
  • SSL VPN appliances – The SSL VPN appliances administrative Web UI uses SSLv3, and your currently can’t disable it. However, you can limit exposure simply by not allowing external access to the Web UI. As far as client VPN connections, you can disable SSLv3 in the Manage System => Device Setting page. Doing so ensures attackers can’t exploit this flaw to intercept and decrypt mobile SSL VPN traffic. We will release and update to disable SSLv3 in the Web UI.

This vulnerability’s impact to our appliances is relatively low. Nonetheless, WatchGuard will release updated versions for all affected software and devices that are under support. We are currently planning all these releases, and we will update this post as the dates and releases become available. In any case, if you limit access to the web-based administration interfaces on your WatchGuard appliances, the vulnerability poses you little risk. Furthermore, if you disable SSLv3 in your browser, attackers can’t even leverage it against you, whether or not the appliance uses SSLv3.

To summarize, POODLE is a big enough issue that you should definitely disable SSLv3 in all your browsers and servers as soon as you can. However, despite the wide and alarming coverage of this issue, it does not pose a huge, real-world risk to most users. If you update your browsers, and avoid unsecured WiFi connections, POODLE will likely not bite, and is easy to neuter. — Corey Nachreiner, CISSP (@SecAdept)

 

WatchGuard Releases Appliance Updates to Fix OpenSSL Flaws

WatchGuard has released several important updates to software for all product lines over the past couple of weeks to address reported vulnerabilities. Last month the OpenSSL team released an update for their popular SSL/TLS package, which fixes six security vulnerabilities in their product, including a relatively serious Man-in-the-Middle (MitM) flaw. More details about these vulnerabilities and their impact are available at the WatchGuard Security Center. If you are not already signed up, we recommend that you subscribe to the blog to get regular updates about security vulnerabilities, WatchGuard products, and general security news.

Here are the releases that have been posted to patch the vulnerable version of OpenSSL.  As always, maintenance releases also include many significant bug fixes. Full details are listed in the Release Notes for each release.

  • 11.3.8 for e-Series devices
  • 11.6.8 for XTM 21,22,and 23 devices
  • 11.7.5 for XTM devices
  • 11.8.4 for XTM and Firebox T10 devices, which is also localized into all of the WatchGuard supported languages.
  • 11.9.1 for XTM and Firebox T10 devices
  • Hotfixes for version 9.2 and 10.0 for XCS appliances
  • SSL 3.2 Update 2 for SSL 100 and 560 appliances.

Other highlights in the new Fireware 11.9.1 release include:

  • Support for default gateway on different subnet
  • Several improved warning and informational messages throughout the product

More information including screenshots are available in the What’s New presentation.

Do These Releases Pertain to Me?

The OpenSSL patch is available for all e-Series, XTM appliances, and Firebox T10. Please choose the version that is relevant for your environment and devices. Upgrade to 11.9.1 to get the latest enhancements to the product.

How Do I Get the Release?

e-Series, XTM, and Firebox appliances owners who have a current LiveSecurity Service subscription can obtain updates without additional charge by downloading the applicable packages from the Articles & Software section of WatchGuard’s Support Center. To make it easier to find the relevant software, be sure to uncheck the “Article” and “Known Issue” search options, and press the Go button. Select the appropriate downloads for your devices. Please read the Release Notes before you upgrade, to understand what’s involved.

If you need support, please enter a support incident online or call our support staff directly. (When you contact Technical Support, please have your registered Product Serial Number, LiveSecurity Key, or Partner ID available.)

  • U.S. End Users: 877.232.3531
  • International End Users: +1.206.613.0456
  • Authorized WatchGuard Resellers: +1.206.521.8375

Don’t have an active LiveSecurity subscription for your XTM appliance? It’s easy to renew. Contact your WatchGuard reseller today. Find a reseller ?

OpenSSL Patches Six Vulnerabilities, Including a MitM Flaw

OpenSSL CCS InjectionToday, the OpenSSL team released a critical update for their popular SSL/TLS package, which fixes six security vulnerabilities in their product, including a relatively serious Man-in-the-Middle (MitM) flaw. If you use OpenSSL, you should read up on these issues and update OpenSSL immediately. WatchGuard products, like many others that use OpenSSL, are affected by these issues to different extents. Our engineers are diligently working to release patches for these flaws as soon as possible.

OpenSSL is a very popular implementation of the SSL/TLS cryptography protocols, used to encrypt many network communications, including secure web communications. This week, the OpenSSL team released an update that fixes six vulnerabilities, including some publicly reported ones. Combined, the flaws affect all current versions of OpenSSL to some extent.

The flaws differ technically, and in scope and impact. For instance, one is a buffer overflow flaw that could allow attackers to execute code, assuming you use a particular OpenSSL feature (DTLS), while another allows attackers to crash OpenSSL, resulting in a Denial of Service (DoS) situation. However, the flaw recieving the most attention is a MitM vulnerability involving OpenSSL’s ChangeCipherSpec functionality. In short, if an attacker can get between a client and server, both of which have vulnerable versions of OpenSSL, he can exploit this flaw to decrypt SSL communications.

While this sounds fairly serious, there are a number of mitigating factor that lessen the severity of the MitM flaw. While all versions of the OpenSSL client are vulnerable to this issue, only two server versions are vulnerable. Also, very few client programs or devices use OpenSSL to make client connections. For instance, the popular browsers aren’t vulnerable to this issue. Finally, the attacker needs to intercept traffic between the client and server for this attack to succeed. Based on these factors, Android devices running on wireless networks pose the most risk, since Android is one of the platforms that uses the OpenSSL client, and wireless networks make it easier to intercept other’s traffic.

In the end, these flaws are not as severe as the previous Heartbleed vulnerability (attackers could exploit that from anywhere, without intercepting traffic). Nonetheless, we highly recommend OpenSSL administrators install the patch immediately, and start looking for updates from other vendors who use OpenSSL in their own products.

WatchGuard Products – (Updated on Jun-17)

Finally, WatchGuard appliances are affected by some of these vulnerabilities (to varying degrees). Although they do not have the same level of impact as Heartbleed, a broader range of OpenSSL versions are vulnerable. WatchGuard products impacted are:

  • Fireware XTM version 11.3 to 11.9 and associated WSM management software
  • SSL VPN clients for XTM
  • XCS
  • SSL VPN appliance

The level of risk is relatively low, but WatchGuard will release updated versions for all affected software for devices that are under support. Unlike Heartbleed, certificates do NOT need to be updated. Our IPS signature team has also released signatures to address one of the vulnerabilities (CVE-2014-3466) in signature set 4.422. Estimated release dates and version numbers for patched firmware, including SSL VPN clients, are:

  • XCS Hotfix – June 10th for version 10, June 11th for version 9. Posted!
  • 11.3.8 – June 12th (for e-Series devices) – Posted
  • 11.6.8 – June 13th (for XTM 21/22/23 devices) – Posted
  • 11.7.5 – June 12th – Posted
  • 11.8.4 – June 23rd – Posted
  • 11.9.1 – June 24th – Posted

These dates are subject to change depending on outcome of Quality Assurance process. WatchGuard will continue to provide latest information about these vulnerabilities and latest status on release dates in this blog post.

— Corey Nachreiner, CISSP (@SecAdept),  Brendan Patterson, CISSP

 

%d bloggers like this: