Low
Ripple20 Treck TCP/IP Stack Vulnerabilities
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
Low
(2 users assessed)Very Low
(2 users assessed)Unknown
Unknown
Unknown
Ripple20 Treck TCP/IP Stack Vulnerabilities
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
Description
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.
Add Assessment
Ratings
-
Attacker ValueLow
-
ExploitabilityVery Low
Technical Analysis
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportTechnical Analysis
CVE-2020-11899 (one of the Ripple20 bugs) has now been reported as exploited in the wild as per https://www.cisa.gov/known-exploited-vulnerabilities-catalog, No evidence that other bugs have been exploited though as of the time of writing.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportGeneral Information
Exploited in the Wild
Would you like to delete this Exploited in the Wild Report?
Yes, delete this reportReferences
Related AttackerKB Topic
Miscellaneous
Additional Info
Technical Analysis
Description: On Tuesday, June 16, security firm JSOF published research on a collection of 19 vulnerabilities in a low-level TCP/IP software library developed by Treck, a company that has distributed embedded Internet protocols since the 1990s. The Treck TCP/IP stack is widely used across real-time operating systems and embedded and IoT devices; according to the researchers, the 19 vulnerabilities “affect hundreds of millions of devices (or more),” thanks to the ripple effect of the supply chain. JSOF named the collective set of bugs “Ripple20.”
A summary of JSOF’s research is here, along with a technical whitepaper.
Affected protocols include:
- IPv4
- IPv6
- UDP
- DNS
- DHCP
- TCP
- ICMPv4
- ARP
The 19 vulnerabilities are not equal in their severity and potential impact. JSOF’s researchers have highlighted four vulnerabilities as having potential for remote exploitation:
- CVE-2020-11896: Improper handling of length parameter inconsistency in IPv4/UDP component when handling a packet sent by an unauthorized network attacker. This vulnerability may result in remote code execution. (CVSSv3 score: 10)
- CVE-2020-11897: Improper handling of length parameter inconsistency in IPv6 component when handling a packet sent by an unauthorized network attacker. This vulnerability may result in possible out-of-bounds write. (CVSSv3 score: 10)
- CVE-2020-11898: Improper handling of length parameter inconsistency in IPv4/ICMPv4 component when handling a packet sent by an unauthorized network attacker. This vulnerability may result in exposure of sensitive information. (CVSSv3 score: 9.8)
- CVE-2020-11899: Improper input validation in IPv6 component when handling a packet sent by an unauthorized network attacker. This vulnerability may allow exposure of sensitive information. (CVSSv3 score: 9.8)
Rapid7 Analysis: The Ripple20 vulnerabilities are likely to persist for quite some time. Due to the vulnerable library’s low-level integration and wide reach, it is probable that many device vendors may not supply patches at all, especially for obsolete or unsupported devices. That said, the practical attacker value of this suite of vulnerabilities is, on the whole, relatively low. This is in large part because of the lack of attack scalability: Each attack will, in all likelihood, need to be tailor-made for the target device, and even the value of targeting specific devices is heavily dependent on device capabilities and the context in which that device is used. An industrial control device, for instance, is undoubtedly a higher-value target for an attacker than a toy that may be affected by the same vulnerability. The Treck TCP/IP stack is geared towards low-resource devices, which makes the Ripple20 vulnerabilities significantly less likely to be targeted in resource-heavy attacks such as crypto-mining or ransomware campaigns.
There are no known public exploits or reports of active exploitation as of Wednesday, June 17, 2020.
Guidance: As a general rule, users are best served by applying detections at the edge and internal network level to filter out malformed TCP/IP packets, IP fragments, and other lesser-used networking features where possible. A set of rules and guidance for filtering and detecting this traffic is available from the CERT CC Github repository.
Treck has recommended that vendors integrating Treck TCP/IP reach out to them to obtain fixes, which are available in Treck TCP/IP 6.0.1.67 or later versions. Customers and end users will need to obtain fixes from their vendor rather than from Treck directly. A number of vendors, including Schneider Electric, Caterpillar, and Rockwell (among others), have reportedly published advisories of their own. If you are a customer of one of the affected vendors, you may want to monitor their public and customer communications for updates.
CISA recommends the following general measures to mitigate risk of exploitation:
- Minimize network exposure for control system devices and systems; ensure that they are not accessible from the Internet.
- Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
- When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.
- Use an internal DNS server that performs DNS-over-HTTPS for lookups.
Project Sonar Analysis
We have made an initial observation with Project Sonar that certain implementations of the Treck HTTP server respond with a Server header of $ProjectRevision: <version>$
, which may correlate with the Treck TCP/IP stack version. Due to the customization possibilities in different products, this may not be a reliable fingerprint, but initial results show these results across a recent Sonar survey of HTTP servers:
625 "$ProjectRevision: 6.0.1.5 $" 235 "$ProjectRevision: 6.0.1.45 $" 102 "$ProjectRevision: 4.0.2.38 $" 41 "$ProjectRevision: 4.7.1.12 $" 34 "$ProjectRevision: 5.0.1.23 $" 31 "$ProjectRevision: 6.0.1.29 $" 23 "$ProjectRevision: 4.7.1.17 $" 23 "$ProjectRevision: 4.2 $" 16 "$ProjectRevision: 4.2.2.12 $" 11 "$ProjectRevision: 4.1.2.11 $" 6 "$ProjectRevision: 5.0.1.5 $" 4 "$ProjectRevision: 6.0.1.46 $" 4 "$ProjectRevision: 4.5.1.10 $" 2 "$ProjectRevision: 6.0.1.60 $" 1 "$ProjectRevision: 5.0.1.31 $" 1 "$ProjectRevision: 4.7.1.26 $" 1 "$ProjectRevision: 4.7.1.24 $" 1 "$ProjectRevision: 4.2.2.5 $"
The top HTML titles returned by these targets are as follows, which appear to correlate with the kinds of devices that would be in the target market segment for the Treck TCP/IP stack.
72 HP Color LaserJet 2600n 41 HP LaserJet P2035n 30 PowerMonitor 1000 26 HP LaserJet 1022n 23 Loading Cisco Interface... 14 HP LaserJet P1505n 13 HP LaserJet Professional M1212nf MFP 12 HP LaserJet Professional P1102w 11 401 Unauthorized 10 Eaton ePDU G3 8 HP LaserJet Professional P1606dn 7 HP LaserJet M1120n MFP 4 SiteSage Gateway Sign-In 3 HP LaserJet 1022nw 3 Eaton - ePDU 2 HP LaserJet P2014n 1 TotalAlert Embedded System 1 PowerMonitor 5000 1 MILLI-Q INTEGRAL 1 Inicio 1 HP LaserJet Professional M1213nf MFP 1 Eaton - ePDU Network Management Card 1 ACUIX IP Login Page 1 1734-AENT/B 100 Mb Ethernet Module
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Fingerprinting Notes
The demo for Treck from August 2006, which can be found at http://www.treck.com/TreckDemo.zip, appears to contain a copy of Treck 4.2.2.13. That seems to jive with version 4.2 being released in February 2006: https://treck.com/treck-tcpip-version-4-2-released-feburary-2006/
If you look at the HTTP server banner that comes from the demo app, you’ll notice that it contains a ProjectRevision tag in the Server: field:
That seems to be the version of Treck that is embedded in the Server field. If we take a look at Shodan results for this, we find a bunch of printers and other weird devices: https://www.shodan.io/search?query=ProjectRevision%3A
I think at least some subset of devices can be fingerprinted by looking for this banner. There is already a fingerprint in Rapid7’s Recog, though it has a note that it’s not clear what this fingerprint means. https://github.com/rapid7/recog/blob/master/xml/http_servers.xml#L2389
Asked the Recog guys if we could get a distribution of versions out of Sonar to correlate. Anyone else agree on this?
More Fingerprinting
So far, the distribution of
$ProjectRevision
HTTP server versions on the internet appears to line up well with actual Treck software releases. Beyond that, the FTP server also seems to be running with the default banner on a lot of hosts, assuming these are not honeypots. See this Shodan query: https://www.shodan.io/search?query=Treck+FTP+serverThe Telnet server responds with only the ‘Will Echo’ configuration on connect, so probably not enough for a general fingerprint:
This just got more interesting. Apparently a lot of vulnerable targets are HP printers, and they all resolve http://fakeurl1234.com, which given the right circumstances, might allow mass-exploitation of them.
https://twitter.com/Yannayli/status/1273525317374787585
I checked the internet Wayback machine, and it looks like Checkpoint may own this domain (they did in 2018), but it’s not clear who owns it today. It is registered through godaddy as of this writing.
https://attackerkb.com/comments/8e0d9578-a0f5-4c35-ab98-b26a6901a13f
Taking a quick look at https://www.jsof-tech.com/ripple20/ , the number of vendor advisories have increased from 2 on the first day to 14 today. Probably worth a fresh evaluation if you haven’t looked since last week to see what technology you have that might be affected.
Based on a quick reading of some of the advisories, a number of vendors that shipped vulnerable versions were not necessarily vulnerable due to how they specifically setup the software. The HP printer advisory stands out to me, given that this target class appears to be the most exposed across various industries: https://support.hp.com/in-en/document/c06640149
Here’s a nice whitepaper from SCADAFence attempting to reproduce these vulnerabilities. Takeaways quoted from the research.
https://blog.scadafence.com/ripple20-mixed-results-in-scadafences-exploitability-lab-tests
Hat tip to JSOF for continuing to follow-up with timely updates on their twitter account: https://twitter.com/JSOF18/status/1279033787154915328