CVE-2023-43010: Apple Backports WebKit Fix to Counter Coruna Exploit Kit
Saw the news drop today regarding Apple's decision to backport fixes for CVE-2023-43010. It looks like the Coruna exploit kit is actively leveraging this WebKit vulnerability against older iOS and iPadOS versions. While macOS Sonoma got a look-in, the primary concern here is the legacy mobile fleet still running older OS iterations.
The flaw centers on memory corruption in WebKit when processing maliciously crafted web content—classic RCE territory. What's interesting is the decision to backport. Usually, vendors leave older EOL (or near EOL) devices to rot. The fact that Coruna is chaining this suggests significant exploitation in the wild.
For those managing MDMs, you need to verify compliance immediately. We're currently ingesting mobile crash logs into our SIEM to look for indicators preceding the exploit. Here is a basic KQL query we're using to hunt for suspicious MobileSafari terminations that might indicate an exploit attempt or crash:
DeviceProcessEvents
| where InitiatingProcessFileName =~ 'MobileSafari'
| where ActionType in ('ProcessTerminated', 'ProcessHung')
| where Timestamp >= ago(7d)
| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessExitCode
| summarize count() by DeviceName, ProcessExitCode
| where count_ > 5
If you have devices stuck on older versions that can't upgrade to the latest point release, how are you handling the risk? Are you blocking Safari or pushing content filters?
Good catch on the KQL. From an MSP perspective, this is a headache. We have a lot of clients on older iPads used as kiosk terminals that can't run the newest iOS. We've resorted to a restrictive configuration profile via Jamf that effectively locks down Safari and forces traffic through our secure web gateway. Here’s a quick EA script I whipped up to flag vulnerable build versions:
#!/bin/bash
osVersion=$(sw_vers -productVersion)
if [[ "$osVersion" VULNERABLE"
else
echo "PATCHED"
fi
If you can't patch, you have to isolate the device.
The Coruna EK is particularly nasty because it's often delivered via malvertising on otherwise legitimate sites. Patching is ideal, but detection is key for the lag time between update and deployment. I'd recommend checking your proxy logs for unusual User-Agent strings or large POST responses from ad networks, which is often how the payload is staged before the WebKit exploit triggers.
Also, verify if your MDM supports 'Advanced Threat Protection' for web content to filter this stuff before it hits the browser rendering engine.
This reinforces why we shouldn't rely solely on vendor patch cycles for 'legacy' gear. If you have these older devices on the corporate network, segment them immediately. Treat them as untrusted. A compromised WebKit browser is a fantastic pivot point for lateral movement if the device has access to internal file shares or VPN credentials.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access