Para ilustrar el funcionamiento del fuzzing con un ejemplo muy simple, vamos a tomar como referencia el siguiente fragmento de código.

Como se puede ver, en la línea 4 se produce un bug cuando el valor de x contiene la cadena ‘aaa’, por lo tanto el objetivo consiste en proporcionar valores a x sucesivamente (i.e., ‘a’, ‘b’, …, ‘aa’, ‘ab’, …) hasta encontrar una entrada a partir de la cual se desencadene el bug y una vez descubierto, guardar todos los elementos necesarios para poder reproducirlo. La ventaja es que una vez que un fuzzer se pone en funcionamiento, se puede dejar durante días, semanas o meses en busca de errores sin necesidad de interacción.

Cabe destacar que, para un fuzzing efectivo, los datos de entrada proporcionados no deben ser simplemente malformados o aleatorios, sino que deben ser suficientemente válidos como para superar pruebas elementales de consistencia y no ser directamente rechazados, pero suficientemente excepcionales como para producir comportamientos inesperados. Dependiendo de como se crean los datos de entrada, se distinguen 3 tipos de fuzzing: los basados en mutaciones que crean los datos de entrada mutando «aleatoriamente» valores de entrada válidos, los basados en generación que generan los datos de entrada desde cero y el fuzzing evolutivo, que a partir de un conjunto de valores iniciales de entrada y utilizando un algoritmo evolutivo produce los valores que mejor se adaptan en base a una serie de propiedades.

Por otra parte, dependiendo del conocimiento del fuzzer sobre el formato de los valores de entrada, se distinguen 2 tipos: el dumb fuzzing, que como su nombre indica no necesita ningún conocimiento sobre el objetivo y el smart fuzzing, que es consciente de la estructura de entrada a través de modelos o grámaticas. La principal diferencia entre ambos tipos es la validez de los valores de entrada y la cantidad de trabajo necesario para generarlos, es decir, un dumb fuzzer generará casos de prueba con menos esfuerzo que un smart fuzzer pero la proporción de entradas válidas (casi) siempre será menor.

Actualmente el fuzzing es un área activa de investigación debido a su efectividad y buenos resultados, lo que también ha favorecido que las empresas lo adopten dentro del proceso de verificación de calidad en el ciclo de vida de desarrollo de software. Como muestra de su efectividad, Google anunció hace varios meses que su proyecto OSS-Fuzz había encontrado más de 1.000 bugs en 47 proyectos distintos de código abierto en un plazo de 5 meses.

The post Explicando las bases del fuzzing appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

Existe una forma muy útil para conseguir saber quién quiere entrar en nuestra red y con qué intenciones lo hace. Basta con dejar un tarro de vulnerabilidades en medio del bosque y esperar a que las abejas se acerquen. La mayor parte de veces suelen ser sistemas automatizados o script kiddies, otras ciberdelicuentes y, aunque sea algo poco frecuente, investigadores o jóvenes con ganas de aprender (no sería la primera vez que alguien usa la honeypot para tener una amistosa charla con el intruso y descubre los no tan oscuros objetivos del susodicho).

Las honeypots son sistemas premeditadamente vulnerables que permiten proteger y conocer el comportamiento de un posible atacante. Uno de los usos más curiosos que se les da, es utilizar varias honeypots distribuidas alrededor de todo el planeta para conocer los «ataques en tiempo real» que ocurren entre países. En muchas ocasiones, también se crean infraestructuras de red que conectan honeypots con la intención de simular un red completa (honeynets). De esta forma, el estudio que se puede realizar será más detallado y permitirá obtener más datos. Existen dos tipos de honeypots, con sus respectivos objetivos:

• Honeypots de baja interacción: Son programas que únicamente se limitan a simular un sistema operativo o un servicio concreto. Generalmente se suelen utilizar para realizar diferentes estadísticas sobre métodos/técnicas de explotación de vulnerabilidades y detectar nuevos tipos o familias de malware. Para lograr información valiosa es necesario realizar un proceso de administración y mantenimiento exhaustivo. El mayor problema para estas honeypots es que, al ser simulaciones, es sencillo que una persona con experiencia en el área descubra el pastel. Un inusual número de puertos abiertos, demasiada memoria libre, instalaciones por defecto o información sensible a plena vista son algunas de las posibles pistas. Los ataques automáticos en cambio, harán las delicias de los administradores.

• Honeypots de alta interacción: Se utilizan equipos reales que se encuentran en las redes privadas de compañías para detectar intentos de accesos no permitidos. Dado el lugar en el que se encuentran, no suelen ser víctimas de muchos ataques ya que no resulta sencillo pasar el resto de barreras que puede haber puesto la compañía para llegar allí. Los datos que se obtienen tienden a ser bastante interesantes puesto que suelen tratarse de hackers especializados. Al ser sistemas operativos completos, es posible que un atacante intente explotar una determinada vulnerabilidad zero-day, y al no ser equipos que están realizando ningún servicio real, cualquier pequeño movimiento de tráfico que ocurra se podrá aislar para un estudio posterior.

Si os ha gustado la idea de las honeypots, podéis implementaros la vuestra propia (en una raspberry Pi o un equipo antiguo que tengáis olvidado por casa) y ver qué atrapáis. Podéis empezar utilizando la distribución de Linux HoneyDrive, que contiene software de honeypots como  Kippo (SSH honeypot), Glastopf (web honeypot) o Amun (malware honeypot). Tampoco querría dejar pasar el momento de recomendar Tango para hacer un despliegue rápido y eficiente. En caso de estar interesado en utilizar honeypots comerciales de Windows, las más conocidas son KFSensor y Specter. Recordad que cualquier muestra interesante que obtengáis puede ser muy peligrosa en manos inexpertas y produciros disgustos innecesarios, así que tened mucho cuidado y disfrutad investigando.

El que avisa no es traidor.

The post Honeypots, atrayendo hackers con vulnerabilidades appeared first on S3lab.

Hoy vamos a jugar con una herramienta de búsqueda de vulnerabilidades web con la que podremos de forma muy sencilla comprobar la seguridad de nuestras aplicaciones web. La herramienta en cuestión elegida es Vega, una plataforma Open Source de auditoría web que puede ayudarnos a identificar y mitigar agujeros de seguridad ampliamente explotados.

Intalacion y escaneado

En primer lugar descargamos la herramienta desde la web oficial de Vega. Además, necesitaremos el entorno de ejecución de Java (JRE), con lo que en caso de darnos error al ejecutar la aplicación deberemos descargarlo (en versión de 32 o 64 bits, igual que Vega).

Comencemos entonces con el primer análisis. Para ello seleccionamos la opción “Start new scan” mediante su icono, a través del menú “Scan” o con el atajo de teclado “ctrl+n”.En la ventana que se nos presenta, podremos elegir la URI base sobre la que realizar la auditoría. Mucho cuidado eso sí con la elección. Salvo que se tenga consentimiento del responsable del dominio, podríamos tener problemas legales.

Posteriormente se nos ofrece la posibilidad de seleccionar los módulos a ejecutar, los diferentes tipos de ataques a realizar contra nuestro sitio web. Seleccionar todos significa mayor tiempo de análisis pero también mayor certeza de que estamos más protegidos. En caso de querer buscar cosas específicas, por ejemplo tras solucionar los problemas detectados tras un primer análisis, podríamos seleccionar solo aquellos que nos interesen. Por último, podemos añadir cookies que se enviarán en cada petición realizada por la herramienta durante la auditoría, esto puede ser muy útil para que el sistema tenga acceso a zonas que requieren autenticación (como por ejemplo un panel de administración).

Al darle a finalizar comenzará el escaneo, que podremos seguir en tiempo real, pudiendo visualizar las diferentes partes del sitio que han sido y serán analizadas así como las diferentes vulnerabilidades encontradas categorizadas según su relevancia.

Interpretación de los resultados

Una vez finalizado el análisis, podremos recorrer todos los elementos presentes en la sección “Scan Alerts”. Según vamos seleccionando cada una de ellas, se abrirán en la sección “Scan info”, donde no solo se amplía la información sobre la posible vulnerabilidad encontrada sino que además se ofrecen detalles como el impacto que puede tener sobre la aplicación web bajo análisis, como la posible solución que puede tener el problema. Si además seleccionamos la petición del apartado “REQUEST” accederemos a un nuevo panel en el que podremos observar tanto la petición como la respuesta dada por el servidor.

Una vez terminado el análisis podemos “limpiar” el espacio de trabajo a través de la opción “File – Reset Workspace”, no sin antes haber analizado cuidadosamente cada una de las alertas y, por supuesto, tratado de solventar todas ellas. Y con esto hemos realizado un primer análisis básico sobre una aplicación web que nos ayudará a conocer la situación actual de la misma y a paliar, en caso de que existieran, todas las vulnerabilidades que pudieran generar algún tipo de riesgo a los usuarios.

Cabe mencionar que existen multitud de herramientas similares a Vega (ver listado de otras soluciones) cada una con sus ventajas y desventajas. En próximas entradas analizaremos nuevas funcionalidades e intentaremos adentrarnos un poco más en el extenso mundo de la auditoría web. Y recordad, mucho cuidado con los objetivos, la seguridad por oscuridad sigue siendo una forma de vida ahí fuera y no todo el mundo agradece que le saquen las vergüenzas.

The post Buscando agujeros de seguridad en mis webs appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

En los últimos tiempos el paisaje de las vulnerabilidades zero-day se ha visto alterado por un fenómeno cuando menos curioso, el marketing. Y no me refiero a la técnica utilizada por hackers o investigadores de seguridad para venderlas, sino al sistema utilizado para mostrarlas al público, o mejor dicho a los medios de comunicación (tanto especializados como generalistas).

Como hasta ahora, los factores clave para conseguir fama a través de una zero-day son que esta afecte a un gran número de servidores de forma universal y que sea “fácilmente” explotable. Pero el marketing está ganando fuerza progresivamente, ya que logra que la gente hable de ello y que el reporte no pase sin pena ni gloria por las redes sociales. Cada vez más personas están interesadas en conocer los entresijos de los servicios que utilizan y los medios están dispuestos a suplirles con tanta información como les sea posible.

Algunos de los ejemplos más claros y que más han impulsado esta idea de funcionamiento han sido HeartBleed, ShellShock y Poodle. Siguiendo la línea actual, parece que cuando alguien encuentra una vulnerabilidad zero-day tiene que seguir los siguientes pasos antes de reportarla:

• Nombre: Encontrar un nombre pegadizo y fácil de recordar. Tampoco puede ser muy largo, o se convertirá en acrónimo en un abrir y cerrar de ojos. Hay que tener en cuenta que tiene que mostrar la relación de la vulnerabilidad con el servicio para que la gente lo relacione rápido y no le de demasiadas vueltas a la cabeza.

• Imagen: Crear un logotipo que sea capaz de llamar la atención de un posible lector de un vistazo, como se suele decir, una imagen vale más que mil palabras. Tranquilo que si el diseño gráfico no es tu especialidad, porque lo tuyo son claramente los unos y ceros, algún alma caritativa lo hará por ti e intentará esparcirlo por todo lo largo y ancho del globo para conseguir que su diseño sea el más usado y se lleve algo de fama aunque sea de refilón.

• Web: Qué sería una vulnerabilidad sin una página que muestre el porcentaje de servidores vulnerables a nivel mundial o que permita comprobar si el nuestro también es vulnerable. Disponer de toda esa información permite mostrar el peligro real que tiene.

A nivel personal, el último punto me parece que verdaderamente aporta información relevante a la hora de reportar una vulnerabilidad zero-day, pero el resto de los puntos apartan a la comunidad de la información relevante. Si se sigue esta estela, el mundo acabará con menos zero-days reportados «cuando deberían» por perder el tiempo en factores menos importantes, eso sí, jamás olvidaremos sus nombres y logos.

El que avisa no es traidor.

The post El marketing tras las vulnerabilidades zero-day appeared first on S3lab.