New Features Added to CERT Tapioca Tool

The CERT Coordination Center (CERT/CC) at Carnegie Mellon University this week announced the launch of a new version of the network traffic analysis tool CERT Tapioca. CERT Tapioca was first released in 2014 as a network-layer man-in-the-middle (MITM) proxy virtual machine designed for identifying apps that fail to validate certificates and investigating the content of HTTP and HTTPS traffic. CERT Tapioca has been used to identify Android applications that fail to properly validate SSL certificates and expose users to MitM attacks.

More than one million apps have been checked and over 23,000 of them failed dynamic testing. The tool can be used to analyze network traffic not only on smartphones, but also on IoT devices, computers and VMs. Will Dormann, vulnerability analyst at CERT/CC and developer of CERT Tapioca, on Thursday announced the release of version 2.0, which introduces a graphical user interface and can be installed on multiple Linux distributions, including Red Hat, CentOS, Fedora, Ubuntu, OpenSUSE, and Raspbian.

CERT Tapioca 2.0 also allows users to set up a HOSTAP-compatible Wi-Fi adapter for wireless connectivity, and it can save results from multiple tested systems. In addition to checking HTTPS validation, verifying an application's use of modern cryptography standards, and observing the hosts contacted by an application, Tapioca now allows users to search network traffic for specified strings, such as passwords.

The CERT Tapioca 2.0 source code, along with additional details and usage instructions, are available on GitHub. Related: Kaspersky Releases Open Source Digital Forensics Tool Related: Secureworks Releases Open Source IDS Tools

Related: UK's GCHQ Spy Agency Launches Open Source Data Analysis Tool

100 Million IoT Devices Possibly Exposed to Z-Wave Attack

Researchers have demonstrated that the Z-Wave wireless communications protocol, which is used by more than 100 million Internet-of-Things (IoT) devices, is vulnerable to security downgrade attacks. Z-Wave, a protocol primarily used for home automation, uses low-energy radio waves for wireless communications over distances of up to 100 meters (330 feet). Z-Wave was developed by Zensys in 2001 and in 2008 it was acquired by Sigma Designs, which recently sold it to Silicon Labs for £240 million.

According to the Z-Wave Alliance, an organization dedicated to advancing Z-Wave, the protocol is currently used by 700 companies in over 2,400 IoT and smart home products, including thermostats, locks and home monitoring systems. UK-based Pen Test Partners has conducted an analysis of Z-Wave and discovered that a hacker in range of the targeted devices during the pairing process can launch an attack and crack supposedly secure communications. The researchers demonstrated their findings on a Yale smart lock - they showed how an attacker can unlock a door - but the method, which they have dubbed "Z-Shave," works against any device using Z-Wave.

Z-Wave relies on a shared network key to secure traffic between the controller and the client device when they are paired. The initial version of the pairing process, known as S0, was found to be vulnerable to sniffing attacks back in 2013, which led to the introduction of a more secure process named S2. The problem with S0 is that it protects the network key with a known encryption key (0000000000000000), allowing an attacker in range of the targeted device to intercept communications.

S2 addresses this problem by using stronger encryption, but researchers discovered that an attacker can downgrade the connection from S2 to S0, basically removing the protection. The hacker needs to be present during the initial pairing process to perform the downgrade, but Pen Test Partners pointed out that the attacker could use a battery-powered hacking device that is left outside the targeted property for an extended period of time, waiting for the pairing process to be initialized. "The risk is mitigated as one has to be present during the pairing process, but the Z-Wave RF range is significant.

We're investigating whether it might be possible to de-authenticate a Z-Wave client device, but that's work in progress," researchers explained. It turns out that a variant of this downgrade attack was discovered last year by cybersecurity consulting firm SensePost, but the vendor told experts at the time that this was by design and needed for backwards compatibility. In a blog post published on Wednesday, Silicon Labs assured users that the risk is low and highlighted that it's not aware of any real-world exploitation.

"While it's possible that an attacker could intercept the S0 encrypted key exchange frame and decipher it using the hardcoded key, this is only possible during the initial set-up or reinstallation of the device," Silicon Labs said. "To do this, the attacker would need to be within close proximity of the device during the very moment the device is installed - an extremely small window of opportunity. Furthermore, Z-Wave devices can switch their radio to low power transmission mode during key exchange process to make packet interception attack much more difficult." The company added, "It would not be possible to execute an attack without the homeowner becoming aware because they would receive a warning from the S2 controller during the pairing process."

Related: Many Vulnerabilities Found in OPC UA Industrial Protocol

Related: Hackers Exploit SS7 Flaws to Loot Bank Accounts

Flaws in Open Source Components Pose Increasing Risk to Apps: Study

Open source components have been increasingly used by developers, but failure to patch vulnerabilities in this type of software can pose serious risks. The 2018 Open Source Security and Risk Analysis (OSSRA) report published on Tuesday by Synopsys shows that of the more than 1,100 commercial codebases analyzed by the company last year, 96% contained open source components, the same percentage as the previous year. However, many applications now contain more open source than proprietary code, with the percentage of open source components in the codebases of scanned apps increasing from 36% in 2016 to 57% in 2017.

The study shows that 78% of the examined codebases were plagued by at least one open source vulnerability, compared to 67% in the previous year. The average number of flaws discovered per codebase in 2017 was 64, which represents an increase of 134%. Synopsys noted that more than 4,800 vulnerabilities were found in open source software last year, which is not surprising considering that the total number of flaws recorded by the National Vulnerability Database (NVD) exceeded 14,700, compared to only 6,400 in 2016.

More than half of the vulnerabilities identified during Synopsys' analysis have been classified as "high risk" and 17% of them have been highly publicized (e.g. Heartbleed, Logjam, FREAK, DROWN, POODLE). Logjam was the most common, being found in 11% of codebases.

Another highly publicized security hole, the Apache Struts 2 flaw exploited in the massive Equifax hack (CVE-2017-5638), was found in 33% of the codebases that used Struts. The study is based on data collected from a wide range of sectors, including cyber security, automotive, big data, financial services, enterprise software, healthcare, manufacturing, mobile app markets, and Internet of Things (IoT).

The largest percentage of high risk open source flaws was identified in the applications of Internet and software infrastructure (67%), Internet and mobile apps (60%), virtual reality, gaming and media (50%), and cybersecurity companies (41%). The report from Synopsys also highlights another - often overlooked - major risk associated with open source software, namely license issues. "Open source components are governed by one of about 2,500 known open source licenses, many with obligations and varying levels of restriction.

Failure to comply with open source licenses can put businesses at significant risk of litigation and compromise of IP," the company said in its report. "These license requirements can be managed and complied with only if the open source components governed by those licenses are identified. Just as with security vulnerabilities, it is impossible to manage license compliance risk if the components used aren't identified." Related: Slack Releases Open Source Secure Development Lifecycle Tool

Related: HackerOne Offers Free Service to Open Source Projects