VU#932044: Choice Wireless Green Packet 4G WiMax modem vulnerability

Vulnerability Note VU#932044

Choice Wireless Green Packet 4G WiMax modem vulnerability

Original Release date: 28 Jun 2013 | Last revised: 28 Jun 2013

Overview

Choice Wireless Green Packet 4G WiMax modem, model number WIXFMR-111, fails to properly validate ajax requests allowing a remote unauthenticated attacker to view system configuration information or possibly execute commands on the device.

Description

It has been reported that Choice Wireless Green Packet 4G WiMax modem, model number WIXFMR-111, contains a web interface which is listening on both the LAN and WAN side that allows administrators to view or modify the configuration of the device. This web interface fails to properly authenticate ajax requests, allowing a remote unauthenticated attacker to view system configuration information or possibly execute commands on the device.

Example ajax requests include:

    Request to http://<device ip>/ajax.cgi?action=wmxState will provide the current status of the WiMax connection.
    Request to http://<device ip>/ajax.cgi?action=netState will provide detailed information about the current network status, including LAN and WAN IP addresses, interface MAC addresses, etc.
    Request to http://<device ip>/ajax.cgi?action=tag_ipPing&pip=1+%26%26+cat+%2Fetc%2Fsncfg%2Fwmx.cfg will list the device’s WiMax configuration, including username and password in plain text.

Impact

A remote unauthenticated attacker may view system configuration information or possibly execute commands on the device.

Solution

We are currently unaware of a practical solution to this problem.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Choice Wireless Affected 28 Jun 2013

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C
Temporal 7.1 E:U/RL:U/RC:UC
Environmental 5.3 CDP:MH/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Chris Meller for reporting this vulnerability.

This document was written by Michael Orlando.

Other Information

  • CVE IDs:
    CVE-2013-3581
  • Date Public:
    28 Jun 2013
  • Date First Published:
    28 Jun 2013
  • Date Last Updated:
    28 Jun 2013
  • Document Revision:
    11

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/932044

VU#704828: Lookout! Mobile Security contains a denial-of-service vulnerability

Vulnerability Note VU#704828

Lookout! Mobile Security contains a denial-of-service vulnerability

Original Release date: 27 Jun 2013 | Last revised: 27 Jun 2013

Overview

Lookout! Mobile Security version 8.14.1-7fe5f1, and possibly earlier versions, contains a denial-of-service vulnerability.

Description

Lookout! Mobile Security (version 8.14.1-7fe5f1) crashes if an intent is sent to com.lookout.security.ScanTell intent with no arguments.

Impact

A malicious application installed on the phone may be able to disable the Lookout! Mobile Security software.

Solution

Apply an Update

Lookout! Mobile Security version 8.17-8a39d3f has been released to address this vulnerability.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Lookout Affected 11 Jun 2013 27 Jun 2013

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 3.8 AV:L/AC:H/Au:S/C:N/I:N/A:C
Temporal 3.0 E:POC/RL:OF/RC:C
Environmental 2.3 CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to china.x.orion for reporting this vulnerability.

This document was written by Adam Rauf.

Other Information

  • CVE IDs:
    CVE-2013-3579
  • Date Public:
    27 Jun 2013
  • Date First Published:
    27 Jun 2013
  • Date Last Updated:
    27 Jun 2013
  • Document Revision:
    7

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/704828

VU#662676: Digital Alert Systems DASDEC and Monroe Electronics R189 One-Net firmware exposes private root SSH key

Vulnerability Note VU#662676

Digital Alert Systems DASDEC and Monroe Electronics R189 One-Net firmware exposes private root SSH key

Original Release date: 26 Jun 2013 | Last revised: 26 Jun 2013

Overview

Digital Alert Systems DASDEC and Monroe Electronics One-Net E189 Emergency Alert System (EAS) devices exposed a shared private root SSH key in publicly available firmware images. An attacker with SSH access to a device could use the key to log in with root privileges.

Description

The Digital Alert Systems DASDEC-I and DASDEC-II and Monroe Electronics R189 One-Net/R189SE One-NetSE are Linux-based EAS encoder/decoder (ENDEC) devices that are used to broadcast EAS messages over digital and analog channels. IOActive has reported several security issues affecting these devices. The most severe of these issues is the public disclosure of the default private root SSH key. The less severe issues could also contribute to an attacker’s ability to compromise a vulnerable device.

Compromised root SSH key (CVE-2013-0137)
Publicly available firmware images for these devices included a private root SSH key that was authorized to log in to the devices (CWE-798, CWE-321). The fingerprint for the compromised SSH key is 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3. Although this key is not hard-coded, it may be impractical for less technical users to manually disable or change they key prior to firmware version 2.0-2.

Predictable session ID
IOActive reports that the administrative web server uses a predictable, monotonically increasing session ID. This finding is based on running the web server in a test environment. Testing on a variety of firmware versions on devices both at the factory and in the field, Monroe Electronics could not reproduce this finding.

Log information disclosure
Logs available via the web server provide a variety of information about the configuration, operation, and status of the device (CWE-532). Some of the log information is public and may be required by regulation.

Predictable password generation
The dasdec_mkuser script generates passwords in a deterministic way (CWE-341), however these passwords are not for administrative access, and the script is not used for general user account configuration.

Default password
Like many similar devices, the DASDEC and One-Net ENDECs use default administrative credentials. Some sites fail to change the default administrative password and allow unrestricted internet access.

Impact

An attacker with the private key and SSH access can log in to a device with root privileges.

Predictable session IDs could allow an attacker to take control of an existing administrative web session.

Predictable and unchanged default passwords can allow an attacker to log in to a device with root privileges. Devices exposed to the internet are at particularly high risk, for example, see Secure EAS Codecs Prevent Zombie Attacks and US-CERT Alert TA13-175A.

Logs may disclose configuration information that can benefit an attacker.

Solution

Apply an update

On April 24, 2013, Monroe Electronics and Digital Alert Systems released firmware version 2.0-2 that disables the compromised SSH key, provides a simplified user option to install new unique keys, and enforces a new password policy. Monroe Electronics has taken considerable effort to provide update information to DASDEC and One-NetSE users.

DASDEC users can obtain updated firmware and release notes by contacting <support@digitalalertsystems.com>. R189 One-Net users can contact <eas@monroe-electronics.com>.

Disable compromised SSH key

The compromised root SSH key should be disabled immediately, especially if the SSH service is exposed to untrusted networks such as the internet. If SSH connectivity is required, generate, install, and test new SSH keys before disabling the compromised key. The fingerprint for the compromised SSH key is 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3.

Manually inspect SSH keys

To identify a compromised key, examine the authorized_keys file at /root/.ssh/authorized_keys2.dasdec and use the ssh-keygen command to show SSH key fingerprints. The following example shows the fingerprint for the compromised key:

$ ssh-keygen -l -f authorized_keys2.dasdec
1024 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3 wood@endec1 (DSA)

Note that ssh-keygen only shows the fingerprint for the first key/line in the file. If authorized_keys2.dasdec contains multiple keys (multiple lines, one key per line), it will be necessary to extract each key (line) to a separate file and run the ssh-keygen command on each key/file. These shell scripts can be used to list and test multiple SSH keys in an authorized_keys file:

To generate new SSH keys, use ssh-keygen.

Restrict access

If for some reason you are not able to remove and replace the compromised SSH key, restrict access to the SSH service to highly trusted hosts and networks only. As a general good security practice, restrict access to all services to trusted hosts and networks.

Change default passwords

Change any default passwords, and do not deploy production systems without changing default passwords. Search engines like Shodan can index systems exposed to the internet and default passwords are usually documented and well-known. It is often trivial for an attacker to identify and access systems on the internet using default passwords.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Digital Alert Systems Affected 18 Jan 2013 24 Jun 2013
Monroe Electronics Affected 18 Jan 2013 24 Jun 2013

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 10.0 AV:N/AC:L/Au:N/C:C/I:C/A:C
Temporal 8.7 E:ND/RL:OF/RC:C
Environmental 6.8 CDP:LM/TD:M/CR:ND/IR:M/AR:ND

References

Credit

Thanks to Mike Davis and Cesar Cerrudo of IOActive for reporting these issues. Thanks also to Monroe Electronics for their efforts to contact affected users.

This document was written by Art Manion.

Other Information

  • CVE IDs:
    CVE-2013-0137
  • Date Public:
    24 Jun 2013
  • Date First Published:
    26 Jun 2013
  • Date Last Updated:
    26 Jun 2013
  • Document Revision:
    75

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/662676

VU#225657: Oracle Javadoc HTML frame injection vulnerability

Vulnerability Note VU#225657

Oracle Javadoc HTML frame injection vulnerability

Original Release date: 18 Jun 2013 | Last revised: 18 Jun 2013

Overview

Javadoc HTML pages that were created by Javadoc 7 Update 21 and before, 6 Update 45 and before, 5.0 Update 45 and before, JavaFX 2.2.21 and before contain a frame injection vulnerability that could allow an attacker to replace a Javadoc web page frame with a malicious page.

Description

Oracle Java Development Toolkit (JDK) contains a Javadoc toolkit that allows a developer to generate API documentation in HTML format from doc comments in source code.

Javadoc HTML pages that were created by Javadoc 7 Update 21 and before, 6 Update 45 and before, 5.0 Update 45 and before, JavaFX 2.2.21 and before contain JavaScript code that fails to parse scheme relative URIs parameters correctly. An attacker can construct a URI that passes malicious parameters to the affected HTML page that causes one of the frames within the Javadoc-generated web page to be replaced with a malicious page.

For additional information please see Oracle Security Advisory.

Impact

An attacker can cause one of the frames within a Javadoc-generated web page to be replaced with a malicious page. This vulnerability could be used for phishing or social engineering, or it could be used for browser exploitation if combined with another browser-related vulnerability.

Solution

Apply Update

Oracle has released June 2013 Java Critical Patch Update to address this vulnerability. Oracle Java Developers Toolkit (JDK) and Javadoc users are advised to apply June 2013 Java Critical Patch Update and regenerate and republish affected Javadoc HTML pages.

Fix-in-Place Fix Tool

Oracle has released a fix-in-place tool named Java API Documentation Updater Tool. This fix-in-place tool can process directories or folders to search for HTML files to be remediated without having to regenerate existing Javadocs. When presented directories/folders and their sub-directories or sub-folders the Java API Documentation Updater Tool will search for files with the following names:

  • index.htm
  • index.html
  • toc.htm
  • toc.html

For each file that matches the names noted above the Java API Documentation Updater Tool will search the file for the affected JavaScript text and replace it with the remediated version. Note that this tool will not detect Javadoc pages that have been renamed to something other than one of the above page names.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Oracle Corporation Affected 12 Jun 2013

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 5.0 AV:N/AC:L/Au:N/C:N/I:P/A:N
Temporal 4.1 E:F/RL:OF/RC:C
Environmental 4.4 CDP:LM/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Oracle for reporting this vulnerability.

This document was written by Michael Orlando.

Other Information

  • CVE IDs:
    CVE-2013-1571
  • Date Public:
    18 Jun 2013
  • Date First Published:
    18 Jun 2013
  • Date Last Updated:
    18 Jun 2013
  • Document Revision:
    25

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/225657

VU#422807: Adobe Reader and Acrobat memory corruption vulnerabilities

Vulnerability Note VU#422807

Adobe Reader and Acrobat memory corruption vulnerabilities

Original Release date: 14 Feb 2013 | Last revised: 14 Feb 2013

 

Overview

Adobe Reader and Acrobat 11.0.01 and earlier, 10.1.5 and earlier, and 9.5.3 and earlier contain memory corruption vulnerabilities.

Description

The Adobe security advisory APSA13-02 states:

Adobe has identified critical vulnerabilities (CVE-2013-0640, CVE-2013-0641) in Adobe Reader and Acrobat XI (11.0.01 and earlier), X (10.1.5 and earlier) and 9.5.3 and earlier for Windows and Macintosh. These vulnerabilities could cause the application to crash and potentially allow an attacker to take control of the affected system.

Adobe is aware of reports that these vulnerabilities are being exploited in the wild in targeted attacks designed to trick Windows users into clicking on a malicious PDF file delivered in an email message.
Adobe is in the process of working on a fix for these issues and will update this advisory when a date for the fix has been determined.

Additional details may be found in the full advisory APSA13-02.

Impact

A remote attacker may be able to cause a denial of service or execute arbitrary code on the system in the context of the user running the Adobe product.

Solution

We are currently unaware of a practical solution to this problem. Please consider the following workarounds.

Enable Protected View

Users of Adobe Reader XI and Acrobat XI for Windows can protect themselves from this exploit by enabling Protected View. To enable this setting, choose the “Files from potentially unsafe locations” option under the Edit > Preferences > Security (Enhanced) menu.

Use the Microsoft Enhanced Mitigation Experience Toolkit

The Microsoft Enhanced Mitigation Experience Toolkit (EMET) can be used to help prevent exploitation of this vulnerability. CERT/CC has created a video tutorial for setting up EMET 3.0 on Windows 7. Note that platforms that do not support ASLR, such as Windows XP and Windows Server 2003, will not receive the same level of protection that modern Windows platforms will.

Enable DEP in Microsoft Windows

Consider enabling Data Execution Prevention (DEP) in supported versions of Windows. DEP should not be treated as a complete workaround, but it can mitigate the execution of attacker-supplied code in some cases. Microsoft has published detailed technical information about DEP in Security Research & Defense blog posts “Understanding DEP as a mitigation technology” part 1 and part 2. DEP should be used in conjunction with the application of patches or other mitigations described in this document.

Note that when relying on DEP for exploit mitigation, it is important to use a system that supports Address Space Layout Randomization (ASLR) as well. ASLR is not supported by Windows XP or Windows Server 2003 or earlier. ASLR was introduced with Microsoft Windows Vista and Windows Server 2008. Please see the Microsoft SRD blog entry: On the effectiveness of DEP and ASLR for more details.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Adobe Affected 14 Feb 2013

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C
Temporal 8.8 E:H/RL:W/RC:C
Environmental 8.8 CDP:MH/TD:H/CR:H/IR:H/AR:H

References

Credit

This document was written by Jared Allar.

Other Information

  • CVE IDs:
    CVE-2013-0640
    CVE-2013-0641
  • Date Public:
    13 Feb 2013
  • Date First Published:
    14 Feb 2013
  • Date Last Updated:
    14 Feb 2013
  • Document Revision:
    7

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/422807