SoylentNews

upstart [soylentnews.org] writes:

████ # This file was generated bot-o-matically! Edit at your own risk. ████

upstart [soylentnews.org] writes in with an IRC submission:

'Ripple20' Bugs Impact Hundreds of Millions of Connected Devices [threatpost.com]:

Share this article:

The vulnerabilities affect everything from printers to insulin pumps to ICS gear.

A series of 19 different vulnerabilities, four of them critical, are affecting hundreds of millions of internet of things (IoT) and industrial-control devices.

The issue is based in the supply chain and code reuse, with the bugs affecting a TCP/IP software library developed by Treck that many manufacturers use. Researchers at JSOF uncovered the faulty part of Treck’s code, which is built to handle the ubiquitous TCP-IP protocol that connects devices to networks and the internet, in the devices of more than 10 different manufacturers—and it’s likely present in dozens more.

Affected hardware includes everything from connected printers to medical infusion pumps and industrial-control gear, according to researchers at JSOF’s research lab. Treck users include “one-person boutique shops to Fortune 500 multinational corporations, including HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors suspected of being of vulnerable in medical, transportation, industrial control, enterprise, energy (oil/gas), telecom, retail and commerce, and other industries,” according to the research.

“The wide-spread dissemination of the software library (and its internal vulnerabilities) was a natural consequence of the supply chain ‘ripple-effect,'” researchers said in a posting [jsof-tech.com] on Tuesday. “A single vulnerable component, though it may be relatively small in and of itself, can ripple outward to impact a wide range of industries, applications, companies and people.”

The flaws, dubbed Ripple20, include four remote code-execution vulnerabilities. If properly exploited, data could be stolen off of a printer, a medical device’s behavior could be tampered with, or industrial control devices could be made to malfunction.

“An attacker could hide malicious code within embedded devices for years. One of the vulnerabilities could enable entry from outside into the network boundaries; and this is only a small taste of the potential risks,” according to JSOF.

Vulnerability Details

The Ripple20 bugs include four critical flaws. These include CVE-2020-11896, with a base score of 10 out of 10 on the CVSS severity scale, which can be triggered by sending multiple malformed IPv4 packets to a device supporting IPv4 tunneling.

“It affects any device running Treck with a specific configuration,” according to JSOF. “It can allow a stable remote code execution and has been demonstrated on a Digi International device. Variants of this issue can be triggered to cause a Denial of Service or a persistent Denial of Service, requiring a hard reset.”

The critical bug tracked as CVE-2020-11897 meanwhile also carried a 10-out-of-10 severity, and is an out-of-bounds write flaw that can be triggered by sending multiple malformed IPv6 packets to a device. It affects any device running an older version of Treck with IPv6 support, and was previously fixed in a routine code change. It can potentially allow stable remote code execution, according to the writeup.

Another critical bug, CVE-2020-11901, ranks 9 out of 10 on the severity scale and can be triggered by answering a single DNS request made from the device. It can allow an attacker to infiltrate the network, execute code and take over the device with one vulnerability, bypassing any security measures.

“It affects any device running Treck with DNS support and we have demonstrated that it can be used to perform remote code execution on a Schneider Electric APC UPS,” according to JSOF. “In our opinion this is the most severe of the vulnerabilities despite having a CVSS score of 9, due to the fact that DNS requests may leave the network in which the device is located, and a sophisticated attacker may be able to use this vulnerability to take over a device from outside the network through DNS cache poisoning, or other methods.”

The last critical bug is CVE-2020-11898, rating 9.1, which is an improper handling of length parameter inconsistency bug in the IPv4/ICMPv4 component, when handling a packet sent by an unauthorized network attacker. It can allow information disclosure.

Other flaws range from high-severity 8.2 bugs (such as CVE-2020-11900, a use-after-free flaw) to low-severity improper input validation issues (such as CVE-2020-11913, rating only 3.7 in severity).

“The other 15 vulnerabilities are in ranging degrees of severity with CVSS score ranging from 3.1 to 8.2, and effects ranging from denial of service to potential remote code execution,” the firm said. “Most of the vulnerabilities are true zero-days, with four of them having been closed over the years as part of routine code changes, but remained open in some of the affected devices (three lower severity, one higher). Many of the vulnerabilities have several variants due to the Stack configurability and code changes over the years.”

Effective exploitation can lead to a host of bad outcomes, the research firm warned, such as remote takeover of devices and lateral movement within the compromised network; broadcast attacks that can take over all impacted devices in the network simultaneously; hiding within an infected device for stealthy recon; and bypassing network address traversal (NAT) protections.

JSOF will offer further details of the vulnerabilities at the Black Hat USA virtual event [threatpost.com] in August.

Jonathan Knudsen, senior security strategist, Synopsys, noted that the Ripple20 disclosures illustrate endemic difficulties in software development.

“First, security must be integrated to every part of software development: From threat modeling during design to automated security testing during implementation, every phase of software development must involve security,” he said via email. “Second, organizations that create software must manage their third-party components. The main reason for the far-reaching effects of the Ripple20 vulnerabilities is that they are vulnerabilities in a network component used by many organizations in many products. Each software development organization must understand the third-party components they are using to minimize the risk that they represent.”

Patches and Mitigation

Treck has issued a patch for use by OEMs in the latest Treck stack version (6.0.1.67 or higher). The challenge now is for those companies to implement it. In addition to advisories from ICS CERT, CERTCC and JPCERT/CC, Intel [intel.com] and HP [hp.com] have also issued alerts.

“While the best response might be to install the original Treck patch, there are many situations in which installing the original patch is not possible,” according to the JSOF analysis. “CERTs work to develop alternative approaches that can be used to minimize or effectively eliminate the risk, even if patching is not an option.”

Because it’s a supply-chain issue, affected products should be able to update themselves, Knudsen added – something that’s not always the norm in the IoT and industrial-control sectors.

“Using secure development practices and managing third-party components will result in fewer, less frequent updates,” he explained. “Nevertheless, something will always go wrong and updates will always be necessary. Systems and devices must be able to update themselves securely, and the manufacturer must make a commitment to maintaining the software for some clearly stated time period.”

Based on CERT/CC and CISA ICS-CERT advisories, if gear can’t be patched, admins should minimize network exposure for embedded and critical devices, ensuring that devices are not accessible from the Internet unless absolutely essential. Also, operational technology networks and devices should be segregated behind firewalls and isolated from any business networks.

Users can also take steps to block anomalous IP traffic, employ pre-emptive traffic filtering, normalize DNS through a secure recursive server or DNS inspection firewall and/or provide DHCP/DHCPv6 security, with features such as DHCP snooping, according to the CERTs.

“The software library spread far and wide, to the point that tracking it down has been a major challenge,” the researchers concluded. “As we traced through the distribution trail of Treck’s TCP/IP library, we discovered that over the past two decades this basic piece of networking software has been spreading around the world, through both direct and indirect use. As a dissemination vector, the complex supply chain provides the perfect channel, making it possible for the original vulnerability to infiltrate and camouflage itself almost endlessly.”

Insider threats are different in the work-from home era. On June 24 at 2 p.m. ET [gotowebinar.com], join the Threatpost edit team and our special guest, Gurucul CEO Saryu Nayyer, for a FREE webinar, “The Enemy Within: How Insider Threats Are Changing.” Get helpful, real-world information on how insider threats are changing with WFH, what the new attack vectors are and what companies can do about it.Please register here [gotowebinar.com] for this Threatpost webinar.

This Week In Security: Bitdefender, Ripple20, Starbucks, And Pwned Passwords [hackaday.com]:

[Wladimir Palant] seems to be on a one man crusade against security problems in security software. The name may not be immediately recognizable, but among his other infamies is originating Adblock Plus, which we have a love-hate relationship with. (Look, surf the net with an adblocker, but disable it for sites you trust and want to support, like HaD).

This week, he announced a rather serious flaw in the Bitdefender [palant.info]. The disclosure starts off with high praise for the Bitdefender: “security-wise Bitdefender Antivirus is one of the best antivirus products I’ve seen so far….” Even with that said, the vulnerability he found is a serious one. A malicious website can trigger the execution of arbitrary applications. The problem was fixed in an update released on the 22nd.

The vulnerability is interesting. First, Bitdefender uses an API that was added to web browsers specifically to enable security software to work without performing man-in-the-middle decryption of HTTPS connections. When a problem is detected, Bitdefender replaces the potentially malicious page with it’s own error message.

Because of the way this is implemented, the browser sees this error message as being the legitimate contents of the requested site. Were this a static page, it wouldn’t be a problem. However, Bitdefender provides an option to load the requested page anyway, and does this by embedding tokens in that error page. When a user pushes the button to load the page, Bitdefender sees the matching tokens in the outgoing request, and allows the page.

This can be exploited through an AJAX call. A malicious webpage makes an XMLHttpRequest call back to the same domain, and manipulates the response so an error message is injected by Bitdefender. Since it’s the same domain, the contents of that response are accessible to the malicious page, meaning the security tokens are leaked. Those tokens can then be used to trigger the launch of Bitdefender’s Safepay browser. That’s not terrible in itself, but the real problem is the fact that the Safepay browser is launched using an attacker provided url. request.send("data:text/html,nada --utility-cmd-prefix=\"cmd.exe /k whoami & echo\""); The spaces don’t get properly escaped, so command line arguments can be injected, leading to arbitrary execution.

Ripple20

JSOF just released part of their research on the Trek TCP/IP stack, [jsof-tech.com] but they’re exploiting this to harvest email addresses, a tactic that I find repugnant, and frankly any security company should as well. Thankfully the PDF is available once you know where to look [jsof-tech.com].

Trek produces an IP stack that can be used as an element of a Real Time OS, or even on embedded devices that lack a full OS. That software stack has been deployed on IoT devices around the world. This is what the JSOF researchers are talking about when they say “the supply-chain factor”. They discovered 19 separate vulnerabilities in this software stack, four of which were critical remote code execution (RCE) problems.

(I feel I must take JSOF to task once more, as they refer to these as zero-day vulnerabilities. While it may have been strictly true that they were zero-days when they were first discovered, the fact that JSOF went through a coordinated disclosure process means that these are no longer zero-day vulnerabilities. This seems like an attempt to hype their research, rather than being based on fact.)

JSOF reached out in response to my criticisms, and made some fair points in their defense. I’ve included their response below.

“JSOf only uses the emails to send a one time single email offering to join our mailing list of all-research and content. Subscribing to the mailing is explicit and a subscriber would have to insert their email again and press subscribe. We have been receiving good feedback to this process.

We believe the description of vulnerabilities as zero-day vulnerabilities correctly depicts the situation at the time of publishing and the current ongoing situation where patches are not available for many devices, many devices remain unpatched, and more vendors and devices are expected to release advisories and patches”

So far, the details have only been released for two vulnerabilities: CVE-2020-11896 and 11898. The first is a RCE and the second an information leak. Both vulnerabilities stem from improper handling of fragmented IP-in-IP tunneled packets [wikipedia.org]. Apparently the target device doesn’t need to have an IP tunnel configured, but it does need to have IP tunneling support. It’s unclear how common or uncommon this configuration is, but as long as fragmentation and tunneling support is present, all that is needed for compromise is a single open UDP port.

When receiving packets, when the length of packet fragments exceeds the length indicated in the packet headers, a function is called to trim the excess received data. It’s possible to manipulate this function such that more data will be processed than is expected. The excess data is copied beyond the end of an allocated buffer, leading to predictable results. There are some clever additional steps needed to actually achieve RCE, so go read the paper for more details.

Interestingly, Cisco just released an advisory [cisco.com] detailing their initial work on triaging the Ripple20 bugs. So far it appears that patches are not yet available for vulnerable Cisco products, which highlights what a challenge this particular set of bugs might be.

Secure Boot Bypass

[Jason A. Donenfeld] of Wireguard fame has discovered a fun flaw [zx2c4.com] in the Linux kernel’s lockdown mode. Kernel lockdown is an extension of the EFI Secure Boot scheme that, among other things, ensures that unsigned kernel modules don’t get loaded, even by root. As you can imagine, it was an uphill battle [zdnet.com] getting that feature in the Linux kernel at all.

The vulnerability is an EFI variable that can be written to, even with a kernel lockdown policy, that inserts an ACPI table. This essentially means injecting code into the pre-boot process, instructing the booting machine to set the kernel lockdown policy to disabled. The humorous part of all of this work is that Donefeld’s test case is loading the Wireguard module. It seems like a lot of work just to get his VPN to load.

Searching a Starbucks API

[Sam Curry] must constantly have his browser’s DevTools window open, because he just happened to notice API calls [samcurry.net] that were being processed while he was purchasing a Starbucks gift card. Being the curious, security minded individual he is, Sam decided to take some time to explore the API that was being used. He quickly determined that the API was using an Internet facing front-end to proxy API calls into the Starbucks internal network. After much trial and error, the following API endpoint was discovered:

/bff/proxy/stream/v1/users/me/streamItems/

web\..\.\..\.\..\.\..\.\..\.\..\.\search\v1\Accounts\

It was never intended to be publicly accessible, but some clever path traversal work made it possible. This endpoint allowed Sam to search through every user in the Starbucks system, all 100 million records.

This did represent quite the problem, so the finding were quickly reported, and fixed within 24 hours. There isn’t any evidence that the vulnerable endpoint was independently discovered or exploited. Sam did net a nice $4,000 bounty for the find.

Pwned Passwords, Version 6

[Troy Hunt] keeps popping up, and this week it’s because he published the sixth iteration of the Pwned Passwords service [haveibeenpwned.com]. He wrote a blog post about the update [troyhunt.com], and the update added over 17 million new passwords. For those of us not familiar with the service, it’s a web page where you can enter your password, and see if it’s been compromised in a data breach. Yes, you read that right, the intention is for you to go enter your password on someone else’s web service. Yes, this is nuts. The r/netsec Reddit thread [reddit.com] has both had a lot of fun [bash.org] with this, and has suggestions for how to use the service without trusting any of Troy’s code.

All kidding aside, the service uses k-anonymity [troyhunt.com] to protect your password. It works like this. Your browser takes the password you enter, generates a SHA1 hash, and then sends the first five characters of that hash to the service. The list of hashes beginning with those five characters is returned, and the code running in your browser checks to see if the full SHA1 is in the returned list. It’s clever, should be safe, and there’s still no way I’m putting an important password into that web site. Instead, I prefer the simple python script put together by [Ben Wiederhake] [github.com]. It’s short and simple enough for all of us to read through the source before running it.

(Editor’s note: I use Pwned Passwords occasionally. It’s good for verifying that your non-critical password(s) aren’t easily crackable. Hackaday1234 passes, for instance, so feel free to use that for forum logins. But your actually important passwords should be unique, long, and randomly generated, and thus don’t even require checking. head -c 8 /dev/urandom | base64 and done.  Security can be very simple if you let it.)

Ripple20: Flaws in Treck TCP/IP Stack Expose Millions of IoT Devices to Attacks [securityweek.com]:

Millions of IoT devices worldwide could be vulnerable to remote attacks due to serious security flaws affecting the Treck TCP/IP stack, Israel-based cybersecurity company JSOF warned on Tuesday.

Treck TCP/IP is a high-performance TCP/IP protocol suite designed specifically for embedded systems. JSOF researchers have discovered that the product is affected by a total of 19 vulnerabilities, which they collectively track as Ripple20 [jsof-tech.com].

The vulnerabilities rated critical and high-severity can be exploited for remote code execution, denial-of-service (DoS) attacks, and for obtaining potentially sensitive information. Exploitation involves sending specially crafted IP packets or DNS requests to the targets, and in some cases it may be possible to launch attacks directly from the internet.

“Ripple20 vulnerabilities are unique both in their widespread effect and impact due to supply chain effect and being vulnerabilities allowing attackers to bypass NAT and firewalls and take control of devices undetected, with no user interaction required,” JSOF said in a report describing Ripple20. “This is due to the vulnerabilities’ being in a low level TCP/IP stack, and the fact that for many of the vulnerabilities, the packets sent are very similar to valid packets, or, in some cases are completely valid packets. This enables the attack pass as legitimate traffic.”

The vulnerable library has been used in devices made by more than 100 organizations, including industrial, medical, smart home, networking, enterprise, retail, energy and transportation systems.

According to JSOF, depending on what the targeted system is used for, exploitation of the vulnerabilities can allow an attacker to maintain access to a network, cause financial damage, cause disruption, or take control of devices (in the case of medical devices this can threaten an individual’s life or health).

The list of vendors that use the Treck TCP/IP stack include BAE Systems, BD, Broadcom, Cisco, Dell EMC, GE, Honeywell, HP, Intel, Lockheed Martin, NASA, NVIDIA, Philips, Rockwell Automation, Schneider Electric, and many others. However, it’s worth noting that researchers have only confirmed the presence of the vulnerabilities in the products of a handful of companies, such as B. Braun, Baxter, Caterpillar, HP, Intel, Schneider, Rockwell, and HCL Technologies.

JSOF says it has been working with several organizations to coordinate the disclosure of the vulnerabilities and patching efforts, including CERT/CC, CISA, the FDA, national CERTs, impacted vendors, and other cybersecurity companies.

Treck has developed patches for the vulnerabilities, but in many cases it’s not easy to deploy them on impacted devices. In some cases, it’s not possible to install the patches and users will need to take steps to minimize the risk of attacks.

JSOF noted that some of the identified security holes were patched years ago by the vendor as a result of routine code changes, but many devices using the Treck library remain impacted. The researchers also pointed out that various code changes and configurations introduce several variants for some of the vulnerabilities.

Treck and some of the affected vendors are working on publishing their own advisories for the Ripple20 vulnerabilities.

UPDATE: Treck [treck.com] and CERT/CC [cert.org] have published their advisories for the Ripple20 vulnerabilities.

UPDATE June 22: Sandia National Labs has been removed from the list of affected organizations.

Related: Urgent/11 Flaws Impact More RTOS Used by Medical, Industrial Devices [securityweek.com]

Related: Antivirus Vendors Patch Bug First Discovered 10 Years Ago [securityweek.com]

View the discussion thread. [disqus.com]

Original Submission