Looking for some help, my company might not be able to fully patch CVE-2023-4863 aka BLASTPASS for a few days. Does anyone know a way of detecting exploitation of this through Splunk? Can you see it in web server logs? Next-gen firewall? WAF? I’m not seeing much info online about how to detect the exploitation.
CVE-2023-4863 (CVSSv3: 8.8 high severity, disclosed 11 September 2023 by Google as a Zero-Day with an exploit in the wild, added to CISA's Known Exploited Vulnerabilities (KEV) Catalog on 13 September 2023) is a heap buffer overflow in libwebP. A remote attacker could perform an out of bounds memory write via a crafted HTML page.
CVE-2023-4211 (pending CVSSv3 score, disclosed 02 October 2023 by Arm as a Zero-Day under limited targeted exploitation as reported by Google Threat Analysis Group/Google Project Zero, added to the KEV Catalog on 03 October 2023). A local non-privileged user can make improper GPU memory processing operations to gain access to already freed memory.
@thijs Ben Hawkes links #CVE20234863 (the original webP vulnerability) to the Apple Zero-Day #CVE202341064 which was exploited in a "zero-click" attack.
My understanding is that the image decoding of the maliciously crafted webP file is not done by the user but by the system. If the user visits an attacker-controlled or compromised website which displays the webP file... or if the email contains the maliciously crafted webP file (see Mozilla Thunderbird). Not to mention that hundreds or possibly thousands of other applications incorporate libwebp, so the attack could come from Discord, Teams, Slack, 1Password, Tor, Vivaldi, Brave, Signal, Telegram, ffmpeg, Gimp, LibreOffice. etc.
But this seclists thread seems to say that CVE-2023-5129 is associated with libwebp commits that are different from the fixes associated with CVE-2023-4863 [Edit: but these are described by the issuer as cleanups]:
The seclists poster is reaching out to double-check whether it's new. Solar Designer's assessment is that it's probably the same (but that the cleanups in the code should be examined anyway):
Roughly 2 weeks ago Google patched a critical vulnerability, CVE-2023-4863, that was being exploited in the wild. The broad impact of the root cause of the vuln and the fact that it will have a long tail of unpatched software has been poorly communicated. You can read more in @dangoodin 's excellent article on Ars Technica.
As pointed out in the article above, Electron is based on Chromium and is impacted. Electron is bundled in a ton of apps that people might overlook.
I threw together the following shell command to help macOS audit which versions of Electron apps are installed.
find /Applications -type f -name "*Electron Framework*" -exec <br></br> sh -c "echo "{}" && strings "{}" | grep '^Chrome/[0-9.]* Electron/[0-9]' | head -n1 && echo " ;<br></br>
When run, you should see something similar to the following:
/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework<br></br>Chrome/114.0.5735.289 Electron/25.8.1<br></br><br></br>/Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework<br></br>Chrome/116.0.5845.188 Electron/26.2.1<br></br>
In my earlier thread I should have recommended that folks be on the lookout for end of life(EoL) versions of Electron that are bundled with software that is itself updated to the latest version. I've observed a case where fully updated software was using Electron 22.x.x that isn't EoL yet, but will be in 2 weeks. In those cases I strongly suggest you notify your vendor and, if it is paid software, pressure them to migrate to a supported version ASAP.
Note: There IS a patched version of 22.x.x which is 22.3.24.
The #WebP buffer overflow bug that caused all the major browsers to issue patches earlier this week (e.g. #Firefox 117.0.1) also affects applications built with Electron. #1Password issued an update today for their Mac build.
The CVE affects the underlying webp library, not just web browsers, so this will be an ongoing issue.
"Who uses #libwebp?
"There are a lot of applications that use libwebp to render WebP images, I already mentioned a few of them, but some of the others that I know include: #Affinity (the design software), #Gimp, Inkscape [not according to Martin Owens, see comment below], #LibreOffice, #Telegram, #Thunderbird (now patched), #ffmpeg, and many, many #Android applications as well as cross-platform apps built with #Flutter."
If you are unable to update ASAP, I imagine that disabling "image.webp.enabled" in about:config could in theory assist in avoiding this exploit being executed? However, please take that solely as a theory and not concrete evidence.