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.