Bug Bountry: Recompensa por encontrar vulnerabilidades en Offensive Security

Oficialmente Offensive security ya tiene su propio programa de recompensa por encontrar vulnerabilidades en sus dominios y subdominios. Se puede reportar vulnarabilidades de cualquiera de las páginas del grupo Offensive Securty:

• offensive-security.com
• exploit-db.com
• kali.org
• backtrack-linux.org

Los precios oscilan desde los $200 hasta los $1000.

$200 Reward:
  Local File Disclosure
  Configuration File Exposure

$500 Reward:
  Persistent XSS
  SQL Injection
  Local File Inclusion

$1000 Reward:
  Remote File Inclusion
  Remote Code Execution

Esta es una pequeña tabla de precios. El único ataque que no se considera vulnerabilidad, son los ataque DDoS, obvio. Además se reservan el derecho a poder rechazar cualquier solicitud, ya que XSS reflejados, directora listíngs, CSRF, y vulnerabilidades menores no entran en el programa de recompensas.
Se podría decir que pagarán por aquellas vulnerabilidades donde realmente exista un riesgo de “hackeo”
Lo que dejan bien claro es que para reportar la vulnerabilidad y que esta sea pagada, todo debe de estar bien documentado.

Los pagos por encontrar estas vulnerabilidades se realizarán a través de Paypal, como en la gran mayoría de los Bug Bountry.

En la entrada que han publicado en su blog tenemos más información sobre cuales serán los criterios para evaluar las vulenrabilidades, y la filosofía que se debe de tomar a la hora de querer encontrar vulnerabilidades. Además también hacen una serie de recomendaciones muy a tener en cuenta.

Curso Penetration Testing With Kali Linux

Imagen 1: PWK: Penetration Testing With Kali Linux - Online course update

El próximo día 5 de Enero sale oficialmente el Curso de Offensive security con Kali Linux, el que anteriormente era el PWB, Penetration with Backtrack, con el que podías conseguir la certifición OSCP (Offensive Security Certified Professional). Desde el 2011 no se renueva el material de Backtrack con el que se podía obtener dicha certificación, sin embargo con la salida de Kali Linux, la gente de Offesive Security se han visto obligados a actualizar su material.
La noticia la hicieron publica ellos mismos en su blog, y en él nos cuentan la inminente llegada de este curso en el que se espera encontrar muchas novedades.

Tanto Backtrack como Kali Linux podrían tener un curso con miles y miles de página ya que cada una de estas distribuciones tiene herramientas muy sofisticadas para cada una de las ramas de la seguridad informática. Sin embargo en el anterior PWB, el curso contenía unas 350 pag. centrándose exclusivamente en los ataques más comunes y conocidos junto con las herramientas más usadas. Aún no se han dado detalles sobre que contenidos contendrá el curso de Kali Linux, pero se entiende que en el próximo PWK habrá cambios significativos. En la nueva sección que se añadió en Kali Linux sobre el Top Ten de herramientas utilizadas, se hace mención de Burpsuite, OWASP ZAP y aircrack-ng, entre otra. Estas herramientas no se mencionan en ningún momento en el anterior PWB, por lo que la renovación del curso promete importantes mejoras.

Este curso es el oficial para obtener la certificación (OSCP), no se trata de un simple libro o manual, el curso consta de este PDF con la explicación las prácticas, un acceso de 30 días (ampliable) a los laboratorios, y una conexión vpn a sus equipos de pruebas para hacer las prácticas, por último incluye la certificación, es decir, el examen. Que dicho examen es una prueba a realizar en 24h.

De momento sólo se ha publicado la noticia de la salida de este curso, lo que no se ha comentado es si el examen, o las tarifas cambiarán, entendemos que no.

OWASP ZAP: Así funciona su búsqueda automática de vulnerabilidades

En este artículo vamos a explicar como funciona la búsqueda automática de vulnerabilidades en OWASP ZAP, la alternativa a Burpsuite. Aunque mucha gente ya sabrá como funciona, habrá otra que no sepa que hace realmente OWASP ZAP cuando se buscan vulnerabilidades.

OWASP ZAP, es uno de los productos de OWASP, sus siglas ZAP corresponden a Zed Attack Proxy. Y nada mejor que la propia herramienta para explicarnos qué puede hacer. Aquí tenemos el mensaje de bienvenida cuando se abre:

<<Bienvenidos al OWASP Zed Attack Proxy (ZAP).
ZAP es una herramienta para pruebas de penetración, de fácil uso y con múltiples componentes, para encontrar vulnerabilidades en aplicaciones web. Ten en cuenta que sólo debes atacar aplicaciones para las cuales se ha sido previamente autorizado.>>

Poco más hace falta saber de cual es su cometido. Posiblemente su facilidad de uso sea el que le ha convertido en uno de los buscadores de vulnerabilidades en aplicaciones web más famosos. Ya que para empezar a usarlo, para encontrar vulnerabilidades rápidamente, tan sólo hace falta introducir la URL, y atacar.

Imagen 1: Mensaje de bienvenida de OWASP ZAP para empezar a atacar.

A partir de ese momento OWASP ZAP empezará a a buscar vulnerabilidades indiscriminadamente.
Lo primero que hará será recorrer todas las URL del sitio a través del Spider. De esta forma podremos tener un mapa de la web.

Imagen 2: recorrido de URL a través del Spider

Cuando se hace este recorrido por todas las URLs a través del Spider, se vana analizando cada una de las URL encontradas en busca de información sensible, y en caso de encontrar alguna URL que esté catalogada como sospechosa, se mostrará un alerta indicando su grado de riesgo, es decir, si la vulnerabilidad es grabe, media, o casi sin importancia.

Para entenderlo mejor; hay que saber que el Spider por su parte recorre todas las URLs de la página web dibujando un mapa del sitio, posteriormente las URLs se analizan en función de una serie de evaluaciones y criterios que viene preestablecidos por defectos en OWASP ZAP, los cuales determinar si la URL puede considerarse un riesgo, o no. Algunos de estos ejemplos de URL son URL del tipo:

• www.sitioweb.com/robots.tx
• www.sitioweb.com/admin
• www.sitioweb.com/usuarios
• www.sitiosweb.com/config.php
• etc.

Podemos imaginarnos que el listado de urls que pueden ser altamente peligrosas es muy grande.

Gracias a esto podemos tener una imagen global de como está formada la web y del tipo de programación web que tiene. Cuando el Spider finaliza su recorrido, automáticamente pasa a realizar un Escaneo Activo del sitio, de todas las URL que se encontraron anteriormente.

Es aquí donde OWASP ZAP hace mayor ruido en su ataque, ya que al tratarse de un Escáner Activo, lo que hará será probar todo tipo de ataques en las direcciones entradas. Esto implica desde una búsqueda de configuración en un simple parámetro de alguno de los archivos que compone la web, hasta ataques de SQL injection, XDD, LFI, RFL, etc.

Imagen 3: Escáner Activo de búsqueda de vulnerabilidades

Este escáner permitirá determinar si existe una vulnerabilidad o no, pero nunca atacará directamente sobre el servidor. El escáner, de la misma manera que el Spider, irá recorriendo todas las URL e irá probando “ataques” sin llegar a ejecutarlos.
Al finalizar este proceso, habrá terminado la búsqueda automática de vulnerabilidades.

Es en la parte de de Alertas donde podremos ver el resultado de todas las vulnerabilidades encontradas en función de su riesgo. Este panel donde se muestra las posibles vulnerabilidades y el riesgo que conlleva, muestra además, información sobre cómo se puede vulnerar, y qué medidas se pueden tomar para evitar que dicho fallo de seguridad sea vulnerable.

Imagen 4: Alerta de vulnerabilidades

En resumen, el ataque por parte de OWASP ZAP que permite la búsqueda de vulnerabilidades automáticas, funciona de la siguiente forma:

1. Se hace un recorrido de URL con el Spider
2. Se realiza un escaneo activo de todas las URLs obtenidas en el spider
3. Se analiza el contenido de cada URL y se muestran las alertas en función de la criticidad de la vulnerabilidad

Sistema operativo de Die Hard 4 (Jungla de Cristal 4)

En todas las películas estamos acostumbrados a ver sistemas operativos parecidos sacados del futuro. En muchos de ellos lo que se hace es crear un diseño que simule una interface de sistema operativo, pero realmente no se trata de ningún sistema operativo en concreto. Sin embargo en otras películas se suele utilizar alguna verisón de Linux con KDE, Fluxbox, o alguna otra interface de escritorio.
En la película Die Hard 4 donde todo gira alrededor de un Hacker, hay un momento en el que se ve al joven utilizando un equipo Apple pero con un aspecto completamnte distinto al de Mac OS X (además en ese instante se ve una ventana de Nmap corriendo)

Imagen 1: Fragmento de la película Die Hard 4 usando nmap

En xfce-look.org podemos encontrar exactamente el tema utilizado para crear esa interface tan "hacker" que se ve en la película.

Este tema de escritorio es para xfce, e instalarlo es tan sencillo como copiar la carpeta del tema en la ruta /usr/share/theme.
Luego aplicas la configuración y ... ya tendrás tu Linux como el de Die Hard.
Os dejo una captura de como quedó mi Linux con este aspecto:

Imagen 2: xfce con el Tema diehard

Escalada de privilegios: Utilman no es explotable en Windows 8

Adiós a a la famosa prueba de concepto de escalada de privilegios en Windows. Ya es casi un clásico en las auditorías de seguridad hacer una escalada de privilegios en Windows al renombrar un archivo.
Hasta la última versión de Windows 7, se podía renombrar el archivo utilman.exe, para invocar a un cmd y hacer un bypass en el Logon del inicio de sesión.
En el principio de los tiempos esto se solía hacer arrancando la máquina con un Live cd y accediendo a los archivos de windows para poder renombrar el utilman.exe.
Este archivo, o mejor dicho programa, es el encaragado de la parte de "accesibilidad" del equipo. Aquella que es utilizada para personas con algunas discapacidades.
La gran ventaja de este fallo de seguridad, era, y es, que al invocador un cmd, éste se hacía con permisos de administrador, por lo que no hacia falta eliminar la password actual del administrador, ya que podíamos crear un usuario nuevo, también con permisos admin.
El primer remedio que se puso para evitar este tipo de escalada de privilegios fue el capar los medio externos, es decir, no se permitía ni lectores de DVD/CD, ni conexiones a los Puertos USB, y nada que fuera externo, además de esta medida, el tener una contraseña en la BIOS reforzaba la seguridad en caso de que alguien se saltara la seguridad de los Puertos o los CDs.
El gran problema de esto en Windows 7 es que se podía seguir escalando privilegios sin tan siquiera necesitar de un Live CD. Para ello lo que se hacía, y se hace, es iniciar el equipo en "modo recuperación" para que éste verifique posibles fallos del sistema, cuando este proceso se está ejecutando se para y se revisa el log en un notepad, el cual permite a través de este notepad abrir un cmd y renombrar el utilman, o crear desde ahí mismo el usuario admin que queramos.

Todo esto con Windows 8 ha cambiado, ahora cada vez que se requiera hacer alguna función se solicitará un usuario con permisos Administrador para después hacer las típicas tareas de "reparación del sistema "opciones avanzadas," etc.
Por lo tanto, o tenemos de antemano la pass del admin, o tendremos que buscar alguna otra manera de escalar privilegios en Windows 8.

Bitacora I de Backox Linux - Iniciación al Pentesting

El día que me decidí a escribir un libro que tratara sobre seguridad informática y hacking ético, no me paré a pensar en todo el trabajo que con él me llevaría, el desarrollo, la maquetación del documento, la información a mostrar, etc. Somo muchísimos detalles los que hay que hay que tener en cuenta.
La gran problemática de querer hacer un libro de hacking, es que no eres el único en hacerlo, y que posiblemnete una de las información que fluya más rápido por Internet sean los “How to” de hacking, ya que a día de hoy cualquier material y contenido sobre cualquier técnica de pentesting la podemos encontrar buscando en Youtube y Google sin tener que hacer un búsqueda muy profunda.
Después de todo esto, ser original y creativo queda a un lado. Tratas de escribir lo que sabes de la mejor manera posible. En mi experiencia intenté apoyarme en otros libros para ver su forma de escribir y coger algunas ideas para mi Libro, sin embargo, en un primer momento no me me decantado por tomar la filosofía de los libros que leí para tener una referencia. Me fijé en que casi todos los libros que leí parar tomarlos como referencia, añadían demasiada información que, o bien no era necesaria desde mi punto de vista, o bien hacían que el libro fuera mucho más denso y más pesado de leer. En algunos capítulos de estos libros cuentan con mucho detalle algunas técnicas o materias, y en otras sin embargo no se centran tanto. Normalmente se centran más en explicar detalladamente la parte teórica que la parte práctica.
Todo sabemos que saber la teoría de una técnica es bonito, pero si no sabemos como llevarla a cabo, de nada nos servirá el saber que es un XSS, un SQL injection, o cualquier otra técnica hacking.
Fue por esto por lo que me decidí a escribir un libro que estuviera más enfocado a detallar más las partes prácticas que las teóricas. Al tomar esta filosofía el lector puede ir directamente al grano de lo que busca, viendo con Pruebas de concepto, algunas reales y otras en laboratorios, el como se realizan los ataques hacker.

Después de verme embaucado en mitad de libro y leyéndolo, me paré a pensar que si era un libro para la iniciación al pentesting quizás hubiera partes del libro que debería de explicar un poco más sin llegar a modificar la parte pirática. Un claro ejemplo de esto es la explicación de las herramientas, en el caso de nmap, explico como hacer un simple escaneo de puerto a un servidor, pero no entro en más detalles. Hablar de todas las posibles configuraciones de nmap, no es lo que busco, ya que daría para escribir un libro entero de nmap (ya existe un libro que habla sólo de nmap), lo que quiero decir, es que podría haber comentado donde encontrar nmap, cual es la forma en la que se pueden descubrir puertos, o como sacarle el máximo partido a nmap en ese momento. Siempre sin desviarnos del tema que tratamos en ese momento, no voy a explicar formas que tiene nmao de enumerar usuarios de un dominio si en ese momento el capítulo trata sobre descubrimiento de servicios y puertos de un servidor.

Teniendo las ideas clara de como quiero que termine siendo el libro, y teniendo ya los pilares fundamentales, voy a reescribirlo para que éste tome una forma más compacta y no tenga un aspecto de manual de usuario.
Con esto quiero aventurarme a decir, que es probable a que las entradas en el blog no sean tan regulares. Como contra partida comentar que, es posible que salga una versión de pago en formato ebook para iOS. Las razones para que están sean de pagos es porque al llevarlas a la plataforma de eBook de Apple se requiere un gran trabajo y esfuerzo. Toda la maquetación, el formato de las imágenes, etc, cambia radicalmente. En algunos casos se pueden llegar a incrustar vídeos en los capítulos o presentaciones más profesionales.
Esto es un idea que me gustaría realizar. Pero como ya he dicho antes, lo primero es volver a reescribir el libro, aunque no o haya terminado aun, para que éste tome una forma más seria y tenga menos aspecto de manual.

BackBox 3 - Iniciación al Pentesting (Parte 14)

Local File Inclusion: un paso más cerca del control

Local file inclusion (LFI ) se trata de una vulnerabilidad que permite al atacante subir una shell al servidor.

Esta shell no es más que un archivo que puede estar programado en distintos lenguajes como son PHP o ASP. El atacante buscará la manera de poder subir el archivo/shell a través de la web.

Normalmente este fallo de seguridad es debido a que los formularios de subida de archivos (documentos, imágenes, música... ) no hacen bien el filtrado del tipo de archivo o extensión que se sube. Esto se debe a un fallo de programación en el propio PHP o por una mala configuración en Apache.

Al disponer de una shell en la máquina de manera local podremos enviar casi cualquier comando como si estuviéramos delante del ordenador. Comentar que, a pesar de que se pueden lanzar comandos, no todos los comandos se podrán ejecutar, ya que para abrir determinados programas o acceder a algunos directorios y carpetas, se requieren permisos más elevados o de Root, sin embargo estos pocos permisos serán suficiente como para intentar una escalada de privilegios y así poder tener control total sobre el usuario y la máquina.

Imagen 1: Local File Inclusion

Si bien es cierto que en la mayoría de los casos este fallo se explota a través de formularios de subida, cada hacker se las ingenia para al final disponer de una shell en el servidor web independientemente el medio que haya utilizado.

LFI a Wordpress

Llegados a este punto podíamos haber vuelto a buscar vulnerabilidades, esta vez en Wordpress, con el fin de encontrar algún plugin que nos facilitara la subida de una shell. Sin embargo, puesto que ya tenemos un usuario Admin, nos aprovecharemos de éste para introducir así nuestra shell.

El proceso es sencillo ya que tan sólo nos va a hacer falta modificar algún archivo PHP de los que compone Wordpress. Al tratarse de uno de los archivos del propio Wordpress, el usuario Admin de Wordpress tendrá permisos suficientes para modificar dicho archivo y que éste se quede guardado en el servidor.

Para lograr nuestro propósito vamos a acceder al panel de administración con el usuario Admin (el cual ya creamos anteriormente a través de la BD) y vamos a buscar, entre toda la configuración del Panel Admin, la manera de modificar un archivo de los que compone Wordpress.

Una buena idea sería editar la plantilla/Theme que está instalado en ese Wordpress. Muchos de los archivos que componen el Theme están programados en PHP y se pueden editar.

Siempre que se hagan este tipo de modificaciones hay que tener cuidado con el archivo que se modifica, ya que si editamos un archivo que no debemos podemos dejar sin servicio la web.

Ahora que ya sabemos cual va a ser la forma de actuar y el proceso que se va a seguir, necesitamos descargar una shell para incrustarla en uno de estos archivos. En la web http://www.oco.cc/ podemos encontrar numerosas shell que nos servirán para hacer esto mismo. Cualquiera de ellas es válida.


Como ejemplo utilizamos la shell c99.php los pasos a seguir son:

• Descargamos la shell (c99, r57, c100...)
• Con algún editor de texto, abrimos la shell y copiamos su contenido.
• Buscamos un archivo php que se puede editar dentro del panel Admin de Wordpres.
• Pegamos el contenido de la Shell en el archivo de Wordpress. 

Imagen 2: Shell copiada en archivo author.php del Theme Twenty Twelve de Wordpress

Después de colocar la Shell en uno de los archivos sin que nadie note nada, nos falta saber la ruta exacta donde está alojada. En Wordpress, como en todos lo CMS, los archivos, directorios y rutas, son estáticos, por lo que podemos hacer dos cosas, 1-Bajarnos Wordpress y ver donde se encuentra la ruta, o 2-Buscar la ruta dentro del código fuente.

Quizás si hubiéramos modificado cualquier otro archivo de Wordpress nos hubiera hecho falta bajar una copia de Wordpress a nuestro equipo para ver la ruta, o utilizar un spider para recorrer todas las URL y ver así todos sus directorios (algo que puede estar capado si el administrador se ha preocupado de la seguridad de su sitio). En nuestro caso no va ser necesario todo esto, si vemos el código fuente de la página principal de Wordpress, podremos localizar fácilmente la ruta donde esta el Theme.

Imagen 3: Código fuente de la página principal de Wordpress

Lo siguiente será ver que comprobar que todo ha salido como esperamos y que al introducir la ruta donde hemos guardado la Shell realmente se muestra el panel de configuración de la Shell c99.

La ruta entera quedaría de la siguiente manera:

http://192.168.233.211/wordpress/wp-content/themes/twentytwelve/author.php

Imagen 4: Shell c99: Panel de Administración

BackBox 3 - Iniciación al Pentesting (Parte 13)

Penetrando en Wordpress

Existen escáner de vulnerabilidades web capaces de encontrar vulnerabilidades en Gestores de Contenido tipo CMS como Wordpress, Joomla, etc, pero además, por otra parte también existen herramientas especializadas, pensadas para analizar y encontrar todo tipo de vulnerabilidades en Joomla y Wordpress, como es el caso de wpscan para Wordpress, o joomscan para Joomla.

Estas herramientas son capaces de analizar todo tipo de plugin, componentes, módulos, widgets... con el fin de determinan cuales de ellos están instalados, cual es su versión y si es vulnerable o no.

Esta vez no vamos a mostrar ninguna de estas herramientas ya que anteriormente hemos obtenido acceso a la Base de datos del servidor donde se aloja también la Base de datos del propio Wordpress, pero está bien saber que existen para en un futuro poder utilizarlas en nuestras auditorías de seguridad.

Creando un nuevo usuario en Wordpress a través de mysql

Ahora que tenemos acceso a la Base de datos probaremos a crear un usuario con permisos Admin dentro del panel de administración de Joomla.

El motivo de hacer esto y no extrae directamente la contraseña de alguno de los usuarios que ya exista en Wordpress, es porque el cifrado de la contraseña de Worpdress es muy fuerte, y tardaríamos meses en poder Crackear el Hash.

Para poder crear un nuevo usuario de Wordpress a través de la Base de datos, debemos de insertar una sería de filas y campos dentro de la tabla wp-usermetada y wp-users. Estas dos tablas son las que contienen la información de los usuarios y sus permisos.

Wp-users

Esta tabla contiene los campos de toda la información del usuario:

• Nombre
• Contraseña
• Nickname
• Email de usuario
• Estado
• Etc

Wp-usermetada

Sin embargo esta otra tabla contiene los datos necesarios que otorga al usuario ciertos permisos y privilegios, como son:

• Editor
• Autor
• Administrador
• Invitado
• Etc

Quizás una de las cosas más importantes a tener en cuenta es el nombre que elijamos para el nuevo usuario que crearemos. Hay que procurar pasar lo más desapercibido posible.

Inventarse nombres del tipo, user_tmp, 001_tmp, admins, usr... pueden ser una buena idea para que el administrador del sitio apenas se de cuenta de que existe un nuevo usuario. El nombre que se pone es de esta índole para que en caso de que alguien lo vea tienda a pensar que es un usuario del propio sistema, o que fue creado junto con la instalación de algún componente o plugin.

Imagen 1: Tabla wp_users. Contiene los datos del usuario

Para la parte que contiene los privilegios de los usuarios, tan solo vamos a fijarnos en cual de los usuarios que ya existe es administrador para copiar los mismos valores en una nueva fila y asociarlos al ID del usuario que hemos creado.

Imagen 2: Tabla wp_usermetada. Contiene los datos que otorgan permisos al usuario.

Es decir, el primer paso es añadir una nueva fila en la tabla wp_usuers, tal y como muestra la ilustración 21. El segundo paso es insertar dos filas más en la tabla wp_usermetada, las cuales asociaremos al ID del usuario que creamos anteriormente en la tabla wp_user.

Con esto ya podríamos ir a la parte de administración de Wordress e intentar ingresar con el nuevo usuario que hemos creado.

Imagen 3: Login del backend de Wordpress

Por defecto en la ruta con la que accederemos a Wordpress se ubica en www.sitio.com/wp-admin.

Si todo ha ido bien ya podemos empezar a navegar por todo el sitio en busca de más información relevante, o en busca de nuevas proezas que nos ayuden a adentrarnos un poco más en la infraestructura de la empresa.

Imagen 4: Panel de administración de Wordpress

BackBox 3 - Iniciación al Pentesting (Parte 12)

Acceso al servidor

Existen muchas formas de poder acceder al servidor una vez que se encuentra una brecha de seguridad en el sistema. En la gran mayoría de las ocasiones el acceso al servidor será de manera indirecta para ir escalando privilegios.

Es muy común en un ataque la escalada de privilegios.

Escalada de privilegios

Se conoce como escalada de privilegios la técnica que permite ir adquiriendo más permisos sobre un sistema informático. Algunos casos típicos es cuando un atacante obtiene la cuenta de usuario de un sistema sin apenas privilegios, y a partir de éste ir accediendo a otros sistemas hasta hacerse con algún otro usuario Administrador que le otorgue más permisos sobre su propio sistema o sobre otro.

Esto se emplea normalmente para conseguir un control total sobre la máquina que se quiere atacar.

Acceso indirecto al servidor: Base de datos

En base a la información extraída del archivo de configuración de Wordpress podemos acceder y hacer un recorrido por servidor que almacena la Base datos, con el fin de ver que otras Bases de datos, tablas, y usuarios existen en él.

Aunque esto mismo se podría haber hecho anteriormente con SQLmap, la navegación en un entorno gráfico mediante un cliente de sql es mucho más amigable e intuitiva a la hora de seguir buscando información sensible que nos permita ir escalando privilegios.

El archivo de configuración wp-config.php de Wordpress permite conectar la página web montada sobre wordpress con la Base de datos. Para ello este archivo guarda las credenciales del servidor contra el que se autenticará, así como la Base de datos a la que debe de atacar.

Para realizar la conexión contra el servidor de Base de datos se ha utilizado el cliente Dbeaver (http://dbeaver.jkiss.org/) multiplataforma y operativo para todos los gestores de base de datos conocidos.

Imagen 1: Cliente DBeaver. Accediendo al servidor de Base de datos

Vulnerar servidores Zabbix con Armitage en 2 Clics

Lo que voy  contar no es nada nuevo, no por ello quiere decir que no sea importante.
Zabbix, el famoso Software Open Source para la monitorización de equipos, como cualquier otro software, tiene brechas de seguridad. Y esta vez le ha tocado a él, nos hemos basado en una versión de Zabbix no actualizada, pero que sigue existiendo en muchos servidores, ya que los administradores no la actualizan, ya bien sea por desconocimiento de las vulnerabilidades, o por problemas de infraestructura. El motivo para tener este software, y cualquier otro, desactualizado, implica un grave fallo de seguridad para todos.

Si hacemos una búsqueda en Armitage para ver que podemos encontrar de Zabbix, vemos un llamativo exploit zabbix_sqli.

Imagen 1: Buscando exploit en Armitage para Zabbix

AL abrir la configuración de este exploit vemos como se trata de un exploit que vulnera la versión de Zabbix 2.0.8 mediante un SQL injection.

Imagen 2: Información y configuración del Exploit

Sabiendo lo que es capaz de hacer y a que versiones afecta, basta con buscar nuestro objetivo en Shodan e intentar lanzar el ataque.

Imagen 3: Servidores Zabbix encontrados por Shodan

Es cierto que los servidores Zabbix que encontró Shodan tenían distintas versiones entre sí, pero a nosotros sólo nos hace falta uno que coincida con la versión 2.0.8.

El resto es pan comido, introducimos la IP del servidor en el RHOST de Armitage, como viene siendo habitual para cualquier configuración de una exploit en Metasploit, y esperamos a que éste haga sus funciones.

Cuando termine veremos el resultado de sucesfully.

Imagen 4: Servidor Zabbix Vulnerado,

Ahora que ya tenemos el servidor vulnerado podemos lanzar un Shell y tener control total sobre la máquina.

Imagen 5: Inyectando al servidor con una Shell

Lo que haga cada uno dentro de la máquina es infinitamente proporcional a su imaginación. Yo para hacer la prueba el lanzado un simple ls -l

Imagen 6: Shell remota en el servidor vulnerado

Todo este proceso se basa en un fallo de seguridad que permite la ejecución de código mediante una inyección SQL. Este fallo ya se hizo público y se puede encontrar su exploit en exploit-db. Armitage lo único que nos permite es ahorrarnos la tarea de tener que buscar de manera manual dicho fallo.
CVE: 2013-5743

En resumen, estos dos pasos se basan en:

1. Abrir Armitage
2. Buscar el exploit
3. Lanzarlo
4. Enviar una shell al server

Si tomas precauciones practicando sexo, con Internet haz lo mismo!!

El 99% de los usuarios toma internet como un juego…

…¿que es lo que no sabes y que deberías de tener en cuenta si no quieres sufrir una verdadera pesadilla informática?


Excelente artículo en el que puede participar gracias a la entrevista que me hizo Daniel Koox para su blog.

En él se habla de la importancia de la seguridad informática en internet, de si realmente la gente está concienciada de todos los datos que circulan en la red, y sobre que medidas podemos tomar para evitar en la medida de los posible que un hacker pueda robar tu cuenta de facebook, twiter, etc, o de que prácticas tomar para estar tranquilos a la hora de hacer una compra online.

Imagen 1: Extracto de la entrevista

Entrevista: Si tomas precauciones practicando sexo, con internet haz lo mismo!!
Google+: +Daniel Koox
Twitter: @danielkoox

Los tesoros de Google Dorks

Hace poco un amigo me hizo una entrevista en uno de los artículos de su página web, en el que hacía especial hincapié en lo importante que es la seguridad en internet.
Parece mentira que ha día de hoy, con lo informatizado que está todo, aún sigamos descuidando tantísimo la seguridad.
Ya hemos visto muchas veces lo fácil que puede llegar a ser para un hacker el hackear una web.
Aquí otro claro ejemplo del que no nos cansamos de enseñar una y otra vez.
Dando una vuelta de nuevo por http://www.exploit-db.com encontramos un gran número de Google Dorks. Algunos más recientes que otros, pero todos hacen el mismo daño.

Submited: 2004-05-13
Este Google Dorks que lo que hace es buscar los log de Putty, fue reportado en el 2004, sin embargo seguimos teniendo resultados muy recientes como  por ejemplo este del 2011.

Imagen 1: Búsqueda de Log en Google. Resultado del 2011

Imagen 2: Datos del archivo .log de Putty

O este otro del 2013 donde se puede ver muchísima información de gran utilidad para aquel que quiera atacar al servidor...

Imagen 3: Búsqueda de logs de Putty en el año 2013

Imagen 4: Archivo del Log de Putty

Google search: filetype:log username putty


Submited: 2012-05-15
Este otro Google Dorks hace una búsqueda de aquellas web que fueron vulneradas mediante la subida de una Shell en asp.net

Imagen 5: Listando directorios del servidor donde se aloja la Shell

No sólo no somos conscientes de lo importante que es la seguridad, sobre todo de cara a los desarrolladores, si no que además de que la web es hackeada, parece como si ya estuviera todo hecho, y nadie más va a entrar a romperla porque ya la a roto otro. No nos engañemos, estas web que tienen una shell que fue subida por otra persona, y que están "como olvidadas", a una tercera persona le podrá servir para alojar en ese servidor otras shell y así hacer RFL (Remote File Include), o cualquier otra cosa que se le pase por cabeza. A fin de cuentas tener una shell en un servidor, es como ser administrador del mismo.

Google search: intitle:awen+intitle:asp.net

A mí solo me ha hecho falta echarle un vistazo a la Base de datos de exploit-db para ver algunos ejemplos...

Imagen 6: Google Hacking Database

BackBox 3 - Iniciación al Pentesting (Parte 11)

Capítulo 4 Post-explotación

Introducción

La post-explotación de los sistemas en una auditoría de hacking ético no es más que aquello que podemos realizar una vez vulnerado los sistemas. Es decir, una vez que ya tenemos control sobre un equipo intentar vulnerar otros equipos de la red.

Durante todo el libro se está realizando el ataque sobre una misma máquina, por lo tanto, y para que todos entendamos bien el concepto de post-explotación seguiremos haciéndolo de igual forma, sobre la misma máquina.

Como ya hemos visto, tenemos acceso sobre la BD, y además tenemos unas passwords que se pueden ver sin necesidad de Crackearlas.

Al principio del Tema 1, se vio que la recogida de información era muy importante para después poder realizar un ataque. Esto nos va a permitir vulnerar aún más la BD.

Si recordamos, la máquina que estamos atacando, que no es más que un servidor web, uno de sus apartados era un blog basado en Wordpress. Vamos a aprovecharnos de la brecha de seguridad del MySql para hacernos con el control total de la base de datos a través del archivo de configuración del propio Wordpress.

Esto lo podremos hacer con SQLmap descargándonos o mostrando (como prefiramos) el archivo wp-config.php el cual contiene el nombre de usuario y la contraseña con la que Wordpress se conecta a la BD.

Lectura de archivos con SQL

Otras de las características de SQLmap de la que sacaremos gran partido es la posibilidad de leer ficheros del servidor o máquina remota. Observando la ayuda que nos ofrece SQLmap vemos que sus usos y funciones son casi infinitos. Ahora bien, fijémonos en el parámetro –-file-read=

Imagen1: Opciones para leer o descargar archivos con sqlmap

Este parámetro nos permite leer un archivo al lanzar el comando #sudo sqlmap -u http://website.es/actualidad/evento.php?id= –-file-read=/etc/passwd
Es lo mismo que si hiciéramos un #nano /ruta/del_archivo.txt

Esto nos permitirá visualizar el archivo en nuestra máquina. Com ya he comentado, sabiendo que nuestro objetivo tiene un Wordpress montado, y que éste guara la información del nombre de usuario y las password de la base de datos a la que se conecta, podremos penetrar en este servidor. Para ello sólo debemos de leer el archivo wp-config.php

#sudo sqlmap -u http://website.es/actualidad/evento.php?id= –-file-read=/opt/lammp/sitio/blogs/2013/wp-config.php

Imagen 2:  Archivo de configuración de Wordpress obtenido con sqlmap

Leyendas urbanas que hablan de lo fácil que es Hackear un iPhone

Si hacemos una búsqueda en Youtube veremos miles de videos donde se muestra lo “fácil” que puede ser robar información en un terminal iOS. Lo cierto es que para poder realizar esa tarea que a simple vista parece que con 2 Clics de ratón vamos a poder hacerlo, pues, no es así.
En los últimos días también hemos visto en la TV ha grandes expertos de Seguridad informática hablando, o mejor dicho, metiendo el miedo a la gente, de lo fácil que podría ser que un hacker entrara en tú móvil y a través de éste se metiera en tu cuenta de Facebook, o de cualquier otra cuenta.
Esta técnica de Robo de identidad se conoce con el nombre de Hijacking, y en el caso de iOS consiste en copiar la Coockie que almacena los datos de la cuenta que tiene inicia la sesión en la aplicación (Faceboo, Twitter, instagram… etc) para introducirla en otro terminal y así hacer creer a la aplicación que ya estabas logado, eso sí, con la cuenta de la otra persona.
Hasta aquí es lo que normalmente se suele explicar para demostrar que un iPhone es vulnerable, pero en realidad, para poder llegar al objetivo de tener esa Cookie o de poder entrar en el terminal, se deben de cumplir una serie de condiciones.
De primeras tenemos que disponer del dispositivo fisicamente, olvidaros de que se puede entrar en un iPhone a través de Wifi, por que eso es completamente imposible a no ser que el iPhone o iPad tenga el Jailbreak hecho y aun mantenga el servicio SSH corriendo con el usuario y contraseña por defecto, cosa que en las últimas versiones de Jailbreak no viene activado el SSH.
Sabiendo que no podemos entrar al dispositivo por Wifi, y que debemos de tenerlo en la mano para entrar a sus archivos, nos hace falta un ordenado con un programa del tipo iExplorer, para poder navegar a través de los archivos y carpetas que él contiene. Sin embargo esto tampoco es lo más sencillo del mundo.
Apple ha establecido una serie de medidas de seguridad para que cualquier persona que conecte el terminal al ordenador no tenga acceso completo a sus datos. En verisones anteriores sí permitía dichos accesos, pero a día de hoy, cuando conectamos un terminal al ordenado, tanto el iPhone como el iTunes nos pregunta si queremos “Confiar en este ordenador”.

Para poder confiar en el terminal debemos saber la código de desbloqueo, ya que si no no podremos aceptar el “Confiar en este ordenador”
En el caso de tener itunes instalado, la primera pregunta es si queremos permitir el acceso a la información de ese dispositivos desde esa cuenta de Apple ID, (otro problema añadido, tu cuenta la tiene Apple, y el dispositivo queda registrado también en sus servidores).

Imagen 1: Aviso de iTunes preguntando si queremos tener acceso a la información de ese dispositivo

Tal y como he dicho antes, para poder acceder al dispositivo, en caso de que queramos saltarnos el paso de iTunes para ahorrar tiempo y para evitar el lio de la cuenta de Apple ID, nos saltará el Pop-up para poder confirar en el ordenador.

Imagen 2: Mensaje de espera hasta que el dispositivo acepte la relación de confianza con el equipo

Imagen 3: Mensaje de alerta del iPhone para confiar en el ordenador al que está conectado por USB

Lo que pasaría si intentamos ver los archivos sin establecer esta realación de confianza es que el programa que estemos utilizando no detectará ningún dispositivo contectado y por tanto no veremos absolutamente nada.

Imagen 4: iExplorer no muestra ningún dato sin que el iPhone no confie en el ordenador

Ahora bien, si hacemos todos estos pasos, evidentemente sí tendremos acceso al terminal y junto a todas sus carpetas y archivos. A partir de aquí si podríamos robar la información del dispositivo.

Imagen 5: Acceso a un dispositivo iOS a través de iExplorer tras confiar en el ordenador

Creo que son demasiados pasos los que se han saltado aquellas personas que demuestran lo fácil que es el robo de una simple Cookie en un iPhone. Sí que es cierto que en versiones anteriores de iOS esto si se podía hacer ya que estas verificaciones y relaciones de confianza entre el iPhone y el ordenador no estaban establecidas entre las políticas de Appe, y ello permitía que el acceso al terminal fuera menos complicado. Aún así se necesitarían demasiadas condiciones…

En cuanto otro tipo de Hack que también se ha visto atacando directamente a los Backup que realiza iTunes, he de decir que para evitar esto se puede poner contraseña a dicho Backup para que nadie pueda acceder a los datos de estos Backups, además de que podríamos indicar a nuestro dispositivo que el Backup se guardara en iCloud. Estos dos Pasos son primordiales para impedir que alguien entre en nuestros datos. Al establecer una contraseña al Backup, ésta queda cifrada, y si además el Backup esta almacenado en iCloud, por mucho que alguien consiga acceso a nuestro ordenador, y llegue hasta la ruta donde se almacenan estos datos, o bien no verá nada, o no podra acceder por la contraseña que establecimos.

Todos ls videos de la Navaja Negera Conference 3ªEdición

Ya se han publicado todos lo videos de las 3 eidción de la Navajas Negras. Si fuistes uno de los que no pudo ir puedes estar tranquilo, la organización de la conferencia se ha encargado de subir todos los videos a YouTube, junto con las diapositivas.
Yo desafortunadamente tampoco pude ir, yo ya le he estado hechando un vistado al gran contenido que hay en estos videos.

Imagen 1: Inauguración de la NN3d

Charlas como las de Pepelux hablando de la Deepweb, o de Lawwait enseñandonos su propia herramienta de forensic para iOS.

Imagen 2: Cartel de la 3ªEdición Navajas Negras.

Desde aquí quiero dar la enhora buena a los organizadores cr0hn y s4ur0n por el gran esfuerzo que están haciendo para llevar acabo un evento tan importante como este. Recordar a todos que el disponer de un evento de estas caractrísticas en España no es nada fácil encontrarlo. Hasta ahora estabamos acostumbrados a escuchar nombres como la RootedCon o la NoConName, pero desde luego siendo esta la 3ªedición de navaja negra, tenemos claro que vino para quedarse, y que aun nos queda muchas otras ediciones por disfrutar.

Visualsniff+TOR+Vidalia+ProxySocks=Anonimato en Mac OS X

Visualsniff es una herramienta para monitorear todas las conexiones que realiza tu equipo hacia el exterior. Es la alterativa a Etherape para Mac OS X. Nos permite saber si cuando utilizamos Vidalia para navegar a través de la red TOR nuestras conexiones enrutan realmente a hacia sus servidores Proxys evadiendo así el dejar rastro de nuestras conexiones reales.

Ya hemos explicado en otras ocasiones como navegar de manera anónima al 100% sin pasar por los servidores DNS que serían los únicos que podrían dejar rastro si navegamos sólo y exclusivamente a través de Vidalia sin utilizar ninguna otra herramienta, ni ninguna otra configuración. En la entrada anterior mostramos 3 alternativas proxy para permanecer anónimo, pues bien, para estar seguros de que todas nuestras conexions viajan a través de TOR, incluida la salida de los DNS, hemos configurado el proxy Socks de la configuración de Red. Una caracterñistica que viene por defecto en Mac OS X y que nos permitirá indicar por que proxy enviar las solicitudes de nuestro equipo. En este caso redirigiremos todas estas coenxiones hacia la direción 127.0.0.1 por el puerto 9050 para que éstas salgan a la red de TOR medíante vidalia.

Imagen 1: Configuración Proxy Socks en Mac OS X para redirigir el tráfico a través de TOR.

En resumen: Configuramos el proxy de nuestro equipo, arrancamos Vidalia, arrancamos Visualsniff, y comprobamos que ninguna de nuestras conexiones deja rastro de los DNS o de la IP que ofrece nuestro ISP.

Imagen 2: Monitor de red VisualSniff. Asegurando que nuestras conexiones no dejan rastro

En la imagen anterior podemos apreciar que VisualSniff muestras muchas conexiones además de las de nuestra máquina, y eso es, porque como su propio nombre indica, snifa todas las conexiones de la red, sabiendo así que conexión hace cada máquina de LAN. Abrá que tener más en cuenta esta herramienta para futuros análisis de la red...

Trabajar con Nmap y Keepnote

En otra ocasión ya hablé de que es Keepnote y para qué sirve. Ayer navegando por las noticias de Twitter encontré una gran extensión que permite importar los resultados de Nmap en Keepnote. Esto nos permitirá tener toda información bien organizada. El aporte lo ha realizado @felmotor, un desarrollador de Jaén y que no ha reparado en hacer un script en python para terminar conviertiendolo en una favolusa extensión para keepnote. Nosotros ya lo hemos probado y nos ha impresionado bastante.

La instalación es sencilla, en 4 pasos podemos empezar a trabajar sobre keepnote con los resultados de nmap.


Instructions

1. Open your keepnote.
2. Navigate to "Edit -> Preferences -> Extensiones"
3. Click on "Install new extension" and open the file import_nmap.kne.
4. Once it is installed correctly you can navigate to "File -> Import Notebook -> Import Nmap XML" and select your XML file.

Cuando se importa la información obtenida con Nmap, Keepnote pinta de colores los resultados para siendo todo más gráfico e intuitivo:

IP:

Color Red: Is Down
Color Green: Is Up

Ports:

Color Red: Closed
Color Orange: Filtered
Color Green Is open

Imagen 1: Resultados obtenidos con Nmap, importados en Keepnote

Al ver este gran aporte decidí darle la enhorabuena y las gracias a @felmoto por el trabajo realizado, a lo que él me contestó que pronto tendrá nuevas mejoras.

Imagen 2: Twitter del desarrollador

Sabiendo que esta extensión permite importar el xml obtenido por nmap cuando se exportan sus resultados, no sería de extrañar que además de esta extensión, se creen otras para Nessus, owasp , etc ...
https://github.com/felmoltor/Keepnote_import_nmap

Tres aplicaciones proxy para navegar de forma anónima en Mac OS X

Ha estas alturas todo aquella persona que quiera navegar de forma anónima y que haya hecho una breve búsqueda en Google sabrá que con la aplicación Vidalia para TOR es sumamente fácil.
Sin embargo TOR y Vidalia no garantizan el anonimato 100%. TOR no es más que un proxy por donde enviar las solicitudes de nuestra aplicación, las conexiones DNS no las enruta. Para que todo el tráfico incluido el de las DNS fuera filtrado por TOR tendríamos que configurar las conexiones por Socks. Y para hacer esto existe alguna herramienta que nos facilita el trabajo.

Proxycap

Una aplicación de pago que permite configurar todos los proxy que nosotros queramos, añadiendo la peculiaridad de que permite redirigir el tráfico de una aplicación o de todas, por un porxy determinado. Además también permite enlazar proxys, de tal manera que el anonimato sea aún más efectivo. Combinando Proxycap con TOR podemos obtener una navegación anónima más fiable.
Como ya podemos imaginar, gracias a sus configuraciones se puede hacer prácticamente cualquier tipo de Tunneling.

Image 1: Configuración Proxycap

Por otra parte disponemos también de otra herramienta de pago llamada Netshade

NetShade

Esta apreciación es tan sencilla como se ve en la imagen. Sin embargo es mucho menos potente que la anterior y algo más automatizada. En ella encontramos dos configuraciones claves, VPN Server y Proxy Server.

Ambas nos van asegurar que nuestras conexiones sean seguras. Sin embargo todo tiene un precio, esta aplicación también es de pago y está algo más limitada ya que los proxys ya viene configurados por defecto y la subscripción viene dada en función del tiempo y de la cantidad de proxy que quiramos contratar. Admás de que las conexiones las hace a través de una lista propia de proxys, y no brinda la posibilidad de enlazar con TOR.

Imagen 2: configuración disponible en Netshade

Por último hablaremos de la propia configuración proxy que se puede hacer en los ajustes de REd de Mac OS X

Configuración proxy Mac OS X

A través de esta configuración se puede reenviar todo el tráfico por los servidores proxy de Tor o de cualquier otro servidor. Evitando así dejar nuestro rastro DNS en los logs de los IDS. Es simple y sencillo. Además se puede configur la navegación por proxy de diferentes servicios además de la configuración Socket. como puede ser FTP, HTTP, RTSP …

Imagen 3: Configuración proxy que viene por defecto con Mac OS X

¿Por qué un Hacker no roba cuentas de correo, Facebook y Twitter?

Sencillamente un Hacker no se dedica a robar cuentas de ningún tipo puesto que no entra dentro de la ética de cada Hacker. Hay una ética no escrita por la que los Hacker se rigen. Se sabe de esta ética que ningún Hacker se nombrará a si mismo Hacker, que un Hacker nunca alardeará de sus hazañas o hechos. Y que un Hacker nunca utilizará sus conocimientos para su beneficio o el beneficio de otros.

Esto último es la que hace referencia a la de robar las contraseñas de cualquier cuenta.

Todos estamos acostumbrados a entender que un Hacker es capaz de conseguir la contraseña de cualquier cuenta, sin embargo no caemos en la cuenta de que esto no quiere decir que lo vaya hacer si alguien se lo pide.

Una de los motivos más contundentes por los que un Hacker no va a hacer tal encargo es porque en sus planes no entra el violar la privacidad de una persona.

Hay que dejar bien claro que hablo del Hacker de guante blanco. Por supuesto que hay otro tipo de Hacker denominados Blackhat que si se dedican a robar cuentas de correo. Pero cuidado, tampoco lo mal interpretemos, cuando hablamos de un Hacker mal intencionado éste tampoco roba la cuenta de una persona en particular. Si no que lo hace a gran escala y posiblemente para venderlo en el mercado negro.

Cada vez es más frecuente encontrarse con trabajos “sucios” donde hay gente que paga por 1 millón de cuentas de correo para después hacer Spam, o venderlas a la competencia, y aquí, es donde entra el Hacker “malo” ha hacer su función. Cuando un Hacker ofrece cuentas de usuario a cambio de dinero, no quiere decir que haya ido ordenador por ordenador instalando un Keylogger. Así sería tal y como se haría si quisiéramos en concreto al información de una persona. Cuando se habla del negocio negro, se buscan fallos en las BBDD de datos del servidor de la empresa que se está atacando para poder extraer el mayor número de emails, de nombres de usuario o de password posibles. Aunque existen otras técnicas como crear Botnet, las cueles se dueñaran de un montón de máquinas para recopilar información para que después esta información sea vendida en el mercado negro.

Quizá sea este uno de los motivos por lo que los Hacker no se dediquen a robar cuentas personales.

¿Es fácil Hackear Joomla?

La respuesta rápida es NO. Para hackear Joomla se requieren una serie de condiciones muy específicas. Joomla es un gestor de contenido que suele tener unas estrictas medidas de eseguridad en su desarrollo. Si bien es cierto que se han encontrado vulnerabilidades en todas sus versiones, es más seguro de lo que pensamos.
En la gran mayoría de vulnerabilidades que se encuentran en Joomla, estas no son propias del Gestor de contenidos, si no de módulos, componentes o plugin de terceros. Por este motivo es más complicado vulnerar Joomla. Cuando se lanza un scan con Joomscan, las vulnerabilidades encontradas, por lo general, son siempre en versiones muy antiguas, y en componentes también muy antiguos.
Si un webmaster tuviera su sitio web montado con Joomla, y este estuviera debidamente actualizado, no tendría porqué preocuparse de que algún individuo tomase control de su página.
Hace mucho tiempo, en la versión 1.5 de Joomla yo mismo pude sufrir un Defacement. Cuando lo hicieron el susto es bastante grande ya que lo primeros que ves es una imagen enorme en tu página principal, de un grupo de hackear. El miedo te lleva a pensar que tal vez se adueñaron de algo más, además del defacement que hicierons. Tras investigar un poco descubrí que eran unos “hacker” un poco peculiares, se dedicaban a buscar ciertas vulnerabilidaes en Joomla a través de Google, y así defacementar el mayor número de sitios posibles.
Tras actualizar mi Joomla, todo quedó solucionado.
Por otra parte visto desde el punto de vista de un hacker, atacar a un sitio web concreto montado con Joomla y utillizando Joomscan, es mucho más complicado de lo que se cree.
Haciendo unas pruebas de estrés contra un Joomla con la versión 1.5, reportó tan solo 3 vulnerabilidades. Teniendo en cuenta que Joomla ya está por la versión 3, son muy pocas.

Imagen 1: Vulnerabilidades encontradas en Joomla 1.5 con Joomscan

Sin nos fijamos en las vulnerabildiaes encontradas, la primera de ellas hace referencia a un Bypass en un componente para enviar mails, pero para esto debemos de disponer de una cuenta de usuario. En la segunda vulnerabilidad se necesita también una cuenta de usuario, ya que afecta a TinyMCE, que si no me falla la memoria es un plugin para hacer el editor de artículos más potente. Por tanto también quedaría descartada.
Por último tenemos una vulnerabilidad Cross Site Request Forgery que afecta a la parte de la administración. Esta sería de las tres la más crítica si no fuera porque es la que más desarrollo lleva y porque afecta a la versión 10.3. Por lo que también queda descartado.

En definitiva, un componente Jooma bien actualizado es bastante seguro. Eso no significa que haya una persona esperando a que nuestro componente “X” esté desactualizado para aprovecharse de “X” vulnerabilidad. Así es como funcionan mucho de los ataques que se producen en Internet.