2019

Five recent vulnerability notes of the year 2019

1. Telos Automated Message Handling System contains multiple vulnerabilities.

Overview:

Telos Automated Message Handling System (AMHS) contains multiple XSS vulnerabilities and a database information disclosure vulnerability.

Description:

Telos AMHS is a web-based messaging system that supports DoD and Intelligence Community (IC) security marking requirements. AMHS versions prior to version 4.1.5.5 contain multiple XSS vulnerabilities and also fail to properly restrict access to information about other users on the system.

Impact:

By creating a specially-crafted AMHS URI, an attacker may be able to inject arbitrary JavaScript into AMHS session or access information about other AMHS users.

Solution:

Apply an update

These issues are addressed in AMHS version 4.1.5.5. Please contact Telos for update availability.

2. Apple devices vulnerable to arbitrary code execution in SecureROM.

Overview:

Some Apple devices are vulnerable to arbitrary code execution at the Boot ROM level (called "SecureROM" by Apple) by exploiting a use-after-free vulnerability. Successful exploitation results in the ability to execute arbitrary code on the device. checkm8 is a public exploit for this vulnerability.

Description:

A vulnerability in the SecureROM of some Apple devices can be exploited by an unauthenticated local attacker to execute arbitrary code upon booting those devices. SecureROM, which is located within the processor, contains the first code executed by the processor upon booting the device. Because SecureROM is read-only, it cannot be patched with a firmware update.

Apple devices that implement processing chips A5 through A11 are vulnerable. This corresponds to iPhone models 4S through X; additionally, certain models of iPad, Apple Watch, iPod Touch, and Apple TV are vulnerable. See the Malwarebytes blog entry for a full list of affected devices. Further details about the vulnerability are available in Ars Technica's interview with the vulnerability's discoverer.

Impact:

This vulnerability allows arbitrary code to be executed on the device. Exploiting the vulnerability requires physical access to the device: the device must be plugged in to a computer upon booting, and it must be put into Device Firmware Update (DFU) mode. The exploit is not persistent; rebooting the device overrides any changes to the device's software that were made during an exploited session on the device. Additionally, unless an attacker has access to the device's unlock PIN or fingerprint, an attacker cannot gain access to information protected by Apple's Secure Enclave or Touch ID features.

Solution:

The CERT/CC is currently unaware of a practical solution to this problem. Because the vulnerability exists in the read-only Boot ROM level, replacing the device with one that does not contain a vulnerable processing chip is the only solution that guarantees immunity to the vulnerability.

Generally speaking, physical access to a computer system can be used to bypass software-based access control mechanisms.

3. Microsoft Office for Mac cannot properly disable XLM macros.

Overview:

The Microsoft Office for Mac option "Disable all macros without notification" enables XLM macros without prompting, which can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.

Description:

XLM macros Up to and including Microsoft Excel 4.0, a macro format called XLM was available. XLM macros predate the VBA macros that are more common with modern Microsoft Office systems, however current Microsoft Office versions still support XLM macros.

SYLK and XLM macros

XLM macros can be incorporated into SYLK files, as outlined by Outflank. Macros in the SYLK format are problematic in that Microsoft Office does not open in Protected View to help protect users. This means that users may be a single click away from arbitrary code execution via a document that originated from the internet.

SYLK and XLM macros with Microsoft Office for Mac

It has been reported that Office 2011 for Mac fails to warn users before opening SYLK files that contain XLM macros. According to this post, Microsoft has reported that Office 2016 and Office 2019 for Mac properly prompt the user before executing XLM macros in SYLK files.

Impact:

By convincing a user to open specially-crafted Microsoft Excel content on a Mac that has "Disable all macros without notification" enabled, a remote, unauthenticated attacker may be able to execute arbitrary code with privileges of the user running Excel.

Solution:

Apply an update

This issue is addressed for Office 2016 for Mac build 16.16.16 (19111100) and Office 2019 for Mac build 16.31 (19111002), as described in the Microsoft Security update for CVE-2019-1457.

4. Multiple D-Link routers vulnerable to remote command execution.

Overview:

Multiple D-Link routers are vulnerable to unauthenticated remote command execution.

Description:

Several D-Link routers contain CGI capability that is exposed to users as /apply_sec.cgi, and dispatched on the device by the binary /www/cgi/ssi. This CGI code contains two flaws:

1. The /apply_sec.cgi code is exposed to unauthenticated users.

2. The ping_ipaddr argument of the ping_test action fails to properly handle newline characters.

Any arguments after a newline character sent as ping_ipaddr in a POST to /apply_sec.cgi are executed on the device with root privileges. The following devices are reported to be vulnerable:

DIR-655

DIR-866L

DIR-652

DHP-1565

DIR-855L

DAP-1533

DIR-862L

DIR-615

DIR-835

DIR-825

We have made a proof-of-concept exploit available, which will disable network connectivity for one minute on affected devices.

Impact:

By performing an HTTP POST request to a vulnerable router's /apply_sec.cgi page, a remote, unauthenticated attacker may be able to execute commands with root privileges on an affected device. This action can happen as the result of viewing a specially-crafted web page.

Solution:

The CERT/CC is currently unaware of a practical solution to this problem. The devices listed above are no longer supported by D-Link.

5. Bluetooth BR/EDR supported devices are vulnerable to key negotiation attacks.

Overview:

The encryption key length negotiation process in Bluetooth BR/EDR Core v5.1 and earlier is vulnerable to packet injection by an unauthenticated, adjacent attacker that could result in information disclosure and/or escalation of privileges. This can be achieved using an attack referred to as the Key Negotiation of Bluetooth (KNOB) attack, which is when a third party forces two or more victims to agree on an encryption key with as little as one byte of entropy. Once the entropy is reduced, the attacker can brute-force the encryption key and use it to decrypt communications.

Description:

Bluetooth is a short-range wireless technology based off of a core specification that defines six different core configurations, including the Bluetooth Basic Rate / Enhanced Data Rate Core Configurations. Bluetooth BR/EDR is used for low-power short-range communications. To establish an encrypted connection, two Bluetooth devices must pair with each other and establish a link key that is used to generate the encryption key. For example, assume that there are two controllers attempting to establish a connection: Alice and Bob. After authenticating the link key, Alice proposes that she and Bob use 16 bytes of entropy. This number, N, could be between 1 and 16 bytes. Bob can either accept this, reject this and abort the negotiation, or propose a smaller value. Bob may wish to propose a smaller N value because he (the controller) does not support the larger amount of bytes proposed by Alice. After proposing a smaller amount, Alice can accept it and request to activate link-layer encryption with Bob, which Bob can accept.

An attacker, Charlie, could force Alice and Bob to use a smaller N by intercepting Alice's proposal request to Bob and changing N. Charlie could lower N to as low as 1 byte, which Bob would subsequently accept since Bob supports 1 byte of entropy and it is within the range of the compliant values. Charlie could then intercept Bob's acceptance message to Alice and change the entropy proposal to 1 byte, which Alice would likely accept, because she may believe that Bob cannot support a larger N. Thus, both Alice and Bob would accept N and inform the Bluetooth hosts that encryption is active, without acknowledging or realizing that N is lower than either of them initially intended it to be.

Impact:

An unauthenticated, adjacent attacker can force two Bluetooth devices to use as low as 1 byte of entropy. This would make it easier for an attacker to brute force as it reduces the total number of possible keys to try, and would give them the ability to decrypt all of the traffic between the devices during that session.

Solution:

Bluetooth host and controller suppliers should refer to the Bluetooth SIG's "Expedited Errata Correction 11838" for guidance on updating their products. Downstream vendors should refer to their suppliers for updates.