El próximo 26 de Octubre participaremos en las Jornadas de Ciberseguridad Industrial @Araba40




El próximo viernes 26 de Octubre tendrán lugar en Vitoria-Gasteiz las Jornadas de Ciberseguridad Industrial Araba 4.0, donde nuestro CEO y CSO de Osane, Juan Antonio Calles y Diego León, responsable del área de Seguridad Ofensiva de Zerolynx y de Osane, impartirán una interesante conferencia sobre ciberseguridad industrial y red team.

El evento tendrá lugar en el parque tecnológico de Álava y transcurrirá entre las 9:15h y las 14:00h. Junto a nuestros expertos asistirán reputados profesionales del campo de la ciberseguridad, como Román Ramírez, fundador y anterior presidente de RootedCON y Carmen Torrano, doctora e investigadora en ciberseguridad de Telefónica, así como numerosos profesionales del sector industrial de compañías como Mercedes Benz, Michelin, Aernnova Aerospace o Tubacex

A continuación podréis ver el programa completo del evento:

PROGRAMA

08:45  Acreditaciones

09:15  Apertura institucional
  • D. Ramiro GonzálezDiputado General de Álava
  • Gabriel Uriarte, representante del Grupo ARABA 4.0 Taldea
09:30  ¿Estamos preparados para tanta conectividad?
Conectarse es una necesidad, pero ¿qué implicaciones tiene para la seguridad de las empresas? ¿Cuáles son los riesgos a los que nos enfrentamos? ¿Cómo pueden prepararse las pymes industriales ante este reto?
  • Carmen Torrano, Senior Cybersecurity Researcher en Eleven Paths (Telefónica)
  • Román Ramírez, fundador de RootedCON
10:00  Mesa redonda: Demandas de las empresas tractoras del Territorio en cuanto a ciberseguridad
Las grandes empresas alavesas ya están adoptando las medidas necesarias para garantizar la continuidad de su negocio, pero ¿qué ocurre con sus proveedores? ¿Qué es necesario que estos hagan en materia de ciberseguridad para poder seguir trabajando con ellas?
  • Juan Mocoroa, Responsable de Ingeniería de Mercedes Benz en Vitoria-Gasteiz
  • Ricardo Vázquez, Director Técnico de Michelin en Vitoria-Gasteiz
  • Javier Herrero, VP of Change Management & IT at Aernnova Aerospace
  • Javier González, CDO Chief Digital Officer at Tubacex
Modera: Ana Ayerbe, Directora IT Competitiveness en Tecnalia

11:00  Café y visita a la zona de exposición de empresas locales relacionadas con la ciberseguridad

11:30  Infraestructuras de Ciberseguridad en Álava
Álava se ha convertido en un territorio referente en materia de ciberseguridad. En los últimos meses, se han puesto en marcha diversas infraestructuras para ayudar a las empresas a protegerse o defenderse de ataques informáticos.
  • Asier Martínez, Head of CSIRT Services in Basque Cybersecurity Centre (BCSC)
  • Óscar Lage, Responsable de Ciberseguridad de Tecnalia
  • Joseba Alustiza, Consultor de Seguridad en Encriptia
12:15  Continuidad de negocio: análisis de los riesgos y oportunidades desde la Industria 4.0
Álava no sólo cuenta con infraestructuras para la ciberseguridad si no que en su tejido empresarial se cuenta con numerosas empresas que pueden ayudar a analizar los riesgos, vulnerabilidades y oportunidades a las PYMES alavesas.
  • Juantxu Mateos, Innovation and Business Development Manager at S21sec|Nextel
  • Amaia Santamaría, Responsable de Innovación y Mejora Continua en Odei
  • Eneritz Zubizarreta, Responsable de servicios en Globe Testing
12:45  Desplazamiento al edificio de Tecnalia y visita al site central del nodo de Ciberseguridad del BDIHI
  • Ejercicio de ciberataque y análisis de vulnerabilidad de las empresas: identificación de riesgo. Juan Antonio Calles, Director de Ciberseguridad en OSANE Consulting.
  • Escenarios de ciberataques: potencial del Ciber Range. Tecnalia.

14:00  Cierre

Red Teaming: terreno de pasiones, mitos y fantasías



Dentro de los servicios ofrecidos por las empresas de ciberseguridad, uno de los que más pasiones levanta es el de Red Teaming. Cada vez es más habitual escuchar este término en todo tipo de conferencias y artículos, con detalladas explicaciones sobre cómo saltarse la seguridad física de un entorno para colocar un implante hardware que nos permita conectarnos remotamente, con explicaciones de diversos ataques de ingeniería social y phishings a los empleados de una organización, o con listas y explicaciones sobre cómo usar los últimos “Living-Off-the-Land Binaries” o LOLBins, aplicaciones, scripts y librerías nativas que pueden ser usadas y abusadas para ejecutar código adicional, como podrían ser rundll32, regsvr32, msbuild, y muchísimas otras más. Sin embargo, ¿tenemos todos claro lo que significa Red Teaming?



Pruebas con Lolbins


Cuando un cliente solicita un análisis de vulnerabilidades, casi todos estaremos de acuerdo en que busca escanear una aplicación, servicio o infraestructura (interna o externa) con herramientas automáticas de detección de vulnerabilidades. Al final, el objetivo será conseguir un informe con todas las vulnerabilidades detectadas, que con suerte, nos entregarán limpio de falsos positivos, y podremos finalizar el proyecto. 

Cuando los clientes requieren un test de penetración, las cosas empiezan a dejar de estar tan claras y suele ser necesario aclarar qué busca exactamente el cliente. Bajo el mismo paraguas de “test de penetración” se suelen requerir una gran variedad de servicios: 

  • Una revisión completa (automática y manual) sobre una aplicación, estando el pentester en listas blancas, con el objetivo de detectar el mayor número posible de vulnerabilidades para su posterior corrección.
  • Una demostración sobre si somos capaces de penetrar en el perímetro de la organización a través de una aplicación con todas las defensas levantadas… en ocasiones bajo la premisa del "realismo". Eso sí, indicando que las denegaciones de servicio, la ingeniería social al personal, o los ataques a cualquiera de las otras 200 direcciones IP identificadas en la organización no están permitidas. Es decir, que se busca un escenario "realista" en el que el realismo consiste en que el atacante está limitado a atacar un único activo, altamente bastionado, monitorizado y protegido por todo tipo de soluciones de seguridad. Este tipo de proyectos, aunque necesarios para revisar, por ejemplo, la correcta configuración de las medidas de seguridad desplegadas para proteger un activo, desde luego no deberían ser justificados con el “realismo”, porque por todos es conocido que el adversario ataca siempre al eslabón más débil, y nunca al más protegido.
  • Una auditoría de seguridad interna con más o menos limitaciones, en la que se suelen permitir tanto el uso de equipos informáticos de los auditores, como de equipos plataformados por la organización. El objetivo es demostrar hasta qué punto lograrían penetrar, simulando por ejemplo, a un usuario que se convierta en malicioso. Este tipo de proyectos suelen acabar con el pentester alcanzando permisos de Domain/Enterprise Admin, desgraciadamente, con más frecuencia de la que debería.
  • Y cualquier combinación más o menos acertada de las anteriores.

Por este motivo, cuando empezamos a hablar de Pentesting siempre nos sentamos con el cliente para que nos explique su nivel de madurez percibido, qué busca exactamente conseguir a través del proyecto, e intentamos guiarle y sugerirle la forma de obtener el mayor beneficio frente a su inversión. 

Y finalmente llegamos al Red Teaming: terreno de pasiones, mitos y fantasías. Desconozco si es una cuestión de oportunismo, de curiosa fascinación ante la terminología militar que atrae a todo tipo de perfiles, o de falta de conocimiento y consenso alrededor del término, pero es en este terreno donde apreciamos mayor falta de precisión. ¿Tiene que ver todo esto con que cada vez más directores, managers y otros responsables en el lado del cliente reconozcan en privado que no están, para nada, del todo satisfechos con los servicios que les han ofrecido hasta el momento en este tipo de proyectos?  

Cuando se habla de Red Teaming con alguien, la respuesta suele derivar rápido a una suerte de proyectos de pentesting avanzado en el que no hay reglas, todo está dentro del alcance, y el equipo de seguridad puede hacer lo que desee para entrar hasta la cocina. Y a ser posible, en proyectos de larga duración con perfiles muy senior, debido a que van a tocar sin límites. Al menos, déjame que te garantice que no van a cometer ningún error que pueda impactar a tu negocio. Pero… ¿de verdad no hay reglas y todo está en el alcance? 

No solo puede, sino que debe haber reglas en cualquier proyecto de Red Teaming. 

¿De qué hablamos cuando decimos que no hay reglas? ¿De la posibilidad de utilizar ataques lógicos, físicos, e ingeniería social? En un proyecto de Red Teaming es posible evaluar cualquiera de esos planos de la seguridad de la organización de forma independiente, o una combinación de ellos, pero no tienen por qué incluirse en el proyecto para que se trate de un proyecto de Red Teaming.

No solo puede, sino que hay restricciones en cualquier proyecto de estas características.

¿Qué pretendemos con esta supuesta carencia de restricciones, emular el auténtico comportamiento de un adversario real, un auténtico APT? ¿Darle realismo al proyecto? Se sabe de actores maliciosos que han atacado a los activos personales de los empleados, como el correo electrónico o el ordenador personal, para así poder atacar a la organización. ¿Estará esto también dentro del alcance? También es cada vez más habitual atacar a los proveedores o a la cadena de suministro. A ver como explicamos a todos los proveedores para que firmen un consentimiento expreso..., ya no sólo para ser auditados, sino para recibir ataques sin límites, en cualquier momento y por parte de un equipo de seguridad avanzado. Suerte con esto de intentar modelar la auténtica ausencia de reglas que tienen los criminales de verdad o un grupo amparado por el estado, así como los recursos y tiempo del que ellos disponen.

¿Hace falta invertir tanto dinero para demostrar la obviedad de que sin reglas, con recursos y suficiente tiempo se pueden colar en casi cualquier sistema? La respuesta es ¡no!, no hace falta que se demuestre, ya que la respuesta os la podemos dar en este mismo artículo, ¡y gratis! Esto hace tiempo que está superado y se llama modelo de compromiso asumido. Es necesario asumir que se van a colar en un sistema y empezar a trabajar en las capacidades de monitorización, detección y respuesta de la organización. Se debe preparar el entorno interno para que, dando por hecho que se van a colar, su capacidad de movimiento esté muy restringida, que va a ser detectado lo antes posible, y que la respuesta ante dicha detección va a ser la adecuada.

Por tanto, es necesario realizar pentests para verificar que la seguridad lógica está debidamente implementada, es necesario realizar pentest físico para verificar que nadie puede saltarse el perímetro de seguridad de nuestras instalaciones, y es necesario evaluar la concienciación de nuestros empleados frente a ataques de ingeniería social. Por separado o todo a la vez. Pero si en un proyecto se te cuelan, te entregan un informe con la metodología y las vulnerabilidades explotadas, y acto seguido se acaba el proyecto, entonces difícilmente te habrán hecho un ejercicio de Red Teaming. Te habrán hecho un pentest, más o menos avanzado, pero, al fin y al cabo, un pentest.

¿Entonces qué es el Red Teaming, y qué lo hace diferente? 

Para empezar, es importante entender que cualquier organización está formada por un conjunto de personas con una cultura, forma de pensar y de trabajar propias. Como cualquier sistema humano, la organización puede fallar, es susceptible a creencias, prejuicios y tiene sus propias limitaciones que pueden provocar sesgos en la capacidad de análisis y toma de decisiones.

El objetivo del Red Team es, en general, someter las ideas, planes, programas o suposiciones de la organización a un estricto análisis, con el objetivo de identificar suposiciones incorrectas, opciones alternativas no contempladas, y detectar vulnerabilidades o riesgos que puedan afectarla. Una de las formas más habituales de hacer esto, como podemos imaginar, es tomar la perspectiva del adversario. Sin embargo, debemos dejar claro que es igualmente válido como Red Teaming el sentar a una persona ajena a la organización y por tanto a sus prejuicios y suposiciones, junto a los responsables de ejecutar la respuesta a incidentes, con la finalidad de evaluar y cuestionar los planes definidos sobre el papel, como ejecutar un ejercicio en vivo para verificar si además de los planes correctos, existen las adecuadas capacidades de ejecución y coordinación necesarias en dichos planes. En función de la madurez de la organización, se necesitará una u otra cosa.

Por otro lado, es fundamental conocer la organización para entender su modo de operar y sus procesos internos. Es importante entender que no se evalúan simplemente las tecnologías, sino que también se quieren evaluar los procesos y personas que las acompañan. Una gran parte de las ocasiones, son los propios responsables dentro de la organización los que ya tienen identificadas posibles debilidades y procesos que pueden generar riesgos a la organización. Son ellos los que pueden guiar al Red Team hacia procesos o tecnologías que deben ser analizadas, eso sí, con la experiencia particular que este grupo tan especializado puede aportar. Por ejemplo, si se han tenido numerosos incidentes relacionados con el malware recientemente, quizás merezca la pena incorporar a un especialista para analizar tanto las soluciones tecnológicas antimalware desplegadas en la organización a todos los niveles, como los procesos y personas que deberían acompañar a estas tecnologías para que realmente sean efectivas. ¿Es nuestro sistema antimalware tan bueno como creemos? ¿Cubrimos realmente todas las vías de entrada de malware a la organización? Cuando detectamos malware en un dispositivo, ¿realmente actuamos de la forma correcta? ¿Cómo sería de fácil para un malware que no ha sido detectado propagarse a través de nuestra red? ¿Tenemos definidos los planes de actuación para responder en casos como este? ¿Están las personas adecuadas informadas, entrenadas y preparadas para actuar acorde a estos planes? Estas y otras preguntas son preguntas que puede responder un Red Team, siendo posible utilizar sus conclusiones para el apoyo a la toma de decisiones internas.

En general, a no ser que el nivel de madurez en seguridad de la organización sea muy alto y los recursos no supongan un problema, donde un ejercicio Red vs. Blue a gran escala y en escenarios muy realistas tenga sentido, para la gran mayoría de las organizaciones la aproximación basada en la colaboración constante entre el personal interno y el externo es la que más valor aportará. Y es que esta es una de las claves de cualquier ejercicio de Red Teaming, una de las cosas que más valor aporta con respecto a un pentest genérico, el entrenamiento al personal interno, incluyendo al Blue Team.

Si al final del proyecto la organización no ha aprendido, y el Blue Team lo único que puede afirmar es que ha sido evadido, entonces el proyecto no ha sido un éxito.

Supongamos que desplegamos una infraestructura de Red Teaming con las siguientes características:

  • Direccionamiento IP repartido entre diferentes proveedores a lo largo del mundo.
  • Con dominios registrados de forma anónima.
  • Usando hosts de redirección para proteger la infraestructura real usada por los operadores.
  • Con mecanismos preparados para evitar la entrega de payloads al Blue Team, por ejemplo, a través de la detección de sistemas operativos y/o navegadores no utilizados por la fuerza de trabajo común.
  • Usando cifrado y Domain Fronting para proteger y camuflar las comunicaciones. 
  • Generando agentes de alta y baja interacción, que permitan recuperarnos en el caso de que los primeros caigan. 
  • Etc.

De nada serviría hacerlo si luego resulta que, después de todo, el nivel de madurez de la monitorización, detección y respuesta interna no es el adecuado para enfrentarse a este tipo de ejercicio, y, por tanto, el personal interno no aprenderá en el proceso.

Todo ejercicio de Red Teaming debe ser correctamente medido, escalado, y adaptado a cada organización, y esto empieza por la colaboración constante entre ambas partes, que nos permita decidir si lo que se requiere es un escenario como el que arriba se plantea, o si sólo es necesario generar, partiendo del compromiso asumido, determinados eventos de seguridad para confirmar si nuestros sistemas de detección están correctamente parametrizados o no, si es necesario realizar una mayor inversión en tecnología o personal que permita una mejor detección y respuesta, o si nuestro proveedor de servicios de CSOC es el adecuado.

Zerolynx adquiere parte de la consultora vasca de servicios profesionales Osane



La firma de servicios especializados en ciberseguridad y ciberinteligencia Zerolynx ha anunciado este jueves 11 de Octubre la adquisición de participaciones de la firma vasca de servicios tecnológicos Osane.

El acuerdo fue cerrado ayer miércoles en Vitoria-Gasteiz por Lorenzo Díaz Apodaca, Director General de Osane, y Juan Antonio Calles, Chief Executive Officer de Zerolynx.

Esta iniciativa forma parte de la estrategia de crecimiento de Zerolynx para convertirse en referente de ciberseguridad, sumando así nuevas capacidades a su equipo profesional y ampliando su presencia en nuevas ubicaciones que le permitirán estar más cerca de todos sus clientes.

Juan Antonio Calles y Daniel González, COO de Zerolynx, se incorporan así a la junta directiva de Osane, asumiendo además la dirección de las áreas de Ciberseguridad y Ciberinteligencia respectivamente, compatibilizando la dirección de ambas compañías del grupo. 

<<Esta alianza permitirá a Zerolynx sumar las capacidades de Osane, que cuenta con reconocidos profesionales en diferentes áreas de conocimiento, destacando entre otras su área de Seguridad Patrimonial, la cual nos permitirá reforzar algunas de nuestras líneas de servicios estratégicos, como las líneas de seguridad industrial e inteligencia>> comenta Juan Antonio Calles, CEO de Zerolynx.

Acerca de Osane Consulting

Osane Consulting es una sociedad de ingeniería y consultoría de carácter internacional, con sede principal en el Parque Tecnológico de Álava - País Vasco. Aglutina a profesionales expertos en las diferentes disciplinas de la seguridad patrimonial, con el fin de asegurar la continuidad de la actividad identificando riesgos y tomando las medidas equilibradas y necesarias. Potencian y aseguran el patrimonio de las empresas y de las personas de manera equilibrada y coherente.


El próximo 19 de Octubre participaremos en Mundo Hacker Academy, ¿nos acompañas?



El próximo 19 de Octubre, nuestros compañeros Juan Antonio Calles y Daniel González, CEO y COO de Zerolynx, participarán en el evento Mundo Hacker Academy, en el espacio MEEU de la estación de Chamartín de Madrid.


Nuestra intervención tendrá lugar en la Sala 1 del congreso, a las 18:00h. Bajo la colaboración de ISACA, presentaremos a los asistentes la certificación CSX, con una ponencia orientada hacia el Red Team en la empresa, con varias demostraciones prácticas para ilustrar nuestra experiencia en la realización de campañas de simulación de adversarios.

Más información en: https://mundohackeracademy.com

Auditando los 5GHz sin morir en el intento (Parte II)

En esta segunda parte de la cadena "Auditando los 5GHz sin morir en el intento", vamos a pasar a un nivel más práctico. Si habéis leído la primera parte sabréis la importancia que a día de hoy tienen las redes Wi-Fi de 5GHz, y que por tanto es necesario auditar las redes en estas frecuencias. No obstante, la configuración del equipo para realizar las tareas de auditoría con más complicadas que en 2.4GHz, al utilizar antenas más modernas que no son soportadas directamente por el kernel de Linux. 

Así pues, en este segundo post os vamos a contar cómo configurar una antena WiFi con un chipset específico y muy utilizado: el Realtek RTL8812AU. Específicamente, se ha utilizado una antena Alfa Network AWUS036AC (no confundir con la 036ACM, con chipset de Mediatek). 
Alfa Network AWUS036AC 

Esta antena tiene unos drivers Linux oficiales, pero llevan sin actualizarse desde abril de 2014… Por tanto, tenemos que recurrir a la comunidad, que ha desarrollado diferentes drivers, muchos de ellos perfectamente funcionales. Nosotros elegimos usar los drivers proporcionados en el mismo repositorio de Aircrack-ng en GitHub

Por tanto, una vez conectada la antena al puerto USB, clonamos este proyecto, obteniendo un directorio con unos cuantos shell scripts. El que nos interesa es el llamado dkms-install.sh, el cual debemos ejecutar como vemos en la siguiente imagen. 


Instalación del driver 

Como veis, este script se encarga de instalar el driver en el kernel a través de DKMS. Podemos comprobar que se ha instalado correctamente con el comando dkms status, donde se puede ver que el nuevo driver aparece. 


¡Ya podemos usar nuestra antena! 

Tras esto, y sin necesidad de reiniciar, si realizamos un ifconfig podremos ver que tenemos una nueva interfaz de red, en nuestro caso denominada “wlan1”. 

Si esto fuese una auditoría sobre 2.4GHz, lo siguiente que se haría sería llamar a airmon-ng para poner la interfaz en modo monitor, pero en este caso no es posible hacerlo de forma automática. Por suerte, hacerlo de forma manual es sencillo. 

  1. Con el comando airmon-ng check kill cerramos todos los servicios que puedan dar problemas a la tarjeta usando el modo monitor. 
  2. Desactivamos la interfaz de red con el comando ip link set <interfaz> down. 
  3. Ponemos la interfaz en modo monitor con el comando iw dev <interfaz> set type monitor. 
  4. Reactivamos la interfaz con el comando ip link set <interfaz> up. 
  5. (Opcional, si queremos tener conectividad y la hemos perdido con los pasos anteriores) Reiniciamos el gestor de red con el comando service NetworkManager restart. 
Ahora sí, nuestro hardware está totalmente listo para empezar a trabajar. Lo siguiente es conocido, lanzamos airodump-ng y… solamente obtenemos redes de 2.4GHz. 

Este es el comportamiento por defecto de airodump-ng, hay que especificar que se quiere analizar el espectro en 5GHz. Para ello, hay dos maneras de hacerlo: especificando el protocolo 802.11a (una especificación anterior a 802.11ac, también sobre 5GHz) con la opción --band, lo que provocará un barrido por la banda de 5GHz a (también puede usarse la opción --band ag si queremos analizar también las redes 802.11b/g/n de la banda 2.4GHz); o con la opción --channel, donde podrán especificarse canales de la banda de 5GHz (recordemos, del 36 al 140) 


Monitorización de redes en 2.4GHz y 5GHz 

¡Perfecto! La monitorización funciona, pero… ¿podemos inyectar paquetes? 

Vamos a terminar realizando una inyección de paquetes broadcast usando la herramienta aireplay-ng. Mientras lanzamos la herramienta, mantenemos airodump-ng funcionando, monitorizando un canal de 5GHz para comprobar que de verdad los paquetes son inyectados. Podemos ver que la inyección funciona sin problemas, pues aparecen una gran cantidad de IDs de cliente distintos en este canal. 


Inyectando paquetes @ 5GHz like a boss :) 

¡Y esto es todo por ahora! Esperamos que estos dos artículos os hayan parecido útiles y/o interesantes, y que os ayuden en vuestras futuras auditorías a redes de 5GHz. 

¡Saludos! 

#theBeeQueen