Full Disclosure mailing list archives

Dear All,

We have recently experienced "an outage" / unavailability of our website
[1] due to Google suspending our Firebase project (the root for our website
hosting).

On Oct 16, 2025 (23:20 PM CET) we received a message [2] from Google Cloud
Compliance, which indicated our hosting project was potentially violating
Google Policies / TOS due to "hosting, distributing, or facilitating the
distribution of malware, unwanted software, or viruses". At the same time
(Oct 16, 2025 23:20 PM CET) 404 HTTP errors started to be visible in web
server logs [3].

In its message, Google pointed to the Java SE Proof of Concept code for a
security issue from 2016 [4] as the base for the claim (and suspension).

This was not the first time this or similar codes (in most cases 10+ years
old) has been pointed out by Google (most likely in an automatic fashion)
as potentially violating Google Cloud Policies / TOS.

We already experienced similar warnings and / or suspensions in the past:
1) Aug 7, 2024 (suspension for ~1 day)
2) Feb 19, 2025 (suspension for ~1 day)
3) Jun 11, 2025 (appeal filed, no supension)
4) Jul 17, 2025 (appeal filed, no supension)
5) Aug 21, 2025 (appeal filed, no supension)

Case 1) is more interesting as Google pointed out the apparent violation
in relation to POC codes for our research affecting Google's own App Engine
and 10+ years old POC codes [5].

The suspension which took place this time was done in relation to Java SE
POC that has been found OK by Google more than a year ago [6] (we needed to
appeal with respect to it, on Aug 08, 2024 Google informed us that target
code comply with company's policies and reinstantiated our project).

We don't know why Google complained (and supended) our website due to this
code again.

The recent suspension took longer than usual to resolve. We filed several
appeals in order to provide Google with arguments indicating target code is
fine, we also reached out to Google Support. All without success.

After 4+ days of waiting for Google resolution, we decided to handle things
on our own.

There is an obvious way to bypass Google suspension of a Firebase project
potentially "hosting, distributing, or facilitating the distribution of
malware, unwanted software, or viruses".

One can simply create a new Firebase hosting project:

```
/www $ mkdir semirror
/www $ mkdir semirror/public
/www $ cd semirror

/www/semirror $ firebase init

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

  /www/semirror
...
✔  Firebase initialization complete!
```

copy the original files to it:

```
/www/semirror $ cp -R ../se/public .
```

this includes the "offending" files (apparently not compliant with Google
TOS / policies and leading to suspension):

```
/www/semirror $ ls -la public/materials/se-2012-01-69.2.zip
-rw-r--r--    1 nobody   test         25446 Oct 21 07:30
public/materials/se-2012-01-69.2.zip
/www/semirror $
```

and deploy target project to Google Firebase server:

```
/www/semirror $ firebase deploy -m "SE mirror setup"

=== Deploying to 'xxxxxxxxxxxxxxx'...

i  deploying hosting
i  hosting[xxxxxxxxxxxxxxx]: beginning deploy...
i  hosting[xxxxxxxxxxxxxxx]: found 553 files in public
✔  hosting[xxxxxxxxxxxxxxx]: file upload complete
i  hosting[xxxxxxxxxxxxxxx]: finalizing version...
✔  hosting[xxxxxxxxxxxxxxx]: version finalized
i  hosting[xxxxxxxxxxxxxxx]: releasing new version...
✔  hosting[xxxxxxxxxxxxxxx]: release complete

✔  Deploy complete!
```

When accompanied with proper DNS records' setup (along domain ownership
verification), target Firebase site can be ressurected manually with less
than 1 hour (I am sure some skilled admins can do this 10x faster and in
an automatic fashion).

If one was really hosting malware, the above would constitute an obvious
and trivial bypass of Google Cloud policies (bypass assumed as long as
Google assumes site suspension as a security / protection countermeasure).

Google suspension of our our website has exposed several things.

It revealed that scanning implemented by the company for malicious software
and/or viruses is far from being perfect (false positives, signalling same
issues even though these were resolved). Instead of blocking target file
(suspicious content), whole site gets suspended. This is inconsistent with
project owner's ability (privileges) to create new project instances (and
continue hosting arbitrary content).

Google suspension also revealed that several things were not working as they
should when it comes to auth / privileges propagation (apparently known to
Google Support, subject to resolution) or what I think could be the async
nature of the internal protos / comms.

I don't want to make any unjustified conclusions at this point, but taking
into account the complexity of the thing (GCP) along past experience when it
comes to security, I start to wonder whether those little issues I have been
experiencing could be manifestations of some potentially more serious
issues.

There is also an issue related to the web page enforced / displayed by
Google
upon suspension of a given hosting project. This web page is highly
misleading.
If Google is taking action to suspend a hosting project, this action should
be also clearly communicated to the outside world. Current approach ("Site
not
found" page) implicates target website was either misconfigured by the owner
or simply hacked.

At the end, let me say that Google suspension did have some consequences to
3rd parties too.

According to our web server logs, our recent project pertaining to eSIM
security [7] has been the source of information for many MNOs, mobile phone
and eSIM vendors when it comes to security issues related to eSIM
technology.

By suspending our website, Google did cut all of these parties from the up
to date (or simply needed) project information (vide 220+ WebEx Agents / con
call participants observed over the recent 4 week time that visited this
page alone).

The irony is our web pages might become the source of information for Google
itself if it turns out that some of the eSIM security issues found (those
post
Kigen) are affecting Google Pixel phones (vide EID 89 033 023 ... chip id).

Thank you.

Best Regards,
Adam Gowdiak

----------------------------------
Security Explorations -
AG Security Research Lab
https://security-explorations.com
----------------------------------

REFERENCES:
[1] "Site Not Found" displayed for Security Explorations website

https://security-explorations.com/samples/google_suspension_site_not_found.jpg
[2] Suspension message from Google cloud

https://security-explorations.com/samples/google_compliance_suspension_msg_16.10.2025.jpg
[3] 404 HTTP errors observed in web server logs

https://security-explorations.com/samples/google_suspension_start_of_404_errors.jpg
[4] Java SE POC code from 2016 illustrating broken fix for issue from 2012
/ 2013
    https://security-explorations.com/materials/se-2012-01-69.2.zip
[5] POC Codes for issues in Google App Engine for Java from 2014 / 2015
    https://security-explorations.com/materials/se-2014-02-32-34.zip
    https://security-explorations.com/materials/se-2014-02-codes.zip
[6] Message indicating Java SE POC compliance with Google TOS

https://security-explorations.com/samples/google_compliance_url_ok_msg_08.08.2024.jpg
[7] eSIM security
    https://security-explorations.com/esim-security.html
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

• Google Firebase hosting suspension / "malware distribution" bypass Security Explorations (Oct 21)