A security vulnerability report arrived that claimed to have achieved code execution via a shortcut (LNK) file. The report was somewhat convoluted, but it went something like this:
- Start with this pre-fabricated shortcut file.
- Copy it to a folder of your choosing.
- Edit the shortcut file in this very special way, substituting the full path to the shortcut file where specified.
- Double-click the shortcut file.
- Code execution is achieved!
If you can trick the user into double-clicking an arbitrary shortcut file of your choosing, then you don’t have to do all this weird special editing nonsense.
- Create a shortcut that runs
pwnzor.exedirectly from an Internet-accessible file share. - Double-click the shortcut file.
- Code execution is achieved!
When phrased this way, it’s clear that the attack is really a social engineering attack: If you can convince a user to do anything you tell them to, then you can get them to do anything.
This in itself is not particularly interesting.
Upon closer inspection, what the finder was actually reporting was that they found a clever way to make a file both a legal LNK file and a legal script file. The “Edit the shortcut file in this very special way” was setting things up so that the LNK file could feed itself to the script engine.
This was an interesting discovery, the ability to polyglot a LNK file with a script file. But it’s not a security vulnerability. It’s just a curiosity.
Because you still have to convince the user to run it.
The real vulnerability here is:
1. Give long instructions.
2. Reader gives up reading your instructions and just click the link.
3. Pwned.
It’s a vulnerability widely exploited by lawyers. They write interminable and incomprehensible license agreements. You don’t read it because it’s too convoluted. You agree to anything they say.
I’m deeply unclear whether the comments are disagreeing that this is a social engineering attack and not a security boundary violation, or if they believe Microsoft should be in the business of preventing anyone from doing anything interesting if it could ever possibly result in a social engineering.
It turns out that both malware and users like to be able to muck with desktop shortcuts while in user mode.
Many places I've worked at the IT guys set up your computer so it has N links on your desktop to go to Contoso Lotus Notes, Contoso TimeSheet Manager, Contoso HR Probation Manager, Contoso HR Videos, shortcuts to "Network Shares" that are located in Beumon Texas and never respond, etc, etc, etc. After a few weeks of using those you get conditioned to "the IT guys add and delete desktop Icons and they all...
If you have found a way to deploy shortcuts to other people’s desktops, then that is the interesting vulnerability. The shortcut itself doesn’t need to be one of these fancy polyglots. It could just be a shortcut to pwnz0r.exe. Because the vulnerability is in getting the shortcut onto the machine and convincing the user to launch it.
Where things get ugly is when:
1) A user runs an application in user-mode and the application adds a camouflaged shortcut to the user's desktop (the application could just as easily launch pwnzor.exe).
2) The user launches the camouflaged short-cut, thinking it was added by IT (or added by the user, if it replaced an existing shortcut). The user clicks "yes" on the UAC prompt.
Mind you, it's not Microsoft's responsibility to block this sort of...
If the user could click “Yes” on UAC prompt, the user is already an administrator. Given that you can already bypass UAC by injecting bogus environment variable for disk cleanup, this isn’t a very interesting attack. For the best security, one should use LUAs instead.
While this is entirely true, dismissing the issue entirely seems dubious on its own. If a feature has a specification or contract dictating what its behavior is and how it's intended to work, and the feature can be used in such a way that it enables behavior outside of that contract, that's most certainly a concern. Perhaps not a security vulnerability, no, but it is a sign that the implementation has weaknesses and could either...
This is nothing about using the feature in a manner it wasn't intended. This is like saying "I found an exploit in the C compiler. I found a way to compile this shell script!" What you found is a polyglot, which is a curiosity but not a security vulnerability. The extra tweak is to make the program, when run, re-launch itself as a shell script. Which is a neat trick, but that's about it.
Making a compiler compile a file that contains features of multiple languages is one thing. The compiler is behaving according to the contract and the file complies with that contract (and coincidentally complies with another contract). The way you're describing this, though, is that the Shell is opening the LNK file and executing arbitrary code as a script. That sounds like something well outside of the contract and scope for how the Shell should be...
It's the latter. It's a perfectly valid LNK file that says "I am a shortcut to this script," where the path to the script is... the link file itself. The manual editing of the LNK file is in order to patch in the path to itself. The script is embedded in a place that the LNK file parser doesn't care about when executing the link. I forget where, but for the sake of discussion, let's...