ALTBN128_ADD, ALTBN128_MUL, ALTBN128_PAIRING precompile functions do not check if points are on curve

Besu Native contains scripts and tooling that is used to build and package the native libraries used by the Ethereum client Hyperledger Besu. Besu 24.7.1 through 25.2.2, corresponding to besu-native versions 0.9.0 through 1.2.1, have a potential consensus bug for the precompiles ALTBN128_ADD (0x06), ALTBN128_MUL (0x07), and ALTBN128_PAIRING (0x08). These precompiles were reimplemented in besu-native using gnark-crypto's bn254 implementation, as the former implementation used a library which was no longer maintained and not sufficiently performant. The new gnark implementation was initially added in version 0.9.0 of besu-native but was not utilized by Besu until version 0.9.2 in Besu 24.7.1. The issue is that there are EC points which may be crafted which are in the correct subgroup but are not on the curve and the besu-native gnark implementation was relying on subgroup checks to perform point-on-curve checks as well. The version of gnark-crypto used at the time did not do this check when performing subgroup checks. The result is that it was possible for Besu to give an incorrect result and fall out of consensus when executing one of these precompiles against a specially crafted input point. Additionally, homogenous Besu-only networks can potentially enshrine invalid state which would be incorrect and difficult to process with patched versions of besu which handle these calls correctly. The underlying defect has been patched in besu-native release 1.3.0. The fixed version of Besu is version 25.3.0. As a workaround for versions of Besu with the problem, the native precompile for altbn128 may be disabled in favor of the pure-java implementation. The pure java implementation is significantly slower, but does not have this consensus issue.

VyOS 1.3 through 1.5 (fixed in 1.4.2) or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run "rm -f /etc/dropbear/*key*" and/or "rm -f /etc/dropbear-initramfs/*key*" and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.

Crypt::CBC versions between 1.21 and 3.05 for Perl may use insecure rand() function for cryptographic functions

Crypt::CBC versions between 1.21 and 3.05 for Perl may use the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions. This issue affects operating systems where "/dev/urandom'" is unavailable.  In that case, Crypt::CBC will fallback to use the insecure rand() function.

Weak encryption vulnerability in JP1/IT Desktop Management 2 - Smart Device Manager

Weak encryption vulnerability in Hitachi JP1/IT Desktop Management 2 - Smart Device Manager on Windows.This issue affects JP1/IT Desktop Management 2 - Smart Device Manager: from 12-00 before 12-00-08, from 11-10 through 11-10-08, from 11-00 through 11-00-05, from 10-50 through 10-50-06.

Emissary Use of a Broken or Risky Cryptographic Algorithm

Emissary is a P2P based data-driven workflow engine. The ChecksumCalculator class within allows for hashing and checksum generation, but it includes or defaults to algorithms that are no longer recommended for secure cryptographic use cases (e.g., SHA-1, CRC32, and SSDEEP). These algorithms, while possibly valid for certain non-security-critical tasks, can expose users to security risks if used in scenarios where strong cryptographic guarantees are required. This issue is fixed in 8.24.0.

Broken or Risky Cryptographic Algorithm, Use of Password Hash With Insufficient Computational Effort, Use of Weak Hash, Use of a One-Way Hash with a Predictable Salt vulnerabilities in Beta80 "Life 1st Identity Manager" enable an attacker with access to password hashes to bruteforce user passwords or find a collision to ultimately while attempting to gain access to a target application that uses "Life 1st Identity Manager" as a service for authentication. This issue affects Life 1st: 1.5.2.14234.

Deprecated 3DES cryptographic algorithm used by Request Tracker in emails encrypted with S/MIME

Vulnerability in Best Practical Solutions, LLC's Request Tracker prior to v5.0.8, where the Triple DES (3DES) cryptographic algorithm is used to protect emails sent with S/MIME encryption. Triple DES is considered obsolete and insecure due to its susceptibility to birthday attacks, which could compromise the confidentiality of encrypted messages.

PandaXGO PandaX JWT Secret config.yml hard-coded key

A vulnerability was detected in PandaXGO PandaX up to fb8ff40f7ce5dfebdf66306c6d85625061faf7e5. This affects an unknown function of the file config.yml of the component JWT Secret Handler. The manipulation of the argument key results in use of hard-coded cryptographic key . The attack may be performed from remote. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit is now public and may be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet.

MartialBE one-hub docker-compose.yml hard-coded key

A vulnerability has been found in MartialBE one-hub up to 0.14.27. This vulnerability affects unknown code of the file docker-compose.yml. The manipulation of the argument SESSION_SECRET leads to use of hard-coded cryptographic key . The attack may be initiated remotely. The complexity of an attack is rather high. It is stated that the exploitability is difficult. The exploit has been disclosed to the public and may be used. It is recommended to change the configuration settings. The code maintainer recommends (translated from Chinese): "The default docker-compose example file is not recommended for production use. If you intend to use it in production, please carefully check and modify every configuration and environment variable yourself!"

running-elephant Datart API AESUtil.java getTokensecret hard-coded key

A vulnerability has been found in running-elephant Datart up to 1.0.0-rc3. Affected by this issue is the function getTokensecret of the file datart/security/src/main/java/datart/security/util/AESUtil.java of the component API. The manipulation leads to use of hard-coded cryptographic key . The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used.

PheonixAppAPI has visible Encoding Maps

Pheonix App is a Python application designed to streamline various tasks, from managing files to playing mini-games. The issue is that the map of encoding/decoding languages are visible in code. The Problem was patched in 0.2.4.

nvOC through 3.2 ships with SSH host keys baked into the installation image, which allows man-in-the-middle attacks and makes identification of all public IPv4 nodes trivial with Shodan.io. NOTE: as of 2019-12-01, the vendor indicated plans to fix this in the next image build.

Improper Authorization in the installer for the EOL OVA based connect component

An Improper Authorization vulnerability was identified in the EOL OVA based connect component which is deployed for installation purposes in the customer internal network. Under certain conditions, this could allow a bad actor to gain unauthorized access to the local db containing weakly hashed credentials of the installer. This EOL component was deprecated in September 2023 with end of support extended till January 2024.

SimpleMiningOS through v1259 ships with SSH host keys baked into the installation image, which allows man-in-the-middle attacks and makes identification of all public IPv4 nodes trivial with Shodan.io. NOTE: the vendor indicated that they have no plans to fix this, and discourage deployment using public IPv4.

An issue was discovered in Kaseya Rapid Fire Tools Network Detective through 2.0.16.0. A vulnerability exists in the EncryptionUtil class because symmetric encryption is implemented in a deterministic and non-randomized fashion. The method Encrypt(byte[] clearData) derives both the encryption key and the IV from a fixed, hardcoded input by using a static salt value. As a result, identical plaintext inputs always produce identical ciphertext outputs. This is true for both FIPS and non-FIPS generated passwords. In other words, there is a cryptographic implementation flaw in the password encryption mechanism. Although there are multiple encryption methods grouped under FIPS and non-FIPS classifications, the logic consistently results in predictable and reversible encrypted outputs due to the lack of per-operation randomness and encryption authentication.

Use of hard-coded cryptographic key vulnerability in i-PRO Configuration Tool affects the network system for i-PRO Co., Ltd. surveillance cameras and recorders. This vulnerability allows a local authenticated attacker to use the authentication information from the last connected surveillance cameras and recorders.

HiveOS through 0.6-102@191212 ships with SSH host keys baked into the installation image, which allows man-in-the-middle attacks and makes identification of all public IPv4 nodes trivial with Shodan.io. NOTE: as of 2019-09-26, the vendor indicated that they would consider fixing this.

CVE-2023-7003

The AES key utilized in the pairing process between a lock using Sciener firmware and a wireless keypad is not unique, and can be reused to compromise other locks using the Sciener firmware.

Versions of the package cocoon before 0.4.0 are vulnerable to Reusing a Nonce, Key Pair in Encryption when the encrypt, wrap, and dump functions are sequentially called. An attacker can generate the same ciphertext by creating a new encrypted message with the same cocoon object. **Note:** The issue does NOT affect objects created with Cocoon::new which utilizes ThreadRng.

Copypress Rest API 1.1 - 1.2 - Missing Configurable JWT Secret and File-Type Validation to Unauthenticated Remote Code Execution

The Copypress Rest API plugin for WordPress is vulnerable to Remote Code Execution via copyreap_handle_image() Function in versions 1.1 to 1.2. The plugin falls back to a hard-coded JWT signing key when no secret is defined and does not restrict which file types can be fetched and saved as attachments. As a result, unauthenticated attackers can forge a valid token to gain elevated privileges and upload an arbitrary file (e.g. a PHP script) through the image handler, leading to remote code execution.