Envato mostra codice 400

Come Envato ha gestito dei potenziali rischi per la sicurezza attraverso il suo programma Bug Bounty

Quando si pensa a grandi aziende come Slack, Atlassian, la sicurezza, dell’azienda e del cliente è fondamentale. Ma se proprio una di queste aziende come Envato, non fosse totalmente sicura? Ecco qua un rapporto tecnico su delle vulnerabilità scoperte e riportate ad Envato dal sottoscritto.

Riassunto o TL;DR

Gli sviluppatori di Envato non hanno costruito un buon filtering per evitare una Cross Site Injection, ho notato quindi che potevo iniettare senza problemi codice HTML (e anche javascript). Ho contattato urgentemente Envato e dopo alcune ricerche per trovare la causa, mi hanno scritto che le due vulnerabilità potevano portare a un bypass di alcuni endpoint nel codice. Hanno risolto tutto in circa 5 giorni. Ottimo lavoro, Team di Envato!

Come tutto iniziò

Prima di tutto, sono un Envato Author: ho iniziato a vendere miei prodotti (quali plugin e temi) da agosto .Envato è un colosso australiano, il cui obiettivo è stato creare dei market e permettere a freelancer come me di vendere prodotti (quali possono essere temi, canzoni, plugin, grafica). Sono principalmente uno sviluppatore web (anche se non me la cavo male sul lato desktop) e un ricercatore di sicurezza. Penso che la sicurezza dei dati debba essere una delle priorità, se non la più importante per aziende come Envato.

Envato, al momento, ha più di 1 milione di clienti con oltre 41 milioni di prodotti venduti in circa 11 anni. Tutto iniziò quando mi imbattei nei vari bug bounty di varie aziende famose, tra le quali anche l’azienda Envato. Ovviamente, testandone l’infrastruttura e i vari market, io accettavo automaticamente un bug bounty con delle regole precise per migliorare il rapporto tra il team di sviluppo e il ricercatore. Per chi non dovesse sapere cosa sia un bug bounty, semplicemente è un “accordo” tra due parti: l’azienda e il ricercatore, grazie al quale un individuo può ricevere riconoscimenti e ricompense in denaro per la segnalazione di bug, in particolar modo di quelli relativi ad exploit e vulnerabilità.

“Ricordati che non puoi fare alcun genere di test, se non accettando il programma bug Bounty di Envato.”

Detto ciò, ho aperto il browser e ho digitato uno dei famosi market di Envato: Codecanyon. Con Codecanyon, puoi rivendere plugin di tutti i tipi, da Wordpress a Prestashop ma anche web-app sviluppate con php. Aprendone la pagina, ho incominciato a cercare cosa potevo “rompere”. Ma andiamo con ordine, le vulnerabilità accettate dal programma di Envato includono: Cross Site Scripting, sql injection, esecuzione codice da remoto e il bypassing di alcuni controlli di sicurezza.

Da quando ho iniziato a sviluppare e testare web-app, il rischio maggiore per le vulnerabilità, oltre a porte aperte, server configurati male con ftp pubblico, sono gli input degli utenti. Gli input degli utenti, se mal costruiti, possono essere le prime vie per aggiungere, modificare, eliminare qualche dato pur non avendo un completo accesso al database. Se poi gli input vengono richiamati nelle varie pagine senza un filtering (controllo), un malintenzionato potrebbe iniettare qualche script malevolo. Uno dei campi input più usati per “testare” la web app è la barra di ricerca: in ogni sito ce ne è sempre una, da un lato potrebbe essere anche una funzione utile per gli utenti finali, dall’altra potrebbe essere la miglior via per attacchi come sql injection. Senza un buon filtering, la web app potrebbe eseguire un qualsiasi input che può codice e / o query sql fornito dall’utente.

Campo di ricerca per Envato

Nel mio caso, avevo provato a iniettare nel campo di ricerca una query sql come ad esempio where '1' = 1, per fortuna non funzionava (era una grande notizia, immagina se avessi avuto accesso al database). Mi aspettavo ciò perchè, per fortuna, il team aveva sviluppato un backend e un frontend separato, pero’ mai fidarsi ciecamente, anche il backend potrebbe avere qualche vulnerabilità che sfruttata a dovere porterebbe a un accesso completo ai dati.

Ma per quanto riguarda il frontend? C’è un tipo di vulnerabilità che spaventa molto sviluppatori di tutto il mondo (letto e riletto da un rapporto finale del 2016 di Hackerone): le Cross Site Scripting Injection.

Il Cross-site scripting (XSS) è una vulnerabilità che affligge siti web dinamici che impiegano un insufficiente controllo dell’input nei form. Un XSS permette ad un Cracker di inserire o eseguire codice lato client al fine di attuare un insieme variegato di attacchi quali ad esempio: raccolta, manipolazione e reindirizzamento di informazioni riservate, visualizzazione e modifica di dati presenti sui server, alterazione del comportamento dinamico delle pagine web ecc.

Nell’accezione odierna, la tecnica ricomprende l’utilizzo di qualsiasi linguaggio di scripting lato client tra i quali JavaScript, HTML. Il loro effetto può variare da un piccolo fastidio a un significativo rischio per la sicurezza, a seconda della sensibilità dei dati trattati nel sito vulnerabile e dalla natura delle strategie di sicurezza implementate dai proprietari del sito web.

Ho scoperto che ogni query di ricerca veniva passata al frontend come un url simile a quello qua sotto : https://codecanyon.net/search/query dove query è la query di ricerca, che può essere qualsiasi parola. Ma cosa succederebbe se provassi a sostituire query con uno script XSS?

Ho provato, quindi, con una delle più semplici delle XSS injection: <script>alert("envato");</script>

Prima prova

Come puoi vedere dallo screenshot in basso sembrerebbe che la web app mi abbia filtrato l’input e restituito una pagina 404, allora saranno protetti anche dalle XSS Injection. Purtroppo non è così, infatti sostituendo query con <script>, la pagina di ricerca mi ha dato un risultato inaspettato. Gli screenshots qui di seguito danno una visione completa di quella che potrebbe essere una vulnerabilità: nella pagina di ricerca, quando il backend trova qualche prodotto in relazione con la query, appare una frase: “You have found 301 query plugins and scripts from $2. All from our web community”, dove query è la tua parola di ricerca (nell’esempio la parola era “envato”). Ho scoperto da ciò che il frontend non sanizzava l’input della ricerca effettuata dall’utente.

Cercando Envato
Potenziale injection

Non avevo ancora capito di aver trovato una vulnerabilità così tanto seria, ma avevo scoperto che la vulnerabilità funzionava solo se il frontend trovava qualcosa abbinato alla mia query di ricerca. Questo stava a significare che <script>alert("envato");</script> non funzionò perchè nessun prodotto aveva come nome o conteneva come descrizione le parole “script” “alert” “envato”. Guardando anche il codice da “Ispeziona Elemento”, si può ben capire l’iniezione XSS, che non comprendeva solo gli script ma anche tag html.

Ispezionando i sorgenti

Per le ragioni precredenti, non potevo iniettare un codice contenente ’’ or “”, così provai <script>alert(1);</script> per avere un Proof of Work da presentare al team di Sviluppo. Quando il frontend mi restuì il risulato, fui subito reindirizzato all’url “data;”. Questo stava a significare che potevo iniettare uno script semplicemente dall’url!! Pensavo che fosse uno scherzo di una lunga serata cercando di scoprire qualche vulnerabilità quà e là, invece era tutto vero: ora bastava soltanto la segnalazione al team.

Contattare il team di sviluppo

Envato fornisce ai suoi clienti e venditori un buon supporto, puoi contattarli senza problemi con i social network o mail. Ho preferito l’email, dato che è più formale. Ho incominciato a documentare il tutto: le 2 vulnerabilità (XSS injection e nessun filtering), un buon proof of work e qualche suggerimento per il futuro su come evitare queste spiacevoli vulnerabilità, frutto di sviluppatori (forse) incompetenti. Il team principale ha base in australia, così nel giorno che è passato per ricevere una prima conferma/risposta da parte loro, ho “giocato” (senza ovviamente recar danno alcuno) con le vulnerabilità trovate ore prima.

In sostanza, ero in grado di:

  • Iniettare qualsiasi codice html, tra cui <a><style>
  • Iniettare qualsiasi script che mi portava a fare tutto o quasi ciò che volevo, dalla modifica semplice di qualche elemento nella pagina al cookie stealing, data capturing e invio di tutto ciò in un form nascosto all’utente.
Link Injection

Dopo la conferma di questi due problemi, Envato mi notifica di aver trovato un altra vulnerabilità molto più seria (a me sconosciuta).

Momento divertente
Un altro momento divertente

Il premio

Come l’azienda scrive nel suo programma bug bounty, non possono mandarmi alcuna forma di denaro come alcune compagnie che potrebbero pagare anche 1,000 dollari per una vulnerabilità del genere.

“Reported issues will be prioritised based on impact on our community, not based on financial incentives.”

Invece di un premio economico, ho ricevuto un grande “Grazie” da parte del team di Envato, un fantastico badge sul mio profilo Envato e una menzione su “Honor Roll Envato Systems”, una sorta di lista di tutti gl utenti che negli ultimi anni hanno riportato vulnerabilità serie.

Helpful Hacker
Honor

Come hanno risolto

Dopo ben 5 giorni di astenuante ricerca da parte loro, sono arrivati a sviluppare una soluzione. Se provassi adesso a iniettare qualsiasi tag html direttamente nell’url, comparirà un errore 400 Bad Request. Stesso errore per quanto riguarda l’iniezione dal campo input di ricerca.

Envato mostra codice 400
Envato mostra codice 400 nella pagina di ricerca

Questo è tutto per ora, volevo ringraziare in particolar modo il team Envato che mi ha supportato durante la segnalazione.