In June 2020 JSOF, a research lab based in Israel, discovered a set of critical vulnerabilities which they named ‘Ripple20’. These vulnerabilities exist in a TCP/IP code library which is used to provide fundamental network communication functions in embedded systems and IoT devices across a wide range of global industries.
This is not good news for any system that uses the code. The identified issues include four critical vulnerabilities which can allow remote code execution on the affected systems, and several other high-risk issues*. The JSOF site lists 12 sectors they believe are affected, including government and national security, retail devices and the catch-all ‘other IoT devices’. Several advisories list some of the affected vendors, for example the CERT/CC Vulnerability Notes Database , however this is not a full list of affected devices.
One of the biggest issues is use of common components throughout IoT and Industrial Control systems. The library performs low-level connectivity functions needed by most types of connected devices, and the result is that a large number of devices could be affected. Unfortunately, it will not be easy for the device users to identify whether their devices are vulnerable.
Updating to a non-vulnerable version is also not an easy task due to the complex supply chain involved (hence the name ‘Ripple’). The library has been in use for over 20 years, and it is impossible to say how long these vulnerabilities have existed within that time. There will be devices developed years ago using the library, and it may be difficult to obtain updates to the products, especially if the original development company no longer exists. In these cases, an organization may have to purchase new equipment to fix the vulnerabilities.
Even where the product is still supported, updating these types of devices can be complicated, depending on the mechanism used. Many of them do not have a straightforward process to update firmware, if one exists at all. There is also the question of who would pay for the code updates, and which organization performs the updates.
It is an alarming situation, and there is not an easy solution. On their website, JSOF have offered scripts for the identification of products running the affected code, and Nessus have released a plugin which can identify vulnerable devices. However, as soon as identification becomes easier for the good guys, it also becomes easier for those wishing to exploit the issues.
One piece of good news is there does not appear to be any exploits in the wild. Following the widespread publication of the issues that may not last long and it is in everyone’s interest to start looking at this now. Users of potentially affected devices can protect themselves as far as possible by using network separation and following general security good practice. Whist this won’t remove the issue, reducing the attack surface will lower the chances of being compromised, and give their vendors time to update their solutions.
Guidance on best practice can be found online from a range of sources, including (the EU Agency for Cybersecurity) and the UK’s .
Overall, it may be difficult for an organization to know if they are vulnerable and manage remediation through the complex supply chain. Even if they are not affected by Ripple20, the next vulnerability could impact them and a comprehensive asset register would help ensure the response is swift and effective. These organizations should engage with trusted partners like BSI to identify their assets and engage with their suppliers if they are affected. Our Consultancy and Testing services can help.
Similarly, manufacturers should start to look at their code management practices, understanding their supply chain and how they provide ongoing support for embedded devices. Certification and evaluation can help with this process by providing a framework for best practice. BSI provide a range of evaluation services to assist with this, including the IoT Kitemark and assessments through our NCSC Certified Cyber Lab.
This discovery is likely going to take years to address and may cost a significant amount of money to replace unsupported systems. Hopefully, this issue will be a wake-up call to the industry which triggers positive change and a higher emphasis on security in the supply chain and future-proofing embedded devices.
* For more details of the vulnerabilities, see
