## 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
**Product(s)**| **Version(s) number and/or range **| **Remediation/Fix/Instructions**
—|—|—
Watson IoT Platform| 1.0| Use the guidance under Workaround and Mitigations section.
## 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:
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: