Interesting paper. I am curious about this statement though as you seemingly
don't give supporting information.
"If network is configured in accordance to these recommendations it's
possible to bring whole Windows 2003 forest down
with a single UDP packet."
What is your line of reasoning here? In a properly configured forest, all
machines will take their time from their default time source and not from a
preconfigured machine as you outlined. If the time on the PDC emulator of
the forest is spanked into a new value, either the other machines will be
unable to sync with it due to not being able to authenticate with it or the
forest time will change and authentication will continue on. It could impact
kerberos certs in that they may need to be reissued sooner, but I fail to
see an issue where the entire forest could be brought down. I could see this
having adverse affects on MIT trusts and non-MS kerberos clients unless they
have the Vintela or Centrify *nix/Win integration software (or other
software configured to do the same) that forces a timesync with the Forest.
If you would prefer to discuss offline, that is fine as well.
Thanks, joe
-----Original Message-----
From: full-disclosure-admin (at) lists.netsys (dot) com [email concealed]
[mailto:full-disclosure-admin (at) lists.netsys (dot) com [email concealed]] On Behalf Of 3APA3A
Sent: Thursday, August 19, 2004 5:26 PM
To: bugtraq (at) securityfocus (dot) com [email concealed]
Cc: full-disclosure (at) lists.netsys (dot) com [email concealed]
Subject: [Full-Disclosure] Security aspects of time synchronization
infrastructure
Hello bugtraq,
I published whitepaper called "Security aspects of time
synchronization infrastructure". It describes some observations on
very common security flaws in time synchronization infrastructure
design, including (but not limited to) MS Windows Active Directory.
don't give supporting information.
"If network is configured in accordance to these recommendations it's
possible to bring whole Windows 2003 forest down
with a single UDP packet."
What is your line of reasoning here? In a properly configured forest, all
machines will take their time from their default time source and not from a
preconfigured machine as you outlined. If the time on the PDC emulator of
the forest is spanked into a new value, either the other machines will be
unable to sync with it due to not being able to authenticate with it or the
forest time will change and authentication will continue on. It could impact
kerberos certs in that they may need to be reissued sooner, but I fail to
see an issue where the entire forest could be brought down. I could see this
having adverse affects on MIT trusts and non-MS kerberos clients unless they
have the Vintela or Centrify *nix/Win integration software (or other
software configured to do the same) that forces a timesync with the Forest.
If you would prefer to discuss offline, that is fine as well.
Thanks, joe
-----Original Message-----
From: full-disclosure-admin (at) lists.netsys (dot) com [email concealed]
[mailto:full-disclosure-admin (at) lists.netsys (dot) com [email concealed]] On Behalf Of 3APA3A
Sent: Thursday, August 19, 2004 5:26 PM
To: bugtraq (at) securityfocus (dot) com [email concealed]
Cc: full-disclosure (at) lists.netsys (dot) com [email concealed]
Subject: [Full-Disclosure] Security aspects of time synchronization
infrastructure
Hello bugtraq,
I published whitepaper called "Security aspects of time
synchronization infrastructure". It describes some observations on
very common security flaws in time synchronization infrastructure
design, including (but not limited to) MS Windows Active Directory.
http://www.security.nnov.ru/advisories/timesync.asp
Any comments are very appreciated.
--
/3APA3A
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
[ reply ]