Efail: What A Disclosure FAIL That Was!

[This was originally published on RiskBasedSecurity.com.]

Yesterday, news broke of a “critical” vulnerability in OpenPGP and S/MIME, named ‘Efail’ that could lead to an attacker gaining access to plaintext emails. News broke in the form of a dire warning from the Electronic Frontier Foundation warning people to “immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email.” This was, of course, picked up by various news outlets that ran with headlines varying from slightly alarming to factually wrong and embracing the hype. Potentially impacted vendors had to scramble fast, offering commentary on what the disclosure really means. Today, the researchers released the full paper, titled “Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels”.

In short, the researchers outline an attack scenario against OpenPGP and S/MIME that uses a combination of a known cryptographic attack along with mail clients that do not properly implement a MIME parser. The attack they outline requires access to the encrypted emails, which are then manipulated and sent to the victim. When the victim opens the email and decrypts the contents, a back-channel is established through the use of crafted content in an iframe that is not visible to the user. This general type of attack is well-known, but some email clients that implement OpenPGP or S/MIME may not throw the proper warnings when receiving modified cryptographic content. Overall, there is a high degree of complexity required to exploit these flaws, and it requires the victim to be running a vulnerable email client, load the crafted email, and decrypt the contents. There are several components of this disclosure that are rooted in history.

First, the cryptographic attacks against the Cipher Feedback Mode (CFB) (used by OpenPGP) and the Cipher Block Chaining (CBC) mode (used by S/MIME) have been known since 1999, and more generally known before that. Back in 2000, GnuPG implemented protection mechanisms to detect and warn about modified messages called Modification Detection Code (MDC), which will cause any message that has been modified to throw a clear error message warning the user. GnuPG has said that “ancient versions” (the 1.x line) may be susceptible to this, but any modern version (the 2.x line) is not. OpenPGP implemented protection against malleability attacks since 2001 through the use of authenticated encryption (AE) called Modification Detection Code (MDC). In the coming years, OpenPGP will be implementing a stronger form of AE (EAX or OCB depending on key preferences) that will better protect against these types of attacks. Finally, using iframes to hide content in email has long been used in a variety of spoofing attacks as well as companies using the method to track when an email is viewed.

When the actual paper was published, giving technical details of the vulnerability, it confirmed to many what GnuPG had already said and what was also echoed by an Enigmail developer. While there is an issue that may impact users in some situations, the notion that “encrypted email isn’t safe” is certainly false!

This highlights an ongoing problem we see with vulnerability research that is done to garner as much media attention as possible before disclosing details. We wrote about this a couple years ago with the Badlock vulnerability, where like Efail, the hype and claims before disclosure didn’t live up to the disclosure itself. When getting news coverage is more important than protecting organizations, such disclosures ultimately become a great disservice. Imagine organizations that caught wind of this vulnerability last night or this morning and began scrambling to figure out how to roll out mitigations based on the news articles. Is it really helpful if they disabled encrypted email across the entire organization? We don’t think so. Forgoing all integrated email encryption on the slim chance you may be targeted with this attack just doesn’t make sense. In addition to the hype around the vulnerability, there are two more aspects of this disclosure we’d like to point out that further highlight the problem.

First, the paper includes a list of 36 software-based email clients and 12 web-based clients offered via SaaS that are potentially susceptible. In that list, they say that Mailpile version 1.0.0rc2 is affected. However, according to the vendor, they explain why their software isn’t vulnerable due to a list of defense-in-depth measures they had previously implemented (Note: one researcher disagrees with Mailpile, saying they are still vulnerable, and another disagrees with the disagreement). This calls into question the rest of their affected software list, especially on the back of finding out this vulnerability is not critical as claimed. The second aspect of this disclosure that stands out to us is the last paragraph of their introduction, which states:

Responsible disclosure. We have disclosed the vulnerabilities to all affected email vendors, and to national CERTs and our findings were confirmed by these bodies.

The notion that the researchers performed “responsible disclosure” with this vulnerability is frustrating and misleading. As Robert Hansen points out, he didn’t receive a copy of the report from the researches, though another researcher disagrees saying Hansen was contacted in 2017. While they may have reached out to the impacted vendors, they apparently did not give them time to fix in some cases. Further, their contact with the GnuPG developers almost certainly included details that explained not only how they weren’t vulnerable, but why the issue at hand was not as critical as they claimed. Yet, the paper was released after the news articles promoting how critical the issue supposedly was.

Additionally, we are long-time champions of the more accurate term of “coordinated disclosure” over “responsible disclosure”. The idea of responsible disclosure was pushed heavily by Scott Culp at Microsoft back in October, 2001 and has become polarizing among many in Information Security. After years of pushing back, in 2010, Microsoft opted to drop the term as well due to the problems it caused.

There is a fine balance between using the press as an avenue for better awareness of a critical vulnerability. We understand the concept of naming a vulnerability and creating a web site for it as a one-stop clearinghouse for information on it. However, when time is spent doing that in a way that is misleading to organizations and may prompt them to make poor decisions that negatively impact their security posture, researchers must strongly evaluate their actions and improve their process going forward. This type of disclosure is a reminder that discussing disclosure issues, “responsible” or “coordinated”, is relevant and timely.

CryptoCurrency, Blockchain, & SCADA

[This was originally published on RiskBasedSecurity.com in the 2018 Q1 Vulnerability QuickView Report.]

CryptoCurrency and Blockchain: The Latest Rage

Blockchain technology, the foundation of CryptoCurrency such as Bitcoin, Ethereum, and countless others is starting to dominate the news. With the wild ride of Bitcoin prices, where one coin was worth around $19,000 in December, 2017 and a drastic fall in February, 2018 to around $6,900, the financial industry is abuzz with the possibilities. Many would-be entrepreneurs are looking to get involved, while few organizations are monitoring the vulnerabilities in this technology. Risk Based Security has been studying the security aspects for many years and has been collecting the vulnerabilities that range from annoying remote denial of service conditions, to vulnerabilities that allow a single person to mint as many coins as they like, that could lead to serious destabilization of the currency. In the coming months, we will be publishing an extensive blog on the topic of vulnerabilities in the CryptoCurrency market as we continue to aggregate blockchain-based vulnerabilities.

Case Study: SCADA Vulnerabilities

Supervisory Control And Data Acquisition (SCADA) systems are generally considered the systems that run public infrastructure, ranging from power plants and electric grids to damns and spillways. Vulnerabilities in such systems can have catastrophic consequences as we saw in 2015 when Ukraine’s power grid was attacked and portions of the country lost power due to computer intrusion. It is believed to be the first attack against SCADA systems that resulted in wide-scale power outages. Ukraine was attacked in again in 2017 using modified ransomware, that affected a wide variety of systems including radiation monitors at Ukraine’s Chernobyl Nuclear Power Plant. These devastating attacks, according to some experts, are a hint of what may come if SCADA systems are not secured in short order.

2017 saw a significant drop in SCADA disclosures, which led us to speculate in our 2017 End of Year report:

Vulnerabilities in SCADA products only accounted for 1.7% of all reported vulnerabilities in 2017, down from 2.8% in 2016. It is hard to determine if this decline in the number of vulnerabilities found in SCADA products is the result of researchers no longer focusing on SCADA products (e.g. transitioning to IoT or other software) or something else. Based on our knowledge of SCADA, it is hard to imagine it is due to SCADA security improving or vulnerabilities being more difficult to find. Despite this decrease, the potential impact for exploitation of such issues can be far greater than most organizations face.

This year, the first quarter shows an increase in SCADA disclosures, enough to suggest that this may be a new record year.