Jump to content

Webpage sets the system clock?

Recommended Posts

 Hello dear friends!


Would it be possible for a webpage designed purposely to set the clock of the computer that displays this page?


For instance, I have a small program called Atomic Clock Sync, found there


which visits the websites of a few atomic clock standards and sets my computer's clock.


I know, Xp does it alone. But up to 2k, Windows doesn't. Correspondingly, the v3.5 of Atomic Clock Sync installs on Xp only a user interface that tunes the behaviour of Xp's built-in synchronization. But from the same website, you can download the v2.7 through the link there


which does on Xp the same as on W95-98-Me-Nt4-2k: it sets the clock autonomously.


Interestingly enough, this v2.7 works perfectly even from a regular user session - no admin, no power user. Including on Xp, despite Xp throws normal users off if they try to use the Control panel for it. Once again, Xp protects only against legitimate users... And, well, Atomic Clock Sync displays a message because it's polite, but besides that, the user gets no warning from Windows and has nothing to accept nor confirm. In other words: a less benevolent program could set the clock without the user noticing it.


I can't exclude that several Api functions exist for that purpose, the older unrestricted, the newer demanding some privileges.


but anyway, the unrestricted function is available at least up to Xp.


The clock set wrongly could have some unpleasant consequences for the user. so:

  • Do you believe a webpage could do it? Say, by launching a Windows command or a Java program.
  • Would it need administrator privilege? (Not a big deal, since Oem computers use to have only admin sessions).
  • Would it need some sort of confirmation by the user? (Not a big deal neither, since most users would accept it)

Thank you!

Link to comment
Share on other sites

I also have a tiny program called RunAsDate


which provides a user-chosen date and time to an application. It just exposes additional functions

GetSystemTime, GetLocalTime, GetSystemTimeAsFileTime

and these being called instead of the Windows functions give the chosen information. Simple and tasteful.


Very nice for some applications. For instance FdTach was a beta version that stopped working on 20050101 but no final version was ever made.


Could an Internet webpage do the same? Bring the additional functions to be used by the computer on that same page? Or even, to be used on other pages - at least on some versions of some browsers?


The reason behind my query is that I'm worried about some encryption packages that rely on the computer's clock. I believe that this is very unsafe (in fact, all serious books warn against), but apparently such packages exist, so I try to evaluate the risk.

Edited by pointertovoid
Link to comment
Share on other sites

It was certainly possible in the early days of Flash... and I wouldn't doubt it would be possible nowadays but there are considerations. It really depends if the user wants the behaviour, sees it or doesn't see it and/or doesn't want it.

Link to comment
Share on other sites

Well, it all depends on the privileges in which the *whatever* is run.

To give you an example, see here:


basically the malware, in order to be able to install/use a proprietary driver, sets the date to one compatible with the "time restricted" authentication code/serial that the Author of the driver provides as "trial period".



Link to comment
Share on other sites





Here is my concern. The Aes standard describes an Aes-Ctr mode (which I believe it shouldn't have) where Aes serves to create a pseudo-random stream which is Xored with the plaintext to produce the ciphertext - that's called stream cipher traditionally.


Stream ciphers have a long tradition of failure. Not only is RC2 broken and RC4 badly wounded by over ten attacks; stream ciphers have also terrible weaknesses due to their very nature.

  • An attacker can trivially forge a modified ciphertext that has a known effect on the deciphered text (=the same Xor modification as on the ciphertext), so all the security relies on authentication; though, message digests too have a long tradition of failure and are necessary to authentication.
  • The Initial Value that feeds the pseudo-random generator must be unique - absolutely, totally, completely unique. If two Initial Values are identical, the user Xors the plaintexts with identical pseudo-random sequences.

Identical pseudo-random sequences would mean that

  • An attacker who knows one plaintext (for instance because he chose it) knows the pseudo-random sequence as well, even without knowledge of the encryption key, so he can decrypt the other ciphertext into the original plaintext;
  • Or with enough ciphertexts that have been Xored with the same pseudo-random sequence, the attacker can rely on loose information about the plaintext (like: "it's a Utf text)" to deduce the pseudo-random sequence with a good probability.

So identical sequences must be avoided at any cost, guaranteed to be impossible, and this is very hard - I'd say impractical. Some details there at "Ctr mode"





Alas, the Java example of Aes-Ctr by Chris Veness does exactly what shall not be done:


that is, its Initial Value results from

  • A block counter defined by the Aes standard - as predictable as a counter;
  • A pseudorandom number obtained from Math.random() - predicatble and settable;
  • And the computer's clock.

What may give a misleading sense of security is that this Initial Value (known under varied names like nonce) gets encrypted by Aes using the user's secret key. As long as Aes isn't broken, an attacker who knows the stream cipher won't deduce the secret key nor the inital value - but as we've seen, the attacker who knows the stream cipher doesn't even need more information.


Alas again, and as you had expected, it seems that many programmers have just kept the use of the system clock for serious cryptographic applications - in fact, they kept Chris Veness' code. The Aes standard had rather in mind that keys would be chosen in a complicated protocol, with very much entropy in them, and means to check that they were chosen honestly - certainly not the system clock and random().




So now, I wonder whether such cryptosoftware, which seems to have spread among computers, is very weak or rather extremely weak.

  • The block number is a sequence, identical for all encryptions.
  • The attacker can set Math.random() at will.
  • If the attacker can set the computer's clock, all is lost.

The attacker could then let encrypt an other text, known or chosen by him, with the same pseudo-random sequence as the coveted user's plaintext, end of the game.


The examples of Atomic Clock Sync 2.7 (which runs on Windows with user privilieges to set the clock) and RunAsDate (which provides a fake GetSystemTime() to an application) show that setting or providing a wrong system time doesn't need installation nor administrator privileges.


I may detail later attack protocols that look feasible to my eyes. Some may even be simpler than that.




Hence my query, whether an Internet webpage can set the clock (in html, Java...).

  • Administrator isn't a barrier: most computers have only administrators.
  • Unnoticed isn't so critical: many users would accept a query to adjust the clock or run a well-named program.
  • I wonder if a change made in one displayed webpage (like GetSystemTime() faked) would act on the other webpage displayed by the victim's computer.
  • And do you confirm that the persistent value of Math.random() is shared by all applications, processes, threads and webpages? Last time I checked it was so - as the only way to get different seeds for each start of an application.

Your help is welcome, thanks!

Link to comment
Share on other sites

So, could someone shed light about what a webpage can do or can't abou the clock and random()? I could make trials, but I programmed last time during the stdio.h era or little later, and have no desire to spend again all my time on programmation. Like: can a webpage supply a fake GetSystemTime() to the system or to an other webpage displayed by the same browser? [This can be necessary or not, depending on the attack scenario]


The previous explanation was sort of long, but not every reader is supposed to be a crypto expert - a crypto expert would in fact need no explanation at all to avoid stream ciphers and computer clocks, or worse, both together.

Link to comment
Share on other sites

Maybe I should tell first what the attacker may try, then you see concretely what it needs at the webpage and tell me what is feasible or not.


This attacker can listen the Web connection, introduce data on the connection, doesn't know the encryption key but wants to read or modify the encrypted data - this is what cryptography shall protect against.


The crypting method, which I fear is extremely weak, uses data from the system clock, plus a call to Math.random(), plus an incremental block number, as a "nonce" which is encrypted by Aes using the key to create a pseudo-random stream which Xors the plaintext to create the cyphertext, because the programmer was influenced by


as seemingly many were.




Most pseudo-random generators use successive multiplications modulo 2^32, or sometimes a Fibonacci sequence modulo 2^32 - or on bigger numbers. They offer a means to set the "seed" or initial value, and the ones I know keep one single state for all the calls of all applications and users.


That is, if the attacker wanted to know the value used by the crypto program, he would just call random() from time to time, and knowing the algorithm (if needed by observation) he would deduce which value was skipped from the sequence he obtained, hence given to the crypto algorithm.


Or, depending on the crypto algorithm, he would read this value in the clear data send over the Internet.


Then he could seed() the necessary value so the crypto algorithm obtains and uses always the same random() value. If necessary, the seed() value that results in a random() value desired by the attacker is easily computed.


Or the attacker could himself use always the same random() value to let encrypt a cleartext chosen by him.


Or he could regularly seed() the generator to some value so the crypto program gets always the same random() value.


Or he could provide a fake random() function to be used by the crypto program, or even only by the own attacker's webpage.




The system time is often defined in milliseconds by the software, sure... But the computer clock I observed was updated about 18 times per second, in increments of 50ms and 60ms. In other words: you would not get a time like 12345.678 seconds but only 12345.050 and later 12345.100 seconds.


So if an attacker estimates when the crypto software calls GetSystemTime() to 10s accuracy just by listening to the connection, he knows the value among only 200 possibilities - that's not cryptography. With an estimate accurate to 0.5s the uncertainty is among 10 possibilities. And if the crypto software transmits it in clear (normally it should hash it) then the uncertainty is gone.


Anyway, even if the "nonce" results from a hash, the attacker has to hash just 200 possible times and compare with the transmitted value to know what system time produced it.


What then?


The attacker could (can he?) set the system clock regularly to this deduced value, and then the crypto software uses always the same "nonce" - you know, the one that shall differ at any cost.


Or he could set the system clock right from the beginning, even before the crypto software uses GetSystemTime(), again and again and always to the same value. That must be possible from a separate webpage (is it?).


Or he could (can he?) provide a fake GetSystemTime() if the crypto software uses it.


And even worse: if the attacker can let the browser use the same crypto software and key for its own webpage (the crypto software may ask the user's key again, "as a confirmation" or whatever) then he can encrypt the plaintext he choses, which ends the game. In that case, the webpage can more easily provided faked rand() and GetSystemTime() functions since they are for its own use.


There are variants. The attacker's webpage could send often the encrypted chosen plaintext, so that one attacker's texts is probably encrypted at the same SystemTime() as the user's plaintext. This only needs to set the random().


Or the attacker's webpage could listen to the encrypted message, and later try a few SystemTime() to obtain the desired nonce to let encrypt his chosen plaintext.




My knowledge about browsers, their protections, and programmation is rusty. Your input is precious, thanks!

Link to comment
Share on other sites

  • 2 weeks later...

I've carried more trials on RunAsDate, the tiny application that provides a fake GetSystemTime() to an other application like FdTach.


I had used the v1.05 up to now, on Win95a-95b-98-98se-Me-2kSp4r1-XpSp3: even from a limited user session, it runs silently and permits the expired FdTach to run.


64b Seven does not accept the v1.05 of RunAsDate, but Nirsoft provides a v1.40 for W2k-to-8


I had to launch RunAsDate "as admin", and then I could designate FdTach which launched without complaining that time about the date.


So 64b Seven at least demands a user action (really every time? Can the user be fooled about the action or goal?) but still permits to fool an application. If this application is a crypto software that depends on the system clock as a non-repeating number source, that's annoying.


And anyway, many computers still run Windows Xp - plus all other operating systems: which ones do protect the clock? An Internet page running on an undefined computer cannot depend on this.

Link to comment
Share on other sites

  • 2 weeks later...

One additional worry is for computers whose mainboard battery is empty. Some won't start then, but many do and reset their clock to a fixed date like 01 Jan 1970.


Encryption made not much later after the computer started would then get a limited set of system dates - the same set every time. Imagine a system time upated 18 times per second: from t+1min to t+5min, it provides only 4320 different dates.


This may be less immediately exploitable by an attacker because it needs to hear more communications before some can be read - not necessarily the interesting ones - and works only for computers with an enpty battery, but it demands no intervention at all, no protection to break, nothing. Statistically, the attacker has to hear only 66 encrypted messages before having good chances that one pair (which he can't choose) uses the same system time for encryption.


We are very far here from secure cryptography, for which experts seek risks like 2-128 to get broken. An attacker with economic goals can perfectly target millions of computers, among which many have an empty battery, and after few weeks he will have a wealth of collisions among the stream ciphers and be able to read some ciphertexts with valuable information.

Link to comment
Share on other sites

I'm not trying to be disrespectful at all, but I'm confused as to what the current point of this thread is.


It started by asking whether a web page could change the system clock, then progressed to a discussion about cryptography methods that are based on the system clock, and now mentioning what the default behavior for the system clock is when the system's battery is run down or empty.


From the lack of responses, except that of Trip and jaclaz, it doesn't seem that anyone knows for sure whether it is possible today for a web page to change the system clock or not.  Is that still what you are trying to find out?  Or, if it is possible, are you trying to find out how to prevent it?  Or, if you can't prevent it, are you trying to find out how to safeguard encrypted files from being broken anyway?  And I'm not sure which OS this could impact, or is that yet another question you are trying to resolve?


I'm confused as to whether you are looking for an answer to some question, or if you are just trying to raise awareness of this possible method of attack so that some kind of block for it can be developed, or what?


Cheers and Regards

Link to comment
Share on other sites



it's true that the intended discussion resembles more a monologue, and includes more topics meanwhile. Perhaps my reasoning makes it clearer.


Elsewhere I read that some programmers use the system clock and random() as a nonce for a stream cipher through EAS CTR and got horrified, as should everyone with some crypto background.


Stream ciphers are known to be extremely difficult to program without introducing deadly weaknesses, and most dead ciphers are of stream type: RC2, RC4... Knowing that this mode brings no advantage over codebook or chained block modes, I wonder why the AES standard introduced it - and even, if this was meant to lure programmers into weak ciphers despite the core AES is considered safe.


In addition, it's well know that the system clock should not be used for cryptography, and the random() generators even less so. Though, this is exactly what was recommended elsewhere.


Then I saw the webpage by Chris Veness


which does everything that shall not be done: stream cipher and system clock and random().

That author tells "as an example"... I can't decide whether this is a case of a programmer ignoring cryptography who imagined he could do it, or if a governmental agency offered this free model to be copied by as many programmers as possible to sabotage the encryption.


Seasoned cryptographers wouldn't even consider any one of these, but as it seems, some (many?) programmers have just taken Chris Veness' horrors as they are, and programmed real web pages like this. Cryptographers wouldn't need a practical attack to stay away from what smells unhealthy, but well, I wanted to check how easy an attack is.



  • My query, which still stands, about the ease of programing it;
  • My strongest warning against copying the frenzy from Chris Veness' page - also against the CTR more and using the system clock and against random();
  • And a first description of a plausible attack against computers with an empty battery, when I imagined it.


Link to comment
Share on other sites

  • 4 years later...

Hi everybody, nice to see you again!

I had imagined that resetting a computer's clock might be a way to weaken its encrypted communications, especially if they are as poorly programmed as what the cited webpage gives as an example. Recently at my close relatives, two computers have shown abnormal clock resets.

  • At my old mother, the Cmos' battery was empty. I replaced the battery with a new one from a reputed brand bought in a closed package a quarter hour before, I set the clock, and the computer worked properly. A week later, this computer lost the date again. The computer was far from me, I got the account over my mother.
  • At my nephew, who is comfortable with Pc hardware and can replace a battery, the computer with a recent battery lost the date.

I had expected a reset date like 01 Jan 2000 or 01 Jan 1970, as usual with an empty battery, but at my mother's machine it was like 31 December 2001.

So: did you observe something similar recently? The alternative explanation would be a malware that sets the computer's clock, possibly to exploit the weakness I outlined above. I could admit a hardware defect drawing the battery empty at one mobo, not at both.

Thank you!

Link to comment
Share on other sites

On 6/28/2019 at 11:31 PM, pointertovoid said:

So: did you observe something similar recently? The alternative explanation would be a malware that sets the computer's clock, possibly to exploit the weakness I outlined above. I could admit a hardware defect drawing the battery empty at one mobo, not at both.

Well, my brother in law's automatic irrigation system and my nephew's home alarm system (which has also some "smart home" features such as remote (via Android app) switching on and regulating heating/cooling)  both lost their date/time last week.

While the second is connected (through a SIM/Cellular network) to the internet, the first is not.

So, I would attribute at least the first case to little green men tired of stealing socks, but I am perplexed by the second case. :dubbio:

Since - according to Gibbs' Rule #39:


There is no such thing as coincidence.

summing up your recent experience with mine Rule #40 must apply:


If it seems like someone is out to get you, they are.

or - maybe - Rule #36:


If you feel like you are being played, you probably are.

We have too few data points to plot a trend/theory, a possibility is that little green men are both tired of stealing socks AND have an internet access. :unsure:



Link to comment
Share on other sites

Thanks Jaclaz!

I'd need more evidence before involving little green men in this story (or elsewhere).
And I'd like to know why a mobo with a new battery should lose the date. Or even two mobos.
So I'm still interested in testimonies: did other people observe an abnormal clock reset on their mobo?

Thank you!

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...