OS Command Injection
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio Blind OS command injection with output redirection de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.
ANÁLISIS DE RIESGO
CWE-78 | Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) |
IMPACTO | ALTO |
CVSS BASE SCORE | 6.5 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N |
COMPONENTES AFECTADOS | https://LAB-ID.web-security-academy.net/feedback |
EXPLICACIÓN | Esta vulnerabilidad permite la inyección a “ciegas” de comandos en el SO. De esta manera, un usuario no autenticado puede redirigir la salida del mismo hacia la ruta de otro archivo, poniendo en riesgo la confidencialidad e integridad de los mismos. |
RECOMENDACIONES
1) Validar y Sanitizar las entradas de datos: Se debe asegurar de que solo se permitan caracteres válidos y rechazar cualquier entrada inesperada, especialmente aquellas que se utilizan para construir comandos del sistema operativo. Un ejemplo en PHP podría ser:
//Validación y sanitización de una cadena de entrada. $userInput = $_POST[‘user_input’]; $cleanInput = htmlspecialchars($userInput, ENT_QUOTES, ‘UTF-8’); |
2) Escapar caracteres especiales: Se recomienda filtrar o rechazar caracteres como ;, &, |, >, <, entre otros. Sumado a esto, se podrían utilizar funciones específicas del lenguaje para realizar esta tarea. Por ejemplo, en Python se puede usar shlex.quote()de la siguiente manera:
import shlex user_input = «input from user» escaped_input = shlex.quote(user_input) |
Y en PHP escapeshellarg().
$user_input = «input from user»; $escaped_input = escapeshellarg($user_input); |
3) Utilizar Parámetros de Consulta como Argumentos: En lugar de concatenar directamente los parámetros de consulta en la cadena de comandos del sistema, se recomienda tratar los parámetros como argumentos del sistema, ya que esto puede evitar ataques de inyección al separar la ejecución del comando de los datos proporcionados por el usuario.
4) Establecer una Política de menor privilegios: Se recomienda asegurar que el proceso, o usuario, que ejecuta la aplicación web tenga los permisos mínimos necesarios. Un usuario estándar del sistema no debería tener privilegios elevados que podrían comprometer la seguridad del sistema en caso de una inyección de comandos.
5) Establecer reglas de registro y/o monitoreo: Se recomienda implementar reglas y/o registros de actividad para detectar y bloquear posibles intentos de inyección de comandos. Por ejemplo, se pueden establecer alertas para eventos sospechosos y realizar un monitoreo regular de los registros para identificar posibles amenazas. Por ejemplo:
Para detectar comandos en parámetros de URL: En esta regla, se busca la presencia de palabras clave como bash, cmd, exec y sh.
alert http $EXTERNAL_NET any -> $HOME_NET any
(msg:«Possible Command Injection OS»;
pcre:«/(\%2E%2E\/|bash|cmd|exec|sh)/i»; sid:1000002;)
Detectar patrones específicos de inyección de comandos: En esta regla se busca la presencia de patrones que puedan indicar comandos peligrosos, como cat /etc/passwd o herramientas como nslookup, ping, nc y telnet.
alert http $EXTERNAL_NET any -> $HOME_NET any
(msg:«Possible Command Injection OS»;
pcre:«/(\|\s*cat\s*\/etc\/passwd|\b(?:nslookup|ping|nc|telnet)\b)/i»;
sid:1000004;)
Limitar Solicitudes por Segundo a través de Iptables: La siguiente regla permitirá hasta 5 solicitudes por segundo desde una dirección IP antes de bloquearla.
iptables -A INPUT -p tcp –dport 80 -m recent –update –seconds 1
–hitcount 5 -j DROP
iptables -A INPUT -p tcp –dport 80 -m recent –set -j ACCEPT
6) Realizar pruebas de seguridad: Se recomienda utilizar servicios como SAST, DAST y/o OAST para corregir y prevenir posibles huecos de seguridad en las diferentes etapas del desarrollo. Como así también, mantener actualizadas todas las herramientas con sus respectivos parches de seguridad.
7) Educar en Materia de Seguridad informática: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web, se pudo observar que la misma cuenta con las pestañas “home” y “Submit feedback” como se ve a continuación.
Por tanto, se procedió a ingresar a la pestaña de feedback para estudiar la forma en la que se envían los datos cuando se llena un formulario. Para ello, se ingresaron los siguientes datos.
Teniendo esto en cuenta, se procedió a utilizar la herramienta Burpsuit para capturar la petición y visualizar los datos.
Teniendo en cuenta dichos parámetros, una de las medidas que se tomaron fue colocar x & sleep 10 # dentro del parámetro “email” para verificar si el mismo es vulnerable a una inyección de comandos. Por tanto, dichos datos se enviaron vía URL-Encode de la siguiente manera:
Significado de caracteres:
x —> Se utiliza para especificar el contenido del parámetro “email”.
%26 —> Refiere al caracter ‘&’ en Hexadecimal. El mismo se utiliza para delimitar, o separar, el contenido del parámetro con respecto al comando a inyectar.
sleep 10 —> Comando utilizado para generar un retraso de 10 segundos en la respuesta del servidor.
%23 —> Refiere al caracter ‘#’ en Hexadecimal. El mismo se utiliza para indicar el final de la consulta y evitar posibles problemas con el servidor.
De esta forma, como se puede observar, se generó un retraso de poco más de 10 segundos por parte del sevidor. Por tanto, se puede verificar que la aplicación es vulnerable a Inyección de comandos a través del parámetro “email”.
No obstante, si bien se pudo comprobar que el fallo de seguridad existe, el servidor no devuelve el output en texto plano de ningún comando inyectado. Esto quiere decir que la salida del mismo se realiza “a ciegas”. Por lo tanto, se procedió a generar una redirección de dicho output hacia la ruta de otro archivo, más específicamente, hacia /image/?filename=number.jpg las cuales se cargan cuando se accede al home (o raíz) de la aplicación.
Generalmente el index de la aplicación en servidores linux suele estar dentro del directorio /var/www o /var/www/html.
Por tanto, se utilizó la línea de comandos whoami>/var/www/images/output.txt para poder enviar el ouput del comando “whoami” dentro del directorio /images y verificar si el mismo se encuentra dentro de /var/www.
De esta manera se pudo comprobar que, por más que el servidor devuelva la respuesta a del comando inyectado a “ciegas”, es posible visualizar el contenido del mismo a través de una redirección a otro directorio o archivo. De esta forma es posible ver la salida del comando whoami el cual refiere al usuario “peter-3ysEzp”.
El impacto que esta vulnerabilidad puede provocar son las siguientes:
- Un atacante puede visualizar el archivo /etc/passwd donde puede conocer los usuarios con y sin shell interactiva para iniciar sesión.
- Buscar posibles versiones vulnerables en el kernel del SO a través del comando uname -a.
De esta manera, un usuario no autenticado puede visualizar archivos locales del sistema y ejecutar comandos de forma remota, poniendo en riesgo la confidencialidad e integridad de los mismos.
