Ripple20 follow-up #2

Share on linkedin
Share on twitter
Share on facebook
Share on reddit
Share on telegram


Ripple20 follow-up #2: Reverse Engineering on Multiple Levels

Ripple20 disclosure has generated a lot of waves – pun intended! In the 4 months since we disclosed the Ripple20 set of vulnerabilities, we have seen a lot of feedback and discussion around the internet. Many people have asked about our reverse engineering process, which is the focus of this blog post. Many people also asked us if we had source code – we did not.

The process included piecing together a loose historical timeline showing how the original software library changed over time and over branches. We realized we would need to reverse engineer multiple devices, to compare and correlate our findings, and track down the underlying issues. We also realized that we would not be piecing together the whole picture, as this spanned 20 years, with dozens or hundreds of vendors in total over the years, each maintaining their own code base. We quickly came to call the process “reverse engineering archaeology”.

(Photo by Alexander Paukner on Unsplash)

Our first challenge was obtaining the devices or firmwares, quickly followed by additional challenges per-device.

For some of the devices, we had to start our research by reverse engineering the firmware update package format. We did this, for example, with HP printers and their firmware updates. (See our 4-part blog series about unpacking the HP firmware).

For others, we worked with less-common architectures. In one case we had to hack an IDA pro script to produce multiple segments and emulate a non-standard segmentation model.

We ended up working with 7 different Treck instances (including demo code), with multiple versions of some. We found that some vendors made changes to the underlying TCP/IP code, compiled it differently, or used different sections, resulting in end-products with different vulnerabilities and different versions of the same vulnerabilities.

We collected the available information from every device, such as debug symbols and strings, and used debuggers when available, cross-correlating this information between the different devices and binaries. We also used diff-patching to identify the differences between device versions and thereby pinpoint the vulnerabilities in the previous (pre-patch) version.

This led to some zero-day vulnerabilities, variants of an older vulnerability that were not previously identified. In one instance, we identified a vulnerability that we thought had been closed, but when carefully comparing this finding to other devices, we realized that on this device the vendor changed the underlying code and thereby, as a side effect, closed the vulnerability. The other devices had not been changed, and were therefore still vulnerable.

We have presented (and will present – see list at the end of this blog post) this information at various international security industry conferences, describing how we reverse engineered the devices simultaneously, using comparative techniques to confirm each point. We highlighted an interesting outcome of the supply chain ripple effect, and how it can be used to find a vulnerability affecting hundreds of devices for near zero effort, in a form of patch-gapping on steroids.

Security conferences in which we are presenting sessions focusing on the reverse-engineering and research process for Ripple20, as well as Ripple20 in general, are listed here. Links to the presentation slides and videos are added as they are available. These conferences are now all being arranged online; you are invited to join the sessions that are convenient for you.

The full presentation is available for download. Get the full Reverse Engineering Archeology presentation from the CONfidence 2020 conference HERE

 

Get our posts to your Email

Subscribe to our mailing list