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 

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

Si estás leyendo esto, lo más seguro es que hayas realizado alguna auditoría Wi-Fi en tu trabajo, o al menos hayas trasteado con tu propia red. El procedimiento, en resumen, suele ser: utilizar una antena que pueda configurarse en modo monitor e inyectar paquetes, lanzar la suite Aircrack-ng y empezar a interceptar paquetes como si no hubiera un mañana. 

Esto suele ser así de sencillo cuando se hace uso de una antena Wi-Fi de 2.4GHz, ya que al llevar tanto tiempo en el mercado, los drivers de los chipsets están totalmente integrados en el kernel Linux. Por desgracia, esto no ocurre aún con las antenas de 5GHz. 

En este primer artículo de la cadena vamos a realizar una pequeña introducción teórica a estas bandas de frecuencia desde un punto de vista “teleco”. En el siguiente artículo os contaremos paso a paso cómo configurar vuestros equipos para poder realizar una auditoría de una red Wi-Fi en 5GHz. 

¡Empecemos! 

Hoy en día, podría decirse que la gran mayoría de las redes Wi-Fi son “de tipo N”. Esto quiere decir que siguen el estándar IEEE 802.11n, el cual es una evolución de estándares anteriores (802.11b y 802.11g como los más conocidos) para alcanzar velocidades teóricas de hasta 600Mbps. Por lo general, una red de este tipo ocupa un ancho de banda de 20 o 40 MHz y se emite sobre una de las 13 portadoras que existen en torno a los 2.4GHz (lo que se denomina “canal”). 



Estos son los canales de la banda 2.4GHz (el 14 está prohibido en Europa) [Fuente: Wikipedia] 

¿Por qué 2.4 GHZ? Porque es una banda ISM de uso libre y de relativamente gran alcance. Sin embargo, este alcance es lo que genera el problema de esta banda: todo el mundo tiene un router Wi-Fi en su casa emitiendo señal. Así que es muy común hacer un análisis del espectro y ver a todos vuestros vecinos interfiriendo con vuestra preciada señal. Suponemos que la siguiente imagen os resultará familiar: 


El horror de las interferencias 

Y por esta enorme saturación, esos 600Mbps son totalmente teóricos (dad gracias si os llegan 60Mbps). Por este motivo, llegó un momento en el que era necesario aumentar la velocidad de los routers inalámbricos (¿quién va a contratar 500Mbps de fibra si por Wi-Fi le llegan 20Mbps?). 

La solución fue aumentar la frecuencia de emisión, saltando a los 5GHz: al ser una banda de frecuencias más alta, el alcance es menor (digamos que a la misma potencia de emisión “las ondas son absorbidas por más cosas en vez de atravesarlas”). Esto evita las interferencias con tus vecinos, ya que a la señal “le cuesta más” atravesar las paredes. Por esta misma razón, al estar más libre el espectro, se pueden usar canales mucho mayores, aumentando con ello la tasa binaria. 

Por esta razón, el uso de 5GHz permite obtener unos bitrates mucho mayores que en 2.4GHz; y, pese a que es posible usar el estándar 802.11n sobre 5GHz, el rey indiscutible de esta banda es el IEEE 802.11ac, el cual permite obtener velocidades teóricas de hasta casi 7Gbps haciendo uso de anchos de banda de hasta 160MHz. 



Canales en 5GHz en Europa. Como veis, es un poco más lioso que en 2.4GHz [Fuente: Cisco] 

Como curiosidad, os mostramos el espectro de la banda de 5GHz en el mismo punto que antes: 



Mucho mejor así, ¿no? 

Para concluir para esta primera parte y a modo de resumen, ante la saturación de la banda de 2.4GHz, se están normalizando las redes Wi-Fi sobre 5GHz debido al mayor bitrate que proporcionan. 

Por tanto, es necesario también realizar pruebas de auditoría Wi-Fi sobre 5GHz. En el siguiente post hablaremos sobre qué pasos seguir para poder realizar estas auditorías. 

¡Saludos! 

#theBeeQueen


Tor Browser Alpha para Android

La ciberinteligencia poco a poco se va integrando en las empresas, y cada vez son más aquellas que suman analistas de inteligencia a sus filas con el fin de prevenir ciberataques, e identificar posibles exfiltraciones de información que hayan podido sufrir y que puedan no haber sido identificadas durante sus controles preventivos y reactivos de seguridad.

Uno de los navegadores más utilizados por los analistas de inteligencia es Tor Browser, por sus capacidades de anonimización, y por la automatización que incorpora para el acceso mediante proxy a las páginas de la red TOR, vital para identificar posibles transacciones ilícitas de los datos de nuestras empresas en foros underground, como puedan ser correos electrónicos, tarjetas de crédito o bienes sustraídos, entre otros. A este conocido navegador entre la comunidad hacker, con versiones para varios sistemas operativos, se le ha sumado recientemente su versión Android (como versión alpha por el momento), y que se une a otras soluciones ya existentes para Android, como Orbot Proxy.



Estos navegadores sobre sistemas Android facilitan sin duda las labores de inteligencia de analistas desplazados, o que se encuentran realizando labores de campo y que no cuentan con un ordenador accesible en todo momento.

Podéis descargar Tor browser para Android desde el siguiente enlace:




Primer malware que explota el exploit de ALPC LPE

Como ya hemos comentado en entradas anteriores, hace unos días una investigadora de seguridad descubrió un 0-day que permite la escalada de privilegios local hasta SYSTEM en Windows 10 a cualquier usuario del sistema.


Como podemos leer en el blog de ESET, han pasado sólo dos días hasta que han encontrado la primera muestra que hace uso de este jugoso exploit. La muestra, asociada a una campaña del grupo bautizado como PowerPool, se ha detectado en Chile, Alemania, India, Filipinas, Polonia, Rusia, el Reino Unido, Estados Unidos y Ucrania.

Los actores maliciosos han modificado el exploit original para cambiar los privilegios del fichero de actualizaciones de Google, situado en el siguiente directorio:


Una vez cambiados los privilegios, lo pueden sustituir con el second-stage de su malware, consiguiendo así obtener permisos de SYSTEM cada vez que se ejecute el sistema de actualizaciones de Google.

Aunque no se tienen demasiados datos, parece que el compromiso inicial lo están realizando al menos mediante dos mecanismos. El primero de ellos es el envío directo de un first-stage como adjunto de correo a buzones concretos. El segundo es mediante spam con ficheros .slk, que permite el compromiso a través de un mecanismo ya reportado a finales de mayo en los foros del Internet Storm Center del SANS.

Este segundo mecanismo permite ejecutar código desde Excel. Podemos ver el ejemplo mostrado en los foros del SANS, en el que se puede ver que si actualizas el código dinámico de una celda acabaríamos ejecutando un típico ataque basado en Powershell.


Durante la investigación han encontrado, precisamente, un ejemplo de estos correos de SPAM con un fichero slk malicioso.


Tras el análisis del malware parece confirmarse que el first-stage ofrece un mecanismo de triaje a los operadores. El malware puede ejecutar algunos comandos básicos dirigidos al reconocimiento del sistema afectado, es capaz de tomar capturas de pantalla de la víctima, y posteriormente puede exfiltrar la información al C&C junto a datos de configuración del proxy del sistema. Como dato curioso, los operadores han cometido el error de tener la dirección del servidor de comando y control hardcodeada en el código.

Presumiblemente, una vez que los operadores deciden que un sistema es interesante, utilizan el first-stage para descargar la carga secundaria. De nuevo, en este segundo stage el malware tiene hardcodeados los datos del C&C, y se ha confirmado que los operadores no tienen capacidad de actualizar esta importante configuración del malware. Esta carga secundaria permite a los operadores ejecutar comandos, matar procesos, subir y bajar ficheros, y listar los contenidos de carpetas del sistema.

Las herramientas que utilizan los actores maliciosos para ayudarse en la etapa de movimiento lateral son viejas conocidas para la mayoría, como son PowerDump, PowerSploit, Invoke-SMBEnum, Quarks PwDump y FireMaster.

Era de esperar que con la publicación abierta de semejante 0-day, que sigue sin ser parcheado por Microsoft, algún grupo malicioso lo incorporase en su arsenal. Mientras tanto, podéis estar al tanto de los IOC disponibles, o intentar desplegar la mitigación no aprobada por Microsoft que se menciona en el CERT/CC.

¡Un gran trabajo de ESET!

Medium - Control de acceso y lecturas gratuitas

Para los que no conozcáis Medium, os diremos que se trata de una plataforma de publicación de contenido creada por los cofundadores de Twitter Evan Williams y Biz Stone.



Uno de los principales objetivos de esta plataforma es ofrecer contenido de calidad, profundo y original, alejándose de la horrible tendencia al clickbait y las lluvias de ads que otros medios de comunicación nos tienen acostumbrados. Por este motivo, aparte de contenido gratuito existen publicaciones premium que sólo pueden ser leídas bajo suscripción, y con el que la plataforma promociona directamente a los autores. Además y como mecanismo de promoción, la plataforma permite a todos aquellos usuarios con acceso gratuito la lectura de hasta tres publicaciones premium al mes.

Sin embargo, reciéntemente Yuval Shprinz ha podido constatar que el control de acceso a estas publicaciones premium tiene una peculiar debilidad, y es que el sistema simplemente verifica que por cada cookie de sesión sólo sea posible acceder a tres historias premium. Algo tan sencillo como borrar la cookie de sesión (o usar un navegador en modo Incógnito) nos permite leer tantas historias como queramos, sin necesidad de apoyar económicamente a la plataforma.

El proceso que ha seguido Yuval ha sido la obtención del código de la APK, su modificación a través de las instrucciones smali correspondientes, y el recompilado e instalación de la apk modificada (fuente original).



Esto mismo se podría haber realizado a través del uso de un navegador en modo incógnito, como el mismo autor comenta, o borrando las cookies al vuelo a través de Burp o nuestro proxy favorito.

Todo apunta a que los responsables de la plataforma conocen el fallo, y no tienen intención de modificar el comportamiento, ya que en las exclusiones de su programa de bug bounty se incluye precisamente:

"Defeating the paywall by clearing cookies, private browsing, or otherwise creating new user sessions"

Hay situaciones en las que, desde una perspectiva de negocio, se asume el riesgo de una vulnerabilidad y se decida no corregirla, ya sea porque el riesgo es muy bajo, o porque las correcciones a implementar suponen un coste extremadamente alto que hace que  no compense realizar ese trabajo. Parece ser que este es uno de esos casos.

Aplicar el mismo control sobre la cuenta de usuario, y no sobre la sesión abierta, obligaría a tener que crear una cuenta de correo electrónico falsa nueva por cada tres noticias premium leídas. Esto es algo bastante más tedioso que simplemente abrir el navegador en modo incógnito, sobre todo si bloqueas los dominios de cuentas desechables, y desde luego es un cambio que no requiere de grandes esfuerzos.

Veremos si Yuval recibe respuesta del equipo de Medium...

Un saludo!

Arrancamos la campaña #CaminandoHaciaLaCiberseguridad

Este mes de septiembre volvemos de las vacaciones con las pilas cargadas para la nueva temporada que da comienzo, y con ella, hemos dado inicio a una nueva campaña a la que hemos denominado #CaminandoHaciaLaCiberseguridad. Esta campaña, que ya hemos empezado a compartir en prensa escrita especializada y en algunos medios online, tiene como objetivo dar a conocer nuestras capacidades con importantes ofertas en nuestros servicios profesionales de ciberseguridad, con especial foco en todos aquellos relacionados con los siguientes cuatro ejes, seguridad ofensiva y hacking ético, mitigación de amenazas, análisis forense digital y respuesta ante incidentes (DFIR), y ciberinteligencia.

Si precisas de más información sobre nuestros servicios, o quieres que contactemos con vosotros para valorar una posible colaboración, podéis escribirnos a nuestro email [email protected], o llamarnos al número de teléfono que figura en la parte inferior de nuestro sitio web. Estaremos encantados de hablar con vosotros, y proponeros la mejor solución posible para vuestras necesidades.

Queremos ser vuestro proveedor de ciberseguridad, ¿nos dejas acompañarte?


Escalando privilegios en Windows 10: Segunda Parte



En la primera entrada sobre la reciente vulnerabilidad de escalada de privilegios local en Windows 10 comentábamos como a través de un enlace duro (hard link), y gracias a la falta de control sobre los permisos, era posible modificar los permisos de forma arbitraria en cualquier objeto del sistema.

Entrando un poco más en detalle, podemos observar que el primer problema reside en que el método SchRpcSetSecurity del Task Scheduler, accesible de forma externa a través de ALPC, no realiza una correcta impersonalización antes de establecer el descriptor de seguridad que define los permisos sobre el objeto que se quiere modificar. Lo lógico sería que, antes de realizar esta acción, el método impersonalizase al proceso que ha llamado a la función, usándose así por tanto los privilegios de dicho proceso para decidir sobre la capacidad de definir descriptores de seguridad sobre cualquier objeto. Sin embargo, esta acción no es realizada correctamente y por tanto se utilizan los propios permisos del Task Scheduler, con la suerte de que este proceso corre con permisos de SYSTEM. Por tanto, tenemos capacidad de asignar cualquier tipo de permiso sobre cualquier tipo de objeto.

Como ya hemos comentado, el segundo problema reside en que además esta acción se puede ejecutar no sólo sobre un objeto final, sino sobre una suerte de enlace simbólico. Gracias a esta incorrecta elección de diseño, es posible utilizar enlaces para redirigir esta modificación de permisos a cualquier objeto del sistema.

Con estos elementos encima de la mesa se repite la historia de siempre. Somos capaces de modificar cualquier ejecutable del sistema, que normalmente estaría protegido frente a modificaciones, y sólo tenemos que esperar a que un proceso privilegiado lo ejecute por error.

SandboxEscaper simplemente encontró una posible vía de ataque, aunque ella misma reconoce en su WriteUp que pueden existir más. Durante su investigación comprobó que al ejecutar la impresora XPS a través del servicio SpoolSv, se ejecutaba una dll del sistema llamada PrintConfig.dll. Además, teníamos la suerte de que habitualmente esa dll no estaba cargada directamente en el sistema, ya que de lo contrario intentaríamos modificar una dll ya cargada y nos encontraríamos con problemas de violaciones de acceso.

Por tanto, su demostración sigue los siguientes pasos:

  1. Crea un fichero UpdateTask.job en %SystemRoot%\Tasks, donde cualquier usuario (guest incluido) puede escribir para poder crear tareas programadas. Este fichero, sin embargo, es un enlace apuntando a PrintConfig.dll, nuestra dll objetivo
  2. Utiliza el método SchRpcSetSecurity del Programador de Tareas para cambiar los permisos de UpdateTask.job, que en realidad se trata de un enlace a PrintConfig.dll, para que cualquiera en el sistema pueda modificarlo. Esto es posible gracias a que esta modificación, recordemos, no se ejecuta con los permisos del usuario, sino con los permisos de SYSTEM asociados al Programador de Tareas.
  3. Acto seguido, se modifica nuestra dll objetivo (PrintConfig.dll) ya que a estas alturas puede ser modificada por cualquiera, y se sustituye con una dll maliciosa de nuestro interés. 
  4. Provocamos que el servicio Cola de Impresión cargue y ejecute la dll maliciosa. Finalmente, la carga maliciosa de nuestra dll se está ejecutando con permisos de SYSTEM, los permisos asociados al servicio de Cola de Impresión.
Es importante darse cuenta de que, como comentamos en la primera entrada, es trivial modificar el exploit para que en vez de ejecutar notepad utilicemos una dll maliciosa con meterpreter o cualquier otra carga dañina.

Mientras Microsoft sigue analizando el problema, una empresa ya ha sacado una solución que parchea al vuelo los binarios del sistema afectados. En esencia han analizado el código y se han dado cuenta de varios problemas.

  • Primero, pensaban que no se encontrarían con código de impersonalización, uno de los principales errores detectados en esta vulnerabilidad. Sin embargo, se han encontrado con que sí existe este código. El problema reside en que esta llamada de impersonalización se realiza incorrectamente justo después de hacer la llamada que asigna los permisos. ¿La solución? Han subido la llamada a RpcImpersonateClient para que se ejecute antes de que se inicie el proceso de asignación de permisos.
  • Segundo, una vez añadido este primer parche el exploit seguía funcionando. ¿El motivo? También existe una llamada a RpcRevertToSelf, que sirve para revertir la impersonalización, pero que de nuevo está incorrectamente situada y se ejecuta antes de la llamada que asigna los permisos. Por tanto, se elimina la impersonalización demasiado pronto. ¿La solución? Han eliminado esa llamada del código y la colocan más tarde, después de que los permisos se hayan asignado correctamente.

En el siguiente vídeo podéis ver en el process monitor, como las llamadas que anteriormente eran permitidas por una incorrecta gestión de los permisos pasan a estar completamente bloqueadas.

Escalando privilegios en Windows 10

El pasado 27 de agosto, la experta en ciberseguridad "SandboxEscaper" liberó en Github un exploit de escalada de privilegios local en Windows 10. El exploit, el cual enlazó desde un tweet publicado en la red social Twitter, se hizo viral rápidamente, saltando la noticia hasta varios medios generalistas:



El exploit aún se encuentra accesible, y puede ser descargado desde el siguiente enlace:
https://github.com/SandboxEscaper/randomrepo/blob/master/PoC-LPE.rar

Dentro del mismo se encuentra un completo Write-up explicando la vulnerabilidad. En concreto, el programador de tareas de Windows tiene una vulnerabilidad en la interfaz de la Llamada a Procedimiento Local Avanzada, o Advanced Local Procedure Call (ALPC), que permite a cualquier usuario elevar privilegios hasta SYSTEM.

En esta interfaz hay una llamada a la API (SchRpcSetSecurity) que no verifica correctamente los permisos. De este modo, es posible asignar permisos de forma arbitraria a través de un hard link a cualquier objeto del sistema de forma local.


El funcionamiento de la PoC es muy sencillo. En primer lugar decidiremos que proceso deseamos escalar y seleccionaremos su PID. Para ello nosotros utilizaremos el software Process Explorer:


A continuación, lanzaremos el exploit usando por ejemplo el proceso del bloc de notas (PID 4324)


Si volvemos a Process Explorer veremos como el bloc de notas es ejecutado a través del servicio de cola de impresión, esta vez, con privilegios de SYSTEM:


Ahora si intentamos realizar alguna acción que requiera privilegios, como por ejemplo abrir el archivo "hosts" situado en la ruta "C:\Windows\System32\drivers\etc", no tendremos ningún problema:


Obviamente, modificando un poco el exploit podemos olvidarnos del notepad, y ejecutar algo mucho más interesante como podría ser un Meterpreter. Después de generar nuestra propia DLL maliciosa con msfvenom, adaptamos el proyecto de Visual Studio, lo compilamos y volvemos a ejecutar...


Sin embargo, esta vez tenemos nuestro listener preparado y podemos observar como inmediatamente nos llega la sesión de Meterpreter sin problemas, y por supuesto corriendo como SYSTEM.




Os confirmamos que esta PoC ha sido realizada en un sistema Windows 10 Pro x64, actualizado con los últimos parches de seguridad, y se sabe que también afecta a Windows Server 2016. Sin embargo, con modificaciones menores es posible ejecutarlo en la versión 32 bits de Windows 10, y probablemente sea posible hacerlo funcionar en otros sistemas de Microsoft que dispongan de esta funcionalidad.

Microsoft ha reconocido la vulnerabilidad y ha anunciado que se encuentran trabajando para resolver el problema lo antes posible. Hasta entonces, cuidado con lo que ejecutáis... :)

Podéis consultar más información sobre esta vulnerabilidad en la segunda entrada que hemos realizado en nuestro blog.

¡Saludos!