That is fine, I have no problem with people
disagreeing with me. It still won't make me prove a point by documenting how it is done. If I gave a step by step or even a high level that
gave people who couldn't figure it out on their own a clue as to how it is done,
I would have to kick my own ass.
As was stated by others, knowing how this is done does not
arm you so that you can do anything more about it. Windows has always had two
areas you needed to secure and had different
assumptions of who should be in those areas. There is the remote access "zone" and the local access
"zone". I am talking from a software angle, not physical. If someone has
physical access and can do what they want, there really isn't any security
that can not be compromised in some way shape or form.
So now you have
remote and local access (or unrestricted remote system access such as c$ or
registery access, etc). If you have remote access, you have to go up
against the fixed function interfaces MS has made available to connect to and
manipulate the machine such as LDAP or kerberos or remote RPC calls, etc.
These have
been built by MS to be as secure as they, at the time they built the interface,
could. This is the most secure you will find things to be and even this can be
compromised. I simply ask you to review the history of all of the various worms
and viruses that have torn through networks infecting machines through
unauthenticated remote access. Think RPC interfaces, web interfaces, SQL
interfaces, etc. Again, making people use the system resources through remote
fixed function access interfaces is going to be the MOST secure you
will see. Honestly, for a long time this only secured you against people who
didn't want to harm you that were smart enough to keep their machines from being
infected by keeping the services that exposed handles to THEIR machines to a
minimum and ran firewalls to block all but the smallest amount of remotely
activated connections and didn't run code that they didn't fully
trust.
If you have local
access (such as TS to the desktop or remote console), you have bypassed a great
deal of the security barriers Microsoft has put into place. You are within at
least the semi-trusted zone and quite honestly in my opinion, the pretty much
fully trusted zone. You know the MS history in keeping the untrusted zone
safe, do you expect the semi-trusted zone to be that much more successful at
repelling people trying to do you harm? Look at your own house as an example,
once someone is past your locked (lol) windows and doors, how much more security
is there in place to make sure people do not get access to sensitive information
or modify your stuff in a way that you do not know? Probably little to none
because it isn't feasible to audit and/or monitor everything in real time.
Further to that, how many automated systems do you have in your house that you
have no understanding of and wouldn't know one way or the other if they
were compromised and being used against you. How do you know someone hasn't
installed a mini-cam in your bathroom and bedroom and not filming your
most intimate moments that you want no one to know about. That is very much
like the state of having local access on a PC. You giving someone access to your
house to put a camera in place and me telling you, hey, they can put a camera in
place does not mean you can detect it or prevent it. Your option, is to disallow
the person from being in a position where they can easily put that camera in
place in to begin with.
How exactly are
you monitoring your group memberships, what interfaces are being used? Most
folks I have seen who implement group monitoring only watch the membership
and not both membership and primary group membership. These are recorded
differently for LDAP interfaces. In that case, someone could act fast
enough and get themselves primary group membership before your LDAP interfaces
ever picked up on the membership change. What about the binaries on your
machine. Having AV software on your machine doesn't mean the machine isn't
compromised. It doesn't look to determine what should be there, it looks at a
fixed set of signatures and tried to determine what shouldn't be there based on
those signatures. Just because it says that some important exe isn't infected
doesn't mean it is what MS produced. Are your favorite plugins and utilities
and CPLs all the way they should be from MS or have they been compromised?
Has someone replaced one or more of your service or driver binaries? How do you
know? This has become more difficult but still isn't 100%, heck it probably
still isn't even 50%. Show me someone who can tell me 100% where every single
file and component on their machine came from and I can almost certainly show
you a liar or at best, a hopeful guesser. I have asked Microsoft for years to
publish a database containing checksum codes and file date/times for every
single file they have ever installed on any machine ever so that you could scan
a machine and determine every file that came from MS (and those that didn't) and
where they are from and whether or not they should be on the machine at the
current patch level and OS. Sadly, the answer is always a look of incredulity
and an admittance that no that isn't even remotely possible. Heck I had someone
in a meeting at a MS Security conference tell me that they couldn't even do that
with NEW files coming out because too many are coming out through too many
different channels...
Again, once you
are on the local machine, you are in the semi-trusted zone. If someone isn't
fully trusted, they shouldn't be there in the first place because once there,
someone stupid or someone intentionally out to get you will eventually hurt you.
The deck is stacked against you.
Right now, we are
lucky in that no one who seriously understands the technology has gone after
domain controllers and domains and forests as a whole. This means a lot of the
possible holes that could be taken advantage of to cause enterprise wide
disruption and destruction are not being attacked or at least not being attacked
in the most advantageous way possible. You need to be thankful for that because
if you can't sit down and work out on your own how someone could attack your
forest and you feel that granting local access to DCs is a responsible thing to
do then you probably don't have anywhere near the skill set and understanding
needed to stop someone who does have the ability to figure it out on their own
or has been taught how to do it.
Something I like
to tell people about with security is simply this.... Just because YOU
don't know how to compromise a given system doesn't mean someone else doesn't
and it can't be compromised. You can never, yes NEVER, prove a system
to be secure, only secure from you. The best you can do is prove a
system to be insecure and hopefully come up with a workaround to prevent that
insecurity from biting you.
If we start
publishing the various ways in which someone could compromise your domain
controllers, your domains, and your forests, all we have done is lower the bar
for the script kiddies and others to start doing it. If someone is
adamant about giving local access to domain controllers or even remotely
allowing them to reconfigure services and/or modify system components there is
nothing that I nor anyone else can do to protect them. Simply step back and let
them play Russian roulette on their own.
In my mind,
anyone who allows people who are not fully trusted DAs local access to DCs
or allows remote modification capabilities of system components is simply
careless and deserving of anything that happens. This could be you or it could
be the manager who forces you to do it after you fought tooth and nail.
Microsoft has given you an untrusted area to place untrusted people into and you
have decided you know more than they do and that it is safe to put untrusted
people into an area that requires trust. At the same time I would both love
to see it and hate to see it if some admin who felt so strongly that they knew
all of the holes and all of the ways to protect themselves from someone with
local access to a DC walked into work one day to find that every single domain
controller in their forest had suddenly ceased to be a domain controller or they
had been locked out of their own forest.
Again, it isn't
just local logon capability, it is anything that can be done to modify the
system components of a DC. Remotely or locally. Locally is just scarier because
the bar is much lower once you are there. Why do you not run email programs as
Domain Admins (and if you do run email programs as domain admins I don't care to
hear about it, good luck) or any other ID with enhanced rights? Why do
people go through the hassle of having multiple IDs, normal business type IDs as
well as enhanced privilege IDs?
I know I don't
know every way a DC, a domain, or a forest can be compromised and/or damaged.
THAT is why I don't allow anyone but fully trusted DAs access to DCs that
I am responsible for. It isn't because I know of several ways in which
it can be compromised. My opinion is such that if I allow a porcupine
in my house instead of keeping it outside, I am at some point probably going to
get poked. The more determined that porcupine is to poke me, the more likely it
is going to happen and the less chance I have to prevent it even though I know
it can and I know what that poke will look and feel like. Knowing after the fact
that I was poked is moot in my book, too little too late.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh Parmar
Sent: Friday, September 23, 2005 7:12 AM
To: [email protected]
Subject: Re: [ActiveDir] Domain Controller Security
As I mentioned It's not possible for me to not allow local site
guys to login locally to DC, at least for a small period, till we automate
most of the system maintenance like sysstate backup and AV updates check etc..
And I am not saying that we don't trust them, They have physical access to DC,
so if they want to, they can become the enterprise admin through hacks
available on net. (which we counter by extensive physical security).
What surprised me, is possibility of remote compromise
using normal user local login, which can be extended through
terminal services.
I have extensive auditing enabled. And I am daily monitoring the
group membership changes for enterprise admins, schema admins, domain admins,
server operators, backup operators, etc.
as far as I know, that would be the first thing, unauthorised access
will try to do, i.e. elevate their rights within system.
Is this sufficient? is there any other attack symptom, I should be
monitoring DAILY?
I have already raised the concern with our ADS migration PM, and to get
more info from our TAM.
But, if I just ask him, what is the possibility of AD compromise in case of
normal user local login onto DC? I guess TAM is likely to play down the
threat.
I understand, experts' concern for not even talking about it in forum,
in interests of community,
as we don't know the intent of every subscriber.
but I do feel, "this is a big issue, easily exploitable with
little workaround to thwart it."
You know, guys this has increased the priority for me to automate the
maintenance stuff on urgency and remove the rights for local login on DCs. It
will be hard for me to explain to them, why I am doing it, as I have very
little facts. :(
On 9/23/05, ASB
<[EMAIL PROTECTED]> wrote:
>>And knowing it, I can always take extra precautions.The knowing it consists of "don't do it, because you can't secure it"There are no extra precautions to take. Certainly, you can increase your auditing, but you could do that now without knowing anything else.>>basically, 25% more prepared and secure against this type of attack is better than 0%.The more people that know, the higher the potential of attack. And, as folks have pointed out, since there are no viable workarounds, it doesn't help anyone to have the number of potential attackers increased.
Call your TAM and see if he or she will provide enough details for you to feel comfortable.-ASBFAST, CHEAP, SECURE: Pick Any TWO
On 9/23/05, Kamlesh Parmar <[EMAIL PROTECTED] > wrote:I have to disagree a bit here...Certainly, obscuring of information is not the way to feel secure.If I don't know, how it is done, then how do I know, that I will be able to detect it, and trace it.
And knowing it, I can always take extra precautions. Which I think, better than not knowing it at all.basically, 25% more prepared and secure against this type of attack is better than 0%. and certainly it helps calibrate how much paranoid I have to be. :-)
I would like to know, how it is done, as our team is currently migrating some good number of domains to single domain. And we are going to give local guys rights to logon to DC for some system maintenance purposes, till final single domain is cleaned up and we revert back to core team for day-to-day maintenance.So I am very much interested in knowing it.On 9/23/05, joe <[EMAIL PROTECTED]> wrote:The docs are wrong. Many of us have been hounding MS on this for years. They really started straightening out docs with K3. Some of the older 2K docs still suggest this security boundary at the domain. It really came to a head when Lucent put out a paper on this and it started getting quoted in the newsgroups and some of us just flamed the crap out of it.No one here or anywhere should really publish how to exploit rights on a DC to take over a forest. The answer is pretty self-evident if someone understands the underpinnings and processes used in AD and since we can't fully protect against it, it is better left undocumented. If there was a guaranteed safe way to protect ourselves, then we could publish that workaround and some time later publish the issue.joe
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of DeStefano, Dan
Sent: Thursday, September 22, 2005 2:09 PM
To: [email protected]
Subject: RE: [ActiveDir] Domain Controller Security
I thought that in ad domains are considered security boundaries. In the cert exams, namely the 70-219, they are considered as such. Also, how would a domain admin of a child domain elevate his privileges?
Dan
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Phil Renouf
Sent: Thursday, September 22, 2005 1:28 PM
To: [email protected]
Subject: Re: [ActiveDir] Domain Controller Security
Even as a domain admin of a Child domain they will still be able to munge your forest or elevate their priviledges. The security boundary in AD is at the forest, not the domain.
Phil
On 9/22/05, Gideon Ashcraft < [EMAIL PROTECTED]> wrote:
The only thing to do is to make him an admin of that site, or better yet make that site a child domain and make him a domain admin of that child domain. I know from experience that using a DC as anything but a DC is a freakin pain in the ass, my predecessor set a DC up as a print/file server and another as a SQL server (finally able to demote that one now, soon hopefully). But my citrix profiles are on the domain controller, and after months of trying to set delegation up properly in AD and setting up permissions in the appropriate folders on the DC, the only way I was able to get my Helpdesk admin set up to create accounts with my scripts so that I didn't have to do it was to make him a domain admin. My company is too damn cheap to get me another server to put the citrix profiles somewhere else. Oh yeah, and its an app server for network install of office (can you feel my pain).
So, if there is only one server in the site and its a DC, the only way to get him to do anything is to make him a domain admin (make it a child domain so he can't climb up the tree)
Gideon Ashcraft
Network Admin
Screen Actors Guild
ct: RE: [ActiveDir] Domain Controller SecurityLook through the archives.
The short answer is... "Just don't do it". You can't possibly secure this regardless of what anyone says. If someone says it can be made safe, stop asking them technical questions about Domain Controllers and Active Directory.
Either you trust the person or you don't. If you don't trust the person, then don't put the person in a position to show you the meaning of screwed.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of van Donk, Fred
Sent: Tuesday, September 20, 2005 4:52 PM
To: [email protected]
Subject: [ActiveDir] Domain Controller Security
I have a contractor in a remote site. There is only 1 server in that site which is a DC.
He needs to administer that server.
-Create shares
-Make file/share permissions
-Change user passwords in the User OU for that site.
He is not allowed to log on to any other server is the domain.
When I make him a "Server Operator" he can logon to any server in the domain.
Any idea on how to lock him down to that one server and then how to lock him down on that one OU where he should only be allowed to change the passwords of the users.
Thanks!
Fred
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~
