WebApp Sec mailing list archives
IIS: using Windows authentication to run server-side malware?
From: Peter Watkins <peterw () usa net>
Date: Sun, 22 Mar 2009 20:53:08 -0400
Lately I've been working with the WindowsImpersonationContext API in ASP.Net for some legitimate web applications. And I've started towonder 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 WindowsIntegrated 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 implicitlygrants 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 theycontrol, 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 the8 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 sothat 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 onepart 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/
Current thread:
- IIS: using Windows authentication to run server-side malware? Peter Watkins (Mar 22)
- Re: IIS: using Windows authentication to run server-side malware? private private (Mar 26)