4

On /r/programming, Daneel_Trevize and I found a very weird SSL certificate that seems to cover all of the following:

a.ssl.fastly.net, *.a.ssl.fastly.net, fast.wistia.com, purge.fastly.net, mirrors.fastly.net, *.parsecdn.com, *.fastssl.net, voxer.com, www.voxer.com, *.firebase.com, sites.yammer.com, sites.staging.yammer.com, *.skimlinks.com, *.skimresources.com, cdn.thinglink.me, *.fitbit.com, *.hosts.fastly.net, control.fastly.net, *.wikia-inc.com, *.perfectaudience.com, *.wikia.com, f.cloud.github.com, *.digitalscirocco.net, *.etsy.com, *.etsystatic.com, *.addthis.com, *.addthiscdn.com, fast.wistia.net, raw.github.com, www.userfox.com, *.assets-yammer.com, *.staging.assets-yammer.com, assets.huggies-cdn.net, orbit.shazamid.com, about.jstor.org, *.global.ssl.fastly.net, web.voxer.com, pypi.python.org, *.12wbt.com, www.holderdeord.no, secured.indn.infolinks.com, play.vidyard.com, play-staging.vidyard.com, secure.img.wfrcdn.com, secure.img.josscdn.com, *.gocardless.com, widgets.pinterest.com, *.7digital.com, *.7static.com, p.datadoghq.com, new.mulberry.com, www.safariflow.com, cdn.contentful.com, tools.fastly.net, *.huevosbuenos.com, *.goodeggs.com, *.fastly.picmonkey.com, *.cdn.whipplehill.net, *.whipplehill.net, cdn.media34.whipplehill.net, cdn.media56.whipplehill.net, cdn.media78.whipplehill.net, cdn.media910.whipplehill.net, *.modcloth.com, *.disquscdn.com, *.jstor.org, *.dreamhost.com, www.flinto.com, *.chartbeat.com, *.hipmunk.com, content.beaverbrooks.co.uk, secure.common.csnstores.com, www.joinos.com, staging-mobile-collector.newrelic.com, *.modcloth.net, *.foursquare.com, *.shazam.com, *.4sqi.net, *.metacpan.org, *.fastly.com, wikia.com, fastly.com, *.gadventures.com, www.gadventures.com.au, www.gadventures.co.uk, kredo.com, cdn-tags.brainient.com, my.billspringapp.com, rvm.io

From what I can tell, the certificate exists because DigiCert authorized the Fastly CDN to represent itself as all of the above sites. Oddly enough, the certificate was found on https://www.cnn.com/ even though CNN is not on the above list.

I can't figure out how to link directly to the certificate, but it's currently available from https://www.cnn.com. Its serial number is 06:28:1D:36:75:B4:1F:CC:B3:FF:18:FA:EC:F8:FD:DF and its SHA1 fingerprint is 98:97:03:4D:AD:78:62:48:5A:8E:24:67:ED:E8:38:21:3E:E2:4F:47.

Are we reading this correctly? If so, is it safe for these sites to share a certificate like that?

David J. Harris
  • 141
  • 4

1 Answers1

0

The reason the certificate is invalid for cnn.com is because cnn.com is not on the list, perhaps due to delays in processing CNN's signup for Fastly. Its not because certificate is revoked.

I see a huge security risk of this, and this is if the CDN operator creates a agreement with a untrusted individual.

Lets say Phisher creates a account with Fastly. He creates a phishing domain like lhglfglhggddlghd.com and does the neccessary agreements with the CA to add the domain to Fastly's certificate.

Then he uploads a github phish login page to the CDN, and it possible gets a url like lhglfglhggddlghd.com/fe9f667fe9fe6f8ecd7a93332326768

Then he sends out a phish email with: raw.github.com/fe9f667fe9fe6f8ecd7a93332326768

and people will 100% fall into the trap since both the domain and the cert will match up and even a computer savy person will think its genuine. (Note that CDNs are often using anycast, and they must optimize their servers well, so often they don't even implement any host: checking, instead they just give each resource a unique URL)

But I think that they have mitigated the issue by implementing a strong KYC before signing someone up as customer for Fastly. Eg, only well vetted, good companies that have a business-need of using Fastly as CDN will be accepted as customers.

sebastian nielsen
  • 8,964
  • 1
  • 20
  • 33
  • 1
    A DNS lookup for raw.github.com will hit Fastly's system and will be forwarded onto the raw.github.com origin, meaning that the phisher will never get to see raw.github.com's traffic. Fastly do not disclose the private key meaning that the phisher can't even install the certificate on their own server. The URL path is irrelevant because the domain name will have to match first. Therefore this is not a viable attack vector (un)fortunately. – SilverlightFox Sep 19 '16 at 08:58
  • That provided they check the Host header. What I described in the answer that they might not, eg like customer1.com/efefe7f97fef7e8f7ef9e7f9efe.htm will be the same resource as customer2.com/efefe7f97fef7e8f7ef9e7f9efe.htm , eg only the path identifies which customer it is. The attacker don't need the private key, its enough that the attacker have same server as the target. However, on CDNs you can not host any scripts, so the attacker's page would need to be a simple HTML or javascript , that forwards the information into attacker's server. The purpose of CDN is hi-performance static hosting – sebastian nielsen Sep 19 '16 at 17:01
  • @SilverlightFox Note that every fastly customer shares the same server IP, and every DNS record points to the same server IP. Else fastly would not need to do this to the certificate. And as I said, they propanbly don't implement any Host: checking either. Hard to test that without being a Fastly customer. – sebastian nielsen Sep 19 '16 at 17:04
  • It will check the domain provided in SNI, otherwise it'd end up serving the wrong content for that domain. Just think of the chaos index.html would cause otherwise. – SilverlightFox Sep 19 '16 at 17:09
  • @SilverlightFox If the server "supported" SNI it wouldn't need to serve this bizarre certificate. And index.html can be handled in many ways, for example serving a soft 404 or similiar, since the root of the CDN shouldn't be visited anyways. It might be that this CDN isn't vulnerable and uses SNI or Host checking, but I pointed out a potential vulnerability by using these type of "bizarre" certificates. – sebastian nielsen Sep 19 '16 at 22:59