So a .LNK is just a special case of scripting executable file. Now, reading the last line of the article, the quote from the spokesperson, seems to indicate that security warnings are already enabled for an untrusted .LNK downloaded from the Internet. It seems that both iOS and Windows are now flagging any executable that's downloaded as "untrusted", until the user plows through the warnings to run it anyway.
So if .LNK is treated as .EXE and .COM and .BAT, then I would say that there is parity there. Unfortunately, typical users aren't sophisticated enough to recognize that a .LNK is an arbitrarily-coded script file, nor to inspect it closely enough when these Evil North Koreans found a way to obfuscate it.
We're still at a level where typical troubleshooting instructions include: "destroy all your data/cookies/cache, disable your firewall & anti-malware, and run this with admin privileges" because sure enough, those pesky security measures can indeed interfere with legitimate operations.
It's the same thing when you tell users to "check the full URL on preview to make sure it's OK before you click it." Well, bud, I'll show you punycode, and link shortener/redirection, and thousands of legitimate gTLDs, and weighing that against the expertise of a typical consumer on what a "valid URL" looks like, not going to help.
The thing is that Windows does not show the .lnk Ending, same for .pif (which can just be a normal MZ Windows EXE), even if all other endings are shown. So your bill.pdf.lnk is shown as bill.pdf, while bill.pdf is also shown as bill.pdf.
(This may have changed with new versions of Windows 11, I'm stopped working in this area a few years back)
It's nice to have conventions that say "PDF is a certain type of file format handled by such-and-such application", but the days are long gone when the file extension was the first and last word for that function.
Windows and every other OS has a complex system that takes into account "mime-types" and custom application handlers, and the whole configuration is quite malleable. The GUI icon accompanying a file is often a more reliable indicator of what's going to launch when you click it. Of course, as files get transferred over the network and shared among heterogeneous systems, that association may ultimately rely on nothing else but the extension when the content-type system doesn't work as designed.
> users are unlikely to detect that they're LNK files
LNK format is a Windows shortcut, which is a signature design feature of Windows 95 and later. It's working as intended, as a soft-link to some other type of file. So of course it is supposed to depict the handler that opens link target, and hide the shortcut-ness, although you should usually also see a curly-arrow at the lower-left side of a shortcut icon. There have been ways to suppress the arrow, but its presence is a dead giveaway of the LNK nature of the icon you're clicking, in the GUI under normal circumstances. Surely it is also distinguishable through PowerShell.
The bottom line is that users are accustomed to reading ideograms, animations, and GUI cues just as well, or better, than the accompanying text, and graphical expressions are becoming mandatory in order to properly describe a button, a widget, an application, or whatever GUI element is in question. Describing them is a whole other ball of wax, especially if you try to do it over the telephone!
Furthermore, I don't know how much uncharted territory is involved with Unicode homoglyphs and file extensions, but it's worth considering whether your freshly downloaded file is named in a mixture of Cyrillic, Turkish, and Icelandic scripts, with ZWJ and other potential shenanigans.
>"We told Microsoft but they consider it a UI issue, not a security issue. So it doesn't meet their bar for servicing as a security update, but it might be fixed in a later OS version, or something along those lines."
This reads like someone at Microsoft looked at the issue and decided that this issue is technically "not my job".
Lots and lots of words, but tl;dr seems to be that it's just the .lnk equivalent of someone adding `logout` to your .bashrc, prepending it with a couple hundred spaces, and hoping your favorite editor doesn't have line wrap turned on. Except here, it's a fixed-width one-line GUI textbox, so there's no vertical space for line wrap, and the "hidden" commands are not a prank.
If the overall info on exploitation is accurate, it's quite surprising just how far one can go with most trivial of tricks.
So you can change the icon of a shortcut and rename it to something misleading? That's an awfully weak "exploit". No wonder it was given a "ZDI-CAN" number (whatever that is) instead of an actual CVE.
I don't particularily agree with some of their philosophy, but they are smart folks and valuable to monitor alongside CVE. It's not like it's some backalley discount version of CVE. They've been around for 20 years, after all.
So if .LNK is treated as .EXE and .COM and .BAT, then I would say that there is parity there. Unfortunately, typical users aren't sophisticated enough to recognize that a .LNK is an arbitrarily-coded script file, nor to inspect it closely enough when these Evil North Koreans found a way to obfuscate it.
We're still at a level where typical troubleshooting instructions include: "destroy all your data/cookies/cache, disable your firewall & anti-malware, and run this with admin privileges" because sure enough, those pesky security measures can indeed interfere with legitimate operations.
It's the same thing when you tell users to "check the full URL on preview to make sure it's OK before you click it." Well, bud, I'll show you punycode, and link shortener/redirection, and thousands of legitimate gTLDs, and weighing that against the expertise of a typical consumer on what a "valid URL" looks like, not going to help.