martes, 31 de diciembre de 2013

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

domingo, 29 de diciembre de 2013

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.

jueves, 26 de diciembre de 2013

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

jueves, 19 de diciembre de 2013

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

martes, 17 de diciembre de 2013

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.

viernes, 13 de diciembre de 2013

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.

lunes, 9 de diciembre de 2013

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

lunes, 2 de diciembre de 2013

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