Ripple20 follow-up #1: Continuing research, clarifications, and updates
It’s been a little more than 3 months since the Ripple20 disclosure, and we have been seeing many reactions of different types. A lot of vendor responses, with some good research expanding on our own, as well as some unfortunate fake news. It’s about time to provide a status update, and some clarifications, which we will be uploading in several parts.
These have been busy months for us! While the JSOF research labs have moved on to other research and are currently in the midst of another (unrelated) multi-vendor disclosure process, we are still seeing Ripple20 reactions and dealing with some follow-up and the natural after‑effects of disclosure.
We will begin with a quick numbers update.
At the time of disclosure, we publicized a carefully assembled list of vendors that may have been affected. The original list only contained vendors that had been listed in an internal document shared between CERT/CC, ICS-CERT and ourselves; their responses are recorded. This list has been updated from time to time, since the confirmations and refutations are steadily arriving.
As of the beginning of October, 2020, there are 34 vendors with a status of ‘Confirmed’ (4 are low risk). 67 vendors are still with a status of ‘Pending’. This is unfortunate, since by not responding, these vendors are only creating uncertainty.
In general, we have seen many responses, of all types. For the most part, they have fallen into one of the following categories.
- We’ve seen detailed responses from independent research groups, with some feedback including good situation breakdown and efforts to fingerprint the Treck stack correctly.
- We’ve seen a lot of vendor responses and advisories, with varying levels of detail and at different paces. Of the many advisories we have seen (and that are linked on our webpage), we believe a shoutout is due to the following vendors for particularly good responses and insights:
- Rockwell Automation :For their great advisory and timely response, which included an excellent breakdown and display for their customers. Their advisory is a concise, informative summary of the situation, with no fluff and no unusual wording to make the list look larger or smaller or more confusing than it really is.
- Green Hills Software: For their overall approach, combining secure design with removal of any unnecessary features, which has reduced the risk and potential impact of the Ripple20 vulnerabilities to the bare minimum, and should serve as a model for other vendors. It is our understanding that this isolation is government-mandated and must also be implemented properly by the end users of the operating system in order to be effective.
- Carestream: For consistently recommending secure setups for their clients, including not connecting devices directly to the hospital network when not required. This simple recommendation has saved them a great deal of trouble, and is certain to do so again in the future.
Note that we are in no way affiliated with or endorse any of these companies. They are simply instances of outstanding responses that we noticed and believe they should be mentioned. Many other vendors had good responses as well.
- There has been some over-the-top hype and exaggeration. For example, one publication stated that there were many billions of vulnerable devices, with over 500 vendors acknowledging vulnerability. They clearly multiplied our painstakingly assembled numbers by a factor of 10 or more, in the hopes of increasing the impact. This was not necessary – the real numbers are formidable enough, there is no need for artificial inflation.
- We also encountered the opposite – companies maintaining that the risks were minimal or non-existent, with almost no vulnerable devices to be found, and privately advising vendors not to install the patches released by different vendors, that they were not necessary, in blatant contradiction of the vendor statements. This is unfortunate, since these posts are mostly based on a misunderstanding of the vulnerabilities and the complexities of the supply chain, and can potentially lead vendors to leave themselves open to significant threats. Someone wrong on the internet turned into an unfortunate distraction.
(Source:XKCD)We emphasized in our communications that the vulnerabilities inherent in the Treck stack affect each device differently, due to the high variability of the stack, device, and configuration combinations and the many code branches. This was very clear to us, and more to the point, to the vendors. It is unfortunate that others seem to have misunderstood, or did not bother to read all the released material in depth.
The bottom line? Go to the source. Place your trust in the device manufacturer for device-specific recommendations. They are the ones you are paying for the devices and for information regarding those devices, and they are the ones who would be held liable if they make mistakes.
The vulnerabilities we discovered require skill to exploit, but the devices mostly lack exploit mitigations and the process of exploitation is mostly relatively straightforward, potentially causing immense damage in some cases. It is simply not worth the risk to minimize or ignore these findings, just as it is does not makes sense to panic needlessly. Asset owners are usually very good at conducting a balanced risk-analysis with the help of vendors and partners. We encourage asset owners to reach out to us with specific questions.
It is also important to note that, given our findings to date, there are very likely other vulnerabilities to be found in the stack. We did not analyze the entire stack; it’s too massive and complex to tackle all at once, without source code, as an independent unpaid project. We hope that our findings will prompt additional in-house or independent reviews by both vendors and Treck. It’s simply a matter of time and effort before more vulnerabilities are discovered.
Vendors must also be conscientious to update their 3rd party software and install the latest versions and patches. Keeping an old, out of date version of any communication stack is simply not secure, especially a complex stack like TCP/IP. Aside from the unknown, not-yet-discovered vulnerabilities, there are almost certainly other vulnerabilities that were fixed over the years, and would provide a known point-of-risk if not addressed.
Continue to follow our blog postings for more information and updates about Ripple20 and other security issues as they become relevant.
We encourage anyone reading these posts to reach out, share their data and experience, and get additional information, as relevant. We are always happy to share information for good-faith security research purposes.
Contact us at: Ripple20@jsof-tech.com
