Hacker News Reader

Comment by londons_explore | Hacker News Reader

I wonder if you could use this 'feature' to exploit a system?

Set up a bunch of servers all over the internet with innocuous web pages. Get all of them to include in their SSL headers the exact identical timestamp of July 5th 1998.

Then get the user to connect to all those domains (eg. with a page with a bunch of iframes).

The Secure Time service will see that lots of remote servers all agree with high confidence that the date is July 5th 1998. So the system clock gets set to then.

Then you use a leaked yet expired cert (or maybe one signed with a broken algorithm) to impersonate an update server or steal valuable cookies/tokens.

Expired certs typically fall out the back of revocation systems too - so it really is just the expiry date/time that protects against their use.

View on HN

That's not just plausible but probably needs a CVE and then MS will have to act.

I can feel an experiment coming on: Mint an OpenSSL based CA and use it to generate 200 certs for randomly generated CNs. The script could write out a zone file and web server vhost configs. Pop the CA cert in a Win PC/Server trust store. "Fix" the time on the web server. AutoIT could be used to poke a browser at each vhost or an iframe monstrosity.

I have yet to see this snag myself but it sounds like an MS style screw up. Excellent engineering fucked up by one wrong assumption which leads to a huge towering monstrosity. Sheer arrogance precludes a back down, MS ploughs on and then after a year or two, a fix is silently released and the victim shaming carries on for a little while longer. Meanwhile social.ms carries on advising sfc /scannow and then reinstalling the OS.

> advising sfc /scannow and then reinstalling the OS.

I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again.

Or you could just wipe all config and reinstall everything and hope it doesn't happen again!

My work Windows server VM boxen started off life largely as 2008 R2, one was 2008. They are all now mostly 2022 and converted to EFI with secure boot - some of them put up quite a fight. Not a large setup - three DCs - one in my home attic for DR, a File n Print n NPS n CA box, a Trellix (Nee McAfee) ePO and a few more bits n pieces.

sfc /scannow can fix issues but it is not a panacea and certainly not the first thing you should reach for. It sorts some aspects of .dll hell but that is an app thing and a complex one.

As you say, get the logs out and your stethoscope. Sadly most of us don't have access to source with Windows, so we rely on intuition, 30 years of experience and some really cunning search queries. Even though Google search is largely wank, a decent and carefully curated ublocklist can winnow out the worst rubbish.

Having said that, Outlook is totally damned when it comes to logs. Outlook trace logging is an Outlook programmers debugging tool only and of absolutely no use for a sysadmin. You literally fly blind with Outlook and are best off looking at Exchange logs instead. The Outlook devs are only interested in themselves and no one else. You do get CTRL - r click on Outlook icon to unlock the connectivity checker to give you absolutely no help apart from showing how bad things are. The autodiscovery checker is handy and I have fixed configuration issues with it.

Fiddler w/ SSL decryption is the way to go to help diagnose connectivity issues with Exchange.

I use wireshark instead - https://wiki.wireshark.org/TLS

They're not comparable tools. I wouldn't use Wireshark to debug HTTP. And Fiddler simply can't intercept other protocols.

Fiddler is a MitM proxy with knobs on. I don't deny it is rather handy. I use a lot of tools.

Wireshark simply listens. If you give it the private key for a TLS exchange it is able to decrypt the stream.

Fiddler makes changes to the stream - it turns a single stream into two streams with the Fiddler in the middle, Wireshark does not - per se - it just listens but because it will be a tap in a stream it will slightly affect that stream, unless you use a switch that can mirror ports - and that's what I do.

When it is your web server (int al) then you have access to the private key and then Wireshark's minimal touch is indicated. Otherwise Fiddler or similar (Squid and others for me) is indicated instead.

(I've used Fiddler for... ever, so I'm familiar with it)

The GP likely doesn't have the private key if they're using Outlook. As if they're using Outlook it is most likely with Exchange. And if they're using Exchange, it is most likely EXO. Hence, Fiddler as the appropriate recommendation for this portion of the thread.

If you have to resort to a proxy (fiddler) then you are making changes. You do not get to sample unblemished data. Perhaps that is OK for the snag/issue in question but may not be.

Port mirroring/SPAN/RSPAN is the only way to be an observer without affecting the traffic you are inspecting. Fiddler literally does a man in the middle attack.

If you don't have access to a private key for a TLS exchange and stream, then you cannot do quite a lot of diags.

In the end, Fiddler and the like might do the job but to really get close to the wire requires full knowledge and a much lighter touch. That will be a port SPAN/mirror and Wireshark and a private key.

Again, irrelevant for the discussion at hand.

TFA seems to only mention errors where the time is set to the future, which would probably indicate that Microsoft at least thought of this. Their responses seem to indicate that they also don't think that it's a security issue, which means they likely don't know of any _explicit_ way to exploit this.

It seems to me that it could still be used to bring down a windows server right around the time that you wanted to, which is still a potentially serious security concern.

At the very least you can can screw with Kerberos which requires a default of something like five mins time sync. That's a denial of service. Keep it up for long enough and the device will fall off AD as well.

You can, just not the one you think.

If you're a big enough customer, and you contrive a way to rely on this bug, then you've hacked the Microsoft backwards compatibility commitment. They'll have to preserve the functionality in perpetuum.

Hmm, so would an Outlook server hit this if a bunch of mail servers did this?

Bitcoin? Heartbleed? SSL? Wow anon, you must have hit your head hard. C'mon, we're gonna be late for the Windows 98 launch party!

I was wondering what the newly exposed vector of exploitation was here and I think you nailed it.

Reply on news.ycombinator.com