Rogue Robots: Cómo volver maliciosos robots industriales (Parte 1 de 2)

Ahora que todo el mundo está hablando de los robots y el impacto (negativo o positivo, según se mire) que tendrán en nuestra sociedad, y viendo su crecimiento expansivo, tanto ayer, como hoy, es un buen momento para comenzar a analizar la seguridad de estos Sistemas de Control Industrial (ICS).

Figura 1: Rogue Robots. Cómo volver maliciosos robots industriales (Parte 1 de 2)

No es necesario explicar la tremenda gravedad de no asegurar correctamente estos sistemas los cuales pueden afectar al proceso de fabricación de elementos críticos (aparatos médicos o componentes de coches como los frenos, por ejemplo) o incluso a la seguridad física de las personas que trabajan en la misma fábrica (¿será ya la hora de aplicar las Tres leyes de Asimov? Aunque ya sabemos que tienen fallos). Esto sin contar que las fábricas son instalaciones críticas para cualquier nación, convirtiendo este sector en otro objetivo en una situación de ciberguerra. 

Figura 2: Las famosas "Tres leyes de la robótica" de Asimov

Aunque las vulnerabilidades en robots industriales son conocidas, no existen muchos estudios que analicen en profundidad esta temática. Un primer paso para comenzar a tener una visión más amplia de esta problemática lo han dado investigadores de la Universidad Politécnica de Milán y la empresa de Trend Micro, realizando una investigación exhaustiva sobre la seguridad de los robots industriales y los resultados no son nada alentadores. En el siguiente vídeo explican qué se podría hacer con un "Rogue Robot" que hubiera sido comprometido y  convertido en malicioso.

Figura 3: "Rogue Robots"

Básicamente han estado haciendo "Hacking con buscadores" utilizando Shodan, ZoomEye y Censys buscando robots de las marcas más conocidas del sector. Al igual que ocurre con muchos otros sistemas industriales - en el libro “Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación” encontrarás mucha información sobre la seguridad de este tipo de sistemas -, han localizado robots utilizando direcciones IP públicas, contraseñas de acceso por defecto, software obsoleto - por ejemplo versiones Linux 2.6 ó .NET SDK 3.5 con vulnerabilidades conocidas - o incluso han llegado a acceder sin que el sistema solicitara contraseña alguna. Y estamos hablando de robots de marcas tan conocidas como Mitsubishi o Kawasaki. 

Para comprender el impacto real de los problemas de seguridad en este tipo de instalaciones, es necesario tener clara la arquitectura industrial de los ICS:

• Robot: este componente es el más fácil de reconocer ya que habitualmente tiene forma de brazo humano y es capaz de moverse en tres o más ejes. Puede estar fijo en una posición o también puede desplazarse (móvil). Puede realizar mucho tipo de tareas desde coger objetos, doblar materiales o incluso manipular otros dispositivos como por ejemplo un láser.

• Controlador: está compuesto de múltiples subsistemas informáticos complejos interconectados entre sí para recibir información del exterior y de esa forma tomar decisiones. Es básicamente el cerebro del robot y puede operar de forma automática (tarea programada) o manual (es el operador quien controla el robot habitualmente usando un joystick). 

• Interface Robot-Humano: generalmente existe un dispositivo llamado “teach pendant” el cual se conecta directamente utilizando un cable o vía wireless. En esta consola de mandos está el teclado o incluso el joystick mencionado antes para controlar el robot. Se utiliza tanto para programar el robot como para su monitorización.

• Programación del robot: los programas suelen estar escritos en un entorno desarrollado por el propio fabricante. Se puede programar utilizando el joystick o utilizando secuencias de comandos desde un simulador interno. Estos programas se almacenarán en la memoria del controlador.

Figura 4: Arquitectura de un robot industrial

Es importante destacar también que todos estos robots suelen estar conectados a Internet a través de routers industriales de marcas como: Robustel, inHand o Digi. La conexión entre dichos robots se realiza básicamente para tareas de mantenimiento y monitorización. Esta conexión se lleva a cabo utilizando directamente Internet, una conexión VPN o incluso por GPRS usando APNs propias de los fabricantes.  

Figura 5: Ejemplos de routers industriales de las marcas Robustel, InHad y Digi

Una vez tenemos una visión de la arquitectura y el entorno de estos sistemas, podemos comenzar a estudiar algunos ejemplos de ataques. El primer paso será necesario entender un poco funcionamiento de estos robots. Es bastante fácil encontrar por Internet documentación, manuales e incluso ficheros ejecutables del controlador (podríamos aplicar técnicas de ingeniería inversa) o también ficheros de firmware o actualizaciones.

Ataques a Robots Industriales

Por otro lado, es importante distinguir entre ataques de red y ataques físicos. En el ataque de red sólo puede haber comunicación con el robot a través de una conexión de red. Aunque el robot no esté conectado directamente a Internet, suelen estar conectados a una LAN la cual puede a su vez tener fallos de configuración o incluso vulnerabilidades - por ejemplo, atacando un ordenador de algún usuario en esa misma LAN pero con conexión a Internet -.

En cambio, el atacante físico suele ser alguien con acceso directo al robot, como por ejemplo el mismo operador, pero también puede ser personal externo como técnicos de mantenimiento. El acceso físico es más peligroso ya que garantiza un acceso total al controlador del robot utilizando cualquier de los puertos de I/O habituales (aunque algunas conexiones son propias de los mismos fabricantes).

Figura 6: Rogue Robots: Testing the limits of an Industrial Robot´s Security (PDF)

Los diferentes ataques que se pueden realizar a estos sistemas son los siguientes (aquí están resumidos, en el paper original puedes verlos más en detalle):

• Ataque 1: alterar los parámetros de control de movimiento. Este es quizás el ataque más llamativo ya que puede violar todas las normas de seguridad física al alterar de forma aleatoria e incluso violenta los movimientos del brazo robot, pudiendo dañar material, al mismo robot o incluso a personas. Este ataque podría ser utilizado en caso de tener como objetivo dañar o modificar el producto que se está fabricando.

• Ataque 2: manipulación de los parámetros de calibración. Este ataque es parecido al anterior, pero se centra específicamente en modificar los datos de calibración almacenados en el equipo. Estos datos son utilizados por el controlador para corregir posibles errores de medida cuando los servomotores están funcionando. Una mínima variación de estos valores podría destruir el objeto que se está fabricando o dejarlo inservible. Los efectos de este tipo de ataque son los mismos que en el tipo de ataque número 1.

• Ataque 3: manipulación de la lógica interna del producto. En este caso el atacante manipula el programa que se está ejecutando en el robot cambiando internamente su funcionamiento. El objetivo es dañar, modificar o alterar el producto que se está fabricando en la línea de montaje.

• Ataque 4: alteración de los interfaces de estado del robot. El robot tiene que informar continuamente sobre el estado de, por ejemplo, sus motores. Esta información es visualizada en interfaces las cuales podrían ser vulnerables a ataques que modificaran la forma en la que muestran dicha información. Aunque un testigo o un panel indicara que los motores están parados, estos podrían seguir en funcionamiento.

• Ataque 5: alteración de los estados del robot. En este tipo de ataque el objetivo son directamente los estados en vez de las interfaces. Por ejemplo, un atacante podría cambiar el modo manual a automático y viceversa, ya que normalmente el cambio de este estado se realiza por software en vez de utilizar un interruptor mecánico.

Ahora que ya tenemos algunos tipos de ataques posibles, pasamos a describir una demostración real de ataque.

PoC: Análisis de seguridad de un brazo robot

El objetivo será el brazo robot ABB de seis ejes IRB140, capaz de manipular hasta 6kg de peso. Viene equipado con un controlador bastante común modelo IRC5 y ejecuta el software RobotWare 5.13.10371 y FlexPendant (sistema basado en Windows CE). Este robot debería operar dentro de una jaula para evitar posibles accidentes con otros trabajadores humanos.

Figura 7: Brazo Robot ABB IRB140

Y ahora viene una de las partes que más nos interesa, los puntos de entrada. Para localizar en Internet modelos como el ABB IRB140, se ha utilizado en concreto Shodan - el cual ya hemos visto varias veces en otras pruebas de sistemas industriales -. En el caso práctico de este estudio, se realizado una búsqueda con estos parámetros “Server: eWON¨.

Figura 8: Ejemplo de búsqueda en Shodan de dispositivos eWon

eWON corresponde a la etiqueta que aparece en los servidores web embebidos correspondientes a la marca ABB. Para hacer una búsqueda más precisa podríamos poner el nombre de la empresa fabricante dentro del campo “Basic realm” para comprobar la cabecera de la respuesta HTTP. Una vez descubierto el dispositivo podemos comenzar a buscar vulnerabilidades, pero esto queda para la siguiente parte de este artículo. Vamos, que hacemos un Cliffhanger en toda regla.

Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.

Fileless 3: Bypass UAC en Windows 10 (Otro más, aunque parezca increíble)

Hoy traemos un nuevo bypass de UAC del tipo Fileless, y van tres descubiertos ya con el de hoy, con el que podemos saltarnos la interacción con el usuario para saltar la protección de User Account Control . Este método ha sido encontrado por un investigador alemán que prepara su tesis sobre este tipo de debilidades de los sistemas de Windows. Es cierto que Microsoft no lo considera una vulnerabilidad, pero ha decidido parchear algunos ya que pueden ser utilizados por malware para lograr ejecutarse como SYSTEM en el equipo.

Figura 1: Fileless 3: Bypass UAC en MS Windows 10

Meses atrás hablamos del Fileless y Fileless 2 como los primeros métodos en los que no se generaba o se subía un fichero a disco para llevar a cabo el bypass. Hoy tenemos un nuevo Fileless y, a priori, van tres ya.

Figura 2: Artículo explicando "Fileless 3" por el investigador.

Como ya hemos comentado en otras ocasiones, tenemos unas pre-condiciones para hacer un bypass de UAC y son las siguientes:

• El usuario forma parte del grupo administradores. 

• El UAC tiene la política por defecto, es decir, no se ha modificado esta política desde la instalación del sistema. 

Figura 3: Con la configuración de UAC en "Modo Windows Vista" no funcionan estos bypass

• En este caso, tenemos un sistema operativo Windows 10. El Fileless 3 solo nos funcionará en esta versión, ya que el binario que permite llevar a cabo el bypass solo se encuentra en esta versión.

Como buen Fileless este bypass radica en errores de los binarios al consultar ramas del registro que se encuentran en HKCU. Si una rama consultada en HKCU no existe, podemos crearla y hacer que exista de forma sencilla. Por esta razón, veremos a continuación cómo de fácil es encontrar otros bypass de UAC siguiente el patrón.

PoC: Fileless 3 in action!

Vamos a llevar a cabo una prueba de concepto sencilla sobre un sistema Windows 10. Para observar cuando un binario consulta ramas de registro no creadas en HKCU utilizaremos la herramienta Process Monitor. Esta herramienta es fácil de configurar y, para ello, crearemos un par de filtros, uno para el binario fodhelper.exe y otro para los resultados “NAME NOT FOUND” que se obtengan de consultar al registro, como ya hemos hecho en otros bypass de UAC.

Figura 4: Filtros en Process Explorer para fodhelper.exe y "NAME NOT FOUND"

En la imagen podemos ver cómo la consulta a HKCU:\Software\Classes\ms-settings\Shell\Open\command nos proporciona un “NAME NOT FOUND”. Si creamos esta ruta en el registro de Windows, ya que se encuentra en HKCU y podemos hacerlo sin problema, y volvemos a ejecutar el binario fodhelper.exe monitorizado con Process Monitor nos encontraremos lo siguiente:

Figura 5: Falla en la localización de la clave DelegateExecute

Si buscamos la ruta HKCU:\Software\Clasess\ms-settings\shell\open\command\DelegateExecute vemos que no existe, es decir, no se encuentra por el binario. Si nos fijamos en la clave anterior, vemos como sí la ha encontrado, pero no la clave DelegateExecute.

Cuando el String Value de DelegateExecute existe, el binario buscará la clave por defecto de la ruta HKCU:\Software\Classes\ms-settings\shell\open\command ejecutando lo que haya en el valor de dicha clave. Al ser ejecutado con un binario que se está ejecutando con integridad alta, el nuevo proceso tendrá el mismo nivel de integridad.

Figura 6: MicEnum permite analizar los niveles de integridad de binarios y claves de registro

Para revisar los niveles de integridad en Windows se puede utilizar nuestra utilidad de ElevenPaths MicEnum. Además, como el binario fodhelper.exe está firmado por Microsoft y tiene el AutoElevate a True por lo que no solicitará la confirmación del usuario con UAC.

Figura 7: Valor por defecto en la clave DelegateExecute (value not set)

Ahora, modificamos (Default) e indicamos, por ejemplo, C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe. Esto hará que cuando invoquemos a fodhelper.exe, éste acabe abriendo una Powershell con el máximo privilegio.

Figura 8: Valor modificado a ejecución de Powershell

Os dejamos un video dónde podéis ver el proceso de manera sencilla. Un nuevo Fileless que puede ser utilizado en el mundo de la auditoría y el hacking ético. Aunque viendo lo que ocurrió con el primer Fileless, hay que estar preparado para luchar contra el posible malware que pueda utilizarlo.

Figura 9: PoC en Vídeo de Fileless 3 UAC Bypass

Como se puede entender, y hemos visto en otras ocasiones, este tipo de técnicas puede utilizarse en un pentesting dónde poder ser SYSTEM desde un usuario que sea del grupo administradores. Además, se puede utilizar de manera sencilla con Meterpreter en Metasploit gracias a la integración con Powershell que puede hacerse de forma sencilla. Y recuerda, estos métodos no funcionan si tienes aplicada la Máxima Seguridad a tu 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  con la colaboración de Santiago Hernández Ramos, nuevo cybersecurity "padawan" researcher en ElevenPaths

Cómo usar las novedades en ZAP 2.6.0 para hacer pentesting con FOCA de @elevenpaths

ZAP es una herramienta gratuita empleada en test de intrusión en aplicaciones WEB que ayuda en la búsqueda y explotación de vulnerabilidades a la que dedicamos muchas páginas en el libro de Hacking Web Tecnhologies. No solo son de utilidad para un pentester, y también es por eso una herramienta muy utilizada durante el proceso de desarrollo por los programadores de las aplicaciones web, antes de su puesta en producción, en búsqueda de fallos que corregir.

Figura 1: Cómo usar las novedades en ZAP 2.6.0 para hacer pentesting con FOCA

La última versión, la 2.6.0 publicada recientemente presenta algunas características interesantes que me gustaría contaros a continuación, integrándola con la FOCA de ElevenPaths, para sacarle partido en casos como el que os presento hoy.

JxBrowser

Se trata de un contenedor sobre Chromium que viene integrado directamente en esta versión y permite directamente introducir URLs para que ZAP vaya capturando las peticiones/respuestas HTTP. En las versiones anteriores no venía directamente integrado en ZAP y había que instalarlo como un complemento a parte. Ahora lo tienes a golpe de icono.

Figura 2: Icono para lanzar JxBrowser

Presenta la ventaja de que no es necesario configurar de manera manual las opciones de navegación con proxy en un navegador externo a ZAP. Además, introduce por defecto su propia CA para poder monitorizas las peticiones/respuestas que vayan bajo HTTPS con técnicas de Bridging HTTPs.

Figura 3: Mensaje que aparece al lanzar JxBrowser

Para capturar peticiones y respuestas HTTP/HTTPS, únicamente hay que introducir la URL de la web a auditar y ZAP empezará a monitorizar en intercambio de mensajes entre cliente y servidor.

Figura 4: Envío y captura de peticiones HTTP desde JxBrowser

Exportación de las URL detectadas por el spider a un fichero

Una de las características de reporte más demandada hasta el momento y que incorpora esta nueva versión es la posibilidad de exportar en un fichero de texto todas las URL que el spider ha ido encontrando durante el rastreo de la web.

Figura 5: Exportación de las URLs descubiertas a un fichero de texto

Como veremos más adelante, esta funcionalidad puede resultar bastante útil porque, junto con otras herramientas como FOCA, puede ayudar a detectar vulnerabilidades que puede que inicialmente pasen desapercibidas para ZAP, como por ejemplo, localización de métodos HTTP inseguros en el servidor web, listado de directorios abierto, etcétera.

Codificar/Decodificar/Hash

Una característica interesante es la opción de Codificar o Descodificar información. Esta funcionalidad puede ser útil, por ejemplo, en las fases de desarrollo de una aplicación web mientras se prueba el sistema en busca de fallos y se necesita codificar información en formato Base64 o hexadecimal, descodificar una URL.

Figura 6: Herramienta de Codificar/Descodificar/Hash

Figura 7: Diferentes opciones de codificación y decodificación

Figura 8: Opciones de cálculo de Hashes (resúmenes)

A veces puede que necesitemos generar un hash en formato MD5 o SHA1 (nunca obtener el texto claro que genera el hash) para manipular el resumen que aparece en una petición al servidor web.

Prueba de Concepto: ZAP & FOCA

En esta pequeña prueba de concepto vamos a poner en práctica la utilidad de reporte comentada anteriormente: volcar a un fichero de texto las URLs localizadas por el motor de spidering en la fase de descubrimiento de recursos y utilizarlas en la FOCA para la búsqueda de vulnerabilidades en el servidor web, tal y como se podía hacer con las URLs de Burp. Las pruebas se realizarán con algunas de las sedes electrónicas de diversos ayuntamientos españoles.

Figura 9: Documento de la sede electrónica de uno de los ayuntamientos

Tras seleccionar el objetivo y enviar peticiones HTTP/S usando JxBrowser, capturamos las peticiones/respuestas de servidor web y ejecutamos el spider para que busque todos los activos en función del código que se vaya encontrando por las páginas que visita y exportamos las URL localizadas por el spider.

Figura 10: Exportación de URLs a un fichero de texto

Una vez generado el fichero con todas las URLs, lo utilizamos con FOCA para que ésta realice los escaneos oportunos en segundo plano en busca de vulnerabilidades web.

Figura 11: Importando en FOCA las URLs desde un fichero de texto

Una vez que la FOCA se pone a analizar las URLs, vemos como localiza diversas vulnerabilidades: Directory listing, métodos HTTP inseguros y la vulnerabilidad de ShortName presente en el IIS de ciertas versiones de Microsoft Server, y que permite que se listen los ficheros de las carpetas en formato 8:3 haciendo un ataque a ciegas, aún cuando el administrador del sitio haya configurado el servidor para que no se muestren los listados de directorios.

Figura 12: Diversas vulnerabilidades detectadas por FOCA

Analizando la URLs donde FOCA detecta Directory listing, podemos ver cosas tan curiosas como la posibilidad de subir un fichero de texto al sistema sin la necesidad de estar autenticado en la sede electrónica.

Figura 13: Subir un fichero a la sede electrónica sin estar autenticado

También es posible ver ficheros importantes de configuración de la sede electrónica, como el Web.config, ConfigWizard.xml, y algunos ficheros de las fases de prueba y de configuración.

Figura 14: Ficheros importantes de configuración de la sede electrónica

Figura 15: Ficheros .def con información sensible de la configuración

Figura 16: Más directorios con ficheros expuestos

Además, navegando por la URL, es posible llegar hasta el formulario de acceso a la sede electrónica.

Figura 17: Formulario de acceso a la sede electrónica

Si no se han tomado las medidas de protección adecuadas y alguno de los usuarios ha utilizado el mismo login y password, es posible acceder a la sede electrónica.

Figura 18: Acceso a la sede electrónica de un ayuntamiento

Autor: Amador Aparicio (@amadapa), autor del libro "Hacking Web Technologies"

PD: tanto el ayuntamiento como la empresa que ha programado la sede electrónica han sido informadas de estas vulnerabilidades.

Agenda de eventos para la semana del 29 de Mayo al 2 de Junio @elevenpaths @0xWord @luca_d3

Os dejo en el artículo de hoy la lista de citas que tienes que tener en mente para la semana que viene. El momento más importante para nosotros es el Security Day de ElevenPaths, pero los días están llenos de otras actividades que merece que tengas en el radar.

Figura 1: Agenda de eventos para la semana que viene

El lunes 29, como ya os dejé anunciado la semana pasada, comienza el Curso Online de Auditorías Móviles en The Security Sentinel, con una duración de 120 horas y con el libro de 0xWord dedicado al Hacking iOS: iPhone & iPad 2ª Edición como material de estudio .

Figura 2: Curso Online de Auditorías Móviles

El martes 30 yo participaré en el Conversatorio sobre Derechos Digitales de los Ciudadanos. Será en Madrid, el día 30 y está organizado por Red.es. Tienes más información en la web del mismo.

Figura 3: Conversatorio sobre Derechos Digitales de los Ciudadanos. Madrid

El miércoles 31 de Mayo tendrá lugar en Madrid el Security Day 2017: Cybersecurity Beats  de ElevenPaths. Este año tenemos el auditorio lleno, y esperamos que hayas podido conseguir una plaza, porque desde hace tiempo no se confirman registros. Si quieres venir, deberás hablar con tu responsable de cuenta en Telefónica. Yo daré la Keynote de este evento.

Figura 4: Security Day 2017. Cybersecurity Beats

El mismo día, en México D.F. tendrás el Expert CyberSecurity Day, en el que participaremos compañeros de ElevenPaths y Telefónica. Una oportunidad única para venir y conocer más cosas de las que hacemos en México - que son una buena cantidad de ellas -.

Figura 5: Expert Cybersecurity Day en México D.F.

En la Universidad Rey Juan Carlos de Móstoles - donde yo estudié mi doctorado -, del 31 de Mayo al 2 de Junio, tendrán lugar las III Jornadas de Investigación en Cyberseguridad, donde participaremos con una investigación realizada en ElevenPaths el mismo día 31 de Mayo. Tienes toda la información de este evento en la web.

Figura 6: III Jornadas Nacionales de Investigación en Ciberseguridad URJC

El día 1 tendrá lugar el Curso Online de Pentesting con Powershell en The Hackers Club, que tendrá como material de apoyo el libro de mismo título de 0xWord "Pentesting con Powershell". Tiene una duración de 15 horas de clase más prácticas. Más información en la web del curso.

Figura 7: Curso Online de Pentesting con Powershell

Por último, el día 1 de Junio llega OpenExpo 2017 en Madrid, donde participaremos con una charla de ElevenPaths y otra de LUCA D3. Además de que habrá un stand para que puedas adquirir los libros de 0xWord. Yo daré la charla inaugural de este evento.

Figura 8: OpenExpo 2017. Madrid

Después de mi charla inaugural en OpenExpo, iré a Microsoft Madrid al Open Day de los MVPs, así que si eres uno de ellos nos vemos por allí que también daré una sesión.

Y estas son las actividades en las que vamos a tener presencia la semana que viene. Espero que alguna de ellas sea de vuestro interés, y nos veamos presencialmente o por Internet.

Saludos Malignos!

LUCA (@LUCA_d3): Big Data for Social Good in Action 2017 [Vídeos]

Esta semana se ha realizado en las instalaciones de Wayra el evento organizado por LUCA D3 dedicado al uso de las tecnologías Big Data for Social Good. 

Figura 1: Big Data for Social Good in Action 2017 [Vídeos]

En él, además de presentaciones y mesas de debate, hubo presentación y demos de algunas de las soluciones que se están realizando. Los compañeros de LUCA han subido los vídeos a su canal, y ahora podéis ver el evento completo en vuestra casa. Estos son las presentaciones:

Figura 2: Big Data for Social Good in Action 2017 [resumen] 

Figura 3: ¿Qué es Big Data for Social Good y qué importancia tiene? 

Figura 4: ¿Cuáles son los retos de utilizar los datos para tener un impacto social? 

Figura 5: Demo de Big Data for Social Good: Telefónica & UNICEF 

Figura 6: Demo de Vizzuality 

Figura 7: Demo de BBVA

Por último, además de este evento, la semana pasada los compañeros de LUCA hicieron el seminario de cómo utilizar el Big Data para transformar el sector turístico, y aquí tienes la grabación del seminario.

Figura 8: Cómo utilizar Big Data para transformar el sector turístico

Que tengáis un feliz fin de semana a todos, y os entretengan mucho estas presentaciones, que además de enseñar pretenden inspiraros nuevas ideas.

Saludos Malignos!

Developer, protege tu cuenta de GitHub que los malos van a por ti

A finales de Marzo, la Unit 42 de Palo Alto levantó la alerta de una campaña de ataques dirigidos a desarrolladores en GitHub. El malware utilizado para infectar a los desarrolladores y llevarse las passwords de sus cuentas se bautizó como Dimnie, y no era una pieza de software mal diseñada o fácil de analizar, lo que parece probar un ataque dirigido de nivel.

Figura 1: Developer, protege tu cuenta de GitHub que los malos van a por ti

Lo cierto es que si eres desarrollador de software, eres un objetivo goloso para el mundo del cibercrimen, ya que con cuentas robadas se podrían infectar los repositorios de código de esos desarrolladores o, como sucedió con el caso del malware XCodeGhost para OS X, directamente infectar el compilador y que todos los programas salgan ya infectados.

Figura 2: Informe de Dimnie hecho por la Unit 42 de Palo Alto

En el caso de XCodeGhost, con copias piratas de XCode, se consiguieron colar en AppStore 71 apps infectadas con malware que habían sido subidas por desarrolladores que no eran conscientes de estar infectados y estar infectando a todos los usuarios que se descargaban sus apps.

Figura 3: Activación de Segundo Factor de Autenticación en GitHub

Si tienes una cuenta en GitHub donde gestionas código personal o de tu empresa, deberías extremar las precauciones de ella, y entre otras cosas puedes ponerle un 2FA a la misma, utilizando un Cloud TOTP.  Vete a las opciones de cuenta y activa el Segundo Factor de Autenticación en Seguridad.

Figura 4: Activación de 2FA TOTP en GitHub

Selecciona el uso de una app para acceder a los TOTP Tokens, y escanea el QRCode con la app de Latch, como se hace en el resto de los ejemplos que tenéis disponibles de Latch Cloud TOTP.

Figura 5: Cloud TOTP de GitHub en Latch

Así al menos, si alguien te roba la cuenta de GitHub no va a poder estar manipulando tu código sin tu permiso, algo que ya ha pasado en otros casos en el pasado y que va a volver a suceder en el futuro con total seguridad.


Figura 6: Cómo proteger GitHub con Latch Cloud TOTP
En el vídeo de arriba tienes el proceso completo en un par de minutos, para que veas qué sencillo y rápido es el método y cómo puedes mantener mucho más segura tu identidad.

Saludos Malignos!

Cómo ejecutar en red Telefónica WannaCry File Restorer usando Active Directory

La semana pasada publicábamos Telefónica WannaCry File Restorer, un script escrito en Powershell con el que se podía recuperar archivos temporales afectados por el ransomware Wannacry. El script funciona bastante bien en los casos en los que el ransomware ha sido “cortado”, es decir, en un momento dado el proceso ha dejado de funcionar, ya sea porque haya sido parado con un error - muchos casos -  o porque se haya apagado o hibernado el equipo.

Figura 1: Cómo ejecutar en red Telefónica WannaCry File Restorer usando Active Directory

Lo interesante, y por lo que primero nos focalizamos en crear un script en Powershell - además de luego dotar a los usuarios de una versión escritorio de Telefónica WannaCry File Restorer,  es que cualquier equipo de IT que se haya visto afectado por este ransomware puede lanzarlo en su dominio/s con el objetivo de recuperar archivos, sin necesidad de que el usuario final participe en el proceso, aprovechando las posibilidades de Active Directory.


Figura 2: Telefonica WannaCry File Restorer (PowerShell Script)

Para mostrar cómo hacerlo hemos querido montar un pequeño entorno que conste de un dominio Microsoft con un Domain Controller en Windows Server 2016  en y con un par de máquinas Windows cliente.


Figura 3: Telefónica WannaCry File Restores Desktop Version

Por supuesto, se podría proveer la herramienta de escritorio a todos los usuarios, pero la idea es mostrar cómo un administrador del dominio podría lanzar el script Telefonica WannaCry File Restorer con el objetivo de que se ejecute en cada máquina del dominio de forma, totalmente, transparente al usuario, como vamos a ver en la PoC.

PoC:  Ejecutado en TWCFR usando AD

El escenario es sencillo: un controlador de dominio desde dónde invocaremos el script con una instrucción de Powershell, un par de máquinas con sistemas operativos cliente de Windows. Todo el proceso, por parte del equipo de IT, ocurre de forma transparente al usuario, lo cual es un proceso interesante, ya que no genera ruido en el trabajo del usuario.

En la siguiente imagen, se puede ver como invocamos al script de Telefonica Wannacry File Restorer. El comando Invoke-Command es utilizado en Powershell para ejecutar cualquier comando en Powershell y tiene la característica de poder ser ejecutado en un entorno remoto. Si las credenciales que se proporcionan son las de un administrador de dominio, el script podrá ser ejecutado en otras máquinas pertenecientes al dominio.

Figura 4: comando para invocar el script TWCFR desde Powershell

El parámetro –FilePath indica el script que debe ser ejecutado. Cuando el script comienza su ejecución podemos detectar sobre qué path se está ejecutando, en este caso sobre la carpeta %localappdata%\temp del usuario1. Esto puede verse en la siguiente imagen.

Figura 5: El script ejecutándose sobre la carpeta del usuario1

Sin duda, muchos equipos de IT afectados por la lacra del ransomware puede utilizar el dominio para llevar a cabo tareas de limpieza o restauración. En el caso de WannaÇry, cualquier equipo de IT afectado puede utilizar este método para recuperar archivos temporales que hayan quedado en los equipos. Os dejamos un video del funcionamiento del despliegue del script en un dominio Microsoft.

Figura 6: PoC ejecución de TWCFR en un Active Directory

Por supuesto, nosotros recomendamos el uso de herramientas de prevención para evitar cualquier ransomware que pueda afectar en el futuro a tus documentos, y como es el caso de Latch ARW.

Figura 7: Latch AntiRansomware protegiendo frente a WannaCry

Además, la utilización de políticas de backup (en un almacenamiento protegido) adecuadas es fundamental para poder luchar en igualdad de condiciones contra la lacra del ransomware.

Autores: 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 y Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths