According to Microsoft it is not a security concern: UAC is rendered useless by the possibility of an unprivileged session to modify shortcuts to point at an identical looking executable which can silently run malicious code with admin approval, Windows defender would not help much.
I have told them to fix this issue by limiting unprivileged sessions to only point at unprivileged executable, they replied by saying that unless I could demonstrate admin's desktop being modified by another user, they won't be concerned. In reality though, too many computers only have one user account who is also admin. Apparently the admin account was never meant for daily activity, UAC must be there to provide false sense of security, together with Windows defender, I would really like to see how it could currently stop a trojan daring to create desktop shortcuts. Remote execution scenario: The user has shortcuts in his system, some of these point at programs which require admin rights to be run. The attacker lures the user into running an application that does not contain any threat currently recognizable by windows defender, the executable A. Executable A does not require admin rights to run, it can't access any sensitive files, system settings and other user's; UAC and privilege policies exist for to ensure this. In contrast, Windows allows user sessions to modify shortcuts, such as those in the desktop and start menu; executable A can modify the path field of them, to point at executable B. Executable B requires admin rights to be run, executable A creates various copies of it, one for each shortcut that has been modified, each executable can be given the proper icon from the original program executable. Executable B downloads sensitive information, files, cookies, into the attacker's machine, with admin approval, thus without triggering Windows Defender. UAC dialog is used against the admin, who launches his own shortcut which have been previously modified by executable A. UAC has two protective measures in its prompt. 1) Highlighting of unknown certificate of the executable. 2) The possibility to check the path of the executable. The first measure is useless whenever the target shortcut is originally pointing at an unknown source's program. The second works only if the admin decides to see more info in the UAC prompt. Steps to reproduce: executable A can contain a powershell script that finds shortcuts and modifies them to point at executable B ls $home/Desktop/* -fil *.lnk|%{$lnk=new-object -ComObject wscript.shell.createshortcut($_);$lnk.targetpath="path/to/executable/B.exe"; $lnk.save() etc.. Executable B can be made by echoing malicious code to a batch script and converting it into an executable. Icons can also be included in the executable to make it look exactly like the original. This can also be done by executable A. The original program can also be launched as expected, and forensic evidence cleared. When the user will run executable A, his desktop shortcuts will be altered unnoticeable, to point at executable B. When the user will give admin rights to his application's shortcut, executable B is run. Shortcuts from the public desktop can't modified without admin rights, but can be moved to the ordinary desktop and modified. Suggested solution to MSRC: UAC dialog must always show the full path, or alternatively, prevent unprivileged sessions to create shortcuts pointing to UAC enabled executables. - All vain, have fun. P.S. Outlook client puts their mails in the junk folder, too much copy and paste I believe. _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/