Security Bulletin: An unauthorized attacker who has obtained an IBM Watson IoT Platform security authentication token can use it to impersonate an authorized platform user (CVE-2023-38372)

Summary

Guidance on best practices to mitigate or avoid compromise in case an unauthorized attacker obtains an IBM Watson IoT Platform security authentication token (CVE-2023-38372).

Vulnerability Details

CVEID:CVE-2023-38372
**DESCRIPTION:**IBM Watson IoT Platform contains a vulnerability that could allow an unauthorized attacker to obtain security authentication tokens.
CVSS Base score: 5.9
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/261201 for the current score.
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)

Affected Products and Versions

Affected Product(s)|**Version(s)
**
—|—
Watson IoT Platform| 1.0

Remediation/Fixes

Workarounds and Mitigations

Application Security in Watson IoT Platform

Applications authenticate to the Watson IoT Platform using API Keys which can be given permission
to carry out a number of different operations. It is, therefore, important to consider a number of
security-related aspects when creating keys.

Roles

When you create an IoT Platform API Key you have to assign it a role [1]. It is important to use the
“Principle of Least Privilege” and assign each API key a role that permits only the operations that its
application needs to perform. In this way exposure can be minimised if an application’s credentials
are compromised. Application roles are discussed here:
https://www.ibm.com/docs/en/mapms/1_cloud?topic=devices-using-role-based-access-control#application_roles

with more details about the individual roles available here:
<https://www.ibm.com/docs/en/mapms/1_cloud?topic=control-application-roles&gt;

By default, API Keys that are created using the IoT User Interface (shown above) are assigned the
”Visualization Application” role. This is the least-privileged of all the pre-defined roles. It gives an
application the ability to view events being sent from devices, but not to send commands to devices.

Dedicated API Keys

Although a single API key can be used by multiple applications, we recommend that you generate a
separate API Key for each application. This means that if an API key is known to have been
compromised, it can be revoked without impacting the other applications.

API Key expiry

When API keys are created (In Apps > Generate API Key) [1], they can be assigned an expiry date.
Giving an API key an expiry ensures that:
1. Credentials for temporary applications do not live longer than are required
2. It ensures that tokens are rotated at appropriate intervals and that old credentials that are
eventually compromised do not act as an attack vector.

We recommend that API keys are created with expiry and that new API keys are generated and
provisioned to applications when the old ones expire. Programmatic APIs are available to allow this
process to be automated. The default expiry time (if expiry is enabled) in the User Interface is 30
days.

Secure storage of the token

In order to ensure the credentials for an application are not leaked, it is important to ensure that
these credentials are stored properly. For example, care should be taken with file permissions and
only copied to systems where necessary. Credentials should not (for example) be embedded in
webpages distributed to multiple users.

Signing and verification of command messages

One use of applications is to send command messages to devices. In many cases, devices rely on the
fact that the IoT Platform has authenticated and authorized the Application that sent the command.
For situations that require a higher degree of security, this can be augmented through the use of
digital signatures.

1. The Application is provisioned with a PKI private key and public key certificate signed by a
   Certificate Authority that is trusted by the device firmware. The application uses its private
   key to sign the content of the command. The private key can be held by a secure
   computing element and this element can also perform the signing operation, to
   Minimize the risk of the private key being compromised.
2. With MQTT version 5 it is possible to publish metadata in the form of properties with a
   message. These properties can include the signature of the payload and the certificate that
   was used for this signature.
3. The Device can then use the signature to verify the contents of the message and
   retrieve the identity of the sending application from the Certificate. This allows the
   private key used to sign the command messages to be a second factor in the verification of
   command messages, in the case that the API key had been compromised.

[1] The creation of API Keys is described as follows:
<https://www.ibm.com/docs/en/mapms/1_cloud?topic=gateways-using-applications#authentication&gt;