CWE-328

Urządzenie GNCC GP5 w wersji v7.1.76 chroni hasło użytkownika root przy użyciu słabego algorytmu haszowania, co stanowi poważne zagrożenie bezpieczeństwa. Atakujący może odtworzyć hasło root metodą brute-force i przejąć pełną kontrolę nad urządzeniem.

Podatność umożliwia nieuwierzytelnionemu atakującemu zdalne ominięcie mechanizmu autoryzacji urządzenia. Krytyczny poziom zagrożenia wynika z możliwości przejęcia kontroli nad urządzeniem bez posiadania prawidłowych danych logowania.

Urządzenie wykorzystuje słaby algorytm hashowania do tworzenia skrótów haseł, co umożliwia atakującemu łatwe odtworzenie oryginalnego hasła. Podatność ma krytyczny wpływ na bezpieczeństwo i integralność urządzenia.

Since the Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability was disclosed by Microsoft on Nov 8 2022 and per RFC8429 it is assumed that rc4-hmac is weak, Vulnerable Samba Active Directory DCs will issue rc4-hmac encrypted tickets despite the target server supporting better encryption (eg aes256-cts-hmac-sha1-96).

Econolite EOS versions prior to 3.2.23 use a weak hash algorithm for encrypting privileged user credentials. A configuration file that is accessible without authentication uses MD5 hashes for encrypting credentials, including those of administrators and technicians.

The MD5 Message-Digest Algorithm is not collision resistant, which makes it easier for context-dependent attackers to conduct spoofing attacks, as demonstrated by attacks on the use of MD5 in the signature algorithm of an X.509 certificate.

Ecommerce Systempay 1.0 wykorzystuje słabą implementację kryptograficzną (SHA1) do ochrony 16-znakowego klucza produkcyjnego używanego do podpisywania płatności. Podatność umożliwia atakującemu odgadnięcie klucza metodą brute force, a następnie fałszowanie podpisów transakcji i manipulowanie kwotami płatności.

Serwer ASU (Attended Sysupgrade Server) dla dystrybucji opartych na OpenWrt stosuje obcięte do 12 znaków skróty SHA-256 do identyfikacji żądań budowania obrazów, co drastycznie obniża entropię i umożliwia atakującemu wygenerowanie kolizji. W połączeniu z podatnością command injection w Imagebuilderze pozwala to na podrzucenie złośliwego firmware'u podpisanego legalnym kluczem budowania.

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.

crypto-js is a JavaScript library of crypto standards. Prior to version 4.2.0, crypto-js 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 4.2.0 contains a patch for this issue. As a workaround, configure crypto-js to use SHA256 with at least 250,000 iterations.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 22.0.1, 21.2.17, and 20.3.25, Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in TransferState using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., q=aaCAZMMM for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., /api/user/profile). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the TransferState cache. This vulnerability is fixed in 22.0.1, 21.2.17, and 20.3.25.

MD5 Checksum Bypass vulnerabilities where found exploiting a weakness in the way an application dependency calculates or validates MD5 checksum hashes.  Affected products: ABB ASPECT - Enterprise v3.08.01; NEXUS Series v3.08.01; MATRIX Series v3.08.01

An issue in beego v.2.2.0 and before allows a remote attacker to escalate privileges via the getCacheFileName function in file.go file

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”

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.

soroban-poseidon provides Poseidon and Poseidon2 cryptographic hash functions for Soroban smart contracts. Poseidon V1 (PoseidonSponge) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (inputs.len() < T - 1), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector [m1, ..., mk] hashed with a sponge of rate > k, hash([m1, ..., mk]) equals hash([m1, ..., mk, 0]) because both produce identical pre-permutation states. This affects any use of PoseidonSponge or poseidon_hash where the number of inputs is less than T - 1 (e.g., hashing 1 input with T=3). Poseidon2 (Poseidon2Sponge) is not affected.

### Impact When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized. This is similar to [a prior advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf), which provided an inadequate fix for the hash collision part of the vulnerability. ### Patches The following steps are required to mitigate this risk. 1. Upgrade to a version of the library where a fix is available. 1. Review the steps in [this previous advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf) to ensure you have your application configured for untrusted data. ### Workarounds If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows: 1. Declare a class that derives from `MessagePackSecurity`. 2. Override the `GetHashCollisionResistantEqualityComparer<T>` method to provide a collision-resistant hash function of your own and avoid calling `base.GetHashCollisionResistantEqualityComparer<T>()`. 3. Configure a `MessagePackSerializerOptions` with an instance of your derived type by calling `WithSecurity` on an existing options object. 4. Use your custom options object for all deserialization operations. This may be by setting the `MessagePackSerializer.DefaultOptions` static property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to any `Deserialize` method. ### References - Learn more about best security practices when reading untrusted data with [MessagePack 1.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp/tree/v1.x#security) or [MessagePack 2.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp#security). - The .NET team's [discussion on hash collision vulnerabilities of their `HashCode` struct](https://github.com/GrabYourPitchforks/runtime/blob/threat_models/docs/design/security/System.HashCode.md). ### For more information If you have any questions or comments about this advisory: * [Start a public discussion](https://github.com/MessagePack-CSharp/MessagePack-CSharp/discussions) * [Email us privately](mailto:andrewarnott@live.com)

jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n²) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.

Actualizer is a single shell script solution to allow developers and embedded engineers to create Debian operating systems (OS). Prior to version 1.2.0, Actualizer uses OpenSSL's "-passwd" function, which uses SHA512 instead of a more suitable password hasher like Yescript/Argon2i. All Actualizer users building a full Debian Operating System are affected. Users should upgrade to version 1.2.0 of Actualizer. Existing OS deployment requires manual password changes against the alpha and root accounts. The change will deploy's Debian's yescript overriding the older SHA512 hash created by OpenSSL. As a workaround, users need to reset both `root` and "Alpha" users' passwords.

Certain switch models from PLANET Technology only support obsolete algorithms for authentication protocol and encryption protocol in the SNMPv3 service, allowing attackers to obtain plaintext SNMPv3 credentials potentially.