Publicada la OWASP Testing Guide v4

  • 0

Publicada la OWASP Testing Guide v4

Introducción

El pasado 17 de Septiembre se presento oficialmente la versión 4 de la Guía de Testing de Owasp. La verdad es que la noticia paso sin pena ni gloria por los diferentes blogs y paginas dedicadas a la seguridad. Creemos que es una noticia muy importante y no se ha dado la transcendencia que merece. El Owasp Testing Guide es un libro imprescindible que debe estar en todo auditor de seguridad o persona que quiera conocer mas sobre el tema tan apasionante de la seguridad informática.

Figura 1: Portada de la Guía OWASP de Testing.

Figura 1: Portada de la Guía OWASP de Testing.

En principio y hasta que este traducida la podremos de leer en dos formatos en pdf (https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf) o accesible en a través del web (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents).

¿Que es la versión 4 de la Testing Guide de OWASP?

La Testing Guide es una guía, como su nombre indica de, una serie de pruebas que se pueden hacer a sistema y aplicativos para comprobar su seguridad. Dicho así suena como a “chino”, pero vamos a intentar ver como funciona mirando un capitulo de dicha guía como ejemplo.

La idea de cada capitulo es definir una prueba o un problema. Se explica el mismo, que es, que se intenta conseguir, etc. A continuación se definen una serie de pruebas con código y respuestas para ver como se puede evaluar si el sistema o aplicativo es vulnerable a ese problema. Y para terminar se recomiendan una serie de herramientas que automatizan en la medida de lo posible estas pruebas.

Ejemplo de prueba de la guía “Test HTTP Methods (OTG-CONFIG-006)”

El estudio de cada uno de los problemas o pruebas que debemos hacer en los sistemas o aplicativos se dividen en una serie de partes que nos indicaran que es y como se puede comprobar si el sistema es vulnerable.

Summary

Primera parte del estudio de la vulnerabilidad. En la versión Inglesa recibe el nombre de “Summary”. En esta parte explican de una manera clara cuales son las puntos importantes de estas caraceteristicas de los sistemas o aplicativos. A modo de ejemplo, podemos ver en esta captura la explicación de los métodos HTTP (HEAD, GET, POST,PUT,DELETE,TRACE,OPTIONS,CONNECT) lo que son y para que se utilizan.

Figura 2: Summary, donde se explican las características de la vulnerabilidad.

Figura 2: Summary, donde se explican las características de la vulnerabilidad.

 

How to Test

A continuación viene la parte llamada “How to Test”. Como su nombre indica hace referencia a como se deben de realizar los test para comprobar si el sistema o aplicativo es vulnerable a este problema. En las pruebas se intenta usar comandos o por lo menos hacerlo de una manera muy simple.

Figura 3: How to Test, donde se explican como realizar los test para comprobar la vulnerabilidad.

Figura 3: How to Test, donde se explican como realizar los test para comprobar la vulnerabilidad.

Tools

En esta parte se hace referencia a las herramientas que podemos usar para realizar las pruebas que se han explicado anteriormente pero de una manera mucho mas automática.

Figura 4: Tools, listado de herramientas que podemos usar para realizar las pruebas.

Figura 4: Tools, listado de herramientas que podemos usar para realizar las pruebas.

References

Por ultimo la parte de “referencias”, un listado de enlaces donde podemos leer mas sobre este tipo de ataques, contra-medidas, etc.

 

Figura 5: References, listado de enlaces para conseguir mas información.

Figura 5: References, listado de enlaces para conseguir mas información.

Conclusión

Aunque hemos tenido que esperar un tiempo desde la versión 3 de esta guía, esta versión 4, seguirá siendo un libro imprescindible para realizar las auditorias de seguridad de las personas que nos dedicamos a esto de la seguridad.

Les recordamos los enlaces a los dos formatos disponibles hasta el momento en pdf (https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf) o accesible en a través del web (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents).

Un saludo


  • 0

Hacking con imágenes 2

En un post anterior se describió un posible ataque a través de imágenes bmp, esta vez vamos a hablar de otro tipo de ataque pero también a través de imágenes. La diferencia es que, esta vez, el ataque es del lado del cliente y/o servidor que funciona con imágenes de tipo jpg.

El peligro puede venir de parte del lado del servidor, siempre que en una web exista algún método de subir una imagen jpg. Este problema es muy típico que en foros y otros sitios web donde el usuario tiene permitido subir imágenes y compartirlas con los demás usuarios.

A grandes rasgos el problema se produce al no comprobar el servidor si la “supuesta” imagen que sube el usuario es en realidad una imagen.

Vamos a ver como se puede aprovechar las medidas que se usan para comprobar el código fuente del lado de un servidor, en el siguiente codigo vemos que el servidor comprueba si el tipo del fichero subido es “image/jpg”. Veamos un ejemplo:

<input name="fileToUpload" type="file" onchange="check_file()" >
if($_FILES['userfile']['type'] != "image/jpg")

Muchas veces los programadores utilizarán un código similar que  hace lo que se supone debe hacer, checkea el archivo para comprobar la extensión de lo subido. Lo malo es que si solo hace la comprobación del tipo de archivo al que se refiere se puede truncar esta medida de comprobación cambiando por ejemplo la extensión del archivo.

Por ejemplo, en programación esto definiría los tipos de extensiones permitidas.

$valid_file_extensions = array(".jpg", ".jpeg", ".gif", ".png");

Hay que tener muy en cuenta la hora de filtrar las entradas de usuario que pueden reportar un comportamiento distinto al esperado e implementarlo a través de la programación.

Funciones como strrchr dan mucho juego pues puede ser utilizado para que se consiga baypassear esta comprobación.

$file_extension = strrchr($_FILES["file"]["name"], ".");

Ejemplo de posibles intentos que en muchos casos pueden llegar a funcionar, al subir una imagen a una web que solo comprueba alguna función del tipo strrchr. Con imaginación , alguien maliciosamente podría testear funciones e intentar subir una webshell como c99. Tenemos un ejemplo de este tipo en la siguiente URL http://www.php.net/manual/en/function.strrchr.php

c99.jpg.php – Es posible que llegue a satisfacer la subida del jpg

c99.jpg.PhP – Ofuscación.

c99.php;.jpg – A veces puede ignorar lo que hay detrás de un ;

c99.php.test – Puede ser que se ignore .test

c99.php.xxxjpg – Es posible que invalide el final xxxjpg por invalido

De nuevo, para explotar este tipo de vulnerabilidad, necesitaremos de algo que convierta una imagen esta vez jpg, en una webshell con código malicioso. Esta herramienta nos permite utilizar el espacio de de los metadatos que contiene un jpg para insertar ese código. Simplemente genial.

http://kaoticcreations.blogspot.co.uk/2013/10/ohno-evil-image-builder-meta-manipulator.html

Desde el punto de vista de la programación cada vez más, se están estableciendo unos patrones de metodología de control del desarrollo de la aplicación a nivel de la seguridad. Existen una serie de metodologías que ayudan a realizar ese tipo de comprobaciones. Entendemos que esto es algo que no debe estar resumido en una API de control de usuarios, sino como parte de una rutina que el programador debe asumir además como llevar un control de excepciones (exceptions, errors, etc) que pueda reportarle la aplicación. Se puede resumir en no dejar cabos sueltos, ya que el no tratarlos correctamente puede terminar por convertirse en una vulnerabilidad y ser explotada.

Por todo ello es recomendable que para cualquier proyecto existan una serie de protocolos, metodologías, asesores que guíen en todas las fases de vida de dicho proyecto desde el punto de vista de la seguridad. Cuanto antes se introduzcan expertos o metodologías de seguridad en un proyecto ayudara a que los costes de los cambios sean mínimos si lo comparamos con los costes que se pueden dar en, por ejemplo, reestructurar una herramienta para implementar contramedidas para que los “usuarios” no suban ficheros que no debieran.

Recordar que la seguridad es una lucha de todos, tanto de los que prestan los servicios (web, programas, etc) como del usuario. La seguridad debe de ser proactiva por ambas partes.

Nuestra empresa estará encantada de ayudarles en sus proyectos de seguridad con un grupo de profesionales altamente cualificados que darán soluciones a sus problemas y necesidades

 

 


  • 0

Damn Vulnerables Applications

Vamos a hacer un pequeño repaso de algunas herramientas para los que quieren comenzar con el pentesting sin meterse en “líos” y sin complicaciones, ya que, en su mayoría son live cds que podemos arrancar en una máquina virtual. Esto nos permitirá adecuar el escenario en el que vamos a realizar la auditoría, normalmente un ordenador en el mismo rango de ip que el auditor y con su consentimiento ya que es él mismo.

 

Hacking de aplicaciones Web
dvwaDVWA

DVWA Es una web escrita en PHP que nos ofrece un montón de vulnerabilidades por explotar, entre otras, fuerza bruta, SQLi, SSX, etc. Es muy fácil de instalar puesto que tiene una versión livecd o bien podemos publicarla en un servidor web propio. Nos permite configurarla en 3 niveles de dificultad. Está aplicación es genial si lo que se quiere es entender la mecánica de la obtención de datos a través de inyecciones SQL y además ver en vivo como funciona.

webgoat

WebGoat
Ya había mencionando a WebGoat en un artículo anterior sobre OWASP. Esta aplicación incluye incluso más vulnerabilidades que la anterior y por lo tanto más exhaustiva, funciona en cualquier sistema operativo que permita instalar una máquina virtual de java, ya que está escrito en dicho lenguaje.

Hay muchas otras aplicaciones con vulnerabilidades que podemos encontrar por internet, ya sea en forma de livecd o de página web. Hay numerosos grupos de hackers y expertos en seguridad que las publican para que los novatos practiquen y/o incluso ingresen a sus grupos, si superan los retos correspondientes.

 

Hacking iOS

dvwiosDVIA
Para testear tus skills en hacking de sistemas iOS  en varios aspectos de la seguridad, como puede ser el almacenamiento inseguro o la detección del jailbreak entre otros tantos. Todos basados en vulnerabilidades ya parcheadas de iOS, pero que no deja de ser interesante por ello.

 

Hacking en sistemas linux

hacking_dojo
Hacking dojo
Hacking dojo es una web que ofrece servicios de instrucción en cuanto al pentesting, e-learning en 5 niveles, de novicio a más avanzado.
En esta web podrás encontrar varios live cd muy interesantes, cuando los arrancas, en ellos se encuentran normalmente instalado un servidor web donde indica cual es el objetivo que tenemos que lograr. Estas distribuciones vulnerables están basadas en linux y exigen conocimientos sobre algunos aspectos del sistema, pero a su vez nos embarcará en una serie de retos muy interesantes que nos obligarán a pensar “out of the box” y enfrentarnos al escenario típico de un servidor al que queremos sacar la clave del root.


  • 0

Sobre la ética hacker, la auditoría de seguridad o el mal llamado “Hacking ético”

sombreros_hackerLarga es la discusión para definir el término hacker.., En España por ejemplo todavía existe la idea del pirata informático, cracker o maligno creador de virus como tal. No obstante sabemos que España es uno de esos paraísos donde la mal llamada piratería siempre ha campado a sus anchas. Las cintas de cassette de los 80, los cds de los 90 y las leyes contra la “piratería” inventadas en los últimos tiempos, son claro ejemplo de que a España siempre le ha gustado hackear los sistemas  o que no le ha quedado otra a sus ciudadanos para llegar a la información.

En algunos casos se han escuchado auténticas barbaridades como que todos los hackers son delincuentes, por no hablar del agravio comparativo de lo que supone un delito de lesiones, sangre, violación, secuestro, etc con los que a veces se compara las tropelías ejercidas, eso sí, por ciberdelincuentes, cuyo mayor delito, en muchos casos, no es más que apropiarse de una información que en teoría no les pertenece. Un militar está entrenado para matar, sin embargo no llamamos asesinos a los militares, está lógica no se aplica mayormente a los hackers.

Esta asociación entre conocimiento y aplicación del mismo ha hecho que el termino hacker este asociado especialmente en nuestro país con la delincuencia electrónica y aún más ahondando en la interpretación psicológica que nos dice que lo desconocido siempre a causado respeto y temor haciendo que los hackers sean definidos, o bien entre los héroes o bien entre los villanos.

La verdad es que la percepción sobre los hackers está gravemente influenciada por las películas de Hollywood, donde el hacker es un malvado ciberdelincuente que se cuela en el ordenador de la CIA y anula los sistemas satelitales y de defensa o bien, es un joven superdotado que salva al mundo de un peligro electrónico o de anterior.

La ética y el hacking. De todos es conocido que muchas de las cosas que hacen los hackers rozan con la ética. Así pues, en su mayoría son conocimientos adquiridos que aplicados de una forma no esperada, pueden hacer que un sistema se comporte de una forma de la que se puede sacar alguna aplicación a un fallo como la fuga de información. Así pues, podemos hacer hacking de todo tipo, desde hackear una máquina de refrescos, abrir un candado sin una llave, o modificar una página web, esto también son consideradas formas de hacking.

Como se habrá podido sobreentender del párrafo anterior, todas estas acciones sobre sistemas pueden chocar con la ética de las personas, sobre todo , si eres el dueño de la máquina, del candado de la bici o el administrador de la web en cuestión. Es aquí donde entre la ética del hacker.

Como es nuestra especialidad nos centraremos en este caso de la página web, imaginemos, por ejemplo, que el hacker es en realidad, un simple estudiante probando técnicas de hacking de una vulnerabilidad web. Su intención probablemente será comprobar que la página es vulnerable a una inyección SQL y trataría de extraer información. Sus intenciones no son tan malas, si no hace mal uso de la información que pudiese extraer, por ejemplo si después de extraer los datos, simplemente se siente contento y los borra, esto podría considerarse un comportamiento ético dentro de lo razonable y siempre y cuando no tenga otra motivación que el propio logro.

En otro escenario un hacker que está en contra por ejemplo de los gustos musicales de los usuarios de un foro web sobre música y decide borrar todos los comentarios. En este caso, tenemos que efectivamente su intención es de hacer daño y destruir información. Claramente sus intenciones chocan con la ética.

En ambos casos muchos se supondrán el problema ético del acceso no deseado a la página web, pero realmente es un dilema estúpido que no beneficia en absoluto a la seguridad de los propios sistemas. Lo importante realmente es que alguien a podido saltarse los mecanismos de seguiridad y que podría volver a pasar y las consecuencias que pueden ocurrir a raiz de ello.

No obstante cuando Anonymous atacó la página de Lolita city, conocida web pedofila de la darknet, fue considerada una acción ética, y en absoluto se puso en entredicho la legitimidad de los métodos empleados, sino la finalidad de los mismos. Esto choca frontalmente con la idea de el “hacking ético” que se define como una auditoría de hacking consentida por la parte interesada en llevar a cabo dicha auditoría, pues en este caso se realizo una auditoría sin consentimiento.

Muchos gobiernos han puesto auténticas leyes represivas sobre los accesos a sistemas, que además suponen además un grave peligro para su propia seguridad. Una nación sin jóvenes con educación en la penetración de sistemas y en el conocimiento de estas técnicas puesto que sufren el temor de ser arrestados o perseguidos por la justicia y además penados gravemente si lo hacen, no tendrá defensa ante los ciberdelincuentes, que sí se han enfrentado a diferentes sistemas y escenarios donde conocerán las vulnerabilidades de los mismos. La ciberseguridad se esta convirtiendo en uno de los pilares de las telecomunicaciones. Tanto es así que nos resulta chocante que a medida que ha aumentado la persecución a simples aprendices de hackers que escanean redes y puertos, también ha ido aumentando el número de noticias que indican el constante espionaje al que estamos siendo sometidos por los propios gobiernos e sus instituciones como son los continuos escándalos de EEUU a través de la NSA, curioso es, que en EEUU esté considerado delito el escaneo de puertos.

La la auditoría de seguridad informática, o mal llamado “hacking ético” es estrictamente aquel en que la parte interesada en realizar la auditoría, da su consentimiento al auditor, para que ponga a prueba sus sistemas y de esa forma buscar los puntos débiles de los mismo para intentar mejorar la seguridad de estos. Insisto mal llamado hacking ético porque la seguridad no tiene nada que ver con la ética, la seguridad informática no difiere en absoluto con cualquier otro tipo de medidas de seguridad, ya sea poner una cerradura o una alarma.

El dilema ético de si te puedo abrir el candado o no, es estúpido, porque yo quizás pueda abrírtelo, pero vendrá otro que además de abrirlo, se llevará la bicicleta. Muchas veces se mata al mensajero y no el mensaje.

Pablo Martínez, TeamSec