Re: IIS: using Windows authentication to run server-side malware?

[private private <securecure () gmail com>]

the windows impersonation token does not contain the neccasarry
details(password hash) to authenticate  to a server other than the one
the thread with impersonation context is running on. authorization is
thus isolated to the webserver box.

delegation tokens on the other hand are dangerous.

On 3/23/09, Peter Watkins <peterw () usa net> wrote:
> Lately I've been working with the WindowsImpersonationContext API in
> ASP.Net for some legitimate web applications. And I've started to
> wonder if anyone has done much research on how IIS' integrated
> authentication, especially coupled with Internet Explorer, could be
> used to trick a victim into taking actions of the attacker's choosing
> simply by visiting a web page on a Windows machine in the victim's domain.
>
> It looks like there's a fundamental problem with IIS' use of Windows
> Integrated Authentication. It's not *just* authentication -- when a
> user logs in to an IIS site that uses Integrated Authentication, he not
> merely proves ownership of a domain login account, but implicitly
> grants the IIS server permission to run code on the web server with the
> privileges associated with his AD account. It's authentication plus
> authorization. Think "Run as..." or 'sudo'.
>
> From the white hat web developer's perspective, IIS' integrated
> authentication helps reduce attack surface area and enforce least-
> privilege policies. It helps protect the server against malicious users.
>
> But it also makes the users, and the enterprise resources they
> control, more vulnerable to malicious hosts on the domain. Want to
> trick the HR director into changing your salary? Stop trying to find
> CSRF and SQL Injection flaws in the real HR web app -- write your own
> ASP.Net app that connects to the HR database and changes your salary,
> and then merely get the HR director to visit your app so that your app
> connects to the DB as him. You should even be able to use IIS' URL
> mapping feature to give your /attack.aspx page a URL like /NewLogo.gif,
> and make it output a nice Content-Type: image/gif picture.
>
> Sample attack scenario:
>
> 1) Attacker controls a machine with IIS on the same domain as the victim
>    (or merely controls a web application on a domain member machine that
>     has been configured in IIS to use Windows Integrated Authentication
>     -- and by "domain" I mean Windows/Active Directory domain).
> 2) Attacker's IIS instance is reachable by the victim.
> 3) Attacker's machine is reachable with an unqualified URL
>    (e.g. http://machinename/)
> 4) Victim uses Internet Explorer (IE).
> 5) Victim's browser is configured to use Windows Integrated Authentication
>    for local intranet sites (this is the default setting).
> 6) Victim's IE browser would access the attacker's IIS instance without
>    going through an (explicit?) proxy (again, this is the default).
> 7) Attacker entices victim to open a URL with IE, e.g.
>    http://machinename/MyApp/
> 8) MyApp is written to impersonate the user requesting its web page
>    and execute ASP.Net code as that user.
>
> By default, IE is configured to automatically authenticate to any
> web site that asks for Windows authentication, has a short ("dotless")
> hostname, and is reachable without a proxy. In my experience, it is quite
> typical for enterprises to be configured to use Active Directory's built-in
> DNS features to resolve short hostnames to LAN IP addresses.
>
> So, what's stopping an attacker from tricking a someone else into
> visiting a web app that uses impersonation to take actions using the rights
> and privileges assigned to that other domain user in situations where the
> 8 assumptions I outlined above are true?
>
> (Network configuration, group policy, and other tools could be used to
> address a number of the attack dependencies; I'm just curious how big a
> problem this could be for domains that don't prevent users from treating
> their peers' IIS instances as Local Intranet hosts. And IE is not the
> only attack vector; Firefox supports Windows authentication and can be
> used to transmit Windows credentials to an IIS site, but by default it
> does not automatically provide Windows authentication to web sites.)
>
> As I said, this looks like a fundamental flaw in IIS' Integrated
> Authentication.
> - First, there ought to be an "authentication only" model. It ought
>   to be possible to prove your identity to an IIS web app without
>   giving the app your authority, too.
> - Second, the user interface should clarify whether the web server is
>   asking merely for identification/authentication, or full authorization
>   to act on the user's behalf.
> - Third, any automatic authentication (as for "dotless" hostnames) should
>   default to authentication only.
>
> Background:
>
> Normally the impersonation API is used so that a legitimate app can let
> Windows handle security decisions, and run most code with limited privs
> -- for instance, a CRUD database app could use IIS + Windows Integrated
> Authentication + SQL Server Windows Authentication + impersonation so
> that appropriate users can update the database even while the web server
> and application pool have only connect and datareader privileges on the
> database -- or perhaps no DB privileges at all. Thus the database admins
> can control access, and the web administrators and developers are not
> able to exceed their authorization simply by virtue of controlling one
> part of a multi-tier application.
>
> Here's what typical asp.net impersonation code looks like
>
> // by default, the app runs with limited privileges
> // code here runs as the limited account designated by the web admin
>
> // when IIS requires Windows authentication, the app can do this:
> IIdentity WinId = HttpContext.Current.User.Identity;
> WindowsIdentity wi = (WindowsIdentity)WinId;
> WindowsImpersonationContext wic = wi.Impersonate();
>
> // code here (after Impersonate()) runs as the logged-in web user
>
> wic.Undo();
> // code here runs once again with limited privileges
>
> -Peter
> http://www.tux.org/~peterw/

-- 
Sent from my mobile device