
Attacco XSS su Atlassian Jira tramite Server Side Request Forgery (SSRF).
SSRF & XSS
https://jira.you.com//plugins/servlet/oauth/users/icon-uri?consumerUri=http://www.google.co.uk
Il servlet IconUriServlet del plugin OAuth di Atlassian dalla versione 1.3.0 precedente alla 1.9.12 e dalla versione 2.0.0 precedente alla 2.0.4 consente a un attaccante remoto di accedere al contenuto di risorse di rete interne e/o di effettuare un attacco XSS tramite Server Side Request Forgery (SSRF).
Secondo Atlassian Jira, le seguenti versioni sono vulnerabili:
In un attacco Server-Side Request Forgery (SSRF), l'attaccante può abusare della funzionalità del server per leggere o aggiornare risorse interne. L'attaccante può fornire o modificare un URL che il codice in esecuzione sul server legge o a cui invia dati, e selezionando attentamente gli URL, l'attaccante potrebbe essere in grado di leggere la configurazione del server come i metadati AWS, connettersi a servizi interni come database abilitati HTTP o effettuare richieste POST verso servizi interni che non sono destinati a essere esposti.
L'applicazione target può avere funzionalità per importare dati da un URL, pubblicare dati su un URL o altrimenti leggere dati da un URL che può essere manipolato. L'attaccante modifica le chiamate a questa funzionalità fornendo un URL completamente diverso o manipolando il modo in cui gli URL vengono costruiti (path traversal, ecc.).
Quando la richiesta manipolata arriva al server, il codice lato server prende l'URL manipolato e tenta di leggere dati dall'URL manipolato. Selezionando URL target, l'attaccante potrebbe essere in grado di leggere dati da servizi che non sono direttamente esposti su Internet:
Metadati del server cloud - Servizi cloud come AWS forniscono un'interfaccia REST su http://169.254.169.254/latest/meta-data/ da cui possono essere estratti configurazioni importanti e talvolta chiavi di autenticazione
Interfacce HTTP dei database - Database NoSQL come MongoDB forniscono interfacce REST su porte HTTP. Docker e Kubernetes - se le porte locali sono esposte internamente, un attaccante può creare/eliminare pod e contenitori e recuperare altri segreti.
Se il database è previsto essere disponibile solo internamente, l'autenticazione potrebbe essere disabilitata e l'attaccante può estrarre dati Interfacce REST interne
File - L'attaccante potrebbe essere in grado di leggere file utilizzando URI file:// L'attaccante potrebbe anche utilizzare questa funzionalità per importare dati non affidabili in codice che prevede di leggere dati solo da fonti fidate, e quindi aggirare la convalida dell'input.