RFID hacking & More Vulnerability Shenanigans – Iceman – PSW #834

"The authentication bypass bug, tracked as CVE-2024-2973, scored a perfect 10 rating on both the CVSS 3.1 and CVSS 4 systems, illustrating the seriousness of the issue." - While not (yet) observed in the wild this one has a perfect 10 CVSS score, patches were released out-of-cycle, and there is no workaround. The good news is the patch will only result in 30 seconds of downtime and is only exploitable on routers that run in high-availability mode. Pretty easy to recommend that people just fix this one.

The slight variation provides all of the usernames and passwords on the device: "GreyNoise observed a slight variation in-the-wild which leverages the vulnerability to render a different PHP file to dump account names, passwords, groups, and descriptions for all users of the device. At the time of writing we are not aware of the motivations to disclose/collect this information and are actively monitoring it" - The device in question is EOL, which is not just adding to the list of stuff attackers are now using to build IoT botnets.

"Based on what is currently known about this vulnerability, Wiz Research estimates that widespread exploitation is unlikely. Our reasoning is that currently known exploitations rely on distribution-specific conditions (ASLR for example) and glibc-version-specific struct layouts, which means an attacker must know in advance what Linux distribution they are targeting in order to build a functional exploit. This requirement makes the vulnerability inappropriate for widespread opportunistic exploitation. " - I'm still going with make sure you patch this one. For production Linux servers that are monitored, probably less important as you can put other countermeasures in place. For appliances/embedded OS/IoT, I believe this will be more problematic. Typically these devices have low visibility, making the SSH attack fly under the radar.

These look really cool! I just discovered another potential Flipper Zero alternative: https://github.com/pr3y/Bruce - Currently have it loaded on one of my cardputers, and looking into the expansion modules to give it more functionality (See the wiki for this project for more information).

This makes me want to just run all of my own DNS. Joff was right!

"Our attack identifies a protocol vulnerability in the way RADIUS uses MD5 that allows the attacker to inject a malicious protocol attribute that produces a hash collision between the server-generated Response Authenticator and the attacker's desired forged response packet...In addition, because our attack is online, the attacker needs to be able to compute a so-called chosen-prefix MD5 collision attack in minutes or seconds. The previous best reported chosen-prefix collision attack times took hours, and produced collisions that were not compatible with the RADIUS protocol.

I've not seen or heard about speculative execution attacks occurring the wild, therefore, many just give these a really low priority. Is this true? Are attackers using them? If so, or not, how would we detect them?

This happened to the node-ip project, 17 million downloads weekly. Someone filed a CVE for a bug that does not have a security impact and has also been fixed. The Github repo switched to read-only mode as they were getting so many comments and such. This vulnerability reporting problem is still a mess. Crux of the issue is here: "While I didn't really intend the module to be used for any security related checks, I'm very curious how an untrusted input could end up being passed into ip.isPrivate or ip.isPublic [functions] and then used for verifying where the network connection came from."

The CVE is from 2018, yet this is still a current issue? I'm still trying to unravel this one. So weird: "However, a CVE ID was not obtained as part of the fix outlined above, leaving the vulnerability without a public identifier. In April of 2024, Binarly discovered that the lighttpd vulnerability was still present in a number of products, presenting a supply-chain risk. The lack of CVE ID rendered the security fix invisible to projects that utilize earlier versions of lighttpd. Many organizations depend on a public CVE ID record to initiate security fixes and apply software updates. Binarly also documented many implementations of lighttpd (versions 1.4.50 and earlier) that allowed for a different set of attacks that can leak memory and access sensitive data. The supply-chain impact of this vulnerable software includes multiple products as highlighted in the blog by runZero. The lighttpd project has now obtained CVE-2018-25103 to identify this vulnerability and to alert supply-chain partners to implement the required fix."