RE: [ActiveDir] Thoughts about misusing the "msDS-UpdateScript" a ttribute by an A D-aware virus

Wed, 23 Feb 2005 08:19:51 -0800

Title: Message
Thanks - I should have re-read the rendom literature first :)
 
I guess the response to the original poster is then 'a. The DNM signs and seals the data which it posts in msDS-UpdateScript. 2. DCs will only ever respond to data which is similarly signed and sealed by the DNM, when data is found in msDS-UpdateScript'
 
The first statement is certainly true, but I guess we need to be confident of the validity of the seconds statement.
 
Any further comments?
 
neil
 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: 23 February 2005 16:02
To: Send - AD mailing list
Subject: RE: [ActiveDir] Thoughts about misusing the "msDS-UpdateScript" a ttribute by an A D-aware virus

LOL, I was waiting for that question :)
 
In terms of the signature's construct and/or the keys/digests used to construct it, no I'm afraid not, I've never bothered looking (a finite number of options exist although getting at those keys requires some effort). 
 
The following is taken directly from MS (search on signed) -
 
Actions Performed in Response to the rendom /prepare Command

The following sequence of actions occurs in response to the rendom /prepare command:

  • Rendom issues a special RPC (for internal use only) to every domain controller in the forest in turn, requesting authorization and verification of readiness as encoded in the test component of the script in msDS-UpdateScript. Rendom issues the RPC to multiple domain controllers at a time with a high degree of concurrency, while ensuring that resource limits on the computer that is executing the command are not exceeded. The RPC request and response are signed and sealed for integrity and privacy.
  • In response to the RPC, each domain controller performs the authorization check, ensures the authenticity of the script in msDS-UpdateScript by validating the signature, and verifies the test component of the domain rename script before responding. If any of these checks fails on a domain controller, the RPC returns an error for that domain controller.
  • Rendom updates the state file with the state of each domain controller that was successfully contacted and verified. The state of each successfully verified domain controller is updated from the Initial state to the Prepared state. The Prepared state indicates that the domain controller authorized the execution of the restructure and that the contents of its directory database are consistent with the rename instructions that are contained in msDS-UpdateScript. If a domain controller cannot be contacted or if it fails any of the checks, its corresponding state in the state file remains as Initial with an appropriate error code and message to indicate the cause of failure.

--
Dean Wells
MSEtechnology
* Email: dwells@msetechnology.com
http://msetechnology.com
 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruston, Neil
Sent: Wednesday, February 23, 2005 7:53 AM
To: '[email protected]'
Subject: RE: [ActiveDir] Thoughts about misusing the "msDS-UpdateScript" a ttribute by an A D-aware virus

Do you have any detail on the nature of that "signature", Dean?
 
neil
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: 23 February 2005 15:26
To: Send - AD mailing list
Subject: RE: [ActiveDir] Thoughts about misusing the "msDS-UpdateScript" attribute by an A D-aware virus

If memory serves the attribute content is signed by the DNM when populated, if you can circumvent that (or mimic its signature) I'm fairly certain you could do equally as much harm in many other ways.

--
Dean Wells
MSEtechnology
* Email: dwells@msetechnology.com
http://msetechnology.com
 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto
Sent: Wednesday, February 23, 2005 1:43 AM
To: [email protected]
Subject: [ActiveDir] Thoughts about misusing the "msDS-UpdateScript" attribute by an A D-aware virus

Hi,

A while ago I installed some DCs and domains in a virtual environment and I performed a domain rename.. Just to see how it works and what goes (or could go) right or wrong. This was fun to see... in an environment with 3 domains and about 5 DCs.... So imagine this in a distributed forest all over the world... ;-))

After reading the documentation about domain rename and playing with it, I had (and still have) a thought how some AD-aware virus could misuse the "msDS-UpdateScript" attribute on the Domain Naming master to screw up AD on all DCs.

How do you guys think about this one? Could this happen?

Has anyone done a domain rename for real?

Cheers,
Jorge

For those who have not read the documentation or performed a domain rename (for real or in a test environment) the highlights are:

#################################################
Validate Domain Rename Instructions
When you use the domain rename tool, rendom.exe, to rename an Active Directory domain, the tool must be able to access the domain naming operations master. The domain naming master is the domain controller responsible for validating the instructions that the domain rename tool has generated for the new forest.

Certain changes occur on the domain naming master in preparation for the actual execution of a domain rename. On the domain naming master, the XML-encoded script containing the domain rename instructions is written to the msDS-UpdateScript attribute on the Partitions container object (cn=partitions,cn=configuration,dc=ForestRootDomain) in the configuration directory partition. The Partitions container can only be updated on the domain controller holding the domain naming operations master role for the forest. Therefore, the msDS-UpdateScript attribute must be changed on the domain naming master.

In addition to the msDS-UpdateScript attribute value being written to the Partitions container, the new DNS name of each domain being renamed is also written by rendom.exe to the msDS-DnsRootAlias attribute on the cross-reference object (class crossRef) corresponding to that domain. Again, because cross-reference objects are stored in the Partitions container and the Partitions container can only be updated on the domain naming master, the msDS-DnsRootAlias attribute can only be changed on the domain naming operations master.

The domain naming master replicates the script stored in the msDS-UpdateScript attribute and the DNS name in the msDS-DnsRootAlias attribute to all domain controllers in the forest through scheduled replication of the configuration directory partition.

In preparation of a domain rename operation; rendom.exe uses the domain naming operations master to:

Retrieve all information needed to compute the list of rename instructions for updating the configuration and schema directory partitions.

Write the resulting script to the msDS-UpdateScript attribute of the Partitions container.
Change the msDS-DnsRootAlias attribute of all cross-reference objects for domains that are being renamed.
Validate the forest description against the current state of the forest. If any of these validity checks fails, the command fails. The following requirements are verified:

Each existing domain is part of the new forest.
The new forest is well formed.
The new forest does not re-assign domain names that are being relinquished as part of the current domain rename operation.

For more information about domain rename, see "Domain Rename Technical Reference."
#################################################

Met vriendelijke groet / Kind regards,

Jorge de Almeida Pinto
Infrastructure Consultant
__________________________________________

<<...OLE_Obj...>>

LogicaCMG Nederland B.V. (BU SD/AT)
Division Industry, Distribution and Transport (ID&T)
Kennedyplein 248, 5611 ZT, Eindhoven
.       Postbus 7089
        5605 JB Eindhoven
(       Tel             : +31-(0)40-29.57.777
2       Fax     : +31-(0)40-29.57.709
(       Mobile  : +31-(0)6-26.26.62.80
*       E-mail  : [EMAIL PROTECTED]
"       <http://www.logicacmg.com/> - Solutions that matter -


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

==============================================================================
This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

==============================================================================
This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

Reply via email to