Conoce los tipos de vulnerabilidades que nos podemos encontrar en una aplicación web.
Si aún te preguntas si debes o no actualizar tus plugins, temas o core de WordPress, te animo a que veas este artículo hasta el final y compruebes por ti mismo lo que te puede ocurrir si no lo haces.
En este post iré recopilando los diferentes tipos de vulnerabilidades que nos podemos encontrar en las aplicaciones web. Os dejo una pequeña descripción de cada una de ellas para que se entienda y algunos ejemplos de explotaciones. Para los ejemplos hemos creado unos videos explicativos usando WordPress como gestor de contenidos web.
Tipos de vulnerabilidades
Cross-Site Scripting (XSS)
XSS, del inglés Cross-site scripting es un tipo de vulnerabilidad o agujero de seguridad típico de las aplicaciones Web, que permite a un usuario malintencionado inyectar código JavaScript en páginas web visitadas.
Un atacante puede realizar una petición post inyectando un string.
Para entender mejor cómo se explota mira este video explicativo
Multiple Cross-Site Scripting (XSS)
Se realizan múltiples ataques de XSS lo cual permite a un usuario malintencionado inyectar código JavaScript en páginas web visitadas.
Stored XSS (inyección de código almacenado)
Se trata de uno de los ataques más peligrosos ya que el código que inyecta el atacante se almacena en tu base de datos.
Los ataques almacenados son aquellos en los que el script insertado se almacena permanentemente en los servidores de destino, como en una base de datos, foro de mensajes, registro de visitantes, campo de comentarios, etc. La víctima recupera el script malicioso del servidor cuando solicita la información almacenada. Stored XSS también se conoce como Persistent o Type-I XSS.
Unauthenticated Stored XSS
Un usuario no autenticado o un usuario sin privilegios, que puede enviar un evento, puede insertar código JavaScript en la páginas web a través del navegador.
¿Quieres ver una Prueba de Concepto de cómo explotar esta vulnerabilidad? Pues mira este vídeo donde un usuario sin privilegios, que puede enviar un evento, puede insertar código JavaScript en la miniatura del mapa de Google Maps y la víctima será cualquier usuario que visite la web y vea el mapa.
SQL Injection
Aprovechando un fallo en la programación de la aplicación, un usuario puede ejecutar consultas en el navegador de la víctima. Estas consulta sirven para ver o recopilar información sobre la aplicación atacada y todos sus datos.
CSRF
Authenticated Stored XSS & CSRF
El CSRF (del inglés Cross-site request forgery o falsificación de petición en sitios cruzados) es un tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía.
Server Side Request Forgery (SSRF)
Se refiere a un ataque en el que un atacante puede enviar una solicitud elaborada desde una aplicación web vulnerable. La SSRF generalmente se utiliza para atacar sistemas internos detrás de firewalls que normalmente no son accesibles para un atacante desde la red externa. Además, también es posible que un atacante aproveche la SSRF para acceder a los servicios desde el mismo servidor que está escuchando en la interfaz loopback (127.0.0.1)
¿Viste los videos? Fácil ¿verdad? con esto queda demostrado que un usuario sin muchos conocimientos puede crear un grave problema en tu WordPress.
Como ya comenté, iremos añadiendo más vulnerabilidades y más videos explicativos. Manteneos atentos 😉
XSS, del inglés Cross-site scripting es un tipo de vulnerabilidad o agujero de seguridad típico de las aplicaciones Web, que permite a un usuario malintencionado inyectar código JavaScript en páginas web visitadas.
Cross-Site Scripting (XSS)
Un atacante puede realizar una petición post inyectando un string, por ejemplo un alert como el siguiente:
Aprovechando una vulnerabilidad en el código de alguna aplicación, plugin, plantilla de tema, etc., un usuario malintencionado puede introducir una cadena de código javascript para que se ejecute en el navegador.
A continuación te dejo un video explicativo para entender mejor cómo se explota esta vulnerabilidad.
Modificación de post de nuestros WordPress mediante ataques de «defacement»
Tras varios días de incidencias he decidido escribir este post para que no os preocupéis.
En los últimos días hemos recibido un número indiscriminado de incidencias de webs diciendo que su web había sido hackeada y, efectivamente, así era. Al comprobar los post de sus páginas veían que la última entrada que habían publicado era totalmente diferente, ahora, en el título se leía algo así como «Hacked By XXX», y el contenido o descripción e incluso la imagen destacada también habían cambiado. La verdad que he visto distintos y variados contenidos pero todos, en el fondo, vienen a ser lo mismo:
El «atacante» inyecta código en nuestra base de datos aprovechando una vulnerabilidad de la REST API implementada en la versión 4.7 de WordPress, consiguiendo modificar el contenido de un post.
¿Esto es grave?
Pues la verdad es que no es muy grave ya que un «defacement» no es más que una modificación o cambio intencionado en nuestras páginas, más concretamente y según «wikipedia»:
«Defacement es una palabra inglesa que significa desfiguración y es un término usado en informática para hacer referencia a la deformación o cambio producido de manera intencionada en una página web por un atacante que haya obtenido algún tipo de acceso a ella, bien por algún error de programación de la página, por algún bug en el propio servidor o por una mala administración de este.»
Sin embargo, nunca sabemos la modificación que pueden realizar y de momento, si simplemente se trata de modificar el contenido del post con la frase «Hacked by XXX», no hay más problema que lo feo que queda que en una web nuestra o de algún cliente, se pueda leer que la web esta hackeada en lugar de mostrar nuestro bonito y trabajado post.
¿Cómo lo arreglo?
Esta vulnerabilidad existe desde la versión 4.7 de nuestros WordPress y afecta a las versiones 4.7 y 4.7.1. El fallo de seguridad se solucionó en la versión 4.7.2 así que si estás leyendo esto y te ha ocurrido lo que aquí te indico, lo más seguro es que tengas tu instalación de WordPress desactualizada. Lo primero que te recomiendo es que repares el post afectado y actualices a la última versión de WordPress. También te recomiendo que actualices también los temas y los plugins (por descontado).
¿Cómo puedo securizar mi web para que no me vuelva a pasar?
Si eres seguidor de mi blog ya lo sabrás, sino te invito a visitar este post en el que pongo a tu disposición mi presentación en la WordCamp Cantabria 2015, donde te doy unos parámetros básicos para asegurar tu WordPress.
¡Genial! y ¿me aseguras que no me volverá a pasar nada parecido? pues la respuesta por desgracia es un ¡No! rotundo pues nunca estaremos a salvo de ataques al 100% pero sí que podemos ponérselo a los «malos» lo más difícil posible.
Si no quieres preocuparte por la seguridad de tu web y quieres dedicarte simplemente a tu negocio mi consejo es que contrates los servicios de un profesional de Seguridad en WordPress y por una pequeña cuota mensual, despreocuparte de la seguridad y dedicarte a lo que mejor sabes hacer.
Te dejo toda la información sobre el ataque en el siguiente enlace (en inglés) del blog de Wordfence.
Tomás S.
Valórame, es gratis, solo te cuesta un click [kkstarratings]
