September 29, 2016

Wind River Systems VxWorks Vulnerabilities

United States Computer Emergency Readiness Team (US-Cert) issued two warnings for Wind River Systems VxWorks. The vulnerabilities have been discovered and reported by the security researches at Metasploit.

Here are the notes issues by the US-Cert:

Vulnerability Note VU#362332

Wind River Systems VxWorks debug service enabled by default

Overview

Some products based on VxWorks have the WDB target agent debug service enabled by default. This service provides read/write access to the device’s memory and allows functions to be called.

Description

The VxWorks WDB target agent is a target-resident, run-time facility that is required for connecting host tools to a VxWorks target system during development. WDB is a selectable component in the VxWorks configuration and is enabled by default. The WDB debug agent access is not secured and does provide a security hole in a deployed system.

It is advisable for production systems to reconfigure VxWorks with only those components needed for deployed operation and to build it as the appropriate type of system image. It is recommended to remove host development components such as the WDB target agent and debugging components (INCLUDE_WDB and INCLUDE_DEBUG) as well as other operating system components that are not required to support customer applications.

Consult the VxWorks Kernel Programmer’s guide for more information on WDB.

Additional information can be found in ICS-CERT advisory ICSA-10-214-01 and on the Metasploit Blog.

Impact

An attacker can use the debug service to fully compromise the device.

Solution

Disable debug agent

Vendors should remove the WDB target debug agent in their VxWorks based products by removing the INCLUDE_WDB & INCLUDE_DEBUG components from their VxWorks Image.

Restrict access
Appropriate firewall rules should be implemented to restrict access to the debug service (17185/udp) to only trusted sources until vendors have released patches to disable it.

Vulnerability Note VU#840249

Wind River Systems VxWorks weak default hashing algorithm in standard authentication API (loginLib)

Overview

The hashing algorithm that is used in the standard authentication API for VxWorks is susceptible to collisions. An attacker can brute force a password by guessing a string that produces the same hash as a legitimate password.

Description

An attacker with a known username and access to a service (telnet, rlogin or FTP) that uses the standard authentication API (loginDefaultEncrypt (), part of loginLib) can brute force the password in a relatively short period of time. Since the hashing algorithm is susceptible to collisions, the actual password does not have to be found, just a string that produces the same hash.

For instance, when the default ‘target/password’ login example is used, ‘y{{{{{kS’ hashes to the same string as ‘password’. It is thus possible to login using both ‘password’ and ‘y{{{{{kS’ as the passwords for the user ‘target’.

Impact

An attacker can brute force a correct password by guessing a string that produces the same hash and access the relevant service as the known user.

Additional information can be found in ICS-CERT advisory ICSA-10-214-01 and on the Metasploit Blog.

Solution

Vendors which use VxWorks in their products should not use the default hashing algorithm in standard authentication API (loginDefaultEncrypt()). A trusted authentication API should be used instead. It can be installed by means of the loginEncryptInstall() loginLib hook.

In addition, and so as to avoid registration of the default ‘target’/’password’ credentials at init time, the LOGIN_USER_NAME and LOGIN_USER_PASSWORD project parameters/#defines should be set to empty strings (so that no user is registered using the default encryption routine). Only after the new encryption routine is registered should new users be added to the system. [Truncated]

Share and Enjoy:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks