September 25, 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


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.


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.


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


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)


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.


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’.


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.


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]

VxWorks Vulnerabilities

There is a great article about VxWorks OS vulnerabilities at Metasploit Blog.

Shiny Old VxWorks Vulnerabilities

Back in June, I decided to spend some time looking at the VxWorks operating system. Specifically, I kept finding references to VxWorks-based devices running firmware images with the debug service (WDB Agent) enabled, but I could not find a description of the protocol or any estimates as to how prevalent this service was. After a couple days of digging around and a couple more days of scanning, I became aware of just how extensive this issue is.

For folks who aren’t aware of what VxWorks is — VxWorks was the most popular embedded operating system in 2005, it is a platform developed by Wind River Systems, which has since been acquired by Intel. Vendors who wish to build products using the VxWorks operating system will license it out by component, integrate their own application code, and then build images which can be installed on their products. VxWorks has been used to power everything from the Apple Airport Extreme access points to the Mars rovers and the C-130 Hercules aircraft. VxWorks itself is essentially a monolithic kernel with applications implemented as kernel tasks. This means that all tasks generally run with the highest privileges and there is little memory protection between these tasks (at least with version 5.x).

The WDB agent is a system-level debugger for the VxWorks operating system that runs on UDP port 17185. This service is modeled on the SunRPC protocol in terms of wire format and allows anyone with access to this port to read memory, write memory, call functions, and manage tasks. Since the protocol is UDP and there is no authentication, handshake, or session ID, requests to the WDB agent can also be spoofed by an attacker.

To determine how widespread this issue was, I wrote a scanner module for the Metasploit Framework and conducted a network survey that encompassed over 3.1 billion IP addresses. Of this set, over 250,000 systems were found with the WDB agent exposed. After digging around in the DShield database, it became obvious that an unknown party had already spent most of 2006 scanning for this service. I contacted the Carnegie Mellon CERT and provided them with the list of affected devices that were gleaned from the survey, with the goal of notifying as many vendors as possible in a reasonable amount of time. CERT assigned VU#362332 to this issue and plans to publish an advisory today (August 2nd, 2010). The Rapid7 NeXpose engineering team has created a check for this vulnerability and made this available through the standard product update mechanism.

Read complete article at :

Source: [Metasploit Blog]