Come sfruttare questa vulnerabilità di include_once in PHP?

1

Sto eseguendo un'analisi statica su un codice PHP e ho trovato questa situazione:

include_once SYSTEM_PATH . 'languages/content-' . $_COOKIE ['lang'] . '.php';

Se provo a hackerare con questa richiesta HTTP:

GET /en-us HTTP/1.1
Host: xxxx.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: xxx=eng.php/../../../anotherfile
Connection: keep-alive

La risposta è questa:

ErrorException: 
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

Il file languages/content-eng.php esiste sul server.
Il file languages/../../../anotherfile.php esiste anche sul server (ho accesso al file system).

C'è un modo per sfruttare questa vulnerabilità tramite lang cookie?

    
posta jyz 22.10.2014 - 16:09
fonte

3 risposte

2

Sigh. Ecco il ragionamento per me postare un link al posto di una lunga risposta. Il post originale vuole iniettare / disaffezionare / sfruttare tramite la variabile lang nel cookie:

GET /en-us HTTP/1.1
Cookie: xxx=eng.php/../../../anotherfile

Quindi afferma che ha provato e fallito:

ErrorException: 
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

"Nessun file o directory simile" per me significa una delle poche cose:

1) La sua directory traversal è disattivata:

/export/htdocs/xxxx.com/base/languages/content-eng.php
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/anotherfile.php

Se la struttura è esattamente come sopra, non esiste un periodo di vulnerabilità di attraversamento di directory.

2) eng.php non è abbastanza dettagliato per sapere cosa fa. Questo dovrebbe essere il debole anello vulnerabile della catena

Sta facendo affidamento su un errore, pensando: "Oh beh, ho un errore, sono sulla buona strada"

OP: Potresti armeggiare un po 'di più con le directory. Ti dice "Non riesco a trovare questo file" il problema diventa "cosa stai trovando" se dichiari di avere accesso alla macchina, la soluzione che utilizzerei sarebbe quella di posizionare i token nelle cartelle per determinare dove stai atterrando :

/export/htdocs/xxxx.com/base/languages/**option1**/token1
/export/htdocs/xxxx.com/base/languages/**option1/option2**/token2
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/token3

Quindi prova un altro POST / GET, forse:

Cookie: xxx=eng.php/token1
Cookie: xxx=eng.php/token2
Cookie: xxx=eng.php/token3

Cookie: xxx=eng.php/../token1
Cookie: xxx=eng.php/../token2
Cookie: xxx=eng.php/../token3

Cookie: xxx=eng.php/../../token1
Cookie: xxx=eng.php/../../token2
Cookie: xxx=eng.php/../../token3

Solo perché hai ricevuto un errore, non significa che l'attraversamento della directory sia presente. Per quello che sai, è un errore globale che stai ricevendo. Il link iniziale che ho inviato era di guidarti su una "nota conosciuta" (variabile che controlli) lang.

MODIFICA DEI VINCITORI DELLO SPAZIO:

OP: " La base è /export/htdocs/yyy.com/base/. Il file anotherfile.php è in /export/htdocs/xxx.com/anotherfile.php"

A meno che non stia interpretando male questo:

/ export / htdocs / yyy.com / base /

/ export / htdocs / xxx.com /anotherfile.php

Questi sono su siti separati? Se xxx.com è il tuo server / macchina di prova, ho l'impressione che stai provando un exploit LFI:

you --> modify cookie (hey, take this anotherfile.php from my machine) --> yyy.com

Ancora una volta, il ragionamento per il mio post inizialmente un link al posto di una risposta. Se intendevi il contrario (typo):

/ export / htdocs / yyy.com / base /

/ export / htdocs / yyy .com / anotherfile.php

Quindi devi modificare il tuo inserimento in ../../anotherfile o spostare un altro file in:

/ export / htdocs / yyy.com / base /

    
risposta data 22.10.2014 - 16:43
fonte
2

Non puoi leggere il codice PHP con include() o require() perché queste funzioni valutano il codice PHP all'interno di un file. Se riesci a controllare la parte iniziale della stringa trasmessa a include () o require (), puoi utilizzare php: // filtro per leggere i file php , ma questo modello di attacco non si applica a questo errore.

Per ottenere una shell con questa vulnerabilità LFI, è necessario disporre di una backdoor sulla destinazione con un'estensione .php . Idealmente questo sarebbe fatto usando un'altra vulnerabilità come il caricamento di file. L'iniezione di byte NULL non funziona sulle versioni moderne delle funzioni file di PHP, quindi sei bloccato con l'estensione .php.

Un altro tipo di attacco consiste nell'includere i file .php esistenti per esporre le funzionalità dell'applicazione esistenti in modo non intenzionale.

    
risposta data 22.10.2014 - 17:36
fonte
1

Funziona perfettamente bene per me con eng.php/../../../anotherfile (sto usando PHP 5.5.6-1).

  • Sei sicuro che anotherfile.php sia nella directory corretta? Prova a posizionarlo nella stessa directory dei file lang php e includilo lì (solo per il test).
  • è leggibile dal server web? (per i test, puoi solo chmod 777 file.php ).

Si noti inoltre che mentre si includono i file PHP dovrebbe funzionare, inclusi altri file (ad es. usando byte null) non funziona nelle versioni più recenti di PHP .

    
risposta data 22.10.2014 - 16:43
fonte

Leggi altre domande sui tag