One-click Attack

asp:coverstory

One-clickAttack

MitigateWeb Security Pitfalls

By EricRachner

Imaginethat you've been presented with this hyperlink: http://j-random-site.com.For the sake of discussion, let's put aside the particulars of how this linkhas come to your attention and focus on this one question: If you click thatlink, what's the worst that could happen?

There'sthe obvious potential for a barrage of unwanted frames popping up, under, andaround your display almost as fast as you can close them. Or, your browsermight display a security warning - but you know better than to override it.

You'reprobably also aware that the target of any given link might be a page whichcould exploit a cross-site script vulnerability in some other Web-basedapplication. But cross-site script is so 1999. It's an old problem, and Webdevelopers understand it well enough that we're generally able to click onstrange links without much worry.

Thereare, however, other security pitfalls inherent to Web programming, and the purposeof this article is to dissect a particular attack that has gone without dueattention. At Microsoft, we call it the "one-click attack."

Theone-click attack is a technique whereby an attacker constructs a form and aquery string, then causes somebody else's browser to submit them as part of arequest to a Web application - possibly without the victim ever knowing whathappened. The term "one-click attack" reflects that the victim only needs to belured into following a link supplied by the attacker. This technique was firstnoted in 2000 by Jim Fulton, who called it a "client-side Trojan," and again in2003 by Gavin Zuchlinski, who called it "client automation" (an especially aptdescription, perhaps, but also potentially confusing, since "client automation"has a different meaning in the context of COM programming).

The Basic Idea

To startwith, let's contrive a simple scenario to illustrate the problem. Imagine atypical Web application on the Internet, with a page for users to update theire-mail address. (Since ASP.NET's ViewState functionality complicatesmatters slightly, this example uses classic ASP instead. We'll address theASP.NET case in more detail later.) Figure 1 shows what the hypothetical e-mailupdate form might look like.

Figure 1: A typical e-mail update page.

Let'salso imagine that this application, like many others on the Internet, offers apersistent sign-in option whereby cookies are used to spare users the troubleof manually signing in when they visit the site later. This implies that forthe lifetime of the persistent cookie(s), all requests made by a given clientwill be considered pre-authenticated by the application.

Now thatthe stage is set, let's recall the link to http://j-random-site.comthat was presented earlier and imagine that the link is part of an attemptedone-click attack against a user of this application. Let's also suppose thatthe attacker has used a compelling social pretext to lure the victim to clickthe link.

Figure 2shows the source code for the attacker's Web page. Unlike most malicioushackers, the author of this nasty page has thoughtfully commented his code.

1992 BMW850

Black on black,leather interior.

Low miles,lovingly pampered all its life.

First $65.00takes it.

  "http://some-vulnerable-app.com/UpdateEmail.asp"

name="ExploitForm"method="post">

  value="[email protected]">

  value="[email protected]">

  value="Update">

</p><p>&nbsp;&nbsp;HiddenFrame.document.write(</p><p>&nbsp;&nbsp;&nbsp;&nbsp;document.ExploitForm.outerHTML); </p><p>&nbsp;&nbsp;HiddenFrame.document.close();</p><p>&nbsp;&nbsp;HiddenFrame.document.ExploitForm.submit();</p><p>

Figure2: The attacker'smalicious Web page.

As onecan see, when the victim's browser loads the page listed in Figure 2, it willdisplay what appears to be a simple, static page without a hint of anythingsuspicious. But within the invisible IFRAME, a form of the attacker's choice issubmitted to the vulnerable application - by the victim's own browser! Figure 3shows what the request might look like.

POST http://some-vulnerable-app.com/UpdateEmail.asp HTTP/1.1

User-Agent:Mozilla/4.0 (compatible; MSIE 6.0;

  Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR1.1.4322)

Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,

  application/vnd.ms-excel,application/vnd.ms-powerpoint,

  application/msword,application/x-shockwave-flash, */*

Accept-Language:en-us

Cookie:UID=johndoe; PWD=pass!word1; StaySignedIn=1

Content-Length:84

Host:some-vulnerable-app.com

Referer:http://j-random-site.com

Content-Type:application/x-www-form-urlencoded

[email protected]&txt

  [email protected]&btnSubmit=Update

Figure3: The HTTPrequest, which a victim's browser will send to the target application uponviewing the attacker's malicious Web page.

Noticehow the victim's browser has supplied the persistent cookies to the server,which effectively pre-authenticates the request. (This example assumes that theuser selected the "keep me signed in" option.) And notice that the serversimply has no way of knowing whether the user ever saw the input fields,because the HTTP specification provides only that they should be expressed asname = value pairs, with no further information to describe them.

Youmight also have noticed how the only indication of this request's true natureis in the Referer field. Hold that thought, as we'll come back to it.

Now thatthe imaginary request has been submitted, how would the attacker determinewhether the attack was a success? In this case, we can imagine that theapplication offers the typical "Forgotten password" facility, which theattacker can use to retrieve the victim's password by having it e-mailed to thenew address.

Assumptions

Let'sreview what a would-be attacker needs to attempt a one-click attack. The firstprerequisite is a social pretext that will lure the victim into clicking ahyperlink. One should take this as a given, since it only takes a littleimagination to dream up any number of lures. But even more fundamentally, ifcomputing is ever to be trustworthy, then we should all be able to click onunfamiliar hyperlinks without having to worry about our browsers beinghijacked.

Theattacker also needs a Web site to host the page that launches the attack - butnot always. If the target application uses HTTP GET requests to do its thing,then the attacker has the option of using a bare hyperlink to launch theattack. If the vulnerable page in Figure 1 had used the GET method instead ofthe POST method, then the URL to exploit it might look like this:

http://some-vulnerable-app.com/UpdateEmail.asp?txtEmail1=

  [email protected]&txtEmail2=

  [email protected]&btnSubmit=Update

However,one hopes that cases like this are rare, since RFC 2616 very sensibly states,"... the GET and HEAD methods SHOULD NOT have the significance of taking anaction other than [data] retrieval."

Finally,a would-be attacker needs sufficient knowledge of the target application toconstruct request data, which the application will accept. Generally, thismeans that the attacker needs to know the URL of the vulnerable page, the nameof every form field and query string parameter in the page, and what sort ofvalue is expected for each of them.

Limitations

In asense, the one-click attack is a "write-only" technique. The attacker can useit to submit arbitrary requests, but not to view ensuing responses. This isbecause as soon as the request has been submitted, the frame containing it isin the domain of the target application. From this point onward, the browser'scross-frame security ensures that this frame can only be accessed by scriptsthat belong to documents from the same site, denying the attacker a means todirectly view the results. To learn the outcome of a one-click attack, theattacker needs a way to observe the results indirectly, such as through thefunctionality of the application itself.

Theattacker is also limited as to what parts of the victim's request he cancontrol using this technique. The query string parameters and form fields arecompletely within the attacker's control, but cookies are out of reach. Some ofthe request headers, such as User-Agent, are also out of the attacker's reach,but others, such as Server and Referer, can be controlled to varying degrees.

A Sophisticated Attack

To showthe full extent of what's possible with the one-click technique, let's contrivea more sophisticated attack scenario.

Thisarticle includes a mocked-up application called "Direct Deposit" (see end ofarticle for download details). Its purpose is for the employees of Example.comto specify the bank account wherein their paychecks should be deposited.Because Direct Deposit is hypothetically deployed at http://DirectDeposit in aWindows-based intranet, it uses Windows-integrated authentication.

Withmost articles, the sample application is intended to serve as a positiveillustration. That's not the case here. Direct Deposit is deliberately bad codeand you are accordingly cautioned against borrowing from it unless you're sureyou know what you're doing! However, Direct Deposit is functional enough tofollow along as we dissect this attack.

Let'simagine an attacker, and in the tradition of security analysis, let's call herMallory. Mallory is an unscrupulous, soon-to-be former employee of Example.com,and her intention is to use the one-click technique against the Direct Depositapplication to divert the electronic paychecks of as many of her co-workers aspossible to her own bank account.

Mallory'sfirst step is to reconnoiter the Direct Deposit application. She observes thatbefore a user can access the main page of the application, they must agree tothe terms of use by posting a form to http://DirectDeposit/AgreementRequired.aspx.

Thisindicates to Mallory that her attack will require multiple form submissions:The first form will be posted to AgreementRequired.aspx so as to ensure thather victims are permitted to post requests to other parts of the application.

Byviewing the HTML source for AgreementRequired.aspx (excerpted in Figure 4),Mallory observes that her bogus form must supply values for three input fields:btnSubmit, txtIAgree, and __VIEWSTATE.

  action="http://DirectDeposit/AgreementRequired.aspx"

  method=post encType=multipart/form-data>

    value=dDw5MDY0MjE3MTc7Oz52PvgxQDiXzYRwvr6AhlidJFUNrA==

    name=__VIEWSTATEID="Hidden2">

    name=btnSubmit>

    value="I Agree">

Figure4: The maliciousform targeting AgreementRequired.aspx in the Direct Deposit application.

Supplyingvalues for the first two of these input fields is straightforward, but becauseDirect Deposit uses EnableViewStateMac, Mallory can't simply fabricate avalue for __VIEWSTATE. If she were to try it, ASP.NET would reject it alongwith the rest of the form in which it was embedded. But that's just a minor speedbump. Although Mallory can't fabricate a value for the __VIEWSTATE field, sheknows that she can simply extract the one that was given to her by the server,and transfer it into the malicious form she's constructing. Because thetransplanted ViewState blob was originally generated by the applicationserver, Mallory knows it will pass the server's integrity check. (This impliesthat Mallory could not fabricate a form that ASP.NET would accept if she couldnot access the page herself. Of course, if she couldn't access the page, shewould also have a much harder time of learning the names of the form fields itexpects.)

Now thatMallory has constructed a form that will be accepted by AgreementRequired.aspx,she proceeds to the primary target of her attack: DDMain.aspx. Mallory observesthat DDMain.aspx also expects three input fields: btnSubmit, txtAccountNum, and__VIEWSTATE. These input fields aren't substantially different from those inAgreementRequired.aspx, so constructing a form for DDMain.aspx is easy. Thesource for this form is listed in Figure 5.

  action=http://DirectDeposit/DDMain.aspxmethod=post>

    value=dDwtMjcyMTYzMzQyOzs+v8KEz44WadWz8i6jPCmTs6UeiAc=

    name=__VIEWSTATEid="Hidden1">

    name=btnSubmit>

    value="123000045-98765432">

Figure5: The maliciousform targeting DDMain.aspx in the Direct Deposit application. Note that thevalue for the txtAccountNum is the number of the bank account to which Malloryintends to direct the paychecks of her victims.

With herbogus forms ready to go, Mallory embeds them in a Web page such asBMWForSale.htm, which is included with this article. The critical part of thisWeb page is listed in Figure 6.

// Thisfunction copies the first form into the exploit

// frame andsubmits it.

functionBounceFirstForm()

{

  ExploitFrame1.document.write(

    document.AgreementRequired.outerHTML);

  ExploitFrame1.document.close();

  ExploitFrame1.AgreementRequired.submit();

}

// Thisfunction copies the second form into the exploit

// frame andsubmits it.

functionBounceSecondForm()

{

  ExploitFrame2.document.write(

    document.AccountSet.outerHTML);

  ExploitFrame2.document.close();

  ExploitFrame2.AccountSet.submit();

}

  // Mallory uses the setTimeout method toimpose a

  // 3-second delay between the two requestsso that the

  // server has an opportunity to process thefirst request

  // before the second request is submitted.

  BounceFirstForm();

  window.setTimeout('BounceSecondForm();',3000);

Figure6: The script thatMallory's malicious Web page uses to submit the bogus forms.

AllMallory needs at this point is a site on which to host this page, and aconvincing social pretext to lure her victims to it. For the sake of thisexample, we'll suppose that her Web page advertises a car for sale at animpossibly low price. Perhaps an animation of a dancing baby would have a widerappeal? There's always singing hamsters...

Whateverthe bait may be, Mallory can tempt her victims by sending them a spoofed e-mailmessage, or by posting the link on the cork board next to the water cooler.When they visit her Web site, they won't see anything out of the ordinary, andnobody will be the wiser until pay day.

One-click Attacks and Other Authentication Methods

It'salso important to understand how different types of authentication affect theattack scenario. In the preceding examples, we saw how the convenience ofpersistent cookies and Windows-integrated authentication can be used against usby attackers; they enable the browser to submit a request without prompting theuser for any additional information.

WhenHTTP basic, HTTP digest, or client-certificate authentication is used,one-click attacks are still possible, but the attack scenarios are somewhatconstrained. Because the victim's browser must possess a set of cachedcredentials or a session cookie by which to authenticate the bogus request, aone-click attack will only succeed if the user happens to be logged in to thetarget application at the time.

(Windows-integratedauthentication is not always automatic. If the host name for the application isfully qualified - http://server.com as opposed to http://server - then InternetExplorer will prompt the user to enter their credentials instead of attemptingsilent authentication. As an exception, if the fully-qualified server namehappens to be in the user's trusted sites list, then silent authentication willbe attempted.)

Thismight not seem likely in a case such as Direct Deposit, but an attacker'sability to choose the right moment can vary depending on the circumstances. Forinstance, consider an application that shares data between users, such as amessage forum, auction site, or workspace collaboration system. Every time auser adds or changes data that is visible to other users, it provides anindication that they are currently logged in.

Further Implications

Oneshould recognize that a one-click attack can be launched from outside theboundaries of the organization whose application is being targeted. Mallory'sWeb site can be located anywhere on the 'Net, and everything will work fine aslong as her victims' browsers can access both her site and the Direct Depositsite.

Anotherinteresting side effect of using the victim's browser to submit the bogusrequest is that a review of the server logs will show that the illicitrequest(s) originated from the victim's own IP address, using the victim's ownaccount. Perhaps the only hint that the victim did not intend to submit therequest is in the Referer field.

Countering the One-click Attack

Someapplication developers try to mitigate one-click attacks by checking theReferer field. This is a fairly cheap and effective solution, but it has itsdrawbacks. The main problem is dealing with the issues that arise because notevery legitimate request will have a Referer field, such as when the request ismade via document.location or window.open. Moreover, the routine that validatesthe Referer field needs to be made bulletproof, which is easier said than done.

Theindustrial-strength solution to the problem of one-click attacks is to somehowprevent the attacker from being able to assemble request data that the serverwill accept. This is done by requiring a field in the request to contain anelement of data that the attacker can't supply.

Ahypothetical solution is to put a cryptographic hash of the user's session IDin a hidden input field, which we'll call "MagicNumber". When processing arequest, the server computes the hash of the user's session ID and compares itto the value supplied in the MagicNumber field. If it matches, then we know therequest is legitimate, because the attacker should have no way of knowinganother user's session ID.

Forapplications that use GET requests instead of POST requests to performimportant functions, the same approach works in theory: we simply move themagic number into a query string parameter. Unfortunately, this exposes a lotof problems that illustrate why GET requests are inappropriate for commandsthat have side effects.

Themagic number is sensitive information, and if another user learns it, then theyare able to launch a one-click attack. By putting the magic number in the querystring, you run the risk of "leaking" it in any number of ways: If your applicationcan link to other sites, then the magic number will leak to those sites via theHTTP Referer field. The magic number will also linger in the URL history ofyour users' browsers. There's also a usability concern, in that people areconditioned to use copy and paste to share hyperlinks. With sensitiveinformation in the URL, not only is it exposed by users who share hyperlinks,but you also have to worry about a potential usability issue when the magicnumber doesn't match the user's session.

If yourapplication uses HTTP GET requests to perform commands with side effects, Iemphatically urge you to consider using HTTP POST requests instead. Not onlywill you spare yourself the troubles I've just described, but you'll also availyourself of an excellent solution to this problem now available in version 1.1of the Microsoft .NET Framework: ViewStateUserKey.

ViewStateUserKey

ViewStateUserKey is a string property of the System.Web.UI.Pageclass, and it works much like the hypothetical solution described above. ViewStateUserKeymust be set during the Page_Init phase, and to be effective, the value assignedto it must be unique to the current user. The value of ViewStateUserKey is then used as a factor in computing thecryptographic hash, which is used as the ViewState MAC.

Theeffect of this is to make every ViewState MAC as unique to the currentuser as the value of ViewStateUserKey.

Duringthe subsequent Page_Load phase, ASP.NET determines whether the page request isa client postback. If so, then ASP.NET compares the MAC of the user-supplied ViewStatefield with the one it just calculated during the Page_Init phase. If theymatch, then the request is known to be authentic, and processing continues. Ifthey don't match, then ASP.NET throws an HttpException.

Here's asimple illustration of how to use ViewStateUserKeyin an application that uses one of the authentication methods provided byInternet Information Server:

override protectedvoid OnInit(EventArgs e)

{

  // ...

  ViewStateUserKey=Request.ServerVariables["REMOTE_USER"];

  // ...

}

Whenusing forms-based authentication, the remote user is considered anonymous. Inthat case, the REMOTE_USER server variable is blank, so we need an alternativevalue that is still unique to the current user. The session ID is nicely suitedfor that purpose:

override protectedvoid OnInit(EventArgs e)

{

  // ...

  ViewStateUserKey = Session.SessionID;

  // ...

}

Todemonstrate ViewStateUserKey inaction, the Direct Deposit application that accompanies this article has beenequipped with a setting named VulnerableToAttackin its web.config file. When this option is set to anything other than "1",DDMain.aspx will use ViewStateUserKeyto protect users of this application against one-click attacks.

Ifyou've gone to the trouble of installing the Direct Deposit application andverified that Mallory's attack does in fact work, now is the time to "secure"Direct Deposit by setting VulnerableToAttackto "0".

If only it was nearly so easy in real life. But as far as one-clickattacks are concerned, it is.

The sample code in thisarticle is available for download.

EricRachner hasstudied computer security since his teen years and now brings his obsession tobear upon Microsoft's IT department as a Senior Security Analyst. In thiscapacity, Eric searches for ways to attack and abuse the applications uponwhich Microsoft operates, and works with application teams across the companyto reduce risk through improved software design.