Implications of Machine\ASPNET user as administrator role?

Question

Hi,

We are receiving an application from a third party that will eventually be installed in our production environment.

As part of the setup, they want us to make Machine\ASPNET an Administrator account.

This seems to me like bad practice, but I need specific reasons if I am going to push back on this.

What are the implications of running Machine\ASPNET as an administrator?

Additional details:

• This will be deployed under IIS6 on Windows Server 2003
• This is a three tier application. I believe they want the Machine\ASPNET user as administrator on the middle tier, where the WCF services will be deployed.

Answer 1

I would agree this is a very bad idea, if for some reason there was a security breach on the site an attacker could pretty much do what they want with the server.

You need to find out why the user needs to be an admin, get an exactly list of actions that the user needs to perform and just give permission for these tasks. If they can't give you a proper list then just reject it, it shows that they don't know their application very well and that should enough of a worry.

Answer 2

As you've guessed, making the ASPNET account a member of the Administrators group is a really, really bad idea.

This is because a successful exploit against your third party app (or against any other web app running as ASPNET) would gain administrative access to the machine. This is the principal reason why web app accounts are generally low-privileged.

Instead of granting ASPNET admin rights, you could request from your third party what specific rights they require. You could then grant ASPNET just those rights. This would limit what a succesful exploit could accomplish.

For example, if the app needs read/write access to the registry under HKLM, you could grant ASPNET access to it. Thus an exploit could clobber the registry, but not the file system.

Answer 3

If a vendor is giving this advice you’ll normally find they’ve put doing the job properly in the “too hard basket”. Most likely they’re struck permissions issues and just recommended granting the broadest possible access rights to solve the problem rather than applying the proper due diligence and investigating the route cause.

As others have said, go back and pressure them for more details. There’s a very good reason the ASPNET account operates with limited rights; the onus is on the vendor to properly explain why good security practice should be compromised to run their product.