GWS - Google Platforms Phishing
Last updated
Last updated
Na skyn, standaard, in werkspas lede kan groepe skep en mense na hulle uitnooi. Jy kan dan die e-pos wat aan die gebruiker gestuur sal word, wysig deur 'n paar skakels by te voeg. Die e-pos sal van 'n Google-adres afkomstig wees, so dit sal regverdig lyk en mense mag op die skakel klik.
Dit is ook moontlik om die VAN-adres as die Google-groep e-pos in te stel om meer e-posse aan die gebruikers binne die groep te stuur, soos in die volgende beeld waar die groep google--support@googlegroups.com
geskep is en 'n e-pos aan al die lede van die groep gestuur is (wat sonder enige toestemming bygevoeg is)
Jy mag dalk in staat wees om of 'n geselsie te begin met 'n persoon deur net hul e-posadres te hê of 'n uitnodiging om te gesels te stuur. Verder is dit moontlik om 'n Spasie te skep wat enige naam kan hê (bv. "Google-ondersteuning") en lede daartoe uit te nooi. As hulle dit aanvaar, mag hulle dalk dink dat hulle met Google-ondersteuning praat:
In my toetsing het die genooide lede egter nie eens 'n uitnodiging ontvang nie.
Jy kan sien hoe dit in die verlede gewerk het by: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s
In die verlede was dit moontlik om 'n skynbaar regverdige dokument te skep en dan in 'n kommentaar 'n paar e-posse te noem (soos @gebruiker@gmail.com). Google het 'n e-pos na daardie e-posadres gestuur om te laat weet dat hulle in die dokument genoem is. Tans werk dit nie meer nie, maar as jy die slagoffer e-pos toegang tot die dokument gee, sal Google 'n e-pos stuur wat dit aandui. Dit is die boodskap wat verskyn wanneer jy iemand noem:
Slagoffers mag 'n beskermingsmeganisme hê wat nie toelaat dat e-posse wat aandui dat 'n eksterne dokument met hulle gedeel is, hul e-pos bereik nie.
Jy kan 'n kalendergebeurtenis skep en soveel e-posadresse van die maatskappy wat jy aanval as wat jy het, byvoeg. Skeduleer hierdie kalendergebeurtenis in 5 of 15 minute vanaf die huidige tyd. Maak die gebeurtenis regverdig en plaas 'n kommentaar en 'n titel wat aandui dat hulle iets moet lees (met die hengelskakel).
Dit is die waarskuwing wat in die blaaier sal verskyn met 'n vergaderingstitel "Mense ontslaan", sodat jy 'n meer hengelagtige titel kan instel (en selfs die naam wat met jou e-pos geassosieer is, kan verander).
Om dit minder verdag te laat lyk:
Stel dit so in dat ontvangers nie die ander uitgenooide mense kan sien nie
Stuur GEEN e-posse wat die gebeurtenis aandui nie. Dan sal die mense net hul waarskuwing sien oor 'n vergadering in 5 minute en dat hulle daardie skakel moet lees.
Blykbaar kan jy met die API instel dat mense die gebeurtenis aanvaar het en selfs kommentaar namens hulle skep.
Dit is moontlik om 'n skripsie te skep in https://script.google.com/ en dit bloot te stel as 'n webtoepassing wat deur almal toeganklik is wat die regverdige domein script.google.com
sal gebruik.
Dan kan 'n aanvaller met 'n paar kode soos die volgende die skripsie maak om willekeurige inhoud in hierdie bladsy te laai sonder om die domein te stop te benader:
Byvoorbeeld, deur toegang te verkry tot https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec sal jy sien:
Let daarop dat 'n waarskuwing sal verskyn aangesien die inhoud binne 'n iframe gelaai word.
Dit is moontlik om App Scripts aan dokumente te koppel om toegang tot 'n slagoffer se OAuth-token te probeer kry, vir meer inligting kyk:
Enige van die vorige tegnieke kan gebruik word om die gebruiker te laat toegang verkry tot 'n Google OAuth-toepassing wat die gebruiker sekere toegang sal versoek. As die gebruiker die bron vertrou, kan hy die toepassing ook vertrou (selfs al vra dit vir hoë bevoorregte regte).
Let daarop dat Google 'n lelike waarskuwing toon wat aandui dat die toepassing onbetroubaar is in verskeie gevalle en dat Werkspasie-administrateurs selfs mense kan verhoed om OAuth-toepassings te aanvaar.
Google maak dit moontlik om toepassings te skep wat namens gebruikers kan interaksie hê met verskeie Google-diens: Gmail, Drive, GCP...
Wanneer 'n toepassing geskep word om namens ander gebruikers op te tree, moet die ontwikkelaar 'n OAuth-toepassing binne GCP skep en die scopes (regte) aandui wat die toepassing nodig het om die gebruikersdata te ontsluit. Wanneer 'n gebruiker daardie toepassing wil gebruik, sal hulle gevra word om te aanvaar dat die toepassing toegang sal hê tot hul data wat gespesifiseer is in die scopes.
Dit is 'n baie doeltreffende manier om nie-tegniese gebruikers te hengel om toepassings te gebruik wat sensitiewe inligting ontsluit omdat hulle moontlik nie die gevolge verstaan nie. Daar is egter maniere om te voorkom dat dit in organisasie-rekeninge gebeur.
Soos genoem, sal Google altyd 'n waarskuwing aan die gebruiker toon om die regte te aanvaar wat hulle die toepassing namens hulle gee. Indien die toepassing egter as gevaarlik beskou word, sal Google eerstens 'n waarskuwing toon wat aandui dat dit gevaarlik is en dit vir die gebruiker moeilik maak om die regte aan die toepassing te verleen.
Hierdie waarskuwing verskyn in toepassings wat:
Enige scope gebruik wat privaat data kan ontsluit (Gmail, Drive, GCP, BigQuery...)
Toepassings met minder as 100 gebruikers (toepassings > 100 vereis ook 'n hersieningsproses om die ongeverifieerde waarskuwing te stop)
Hier kan jy 'n lys van al die Google OAuth-scopes vind.
cloud-platform: Sien en bestuur jou data oor Google Cloud Platform-dienste. Jy kan die gebruiker in GCP impersoneer.
admin.directory.user.readonly: Sien en aflaai jou organisasie se GSuite-gids. Kry name, telefoonnommers, kalender-URL's van al die gebruikers.
Begin deur 'n OAuth-kliënt-ID te skep
Gaan na https://console.cloud.google.com/apis/credentials/oauthclient en klik op die instelling van die toestemmingsskerm.
Daarna sal daar gevra word of die gebruikerstipe intern is (slegs vir mense in jou organisasie) of ekstern. Kies die een wat by jou behoeftes pas
Intern mag interessant wees as jy reeds 'n gebruiker van die organisasie gekompromitteer het en jy hierdie Toepassing skep om 'n ander een te hengel.
Gee 'n naam aan die toepassing, 'n ondersteunings-e-posadres (let daarop dat jy 'n googlegroup-e-posadres kan instel om jouself bietjie meer anoniem te maak), 'n logo, geautoriseerde domeine en 'n ander e-posadres vir opdaterings.
Kies die OAuth-scopes.
Hierdie bladsy is verdeel in nie-sensitiewe regte, sensitiewe regte en beperkte regte. Elke keer as jy 'n nuwe reg toevoeg, word dit by sy kategorie gevoeg. Afhangende van die aangevraagde regte sal verskillende waarskuwings aan die gebruiker verskyn wat aandui hoe sensitief hierdie regte is.
Beide admin.directory.user.readonly
en cloud-platform
is sensitiewe regte.
Voeg die toetsgebruikers by. Solank die status van die toepassing toetsing is, sal slegs hierdie gebruikers toegang tot die toepassing hê, so maak seker om die e-pos wat jy gaan hengel by te voeg.
Kry nou geldeenhede vir 'n webtoepassing deur die voorheen geskepte OAuth-kliënt-ID te gebruik:
Gaan terug na https://console.cloud.google.com/apis/credentials/oauthclient, 'n ander opsie sal hierdie keer verskyn.
Kies om geldeenhede vir 'n webtoepassing te skep
Stel die benodigde Javascript-oorspronge en omleidings-URI's in
Jy kan vir beide iets soos http://localhost:8000/callback
instel vir toetsdoeleindes
Kry jou toepassing se geldeenhede
Laastens, laat ons 'n webtoepassing hardloop wat die OAuth-toepassingsgeldeenhede sal gebruik. Jy kan 'n voorbeeld vind by https://github.com/carlospolop/gcp_oauth_phishing_example.
Gaan na http://localhost:8000
klik op die Login met Google knoppie, jy sal genader word met 'n boodskap soos hierdie een:
Die aansoek sal die toegangs- en verfris-token wys wat maklik gebruik kan word. Vir meer inligting oor hoe om hierdie tokens te gebruik, kyk na:
gcloud
Dit is moontlik om iets te doen met gcloud in plaas van die webkonsolide, kyk:
https://www.youtube-nocookie.com/embed/6AsVUS79gLw - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic
https://www.youtube.com/watch?v=KTVHLolz6cE - Mike Felch en Beau Bullock - OK Google, How do I Red Team GSuite?