Slack finalmente rivela i difetti di RCE nella sua app desktop
L’ingegnere di sicurezza Oskars Vegeris di Evolution Gaming ha rivelato diverse vulnerabilità in Slack consentendo agli aggressori di caricare un file e condividerlo con un altro utente o canale Slack per attivare l’exploit sull’app Slack delle vittime.
Ha condiviso i dettagli scritti in privato con Slack nel gennaio 2020, dove sono menzionati dettagli estesi sulla vulnerabilità. Secondo il ricercatore, “Con qualsiasi reindirizzamento in-app: reindirizzamento logico / aperto, HTML o iniezione di javascript è possibile eseguire codice arbitrario nelle app desktop Slack. Questo rapporto mostra un exploit appositamente predisposto costituito da un’iniezione di HTML, bypass del controllo di sicurezza e un payload Javascript RCE. Questo exploit è stato testato per funzionare sulle ultime versioni di Slack per desktop (4.2, 4.3.2) (Mac / Windows / Linux). “
Vegeris ha fornito un video dimostrativo di 5 secondi con un articolo di HackerOne che ha mostrato come ha utilizzato un file JSON per attivare l’avvio di un’applicazione di calcolo nativa tramite l’app desktop Slack. Questo rapporto è stato reso pubblico dalla società questa settimana. Mostra diversi modi in cui l’ingegnere ha elencato per sfruttare l’app Slack.
Questo exploit si traduce in un’esecuzione di codice arbitrario dal computer dell’utente e non dal back-end di Slack. Le debolezze nel codice Files.Slack.com consentono a un utente malintenzionato di ottenere l’iniezione di HTML, l’esecuzione di codice arbitrario e lo scripting intersito.
Vegeris ha pubblicato solo un exploit Proof of Concept HTML / JavaScript che mostra come sia facile avviare l’app calcolatrice nativa caricando il payload su Slack.
Quando l’URL di questo file HTML viene iniettato nell’area del tag della rappresentazione del post JSON di Slack, si abilita RCE con un clic sul dispositivo. L’ingegnere ha dichiarato: “Il collegamento URL all’interno del tag area conterrebbe questo exploit HTML / JS per le app Slack Desktop che esegue qualsiasi comando fornito dall’attaccante”.
Vegeris, in un altro commento ha detto, “Anche il keylogging segnalato in precedenza potrebbe essere applicabile”, si riferisce alla segnalazione di bug presentata a Matt Langlois nel 2019.
Per i risultati, l’ingegnere è stato ricompensato solo con i miseri $ 1.750. Molti gestori di Twitter affermano che l’ingegnere guadagnerebbe più di $ 1.750 se vendesse l’exploit sui mercati illeciti del dark web. Ci sono vari casi in cui gli utenti si scagliano contro Slack, come questo:
Daniel Cuthbert, hacker e coautore dello standard OWASP ASVS ha dichiarato in un thread di Twitter: “Slack, utilizzato da milioni e milioni per chat di progettazione mission-critical, DevOps, sicurezza, fusioni e acquisizioni, l’inferno l’elenco è infinito. i difetti riscontrati da questo ricercatore comportano l’esecuzione di comandi arbitrari sul computer dell’utente. Il TL; DR è wow. “
Cuthbert ha supplicato Slack di pagare correttamente: “Per tutto questo impegno, sono stati premiati $ 1750. Diciassette cento e Cinquanta dollari. @SlackHQ in primo luogo i difetti sono una preoccupazione piuttosto grande, voglio dire la convalida è difficile ma dai, quindi paga correttamente, per favore. Perché questo varrebbe molto di più su exploit.in. “
La società aveva persino dimenticato di accreditare Vegeris in un post sul blog promozionale pubblicato due mesi fa. Inoltre, piuttosto che rivelare i dettagli della vulnerabilità, l’azienda ha celebrato la sua funzionalità sandbox dell’app quella volta.
Questo è quando Vegeris ha richiesto ad HackerOne la divulgazione pubblica dei risultati, la società ha iniziato a scusarsi sinceramente.
Il rapporto di Ryder dice: “Il mio nome è Larkin Ryder e attualmente sto servendo come Chief Security Officer ad interim qui a Slack. @Brandenjordan mi ha reso consapevole di questo passo falso e ti scrivo per esprimere scuse molto sincere per qualsiasi svista nell’accreditare il tuo lavoro. Apprezziamo molto il tempo e gli sforzi che hai investito per rendere Slack più sicuro “.
Ha continuato: “Sebbene il team di sicurezza non sia l’autore di questo post del blog e l’autore non abbia visibilità sul tuo lavoro in H1, dovremmo fare i passaggi aggiuntivi per garantire che tutti coloro che hanno contribuito agli sforzi di miglioramento in quest’area siano riconosciuti. facendo gli opportuni aggiornamenti al nostro post sul blog … Ancora una volta, mi dispiace molto per qualsiasi passo falso da parte nostra. “
Al momento, queste vulnerabilità sono state corrette. Erano passate poco più di cinque settimane dal rapporto.