I have an IIS6 And II7 servers under my management.
all my application pools are running under a custom account which is a member of the IIS_IUSRS
Some of the websites on the webserver were hacked and malicious asp.net files was uploaded to the server.
Those files were used to act as a medium between the attacker and the OS to execute code
I have noticed that the user under which the application pool was running was able to list all the directories of my server and was actually a part of "Authenticated users" and hence "users" group which by default have permissions to execute files/create folders etc.
The hackers were able, using the application pool credentials, to be authenticated as an authenticated user and since authenticated user is part of the users group they were able to do what they want
you can easily recreate the issue by using process explorer to view a worker process security groups.
My Questions are:
How should I secure correctly my server if I want to run the application pool as custom user and not as the built in identitty pool identity ? ( the reason I need to is because I'm using websitepanel management software )
Is something wrong in my config or is it possible that on every MS server that uses custom user as the identity and has some security flaw in the website, a hacker can cause havoc to the entire server ?
Related
There is a similar question pertaining to my topic here, but it doesn't fully satisfy the issue I'm having. Going off the question in the link, how would the apppool identity get used as the current user? My application actually gets the users out of a SQL db, but the apppool identity is not in the db, yet still gets logged as the current user. Thanks in advance!
Your appPool identity IS the current user, as far as IIS is concerned. IIS has no knowledge of any account that you are storing in your application's SQL database. When you enable Anonymous authentication, you can change the account that IIS uses to access your sites and applications. By default, IIS 7 uses "IUSR" as the user name for anonymous access, however you can change this to "Application pool identity" if you want to restrict access that way."IUSR" user name is created when you install IIS 7.Any clients connecting to the application will be connecting as either "IUSR" or "IIS AppPool/{AppPoolName}". I am guessing that your function to log the current user is reading from the SQL information and not from your HTTPcontext. More information about Application Pool Identity here: http://technet.microsoft.com/en-us/library/cc770966(v=ws.10).aspx
Normally a website process (w3wp.exe) impersonates the identity of the application pool identity (IIS APPPOOL\DefaultAppPool)
Unless you are using Integrated Authentication, in which the website process impersonates the identity of the authenticated user account accessing it (YOURDOMAIN\YourUsername).
What your site does beyond that is separate from IIS authentication and totally up to your application - that is, if you then go and set your users from your database, etc.
Short version:
For IIS 7.5 web applications with Windows Authentication does the end
user need to have Read file access?
Long version:
I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:
When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.
Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.
In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.
This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.
Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?
Some relevant details:
Network Service
has Full Control file permissions to the app folder.
When connecting from the server itself I was prompted for credentials
but after entering them i'm authenticated and the application works
correctly including displaying my windows login and connecting and
retrieving data from the db. I later determined that it was prompting
for credentials because http://localhost was in the trusted sites
and therefore not recognised as the Intranet Zone and thus not
passing identity through. I also determined that it was working as
this user identity because it's an admin user who has file
permissions.
The web server is running Windows Server 2008 R2 / IIS
7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and
possibly a couple of other items. A separate WCF app I installed that
uses IIS, anonymous authentication & .net 2.0 is working fine on
that web server.
The app install process is a manual copy of files,
creation of IIS App Pools & web apps, updating connection strings,
etc.
I checked the IE security settings. It was recognizing the
server as in the Intranet zone and had the option 'Automatic logon
only in Intranet zone' selected. Also on Advanced Settings the
'Enable Integrated Windows Authentication' option was checked.
After
installing IIS I ran aspnet_regiis -i for .net 2.0 and
aspnet_regiis -iru for .net 4.0.
Anonymous authentication is
disabled for my app and Windows Authentication enabled.
The app is
running on ASP.NET v4 but there's another app I installed
experiencing the same issue running ASP.NET v2.
The app is running
with Identity = Network Service and in 32-bit mode.
Database
connection string includes Trusted Connection=True and database
permissions are granted to the web server account [domain]\[server]$
e.g. DGM\MyServer$.
In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
In the Windows Security Event Log there
were a series of Microsoft Windows security auditing events: Logon
and Logoff. They indicated that the Logon was successful and was
displaying the User Id of the workstation user. This are from when
I'm connecting from another workstation and receive a 401
Unauthorized after several attempts.
I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.
Update:
This msdn article says
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.
This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.
Are authenticated users allowed to the app folder?
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB
i've always read that the user you set in the IIS website/virtual directory is the user that runs the app (anonymous user identity)
But in the application pool, i can also set a user (process model, identity)
what is the difference between the two, and which one will need access if i do a file read?
EDIT:
the bounty is for this quesyion ' but if i use 'anonymous authentication', is the user i choose in the 'anonymous user identity' ever used? – ' posted as comment
Checkout this post. Quote:
The two accounts are different things.
Think of the website identity
representing the user of the site. If
you create a new website this account
is the anonymous IIS account. If you
disable "Anonymous Authentication",
your users will have to authenticate
against the website (in a
intranet/Windows domain site this
could be implicite using the network
credentials.)
The application pool identity is the
Windows account needed for running
your assemblies. Normally it is the
"Network Service" account which is a
least privileged account with limited
user rights and permissions. It does
have network credentials. This means
that you can use it to authenticate
against network resources in a domain.
You can also use it to access a SQL
Server database with integrated
security.
For example, if your ASP.NET
application has to write to a folder,
you have to grant the permission to
the application pool account, not to
the website account. For more
information on application pool
identities, read here.
Think of the website identity as a rule that defines who can access the site. If you specify an anonymous account to use, that account must have access to the site. If anonymous access is disabled, then the user's credentials must have access to the folder.
The app pool identity defines what the application can do. The app pool's worker process will run using the app pool identity; that account must be granted access to any resources (SQL Server, file shares, etc) that the app will need to access.
To answer your question: yes, the anonymous account is used. Think of the scenario where you're hosting a hundred web sites, and you don't want one customer's files to be able to access another's. You would assign separate anonymous access to each customer. Each site's anonymous account allows IIS to access only the files relevant to that particular site (provided you've configured that account's access correctly).
#Michel
if you have an Anon Access Account setup on your site (virtual dir)
AND you have
<system.web>
<identity impersonate="true" />
</system.web>
in your web.config, this will use that identity.
if you have a part of code where you can set the credentials
CredentialCache.DefaultCredentials
this will point to the Anon Account,if you want to test what user you are using try
Thread.CurrentPrincipal.Identity.Name.ToString()
have a look at this post for more information
http://blogs.iis.net/sakyad/archive/2008/11/19/process-and-thread-identity-in-asp-net-a-practical-approach.aspx
I have an asp.net application that runs on a custom app pool which runs under a service level account. I have anonymous access turned off in web.config. The web server is part of a domain. The application access a sql server which runs on the same machine.
Currently, for all users, I impersonate the service level account to access the Database. When lots of users are accessing the site, this slows the site down as the lsass process starts using the cpu.
I am not allowed to create a sql server account, I have to work with what I have.
I am also not allowed to add each individual user to the database and give them specific access.
My question is, how can I set my application and datbase reletionship up such that I dont have to do impersonation of the Service level account and thus avoid CPU thrashing when website usage is high.
You shouldn't have to impersonate the service account. The service account is the account that needs access to the database and I suppose it already has. Have you already tried running your application without impersonating the service account when you access the database? This should work.
To perform a simple test, check the identity returned by WindowsIdentity.GetCurrent() (inside Page_Load for example). This should return the application pool identity and this is the identity that will be used to access the database.
Of course, this only works if you do not have client impersonation configured in your Web.config file. But since this is not a general practice except for some corner cases I suppose you don't use this. Client impersonation is not necessary for determining who the current user is, you should only use it when you want to access third-party systems (databases, fileshares, queues, ...) using the identity of the currently logged-on user (which is not a very scalable approach).
I have a normal Windows Server 2008 installation with II7. Each website has it's own application pool. But there is a security realated problem.
There is no restriction for an asp.net application to write a file into C: or any other directorys.
In IIS 6 before this could happen I would have to set those rights in the windows folder secuity permissions and allow the ASPNET_Usr to do that.
What is the best practice for hosting asp.net applications and not allowing them to write an read files in eg c:?
EDIT
Anonymous Auth. is enabled and the User specified is "ISUR". All other Authentications are disabled. In the application pool I use as Process Identity "Network Service".
I created a new User on the Server (not in the domain) "www.xyz.test" and deleted all his group memberships. Changed the Process identity to this user and made the anonymous authetication use the app pool identity and was still able to write to C:.
Changing the trust level is in my case not an option because we use an 3rd party application
It all depends on what user account your asp.net website is running on. I.e. is it Network Service? As far as I am aware, if I want to be able to write to the web directory then I give my website account write access solely to the directory where I want to save files. The account I use is the one used for Anonymous Authentication.
I.e. I have a website called mycompany.com . I create this user account as part of the domain user group. I add this as the anonymous authentication credentials and give it access to the web root, and also write access tot he nested folder which I want to write too.
The User account would be called mycompany.com so i know that it has a reponsibility solely for permissions related to the web and that particular website.
Sounds like the web site permissions (in IIS) are set to either
- Windows Auth: And you are logging in with someone who has permissions to those folders
or
- Anonymous Auth: And the account that is being used for impersonation has permissions
Best practice would be to make sure the account which is being used to access the site (i.e. if windows auth - your account or if anonymous then the account which is impersonated) does not have permissions on the folders.
You could also raise the trust level to medium, high or full in the machine.config for additional security enforcement policies - however use with caution as it can cause some ASP.NET apps to fail.