61

I recently wanted to see what happens when I change my local time to something obviously wrong. I tried the year 2218, so 200 years in the future. The result: I couldn't access any website anymore (I didn't try too many, though). I got this error:

enter image description here

I guess NET::ERR_CERT_DATE_INVALID means that an HTTPs certificate is not valid. But usually there is an "advanced" option that allows me to ignore it. Not so here. Also, I wonder why it says "your clock is ahead" - if chrome knows the correct time, why doesn't it take this for comparing?

Coming to my question: How important is local time for security? If an attacker can arbitrarily change the system time, which kinds of attacks allows this? Are there reported cases where time manipulation was a crucial part?

Martin Thoma
  • 3,902
  • 6
  • 30
  • 42
  • 52
    "if chrome knows the correct time, why doesn't it take this for comparing?" - I don't know how it's checking that, but 200 years in the future is rather obviously incorrect. It's possible to know that something is incorrect without knowing what the _correct_ data actually is. – AndrolGenhald Sep 11 '18 at 18:41
  • This does not affect just the browsers. When something happens to a server and the system time is changed/desynchronized, even by just hours, it may cause issues to connect to other services in the network (happened multiple times to me). – Giacomo Alzetta Sep 12 '18 at 10:44
  • 4
    Probably chrome does not know the correct time, but knows that the certificate validity is way out of range. – allo Sep 12 '18 at 11:50
  • [This video](https://www.youtube.com/watch?v=ylfyezRhA5s) by LiveOverflow does a pretty good job of showing some of the issues that can stem from bad time management. – brittenb Sep 12 '18 at 15:25
  • @AndrolGenhald So Chrome was deliberately designed to fail after a certain amount of time? – Acccumulation Sep 12 '18 at 15:40
  • 3
    @Acccumulation As I said, I've not bothered to check how it's implemented. Could be if it sees a certificate that expired more than 10 years ago it just assumes your clock is wrong. – AndrolGenhald Sep 12 '18 at 15:55
  • 5
    @Acccumulation It could be based on the current version's release date as well. – IllusiveBrian Sep 12 '18 at 17:17
  • 7
    @AndrolGenhald I would guess that Chrome itself has a time lookup with its own time servers built in. I'm sure it uses the local time, but I wouldn't be at all surprised if a network time lookup happens in Chrome to know the "real" time regardless of what the local time says. – Conor Mancone Sep 12 '18 at 18:58
  • 1
    Again just speculation, but the TLS protocol also (often) encodes the local server time, which could be compared against local time. – forest Sep 12 '18 at 20:28
  • 1
    " But usually there is an "advanced" option that allows me to ignore it. Not so here" > I can see "Advanced". Yes, it's greyed out, but I think you *may* be able to click it – usr-local-ΕΨΗΕΛΩΝ Sep 13 '18 at 16:31
  • 1
    @ConorMancone: Chrome can't be certain that the keys used by its trusted time servers won't be cracked sometime between in the next 200 years. If the computer's clock says it's now 9/13/2218 but what *seems* to be the trusted time server reports that it's 9/13/2018, Chrome would have no way of knowing whether the server is being truthful, or whether the computer's clock is right and the server is a lying phony, using a key that got cracked sometime in the 200 years since 2018. – supercat Sep 13 '18 at 19:07
  • 2
    At least the browser is telling you your local clock is probably wrong. This took us too long to track down when the browser didn't tell us. – Joshua Sep 13 '18 at 20:59

9 Answers9

68

You have a bunch of questions rolled in there.

I guess NET::ERR_CERT_DATE_INVALID means that an HTTPs certificate is not valid.

Yes.

Here is the cert for help.ubuntu.com:

Certificate for help.ubuntu.com

You'll notice that it has Valid From and Valid Until dates; if you try to access a site protected by this cert outside of these dates, your browser will complain. The reason certs expire is (among other reasons) to force webmasters to keep getting new certs using the latest crypto and other new security features in certificates.

When your browser is trying to decide if it trusts a certificate, it uses the system clock as the definitive source of truth for time. Sure, it'll try to use NTP, but if you (the admin user) have explicitly told it that the NTP servers are wrong, well, you're the boss.

If an attacker can arbitrarily change the system time, which kinds of attacks allows this?

Let's consider personal computers and servers separately. I haven't done any research here, just off the top of my head.

Personal Computers

  • Users often play games with their system clock to get around "30-day trial" type things. If you're the company whose software is being used illegally this way, then you would consider it a security issue.
  • Spoofed websites. It's much easier to hack old expired certificates -- maybe it used 10 year old crypto that is easily cracked, or maybe the server was compromised 6 years ago but the CAs don't track revocation info for that long (idea credit: @immibis' answer). If an attacker can change your system clock then you won't see the warnings.

Servers

  • Logging. When investigating a security breach, if your servers' clocks are out of sync, it can be very difficult to piece together all the logs to figure out exactly what happened and in what order.
  • Logins. Things like OTP 2 factor authentication is usually time-based. If one server's clocks are behind a different server, then you could watch someone enter an OTP code, then go use it against the server that's behind because that code won't have expired yet.
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 4
    Also, obviously, denial of service. If the server uses some third-party web services by HTTPS, the requests will start to fail just like the browser did above. – IMil Sep 12 '18 at 03:25
  • 16
    w.r.t. logins, not just OTP 2 factor auth is affected. Kerberos requires computers to be reasonably in sync ("to prevent replay attacks"). Windows domains, using Kerberos, for example, require computers to be within 5 minutes of each other (by default) or you can't get authorized on the domain. – davidbak Sep 12 '18 at 05:35
  • 2
    Another issue, brought up at this year's DEF CON, is the fact that someone may register a website that was previously registered and may even still have a valid certificate that the previous owner has access to. The expiry date ensures that this will not go on indefinitely. – forest Sep 12 '18 at 20:34
  • Weak algo certificates could be revoked. The reason of many short lived certificates is, in my subjective opinion, money. – bradbury9 Sep 14 '18 at 07:33
  • 1
    @bradbury9 Maybe. Browsers will complain about old crypto (ex MD5 / SHA1) or missing security features (Certificate Transparency), _**if**_ the victim is using an up-to-date browser. I could be wrong, but I think it's actually the browsers, not the CAs, that drove the decision for a 2-year max cert lifetime, and the CA with the shortest cert lifetime - Let's Encrypt at 3 months - is completely free. – Mike Ounsworth Sep 14 '18 at 11:20
  • 5
    Upvoted for "well, you're the boss". Sometimes users can be their own worst enemies no matter how good the security system. :-) – Ben Sep 14 '18 at 18:39
27

One reason is that certificate revocation records are not kept after the certificate expires.

Suppose I stole Google's certificate 10 years ago. Google immediately noticed and revoked their certificate. Since the certificate expired some time in the last 10 years, the revocation entry was deleted. If I set your clock back 10 years to when it was valid, I can impersonate Google and your browser won't notice, because it won't know it was revoked.

user253751
  • 3,885
  • 3
  • 19
  • 15
  • 2
    It seems to me you describe the reverse of the question. OP shows when you change the local time, the browser accepts the change and act accordingly. If anything, this behaviour makes the attack you describe possible, it does not seem to prevent it. – Suma Sep 13 '18 at 08:39
  • @Suma, for security purposes Chrome will always use the user's computer's time. The browser says "This cert expired 2018-12-09 and it is currently 2218-08-06, so the cert cannot be trusted and a certificate error page is needed". After determining that a certificate error page is needed, Chrome tries to create an appropriate page, by guessing the root cause of the problem. In this case Chrome guessed that maybe the certificate is not actually 200 years old, maybe your clock is wrong. So Chrome suggested that you change your clock. – Buge Sep 15 '18 at 23:14
18

Your question is broad, but if an attacker can change the local system clock, then they can poison the logs of their activity. That way, they can hide their activity to appear to have occurred sometime in the past (and maybe beyond the window that the admins are looking for activity) or to coincide with other user's activity.

For example, if you break into a system in the middle of the night, you can set the clock to be at noon the previous day, do your activity, then set the clock back. Anyone inspecting the logs will assume the normal user did the activity (or not see it at all among the normal user's activity).

This is why setting your clock to be synced with an authoritative external source is important. That, and that all logs from all sources can be properly correlated.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 3
    This doesn't address why an out of sync clock is an issue in this particular case. – Austin Hemmelgarn Sep 11 '18 at 23:59
  • 1
    It's a broad question and I tackled part of it. – schroeder Sep 12 '18 at 07:13
  • Hm... that is only true if there are multiple systems involved, right? Because logs are usually written line by line (appended to a textfile). This means the attacker could "slow down time" without notice, but if the attacker "went back in time" (making the log entries not chronological) it would be super easy to spot the ones where he manipulated time. – Martin Thoma Sep 14 '18 at 05:09
  • @AustinHemmelgarn Being the title "How important is local time for security?" Well, it kinda fits. – bradbury9 Sep 14 '18 at 07:36
  • @MartinThoma how would you notice the log entries that have the fraudulent time? – schroeder Sep 14 '18 at 08:14
  • 1
    This is also why some logging solutions include sequence numbers with the entries, or, for example, why linux kernel logs use seconds since boot. – Joel Coehoorn Sep 14 '18 at 16:01
  • 1
    @schroeder `for i in range(1, len(loglines)): if loglines[i]['time'] < logline[i-1]['time']: print("line {} has fraudulent time".format(i))` – Martin Thoma Sep 15 '18 at 11:12
18

If an attacker can arbitrarily change the system time, which kinds of attacks allows this?

Beyond certificates...

Poorly seeded RNGs

They may be able to exploit a poorly seeded random number generator. Using time as a seed used to happen a lot before better random number interfaces realized your average programmer can't be trusted to provide a good seed. An attacker can exploit this by setting the system time to a time where the random number generator will produce their desired output.

Of course, the attacker can save themselves a lot of hassle by simply waiting for a desirable time.

UUIDs

UUIDv1 and v2 both depend on the MAC address and the time. The MAC address can be discovered. Being able to set the time means they can now control which UUID is assigned next. For example, they may be able to duplicate the UUID of an administrative account for themselves. Of course, UUIDv1 and v2 are not meant to be secure, they're just meant to be unique. If you want secure and unique you use UUIDv4, but there's plenty of software which uses UUIDv1 and v2 inappropriately.

Periodic jobs

Many systems have critical processes which run periodically at certain days and times. The attacker can mess with the time to manipulate this.

Many systems have maintenance windows which occur at certain times. The attacker could continuously reset the time to remain in this window and keep the system down for maintenance.

If there is a resource intensive process which occurs periodically, they can mess with the time such that multiple of those processes are running at the same time. If the system does not limit the number of simultaneous processes this can swamp the system.

Or you can go the other way and continuously reset the time to prevent a critical maintenance process from running.

Watchdogs

The system may have watchdog processes which look for too many or too few actions happening in a window of time. The watchdog may choose to take automatic maintenance action such as restarting machines or stopping services. An attacker can manipulate the time to make it seem as if the rate is too high or too low tripping the watchdog and causing it to halt a working system.

Schwern
  • 1,549
  • 8
  • 17
  • Source for UUIDv4: [Section 4.4](https://tools.ietf.org/rfc/rfc4122.txt) – Martin Thoma Sep 15 '18 at 11:22
  • +1 Good answer, but I'm not sure I totally agree. 1) cryptographic RNGs are seeded from things other than the clock, ex.: previous seed, disk IO events, network packet events, so full control of the clock will not give your full control of the seed. 2) even UUIDv4 is not intended to be secure: _"4.4. Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers"_ so any software which uses a UUID as a client secret is probably bad software. 3) Great point about periodic jobs and watchdogs, another good example is advancing the clock to skip over the antivirus' scheduled scan. – Mike Ounsworth Sep 16 '18 at 13:33
  • 1
    @MikeOunsworth Sure, if you're doing it right the first two aren't a problem, but... 1) [The amount of code that is seeding with `time` will shock you](https://github.com/search?q=srand+time&type=Code). 2) Lots and lots of software exposes their UUIDs. – Schwern Sep 16 '18 at 18:30
  • 1
    @Schwern Good discussion! 1) `srand` doesn't claim to be a cryptographically secure RNG. `srand(time());` is fine if you're, for example, generating texture maps; if people are using `srand` to generate cryptographic secrets then yeah, that would be a problem. 2) I'm not sure why that's a problem? In our software we base our security model on the assumption that attackers can figure out UUID values if they really want to. So if a developer needs to expose a UUID for whatever reason, whatever. UUIDs (like any other kind of ID) should not be used as an auth token. – Mike Ounsworth Sep 16 '18 at 19:27
  • 2
    "*In our software we base our security model on the assumption that attackers can figure out UUID values if they really want to.*" That's excellent. A lot of software does not. These are attacks which exploit common, small security mistakes. – Schwern Sep 16 '18 at 19:32
  • @Schwern Oh I see. You're not talking about how _good_ software is built, you're talking about how _bad_ is built. Touché. – Mike Ounsworth Sep 17 '18 at 02:53
3

There would be two possible situations where a computer that thinks the year is 2038 tries to connect to the outside world, and everything in the outside world says that it is 2018:

  1. The computer's clock is wrong.

  2. The year is actually 2038, and everything in what seems to be the outside world is being faked, using certificates from 2018 that have been cracked in the 20 years since then.

Although attacks of that form would be hard enough to pull off that the first possibility would in practice be far more likely, guarding against the second would require getting confirmation that the computer's clock actually is wrong.

supercat
  • 2,029
  • 10
  • 10
  • Hm. And where do you draw the line? What is an acceptable difference to the outside world? – Martin Thoma Sep 14 '18 at 05:16
  • 1
    @MartinThoma: If a computer's clock is within the range where its certificates are valid, then the certificates are probably valid. If the computer's clock is outside that range, it's possible (and in some cases likely) that the certificates are actually valid and it's merely the computer's clock that's in error, but a computer can't be certain that any external time server is trustworthy without a certificate that's valid at the computer's reported time. If external time servers consistently report times that are "in the past", that would suggest that... – supercat Sep 14 '18 at 14:35
  • 1
    ...a diagnostic about the computer's clock being in the future will be more helpful than a message saying all the certificates have expired, but should allow for the possibility of a user looking at a message "Your computer's clock says it's 2018, but everyone else says it's 2012" and saying "It is 2018; the servers claiming 2012 are wrong--probably deliberately so." – supercat Sep 14 '18 at 14:38
  • So your line is a calendar year. This means 365 days wrong in a leap year would be ok, but one day more is not. – Martin Thoma Sep 14 '18 at 15:06
  • @MartinThoma: What times would be acceptable would depend upon what certificates the computer happens to have installed at any particular moment. – supercat Sep 14 '18 at 15:23
2

If you are running a single Windows Domain Controller, or part of it's network, a time difference of only five, or a few minutes can be critical: Kerberos Time Tolerance

I once had to deal with a failed Windows SBS 2008 Server and had to find a way to get in as SYSTEM to read the Event Log.

It turned out that a power surge had reset the CMOS BIOS clock on the Domain Controller, back to the system design date, some years before. The result being that Kerberos tickets could not be issued.

Kerberos tickets are valid for just a few minutes.

birdwes
  • 43
  • 5
0

Another (slightly convoluted) example of an attack against a computer with lagging system time is serving outdated DNS records from a zone secured with DNSSEC.

For example, if client asked for www.example.com address, the attacker could reply with a referral to his own DNS server and an (expired) proof of non-existence of a DS record for example.com from the time when example.com was not yet signed, and subsequently serve forged DNS records for anything in example.com zone.

Edheldil
  • 885
  • 5
  • 9
-3

It could be considered faking and not having the computer clock synced always could have its advantages and disadvantages. Obvious ones are those already pointed. One advantage is websites will not know your real date, although this would enter more into privacy than security per se, normally privacy is considered part of security.

I don't know much about NTP enumeration but its used in pentesting so it's a factor to take into account for security.

"The Network Time Protocol is a protocol for synchronizing time across your network, this is especially important when utilizing Directory Services. There exists a number of time servers throughout the world that can be used to keep systems synced to each other. NTP utilizes UDP port 123. Through NTP enumeration you can gather information such as lists of hosts connected to NTP server, IP addresses, system names, and OSs running on the client system in a network. All this information can be enumerated by querying NTP server." source: "https://www.greycampus.com/opencampus/ethical-hacking/ntp-enumeration"

Devuan User
  • 5
  • 2
  • 3
    This answer lacks concrete details to be useful to me. What is a scenario where it does harm that websites don't know the local time on my machine? How is that a privacy issue? – Martin Thoma Sep 11 '18 at 20:24
  • If you are using a vpn or proxy and your system is using a different time zone than what your ip should have... then any person would consider you are using a vpn or proxy. Most proxies and vpns are not able to hide the time clock of your operative system by default and websites can read that (therefore pointing to the place you live even if using a proxy/vpn, therefore breaking down your privacy) – Devuan User Sep 11 '18 at 20:47
  • @DevuanUser there are a lot of conditions that need to apply: 1) the site would have to look up your IP against the location and look up the timezone, 2) the javascript on the page would have to query local time and send it back to the server, 3) your VPN would have to be in a different time zone than you are. These are important conditions and should not be glossed over in such a short description. – schroeder Sep 11 '18 at 21:01
  • This also does not appear to answer the question about malicious changing of the time. – schroeder Sep 11 '18 at 21:02
  • Well the creator of the thread wondered about security and I have give an answer so he understands possible daily problems that could arise with the clock synching or not. On the other hand though... I will add another answer. – Devuan User Sep 11 '18 at 21:08
  • NTP enumeration does not apply to the situation – schroeder Sep 11 '18 at 21:11
  • "NTP enumeration does not apply to the situation" the question is "How important is local time for security?" The way 99% of internet users do synch their machine to local time is by usage of ntp servers so you do understand how it does really relate one thing to another. ---Added source, noted for the future, thank you--- – Devuan User Sep 11 '18 at 21:19
  • 8
    *"One advantage is websites will not know your real date"* — your real date is the same as everyone else's. We're in the same universe, and we have just the one agreed-upon time stream that we hold in common. Like space. (Exercise: I'm going to conceal how many dimensions I'm in right now, for security purposes. What? You guessed three? Darn it! How did you know?) – Wildcard Sep 12 '18 at 00:35
  • 5
    NTP protocol only exchange timestamp in UTC, no matter the settings of the client & server. So the most an NTP server might get is the machine from a certain IP is off-sync by certain period. Ironically, if it's consistently out-of-sync by a fixed period, the data can be used to track the machine even after IP address change. Compared to regularly synced machine that will have similar offset period with other machines in the region. – Martheen Sep 12 '18 at 04:34
  • @Wildcard Being pedantic, one could say that time is relative. In most cases it doesn't matter, but e.g. for GPS it does. So we don't all have the same time. Also, TAI is an average of several atomic clocks because of exactly this problem. (Anyway, I agree with the general point that this argument / answer does not make much sense) – Martin Thoma Sep 12 '18 at 10:58
  • You can avoid giving out your _local_ time just by setting the timezone for your browser to UTC. This is what Tor Browser does, for example, yet it's still clearly able to detect certificate expiry. – forest Sep 12 '18 at 20:35
-3

Many software, especially those that are working in a cluster, time sync is very important. So if someone messes with the time then the software running on this system will cause a lot of issues, especially with sync. This will eventually count as service impacting.

schroeder
  • 123,438
  • 55
  • 284
  • 319
PrashantKC
  • 1
  • 4
    Welcome! This looks more like a comment, than a full answer. I recommend removing it and adding it as a comment on one of the other answers, or add enough information to make it into a full answer. – browly Sep 13 '18 at 22:51
  • I think for writing a comment you must have at minimum 50 points: https://stackoverflow.com/help/privileges – Martin Thoma Sep 16 '18 at 06:04