The luring attack is a type of elevation of privilege attack where the attacker "lures" a more highly privileged component to do something on his behalf. The most straightforward technique is to convince the target to run the attacker's code in a more privileged security context (WhatIsSecurityContext).

Imagine for a moment that you normally log in to your computer as a privileged user, perhaps as a member of the local Administrators group. An aquaintance sends you a zipped executable file and asks you to run it. You unzip the file to your hard drive and see a program called gophers.exe. Now let me state up front that you should never run code on your machine that you don't trust. The following example shows that even the precaution of running untrusted code under a low-privilege user account often won't save you.¹

Say you add a new local account to your machine called UntrustedUser: a normal, restricted user account. Then you use the secondary logon service (HowToRunAProgramAsAnotherUser) to run gophers.exe under the restricted account, thinking to yourself what a great little sandbox Microsoft has provided with the runas command. Because you keep all of your personal files under your profile directory, gophers.exe won't be able to access them because of the ACLs that restrict access to your user profile (WhatIsAUserProfile). Because your mail settings are under your profile as well, gophers.exe won't be able to send malicious e-mail to anyone in your name. The program runs fine, and you laugh as you watch it animate 500 dancing gophers and play a silly tune.

The next day you recieve hate mail from a few of your friends who wonder why you sent them e-mails with embedded images of gopher porn. You also discover that some new files have been added to your System32 directory! What the heck happened? You just got suckered by a very simple luring attack. When gophers.exe started up, it checked to see if it was running in a privileged security context by peeking at the groups in its token (WhatIsAToken). On discovering its lack of privilege, it took a gamble that the interactive user might actually be logged in with more privileges, so this obnoxious little program simply lured explorer.exe into launching another instance of gophers.exe. It did this by calling a few functions in user32.dll. First it sought out Explorer's Start button and posted a WM_LBUTTONDOWN message to it; then, with a little SendKeys magic, it brought up the "Run..." dialog from the Start menu, entered the full path to gophers.exe, and simulated pressing Enter. Explorer was happy to launch the program, as it had no idea that the interactive user wasn't really in control anymore, and when the new copy of gophers.exe started up it inherited a copy of Explorer's token (WhatIsAToken). Through this simple luring attack (which is just a few lines of code), the attacker not only compromised your documents and e-mail, but, since you were logged in with high privilege, also compromised your operating system. What fun! Figure 7.1 shows a picture of this attack.

Figure 7.1 A luring attack mounted by evil gophers

Look for luring attacks whenever you try to create a sandbox for code that you don't fully trust. The CLR's code access security infrastructure is a great example of a place where luring attacks are taken very seriously. Because managed code from different assemblies can run in the same process with varying degrees of trust, any partially trusted assembly must be verified for type safety, and each full-permission demand performs a stackwalk to ensure that a less trusted component isn't luring a more trusted component into doing its dirty work. Window stations WhatIsAWindowStation) were invented way back in Windows NT 3.5 to prevent luring attacks from daemons (WhatIsADaemon) against the interactive user.

Given luring attacks, you might wonder why I suggest in HowToDevelopCodeAsANonAdmin that as a developer you should log in using a low privilege account while keeping a high-privilege Explorer window and/or a command prompt open so you can administer the machine when necessary without having to log out. This clearly exposes you to luring attacks, but if you were simply running as admin all the time before you read my chapter and changed your evil ways (grin), you would certainly be no less secure now than you were before. No luring attack was necessary before — you were running all programs with high privilege directly. As with any security decision, you always need to balance productivity with the threat level (WhatIsThreatModeling). Someday you may find yourself on a development machine so sensitive that you aren't even allowed to know an admin password for the machine.

¹ Programs are a lot like hamburgers: If someone off the street handed you one, would you feel safe eating it? Ask yourself this question next time someone gives you a program to run!

PortedBy ChrisTavares