Message-ID: <200408201521.i7KFL5ex015101@pop-7.dnv.wideopenwest.com>
Date: Fri, 20 Aug 2004 11:15:58 -0400
From: "joe" <mvp@...ware.net>
To: "'3APA3A'" <3APA3A@...URITY.NNOV.RU>
Cc: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.netsys.com>
Subject: RE: Re[2]: Security aspects of time synchronization infrastructure


Thanks.

So assuming that the time change of a great (epoch date) magnitude could
occur [1], it would occur in a fluid way across the entire forest (or at
least the MS machines that are part of it). Have you actually tried to
change time to some arbitrarily large and incorrect value and see if other
machines can sync when it is set that way or is this speculation? 

Beyond that, time maintained on the Windows machines is not time_t based, it
is FILETIME based (64 bit value whichis the number of 100 nanosecond
intervals since 1/1/1601) format which should be able to represent any 4
digit year > 1601. It can probably go beyond 4 digits but I don't expect any
date routines will support a 5 digit year (holy crap - we now have a Y10K
issue thanks MS, can't wait to have to deal with that one). 

Now that I see where you are going in terms of a vast major change to epoch
ending, assuming the time change would sync across the forest I would guess
that you could have a breakdown in kerberos if you somehow pushed the date
beyond time_t capabilities but that is a guess. I am not sure how kerberos
time is represented in the kerberos internals, are you aware of that format?
Is it time_t? I would say that would be the main thing that could prompt you
to say that the forest would be down. I would expect local logons to domain
controllers by admins would still work (though they would probably have to
change their password while logging on), the overall functionality of the
environment would be unavailable - but again, this assumes kerberos stops
working. 

Also I would guess various and sundry apps (or services) would possibly do
odd things based on how they internally needed and used time. I would guess
the event logs might be a little hokey for some apps. Accounts would lock if
something was automatically sending the now bad passwords and not responding
to the password has expired message (this assumes kerberos is working at all
though which means the forest is actually up). This would impact mostly
service accounts I would guess as well as network/application connections
for people who were currently logged in. 

I really don't see why you feel a 12 hour change would hurt that much other
than forcing an early refresh on kerb tickets. Do you have more detail on
your thoughts on that? Specifics.

So besides getting to a point where kerberos breaks due to how the time is
structured in kerberos I don't see a forest that is down. If the time
changed exceeded your tombstone period AND synced properly I could see
replication stopping due to the delta from the last replication and not
wanting to corrupt with possible bad data (i.e. lingering/revived objects).
However the forest would be up and functioning in terms of authentication,
you would just have to get the time corrected so replication kicks back in -
which if it allowed the change in the first, place the change in the second
place should be pretty easy.

Anyway, I don't know how much of this I would push as an issue without
actually testing to see what would happen. If the date was able to be pushed
far enough, it could be painful, if kerberos is time_t based, then it could
break. I would suggest working that out specifically. If you can actually
force a bad date into the PDC emulator of the forest (and I am not arguing
this point, I don't know enough about it), will it sync to the rest of the
forest? And if so, can the date change be enough to break kerberos? I think
in order to call the forest down, you would have to break either name
resolution or authentication. I don't see name resolution breaking here, so
you focus on authentication which would fall on kerberos. 

  joe


[1] I am still not entirely confident would occur, I think the downstreams
would reject the time source but have no solid testing to prove this. 


 

-----Original Message-----
From: 3APA3A [mailto:3APA3A@...URITY.NNOV.RU] 
Sent: Friday, August 20, 2004 2:22 AM
To: joe
Cc: bugtraq@...urityfocus.com; full-disclosure@...ts.netsys.com
Subject: Re[2]: [Full-Disclosure] Security aspects of time synchronization
infrastructure

Dear joe,



--Friday, August 20, 2004, 2:59:06 AM, you wrote to 3APA3A@...urity.nnov.ru:

j> "If network is configured in accordance to these recommendations it's 
j> possible  to  bring  whole Windows 2003 forest down with a single UDP 
j> packet."

j> What is your line of reasoning here? In a properly configured forest, 
j> all machines will take their time from their default time source and 
j> not from a preconfigured machine as you outlined. If the time on the 
j> PDC emulator of the forest is spanked into a new value, either the 
j> other machines will be unable to sync with it due to not being able 
j> to authenticate with it or the

Time  synchronisation  doesn't require authentication, at least it looks
like  packets  are  only signed with computer key. That's why it's still
possible  to  change time across all forest with a single packet, if one of
the forest's reliable time sources or PDC emulator in root domain use
external SNTP server.

Before  Windows  2000 SP4 it was possible to set date far in future (for
example  to  2038). Locked accounts, expired certificates in addition to
"problem  2038"  (Jan,  19  2038 is maximum date value for 32 bit time_t
timestamp used in many C compilers). But setting date 12 hours in future or
12 hours in past still can produce a lot of harm.

--
~/ZARAZA
Итак, я буду краток. (Твен)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists