A critical Windows component expires in 25 hours | Hacker News Reader

A critical Windows component expires in 25 hours

hexatomium.github.io

276 pointssvenfaw42 comments

So the Untrusted CTL has an expiration of 25 hours. Your screenshot says "Did you know? ... the Untrusted CTL is updated once per day". Doesn't that explain it?

I was asking myself the same question.

In the screenshot, it says that CTL was last modified in March. Judging by the date, I'd guess it has an expiration of 6 months after it is issued. So, it's been nearly 6 months since the daily updates stopped occurring.

Is that the time it was last modified or the time it was last signed?

The last high-profile mis-issued cert was last week, and didn't even escape the control of people who were entrusted with the CA private key. So MS might not even be manually revoking it. Before that, the last blog post on googleonlinesecurity.blogspot.com about a mis-issued certificate was ... March 23.

I would guess that it's re-signed daily, but only changes when there's an actual change to be made.

Following up: if anyone wants to poke around at the file, the download URL is http://ctldl.windowsupdate.com/msdownload/update/v3/static/t... , a CAB archive that contains a single file disallowedcert.stl. That file itself is DER-formatted ASN.1, evidently a PKCS7-signed "Certificate Trust List" (1.3.6.1.4.1.311.10.1). `openssl asn1parse -inform der -in disallowedcert.stl` reads it just fine.

There's a reference to the date 150923203626Z (2015-09-23 20:36:26 UTC) somewhere in there, but I'm having trouble figuring out what it applies to.

Actually it's the expiration timestamp of signing certificate "Microsoft Certificate Trust List Publisher". I intended to add this info in the blog post but can't do it right now.

Is anyone else concerned that the disallowed certs list is downloaded over plaintext HTTP?

It appears to be a signed message, and for these sorts of things, I'm more of a fan of signed data (and the transport being unimportant) than a signed transport and unsigned data: there's a lot less attack surface on both ends.

apt, yum, PGP, etc. work the same way. There remains a decent argument for a secure transport anyway for privacy / avoiding side channels, or a general desire for HTTP delenda est, but it's nowhere near as strong an argument, HTTPS only provides marginal benefit to the side channels (Tor to a hidden service is much more effective), and other engineering concerns can legitimately override these concerns.

I think that may be purposeful. If your local certificate management system is on the fritz, you don't want that rejecting updates to the core cert lists. Probably better to fall back on some other cryptological system on the files themselves, since the content is not private, it's just the authenticity you care about.

I don't think it's really a big deal. Since the list is signed, an active attacker would only be able to replay an old version of the list... but it's hard to see how that would be worse than just blocking the request entirely.

An older version of the list might be missing a recently compromised certificate, though. Of course, you need to both MITM someone and compromise an important cert, so that's not the sort of thing just anybody could pull off.

Right, but assuming Windows isn't dumb enough to accept a remotely downloaded version that's older than the one it already has locally, the effect would be the same as if the attacker just prevented you from receiving new updates. And HTTPS wouldn't make it any harder for them to do that.

Additionally, old versions will expire, so there's a limit to how far back you can keep someone, even if you continuously intercept the update attempts.

What happens if all versions someone has are expired?

> the effect would be the same as if the attacker just prevented you from receiving new updates.

True, but it might be slightly less visible because you'd get an "update" instead of a failure. Also, I wonder if anyone has actually tested that scenario?

I'd like to believe that's true and that should be true, but I'd also have to actually test it before trusting it to be true.

Doesn't matter if it's signed.

I noticed that, too, but then I saw that the last check was Sep 22nd. He might have meant that a check is made for the most recent list once per day.

> I can't accurately foresee what is going to happen in 25 hours

Set the clock forward and see?

I believe this is less about what one individual computer would do and more about what could happen to the millions of Windows users facing this problem in 25 hours.

Finding out what happens to one computer seems like a better start to informed speculation about millions of other computers than not finding out. Sure, it's no guarantee they're all the same, but we can more reasonably discuss whether the observed effects are plausibly widespread after observation...

I think the sentence was meant to imply MSFT might see this issue before the clock hits doomsday.

Microsoft has some experience with expired certificates [1].

[1] https://azure.microsoft.com/en-us/blog/windows-azure-service...

More technically: hook the time functions for that application only.

Why does the app say you're at risk if the certificate is still valid, and why does it say that the last check for one of the lists in the future? Feels like the usual crypto-fearmongering to me.

It just updated tonight, it seems

Edit:

ListIdentifier = "DisallowedCert_AutoUpdate_1"

SequenceNumber = 01d0f584a9ad12f7

ThisUpdate = "23.09.2015 00:18"

NextUpdate = LEER

SubjectAlgorithm = 1.3.6.1.4.1.311.10.11.15, "disallowedHash"

SignerExpiration = "14.08.2016 19:13", "326,3 Days"

CTLEntries = 57

Das System kann die angegebene Datei nicht finden. 0x80070002 (WIN32: 2 ERROR_FI LE_NOT_FOUND) -- http://ctldl.windowsupdate.com/msdownload/update/v3/static/t... tedr/en/disallowedcertstl.sst

MissingCerts = 57

yesterday it told me that it wasn't updated since 180 days.

Can you post a screenshot? "Updated" can mean different things in this context. For the issue to be resolved, Microsoft also has to update the signing certificate itself, which it hasn't done for the last 15 months.

Edit: Confirmed! Blog post updated.

I'm trying to get my head around what a CTL is anyway. I might be tired and a bit hungry (never helps my cognitive processes) but I was struggling to understand the Microsoft article I found here:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

Just a note: Your GMT date is wrong - should be 22, not 23. Apart from that, sounds scary.

I'm not sure it explains the last auto update check time for the trusted CTL ;)

Can anyone else confirm this?

well, running the command gives this:

    Microsoft Windows [Version 10.0.10240]
    (c) 2015 Microsoft Corporation. All rights reserved.
    
    C:\WINDOWS\system32>certutil -verifyCTL disallowed
    LastSyncTime = "22/09/2015 13:53"
    [DisallowedCTL]
    ListIdentifier = "DisallowedCert_AutoUpdate_1"
    SequenceNumber = 01d065c00c3f1258
    ThisUpdate = "24/03/2015 00:21"
    NextUpdate = EMPTY
    SubjectAlgorithm = 1.3.6.1.4.1.311.10.11.15, "disallowedHash"
    SignerExpiration = "23/09/2015 21:36", "1.0 Days"
    WARNING = "SignerExpiration: Less than 180 Days"
    CTLEntries = 57
    The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND) -- http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcert.sst
    MissingCerts = 57

but I know nothing about the implications. It also looks like the file has the possibility to be downloaded from msft on the fly?

I have no idea of potential impact, but the command run on an up-to-date Windows 10 system reports:

    > certutil -verifyCTL disallowed
    LastSyncTime = "9/22/2015 9:33 AM"
    [DisallowedCTL]
    ListIdentifier = "DisallowedCert_AutoUpdate_1"
    SequenceNumber = 01d065c00c3f1258
    ThisUpdate = "3/23/2015 6:21 PM"
    NextUpdate = EMPTY
    SubjectAlgorithm = 1.3.6.1.4.1.311.10.11.15, "disallowedHash"
    SignerExpiration = "9/23/2015 3:36 PM", "1.0 Days"
    WARNING = "SignerExpiration: Less than 180 Days"
    CTLEntries = 57
    The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND) -- http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcert.sst
    MissingCerts = 57

Can confirm, getting similar output on Windows 10.0.10240. Although url is working works in chrome. Could this be a bug in the certutil updater?

        (endpoint) C:\Users\orf
	λ certutil -verifyCTL disallowed | head
	LastSyncTime = "22/09/2015 18:24"
	[DisallowedCTL]
	ListIdentifier = "DisallowedCert_AutoUpdate_1"
	SequenceNumber = 01d065c00c3f1258
	ThisUpdate = "24/03/2015 00:21"
	NextUpdate = EMPTY
	SubjectAlgorithm = 1.3.6.1.4.1.311.10.11.15, "disallowedHash"
	SignerExpiration = "23/09/2015 21:36", "1.0 Days"
	WARNING = "SignerExpiration: Less than 180 Days"
	CTLEntries = 57

Then a whole load of entries like:

        [f69d22ae1ed615b1b9e390e310bbbb31]
	CertId = 1.3.6.1.4.1.311.10.11.0
	Subject = "MISSING_CERTIFICATE"

As of a short while ago (times are US/Eastern):

  C:\Users\gapinski>certutil -verifyCTL disallowed|more
  LastSyncTime = "9/23/2015 3:33 AM"
  [DisallowedCTL]
  ListIdentifier = "DisallowedCert_AutoUpdate_1"
  SequenceNumber = 01d0f584a9ad12f7
  ThisUpdate = "9/22/2015 6:18 PM"
  NextUpdate = EMPTY
  SubjectAlgorithm = 1.3.6.1.4.1.311.10.11.15, "disallowedHash"
  SignerExpiration = "8/14/2016 1:13 PM", "326.4 Days"
  CTLEntries = 57
…

Last autoupdate check on 2015-09-26 ... IN THE FUTURE? THE LAST ONE?

Note to self: Do not take screenshots from the future.

could you open lottery numbers page in the background and post another screenshot, just for clarity?

When is Microsoft going to adopt Certificate Transparency anyway? Google, Mozilla and Apple all support it already.

> Mozilla and Apple all support it already.

Do you have a source? As far as I know that is not accurate.

This is unrelated to CT; this would still be needed to kill any maliciously issued certificates.

Apple has App Transport Security which allows you to require CT. I think the OP meant Google, as the patch[1] for CT is still pending in Firefox.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=944175

Right. What I meant was actually that they either support it or are in the process of supporting it. But I haven't heard anything about it from Microsoft.

Reply on news.ycombinator.com