Contents:
A new vulnerability was discovered in Apple’s macOS Finder. This specific vulnerability makes it possible for the attackers to run arbitrary commands on the Mac devices that are running any macOS version up to the Big Sur release.
Zero-day exploits relate to the approach used by attackers to enter and deploy malware onto a system, as explained by my colleague Cezarina.
A zero-day vulnerability is a newly discovered software security issue that has not yet been patched by the authors and can be exploited as a result.
The phrase “zero-day” is a manufactured concept, as this sort of attack occurs in a very short period of time after the security hole is discovered.
As a result, developers will not have enough time to eliminate or minimize the risks associated with this vulnerability as software manufacturers are reactive, not proactive when it comes to zero-day assaults.
What Happened?
Park Minchan is the security researcher that identified the vulnerability.
He managed to pinpoint the fact that the .iInetloc files processed on macOS can be easily used for running malicious commands. These are embedded by an attacker within the document and run commands without any warnings or prompts.
When discussing macOS, the Internet location files having the .inetloc extensions are system-wide bookmarks that can be used to open online resources such as “news://”, “ftp://”, “afp://” or local files “file://”.
A vulnerability in macOS Finder allows files whose extension is inetloc to execute arbitrary commands.
These files can be embedded inside emails which if the user clicks on them will execute the commands embedded inside them without providing a prompt or warning to the user.
Apple apparently decided to fix this flaw silently and without assigning it a CVE identification number.
Unfortunately, it seems that Apple’s patch only managed to partially address the flaw, therefore leaving the vulnerability open for exploits just by changing the protocol used to execute the embedded commands from file:// to FiLe://.
Newer versions of macOS (from Big Sur) have blocked the file:// prefix (in the com.apple.generic-internet-location) however they did a case matching causing File:// or fIle:// to bypass the check. We have notified Apple that FiLe:// (just mangling the value) doesn’t appear to be blocked, but have not received any response from them since the report has been made. As far as we know, at the moment, the vulnerability has not been patched.
According to BleepingComputer, Park Minchan did not provide more information regarding the way in which malicious actors might abuse this bug, but it is believed that it could be used to create malicious email attachments able to launch a bundled or remote payload when opened by the target.