1901352 - Insecure third-party adservice, gstatic plugins - HTTP Strict Transport Security: "Disabled"

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Jacinta]

Attachment: One of the offending plugins, this is from a fresh session on an Ubuntu Virtual Machine with no add-ons or settings applied.

There are malicious subdomains used presumably by "Google" that have and insecure HSTS policy, these subdomains are embedded into a random number/type of image, video, icon etc, but they are consistently the same ones appearing, and they always seem to be the following: adservice.google.com, gstatic.com and another one that I have been concerned about and taking interest in: ssl.gstatic.com <---- this indicates a potential hijack of the session.

This can be largely tied with the following events: https://discord.com/channels/@me/1154998105062780958/1248797390266433587 and https://digiday.com/marketing/google-delays-third-party-cookie-demise-yet-again/.

The other issue is that https://hstspreload.org/?domain=adservice.google.com you can use this for the other subdomains I have linked.

From my research the past 4 days, I have found that these subdomains, in my case the adservices.google.com will hijack one of your google accounts (when i went to the url and continued to the insecure connection, the plugin adservices.google.com completely vanished, however way more plugins appeared and they seemed to be tied to my google account.

This has been very difficult for me to trace and find as even with proper security measures, these keep bypassing most of them, the only way ive been able to make everything more secure was by verbose banning all of the components from the subdomains using adnauseam, and even then it does not completely eradicate them, and can cause websited to load very slowly and/or break.

As you can see from the screenshot, these "subdomains" are not getting properly blocked, they seem to get blocked initially but then immediately bypass it. I have been working on a temporary solution using adnauseam but I feel like this really needs to be worked on as everyones data, privacy, accounts and hardware are at risk.

Steps to find:
On your firefox browser without add-ons or tight security settings enabled inspect element on "google.com" specifically for now
You will see www.google.com and then the following malicious google subdomains: www.gstatic.com as a javascript and css inside of the google logo, then you have apis.google.com with a js script, then adservice.google.com which is a html ui, play.google.com with the type "plain", and googleads.g.doubleclick.net.

Now strict security settings will remove the following: googleads.g.doubleclick.net and apis.google.com, sometimes it can remove play.google.com but this is not consistent. Notice that ssl.gstatic.com is not there, that one only appears if you have a google account logged in.

The major problem lies in the fact that the following especially: gstatic.com and ssl.gstatic.com bypass even the hardest security measures/settings you can implement on firefox, even with adnauseam. The only way i have reduced (not eradicated) the www.gstatic.com was verbosely linking every component tied to that subdomain.

I have only managed to fully block ssl.gstatic.com specifically, but getting the entire gstatic.com to be blocked itself doesn't seem to happen, it is bypassing everything. Even my system settings on my comptuer verbosely blocking the subdomain.

Comment 1

[Jacinta]

Apologies, I accidentally copied the message link from discord instead of the actual link to this article: https://www.forbes.com/sites/zakdoffman/2024/06/03/google-chrome-warning-72-hours-to-update-or-delete-your-browser/?sh=41b41afdb050

Comment 2

[Jacinta]

Attachment: ssl.gstatic.com showing the HSTS being disabled and public key pinning enabled

I have just discovered another security issue and this can affect every sites SSL certification, a lot of these pluging have public key pinning enabled and HSTS disabled i.e. the ssl.gstatic.com, public pem chain and pem cert are in fact available to download on firefox on any website you want, from my understanding, if these plugins have HSTS disabled and public key pinning enabled, and these keys are available to download, this means there is a major security vulnerability and that any websites SSL certificate is petty much up for grabs.

I will try to notify google, but they dismissed this exact concern I gave and marked it as "working as intended".

Comment 3

[Jacinta]

I suspect this is what caused ChatGPT to crash as well:
domain sharding, Public Key Pinning (HPKP), the absence of HTTP Strict Transport Security (HSTS), and the public availability of PEM chains and certificates — several security risks emerge:

MitM Attacks: Attackers can intercept traffic between users and the server, exploiting the absence of HSTS to downgrade connections to HTTP. With access to public keys and certificates, attackers can impersonate servers or manipulate traffic without detection, potentially leading to data theft or injection of malicious content.

Certificate Impersonation: Publicly available PEM chains and certificates enable attackers to obtain valid public keys for impersonation. They can present these keys during the SSL/TLS handshake, bypassing HPKP protection and leading users to trust malicious servers as legitimate.

Exploitation of Domain Sharding: In a domain sharding setup, inconsistencies in security measures across subdomains can be exploited. Attackers may target subdomains with weaker security, exploiting vulnerabilities to compromise user data or inject malicious content.

Invalidating HPKP: The public availability of PEM chains and certificates can facilitate the extraction of valid public keys. If these keys are pinned using HPKP and later become compromised, attackers can use them to impersonate the server, potentially invalidating the protection HPKP aims to provide.

Risk of DoS Attacks: If users incorrectly pin public keys or legitimate certificates change frequently, it may lead to DoS scenarios. Attackers can exploit this by causing users to be locked out, denying access to services and disrupting operations.

Comment 4

[Jacinta]

Attachment: Public Pem chain and cert that need to be hidden/removed

This popped up on the debugger in inspect element on the pop up window for the certification of a website, I will not be clicking on those other links just in case because I do not like the looks of this.

Comment 5

[Jacinta]

Attachment: n/a

URGENT

You may want to take a look at the vendor section of this part, and look at who the author is and investigate on the name of the person that will appear in the js. It is not an mjs program so i assume mozilla firefox DID NOT write this.

Comment 6

[Jacinta]

Attachment: n/a

New discovery: there seems to be a malicious link within the html for the certification pop up, I looked it up and in fact, "http: //www.w3.org/1999/xhtml" seems to be tied to a lot of malicious activity.

It seems to be popping up in anything related to google or chrome, if you use inspect element anywhere and under inspector just search: w3.org.

Thanks!

Comment 7

[Frederik Braun [:freddy]]

Jacinta: You seem to misunderstand how the web works and how the browser works. Your screenshot for example, shows the programming source code for our browser. The fact that you can debug, inspect and work on the browser from the browser is a symptom of how Mozilla works is a proponent of open source.

The w3.org URL string that you quoted in your "possible w3 xhtml malware" is in fact just a Namespace.

The keywords do not apply here. Removing them so that our statistics are not messed up.

Comment 8

[Jacinta]

All good, thanks for letting me know! The main reason I was concerned it because the pem chain and pem certs are made available to download which from your comment, may be a feature, however because of this main issue of third party cookies with subdomains being injected into images, png, icons etc and with those subdomains having questionable security rules such as: HSTS disabled and public key pinning enabled can cause a lot of issues with those public pem keys being made available while this issue occurs.

Normally, having these keys public is not an issue, but with this vulnerability, it unfortunately it is now, and they appear for every website, including government websites.
It seems that this is a somewhat known vulnerability created by Google chrome: https://nvd.nist.gov/vuln/detail/CVE-2023-4863 the problem is, this has spread beyond the affected version of the libwebp library, it is a widespread vulnerability, and it is involving the adservice.google.com gstatic.com and many others that can be made up.

From what I have gathered the only way to mitigate this issue would be to either: block every single browser/website embedded advertisements, or find a way to force any subdomain/link/url to be https and for something to scan said source to verify that it is a certified source. To do this you would need to remove any public access to public keys (especially the downloadable pem chains and pem certs) so that people can't spoof/use these links to inject malicious software/trackers into any html, png, img, ico etc.

I really do recommend not having those public certificates available to download anymore as it is unfeasible to block advertisements from every single website, so we need a work around. I understand there is a genuine use to having them public, but the consequences outweigh the benefits in this case, and it is unfair to genuine websites that may be smaller and easier to hijack.

To add, I was having issues making my own server to test using digital ocean, especially regarding the public keys, it caused me to get locked out of my own server!

Comment 9

[Jacinta]

To add, I did just realise that lets encrypt exists, which is another problem especially since legitimate sites including chatgpt do use lets encrypt. The problem is lets encrypt being free and easy to certify sites, this can be used to mess around with this vulnerability even more, I don't know how possible it would be to create a domain/subdomain library and updates itself and filters out domains/subdomains based on certain criteria i.e. having a time buffer from when a server was made lets say 2 weeks for example, taking into consideration which certification site was used, (flagging most, small new sites that use letsencrypt for example) to not being able to inject advertisements/subdomains into images, pngs icons outside their own website/server. Thats the general idea I have, its mainly to restrict the way of how advertisements are injected by having them meet security, time and detail criteria. This is just a rough idea but I hope it can at least help with coming up with even half a solution.

Comment 10

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Hi Jacinta,

So far I haven't seen anything in this bug report that indicates a security problem.
Just because gstating has STS disabled, doesn't mean it's insecure.

Could you summarize your thinking by answering two questions:

1. What is the problem?
2. How could this be used to compromise either Firefox or a specific website?

Thanks!

Comment 11

[Jacinta]

Attachment: Compromised account, if i click on the "passkey for google.com" it will open a window by firefox and NOT google.

The problem I have seen so far is that google's subdomains tied with their advertisements are at risk of being hijacked/ are hijiacked. This is proven by the links ive supplied regarding the original vulnerability discovered september 2023 as well as another one, showing a video of a hacker reproducing such attack here: https://www.youtube.com/watch?v=NzAtZzzFoOs. In fact, the same email ive used to make this account has been compromised, because it was the account i was logged into when i accessed the adservice.google.com, one can argue "it was my decision" however this is a legitimate google service that is being hijacked, are going by the perspective of a user who does not know better and it is not a very obvious "hack" (i.e. it is a legitimate source and subdomain being used, it is not a spoof, it is actually a real google service that is hijacked).

For evidence I have my own google account that is sadly tied to the one making this report, however i have security measures in place to prevent it from spreading further, the reality is most people do not. My gmail account was in fact compromised by adservice.google.com, i am also reporting this to google, they even re-opened my case.

When i attempt to login to the google bug bounty site, it will try to use my compromised account as a passkey, it is actually in fact wanting me to create a passkey under the illusion that i already have a passkey (a window popped up asking to put in the passkey i created, but in fact i did not create a passkey), when i entered my "passkey" it actually created one, more concerning, the only response i got to that specifica action from google was them telling me that i have a new sign in to the account, even though it was 1. me signing in on a pre approved site/computer that its never notified my this befote and 2. did not confirm i made a passkey, which means google has in fact, been compromised.

Second proof, the offending adservice.google.com url, this only appears on accounts that have not visited the URL, once you have visited it, adservice.google.com completely disappears from the account attached to the links visitation, I will link images to one of my accounts that isnt affected showing the adservice.google.com ui vs my affected account showing a security warning and having a different subdomain showing and missing the adservice.google.com within the network tab.

These subdomains only appear through firefox's devtools, this may be a coincidence and you could just be showing the problem that exists in all browsers, in which case, we must try to intervene and prevent it from getting worse, think of it as catching it early. It is probably something that is starting in it's infancy stage, at the moment its just the subdomains being hijacked and can currently only hijack through direct means, but as you know, this can in fact escalate into more nefarious means (hijacking main domains and URLS).

How do you hijack domains and subdomains? PKI's, keys to the server, say these subdomains have public key pinning enabled and HSTS enforcement disabled along with the confirmation that at the very least adservice.google.com is in fact a http site and not https (it even deceives you by showing it is https in the GET request description) but because it is not enforced, it goes to http first, the traffic gets intercepted between me and google, oh dear they have access to my account, because you have the public keys there to download, coupled with the insecure settings of HSTS not being enforced and public key pinning --> subdomains hijacked through ssl injection using real pem keys, this is not even spoofing its using real subdomains.

How could this happen? with having HSTS disabled AND public key pinning enabled especially when firefox shows the downloadable pem cert and pem chain keys that can be used along with public key pinning to access these legitimate subdomains. The issue lies on both Google and firefox, for google's end they need to enable HSTS along with fixing their public keys, for firefox you need to stop giving general public access to public keys anymore, this is no longer the environment where it is safe to do so.

I will attach the other screenshots after this one.

Comment 12

[Jacinta]

Attachment: Affected Google Account, google adservice subdomain does not appear in network for this one

This is the affected account adservice.google.com does not appear for this one, and it has security warnings and breach attempts (i.e. the passkey option that appeared).

Comment 13

[Jacinta]

Attachment: This is the unaffected account.

Pay close attention to the adservice.google.com ui i am showing here, notice the get description. To add the way to block this was arduous, I had to put it as a verbose strict ban on Adnauseam strict block list.

The problem is that this is a legitimate google service, it is tricking people into accessing it by pretending to have https (which it probably has a https site but it is not being used for this) but it gets bypassed due to no HSTS strict policy enabled.

Once again, just because it isnt affecting most users now, doesnt meant it wont in the future, the fact that its doing this now, is a cause for concern and if we ignore it, the problem will only escalate and spread more.

Comment 14

[Jacinta]

If you want to test and replicate, create at least 2 dummy google accounts, visit the adservice.google.com url using firefox (exactly as is, just type in that), for one account and leave the other account alone (don't visit any of their subdomain urls) and notice the difference between both accounts.

Comment 15

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Just because HSTS is not enabled, doesn't mean the request is using HTTP.

You can capture a wireshark dump to make sure.

The problem is that this is a legitimate google service, it is tricking people into accessing it by pretending to have https (which it probably has a https site but it is not being used for this) but it gets bypassed due to no HSTS strict policy enabled.

Not sure what you mean by pretending. It seem to have a HTTPS scheme, does it not?

In any case, this doesn't appear to be a valid bug.
If you can point to a HTTPS request incorrectly being made with HTTP instead, we can reopen the bug.

Thanks!

Comment 16

[Jacinta]

If you type in adservice.google.com on a fresh browser with without security settings to force it to use https (I had to create a setting within Firefox and put the specific url to force it to redirect to https), but if you don't and you just visit the url ad service.google.com it will not redirect to https, you will in fact visit the http site.

And that is where accounts get compromised, like I said before you can test this with dummy Gmail accounts and get one to visit the url and inspect the changes.

Comment 17

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

But how will that be a problem?

Assume you have full control of my home network, and I go to gmail.com. gmail.com might load things from https://adservice.google.com - but note the HTTPS scheme. If the website doesn't use http, then there's nothing an attacker can do.
Is there something I'm missing?

Comment 18

[Jacinta]

Not https://adservice.google.com just typing in this as is-> adservice.google.com without http or https.

It will not redirect to https, you will visit the http "site" once I have the time I'll do some more testing using my VM, I'll record it as well if it helps.

Comment 19

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Yes, but why would I type it without the https part? why would I type it at all.
If it's not being used insecurely by gmail.com then it's not affecting users.

Comment 20

[Jacinta]

Attachment: just from typing in "adservice.google.com"

Can you give me a technical explanation as to why Firefox is suggesting to me to visit an insecure http site?

Comment 21

[Jacinta]

No typical user types out the https part, most users just type out a website name like google.com, because it is generally assumed that most websites redirect to https as they should, especially something that is well known like google or any domain/subdomain of google should always redirect to a https site.

The responsibility is on the browser and company not of the user when it comes to web safety, especially managing sites to redirect to https.

Users do not deserve to have their Google/Gmail accounts hacked because of laziness.

Comment 22

[Jacinta]

Here is also an article from stack overflow explaining mechanisms of public key pinning and why it is unsafe to have public pem keys with other information like SHA fingerprints being made available to the public:
https://stackoverflow.com/questions/75131536/best-practice-to-ssl-pinning-in-flutter-fetch-the-certificate-every-time-or-st

Need I remind anyone about the CIA triad when it comes to infosec? particularly confidentiality and integrity.

I currently have university exams this and next week, but if need be during the break in between semesters, I am happy to do more intensive research/help for this as this is the best I can do with my current time constraints.

The fix I'm asking to be implemented is to at the very least, remove the ability for public pem certs and chains to be publicly downloaded as this is making every domain and subdomain compromised and/or force enable HSTS policy on all domains and subdomains especially if they're using public key pinning.

I'm not just asking firefox, I am asking google to do the same and hold them accountable for their own subdomains, we tend to forget what it is like being a user with no tech knowledge and it is very easy to type in something like adservice.google.com by mistake as well as it is a legitimate service and someone who's a startup may type that in and get hacked for no good reason.

And just remember it's not just that subdomain affected, it's most of Google's and probably most of everyone else's subdomains that don't have HSTS enabled at the very minimum.

Comment 23

[Jacinta]

https://security.stackexchange.com/questions/189627/bypassing-hsts-and-public-key-pinning-with-lookalike-characters a comment on this: "A redirect is done by sending a HTTP response with code 302 or similar and the new location inside the Location header of the HTTP response. If a website is on the HSTS preload list the request for the original domain would already be done with HTTPS. This means that a successful TLS handshake need to be done before the HTTP request inside the TLS connection could be send and the HTTP response with the redirect could be received.

This means that in order to send the redirect the attacker would need to intercept the initial TLS connection successfully (i.e. MITM attack) by using a trusted certificate and its private key for the domain the user tries to visit. Attempts to do this with some self-signed certificate or certificate not matching the hostname and hope that the user will just skip any certificate warnings will not work since with HSTS no option will be offered to skip certificate problems.

But, if the attacker has already access to such a trusted certificate (maybe by hacking a CA) then there is no need to issue a redirect in the first place, i.e. the attacker could just continue to serve a different HTTP response (with fake content) for the original domain the same as you propose with the redirect."

Is exactly what I am trying to communicate, because these subdomains are not on the hsts preload lists (which I have proven before using the hsts preload check site).

And I have shown that adservice.google.com does not redirect to https because of those exact insecure settings (not having https strict transfer enabled thus not being on the hsts pre load list).

So far I have shown: evidence of at least one or more google subdomains being misused and not redirecting as expected, evidence of security measures not implemented wherr they should (not having strict https transfer enabled combined with public key pinning while showing the public pem chains and certs for every domain and subdomain available to download), multiple references and sources to such problems and related vulnerabilities that can contribute to this current one, showing my own google account that was temporarily hijacked with attempts to make it into a passkey by trying to trick me into thinking I made a passkey, but it's asking me to make one so that someone else (MiTM attack) can use my google account/leak my personal data.

I do not understand why this isnt being treated as a security issue/dismissed.

Comment 24

[Jacinta]

Attachment: The suspected hacker

This is the suspected hacker who hijacked my account, I also looked up this "mattfox.net" and it is extremely suspicious.

I will explain more in the next image

Comment 25

[Jacinta]

Attachment: suspected hacker "site"

This is what comes up when you search the site the "email" is attached to.

Comment 26

[Jacinta]

Attachment: Pay attention to this one

A comparison I found was "/" there was a malicious file I found during my search that was just named "/" this appears when you visit adservice.google.com and that's where the / file appears, I will link that image as well after this.

probably a reason for that, and it may be tied to this "mattfox.net", if this is yet another Firefox "feature" then I question Firefox's integrity and will file a different complaint as I did not give permission to Firefox to hack into my google accounts in such a manner.

Comment 27

[Jacinta]

Attachment: "/" file in adservice subdomain

This looks exactly like what appears on "mattfox.net", it is no coincidence that this account has a site showing "/" and is blocked from my gmail/google account that was affected (visited the insecure adservice link) without me even physically blocking it (it seemed to be blocked automatically).

If this is not proof of a security breach/attack I don't know what is. I will also be sending this to google because they need to be aware that someone is hacking into people's google/gmail accounts via using a legitimate subdomain thanks to browsers and google being blaze' with their HTTPS and public key policies.

Comment 28

[Jacinta]

Attachment: The ISAKMP for the offending website "mattfox . net"

This I have limited knowledge, but it looks like it may have to do with key scanning/grabbing.
They also seem to be using QUIC a new type of TLS that surpasses TLSv.2.

Comment 29

[Jacinta]

Comment on attachment 9406534 [details]
The suspected hacker

https://who.is/whois/mattfox.net

Comment 30

[Jacinta]

Attachment: dont know what a "gmail.clmo" is?

i was on my VM made a dummy account and then retested on my current "infected" account and this popped up when i tried to login to the google bug hunter using the google sign in button.

Comment 31

[Jacinta]

Attachment: "Issued by Google Trust Services LLC"

This is on that mattfox.net site, it is showing that the certificate was issued by Google Trust Services and i confirmed by viewing the certificate of the https site, however if you use whois it comes up with namecheap being the website's registrar.

Also the same "/" appears in the exact same fashion the exact same format (html) as it did on the insecure adservice.google.com.