SOLVED: Signature Forgery via Domain Fronting

[DavidBuchanan314]

I have forged a signature for www.google.com. The PageSigner extension imports, validates, and displays it like so:

The signature file is attached:

www.google.com.pgsg(1).zip

[themighty1]

Hi, @DavidBuchanan314 , thanks for your research.
Could you please describe what you did to accomplish that?

[DavidBuchanan314]

The fundamental flaw in PageSigner is that the request headers are not auditable. I'm not sure if there's a way to fix this.

There are a million ways to be sneaky with request headers, to make the response contain "unexpected" content.

In this specific instance, I initiated a valid SSL connection to www.google.com, and then made an HTTP request to the host [my-personal-webserver].translate.goog (a.k.a Domain Fronting), which in turn proxies the request to my personal webserver.

So technically, PageSigner is correct in saying that "this page was received from www.google.com", but this is misleading.

The majority(?) of websites are hosted behind a CDN that allows domain fronting, in some capacity.

A given website is vulnerable if, for each domain that can be reached via fronting, there exists a domain that hosts/reflects user-generated content.

It is impossible to enumerate all the frontable subdomains for a given host, and therefore it is impossible to prove whether any PageSigner signature is valid.

This PoC is obviously google-specific, but a similar technique is definitely going to be possible on other sites - and the problem is, we can't know which.

[themighty1]

Bravo! Great research!

The request headers WILL be auditable in the new version we are working on. But for now, I'm gonna pin this issue and also post a warning on chrome webstore.

Thank you.

[DavidBuchanan314]

Thanks, I look forward to seeing the new version.

[Jonas-Metzger]

Very glad you spotted this!

I'm developing a tool whose security depends on verifying .pgsg's of tweets and of files like this one hosted on oco2.gesdisc.eosdis.nasa.gov. Do you expect similar attacks to be possible on these domains as well?

Haven't heard of domain fronting before, but domain hiding sounds like a similar more general hack - would this break pagesigner even more?

[themighty1]

@Jonas-Metzger , the fundamental issue here is that it is impossible to know whether or not the attack is possible for any domain.
The mere fact that it is impossible so say with assurance that the attack was NOT possible, cast doubts on any proof generated by PageSigner.

Of course, the verifier can exercise his discretion and say "it is unlikely that a banking website allows domain fronting/hiding, so I will accept the proof as genuine".

Due to this attack, PageSigner can only be used on a case-by-case basis where the verifier understands the risks they are taking in accepting the proof.

[rjaus]

Domain hiding is no longer possible on Cloudflare: https://github.com/SixGenInc/Noctilucent#update-2020-08-10---it-was-fun-while-it-lasted

Additionally, domain fronting is no longer possible on AWS or Google Cloud. And as @themighty1 suggested, it would be unlikely that all the requirements would be fulfilled to enable this attack within the infrastructure of a target such as bank or financial institution.

Tho the real solution is auditable request headers, which is very cool. Where are you at? Happy to lend a hand if you need more people on the task. Is there a WIP branch?

[DavidBuchanan314]

Fronting still works for Fastly sites, which is a pretty big chunk of the internet. (Although admittedly, I'm not aware of any banks using fastly)

[themighty1]

@rjaus, hi, thanks. Also @DavidBuchanan314 and @Jonas-Metzger (since you are also actively involved). The code is slowly but surely nearing completion. The best help at this point would be theoretical one.
Once request authentication is completed, Pagesigner will check that the HTTP request's Host: header matches the domain name from the TLS certificates.

Do you have any ideas if there are other HTTP headers which the auditee can add to his request in order to pull off an attack?

[rjaus]

I don't know enough about it TBH, I'd only be going off the article linked above.

How's the new version going? Keen to test it out once you're ready for release. If you need a beta tester, let me know.

[themighty1]

@rjaus , ok, thanks, I'll let you know when it is ready to be tested.

[rjaus]

Hey @themighty1 I noticed this repo went up. Is this related in anyway to the new version you're working on? I noticed it discusses attesting the entire req/res cycle. Tho it appears limited to publicly accessible url.

[themighty1]

Hey @rjaus , PageSigner will rely on URLFetcher's attestation. Currently, the verifier of PageSigner's proof verifies whether the notary server was a properly sandboxed instance by making AWS API calls. With URLFetcher, there is no more need for the verifier to go online to make the API calls, but the verifier can trust the URLFecther attestation.

[themighty1]

Hey @rjaus , the updated version is ready for testing here https://github.com/tlsnotary/pagesigner/tree/v3wip
Any comments are welcome in the Discussion section https://github.com/tlsnotary/pagesigner/discussions

[DavidBuchanan314]

Could you summarize what has changed, design-wise, in the v3 version? Also, do you have any flow diagrams, similar to the one on the tlsnotary homepage?

[themighty1]

I'm gonna need some time to make a write-up about how it works. I'll post here when it is ready.

[themighty1]

The new TLSNotary protocol description is available here https://tlsnotary.org/how_it_works
This is a full protocol redesign. The diagram is not yet available. PageSigner v3 is based on this new protocol.

[themighty1]

PageSigner v3 has been released which fixes this issue.

[ctrlcctrlv]

thanks a lot for patching this

https://twitter.com/fr_brennan/status/1545950720670793729