viernes, 29 de noviembre de 2013

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

jueves, 28 de noviembre de 2013

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

miércoles, 27 de noviembre de 2013

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

martes, 26 de noviembre de 2013

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

jueves, 21 de noviembre de 2013

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.

martes, 19 de noviembre de 2013

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.

domingo, 17 de noviembre de 2013

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...

martes, 12 de noviembre de 2013

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

jueves, 7 de noviembre de 2013

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

martes, 5 de noviembre de 2013

¿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.

lunes, 4 de noviembre de 2013

¿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.

domingo, 3 de noviembre de 2013

Libro: Pentesting con Kali

Pentesting con Kali es el primer libro que salió a la luz tras la publicación de la primera versión de Kali Linux. El que fue el sucesor de Backtrack. Tras una larga temporada trabajando con Backtrack, Offensive security decidió darle una vuelta de tuerca y rediseñar por completo su sistema operativo.
Tras el lanzamiento mundial del nuevo sistema para pentester, pocos meses después salió a la venta un Libro enfocado a la seguridad con Kali.
Puesto que Kali Linux es la distribución con el mayor número de herramientas para pentesting que existe en el mercado, el libro está basado práticamente en su totalidad a detallar  las herramientas necesarias para realizar una auditoría de seguridad en cada una de sus ramas. Realizando pruebas de concepto apra que el lector comprenda bien el funcionamiento del programa que se esté explicando.

En este Libro podemos encontrar ejemplos de SQLinjection, LFI, Footprinting, Fingerprinting, Análisis frorense, Hacking Wifi, Ataque de contraseñas, y muchas más técnicas.
Sin embargo uno de los motivos por los que me lleva a recomendar este libro es porque se explica de manera práctica y teórica, el como se hace una auditoría de seguridad, que pasos seguir, y  que tácticas y técnicas se deben utilizar.

Lo podéis encontrar en la editorial 0xword