Weaknesses Undermine Wind River's VxWorks Operating System

Recently the US-Cert issued two security bulletins (VU#362332 and VU#840249) about weaknesses in Wind River Systems VxWorks embedded operating system. VxWorks is one of the most popular operating systems that runs on a variety of appliances and devices. Some of these appliances are part of the critical infrastructure in an organization, such as routers and firewalls. An attacker could fully control vulnerable embedded devices by remotely exploiting these two vulnerabilities.

The first bulletin (VU#362332) contains old and well-known issues (CVE-2005-3715, CVE-2005-3804, CVE-2006-0374) on the VxWorks WDB debugging interface. WDB connects host tools to a VxWorks system during development and it is enabled by default. The vulnerability allows any unsolicited requests to access WDB without authentication using the SUN RPC protocol over UDP port 17185.

The second bulletin (VU#840249) addresses exploits that target VxWorks self-designed hashing algorithm used to store passwords in the VxWorks operating system. VxWorks standard hashing algorithm is susceptible to hash collision attacks, which allow attackers to brute-force the password in a relatively short time.

Combing these weaknesses and exploiting them together, an attacker can fully compromise the device. Here is an example of a typical exploit: First, an attacker can scan for an embedded device with VxWorks WDB debug service enabled by exploiting the unauthenticated access vulnerability as detailed in VU#362332. Once the device is found, an attacker can use the debug interface to find the username and password information stored on the device. Using that information, the attacker can then brute-force the password offline by exploiting the second weakness (VU#840249).

Today, McAfee NSP released a UDS (0×40805600/ UDS-RPC: Wind River Systems VxWorks WDB Debug Activities Detected) that provides coverage for CVE-2005-3715, CVE-2005-3804, CVE-2006-0374, and VU#362332. Please note that it is normal for embedded platforms to have remote debugging enabled in a development environment. The VxWorks WDB debug activities may be legitimate; if that is the case, you can ignore the alerts. However, if users see any attempts from unknown or unexpected IP addresses, we recommend that users investigate the activity and take further action if required.