| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The leakage of channel access token in bluetrick Line 13.6.1 allows remote attackers to send malicious notifications to victims. |
| The leakage of channel access token in best_training_member Line 13.6.1 allows remote attackers to send malicious notifications. |
| The leakage of channel access token in taketorinoyu Line 13.6.1 allows remote attackers to send malicious notifications to victims. |
| The leakage of channel access token in platinum clinic Line 13.6.1 allows remote attackers to send malicious notifications to victims. |
| The leakage of channel access token in craft_members Line 13.6.1 allows remote attackers to send malicious notifications to victims. |
| The leakage of channel access token in Lil.OFF-PRICE STORE Line 13.6.1 allows remote attackers to send malicious notifications to victims. |
| The leakage of channel access token in F.B.P members Line 13.6.1 allows remote attackers to send malicious notifications to victims. |
| An issue discovered in esptool 4.6.2 allows attackers to view sensitive information via weak cryptographic algorithm. |
| CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations. |
| Inadequate encryption strength in mycli 1.27.0 allows attackers to view sensitive information via /mycli/config.py |
| Eaton easyE4 PLC offers a device password protection functionality to facilitate a secure connection and prevent unauthorized access. It was observed that the device password was stored with a weak encoding algorithm in the easyE4 program file when exported to SD card (*.PRG file ending). |
| Inadequate encryption strength vulnerability in multiple routers provided by ELECOM CO.,LTD. and LOGITEC CORPORATION allows a network-adjacent unauthenticated attacker to guess the encryption key used for wireless LAN communication and intercept the communication. As for the affected products/versions, see the information provided by the vendor under [References] section. |
|
Due to the implementation of "deriveVaultKey", prior to version 7.10, the generated vault key
would always have the last 16 bytes predetermined to be "arfoobarfoobarfo".
This issue happens because "deriveVaultKey" calls "retrieveCloudKey" (which will always
return "foobarfoobarfoobarfoobarfoobarfo" as the key), and then merges the 32byte
randomly generated key with this key (by takeing 16bytes from each, see "mergeKeys").
This makes the key a lot weaker.
This issue does not persist in devices that were initialized on/after version 7.10, but devices
that were initialized before that and updated to a newer version still have this issue.
Roll an update that enforces the full 32bytes key usage.
|
|
Vault Key Sealed With SHA1 PCRs
The measured boot solution implemented in EVE OS leans on a PCR locking mechanism.
Different parts of the system update different PCR values in the TPM, resulting in a unique
value for each PCR entry.
These PCRs are then used in order to seal/unseal a key from the TPM which is used to
encrypt/decrypt the “vault” directory.
This “vault” directory is the most sensitive point in the system and as such, its content should
be protected.
This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism,
designed to protect said “vault”.
The code that’s responsible for generating and fetching the key from the TPM assumes that
SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being
checked.
The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.
This leads to several issues:
• Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well
as not sealing their keys at all, meaning the “vault” is not protected from an attacker.
• SHA1 is considered insecure and reduces the complexity level required to unseal the
key in machines which have their SHA1 PCRs enabled.
An attacker can very easily retrieve the contents of the “vault”, which will effectively render
the “measured boot” mechanism meaningless.
|
| PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but
due to the change that was implemented in commit
“7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the
problem of the config partition not being measured correctly.
Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of
SHA256.
This issue was somewhat mitigated due to all of the PCR extend functions
updating both the values of SHA256 and SHA1 for a given PCR ID.
However, due to the change that was implemented in commit
“7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as
the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which
means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault”
key, changes to the config partition would still not be measured.
An attacker could modify the config partition without triggering the measured boot, this could
result in the attacker gaining full control over the device with full access to the contents of the
encrypted “vault”
|
| EisBaer Scada - CWE-321: Use of Hard-coded Cryptographic Key |
| The device is observed to accept deprecated TLS protocols, increasing the risk of cryptographic weaknesses. |
| The server supports at least one cipher suite which is on the NCSC-NL list of cipher suites to be phased out, increasing the risk of cryptographic weaknesses. |
| Vulnerability of 5G messages being sent without being encrypted in a VPN environment in the SMS message module. Successful exploitation of this vulnerability may affect confidentiality. |
| Symmetric encryption used to protect messages between the AppsAnywhere server and client can be broken by reverse engineering the client and used to impersonate the AppsAnywhere server. |
