Entonces, el problema era: estaba ejecutando apache en mi localhost para alojar el exploit y estaba tratando de conectarme de nuevo a mí mismo. (Me di cuenta de esto después de que me bombardeé una vez.)

Después de eso, alojé un shell de reversa de una línea (gracias a los comentarios de @Michael) en una máquina diferente y generé un shell en la máquina de destino.

Comience a enviar un archivo PHP simple con un comando que no requiere salida, pero le permite determinar si se ha ejecutado o no.

Simplemente ejecute el doble del RFI y envíelo desde netcat:

<?php /* do nothing */ ?>

y

<?php sleep(10); ?>

Si el segundo comando hace que el sitio web devuelva la página en un lapso de tiempo de 10 segundos más que con el primer intento, entonces su RFI está potencialmente funcionando. Todo lo que puede queda por ver.

Si los dos comandos regresan al mismo tiempo, no hay una pausa adicional de diez segundos, entonces el código PHP que envió es claramente no se está ejecutando , por lo que enviar una cáscara inversa no tiene mucho sentido.

Los siguientes pasos incluyen enviar algo que intente mostrar en la página de destino.

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

podría funcionar. Además, intente establecer qué sistema está examinando (por ejemplo, Ubuntu 12.04-LTS). Eso te dirá a qué debes prestar atención, por ejemplo. AppArmor o SELinux o permisos especiales. Tratar de obtener un phpinfo() sería bueno, para determinar si algunas funciones se han deshabilitado, por ejemplo.

Usted trabaja hacia arriba desde eso hasta una cáscara inversa completa. En el camino, probablemente descubrirá por qué no funciona la shell inversa, y con algo de experiencia debería poder hacerlo funcionar nuevamente, implementar otra cosa o concluir que no existe una vulnerabilidad real.

Una posibilidad que vale la pena considerar sería utilizar la RFI para crear una segunda RFI que sea más fácil de explotar, si el primer script atacado aún es capaz de escribir archivos en el disco en ubicaciones accesibles (y explotables).

Pero ...

Observe que incluyó 'evilcode.txt' y el script solicitó 'evilcode.php.txt'. Esto no es un simple anexo (habría sido 'evilcode.txt.php').

Lo que parece estar sucediendo es que la página recibe el nombre básico del archivo, luego agrega '.php.txt', que parece indicar algún plan en funcionamiento. No es .php, no es .txt, es .php.txt, como si el autor quisiera marcarlo como PHP, pero al mismo tiempo no PHP.

Es posible que esté leyendo demasiado en una extensión simple. Pero también es posible que la RFI, aunque sea una inclusión de archivos remotos, no ejecute el código de inmediato, sino que haga algo como:

// 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);
}

Lo anterior parecería ser una RFI explotable, pero a menos que conozca la palabra secreta, simplemente no funcionará. Por otro lado, es posible que pueda obtenerlo leyendo una de las páginas remotas, ahora que sabe cómo se obtiene el verdadero nombre local.

Esto es para esperar que esas páginas no estén bloqueadas por IP, y solicitarlas en cualquier otro lugar, pero la dirección del servidor no genera una alerta.

He hecho esto antes, pero inserté una pausa en el script de shell inverso y luego volví a mi host y eliminé apache2 de inmediato. Permite que la máquina remota tome el documento evil.php, etc. y luego me da 3 o 5 o los segundos arbitrarios para matar el apache2 en el puerto 80.