3

Let's say we have a web server. Server startup time is the time the server process was started.

Say, the startup time was being leaked via its response headers due to the carelessness of a programmer by not getting current time while the generation of the response. The programmer is using the time variable he initialized before entering the "listening" loop, which remains the same throughout the process's lifetime, which is the time the process was started.

As we know that date field must be the date and time the response was generated which it is not in the current situation.

Could this information be useful to an attacker? How?

candh
  • 133
  • 5
  • Which header? For example if it's a cache-related header, then the fact that it has the wrong time is probably a bigger issue than the attacker knowing the server's uptime. – Mike Ounsworth Apr 10 '20 at 13:26
  • It's an edge-case, but knowing the uptime could help an attacker to confirm when they have caused a system crash. (precursor to a denial-of-service attack) – Mike Ounsworth Apr 10 '20 at 13:26
  • 3
    Another edge-case: a high uptime may reveal an unpatched kernel. – Esa Jokinen Apr 10 '20 at 13:31

3 Answers3

6

Yes, this could have value as a source of info.

If the attacker is looking to see if a DoS is working, then the server uptime can provide data about success. Alternatively, knowing that a server has been up for a very long time can indicate that resources might be starved, or it is unpatched.

It could also be used to get a sense about the infrastructure's response to load. If you are in a DevOps scenario, where you generate new servers, one could start to map out the unique servers and make some estimates about how many servers you might spawn (if a small pool) or at what load you start to spawn new servers.

Uptime could also be used to uniquely identify one server in your cluster.

The real question is: how much value is this to an attacker? That will depend on your specific environment.

I might push back on the term "sensitive info", because I do not think it is. I would rather use your other expression "useful information" because it might not have intrinsic value by itself, but can help provide secondary information that an attacker could certainly take advantage of while pursuing other goals.

schroeder
  • 123,438
  • 55
  • 284
  • 319
2

Does the user need to know the server's startup time? Because if not, you might as well keep it hidden. That is the generic answer to such a question.

The scenario you described is a careless developer that accidentally revealed it. Sure, that happens, no big deal. But when you learn of information leaks and they're easy to fix, I would choose to fix them.

There is no single, always-present vulnerability that allows an attacker to hack the server with the startup time as only information, but it does help in various scenarios.

In addition to the scenarios schroeder described, few code reviews go by without finding code that seeds the random engine with the current time upon initialization. Since initialization of the service is usually done right when the server starts, the uptime tells me roughly what time it was when the initialization was formed. Instead of searching potentially years' worth of startup times, I can narrow it down to a few seconds. And you don't want to know how many people still use their random engine for generating security tokens like session tokens, one-time login tokens, password reset tokens, etc. (insecure token generation is the real vulnerability, but the startup time might make an attack practical).

Luc
  • 31,973
  • 8
  • 71
  • 135
  • i was actually in the process of reviewing (and fixing) such code and this caught my eye and was wondering about its implications :) – candh Apr 10 '20 at 13:43
0

Besides schroeder's excellent answer, if this is an obvious error then it's an indicator to the attacker that the application was carelessly programmed. This might encourage them to invest more time looking for other vulnerabilities.

Gethin LW
  • 71
  • 3