I am working on the security analysis of a system and some of it's security measurements are based on the Environment.TickCount
property exposed by the .NET Framework. As stated by Microsoft:
Because the value of the TickCount property value is a 32-bit signed integer, if the system runs continuously, TickCount will increment from zero to Int32.MaxValue for approximately 24.9 days, then jump to Int32.MinValue, which is a negative number, then increment back to zero during the next 24.9 days. You can work around this issue by calling the Windows GetTickCount function, which resets to zero after approximately 49.7 days, or by calling the GetTickCount64 function.
So when knowning the estimated uptime of the server one could roughly estimate the value of Environment.TickCount
too. This would weaken the security of the system significantly. A brute-force attack on the complete range of possible TickCount values would take an estimated 2 and a half days with my current implementation (which is not very long either), a ballpark value to pick a starting point in the value-space would make this search much more efficient.
The server is running fully patched Windows Server 2012 R2 and the only exposed service would be IIS serving some ASP.NET pages (maybe IIS leaks some of this information).