miércoles, marzo 29, 2017

Latch en el mundo IoT integrado con Mosquito MQTT Broker #Mosquito #Latch #IoT @elevenpaths

A lo largo de la corta vida de Latch hemos visto muchas integraciones de nuestra tecnología con el mundo IoT, desde las integraciones con la hucha o la máquina de caramelos que hicimos internamente, hasta cosas como la integración en el chip ESP para hacer MicroLatch o el Latch My Car. Son muchas las ideas que han ido apareciendo a lo largo de este tiempo para controlar con Latch tu mundo físico.

Figura 1: Latch en el mundo IoT integrado con Mosquito MQTT Broker

En el pasado Latch Plugin Contest, le dimos el mejor premio - de 5.000 USD - a un proyecto de integración de nuestra tecnología al mundo IoT de la mano del proyecto Mosquito. Este nombre tan peculiar para una tecnología es el que recibe un proyecto Open Source que implementa una especificación MQTT Broker para controlar los dispositivos IoT tanto en el hogar, como en sistemas industriales o SCADA.

Figura 2: Proyecto Eclipse Mosquito

El protocolo MQTT fue diseñado originalmente en IBM, pero se convirtió en un estándar y ahora hay implementaciones Open Source como este Mosquito, hecha en Python, que puedes descargarte y utilizar en tus proyectos.

Figura 3: Faqs MQTT

El objetivo de un sistema MQTT Broker es de hacer de intermediario en esquemas de publicador/suscriptor para el mundo IoT, permitiendo que se descubran nuevos dispositivos, y que se puedan añadir nuevas peticiones de servicios. Esta tecnología permite que sea fácil ampliar, cambiar y reducir los sistemas IoT en una casa, una empresa o una fábrica. 

Figura 4: Esquema de funcionamiento de MQTT

Con la integración de Latch, lo que se permite es añadir un Segundo Factor de Autorización al MQTT Broker para no solo controlar la seguridad del acceso al panel de configuración, sino para añadir controles a las peticiones de servicio que se pueden encaminar a un determinado dispositivo.

Figura 5: Esquema de funcionamiento de control de MQTT con Latch

El manual y la documentación completa del proyecto de Latch para Mosquito MQTT Broker os lo he subido a a Slideshare, y ahí podéis ver desde su instalación, hasta la configuración completa de un entorno.


Además, para que podáis entender mejor el concepto de funcionamiento, este vídeo con una casita en maqueta de lo que sería el mundo IoT en el hogar explica paso a paso el funcionamiento y la utilidad de tener Latch integrado.

Figura 7: Demo de Latch integrado en Mosquito MQTT Broker

Puedes descargar Latch para Mosquito MQTT Broker en el GitHub de su creador, para que lo podáis probar en vuestras propias instalaciones de MQTT.
Cada día que vemos la cantidad de cosas que se integran constantemente con Latch, nos sentimos más contentos del uso que se le da a nuestro Segundo Factor de Autorización, ya que las ideas que van apareciendo son cada vez más curiosas. Me encanta.

Saludos Malignos!

martes, marzo 28, 2017

Latch’sApp: Un hack para exfiltrar datos con Latch @elevenpaths #latch #hacking #dataexfiltration

La pasada semana celebramos la IV Edición de nuestro Equinox, un evento interno en el que cualquier persona de CDO puede participar y llevar a cabo sus ideas más locas. En esta ocasión era mi segunda participación, ya que por varios motivos solo había podido participar en una de las tres ediciones anteriores.

Figura 1: "Latch'sApp" Un hack para exfiltrar datos con Latch

La primera idea que rondó deberá esperar para ver la luz, ya que no fue la elegida para participar en este hackathon, pero seguro que en el futuro se verá. La segunda idea fue la de crear un sistema de exfiltración de datos en el que ocultar información a través de los cerrojos de Latch.... y no sonaba nada mal. Este sistema permite crear un canal encubierto a través de las posiciones de los distintos cerrojos de una app de Latch.

Hands On con la exfiltración con Latch

Le comenté la idea a mi compañero Álvaro Nuñez-Romero (@toolsprods) y le gustó. Decidimos participar en las 24 horas de Equinox con esta idea y llevarla a cabo. La idea toca tres partes fundamentales para algunas pruebas de Data Exfiltration, que cada vez van cogiendo más auge en algunos proyectos de hacking ético.

Figura 2: Codificación de bytes con Latch

Este es un dato importante que fue proporcionado al jurado, ya que para comprobar si la inversión en controles internos que eviten o prevengan el filtrado de información de dentro de la organización al exterior es un hecho que cada vez se prueba más en una organización. El hack tocaba tres partes importantes:
Data Exfiltration: La colocación de los cerrojos de Latch representa un 0 o un 1, es decir, si tuviéramos 8 cerrojos podríamos representar 1 byte. Si tuviéramos 16 cerrojos podríamos representar 2 bytes, etcétera.

Canal encubierto: La posibilidad de crear un canal encubierto, como los vistos en la herramienta DET con el caso de Twitter, de Gmail, de Google Docs, son un claro ejemplo de cómo ocultar información a través de dichos canales.

Esteganografía y/o cifrado: La esteganografía permite ocultar información en imágenes, protocolos, otros archivos, y en este caso pensamos que las posiciones de los cerrojos pueden ocultar información, ya sea de un mensaje concreto o, incluso, un archivo cifrado.
El algoritmo para la transmisión de información es sencillo:
1. Se puede enviar un mensaje o un fichero. Sea cual sea el dato a enviar se lee el primer byte. 
2. Se obtiene un binary string, el cuál es la representación en unos y ceros del byte leído. 
3. Se va leyendo cada posición del binary string. Si es 1 se coloca el cerrojo correspondiente a “off”. Si es 0 se coloca el cerrojo correspondiente a “on”. 
4. Hay un noveno cerrojo que marca si la operación es escritura o lectura. Es decir, cuando emitamos o subamos datos colocando los cerrojos en sus diferentes posiciones se marcará el noveno cerrojo a “off” para que el otro extremo sepa que tiene que leer la información. 
5. Cuando el extremo lee la información colocará el noveno cerrojo a “on”. De esta forma se establece una especie de turno entre ambos extremos. 
6. La información que lee el extremo son 8 cerrojos (o N en el caso de hacerlo escalable). Si el cerrojo está a “off” se añade en un binary string el valor 1, si el cerrojo está a “on” se añade un binary string el valor 0. 
7. Una vez se tenga el binary string completo se obtiene el byte y ese byte se ha filtrado.
En la siguiente imagen se puede ver cómo se produce el traspaso de un mensaje utilizando el algoritmo anterior desde una app que utilizamos como emisor y se dedica a configurar los pestillos en la forma adecuada, y una app receptora que se dedica a leer los valores de los pestillos.

Figura 3: Emisor a la izquierda, receptor a la derecha

En el caso de los ficheros el proceso es exactamente igual. Durante el propio Equinox pensamos que sería interesante cifrar los datos que se envían en local, utilizando para ello una clave que pudieran saber los dos extremos. En primer lugar, pensamos en el OTP que el propio Latch puede proporcionar a los usuarios, pero no conseguiríamos que ambos extremos se “enterasen” del mismo OTP, ya que cada vez que hacíamos una petición a una operación con OTP, éste cambia.

Cifrando los datos con AES

Decidimos utilizar un derivado del APP ID. De esta forma, el extremo A cifra en local todos los bytes que quiere transmitir, por lo que la posición de los cerrojos de un byte cifrado a uno no cifrado no es la misma. Con este método, si alguien tiene acceso a la posición de los cerrojos en un momento dado necesitaría, además, de la clave que descifra la información. El cifrado utilizado es un AES.

Figura 4: Envío de fichero cifrado usando AES y codificado en Base64

Para poder visualizar el envío de información cifrada, los bytes se envían cifrados con AES y luego codificados en base64. En la imagen se puede ver un ejemplo de envío de archivo cifrado a través de las posiciones e interpretación de los cerrojos de Latch.

La PoC final con DET

Aparte de comer, disfrutar de actividades en el Equinox y pasar un rato estrujándonos el cerebro nos sobró tiempo para hacer un plugin de DET utilizando Latch, pero eso ya será contado en otra ocasión. Aquí os dejamos el vídeo funcionando el sistema de exfiltración de datos con Latch.

Figura 5: Exfiltrado de datos con Latch en vídeo

Enhorabuena a los premiados en el Equinox y a las grandes ideas y proyectos que allí se vieron. Ser jurado en este tipo de eventos no es fácil y mis compañeros hacen que no les sea fácil. Suerte al jurado y a los próximos participantes del Equinox de septiembre.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

lunes, marzo 27, 2017

Big Data Security Tales: Riak NoSQL Database #BigData

Haciendo recorrido a motores y tecnologías de Big Data de amplio uso, como parte de nuestro trabajo de actualización y mejora de los plugins de Faast, llegamos a Riak. Éste es un motor NoSQL que goza de cierta popularidad por su capacidad de trabajar en clusters distribuidos y es común encontrarlo en auditorías de seguridad.

Figura 1: Big Data Security Tales "Riak NoSQL Database"

Encontrar estos motores haciendo hacking con buscadores no es especialmente complejo. En primer lugar porque en buscadores como Shodan ya cuenta con su catalogación de producto,  ya que es fácil localizarlo por los puertos 8087 para el protocolo de comunicación riak y el 8098 para el panel de acceso HTTP.

Figura 2: Riak NoSQL en Shodan

En la parte de acceso web, el servidor web utiliza el HTTP Header del servidor MochiWeb & WebMachine, por lo que es sencillo saber si hay muchas posibilidades o no de encontrarse con un servidor NoSQL de Riak.

Figura 3: Puerto 8098 con el servicio HTTP 

Si el servicio HTTP está levantado, lo más probable es que te encuentres con un listado de ficheros en el directorio raíz, donde entre otros estará el archivo de estadísticas, con información general de todos los servidores que forman parte del cluster de Riak.

Figura 4: Contenido del servicio HTTP por el puerto 8098

No muchos de esos archivos son accesibles, y algunos son end-points de peticiones de servicio al motor NoSQL de Riak, pero entre ellos es posible que localices algún panel de adminsitración abierto al público.

Figura 5: Archivo Stats

Son muchos los que tienen el software de Riak Control o Riak Explorer publicados en la carpeta /admin, así que lo único que hay que hacer para ver si están o no publicados al exterior - que no deberían estar sin control - es buscar en esa URL.

Figura 6: Rick Control publicado al exterior de un cluster NoSQL

Con Riak Control se puede ver qué nodos forman parte del cluster y, entre otras cosas de monitorización, parar uno de ellos o hacer cambios en la configuración de cada uno de ellos.

Figura 7: Herramienta para gestionar los nodos de un cluster

Todas las cosas que se pueden hacer con Riak Control las puedes ver en este pequeño vídeo de marketing que hizo la compañía.

Figura 8: Vídeo de explicación de Riak Control

En el caso de Riak Explorer, se pueden crear configuraciones para gestionar los datos almacenados en el cluster NoSQL. Ahí tendrás listados de índices y los cubos de datos que se pueden crear ahí.

Figura 9: Riak Explorer... por HTTP

También se puede acceder a información detallada de cómo está funcionando el sistema y configurar los gráficos de control y monitorización a gusto, para tener los dashboards que se deseen con información de todos los nodos.

Figura 10: Gráficos en Riak Explorer

Tener esta consola de administración de cara a Internet puede ser un peligro, ya que cualquiera puede configurarse los buckets que desee, lo que puede producir errores en el funcionamiento de aplicaciones conectadas al motor.

Figura 11: Publicar una herramienta que puede hacer acciones potencialmente peligrosas en el sistema sin control de acceso no parece lo más oportuno. Ponle un Latch!

Encontrar estas utilidades de adminsitración web publicadas a Internet debería generar una alerta de seguridad para comprobar si están protegidas de forma segura o no. Si tienes un motor Riak en algún revisa su configuración. Sí, yo tampoco he visto mucho HTTPs.
- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)

- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
- Big Data Security Tales: Kibana & ElasticSearch objetivos del ransomware
- Big Data Security Tales: Apache CouchDB Relax... o no
- Big Data Security Tales: Riak NoSQL Database
Saludos Malignos!

domingo, marzo 26, 2017

Citas para la última semana de Marzo @elevenpaths @luca_d3 @movistar_team #BitCoin

En esta última semana de Marzo de 2017 que se nos viene encima, tenemos alguna acción que puede ser interesante. No os traigo muchas referencias, pero sí que algunas curiosas, como el seminario de las ElevenPaths Talks especial que vamos a dedicarle al DirtyTooth Hack, y alguna cosa extra.

Figura 1: Citas para la última semana de Marzo de 2017

El primer evento que os dejo es este martes, en Madrid, un Meetup de un tema que nos interesa mucho "Seguridad en las monedas virtuales". Lo organiza el grupo de Madrid BitCoin y es para usuario generalista, pero como la seguridad de BlockChain y BitCoin es algo que a muchos preocupa, os dejo la referencia del evento del día 28 de Marzo a las 18:00.

Figura 2: Meetup en Madrid sobre la seguridad en las monedas virtuales

Yo el día 29 de Marzo estaré en México D.F. dando una conferencia con la empresa KIO Networks donde hablaré de la gestión de la seguridad en las organizaciones. Será una charla para CEOs, CIOs y CSOs donde intentaré darles algunas ideas de las que suelo compartir con ellos para gestionar mejor la seguridad de la información, que no siempre es una tarea sencilla. Es un evento por invitación, así que no os puedo dejar una URL de registro y debéis poneros en contacto con la empresa.

El miércoles 29, desde LUCA Data-Driven Decisions vamos a impartir un seminario por la tarde, a través de Internet y gratuito, donde vamos a contar el trabajo que estuvimos haciendo con los datos del equipo ciclista Movistar Team y que yo presenté no hace mucho. Puedes registrarte en la siguiente URL: LUCA Talk 3 "Big Data y Ciclismo" 

Figura 3: LUCA Talk 3 - Big Data y Ciclismo
Si te gusta el ciclismo, no debes perderte este seminario, porque estará también el gran Mikel Zabala, que es el actual Director del Cycling Research Center del equipo Movistar Team. Aquí en este vídeo tienes unas pinceladas del trabajo que vas a poder ver en el seminario de LUCA.


Figura 4: Demo del trabajo de LUCA con Movistar Team

Desde ElevenPaths vamos a dar un seminario online gratuito dedicado a al DirtyTooth Hack, de una hora de duración a través de Internet. No estaba en la lista oficial de las ElevenPaths Talks, así que lo hemos organizado ad-hoc para esta semana que entra. Estarán Jorge Rivera  - el CSA manitas que hizo todo el hardware para sustituir el módulo BlueTooth del Marshall Killburn - y nuestro compañero Pablo González, que me ayudó a gestionar el proyecto de este hack para que saliera adelante. 

Será el jueves 30 de Marzo por la tarde, y puedes registrarte gratuitamente en la siguiente dirección URL: ElevenPaths Talk Special Edición DirtyTooth Hack.

Y esto es todo lo que os dejo de referencia. No es mucho, pero más que suficiente para que saques un rato para estar con nosotros, que hay temas interesantes a los que puedes asistir.

Saludos Malignos!

sábado, marzo 25, 2017

Hay otro Internet en las Wireless Meshnets: De Hyperboria a Freifunk pasando por B.A.T.M.A.N. o MeshBerry

Muchas veces, cuando se habla de la Deep Web se tiende a pensar que esta es lo mismo que TOR, y ni mucho menos es así. La Deep Web es un concepto mucho más genérico que habla de aquellos contenidos que no se encuentran accesibles por los canales de flujo masivo de conexiones, como son los buscadores como Google, Bing, o los grandes centros de compartición de información, como son Facebook, Twitter, Youtube, etcétera.

Figura 1: Hay otro Internet en las Wireless Meshnets

El concepto de Deep Web viene de un artículo publicado en el año 2001 en el que se ahonda en la dificultad de localizar aquel contenido que está fuera de los sistemas masivos de indexación, catalogación y búsqueda. Desde páginas web que quedan en el índice secundario de Google, hasta contenido que se encuentra almacenado en redes que necesitan de software especial de conexión, o lugares en los que son necesarias credenciales de acceso.

Figura 2: Artículo del año 2001 que introduce el concepto de Deep Web

En esta catalogación, por supuesto, entra la red TOR, las redes FreeNet o I2P, pero también una gran cantidad de redes P2P - donde yo ideé mi Dust-RSS, redes serverlesss como ISIS & OSIRIS, o la cada vez más popular red CJDNS y su famosa Hyperboria.


Figura 3: Charla en RootedCON 2011 sobre DUST-RSS

A lo largo de este tiempo, las comunidades han seguido desarrollando ideas para crear redes propias, fuera de los canales tradicionales, con diferentes arquitecturas descentralizadas, tal y como funciona TOR o CJDNS. En el año 2014, en las famosas conferencias HOPE (Hackers On Planet Earth) de New York, se impartió una charla sobre cómo estas redes podían hacerse a nivel local con la proliferación y abaratamiento de conexiones Wireless.

Figura 4: Wireless Meshnets

En esa charla se habló del proyecto NYC Mesh, una red comunitaria en la ciudad de New York para conectarse sin necesidad de contar con una infraestructura concreta. Dicha red se crea con la unión de nuevos nodos a la misma que configuran protocolos especiales de encaminamiento que permiten la conexión entre ellos de manera dinámica. Para ello, utilizan una distribución con todo lo necesario para conectarse en una distribución de Raspberry Pi a la que llaman Meshberry.
Uno de estos tipos de redes comunitarias, descentralizadas, y disponibles para cualquiera que quiera ser parte de ella, es Freifunk, muy popular en Alemania y que se basa en el protocolo de enrutamiento B.A.T.M.A.N. (Better Approach To Mobile Ad-hoc Networking), que resuelve el problema de envío de los paquetes en una red cambiante, descentralizada y móvil en la capa 2.

Figura 6: Vídeo que explica el concepto de las redes Freifunk

Llegué a esta red por casualidad, revisando unos mapas que mi amigo rootkit me había enviado, donde se puede ver de forma abierta todo lo que está pasando en cada una de estas redes Freifunk desplegadas por las diferentes regiones de Alemania.
No es que me guste especialmente, pensando en la privacidad, que se puedan ver las conexiones con direcciones MAC de muchos de los equipos que están haciendo uso de ella desde una web, pero supongo que los que utilizan estas redes ya deben saber cambiar la dirección MAC, además de otras medidas de privacidad.
Lo bueno de utilizar una red como Freifunk, es que también te puedes conectar a Internet, lo que permite que, por ejemplo desde una conexión a la red Freifunk hagas uso de una conexión a la red TOR para contar con una capa extra de anonimato.

Al margen del uso que le quiera dar cada uno a este tipo de redes, desde el punto de vista técnico, es precioso ver cómo se siguen creando nuevas tecnologías día a día, y se consiguen proyectos de gran utilidad para muchas personas a base del esfuerzo y el conocimiento de unos pocos. Hay otro Internet fuera del mainstream.

Saludos Malignos!

viernes, marzo 24, 2017

Vídeos de las ElevenPaths Talks Temporada 3

Como ya hiciera con los vídeos de la Temporada 1 de las ElevenPaths Talks y con todas las sesiones que conformaron la Temporada 2, voy a utilizar este artículo para ir recopilando todas las grabaciones de las charlas que impartimos periódicamente desde ElevenPaths sobre tecnología en general y seguridad informática en particular. Tienes ya más de 50 charlas gratuitas disponibles.

Figura 1: Vídeos de las ElevenPaths Talks Temporada 3

Si quieres conocer la agenda de sesiones que tenemos por delante - que estamos en plena campaña - para apuntarte y asistir a ellas gratuitamente, puedes acceder a la web: ElevenPaths Talks

Figura 2: Lista de próximas sesiones de ElevenPaths Talks 3

Por ahora, los vídeos que tienes disponibles son los siguientes, e iré actualizando este artículo a medida que vayan publicándose las grabaciones cada dos semanas, así que pon este artículo en favoritos.

Figura 3: La Guerra contra el Ransomware


Figura 4: La red bajo ataque

Por último, si quieres debatir sobre algo de lo que se haya hablado en las sesiones a posteriori, a priori o quieres proponer algún tema, puedes hacerlo a través de nuestra Comunidad online de ElevenPaths.

Saludos Malignos!

jueves, marzo 23, 2017

DirtyTooth Hack: Cómo reemplazar el módulo BlueTooth en un altavoz Marshall Killburn

Como ya se explicó en el ataque DirtyTooth Hack, si se quiere meter un módulo malicioso que cambie el comportamiento del BlueTooth Speaker para convertirlo en un Rogue DirtyTooth Speaker, como primer paso se requiere remplazar el módulo BlueTooth original por el nuevo módulo creado. En este artículo vamos a ver los detalles concretos del reemplazo en un BlueTooth Speaker modelo Marshall Killburn, que es el que utilizamos para la prueba de concepto.

Figura 1: Cómo reemplazar el módulo BlueTooth en un altavoz Marshall Killburn

Como ya explicó, para hacer el módulo BlueTooth malicioso se había construido un sistema que contenía, en un módulo Teensy v3.2, un módulo BlueTooth BC127 de BlueCreation , un módulo GSM/GPRS SIMCOM800C, un módulo BlueTooth HC-05 para tener una conexión serie sobre BlueTooth, además de la tarjeta SD para almacenamiento de los datos.

Figura 2: Esquema del hardware a introducir dentro del BlueTooth Speaker Marshall Killburn

Para introducir ese módulo malicioso de BlueTooth, primero hay que retirar el módulo original para poder reemplazarlo. En este altavoz en concreto el sistema BlueTooth se basa en un módulo BTM8630, con el chip CSR8630, pero acompañado de abundante electrónica adicional, destacando un doble amplificador operacional JRC NJM4560M.

Figura 3: Ubicación del módulo BlueTooth original en el altavoz Marshall Killburn

En la placa que monta el conjunto de pueden identificar las conexiones siguientes:
• R y L: parecen corresponderse con los canales de audio Right y Left. 
• LED: se corresponde con el Led Bluetooth del panel en lógica negativa. 
• 3.3v: tensión de alimentación estable a 3.3 voltios. 
• ON: corresponde con la selección de entrada de audio HIGH en INPUT. 
12v: tensión variable de 7 a 18v voltios de poca intensidad (nivel batería), 
• PAIR: presenta un pulso en HIGH de 550ms de duración al pulsar PAIR. 
• OFF: permite desconectar el sonido del amplificador en lógica negativa.
Figura 4: Módulo BlueTooth original en el altavoz Marshall Killburn

Tanto el chip original CSR8630 como el BC127 que lo reemplazará, presentan salidas de audio analógicas como corriente alterna de unos 600mVpp como máximo para cada uno de los canales, y ambos acompañados de su señal complementaria diferencial, para posibilitar la reducción de interferencias, tal y como se puede apreciar en la siguiente captura.

Figura 5: Salidas en el chip original CSR8630

Pero al parecer, la electrónica que acompaña al módulo original, especialmente el doble amplificador operacional, se utiliza para montar la señal de audio sobre un offset de corriente continua de 2.6v, lo que debe ser un requisito de diseño del amplificador Marshall.

Figura 6: Señal de audio con offset

La necesidad de satisfacer este requisito sin disponer del esquema original obliga a diseñar un circuito equivalente que presente un comportamiento similar. Para ello se utiliza un doble amplificador operacional Texas Instruments RC4060, de prestaciones similares al original, en configuración de restador de una tensión de referencia de 2.6v proveniente de un regulador lineal A78L02 a la señal complementaria diferencial, cuyo resultado es una señal de audio fiel a la orinal, incluso más nítida si cabe, sobre la portadora de continua esperada.

Figura 7: Señal de audio generada

Este circuito se realiza sobre una placa con un conector compatible con la original, donde se añaden los conectores necesarios para la alimentación a 5v del resto de módulos, un pequeño relé para la desconexión de la batería de litio que requiere el modem GSM.

Figura 8: Placa con conector que ajusta la señal a los requisitos del Marshall Killburn

Se incorpora también un transistor para invertir la lógica de la señal de desconexión del amplificador OFF, ya que aunque Blue Creation no lo documenta, su salida GPIO_03 cambia de estado según esté un audio en reproducción, utilizándose para desconectar el amplificador y evitar los molestos ruidos POTHS!!! entre cambios de audio, tal y como lo realiza el módulo original.

Figura 9: Diagrama con interconexiones finales al módulo adaptador

Una vez dispuestos todos los componentes, su interconexión se realiza tal y como se muestra en el diagrama de la Figura 9 superior. La tensión de alimentación de todos los módulos (INPUT +5vcc) se obtiene mediante la adición de una conexión al regulador lineal de 5 voltios presente en el circuito del amplificador. Aunque de formato SMD, puede llegar a entregar hasta 1.3 amperios, algo que parece más que suficiente para su cometido original y el escaso consumo de los módulos adicionales.

Figura 10: Conexión Final en el altavoz Marshall Killburn

El resultado final conectado al altavoz Marshall Killburn es el que se ve en la imagen superior, y el resultado final de la experiencia con el software es la que habéis visto en los vídeos del ataque DirtyTooth Hack.


Figura 11: Ataque de DirtyTooth Hack

Autor: Jorge Rivera, CSA de ElevenPaths

miércoles, marzo 22, 2017

Windows 10: (Otro) Bypass (más) de UAC usando AppPaths y sdctl.exe #Windows10 #Hacking #pentesting

Muchas eran las quejas de los usuarios sobre UAC (User Account Control) cuando fue introducido por Microsoft en Windows Vista, pero lo cierto es que desde que se rebajó el nivel de seguridad en Windows 7, Windows 8, Windows 8.1 y Windows 10, son constantes las pruebas de concepto de nuevas formas de utilizar la opción de autoElevate para saltarse UAC, lo que hace que sea bastante inútil en su configuración por defecto.

Figura 1: Windows 10 (Otro) bypass (más) de UAC usando AppPaths y SDCTL.EXE

La semana pasada hablamos sobre una nueva forma de hacer bypass de UAC para Windows 7/8/8.1 en el que además se mostraba cómo encontrar aquellos binarios “potencialmente” débiles que encajen con las condiciones para hacer un bypass de UAC, por medio de la opción de autoElevate de la que se habla en la intro de este artículo.


Figura 2: PoC de laa nueva forma de saltarse UAC publicada la semana pasada

Hoy, como explica Enigma0x3 en su artículo sobre los AppPaths y la posibilidad de utilizarlos para hacer un bypass de UAC, Microsoft parece tener un interés renovado en este tipo de técnicas y va parcheando poco a poco. Quizá la aparición de una técnica para hacer bypass de UAC en Windows 7 publicada por Wikileaks en el famoso Vault7 ayuda a que, cada vez más, se tome en serio.

Figura 3: Bypass de UAC en Windows 7 publicado en Vault7

Como he mencionado en otros artículos, el proyecto UACMe proporciona una serie de métodos de bypass de UAC, algunos de los cuales no están parcheados y son aplicables en versiones como Windows 10. Hoy hablaremos de una nueva forma que ha publicado Enigma0x3 en su blog, el cual es uno de los miembros más activos en la búsqueda de este tipo de debilidades o configuraciones débiles del UAC en Windows.

Figura 4: La configuración Modo Windows Vista es segura a estos ataques

Como se ha comentado en otros artículos relacionados con el bypass, como por ejemplo el de Fileless, el de wusa.exe y CompMgmtLauncher.exe o el de Ole32.dll y .NET, la tecla siempre está en la localización de los binarios firmados por Microsoft que son elevados automáticamente, gracias a la directiva autoElevate de su manifest.


Figura 5: Bypass de UAC con Fileless

En el caso del binario sdclt.exe, éste se eleva automáticamente según se indica en el manifest. Existe una diferencia, en este caso, entre el binario en Windows 10 y en Windows 7. En el caso de Windows 10, el binario se auto-eleva, pero en el caso de Windows 7 la directiva requestedExecutionLevel en el manifest se encuentra establecida como “AsInvoker”, lo que impedirá la auto-elevación cuando se inicia desde un proceso de integridad media. Esto es un dato curioso, ya que en Windows 10 sí nos funcionará.

PoC UAC Bypass con sdctl.exe

Analizando el binario se ve como sdclt.exe utiliza una ventana de panel de control para embeberse. En otras palabras, ejecuta un fichero llamado control.exe. ¿De dónde saca la ruta de este binario? La ruta la obtiene del registro, por lo que monitorizando las acciones que se realizan en el registro de Windows se puede encontrar una operación deseada para nosotros ya que la clave:
HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe 
... devuelve un Name Not Found. Esto quiere decir que busca la ruta de control.exe en esta ruta, pero no la encuentra, por lo que la busca en otra ubicación.

Figura 6: Name Not Found en la invocación de control.exe

Visto esto, ¿qué ocurre si nosotros escribimos un valor modificado por nosotros en esa clave del registro? Lo más probable es que podamos invocar un binario y viendo que sdclt.exe está siendo ejecutado un nivel de integridad algo ya tendremos el bypass de UAC.

Las llamadas a HKCU que genera un proceso ejecutado en un contexto de alta integridad son especialmente interesantes. Cuando un proceso elevado está interactuando con la rama HKCU de un usuario, puede fallar en cualquier instante, dando la posibilidad de que el proceso ejecute cualquier cosa, dando lugar a la ejecución en un contexto privilegiado.

Figura 7: Consiguiendo una consola con nivel de integridad alto

En el caso de sdclt.exe, éste busca la ruta de la aplicación de control.exe en la rama HKCU. Si nosotros escribimos la ruta que no se encuentra y, por ejemplo, ponemos la siguiente ruta:
“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” 
...en el valor de la clave, obtendríamos una Powershell ejecutándose en un contexto de integridad alta, por lo que tendríamos el bypass.

Figura 8: Script de Enigma0x3 para simplificar el proceso

Según se explica en Enigma0x3 y se puede comprobar hay que tener en cuenta que esta técnica no permite parámetros, lo cual significa que para ejecutar código arbitrario debemos situar un binario en disco, lo cual hace más fácil que un antivirus detecte este tipo de técnicas. Enigma0x3 ha colgado en su Github un script que simplifica el proceso y enseña cómo aprovecharse de esta técnica.

Figura 9: Sesión elevada tras explotación del bypass de UAC

En la  imagen superior, se puede ver como conseguimos un interfaz de comendos cmd.exe con privilegio o ejecutada en un contexto de integridad alto. Podemos escribir un fichero en C:\ que solo está permitido a este tipo de procesos. En el vídeo siguiente se puede ver la prueba de concepto funcionando completamente.

Figura 10: PoC de bypass de UAC usando AppPaths y sdctl.exe

¿Cómo remediar los bypasses de UAC? Existen diferentes formas, pero una principal es fortificar el sistema Microsoft Widndows y  establecer el nivel de UAC en “Siempre notificar”, cuando se intente ejecutar un proceso en un contexto de integridad alto que requiera los permisos de administración. De esta forma, el usuario o víctima se dará cuenta, ya que el UAC siempre notificará y ningún binario será auto-elevado. En resumen, una nueva técnica que aporta otra forma de lograr ejecutar con privilegio en un entorno Windows.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

martes, marzo 21, 2017

Big Data Security Tales: Apache CouchDB Relax.... o no.

Han pasado unos meses desde que escribí el último artículo dedicado a la serie de Big Data Security Tales que centré en Kibana y ElasticSearch, así que hoy es un buen día para volver a ella. En concreto, gracias a una referencia que mi amigo rootkit me ha enviado sobre los interfaces de administración de las bases de datos CouchDB, que se usan en muchos entornos web.

Figura 1: Big Data Security Tales: Apache CouchDB Relax... o no

El motor CouchDB se basa en un motor NoSQL para entornos de BigData especialmente diseñados para aplicaciones web, donde la sencillez de instalación y uso priman por encima de todo. Desde el año 2008 es un proyecto de Apache, y localizar los paneles de administración en la web es sencillo haciendo un poco de Hacking con Buscadores.

Figura 2: Buscando servidores CouchDB en Shodan

Como se puede ver, buscando en Shodan por su Well-Known Port rápidamente salen casi 4.000 servidores en los que está desplegado dicho motor de CouchDB, y, como se puede ver en algunos de los resultados, es posible acceder a los nombres de las bases de datos que hay en el catálogo porque no están fortificados la mayoría.

Figura 3: Buscando servidores CouchDB en Google con el Truco de la Barra

En cualquier instalación en la que el interfaz web de administración de CouchDB esté abierto a Internet, se puede acceder a la lista de las bases de datos entrando en el directorio /_utils/, tal y como se puede ver en la imagen siguiente.

Figura 4: Cientos de bases de datos en un servidor CouchDB

A partir de ese punto, lo único que debería realizar un atacante es comprobar a qué puede y a que no puede acceder, simplemente navegando por las diferentes bases de datos y explorando los documentos almacenados en cada una de las bases de datos creadas.

Figura 5: Documentos en formato clave-valor en bases de datos NoSQL sobre CouchDB

Por supuesto, lo que se puede encontrar, teniendo en cuenta que está especialmente centrado en proyectos web, está relacionado desde entornos e-commerce hasta aplicaciones web de gestión masiva de datos, con mucha información, y por supuesto con datos de las cuentas de usuarios de las distintas aplicaciones soportadas.

Figura 6: Datos de cuentas de usuarios en bases de datos CouchDB

El número de sitios que, a día de hoy, está abierto al publico en las instalaciones de CouchDB es muy alto, así que si estás haciendo uso de uno de estos motores en tus proyectos web, más vale que revises qué partes están abiertas para cualquier usuario de Internet, para evitar sorpresas.

Figura 7: Claves en texto plano almacenadas en bases de datos CouchDB...relax

Aprovecho también para dejaros la lista completa de artículos dedicados a la serie de Big Data Security Tales, por si alguno de ellos te pudiera servir de utilidad con el objetivo de fortificar tus entornos de Big Data:
- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)

- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
- Big Data Security Tales: Kibana & ElasticSearch objetivos del ransomware
- Big Data Security Tales: Apache CouchDB Relax... o no
- Big Data Security Tales: Riak NoSQL Database
Saludos Malignos!

Entrada destacada

Aura y su negocio oculto para conquistar el mundo

Ya estoy de regreso en Madrid , y mientras todavía continúa el eco de la presentación de Aura y la Cuarta Plataforma , he decidido tomarme ...

Entradas populares