ASP.NET file system permissions - asp.net

I always thought the user running the app pool was used to, for instance, access the file system when an application is trying to write a file.
I have an application in IIS, setup with Windows Integrated Authentication, that tries to write a file to the file system. I always get an error unless I give permissions on the file system to the specific domain user that logged in through Windows Integrated Authentication.
Any reason why I´m observing this behaviour?
Thx in advance

Are you using Impersonation? This would use the User's identity to do stuff, rather than the one of the AppPool. If you're using a third party ASP.net Application, check if they use Impersonation (for example, SharePoint does).
There is a way to revert the identity of the AppPool. Check this question which includes the RevertToSelf and HostingEnvironment.Impersonate methods. The Question is about SharePoint, but these two answers are the non-SharePoint way of reverting to the apppool, so they apply.

Related

How to query all IUSR privileges in Windows Server 2012 to protect against hacker shell access on an IIS 8 website

I had some malicious javascript appended to my .js files on a website and tracked the hack in my logs to an old FCKEditor exploit.
As a relative novice, I've been reading up a bit on how this was done and how I can protect against it, but I have a few specific questions, listed below.
If it's helpful, this was Windows Server 2012, IIS 8 and SQL Server, and, I'm embarrassed to say it, but this was an old site still running Classic ASP. Here are my questions:
I had IUSR as my Anonymous User in IIS. When the hacker uploaded the .asp file to get shell access, I assumed they only had the privileges conferred to them via IUSR, correct? If the server is properly hardened, they can't escalate privileges to get more access than what IUSR has, right?
I've changed my Anonymous User to be the application pool identity. Since a hacker's grab-shell-access ASP program now won't have IUSR's privileges and will only have the application pool identity, is it safe to assume that they can't get the ability to run commands like WHOAMI or any other such commands? What rights would application pool identity (and thus any of my .asp programs that serve up web pages) have?
Last question. OK, so I clearly was giving IUSR too much power on this box, given that an anonymous user for IIS could run a .asp program and get shell access. So how do I query what privileges IUSR has across the entire computer? I know I can, for example, right click on my inetpub folder and look a security to see what IUSR can do, but is there a way to get a report across the entire server to understand the full rights and privileges for that particular user.
My focus with these questions is more about general learning than about protecting this box. I'm sure some might be inclined to say your box is probably toast and backdoored, so dump it and start with a new server, but I know that. I also know that I should have done some hardening that I didn't. Thanks for your answers to questions above, which will help me learn and improve. Much appreciated.
1.IUSR will determine what identity you are using to view your web page and also application pool identity will decide whether the application or shell can be executeed. So you need to minimize permission for both app pool identity and iusr.
2.By default application pool identity don't have permission to access something like powershell or cmd. So you don't have to afraid command like whoami will be executed.
3.I'm afraid there is no simple way to do permission traversal. But you just need to make sure you have already minizized your application pool identity permission.

Why can’t I still get IIS ApplicationPoolIdentity to write a file to folder?

My ASP-Webpages application needs to write self-generated files to a local folder under its root directory. Everything runs like a charm on- and from my development environment, even to any other given network locations.
The problem is that I can’t get the production environment to do the same. Just no files get created, anywhere. Nor are any exceptions thrown on missing permissions etc. Nada.
I believe I’ve read and tried out just about everything anyone had written on the Internet over the past seven years and I feel like I’m chasing my own behind trying to solve this problem. Should it be really that difficult?
At the risk of getting marked as duplicate I see no other option than to post my question here..
Basically, here is what I have this far:
The production application runs on Windows Server 2008 R2, IIS version 7.5. It has a dedicated Application Pool, with its identity set to ApplicationPoolIdentity (.NET Framework v4 / Integrated pipeline).
Application Basic Settings
Verified AppPool membership of IIS_IUSRS.
Verified Group Membership
User Authentication is set to Windows Authentication.
User Authentication
Should Anonymous Authentication be set to ‘Enabled’ to get the ApplicationPoolIdentity be used? I’ve tried setting it on, but it conflicts with the Windows Authentication, which is an essential part of our application and cannot be switched off.
If so, then how?
Both the Application Pool and the IIS_IUSRS have been granted Read & Write permissions on the folder.
I’ve tried setting Full control, but that didn’t help either.
Folder Security Settings
Here is the (stripped down) code that writes the files to the desired location:
Stripped-down Code
Other (silly) things I’ve tried are:
Playing around with absolute and relative path directions in my code.
Enabling Anonymous Authentication, resulting in a conflict with the necessary Windows Authentication.
Set Application Pool ProcessModel identity to Network Service.
Recycle Application Pool.
Load User Profile ‘On’ for the Application Pool.
Setting IE Enhanced Security Configuration ‘Off’ for users.
Restarting server machine.
Using different browsers.
Give 'everyone' full folder permissions, just to try the effects, nothing..
Set AuthenticatedUserOverride to UseWorkerProcessUser via IIS Configuration Editor. This causes that my application doesn't recognise Current.User.Identity.Name anymore, so it blocks further site access.
What I need is to keep Windows Authentication, but also be able to have the application anonymously write files to a given location.
Can anybody please hint me in the right direction or just tell me what I’ve overlooked?
Thanks!

ApplicationPoolIdentity permissions on Temporary Asp.Net files

at work I am struggling a bit with the following situation:
We have a web application that runs on a WIndows Server 2008 64 bits machine. The app's ApplicationPool is running under the ApplicationPoolIdentity and configured for .net 2 and Classic pipeline mode.
This works fine up to the moment that XmlSerialization requires creation of Serializer assemblies where MEF is being used to create a collection of knowntypes.
To remedy this I was hoping that granting the ApplicationPoolIdentity rights to the ASP.Net Temporary Files directory would be enough, but alas...
What I did was the run the following command from a cmd prompt:
icacls "c:\windows\microsoft.net\framework64\v2.0.50727\Temporary ASP.NET Files" /grant "IIS AppPool\MyAppPool":(M)
Obviously this did not work, otherwise you would not be reading this :)
Strange thing is that whenever I grant the Users or even more specific, the Authenticated Users Group those permissions, it works. What's weird as well (in my eyes) is that before I started granting access the ApplicationPoolIdentity was already a member of IIS_IUSRS which does have Modify rights for the temporary asp files directory.
And now I'm left wondering why this situation requires Modify rights for the Authenticated Users group. I thought it could be because the apppool account was missing additional rights (googling for this returned some results, so I tried those), but granting the ApplicationPoolIdentity modification rights to the Windows\Temp directory and/or the application directory itself did not fix it.
For now we have a workaround, but I hate that I don't know what is exactly going on here, so I was hoping any of you guys could shed some light on this.
Thanx in advance!
If the application pool is running as AppPool Identity then things should work out-of-the box since the worker process will be injected the IIS_IUSRS SID which will have the right permissions to write.
My guess, is that the application must be using Windows authentication and impersonation is enabled in ASP.NET so that code is probably be ran as the specific user that is making the request and not necesarilly the process identity.
Am I right on the guess that the app is running Windows Authentication? and impersonation is enabled in asp.net ?
Might not be relevant to you - but if you are running the app pool as a domain user, the rules change on the automatic injection of IIS_IUSRS token into the process at startup. This caught us out recently when moving to .net 4, and not having permission on the new Temporary ASP.net Files directory.
See here for a workaround: http://www.yusufozturk.info/iis7/asp-net-write-access-error-on-iis7-5.html

ASP.NET Granting access to local resources

I have an ASP.NET web application that runs on a windows server 2003 server.
there is a form that reads and writes data to an xml file inside the application's directory.
I always grant the NETWORK SERVICE user full control on my application folder so that it can read and write to the xml file.
I put the application on another windows server 2003 server and did the same steps above but i was getting an Access denied exception on the form that reads and writes to the xml.
I did some search and found that if you grant the user ASPNET full control to the directory it would work, I did that and it worked fine.
my question is: what is the difference between granting full control permissions to NETWORK SERVICE and ASPNET users ?
and what can be the difference between the two servers that caused this issue ?
thanks
In all cases, you need to grant the application pool's user account the appropriate access. Application pools were introduced with IIS6. Before IIS6, the .NET application ran under the user account configured in the machine.config file so you would look there to determine the user that needs access.
Network Service is assigned to application pools by default. It sounds like someone set it up differently on one of the servers.
Ideally, you should not be using either account.
You should create a low privilege account that only has access to the resources you need for each web application you have. Add the new account to the IIS_WPG user group. Then create an application pool for each application and set it to run as the user you created specifically for it.
See this article (TechNet) for directions on changing the identity of the app pool.
The configuration I described is now the default in Server 2008 R2/Win 7 (source).
Unfortunately, because someone changed the default configuration on your second server, there is no way for us to tell you what the differences between the two accounts are.
What you will need to do (or have your IT department do) is compare the permissions each account has on the local machine. This will be tedious. However, if you can run powershell, you can use this article to write a script to list out the permissions for each account and compare them.
Good luck finding the differences.

Write to file not working after hosting (publishing the web application) ASP.Net

Writing to a file is not working after hosting the web application, whereas they were working while developing and testing in my localhost on debug mode. What could be the problem in writing to a file after hosting? Is there any special permission that should be given to the folders/file?
Without knowing the OS version or the code you're trying to use, I'd say the most likely culprit is permissions. The ASP.NET user (which varies based on version of Windows) needs write access to the folder you're trying to write to. This is likely not enabled by your host.
Yes, you will need read, write, and modify permissions to the directory you wish to write to. You need to ensure that the account under which ASP.NET is running has those rights set up.

Resources