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?

  • 3
    I think you just found the next target for massive compromise. – Koorosh Pasokhi Sep 18 '16 at 15:37
  • My browser just told me the certificate was invalid. Seems it has been revoked... – marstato Sep 18 '16 at 16:12
  • @marstato It's still there for me: imgur.com/a/ul6FR – David J. Harris Sep 18 '16 at 16:54
  • It is there for me as well. And Firefox rejects it as insecure as it should do. It seems that CNN have been doing this for quite a while though: news.ycombinator.com/item?id=9097361 - In fact, CNN appear to not know a lot about secure websites! cnn.com doesn't even resolve though it does without the "s" – Julian Knight Sep 18 '16 at 17:21
  • 2
    Is the existence of this certificate a potential threat for companies like Github and Etsy that are listed? – David J. Harris Sep 18 '16 at 19:53

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.

  • 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 8: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

Not the answer you're looking for? Browse other questions tagged or ask your own question.