CVE

11 Articles

This Week In Security: Bogus CVEs, Bogus PoCs, And Maybe A Bogus Breach

July 7, 2023 by 3 Comments

It appears we have something of a problem. It’s not really a new problem, and shouldn’t be too surprising, but it did pop up again this week: bogus CVEs. Starting out in the security field? What’s the best way to jump-start a career? Getting a CVE find to your name certainly can’t hurt. And as a result, you get very junior security researchers looking for and reporting novel security vulnerabilities of sometimes dubious quality. Sometimes that process looks a lot like slinging reports against the wall to see what sticks. Things brings us to an odd bug report in the OBS Studio project.

A researcher put together a script to look for possible password exposure on Github projects, and it caught a configuration value named “password” in a .ini file, being distributed in the project source. Obvious credential leak in Git source, right? Except for the little detail that it was in the “locale” folder, and the files were named ca-es.ini, ja-jp.ini, and similar. You may be in on the joke by now, but if not, those are translation strings. It wasn’t leaked credentials, it was various translations of the word “password”. This sort of thing happens quite often, and from the viewpoint of a researcher looking at results from an automated tool, it can be challenging to spend enough time with each result to fully understand the code in question. It looks like this case includes a language barrier, making it even harder to clear up the confusion.

Things took a turn for the worse when a CVE was requested. The CVE Numbering Authority (CNA) that processed the request was MITRE, which issued CVE-2023-34585. It was a completely bogus CVE, and thankfully a more complete explanation from OBS was enough to convince the researcher of his error. That, however, brings us back to CVE-2023-36262, which was published this week. It’s yet another CVE, for the same non-issue, and even pointing at the same GitHub issue where the alleged bug is debunked. There’s multiple fails here, but the biggest disappointment is MITRE, for handing out CVEs twice for the same issue. Shout-out to [Netspooky] on Twitter for spotting this one. Continue reading “This Week In Security: Bogus CVEs, Bogus PoCs, And Maybe A Bogus Breach” →

This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex

December 4, 2020 by 8 Comments

I hope everyone had a wonderful Thanksgiving last week. My household celebrated by welcoming a 4th member to the family. My daughter was born on Wednesday morning, November 25th. And thus explains what I did last week instead of writing the normal Hackaday column. Never fear, we shall catch up today, and cover the news that’s fit to be noticed.

iOS Zero-click Wifi Attack

[Ian Beer] of Google’s Project Zero brings us the fruit of his lockdown-induced labors, a spectacular iOS attack. The target of this attack is the kernel code that handles AWDL, an Apple WiFi protocol for adhoc mesh networks between devices. The most notable feature that makes use of AWDL is AirDrop, Apple’s device-to-device file sharing system. Because AWDL is a proprietary protocol, the WiFi hardware can’t do any accelerated processing of packets. A few years back, there was an attack against Broadcom firmware that required a second vulnerability to jump from the WiFi chip to the device CPU. Here, because the protocol is all implemented in Apple’s code, no such pivot is necessary.

And as you’ve likely deduced, there was a vulnerability found. AWDL uses Type-Length-Value (TLV) messages for sending management data. For a security researcher, TLVs are particularly interesting because each data type represents a different code path to attack. One of those data types is a list of MAC addresses, with a maximum of 10. The code that handles it allocates a 60 byte buffer, based on that maximum. The problem is that there isn’t a code path to drop incoming TLVs of that type when they exceed 60 bytes. The remainder is written right past the end of the allocated buffer.

There is more fun to be had, getting to a full exploit, but the details are a bit too much to fully dive in to here. It interesting to note that [Ian] ran into a particular problem: His poking at the target code was triggering unexpected kernel panics. He discovered two separate vulnerabilities, both distinct from the vuln he was trying to exploit.

Finally, this exploit requires the target device to have AWDL enabled, and many won’t. But you can use Bluetooth Low Energy advertisements to trick the target device into believing an Airdrop is coming in from a trusted contact. Once the device enables AWDL to verify the request, the attack can proceed. [Ian] reported his findings to Apple way back in 2019, and this vulnerability was patched in March of 2020.

Via Ars Technica.
Continue reading “This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex” →

ESP32 Vulnerability Affects Older Chips

September 24, 2020 by 24 Comments

There is a scene from the movie RED (Retired, Extremely Dangerous) where Bruce Willis encounters a highly-secure door with a constantly changing lock code deep inside the CIA. Knowing the lock would be impossible to break, he simply destroyed the wall next to the door, reached through, and opened the door from the other side. We thought about that when we saw [raelize’s] hack to bypass the ESP32’s security measures.

Before you throw out all your ESP32 spy gadgets, though, be aware that the V3 silicon can be made to prevent the attack. V1 and V2, however, have a flaw that — if you know how to exploit it — renders secure boot and flash encryption almost meaningless.

Continue reading “ESP32 Vulnerability Affects Older Chips” →

This Week In Security: Palo Alto Scores A 10, Cursed Images, VM Escapes, And Malicious Music

July 3, 2020 by 12 Comments

We’ve looked at many vulnerabilities over the years here on Hackaday, but it’s rather rare for a CVE to score a perfect 10 severity. This is reserved for the most severe and exploitable of problems. Palo Alto announced such a vulnerability, CVE-2020-2021, on the 29th. This vulnerability affects Palo Alto devices running PAN-OS that have SAML authentication enabled and a certain validation option disabled. The vulnerability is pre-authentication, but does require access to a service protected by SAML authentication. For example, a Palo Alto device providing a web-based VPN could be vulnerable. The good news is that the vulnerable settings aren’t default, but the bad news is that the official configuration guide recommends the vulnerable settings for certain scenarios, like using a third party authentication service.

The issue is in the Security Assertion Markup Language (SAML) implementation, which is an XML based open standard for authentication. One of the primary use cases for SAML is to provide a Single Sign On (SSO) scheme. The normal deployment of SAML SSO is that a central provider handles the authentication of users, and then asserts to individual services that the connecting user is actually who they claim to be.

The setting needed for this vulnerability to be exploitable is ‘Validate Identity Provider Certificate’ to be disabled. If this option is enabled, the SSO provider must use a CA signed SAML certificates. This doesn’t appear to mean that unsigned SSL certificates would be accepted, and only applies to certificates inside the SAML messages. It seems to be widely accepted that these certificates don’t need to be CA signed. In the official announcement, the vulnerability type is said to be “CWE-347 Improper Verification of Cryptographic Signature”. Continue reading “This Week In Security: Palo Alto Scores A 10, Cursed Images, VM Escapes, And Malicious Music” →