full-disclosure - Re: [FD] Spammers Using storage[.]googleapis[.]com ?!!?

Open Source and information security mailing list archives

Date: Tue, 3 Aug 2021 20:36:29 +0200
From: Adrien JOLIBERT <jolibert@...il.com>
To: Nick Boyce <nick.boyce@...il.com>
Cc: Full Disclosure List <fulldisclosure@...lists.org>
Subject: Re: [FD] Spammers Using storage[.]googleapis[.]com ?!!?

Quite an old trick becoming popular.
So yep, the stuff is hosted on one of the google services in private mode; redirections gives you a valid token to access.

> Le 3 août 2021 à 19:35, Nick Boyce <nick.boyce@...il.com> a écrit :
> 
> I notice that among the spam in my Gmail spam folder, there are a
> number of "address-check" type messages (i.e. that just seek
> confirmation my address exists), which attempt to get their response
> by performing a scripted redirect via a web property belonging to
> Google ...... and I tend to think "Huh? ... Surely Google wouldn't let
> that happen ... is this redirect something that by some chance they
> don't know about ?".
> 
> Every link in the spam has the following HREF:
> 
> https://storage[.]googleapis[.]com/medya00/redirectDOM80.html#[long-alphanum-string-that-presumably-identifies-me]
> 
> The contents of 'redirectDOM80.html' just sets document.location.href
> to somewhere else, passing on the ID string.
> 
> I won't include any of the above spam's boilerplate, but it's offering
> to let me check my "public records" so that I can find out what other
> people might know about me.
> 
> So does anybody know WTF ?   Is this some unfortunate side-effect of a
> Google service that can't be avoided (I have no real idea what the
> purpose of 'storage[.]googleapis[.]c' might be), or is this in fact
> some dreadful snafu on the part of some Google sysadmin somewhere ?
> 
> There's some useless discussion of what sounds like the same thing, here:
> https://community.norton.com/en/forums/storagegoogleapiscom
> but it's the very idea of there being an open redirect in a Google web
> property that astonishes me.
> 
> These Google support tickets from 2020 suggest that anybody can store
> anything they want as a second-level URI within s.g.c, and that
> malicious artifacts are commonly stored there, and that Google is
> blissfully ignorant of it until each individual artifact is reported,
> and that even then Google doesn't care and does nothing:
> https://support.google.com/webmasters/thread/29210246/storage-googleapis-abuse-report?hl=en
> https://support.google.com/webmasters/thread/24437958/does-google-take-actions-with-regards-to-reported-cloud-storage-abuse-reports?hl=en
> ..... but I can't quite believe it - surely they vet incoming traffic
> ?  Allowing the upload of arbitrary HTML to their own domain is ....
> well .. [head explodes].
> 
> FWIW, people complain that Amazon AWS is also abused in the same way.
> 
> [No, I haven't bothered to let Google know directly - all of my
> attempts to let them know about other minor issues with their services
> have just resulted in a deafening silence - but I will try if folks
> think I should.]
> 
> Cheers
> Nick
> 
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives