jueves, octubre 17, 2019

FOCA: Nuevas evoluciones y Twitter oficial para una vieja amiga #FearTheFOCA

Poco se puede contar de FOCA de lo que no se haya hablado ya en post anteriores, desde su nacimiento por el año 2008 hasta liberar el código fuente hace un par de años en lo que hoy día es Foca Open Source, el cual se puede consultar y colaborar en el repositorio GitHub de FOCA.

Figura 1: FOCA: Nuevas evoluciones y Twitter oficial para una vieja amiga

Poco se puede decir más que todo lo que se cuenta en el libro de Pentesting con FOCA que escribió Chema Alonso y con el que colaboramos muchos, y del que se han vendido más de 5.000 ejemplares, siendo uno de los mejores textos para aprender no solo a utilizar FOCA, sino también a aprender cómo funciona un pentesting desde el principio.


Pero entrado ya el año 2019 hemos querido retomarla con fuerza, dedicándole el tiempo y cariño que durante tantos años se ha ido ganando. Y commit a commit hemos ido solucionando pequeños problemas existentes en versiones anteriores, mejorando y refactorizando líneas de código para que sea más tolerante a fallos y mucho más eficiente, y hoy aprovecho para contaros algunos de ellos.

Figura 3: GitHub de FOCA Open Source

Son muchos los pequeños arreglos que se han ido realizando en nuestra querida FOCA, pero también ha habido algunos que son de mayor tamaño. Entre estos grandes cambios podemos destacar los siguientes que os paso a enumerar.
• Se han eliminado todos los ficheros innecesarios de GitHub (producto de la compilación del código fuente) migrando estos al sistema de releases del propio GitHub. Esto facilita la descarga de FOCA, reduce el tamaño del paquete a descargar y ayuda al versionado de la herramienta. 
Así que ya no es necesario clonarse el repositorio completo y acceder al directorio ‘bin’ (ya no existe) como tantas veces se ha nombrado en artículos y videos anteriores, sino que será suficiente con descargar el binario empaquetado en un zip, pudiendo elegir entre las distintas versiones publicadas (aunque es recomendable descarga la última).
Figura 4: GUI de FOCA Open Source 3.4.6.1
• Desde que se hizo open source, FOCA se apoya en una base de datos SQL para la gestión de los proyectos. Se ha mejorado la integración de esta funcionalidad y aunque sigue siendo necesario SQL Server para su funcionamiento, ya no tiene por qué ser la versión Express ni estar corriendo en la propia máquina. Ahora se lanza un prompt para poder configurar la cadena de conexión donde se encuentre alojada la instancia de SQL Server 
Figura 5: Configuración de la instancia de SQL Server en FOCA
• Se han solucionado varios bugs que impedían la descarga de ficheros en ciertos entornos.
• El módulo de buscadores se ha refactorizado, solucionando distintos problemas y mejorando el rendimiento de estos. Además, se han actualizado los componentes necesarios para hacerlos compatibles con las versiones más actuales de las APIs de los diferentes buscadores.
• La librería de extracción de metadatos también ha sufrido cambios, mejorando la estructura de datos y eliminando código innecesario. Con la solución de varios bugs se ha ampliado la cantidad de información extraída, y se ha añadido compatibilidad para los ficheros sin extensión.
• Se ha organizado el menú contextual de la vista de metadatos, añadiendo nuevas opciones y solucionando bugs en casuísticas concretas.
Figura 7 : Nuevo menú contextual
• Diferentes mejoras en la UI, corrigiendo errores gramaticales y ajustando ciertos elementos visuales de los formularios.
• Los distintos ficheros que componen la solución han sido reestructurados, dándole más coherencia y legibilidad al proyecto.
• Mejora general en la gestión de hilos y dibuja de la UI, haciendo más agradable la experiencia de usuario. La última versión publica es la v3.4.6.1 y cómo se ha mencionado anteriormente, podéis descargarla en el apartado releases de GitHub, además de ver el changelog de cada una de las versiones que se vayan publicando.
Figura 8: Twitter oficial de FOCA (@Fear_the_Foca)

Por último, solo queda añadir que, en 0xWord puedes conseguir la Camiseta oficial original de Fear the FOCA y que ya tenemos cuenta oficial de Twitter para Foca (@fear_the_foca), Así que si quiere estar al tanto de las últimas novedades, artículos y ejemplos ya puedes comenzar a seguirla.

Saludos,

Autor: Ioseba Palop, Principal FOCA developer (Contactar con Ioseba Palop)

miércoles, octubre 16, 2019

MyPublicInbox: Unos perfiles de artistas en el mundo del cómic @salvadorlarroca @nikotxan @blowearts @0xWord @respetocanas @celspinol

La plataforma de MyPublicInbox sigue creciendo, ya cuenta con más de 600 usuarios, lo que es una bonita sorpresa para todos nosotros. En la primera entrada os dejé algunos perfiles con los que contactar un poco variados, e hice una segunda entrega con perfiles de gente del mundo del arte y el espectáculo. Hoy os traigo algunos perfiles de MyPublicInbox de artistas del cómic, para que si eres un fan como yo del mundo del cómic puedas contactar con ellos de forma responsable. Para contratarlos, para invitarlos a un sarao, o para demostrar el nivel de fan total que eres.

Figura 1: MyPublicInbox: Unos perfiles de artistas en el mundo del cómic

El primero de ellos es Raul Salazar, uno de los dibujantes que seguramente has visto muchas veces en el El Jueves, donde ha publicado muchos de sus trabajos, que yo me he leído en las más de quinientas revistas y cien Pendones, "Puta Milis", y demás spinoffs de la revista.

Figura 2: Contactar con "Raúl Salazar", dibujante de El Jueves

Su estilo es inconfundible, y tengo muchos de sus dibujos esperando que le pille un día para que me firme y me dedique alguno. Una pasada tenerlo a tiro de 100 Tempos ahora que no pienso desaprovechar.


El segundo perfil que os traigo es del gran Salva Espin, que ha historia con su trabajo en DeadPool y con su forma de ser. Un artista 100% de la región de Murcia, al que es imposible no admirar como profesional y querer como persona por su paciencia y cercanía. Un tipo genial.
Pero no te comas de vista a Salva Espin a la primera, que como dice en su descripción, por sus manos han pasado Hulk, Capitán América, La Patrulla X, Lobezno... y Broncano. Ouh ,Yeah!


Por supuesto, si hablamos de dibujantes españoles, Carlos Pacheco es un must. Su trabajo en la industria del cómic ha sido tan relevante como exitoso, y si tienes cómics de Forum de los años 80 seguro que en alguno encontrarás algunos de esos posters y portadas que hacía cuando estaba comenzado.

Figura 6: Contactar con Carlos Pacheco

Si un día tengo tiempo, le traigo a casa y le clono el ADN para poder extraer algo de su talento en el dibujo y la narración de historias. Un maestro consolidado en el estrellato de este arte.

Este joven artista extremeño, Pablo Gómez Rodrígue (Blowearts), diseñador gráfico, ilustrador, y animador de mascotas tiernas en papel, hace las delicias de los amantes de los perros y las mascotas. Sus tiras, ilustraciones, y diseños son tiernos y entrañables. Una de esas cosas bonitas que da nuestro país.
Me encantan las viñetas que hace Blowearts con Lico El Perro. Una maravilla de artista que puedes contratar para hacer trabajos de ilustración o diseño gráfico a través de su perfil.


Y llegados a este punto, también puedes contactar con uno de los más grandes en el mundo del cómic a nivel mundial. El gran Salvador Larroca, que después de celebrar sus 25 años sigue en la primera línea. Con sus trabajos en Iron Man, Star Wars y X-Men ha marcado un antes y un después en el mundo de los superhéroes.

Figura 9: Contactar con Salvador Larroca. #Respect

Yo tengo un Wolverine que me regaló colgado en mi despacho, y muchos minutos escuchándole y disfrutando de su saber, sus enseñanzas de vida y su tiempo. Os dejo la charla que hizo en la  Fundación de Telefónica celebrando sus 25 años en Marvel.


Figura 10: Salvador Larroca: 25 años en Marvel

Otro con el que puedes contactar, ya lo sabes, es con el Nikotxan. Creador de Cálico Electrónico, Pésame Street, Los Telepis, etc... No hace falta decir lo fan que soy yo, que al final acabé metido en el lío de sacar capítulos de Cálico Electrónico y todo.

Figura 11: Contactar con Nikotcan
Además, si lo que quieres es hacer algún trabajo con Cálico Electrónico, también tiene un buzón especial para que contactes con el equipo que lleva ahora sus apariciones. En breve - mañana si todo va bien - tendrás sorpresas con el gordito.

Figura 12: ¿Quieres hacer algo con Cálico Electrónico? Aquí puedes contactar con él

También puedes contactar con Emilio Gonzalo Mallo (Bigotix), uno de los referentes en el mundo de las exposiciones de cómics, ya sean superhéroes o manga. Todo un referente en este mundo en España si quieres conocer cómo funciona la industria. Sus consejos y su consultoría mueven muchas de las actividades que hay en el mundo de este arte en nuestra tierra.

Figura 13: Contactar con Emilio Gonzalo Mallo (Bigotix)

Por supuesto, no puede faltan en la lista de artistas añadir a Cels Piñol, uno de mis artistas fetiche con sus narizotas. Su Fanhunter y sus mil y una referencia cruzada entre una historia y otra. Sus tramas son nudos gordianos que hay que desliar por la cabeza de un adicto a la cultura pop de los últimos cuarenta años.

Figura 14: Contactar con Cels Piñol

De el es esa camiseta del Profesor Alonso que yo luzco en tantas ocasiones como el día que conocí a Alice Cooper - hoy mismo la llevo puesta para la charla que doy esta tarde, y que tanto me gusta. Ouh Yeah!


Por último, sabéis que estamos editando cómics en 0xWord, donde tenemos ya Hacker Épico Deluxe Edition, Universo Armatura, La Elite y Evil:ONE, así que el equipo que los edita y lleva la historia de Jerry Finger tiene un buzón para hablar con ellos.

Figura 16: Contactar con Jerry Finger Editores

Y aunque no están todos los que son, ni son todos los que están, os he hecho una selección. Recordad que también podéis contactar con el gran Alejandro Pereira Ezcurra, pero ya os haré una entrada dedicada solo al mundo de los escultores de superhéroes.

Saludos Malignos!

PD: También puedes contactar conmigo, pero yo solo hago No Lusers }:)

Autor: Chema Alonso (Contactar con Chema Alonso)

martes, octubre 15, 2019

Google Chrome forzará la política de SameSite=Lax para proteger tus cookies contra los ataques CSRF

Los ataques Client-Side en los navegadores de Internet han ido disminuyendo un poco, pero solo un poco, debido a la cantidad de mejoras de seguridad que se han ido añadiendo para fortificar el navegador. Por desgracia, no siempre son entendidas todas las protecciones por todos los arquitectos de sitios web, ni por supuesto son configuradas en todas las aplicaciones web que visitas. Un ejemplo de ello son las políticas CSP (Content Security Policies) que tan pocos sitios aún configuran, o la política SameSite que Google Chrome ha optado por forzar por defecto.

Figura 1: Google Chrome forzará la política de SameSite=Lax
para proteger tus cookies contra los ataques CSRF

Para entender su funcionamiento hay que ver cuál es el origen de dicha política de seguridad, entendiendo cuáles son los ataques que intentan bloquear. Para ello, la recomendación es que te leas y estudies en detalle el libro de Hacking Web Applications: Cliente-Side Attacks que explica en detalle ataques como XSS, CSRF, CSSP, SSRF, XSPA & SSJS que escribió Enrique Rando (y con el que también puedes contactar vía MyPublicInbox)

Figura 2: Libro de Hacking Web Applications: Client-Side Attacks

El ataque en concreto que busca mitigar el uso de la política SameSite es el de Cross-Site Request Forguery o XSRF, utilizado para forzar acciones en aplicaciones web hechas por usuarios sin que estos sean conscientes, como vimos en votaciones por Twitter donde gente se aprovechaba de este bug para conseguir mejor posición.

CSRF en un minuto

Supongamos que un usuario tiene abierta la página de su aplicación web para ver sus fotografías, donde puede gestionarlas con unos botones de acción que envían por GET la acción. Por ejemplo, para borrar la foto podía ser algo como.
https://www.miweb.com/gestionarfoto.PHP?id=111&accion=eliminar
Lógicamente, esta acción estaría protegida por una cookie de sesión, lo que hace que si alguien conoce ese enlace, pero no tiene iniciada una sesión válida en miweb.com no enviaría la cookie correcta al servidor y por tanto no se podría ejecutar.

Figura 3: Gmail fue afectado por ataques CSRF en sus inicios

Los ataques CSRF se basan en conseguir que sea la víctima del ataque con una sesión iniciada la que envíe esa petición. Para ello el atacante solo necesita saber cuál es la URL que desea ejecutar y hacérsela llegar a la víctima para que ella voluntariamente mediante un engaño haga clic en ese enlace o involuntariamente mediante una vulnerabilidad en cliente que permita forzar la navegación de la víctima a esa URL. Así de sencillo.

¿Cómo protegernos de los ataques CSRF?

Las aproximaciones para evitar este tipo de ataques han sido varias. Primero, poner el envío de acciones como estas en métodos GET no parece la mejor de las ideas. Al ser una URL toda la información GET queda registrada, así que las aplicaciones modernas utilizan más el método POST para evitar que sea tan fácil de capturar e invocar una acción con solo conocer una URL, eso quita gran cantidad de ataques XSS, que por otro lado son mitigados también con los filtros Anti-XSS en los navegadores.

La segunda de las opciones se basa en hacer que la URL por GET no sea tan predecible, para lo que se crean los tokens Anti-CSRF que se añaden en las páginas autorizadas para poner un enlace de este tipo. Es decir, imaginemos que tenemos una herramienta de administración que tiene un panel para pintar la opción de borrar la imagen. Antes de pintarse esa opción, se solicita desde la página web unos tokens Anti-CSRF al backend, y este los entrega a esa URL del panel. Si alguien quiere invocar la URL de borrar, tiene que conocer esos tokens. Si no, el backend lo desecha.

Figura 4: Ejemplo de token Anti-CSRF en OWASP

Es decir, en la petición POST, o en la GET si así fuera, se añaden los tokens CSRF y se evita que el atacante sea capaz de predecirlos. Por supuesto, es necesario que el backend los compruebe, porque hay muchas webs que los añaden pero no los comprueban en el servidor, lo que hace que poniendo cualquier valor, cuele.

La última protección es evitar que vaya la cookie de sesión pegada a la petición. Es decir, evitar que el navegador envíe la cookie de sesión autenticada al servidor si detecta cualquier problema. Y esto es lo que evita la política de SameSite.

Protección de cookies

Como sabéis, el servidor puede establecer que una cookie que él ha generado la entregue el navegador solo a un determinado dominio, a un determinado path, solo bajo métodos HTTP, y bajo conexiones seguras. Son los famosos flags HTTPOnly, Secure y Path. Esto haría que fuera mucho más difícil robar cookies en ataques de Session Hijacking usando JavaScript o suplantación de servidores en ataques de phishing.
Set-Cookie: Elladodelmal=1; Path=/; HTTPOnly; Secure;
Pero no evitan ningún ataque CSRF, en el que el problema es que la petición al backend se hace desde otra pestaña del navegador. Es decir, desde otro origen distinto al que tiene la sesión abierta. Para ello, se creo la política SameSite. Es decir, si la cookie no se ha creado en esa pestaña, a pesar de que se haga un POST al dominio que creo la cookie, el navegador no debería sacarla del Cookie Jar y enviarla. 

Para eso, en la creación de la cookie se añade la política SameSite y el nivel de restricción, que puede ser Strict o Lax. El primero le dice al navegador que bloquee el envío de la cookie desde otra pestaña sea cuál sea el método HTTP que esté utilizando, mientras que con Lax se permite enviar la cookie si el método es GET.
Set-Cookie: Elladodelmal=1; Path=/; HTTPOnly; Secure; SameSite=Strict;
Esto es así, porque muchas aplicaciones web - especialmente redes sociales - viven de referencias en sitios de terceros y exigiría que el usuario tuviera que iniciar sesión cada vez que hiciera un clic en un enlace. Los que tienen esa forma de funcionar, las acciones importantes las configuran siempre por POST y dejan el método GET para eso, para navegaciones internas entre contenidos. Por eso se creo SameSite=Lax
Set-Cookie: Elladodelmal=1; Path=/; HTTPOnly; Secure; SameSite=Lax;
Pero... no mucha gente ha configurado en sus cookies la política Same-Site, así que Google Chrome ha optado por forzarlo de la siguiente manera.

Google Chrome Same-Site-By-Default-Cookies

A partir de la versión de Google Chrome 78 estará activada la opción que está disponible en modo test desde Google Chrome 76 que, si una cookie no tiene la política SameSite, por defecto será como si llevara la opción de SameSite=Lax. Por lo que puede que si tu web utiliza URLs GET sin SameSite para administrar cosas, tal vez te dejen de funcionar comportamientos que son comunes en tus usuarios.

Figura 5: Flags en Google Chrome 77

Lo suyo es que tengas en mente por qué se utiliza SameSite=Lax y veas si puedes mejorar la seguridad de tu web, pero si no, que sepas que Google Chrome va a forzarlo por defecto. Siempre puedes entrar en Google Chrome, y en los flags de configuración cambiar el valor de la opción Same-Site-By-Deafult-Cookies y Deshabilitarlo, pero lo mejor sería que revisaras tu web.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

lunes, octubre 14, 2019

(más) Técnicas de escaneo y evasión con Nmap usando el tiempo

La semana pasada hablé de técnicas de escaneo y evasión con Nmap. Hoy hablo de más técnicas de escaneo, como si fuera una segunda parte del artículo, y puede que vengan más en un futuro. El arte del fingerprinting, en muchas ocasiones es eso, un arte. Nos permite saber cosas sobre las máquinas cuando vamos a ciegas.

Figura 1: (más) Técnicas de escaneo y evasión con Nmap usando el tiempo

No sabemos si la máquina es Windows, un GNU/Linux, un macOS, no sabemos si tiene un puerto abierto o cerrado, si tiene un servicio u otro, si tiene una mecanismo de protección o no lo tiene. Ni siquiera tenemos por qué saber si estamos en la misma red que la máquina o las máquinas de las que queremos saber. Por eso, cuando hacemos un Ethical Hacking, cuanto más sepamos de la fortificación de Windows, de la fortificación de GNU/Linux y de la seguridad de MacOS, mejor entenderemos los resultados que obtenemos.

Fgiura 2: Libros de "Máxima Seguridad en Windows 4ª Edición"
"Hardening de servidores GNU/Linux 3ª Edición"
& "macOS Hacking" de 0xWord

Ligamos Nmap al fingerprinting en muchas ocasiones, pero no es la única herramienta, aunque sin duda es una herramienta con experiencia, con años de desarrollo y con extensibilidad a través de su motor NSE. La semana pasada la utilizamos para dar juego a ping sweep y todas las variantes de bypasses y evasiones que podemos imaginar en un entorno en el que queremos saber si la máquina está o no está.

Figura 3: Libro de técnicas de Ethical Hacking en 0xWord

Hoy vamos a jugar con los templates de tiempo y la forma de bypassear ciertas protecciones gracias al timing.

Nmap Timing: Jugando con el tiempo

La plantilla de tiempo en nmap viene dada por el parámetro –T. Cuando ponemos –T0 es la plantilla de tiempo más lenta, con diferencia, mientras que –T5 es la más rápida. Por defecto, ¿Qué utiliza nmap si no indicamos nada? Por defecto se utiliza la plantilla –T3. A continuación, os dejo un listado de los tipos de plantillas, sus nombres y las posibilidades de éstas:
• Insane –T5: Esta plantilla envía paquetes lo más rápido posible. Solo espera 0,3 segundos para obtener una respuesta ante el envío de un paquete. La diferencia de tiempo entre los dos paquetes enviados es de hasta 5 milisegundos. Escaneo muy rápido, pero el cual genera mucho ruido. La precisión aquí también es rebajada. Este escaneo puede ser utilizado en una red rápida, en un entorno local muy rápido.
• Aggresive –T4: Esta plantilla espera solo 1,25 segundos para obtener una respuesta. La diferencia entre el envío de paquetes es de 10 milisegundos.
• Normal –T3: Esta plantilla es la de por defecto.
• Polite –T2: Esta plantilla se utiliza para enviar paquetes rápidamente. La diferencia entre el envío de paquetes es de 0,4 segundos.
• Sneaky –T1: Esta plantilla se utiliza para enviar paquetes rápidamente pero más lento que un Normal o Polite Scan. La diferencia entre el envío de paquetes es de 15 segundos. 
• Paranoid –T0: Esta plantilla tiene una diferencia entre envío de paquetes de 5 minutos. Genera muy poco ruido, pero estamos metiendo una diferencia entre paquetes muy grande.
En la imagen se puede ver la ejecución de –T2, -T1 y –T0. Se pueden apreciar las diferencias en tiempo de cada escaneo.

Figura 4: Pruebas con -T2, -T1 y -T0

Empezamos a bloquear: Bloqueando –T5

En nuestra máquina GNU/Linux Ubuntu con iptables añadimos estas reglas:
iptables -I INPUT -p tcp -m state --state NEW -m recent --set 
iptables -I INPUT -p tcp -m state --state NEW -m recent --update --seconds 1 --hitcount 1 -j DROP
Como podemos ver en la siguiente imagen, la primera petición se responde, pero las siguientes no tienen margen, como indica la regla, por lo que como no ha pasado el tiempo de un segundo entre peticiones se filtra el paquete.

Figura 5: Resultado con un -T5. Se detectan los servicios.

Como la regla tiene 1 segundo entre peticiones, el bypass es realmente sencillo. Se puede hacer un bypass con el propio –T5 a través de los reintentos. Cada reintento consume tiempo por lo que si aplicamos reintentos podemos superar esos segundos de bypass. Con la opción –max-retries [número de reintentos].

Figura 6: Se salta igualmente

En este caso, también podíamos utilizar las otras plantillas de la –T4 a la –T0. Esto es debido al poco tiempo indicando en el parámetro –seconds de iptables.

Bloqueando –T4, -T3 (modo por defecto) y –T2

Ahora vamos a aplicar nuevas reglas para bloquear estas plantillas de tiempo. Si quisiéramos bloquear –T1 ampliaríamos en más segundos. Como se puede ver el juego es sencillo.
iptables -I INPUT -p tcp -m state --state NEW -m recent --set 
iptables -I INPUT -p tcp -m state --state NEW -m recent --update --seconds 3 --hitcount 1 -j DROP
En la imagen se puede ver cómo se bloquea o filtran las peticiones con –T4, mientras que si se utilizada un –T1 y se tardan 60 segundos para escanear 3 puertos, se obtiene respuesta del estado de los puertos.

Figura 7: Se tarda 60 segundos para escanear tres puertos

Si en las reglas anteriores metemos como valor 100 al parámetro –seconds, iptables hará DROP sobre los paquetes de la plantilla –T1, lo que dificultaría mucho el proceso de scanning. Este bypass, a estas alturas del artículo ya se puede hacer uno a la idea de que será usando la plantilla –T0.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González

Entrada destacada

MyPublicInbox: Unos perfiles de artistas en el mundo del cómic @salvadorlarroca @nikotxan @blowearts @0xWord @respetocanas @celspinol

La plataforma de MyPublicInbox sigue creciendo, ya cuenta con más de 600 usuarios, lo que es una bonita sorpresa para todos nosotros. En ...

Entradas populares