Script for detecting vulnerable TCP/IP stacks released

Just as ICS-CERT published a new advisory detailing four new vulnerabilities in the Treck TCP/IP stack, Forescout released an open-source tool for detecting whether a network device runs one of the four open-source TCP/IP stacks (and their variations) affected by the Amnesia:33 vulnerabilities.

detecting vulnerable TCP/IP stacks

New vulnerabilities in the Treck TCP/IP stack

Reported by Intel researchers and confirmed by Treck Inc., four newly discovered vulnerabilities affect Treck TCP/IP stack Version 6.0.1.67 and prior:

Of those, CVE-2020-25066 is the most critical, as it could allow an attacker to cause a denial-of-service condition, but may also result in arbitrary code execution.

“The Treck TCP/IP stack may be known by other names such as Kasago TCP/IP, ELMIC, Net+ OS, Quadnet, GHNET v2, Kwiknet, or AMX,” ICS-CERT pointed out. Previous vulnerability research by JSOF researchers explained how separate branches of the vulnerable stack came to be.

The good news is that the vulnerabilities have been fixed and that there are no known public exploits specifically targeting them.

A tool for detecting vulnerable TCP/IP stacks in use

Research into TCP/IP libraries has ramped up in the last year or so. In addition to JSOF and Forescout, Armis researchers have also unearthed vulnerabilities in a TCP/IP library – namely IPnet, a TCP/IP stack used in Wind River’s VxWorks real-time operating system and several RTOS offerings by other vendors.

The main problem for organizations is that many embedded systems, IoT and OT devices don’t come with a Software Bill of Materials, and it’s difficult to find out which OS, firmware, or TCP/IP stack each device/system uses.

To help with that, Forescout has created the project-memoria-detector tool – an open-source script that identifies the use of four TCP/IP stacks (uIP/Contiki, picoTCP, FNET and Nut/Net) on a target device via three active fingerprinting methods.

For the moment, the script’s results are not absolute, i.e., it indicates the use of one of those four stacks with a certain level of confidence (high, medium, low).

“The level of confidence is a reminder that the script can still result in false positive (i.e., wrongly indicating the use of a stack) and false negative (i.e., missing the actual use of a stack) matches,” the researchers explained.

They intend to update the script with detections for other stacks in the future as they disclose additional vulnerabilities, and urge the community to help the tool get better at detecting currently vulnerable TCP/IP stacks or other stacks.




Share this