62

If I create a servlet that would return the server time publicly (no need for authentication), would this be a security issue? I couldn't think of any issue with this, but somehow something tells me I could be wrong.

To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).

Manny
  • 651
  • 1
  • 5
  • 7
  • What you should have asked was "How much of a security risk is publicly exposing my server's time?" Exposing **anything** about your system is a potential risk, although time (assuming it's accurate) is at the lowest end of the threat spectrum. – Ian Kemp Jun 08 '18 at 20:48
  • 1
    By the way, the "server time" should be UTC and set via NTP, which means that it's public information anyway. (Oh, and if you're writing servlets directly instead of using a framework like Spring or Dropwizard, that hand-implementation is much more likely to cause security vulnerabilities than exposing the time.) – chrylis -cautiouslyoptimistic- Jun 09 '18 at 03:30
  • You should assume they can change anything. If they're willing to change the date on their phone, who's to say they won't intercept the response from the server at their firewall and change the date there too? The only thing you can rely on a client to tell you is what the client would like to do. Any other validation, no matter how trivial, must be assumed to be compromised and checked somewhere you can trust it. – corsiKa Jun 10 '18 at 16:20

7 Answers7

89

The server time is of little use to an attacker, generally, as long as it is accurate. In fact, what is being revealed is not the current time (after all, barring relativistic physics, time is consistent everywhere) so much as the time skew. Note that, even if you do not explicitly reveal the time, there are often numerous ways to get the local server time anyway. For example, TLS up to and including version 1.2 embeds the current time in the handshake, web pages may show the last modified dates of dynamic pages, HTTP responses themselves may include the current time and date in response headers, etc.

Knowing the exact clock skew of a server is only a problem in very specific threat models:

  • Clock skew can be used in attacks to deanonymize Tor hidden services.

  • Poorly-written applications may use server time to generate secret values.

  • Environmental conditions of the RTC may be revealed in contrived situations.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
forest
  • 64,616
  • 20
  • 206
  • 257
  • 36
    [The current time must also be sent in any HTTP response](https://tools.ietf.org/html/rfc7231#section-7.1.1.2). – Benoit Esnard Jun 08 '18 at 09:36
  • 2
    Does it become a problem when the server time is not accurate? – Todd Sewell Jun 08 '18 at 10:26
  • 5
    @ToddSewell If the server time is not accurate, an attacker can abuse that in various ways. TLS and certificates in general rely on accurate system time. – forest Jun 08 '18 at 10:27
  • 13
    Related, I wrote a guide to a bunch of [different ways you can determine the time on a remote server](https://github.com/gsuberland/infosec-tricks/blob/master/remote_server_time.md). – Polynomial Jun 08 '18 at 11:33
  • 3
    _"as long as it is accurate"_ This seems to imply that server time being *in*accurate would be a security issue. Is it? If so, how? – code_dredd Jun 08 '18 at 22:23
  • A couple more points relating to security; Synchronized time is sometimes a built-in dependency for the correctness of some distributed systems, such as Cockroach DB using timestamps to resolve transaction conflicts, or to protect against replay attacks, as in the Single Packet Authentication protocol used by the dynamic remote firewall reconfiguring tool `fwknop`. I wouldn't rule out the possibility that some clever and determined attacker might find a way to exploit knowledge about clock skew (especially changes in clock skew *over time*) and some such protocol for data corruption or DoS. – mtraceur Jun 08 '18 at 22:53
  • 1
    "after all, barring relativistic physics, time is consistent everywhere" But data going through a fiber optic cable moves at roughly 2/3c. (Reaching the destination may be slower since the light is bouncing around a lot, but it's still moving *dang* fast.) – jpmc26 Jun 09 '18 at 01:12
  • @jpmc26 But the data is light which has no mass, so their speed does not cause any time dilation effects (simplifying a bit here, since photons technically are "frozen" in time from their creation to their absorption). – forest Jun 09 '18 at 04:22
  • 1
    @ray An inaccurate clock is a security issue. As I mentioned briefly above, TLS requires accurate time to be secure. The same is true for many other certificate-related activities such as cryptographic verification done by the package manager. – forest Jun 09 '18 at 04:23
  • @forest so an attack would be, if the sever is asking for client certificates and you know its clock is six months behind, then you can give it an expired certificate instead? However, you don't need to have the time exposed in order to make such an attack - you can just try it anyway. – OrangeDog Jun 09 '18 at 21:13
  • @OrangeDog Right. I didn't mean that a skewed clock is only a problem if you know it's skewed. – forest Jun 10 '18 at 01:50
11

"Servlet" sounds like you're already running a complex server there.

There's a lot of ways that protocols leak server time. For example, HTTP has a popular header field for creation/modification time, and dynamically generated data would always have the current system time, if used properly.

For TLS authentication reasons, you can even binary search to find an endpoint's date and time using expiring client certificates.

This is a necessary evil – if you're doing TLS, your server needs to have a notion of time to know what's a valid key / cert and what not. If that's the case, this will very likely be an NTP-coordinated time. So, you really can't tell anything about the server that an attacker wouldn't already know – there's really only one "correct" time.

If you're not doing TLS: leaking system time is probably not the first thing you should fix.

Regarding security: Not quite sure you should expose yet another servlet just for devices to figure out world time.

To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).

Red flag. You're depending on your client's unmodifiedness for security. Never do that. You simply can't trust anything happening on your user's devices. These are not your devices. They can simply hook up a debugger and modify notions of time in-memory of your process, no matter whether kept by the phone's OS or by your application.

Marcus Müller
  • 5,843
  • 2
  • 16
  • 27
  • 1
    I think you misunderstood the "To explain more.." part. In contrary, I'm already assuming mobile app users are more likely to change the device time to cheat, that's why I need the server time for counter-checking. If there's a more correct way of doing this, I'm all ears. But thank you for your input as well. – Manny Jun 08 '18 at 10:51
  • 8
    @Manny: send every command to the server. Have the server verify every action. You can assume in the client code that the server will approve and carry out consequences. If it turns out the server rejects an action (one second later e.g.,), revert on the client. This way, your server is the authority. Your server is (should be) 100% under your control and there you can trust things like system time. – marstato Jun 08 '18 at 13:58
  • "Leaking" system time should never be fixed. It is required to be revealed for proper operation of TLS and HTTP. – OrangeDog Jun 08 '18 at 18:00
  • @OrangeDog exactly what I said in my answer. – Marcus Müller Jun 08 '18 at 18:07
2

The only thing that could really expose a security risk is the high-precision timers and performance counters. These could be used to precisely time how long some cryptographic process takes on the server, and from there infer secret data.

Timing data to the milisecond or normal "tick" rate is unlikely to expose this.

pjc50
  • 2,986
  • 12
  • 17
2

Server time is not a secret. On the contrary, you are strongly encouraged to sync your time to an outside objective time source (such as an atomic clock exposed through a time server).

Not being a secret has two consequences:

  1. you don't need to protect or hide it. You can safely assume that the attacker is capable of figuring out what the current time is.
  2. it should not have a function on anything that you do wish to protect or hide. For example, you should not derive any keys or secrets from the time. Any random functions you are using should be seeded not with the current time (still a lazy default in many), but with a better seed source.
Tom
  • 10,124
  • 18
  • 51
1

Knowing the server time is of little use for an attacker. So here you should find about possible side effects.

  • is the protection for that servlet weaker (in any way) that the one of other servlets? What are the possible implications of the no need for authentication in term of DOS/DDOS attacks. It could matters if authentication was processed in other more secured servers. Is there any difference for reverse proxying?
  • what are the risks for security flaws in that servlet? Has it followed the same quality insurance controls than the other servlets? What about its maintenance cycle?
  • what about its servlet container?
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
1

I would like to answer that by pointing out, what would follow from the assumption, that exposing the server time would in fact be a risk. It would mean that system administrators would have to set random times on their systems, because any server set to the correct time would be vulnerable, since a correct or near correct server time is just to easy to guess. It would also mean extreme development effort to translate a false setting to a correct time for use in every time related application. Every single file on the system would have a wrong time stamp.

In my experience you invite much more trouble by setting wrong server times, than you can expect with the correct setting. Some examples are mentioned in other answers, but you also have to consider distributed applications or clusters, where correct time settings are usually essential. Basically any time related information you store would be flawed.

So if exposing your system time would be your biggest risk, you were in luck. But most likely there are many other concerns that you haven't paid enough attention to. See https://www.owasp.org/index.php/Main_Page for security related issues and best practices.

Javatasse
  • 111
  • 3
1

The only thing that I can think of is if you exposed the "uptime" time of the server - this could give an indication of the last installed patches; however I believe this isn't usually exposed publicly- but haven't checked so it might be worth confirming this if you are interested.

user195233
  • 21
  • 1