Because IIS knows the password for the xyzweb account. If someone can get IIS to execute arbitrary code (e.g. by uploading some of their own webpages) then IIS can connect to serverB using the domain\xyzweb account, and that account has privileges on serverB.
Yes... If they are using a privileged account then something odd is up. You may see some very weird behavior if you remove the user from the Domain Users group by way of changing the primary group on the user object. Wouldn't that mean that if someone manages to take advantage of one of the many IIS vulnerabilities they very well may have access to information all over your network instead of just the one machine? Sounds like you're a) taking a very subjective approach to this and b) need to update your data. If you are arguing that the customer should redesign their app because customers might not install a security patch then IMO you are wasting your customer's money. Personally I think you're making a mountain out of a mole hill. Like I said this is really a common design. Thanks, Brian Desmond [email protected] c - 312.731.3132 From: Klint Price [mailto:[email protected]] Sent: Thursday, October 07, 2010 7:54 PM To: NT System Admin Issues Subject: RE: Need System/Application Security Advice So what steps should be taken to secure it since no instructions are provided to do so? Because IIS knows the password for the xyzweb account. If someone can get IIS to execute arbitrary code (e.g. by uploading some of their own webpages) then IIS can connect to serverB using the domain\xyzweb account, and that account has privileges on serverB. By running your website as a domain user it is basically giving permission to your web server to access anything that the user has access to on the entire domain. Wouldn't that mean that if someone manages to take advantage of one of the many IIS vulnerabilities they very well may have access to information all over your network instead of just the one machine? A workaround or possible solution would be to instruct the customer that if they are going to use a domain account (which by architecture they are forcing them to do), that they should use a non-privileged account, and remove it from the "domain users" group. That way the account can be considered "authenticated", but has no other default rights on the domain. Additional settings should be implemented to prevent the password from expiring, and locking out. From: Brian Desmond [mailto:[email protected]] Sent: Thursday, October 07, 2010 10:49 AM To: NT System Admin Issues Subject: RE: Need System/Application Security Advice It's very common. There are many things you simply cannot do if you run in a local security context. FYI if you run the app pool as Network Service on a domain joined machine that provides it the domain rights of the server's computer account. If an internet facing app even not in a corp environment runs on a web farm and is anything other than static content you're almost guaranteed to have a domain and shared domain accounts running it too. Thanks, Brian Desmond [email protected]<mailto:[email protected]> c - 312.731.3132 From: Klint Price [mailto:[email protected]] Sent: Thursday, October 07, 2010 7:36 PM To: NT System Admin Issues Subject: RE: Need System/Application Security Advice Internal corporate, yes. Directly exposed to the internet? I would hope not. From: Brian Desmond [mailto:[email protected]] Sent: Thursday, October 07, 2010 10:34 AM To: NT System Admin Issues Subject: RE: Need System/Application Security Advice Ermm what you describe (as I understand it) is probably how 75-90 percent of apps run on IIS in a corporate environment. Thanks, Brian Desmond [email protected]<mailto:[email protected]> c - 312.731.3132 From: Klint Price [mailto:[email protected]] Sent: Thursday, October 07, 2010 7:28 PM To: NT System Admin Issues Subject: Need System/Application Security Advice My off-hour job is consulting for various companies. One such small company puts out a product that I feel needs to be fixed. Company sells two products; ProductA integrates with ProductB which both manage sensitive data and are exposed to the public Internet Windows Forms Authentication is tied to LDAP to authenticate users prior to allowing them into the inner-workings of the system. ProductA and ProductB are configured so that IIS allows a domain account to run the entire website for anonymous users (the equivalent of running an app pool with a domain account). Because the entire site runs under the domain account, there are inherent security risks which Company fails to disclose. I am about to send off an e-mail to the higher ups detailing why this is a bad idea without instructing the customer on the possible security risks, and associated steps to mitigate, let alone re-architect the application to reduce this exposure. Why is it a bad idea to configure a site in this way out-of-the-box, and what articles can you point me to? Any security articles would also be appreciated. At minimum I think the domain user should be removed from the "domain users" group, with additional GPO's applied to lock down the account. What say ye? ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
