2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"

Ya os he contado los trabajos que hemos venido haciendo con respecto a los Second Channels, ahora toca hablar de la parte de cómo protegerse contra los ataques en redes IPv4&IPv6. Ni que decir hay que en ElevenPaths, y en mi equipo de Ideas Locas de CDO trabajamos de continuo con todos ellos y hablamos largo y tendido. Desde ataques de Network Packet Manipulation, hasta ataques de phishing homográficos como los PunnyCodes, pasando por los procesos de Ethical Hacking con SSLStrip2 y Delorean o las investigaciones de HSTS, HPKP y Certificate Pinning.

Figura 11: 2FWB: Second Factor Web Browsing
[Parte 2 de 4] "Network Attacks"

Esto hace que la preocupación cuando Mi Hacker o Mi Survivor utilizan mi equipo en una red para conectarse a buscar algo en Internet sea máxima. Me preocupa y, además de fortificar el end-point, reviso periódicamente todo tipo de detalles para asegurarme que se están conectando al sitio correcto, que no hay ninguna inyección de scripts, que el DNS ha devuelto la dirección correcta, que el certificado digital es el que debe, etcétera. Verificaciones que seguramente también hacéis vosotros en vuestro día a día cuando navegáis por Internet.

Conexión Segura & SmartWiFi

Una de las primeras cosas que he hecho ha sido activar el servicio de Conexión Segura en casa. Este servicio permite que toda la navegación que se produce a través la conexión WiFi y la línea de fibra en los hogares con Movistar Fusión, sea analizado (sin romper HTTPs). Como cualquier servicio de seguridad no te da el 100% de garantías, pero sí que te permite añadir una capa de protección a la navegación y filtrar dominios maliciosos, o ataques comunes.

Figura 12: Gestión de Conexión Segura desde SmartWiFi

Este servicio, que se puede activar desde la app de SmartWiFi de forma gratuita para toda la navegación en la WiFi de Movistar, ha detectado ya que la mitad de los hogares, en los cientos de miles de navegaciones que están protegidas a día de hoy, hayan pasado por un contenido malicioso que ha sido bloqueado. Esto es un montón de peligros quitado. Un dominio que sirve un ransomware y es detectado, se bloquea para todos los clientes Movistar Fusión con Conexión Segura y evita que se expanda.

Figura 13: Gestión de seguridad de red WiFi con SmartWiFi

Es una capa de protección transparente para los hogares, y que yo tengo puesto a todos los familiares y amigos. Con un clic estás más protegido por defecto aplicando la seguridad desde un sitio estratégico, la red por la que circula el tráfico.

Un "Second Channel" para verificar el tráfico

Dicho esto, aún me queda el riesgo de todos ataques de red que se produzcan en la red local, o aquellos ataques al end-point que vengan por canales cifrados, o que no sean detectados por la solución EDR (Endpoint Detection and Response). En todos esos caso, además de hacer una fortificación del puesto de trabajo - recomendable el libro de Sergio de los Santos (@ssantosv) "Máxima Seguridad en Windows 4ª Edición" - queda la revisión manual de los mensajes de alerta, de los detalles de las conexiones, etcétera.

Figura 14: Máxima seguridad en Windows [4ª Edición]

Es decir, navegar de forma conjunta con ellas para ver qué está pasando en el equipo con un ojo crítico con el que buscar hasta el más mínimo detalle que pueda ser el indicador de un ataque. Y eso no escala. Mi tiempo no es infinito, y no puedo hacer todas las comprobaciones manualmente siempre, así que había que automatizar este proceso.

Verificar todo significaba estar siempre sentado a su lado y ver todo lo que pasaba. Pero, ¿y si para revisar todo en vez de estar sentado en su mismo equipo usamos de manera continua dos canales? De esta forma podríamos automatizar en otro equipo las verificaciones de "papapete" para saber si estamos sufriendo un ataque de red.

Figura 15: Idea detrás de 2FWB: Second Factor Web Browsing

La primera idea que se me vino a la cabeza fue que estaría bien tener un equipo con dos tarjetas de red, y tener siempre una conexión a él para ir recibiendo en la pantalla lo que está viendo en su navegación. Algo así como los equipos de "manos remotas" que tenemos en muchos equipos importantes en la red de comunicaciones.

Pero la mayoría de los portátiles - como la Microsoft Surface que le tengo puesta a Mi Hacker - viene con la WiFi solo. Podría comprar una segunda tarjeta, pero debería montar en todo momento una red y conectarla a mi equipo también con dos tarjetas, y además mi equipo debería conectarse a otra red distinta. Esto podría ser fácil, porque yo me suelo conectar vía "hotspot" a mi teléfono móvil vía BlueTooth. No es casualidad que se me ocurriera la malvada idea del DirtyTooth que presentamos en RootedCON 2017, era un power-user de ello.


Figura 16: DirtyTooth en RootedCON 2017
Pero para montar esta verificación de la navegación en tiempo real era demasiado lío el tener que poner el equipo de Mi Hacker o de Mi Survivor conectado al mío por una segunda red creada entre ellos y luego conectar mi terminal vía BluetTooth para usar una conexión de red LTE - que vistos los ataques a redes móviles usar otra red no es del todo seguro - que permitiera tener una segunda visión de los servicios de Internet a los que se conectan y verificar que todo está ok.

¿Y si lo simplificamos?

Al final, si tenemos una conexión vía BlueTooth+2G/3G/4G a Internet tenemos siempre un Second Channel en todos los equipos, y la verdad es que yo siempre llevo mi smartphone y todos los equipos que usamos vienen con BlueTooth. Es fácil conectar el equipo que usan mis hijas con mi SmartPhone utilizando BlueTooth y ver dónde están navegando y qué están viendo, para poder comprobar que lo que están recibiendo es lo que deben recibir.

Esta comprobación podríamos hacerla desde el propio termina móvil donde haríamos las comprobaciones, o mucho mejor, haciéndolo desde un servicio en la nube que haría esas verificaciones para todas las instancias de esta app. Las dos arquitecturas tienen ventajas e inconvenientes. Tener toda la lógica en la cloud simplifica la construcción, pero da un elemento más en el sistema que podría ser atacado en un posible esquema de DDOS al servidor en cloud que recoge la inteligencia para detectar los ataques.

Figura 17: Arquitectura de 2FWB con protección de app en smartphone

Por otro lado, tener toda la lógica en el terminal móvil obliga a desplegar nuevas apps o nueva lógica al dispositivo cuando hay nuevas reglas de detección de ataques. Pero hace el atacante deba conseguir vulnerar la red del equipo desde el que se navega a Internet más la conexión a Internet del smartphone. Un doble ataque más difícil de realizar, sobre todo si no estás cerca geográficamente para atacar al dispositivo móvil - ver libro de Ataques a redes de comunicaciones móviles GSM/2G/3G/4G de nuestros amigos de Layak -.

Figura 18: Libro de hacking y seguridad en comunicaciones móviles
GSM/GPRS/UMTS/LTE (2G/3G/4G)

Con es doble canal usando una conexión a Internet de navegación vía red WiFi o Ethernet, y un segundo canal vía BlueTooth+3G/4G, podríamos realizar dos conexiones al mismo servidor desde dos puntos diferentes, usando dos redes distintas. Usar este doble canal tiene cierta similitud con el doble factor de autenticación en los sistemas de login, donde se busca que el atacante deba vulnerar dos elementos distintos para aumentar su dificultad. En este caso, el tráfico del primer canal debe generar respuestas similares y con propiedades similares al que se obtiene por el segundo canal y si no, generamos una alerta.

Esta idea, permite detectar ataques de red en el canal primario, como un DNS Spoofing, un ataque de Phishing, un dominio marcado en un servicio de seguridad como peligroso por usar ficheros JS de  cryptominnig, ataques de bypass HSTS, o de Certificado Falso. Solo necesitamos saber qué es lo que se está recibiendo como respuesta en el canal primario y hacer una comprobación en el canal secundario.

Arquitectura en el end-point

Para conseguir los datos de seguridad útiles para la detección de ataques, necesitamos en el equipo a proteger tener una extensión en el navegador que nos permita capturar las cabeceras HTTP y datos del DOM de la página HTML de la respuesta, más alguna información de red que recibimos del sistema, como direcciones IP resueltas por el DNS, datos del DNS que responde, tablas ARP, etcétera. Toda esta información se captura usando dos elementos.

- Extensión de navegador (en este caso Google Chrome): Este elemento extrae la información que necesitamos del D.O.M. (Document Object Model, y se lo envía al Agente. Además, recibe del Agente las ordenes de bloquear o no bloquear la sesión de navegación con un mensaje de alerta.

- Agente en el sistema (en este caso escrito en Node JS): Establece la conexión vía BlueTooth con el 2FWB y le envía la información recibida de la Extensión del navegador, además de información del sistema para que el 2FWB le diga el resultado de la evaluación. Después, recibe la información desde el 2FWB y manda las órdenes a la Extensión del Navegador para que bloquee o no la sesión.

Con esta arquitectura, tenemos la ocasión de que las verificaciones que haría yo mismo de forma manual para comprobar que está viendo lo que debe de ver en cada momento, de tal manera que si algo no cuadra, o se detecta un fallo en el certificado, el nombre del dominio, la dirección IP del servidor, los ficheros incrustados en el DOM del documento, etcétera, se bloquea la navegación con un aviso que llega a la pestaña del navegador en la que está visualizando el contenido.

View this post on Instagram

Second Factor Web Browsing en #rootedcon }:)

A post shared by Chema Alonso (@chemaalonso) on Mar 29, 2019 at 8:54am PDT

He de decir que hicimos pruebas con BluetTooth Low Energy y con un solo componente basado en la extensión de Google Chrome, pero la realidad es que teníamos dos problemas con esto:

1.- Volumen de datos: Con el protocolo BLE el volumen de datos que podíamos enviar era muy limitado y lo que necesitamos enviar y a la velocidad que lo necesitábamos nos limitaba mucho a la hora de hacer verificaciones de seguridad.

2.- Datos de red del sistema: Para poder detectar ciertos ataques como ARP Spoofing, ataques MITM en IPv6 con SLAAC, etcétera, necesitábamos información del sistema operativo así que necesitábamos un agente en el sistema.

Así que por eso se eligió usar un perfil BlueTooth desde el Agente y tener la extensión de Google Chrome para acceder a la información de la web que se estaba navegando y ver los datos en tiempo real del DOM. Tener las cabeceras HTTP, información del certificado, los archivos scripts inyectados, etcétera es algo que desde la extensión es posible realizar.

Saludos Malignos!

*****************************************************************************************
- 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
- 2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"
- 2FWB: Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"
- 2FWB: Second Factor Web Browsing [Parte 4 de 4] "Modo Centinela"
*****************************************************************************************

SecDevOps: Una explicación en cinco minutos (o poco más) #SecDevOps

SecDevOps, DevOpsSec, DevSecOps o como lo quieras llamar, supone un gran avance en el diseño y la programación de código seguro. Nuestro libro Docker: SecDevOps estaba centrado en la importancia de este paradigma dentro del diseño de una aplicación hoy en día. Vamos a intentar explicarlo en este post de la forma más simplificada posible siguiendo los principales pasos de este nuevo paradigma que más vale que domines si quieres estar en equipos de creación de tecnología de alto rendimiento, pues se aplica en todos ellos.

Figura 1: SecDevOps: Una explicación en cinco minutos (o poco más) #SecDevOps

DevOps es un cambio en la forma y la cultura de trabajo entre programadores o desarrolladores (“Dev”, developers) y el personal encargado de las operaciones (“Ops”, operations) o mejor dicho de los encargados de la infraestructura (como por ejemplo los administradores de sistemas). Al principio no existía una estrecha relación entre ellos, y una gran mayoría de ocasiones, acarreaba problemas como por ejemplo que la aplicación no funcionara o la típica frase “pues en mi máquina funciona” que tanto hemos oído.

Figura 2: Libro de Docker:SecDevOps en 0xWord de

Fran Ramírez, Elías Grande y Rafael Troncoso

Uno de los pilares de DevOps no es más que acercar a ambos grupos para que al fin y al cabo trabajen juntos y así rellenar ese hueco que antes existía entre ambos departamentos, en definitiva: "Colaboración".

De esta forma el desarrollador, tendrá mayor conocimiento sobre la infraestructura donde correrá su aplicación, y los de operaciones, los recursos que la aplicación necesitará. Y las ventajas son enormes. Por ejemplo, el técnico de operaciones sabrá en todo momento qué librerías/entorno de ejecución, necesitaría para satisfacer las necesidades de la aplicación, y así detectar aquellas que faltan o que son necesarias.

Otro de los pilares de DevOps, es la automatización. En general, la automatización debería aplicarse a todo el proceso. Todo esto incluso implica a la provisión de entornos y recursos. De esta forma llegamos a otros de los pilares que es el feedback o retroalimentación continua. Así podremos observar no solo errores, sino hasta la evolución misma de la aplicación. En definitiva, el desarrollo ya no será sólo cosa de uno, ahora entrarán más actores en el proceso.

Ciclo de vida DevOps

En la siguiente imagen podemos ver el ciclo de vida “típico” de una aplicación en un entorno DevOps.

Figura 3: Modelo clásico DevOps

En “Plan” se recogen los requerimientos de la aplicación, “Code” es donde se comienza a escribir código, “Test” es la fase de ejecución pruebas, “Package” es donde empaquetamos la aplicación para su despliegue (por ejemplo, un contenedor Docker) y luego “Release” es cuando subimos el artefacto (como el contenedor Docker del ejemplo anterior). En la siguiente fase “Deploy” es cuando se comienzan a aplicar los controles de seguridad.

Demasiado tarde. El equipo encargado de la seguridad (“Sec”, Security) encontrará problemas en esta fase reportándolos al equipo de desarrollo y esto provocará un tapón o retraso en los tiempos de entrega. Pero no sólo eso, una vez aplicados los parches o soluciones, estos deberán de ser probados de nuevo o simplemente se darán por resueltos sin estarlo al 100%, lo cual afectará a la calidad y seguridad del producto final. Hay que aplicar una mitigación a este problema, y se llama SecDevOps.

Ciclo de vida: SecDevOps

Simplemente, consiste mover la aplicación de los controles de seguridad desde la primera fase, en lo que se denomina “Shift Left” o desplazamiento hacia la izquierda. Este sería el esquema visto anteriormente adaptado a SecDevOps:

Figura 4: Nuevo modelo SecDevOps

Y visto esto, la pregunta es ¿Qué funciones hay que realizar de Sec en cada una de las fases de este nuevo modelo de ciclo de vida? Pues vamos a verlo.

“Plan” o planificación.

En esta fase es donde se analiza el modelo de amenazas o Threat Modeling. Por ejemplo autenticación de usuarios, servidores externos, cifrado, etcétera. Aquí se generarán “tickets” también conocidos como “stories” destinados específicamente a la seguridad.

Figura 4: Evil User Stories

Algunas herramientas o recursos son OWASP Application Threat Modeling o Don´t forget EVIL user stories, que básicamente es lo que hacen muchos hackers en sus procesos de research.

 “Code” o programación.

El técnico del equipo de seguridad se convierte en formador y proveedor explicando e informando al equipo de desarrollo cómo utilizar ciertas herramientas de seguridad (análisis de código estático), pero sobre todo a familiarizar al programador términos relacionado con la seguridad como por ejemplo qué son los ataques SQLi, XSS, DDoS, etcétera. Vamos, en el mundo de aplicaciones web debes conocerte los temas de Hacking de Aplicaciones Web: SQL Injection, de Hacking Web Technologies y de Hacking de Aplicaciones Web: Client-Side Attacks al dedillo.

Figura 5: Hacking Web Technologies

Aquí también entrarían herramientas como como Git-Secrets o Git-Hound pueden ser algunas de las que se podrían utilizar, las cuales permiten analizar el envío de un git commit no contiene datos críticos como contraseñas, tokens, etcétera.

“Test” o pruebas.

Aquí se ejecutan los tests unitarios y de integración, pero en el caso que nos ocupa, aquí nos enfocaríamos a tests que verifiquen aspectos de seguridad. Estas pruebas deberían de ser totalmente automáticas para de esa forma no dejar pasar ningún problema de los detectados en la fase principal (detección temprana). Las herramientas para esta fase son varias y dependen del entorno donde se realiza el desarrollo. Tal vez en otros artículos podamos ir viendo algunos ejemplos.

“Package” o empaquetado.

Aquí es donde se unifica todo el código en un sólo paquete o artefacto como por ejemplo un programa compilado, etc. Un escaneo de seguridad para las librerías externas donde se detecten posibles vulnerabilidades, sería la operativa de seguridad a aplicar. En el caso de Docker es el momento de comprobar la seguridad de las imágenes. 

Figura 6: Dagda Docker Security Suite 

Para Ruby, por poner algún ejemplo, existen herramientas como bundler-audit, para Docker tenemos Dagda (creada por nuestro colega y co-autor del mismo libro, Elías Grande) o Docker Bench, para Node tenemos nsp, etcétera.

“Release” o entrega.

Aquí es donde ponemos nuestro artefacto en algún repositorio central desde el cual será consumido durante la fase de despliegue. En el caso de Docker, muchos registros ofrecen escáneres de seguridad ya integrados que escasearán nuestra image, en este caso se podría evitar el escaneo de la imagen en la fase anterior.

“Deploy” o despliegue.

La aplicación se despliega o se instala en un entorno preparado para probarla. Podrán existir varios entornos de pruebas específicos para que cada equipo pueda trabajar en una parte concreta del programa. Esta fase se podría llamar también fase de pre-producción. 

Figura 7: Ethical Hacking

Aquí es donde aparece el equipo de QA para realizar los test de calidad y es donde se realiza un análisis dinámico de la aplicación (XSS, SQLi, SSL habilitado, etcétera). Las herramientas del equipo de seguridad son las típicas de cualquier fase de Ethical Hacking, como por ejemplo nmap, sqlmap, Nikto, o la FOCA.

“Operate”, fase de operación.

La aplicación ya está desplegada y funcionando. Entonces es ahora cuando hay que probar la seguridad realizando pruebas RedTeam de seguridad, resiliencia (Chaos Engineering, Circuit Breaker, etc.), etcetera.

View this post on Instagram

Esta es la portada del nuevo libro de 0xWord "CISO: El Red Team de la Empresa" que ha diseñado Rodol. Lo tienes disponible en https://0xword.com/es/libros/114-chief-information-security-office-el-red-team-de-la-empresa.html

A post shared by Chema Alonso (@chemaalonso) on Jun 22, 2018 at 11:58pm PDT

“Monitor” o monitorización. 

Partiendo de la premisa que los logs están centralizados (práctica más que recomendable de seguridad), es cuando estos se analizan de forma automática para detectar posibles ataques como XSS, SQLi, DoS, DDoS, etcétera o incluso situaciones de stress en los equipos como falta de memoria o uso de CPU excesiva. Splunk o Devo de licencias comerciales o ELK sean posiblemente las herramienta más conocidas de las utilizadas en esta fase.

Pues esto es todo, esperamos que este breve artículo sirva de introducción al SecDevOps y entre todos consigamos realizar aplicaciones más seguras.

Fran Ramírez,  es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Rafael Troncoso es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Cómo integrar Latch Cloud TOTP en aplicaciones #NodeJS (& .NET)

La charla de esta semana en las CodeTalk For Developers que hacemos en ElevenPaths ha versado sobre cómo sacare más partido a Latch, al tiempo que fortificas tus aplicaciones web. En este caso, hemos elegido los sistemas de Latch Cloud TOTP para fortificar las identidades que son utilizadas en aplicaciones NodeJS y .NET.

Figura 1: Cómo integrar Latch Cloud TOTP en aplicaciones NodeJS (& .NET)

La tecnología NodeJS se ha puesto muy de moda, gracias a su versatilidad y comodidad en el desarrollo de aplicaciones, tanto web como escritorio, así que hemos decidido dedicar una sesión para los amantes del código para que integren sistemas de Time One-Time Password server side, que estén sincronizados con Latch Cloud TOTP.

Figura 2: CodeTalk sobre Cómo integrar Latch Cloud TOTP en apps NodeJS (& .NET)

El seminario tiene una hora y media de duración, así que relájate, disfruta, y si has programado ya alguna app en NodeJS o .NET no te la pierdas. Verás lo rápido que se puede mejorar la seguridad de tus aplicaciones con Latch Cloud TOTP.

Saludos Malignos!

Cursos, Charlas y Conferencias para esta misma semana @elevenpaths @0xWord #NodeJS #hacking #pentesting

Un domingo más me voy a tomar un rato en dejaros la agenda de la semana que se nos viene encima, por si alguna de las cosas que hay planificadas no las tienes en el radar y te apetece formar parte de ellas. Yo solo tengo una pequeña participación en un ciclo de charlas privadas, así que no estaré en ningún evento o acto en los próximos días.

Figura 1: Cursos, Charlas y Conferencias para esta misma semana

Aquí tenéis las actividades en las que desde LUCA D3 (Data-Driven Decisions), ElevenPaths o 0xWord vamos a estar colaborando de alguna de las formas, además de algún otro evento que creo que debes tener en el radar. Toma nota.

03 de Abril: HackersWeeb en  [Málaga]

Nuestro compañero Sergio de los Santos, en la Universidad de Málaga dará una conferencia gratuita mañana a las 10:45 sobre los protocolos HSTS y HKPK de seguridad que intentan garantizar la integridad y la autenticidad de las conexiones HTTPs. Tienes tiempo para prepararte e ir a ver esta pedazo de charla.

Figura 2: HPKP y HSTS: ¡Lo estáis haciendo mal! en Málaga

Justo después de Sergio de los Santos, nuestro compañero del Lab de ElevenPaths José Torres dará una sesión dedicado al malware de macros en documentos Office que tan popular se ha vuelto estos días. 

Figura 3: Macro Malware: From Russia with Love

Además, la UMA continúa con un buen montón de conferencias durante toda la semana, así que no te pierdas la agenda completa si estás en Málaga o las proximidades. Aquí tienes el ciclo completo de charlas de la HackersWeek de la UMA.

También este lunes, estará nuestro compañero Sebas en el ICAO Cybersecurity Summit en Dubai, pero a lo mejor os pilla un poco más lejos para poder asistir.

03 de Abril: Curso Online de Hacking con Python [Online]

Mañana lunes 3 de Abril - pero tienes abierta toda la semana el proceso de inscripción - da comienzo la nueva edición del Curso Online de Hacking con Python en The Security Sentinel. 

Figura 4: Curso Online de hacking con Python en The Security Sentinel

Un curso de 200 horas en las que los asistentes recibirán como material de apoyo nuestro libro de Hacking con Python. Tienes un detallado programa de 9 semanas de trabajo en la web del mismo.

05 de Abril: Curso online de Hardening Sistemas Windows [Online]

El miércoles 4 de Abril tienes la opción de comenzar el Curso Online en Hackers Club centrado en la fortificación o hardening de sistemas Windows. El profesor es Ángel Álvarez, autor del libro de 0xWord dedicado a "Windows 2016: Configuración, Administración y Seguridad" que será entregado a todos los asistentes como parte del material de la formación. Toda la info en la web del curso.

Figura 5: Curso Online de Hardening de Sistemas Windows

06 de Abril: Quebrando aplicaciones web [Online]

El jueves, por la tarde, nueva edición de una ElevenPaths Talk, en este caso por parte de nuestros CSA Pablo San Emeterio y Diego Espitia, que van a dedicar a cómo quebrar la seguridad de aplicaciones en procesos de Ethical Hacking.

Figura 6: Seminario Online Gratuito "Quebrando aplicaciones"

Puedes debatir con ellos, antes y después del seminario, en la Comunidad de ElevenPaths. El seminario es gratuito y puedes apuntarte en la web de las ElevenPaths Talks.

07 de Abril: Curso Online de Seguridad en Redes [Online]

El viernes, también en The Security Sentinel, tendrás una nueva edición del Curso Online de Seguridad en Redes. Con 8 semanas de trabajo, y el libro de Seguridad en Sistemas Industriales e Infraestructuras Críticas como apoyo, podrás aprender mucho sobre la seguridad en de las redes de comunicaciones hoy en día. Tienes el temario y toda la información en la web del curso.

Figura 7: Curso Online de Seguridad en Redes

07 de Abril: NodeCONF 2017 [Barcelona]

Me ha llamado la atención este evento, sobre NodeJS en Barcelona. Es un evento en el que se verán muchas formas de sacarle partido a NodeJS desde la creación de creación de bots usando Amazon Lex, pasando por la creación de aplicaciones de escritorio para macOS o Windows usando NodeJS con Electron, crear proxies o gestionar HTTP/2.0. La agenda promete:

Figura 8: Agenda de la NodeCONF en Barcelona

Y esto es todo lo que os he traído para la agenda, espero que algo te motive y no dejes pasar una semana sin aprender algo nuevo que te ayude a entender mejor este mundo de la tecnología y disfrutar más de tu pasión.

Saludos Malignos!

Brosec: Una mochila de pentester para almacenar payloads y personalizarlos automáticamente

Brosec es una herramienta que permite utilizar y generar diferentes payloads en diferentes ambientes o escenarios. Es decir, cuando estamos en plena auditoria o pentesting podemos necesitar código ejecutable en distintas plataformas. Brosec reúne esos códigos o scripts necesarios para poder explotar debilidades y vulnerabilidades. Está escrito en Nodejs y permite generar y configurar shells inversas en lenguajes como Python, Perl, Powershell, etcétera. Pero sin dejar de lado algunas otros payloads para web o, incluso, exfiltration data como pudimos ver en el pasado con DET.

Figura 1: Brosec: Una mochila de pentester para almacenar payloads y personalizarlos automáticamente

Brosec puede ser descargado desde su Github. Una vez descargado con git clone, necesita instalar una serie de dependencias para poder ser ejecutado correctamente. En primer lugar debemos ejecutar npm config set registry http://registry.npmjs.org. Posteriormente, se debe ejecutar npm install –g n. A posteriori, n latest. Para finalizar npm install y tendremos disponible la consola de Brosec.

Figura 2: Proceso de instalación de Brosec

Brosec tiene dos modos de ejecución. Con el primero se le pueden pasar por parámetro las acciones a realizar. Con el segundo, se puede ejecutar sin más el binario y acceder a un menú dónde se nos indican diferentes acciones, tal y como se puede visualizar en la imagen siguiente. Las opciones que tenemos disponibles en Brosec son:

Figura 3: Menú de opciones de Brosec

En la parte de (1) Information Gathering nos podemos encontrar la posibilidad de crear código en distintas plataformas para recopilar información de un sistema. En el caso de (2) Linux y (3)Windows tenemos la posibilidad de crear código Powershell, Python, WMI, etcétera, con el fin de ejecutar y obtener beneficio en la máquina. En el caso del apartado (4)Web, podemos generar payloads para SQLi y XXE. En (5) Miscelánea, podemos generar shells inversas en diferentes escenarios. El que quizá más me haya llamado la atención es haga uso del popular entorno AWK, el cual es una herramienta potente para el exploiting de sistemas GNU/Linux.

Brosec tiene un apartado de configuración, al cual se puede acceder ejecutando config sobre la línea de comandos. Para poder configurar parámetros como LHOST, LPORT, RHOST, RPORT, PATH, USER se debe indicar set [parámetro] [valor]. Estos parámetros se utilizarán cuando Brosec genere Pyaloads que los necesiten.

Figura 4: Configuración de parámetros en Brosec para los payloads

Ejemplo: Creando payloads en Powershell

Si elegimos la opción de plataforma Windows podemos ver diferentes opciones. Cada categoría genera acciones interesantes que se pueden ejecutar en esos ámbitos de Windows. Por ejemplo, si pulsamos sobre System Info podremos generar instrucciones o comandos útiles para obtener información en un sistema Windows. Esto también nos puede servir de biblioteca en un pentest. Hay que tener en cuenta que Brosec se encuentra en la versión 0.0.1, por lo que el proyecto está comenzando, pero ya dispone de una gran serie de acciones que se pueden generar y que pueden ayudar a un pentester en un proceso de ethical hacking.

Figura 5: Opciones del menú Windows en Brosec

Para ver un ejemplo, si pulsamos sobre el (5) de Powershell podemos visualizar las opciones que nos ofrecen. Como podemos ver en la imagen siguiente, tenemos el código que debemos ejecutar en una Powershell, o lo que puede ser mejor, en un payload que ejecuta una Powershell, en Metasploit tenemos alguno. Las opciones que nos proporcionan pueden ser interesantes si queremos descargar algún script o funcionalidad concreta y no podemos meterla en el equipo de otra manera.

Figura 6: Código disponible para configurar el payload con Brosec

Como se puede ver a continuación, tenemos un script creado. En este caso el script resultante se descargará código en remoto del parámetro URI que le hayamos indicado.

Figura 7: Payload generado con Brosec

Esta funcionalidad es muy interesante, y se pudo comprobar con la P.o.C. de PSBot, el poder que proporciona una Powershell a la hora de evadir firmas de soluciones antimalware y la posibilidad de ejecutar código de forma dinámica.

Ejemplo: Creando un HTTP Simple y FTP Fast

En algunas ocasiones es necesario montar un servidor HTTP y un FTP. En el lenguaje Python se dispone de SimpleHTTP y en Brosec se proporciona la forma de montar un servidor web de forma, casi, aún más sencilla. Para ver la facilidad de crear o disponer un servidor HTTP y FTP se pueden ver las siguientes imágenes.

Figura 8: Configurando un servidor HTTP con la aplicación bros

Como se puede apreciar, se invoca la aplicación bros y se pasa como parámetros http o ftp. En el caso del ftp se puede utilizar para la exilftración de datos en una organización.

Figura 9: Configuracndo un servidor FTP con bros

Ejemplo: Reverse Shells

Generar código de shells inversas puede ser muy útil, por ejemplo para exiltrar datos o para proporcionar el control remoto de una máquina fuera de los dominios de la organización durante la realización del pentesting. A continuación se muestran, como en el apartado (5) Miscelánea, se pueden conseguir diferentes tipos de códigos, en distintos lenguajes, con el objetivo de crear sesiones inversas.

Figura 10: Reverse shells disponibles

Aparte de las shells inversas, podemos ver el código que se puede obtener para exfiltrar datos. Se utiliza Python, principalmente. En algunos casos la herramienta genera instrucciones poco reales o poco usables. Si observamos en el caso (3) para descargar o subir un archivo vía SCP podría ser detectado por cualquier sistema de protección. Por otro lado, el uso de DET frente a Brosec como herramienta de exfiltración de datos no tiene ningún color. DET está mucho más orientada a no ser detectada.

Figura 11: Opciones de Exfiltración en Brosec

En el apartado (4) Web podemos encontrar payloads o instrucciones de ejecución para vulnerabilidades XML y SQLi. No muy extensa esta parte por ahora.

Figura 12: Opciones de explotación de vulnerabilidades web 

Como se puede ver Brosec aporta cierto conocimiento y comandos e instrucciones que pueden ser útiles en un momento dado. El objetivo de la herramienta es personalizar los parámetros en los casos necesarios y aportar el conocimiento en un momento dato que sea necesario.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”