[unisog] Threat vector of running a service using a domain account

[mcclenbw at oneonta.edu]

See inline....

> -----Original Message-----
> From: unisog-bounces at lists.dshield.org [mailto:unisog-
> bounces at lists.dshield.org] On Behalf Of Harley, Chay
> Sent: Wednesday, September 12, 2007 9:47 PM
> To: UNIversity Security Operations Group
> Subject: Re: [unisog] Threat vector of running a service using a
> domainaccount
> 
> Okay, so answers:
> 
> 1) Sort of. You don't want to use a domain admin account though
because
> a domain admin account is for domain administration, not for service
> management.

What if the service requires Domain Admin rights?  You can't say not to
use a domain admin until you understand what the service does.  Perhaps
the service performs some type of "domain administration".



> 
> 2) Yes, don't use a domain admin account. Create a domain user account
> and give rights to run services.

And what rights does the service require?  Is domain user sufficient?



> 
> 3) ... Subjective answer.
> 
> 4) Service accounts are for local process execution unless you're
> running cluster/enterprise apps ie. Exchange cluster or SQL Cluster.
> Even then, they are not domain admin but a domain user/special rights
> to
> run as a service.
> Further permissions are typically inside the application such as dbo
as
> database admin, or exchange messaging admin/etc.

What??  Service accounts are local process execution only unless I'm
using another Microsoft service/product?  So don't do it unless
Microsoft says it's ok?  Seems hypocritical of them.

> 
> 5. Change the password every 30 days (as usually someone can
bruteforce
> any windows password in that time).
> Script/automate the process. Remember - no one should need to use this
> type of account interactively other than clicking "start" "stop"
> "restart" on the console.

Script a password change?   How do you protect the script?  I'm
interested in this, but skeptical at the same time.

> 
> Furthermore, don't use paper to keep passwords on. They have a nasty
> habbit of ending up in the trash for people to begin figuring out a
> pattern to your passwords.
> Use a password file that has public/private key system attached to the
> file. When someone changes their passphrase, update the file with
their
> new public key.
> 
> For further security, make the access to the file an RSA process, and
> give everyone tokens attached to their keys or mobile phones. It means
> there are two steps to accessing the password file (passphrase/pin +
> sequence generated number).

Or put your password list in a safe inside a secured room (like perhaps
your server room).  If you need to dispose of it, destroy it properly,
like using a cross-cut shredder, burn it up, etc.  Oh, but if you go the
fire route, leave the server room first. :)

I guess you could manage an entire PKI system to protect one file, but
the headache isn't really worth.  Plus, how do securely backup the keys?
Imagine one day you need a password and you can't get it because your
key is lost or corrupt.  Now what do you do?  Nothing more reliable then
ink on paper in a protected safe.


Saqib, yes this risk is manageable.  However, if this is a third party
application/service I would suggest finding out what access the product
really needs.  Many vendors say Domain Admin access is required because
that's the easy way out.  I've implemented my 3rd-party apps. that
stated they need administrator access that in the end did not.  Figure
out what the app does and give it the needed access.  If you need to
call support at any time, give the account administrative access before
you call and once the problem is fixed, remove it again and see if it
still works.  Most vendors are just lazy in test appropriate
permissions.



> 
> Good luck.
> 
> Chay Harley.
> MCSE+I
> 
> -----Original Message-----
> From: unisog-bounces at lists.dshield.org
> [mailto:unisog-bounces at lists.dshield.org] On Behalf Of Ali, Saqib
> Sent: Wednesday, September 12, 2007 1:47 PM
> To: UNIversity Security Operations Group
> Subject: [unisog] Threat vector of running a service using a domain
> account
> 
> i would like to understand the threat vector of using a "dedicated"
> Active Directory account to run a service. Here are some details:
> 
> 1) This particular account will have domain admin privileges.
> 2) The account will NOT be used to perform interactive logon to the
> machines.
> 3) The password for the account will be stored in a safe-box
> 
> The brute-force attack risk is mitigated by the fact that the account
> will lockout after X number of unsuccessful attempt. Also any attempt
> to
> use the account for interactive logon will show up in the audit logs.
> 
> My questions:
> 1) Is the risk manageable?
> 2) Or should we completely avoid this application?
> 3) Is this kind of scenario common?
> 4) What other popular apps require such domain admin privileges for
> service accounts?
> 5) What other Controls can we put in place to prevent misuse of the
> account?
> 
> saqib
> http://security-basics.blogspot.com/
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog
> 
> --
> This message may contain confidential, proprietary, or legally
> privileged information. No confidentiality or privilege is waived by
> any transmission to an unintended recipient. If you are not an
intended
> recipient, please notify the sender and delete this message
> immediately. Any views expressed in this message are those of the
> sender, not those of any entity within the KBC Financial Products
group
> of companies (together referred to as "KBC FP").
> 
> This message does not create any obligation, contractual or otherwise,
> on the part of KBC FP. It is not an offer (or solicitation of an
offer)
> of, or a recommendation to buy or sell, any financial product. Any
> prices or other values included in this message are indicative only,
> and do not necessarily represent current market prices, prices at
which
> KBC FP would enter into a transaction, or prices at which similar
> transactions may be carried on KBC FP's own books. The information
> contained in this message is provided "as is", without representations
> or warranties, express or implied, of any kind. Past performance is
not
> indicative of future returns.
> 
> 
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog