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.

Podatne kontrolery domeny Samba Active Directory wystawiają bilety Kerberos zaszyfrowane słabym algorytmem RC4-HMAC, nawet jeśli serwer docelowy obsługuje silniejsze szyfrowanie (np. AES256). Stanowi to poważne zagrożenie dla bezpieczeństwa infrastruktury opartej na Kerberos, umożliwiając potencjalne ataki na poświadczenia.

Systemy Econolite EOS w wersjach przed 3.2.23 używają słabego algorytmu MD5 do szyfrowania danych uwierzytelniających uprzywilejowanych użytkowników. Plik konfiguracyjny zawierający te dane jest dostępny bez uwierzytelnienia, co umożliwia atakującemu przejęcie kont administratorów i techników.

Algorytm MD5 nie jest odporny na kolizje, co umożliwia atakującym przeprowadzanie ataków spoofingowych. Szczególnie niebezpieczne jest wykorzystanie MD5 jako algorytmu podpisu w certyfikatach X.509, gdzie podatność pozwala na sfałszowanie certyfikatu.

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.

Biblioteka CryptoES w wersjach przed 2.1.0 implementuje funkcję PBKDF2 z domyślnymi ustawieniami, które są co najmniej 1 300 000 razy słabsze niż obecny standard branżowy. Podatność dotyczy każdej aplikacji wykorzystującej CryptoES do ochrony haseł lub generowania podpisów kryptograficznych.

Biblioteka crypto-js w wersjach przed 4.2.0 implementuje funkcję PBKDF2 z domyślnymi ustawieniami czyniącymi ją co najmniej 1 300 000 razy słabszą niż wymaga obecny standard branżowy. Podatność stanowi poważne zagrożenie dla bezpieczeństwa haseł i podpisów kryptograficznych chronionych za pomocą tej biblioteki.

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)

R-SOFT DMS przechowuje dane uwierzytelniające superadministratora przy użyciu zagnieżdżonego skrótu MD5 bez soli, co umożliwia atakującemu, który uzyska plik z hashem, odtworzenie hasła. Podatność jest szczególnie groźna, ponieważ hasło superadmina można zmienić wyłącznie poprzez ręczną modyfikację pliku konfiguracyjnego.

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.