Ripple20 Treck TCP/IP Stack Vulnerabilities

Treck IP stack implementations for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by JSOF, who calls them Ripple20. A summary of JSOF’s research is here, along with a technical whitepaper. See the Rapid7 Analysis tab for further details.

Recent assessments:

busterb at June 17, 2020 6:03pm UTC reported:

This may be interesting to exploit when one has a particular device in mind, and it provides some sort of useful access or control, but there is not going to be an apocalypse of Ripple20 exploits for a few reasons:

• Every target device has to have a tailor-made exploit written for it, outside of a DoS.

• There is no low-hanging fruit here for actual code execution. Those hundreds of vendors are going to have hundreds of ways they integrated this thing, though you may find some commonalities when folks use the same board support package (BSP) for reference designs.

• Getting malformed packets into a target device remotely is a lot harder than you’d think these days. Often times, this might as well be considered a local attack, since a lot of edge and intermediate devices will discard many of the malformed packets involved here. That’s why I’m tagging ‘Requires physical access’, because it’s practically the case.

There’s a reason why devices like this have been off-limits for vuln scans and penetration tests for years. It’s because the vendors and users knew their stacks were fragile. This is just reality the infosec world is finally catching up. This isn’t the first exploration of an embedded stack with problems, and it will most definitely not be the last. Whether this makes a change in the industry is a bigger question.

gwillcox-r7 at March 07, 2022 5:13pm UTC reported:

This may be interesting to exploit when one has a particular device in mind, and it provides some sort of useful access or control, but there is not going to be an apocalypse of Ripple20 exploits for a few reasons:

• Every target device has to have a tailor-made exploit written for it, outside of a DoS.

• There is no low-hanging fruit here for actual code execution. Those hundreds of vendors are going to have hundreds of ways they integrated this thing, though you may find some commonalities when folks use the same board support package (BSP) for reference designs.

• Getting malformed packets into a target device remotely is a lot harder than you’d think these days. Often times, this might as well be considered a local attack, since a lot of edge and intermediate devices will discard many of the malformed packets involved here. That’s why I’m tagging ‘Requires physical access’, because it’s practically the case.

There’s a reason why devices like this have been off-limits for vuln scans and penetration tests for years. It’s because the vendors and users knew their stacks were fragile. This is just reality the infosec world is finally catching up. This isn’t the first exploration of an embedded stack with problems, and it will most definitely not be the last. Whether this makes a change in the industry is a bigger question.

Assessed Attacker Value: 2
Assessed Attacker Value: 2Assessed Attacker Value: 1