IIS and ASP.NET impersonation

Question

What risk is a user exposed to if he accesses a .net web application with impersonation enabled ?

What impersonation level is ASP.NET impersonation ?

This is the documentation of impersonation-levels .

Can I create a website, then lure a sysadmin to open it and do some bad stuff in his name (like adding me to the local sysadmins. I can deploy web applications but I am not an admin)? What are the boundaries of this impersonation? Did not find any precise description in the docs.

Answer 1

First of all you need to understand what is ASP.NET Impersonation . Apart from msdn given definition, in layman language, ASP.Net impersonation is ability to get user information of Active Directory Logged-in user on machine using client side asp.net application.

As you mentioned, there are different impersonation-levels .But before going to that you need to understand that ASP.Net is managed environment . It exist under the scope of IIS application pool. So any application is ability is limited to what an web application in managed environment can do on server.

To directly answer your concerns, these are few considerations:

• If you can host an application is IIS having ASP.impersonation, you should be admin of that machine(non-admin users can't even open IIS)

• Any IIS application can't do Administrative tasks like Creating, deleting users, changing user permissions without calling any native application for manipulation active directory(need to configured & much work needs to be done, non admin can't think of that). That is almost impossible even somehow possible with some 3rd party unmanaged code then also non-admin user can not install those tool/sdk on server without having direct access to servers.

• ASP.Net impersonation is mainly for active directory users and Active Directory exists in securely managed environments in VPN or Office Premises. You need to be active directory user to access impersonation. Even somehow you did that(not possible without admin server access) then also audit/system logs/network logs will find who is insider culprit to did something like that so what that means inside an organisation(apart from getting fired) I leave upto you.

Still you think asp.net impersonation is unsafe, you can ask questions. :)

UPDATE for comments

---

Impersonation Level link you got above is for desktop/windows application which runs in full trust. ASP.net application impersonation is just a way to get identity of Active Directory User with some defined attributes and it is mainly used for authentication & authorization. I again reiterate, ASP.net is managed application inside App pool which only can perform action which is authorized to Account from which you have hosted application and with that too native/administrative actions like creating or modifying Active Directory User access is not possible without calling some another SDK which is already trusted & installed on that machine.

So summarize, operations like creating files or deleting file on the place where you have given Directory access to Web App is possible(Also on network if permission exists while deploying for User used for hosting not logging in) but deleting everything on server or performing Administrative tasks like AD User creation/modification is not possible via login of Admin impersonation of ASP.net webapp without assist of already installed trusted unmanaged software that can do this.

Answer 2

I had a palaver with my sysadmin yesterday. If the user is authenticated by kerberos , it is possible that the webapplication accesses resources on other servers in behalf of the user (delegation). Kerberos constrained delegation works with a white-list .

If my application needs to read files on a file share with credentials of the logged in user, the security admin has to add an entry that my application (identity of app-pool) accesses this file server in the name of the logged in user. I can not create a malware application that reads all the emails of my boss just because he is visiting my webapp.

See https://blogs.technet.microsoft.com/pie/2017/06/30/credential-theft-made-easy-with-kerberos-delegation/