TL;DR: Google speaks of a "tremendous responsibility" that CA's have (see the toot I'm replying to).

However, Google is *also* a CA (Google Trust Services, aka GTS) and they hand out huge numbers of server certificates to cybercriminals without blinking an eye. I'll show 13 examples.

————

Note: as I explained in https://infosec.exchange/@ErikvanStraten/112688092149571552 and the toot I'm replying to: https server certificates do NEVER warrant safe websites.

Their purpose is, for a visitor, to know who is RESPONSIBLE for a website. It's like in offline life: if a building in the center of a city reads "McDonalds", this does not mean that the owner is trustworthy. Typically trustworthyness is estimated based on a known reputation.

Without knowing -with reasonable certainty- who owns a website, it is hard if not impossible to distinguish between fake and authentic websites.

————

Yesterday Lawrence Abrams of Bleeping Computer wrote (https://www.bleepingcomputer.com/news/security/fake-it-support-sites-push-malicious-powershell-scripts-as-windows-fixes/ - source: [3]) about a recent phishing campaign, described in detail by eSentire in [4], mentioning 3 domain names in their IoC [5].

Bleeping Computer found 3 more related domain names, so there are 6 in total. Each of them uses a GTS certificate - none of them have been revoked. They all hide behind CloudFlare; blocking such IP-addresses may lead to false positives (blocking non-malicious sites).

I just checked all 6 of them;

1) pchelprwizzards[.]com
GTS cert: https://crt.sh/?id=13099204882&opt=ocsp
Status from my IP: NXDOMAIN (unreachable)

2) pchelprwizardsguide[.]com
GTS cert: https://crt.sh/?id=13245766407&opt=ocsp
Status from my IP: NXDOMAIN

3) answermedia[.]site
GTS cert: https://crt.sh/?id=13070702221&opt=ocsp
Status from my IP: Cloudflare (using mentioned GTS cert): "Sorry, you have been blocked"

4) pchelprwizardpro[.]com
GTS cert: https://crt.sh/?id=13198762005&opt=ocsp
Status from my IP: live, shows logo "FASTPANEL"

5) pchelperwizard[.]com
Two GTS certs: https://crt.sh/?id=12825854215&opt=ocsp and https://crt.sh/?id=13468820285&opt=ocsp
Status from my IP: live, redirects to "https:⁄⁄fixedguides[.]com/guide/?" (see below)

6) fixedguides[.]com
GTS cert: https://crt.sh/?id=13513930535&opt=ocsp
Status from my IP: NXDOMAIN

The threat of these particular website domain names seems minimal now, but action may have been only taken by Cloudflare (and possibly others) because of media attention.

Here are another 6 malicious sites (USPS package delivery scams), with 4/6 still live:

7) us-usps-ny[.]com
GTS cert: https://crt.sh/?id=13513320124
Status from my IP: Cloudflare reports (using said certificate) that their connection to the actual website timed out.

8) us-usps-np[.]top
GTS cert: https://crt.sh/?id=13524360695
Status from my IP: USPS phishing page is live.

9) us-usps-nt[.]top
GTS cert: https://crt.sh/?id=13513378112
Status from my IP: Chrome says: "The connection to us-usps-nt.top is not secure". When trying "http:⁄⁄us-usps-nt[.]top/", Cloudflare reports that their connection to the actual website timed out.

10) us-usps-nu[.]top
GTS cert: https://crt.sh/?id=13513535700
Status from my IP: USPS phishing page is live.

11) us-usps-zx[.]top
GTS cert: https://crt.sh/?id=13524360361
Status from my IP: USPS phishing page is live.

12) us-usps-zz[.]top
GTS cert: https://crt.sh/?id=13524416080
Status from my IP: USPS phishing page is live.

Interestingly, it appears that if Cloudflare determines that a site is suspicious, they may move such a site from their regular IP-ranges to 188.114.96.0 (mirrored by 188.114.97.0). This can be seen under "Passive DNS Replication" in https://www.virustotal.com/gui/domain/us-usps-ny.com/relations (it applies to all 6 USPS phishing sites mentioned above).

Unsurprisingly one can find lots of malicious sites under "Passive DNS Replication" in https://www.virustotal.com/gui/ip-address/188.114.96.0/relations (with many new sites getting scanned *and* added every day, 24x7).

Here's another site with a GTS certificate, with a VT scrore of 23/93:

13) invoice-system.pages[.]dev
It's GTS cert can be seen in https://www.virustotal.com/gui/domain/invoice-system.pages.dev/details.
Status from my IP: Cloudflare warns:
"This website has been reported for potential phishing." If I tap "Ignore and proceed", a Microsoft phishing page is shown (see the screenshots below) - no thanks to Google and Cloudflare.

What a mess.

[3] https://infosec.exchange/@deepthoughts10/112706318327847849
[4] https://www.esentire.com/blog/fake-it-support-website-leading-to-vidar-infection
[5] https://github.com/esThreatIntelligence/iocs/blob/main/FakeIT_KB_Vidar/FakeIT_KB_Vidar-6-7-2024.txt

Cc: @deepthoughts10 @agl @Tarah @ScottHelme @dangoodin @BleepingComputer @lawrenceabrams

@weddige : sure!

If you go to the centre of a city and see a building that obviously is a bank, then you don't need a "certificate" to be reasonably sure that it's a bank. You don't even have to know the exact address (that one could write as "nr.street.city.country").

The building's geographical location and neighbourhood confirm the identity of what's written on the outside wall, because, in practice, the chance of it being fake is negligible.

OTOH, if you were on holiday in some poor country, and for some reason you end up in a not-so-nice area, and near a scrapyard there's a building that *looks* like a bank; would you trust it?

On the internet you often have no idea where a server is located and how trustworthy anyone with access to it is. The only thing you may know is its address (domain name) - without anyone reliably telling you who is currently "living at that address" (who is responsible for a webserver).

https server certificates USED to do that - more or less.

IMO the following things are needed:

1) Browser users must be able to determine whether information, uniquely identifying the *owner* of a website, is available to them (apart from the address, i.e. the domain name). I.e. what type (DV or better) of certificate is being used;

2) If better than DV, an indication of the *reliability* of the way in which the owner's identity was verified, must be shown. The overall reliability of a CSP (certificate service provider), as determined by the CAB-forum, may affect the reliability score of each certificate signed by that CSP (not as binary as it is/was, i.e. fully distrusting misbehaving CSP's);

3) Users must be educated, at least via functionality built into browsers, that trust depends on answers to the following questions:
a) How sure are you that a website owner is who they say they are (this info should be provided by the browser);
b) What is the reputation of the owner (this knowledge is also required in real life, but IMO makes cert issuance too complicated; external alternative certifications such as ISO 9001 and 27001 *may* help);
c) How trustworthy is the device and software that you use to browse;
d) What is *your* risk (financial or otherwise) if anything goes wong because of some transaction.

So I'm not saying that DV certificates should disappear, but that users should be able to distinguish between knowing just an address versus a website owner identity that was verified with high reliability, as well as a spectrum between those extremes.

W.r.t. the killing of EV-certificates (by Google) based on one incident ("Stripe, Inc") and the assumption that "nobody checks certificates": that incident was caused by the fact that the visible identifying EV information was not worldwide unique (not even between US states) - which is a design error.

Also, certificates contain way too much non-interesting information for end users (serial numbers, SAN's, public key etcetera). This must be fixed.

Furthermore, wildcard certs and certs with lots if seemingly unrelated SAN's (*) in them should have lower reliability scores. If anyway possible, shared hosting should also decrease the reliability score.

(*) Today I ran into one with 582 SAN's: https://crt.sh/?id=7293782180 - part of them are IDN's containing "characters" such as , , etcetera. This cert seems to have been used by a domain name parker, but the one with , appears to be live now (with a certificate only for itself) : https://www.virustotal.com/gui/domain/vdiarybook-com.xn--3t8h.to/summary (see "Siblings").

If end users are not provided with the minimum information required to reasonably assess their risks, or if most or all of them just don't (know how to) do that, then the internet is useless for medium to high-risk transactions. There will be too many victims of fraud (safety-nets are disappearing in NL) and too many company networks will get breached.

#X.509 #x509certificates #Certificates #Certificate #DV #OV #EV #QWAC #CSP #CABforum #Browser #Browsers #Trust #Reliability #Authentication #Impersonation #CA