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/
