Come ho rotto la barra di ricerca di Envato

by SerHack


Postato il 6 Ottobre 2017, alle 12.00


Come Envato ha gestito dei potenziali rischi per la sicurezza

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

TLDR

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 (non contando le festività, sabato e domenica). 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 deve 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 il colosso australiano 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.

Codecanyon Image

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 con una delle più semplici delle XSS injection: <script>alert("envato");</script>

script codecanyon xss injection

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.

script codecanyon xss
Cercando "Envato"
Potenziale XSS 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.

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 la mail, 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.
Dopo la conferma di questi due problemi, Envato mi notifica di aver trovato un altra vulnerabilità molto più seria (al momento a me sconosciuta).

link injection envato
Iniezione di un link
funny injection envato
Momento divertente parte 1
injection envato
Momento divertente parte 2

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. Honor Roll.

profile badge envato
Il Badge sul mio profilo
Envato Hnor Roll
Honor Roll Envato Systems

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.

error 400 bad request envato
Errore 400 Bad Request
error 400 bad request codecanyon
Error 400 nel campo di ricerca

Questo è tutto per ora, volevo ringraziare in ordine: Envato Team che mi ha supportato durante la segnalazione, i miei amici (diversi se non centinaia) su telegram che mi supportano in ogni folle azione che faccio. A mio parere un azienda del genere dovrebbe spendere più risorse (sia finanziare sia per quanto riguarda l'infrastruttura) per evitare questi problemi in futuro. Let's change the world

About Me
Ciao, sono SerHack. Sviluppatore e ricercatore di vulnerabilità.
Newsletter