Security Art Work

Memorias USB y sus riesgos

La facilidad de uso de memorias USB y discos externos ha provocado que estos dispositivos se conviertan en los preferidos de usuarios de tecnologías para respaldar y compartir información; y esto es tan cierto que ya en el año 2014 el INE, en uno de sus informes, indicaba que el 58% de usuarios de tecnología usaba memorias USB, DVDs y otros dispositivos semejantes para compartir información.

Pero con el creciente uso de dispositivos que ha existido, han surgido varios problemas que afectan directamente a la seguridad de la información personal y de las organizaciones, mencionemos algunos de ellos:

“El 62% de las empresas europeas pierden datos confidenciales por el extravío de memorias USB”. https://www.kingston.com/es/company/press/article/41240.
“Los USB y las tarjetas SD causan el 30 por ciento de las infecciones de malware”. http://cso.computerworld.es/alertas/los-usb-y-las-tarjetas-sd-causan-el-30-por-ciento-de-las-infecciones-de-malware.
Las memorias USB son generalmente usadas por ciberdelincuentes para realizar ataques dirigidos. https://www.incibe.es/sites/default/files/contenidos/kit-concienciacion/incibe_kit_ataques_dirigidos_pendrive_infectado.pdf y https://www.welivesecurity.com/wp-content/uploads/2016/12/Tendencias-2017-eset.pdf.
La mayoría de usuarios no aplican medidas adecuadas para la destrucción de estos dispositivos o el borrado seguro de la información que contienen.
Existen registros de no pocas organizaciones que han visto comprometida su seguridad y la confidencialidad de su información por la pérdida de este tipo de dispositivos.

Pero, ¿qué medidas podemos aplicar a la hora de usar estos dispositivos de almacenamiento para mejorar nuestra seguridad? A continuación un par de recomendaciones:

Evitar la conexión de memorias USB de orígenes desconocidos en nuestro ordenador.
No conectar nuestros dispositivos USB en equipos desconocidos o poco seguros.
Mantener actualizado el sistema operativo, antivirus y aplicaciones de nuestro ordenador.
Revisar con un antivirus actualizado todos nuestros dispositivos de almacenamiento.
Cifrar nuestras memorias USB y discos de almacenamiento. Hacer esto mejorará considerablemente la seguridad de nuestra información puesto que para el acceso a estos dispositivos se requerirá de la contraseña de cifrado que únicamente su propietario debería conocer.

Repasemos algo sobre Bitlocker

Como bien se ha comentado en una entrada de RedesZone, Bitlocker es una herramienta que permite cifrar el contenido de particiones de discos y memorias USB en Sistemas Windows. Sabemos también que el cifrado de dispositivos añade una capa de seguridad para el acceso a la información y esto es lo que BitLocker ofrece a los usuarios de sistemas Windows.

Tras realizar el proceso de cifrado con Bitlocker, el acceso a la información queda protegido por la clave de cifrado que es solicitada al iniciar este proceso.

Accediendo a una memoria USB cifrada en diferentes sistemas

Windows XP. En estos sistemas no es posible acceder a discos cifrados. Si se conecta una memoria USB cifrada en Windows XP el sistema presentará una ventana con dos archivos que permitirán, únicamente, acceder a información genérica relacionada con BitLocker.

(N.d.E: esperemos que ningún lector todavía utilice esta versión de Windows, sin soporte desde hace ya varios años)

Imposibilidad de acceso a datos cifrados en Windows XP

Windows Vista, 7, 8, 10 y Server 2008. Cuando una memoria USB cifrada se conecta en cualquiera de estos sistemas se mostrará una ventana informativa que solicita el ingreso de la clave de cifrado para obtener acceso a los archivos de la memoria.

Ventana solicitando el ingreso de la clave para acceso a los datos

Ejemplo de contenido de una memoria USB cifrada

Sistemas Linux. A no ser que se haga uso de herramientas especiales, el acceso y uso de dispositivos cifrados por BitLocker no es posible en estos sistemas.

En sistemas Linux, cuando una memoria USB cifrada es conectada, esta se abrirá y mostrará un sinnúmero de archivos ininteligibles para el usuario. Además, si queremos agregar nuevos archivos o carpetas dentro de esta memoria nos resultará imposible hacerlo.

Contenido de memoria USB cifrada conectada en un Sistema Linux

Mensaje de error mostrado al tratar de crear una carpeta en una memoria USB cifrada en Linux

Accediendo a los datos de una memoria USB cifrada en Linux

El proyecto de Dislocker, cuyo código se encuentra bajo licencia GPL, nos ofrece herramientas que permiten acceder al contenido de un disco o memoria USB cifrados. A continuación presentamos un ejemplo del proceso de instalación y uso de Bitlocker en Linux.

Requisitos del Sistema

Previo a la instalación de Dislocker, nuestro sistema debe contar con algunas herramientas y librerías. Dependiendo de la versión y distribución Linux con la que contemos la instalación de estas herramientas debe ser realizada de una u otra manera. A continuación te mostramos cómo se debe realizar la instalación de las herramientas necesarias para el funcionamiento de Dislocker en sistemas Ubuntu.

Sistemas Ubuntu 14.xx y versiones anteriores.

$ sudo apt install gcc cmake make libfuse-dev libpolarssl-dev ruby-dev

Sistemas Ubuntu 16.xx y nuevas versiones.

$ sudo apt install gcc cmake make libfuse-dev libmbedtls-dev ruby-dev

Para otras distribuciones podremos consultar la página https://github.com/Aorimn/dislocker/blob/master/INSTALL.md.

Descarga e instalación de Dislocker

Para la descarga de Dislocker debemos ejecutar lo siguiente en nuestro sistema Linux. Esto creará una carpeta llamada “dislocker” con todos los archivos necesarios para la instalación de las herramientas.
```
$ git clone https://github.com/Aorimn/dislocker.git
Cloning into 'dislocker'...
remote: Counting objects: 3368, done.
...  ...
Resolving deltas: 100% (2337/2337), done.
Checking connectivity... done.
$
```
Otra forma de obtener “Dislocker” es ingresar en su repositorio en la URL https://github.com/Aorimn/dislocker y descargarlo en formato comprimido (.zip). Tras la descarga bastará con descomprimir el archivo .zip y estaremos listos para proceder con la instalación.

Imagen de la página del repositorio de Dislockee

A continuación, ingresamos al directorio donde se encuentra toda la información de Dislocker y procedemos con su instalación en nuestro sistema.

$ cd dislocker
$ cmake .
   creating: dislocker-master/
-- The C compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
  ...

  ...
-- Generating done
-- Build files have been written to: /home/usuario/dislocker

$ make
[  2%] Building C object src/CMakeFiles/dislocker.dir/dislocker.c.o
[  5%] Building C object src/CMakeFiles/dislocker.dir/common.c.o
[  7%] Building C object src/CMakeFiles/dislocker.dir/config.c.o
  ...

  ...
[100%] Built target dislocker-bek
Scanning dependencies of target dislocker-find
[100%] Built target dislocker-findcc

$ sudo make install
[sudo] password for usuario:
[ 78%] Built target dislocker
[ 84%] Built target dislocker-metadata
  ...

  ...
-- Set runtime path of "/usr/local/bin/dislocker-bek" to "/usr/local/lib"
-- Installing: /usr/local/bin/dislocker-find
-- Installing: /usr/local/share/man/man1/dislocker-find.1.gz

Accediendo al contenido de una USB cifrada

1. Con todo listo, ya podremos acceder a nuestra USB cifrada y, para esto, lo primero que deberemos hacer será conocer qué nombre se ha asignado a nuestra memoria USB. El comando fdisk nos ayudará a realizar esta tarea.
```
$ sudo fdisk -l
  ...

  ...
Disk /dev/sdd: 7,2 GiB, 7746879488 bytes, 15130624 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf3156acc

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdd1        2048 15130623 15128576  7,2G  c W95 FAT32 (LBA)
$
```
  Claramente podemos ver que nuestra memoria USB tiene el nombre “sdd1”
2. A continuación crearemos un directorio con cualquier nombre en un sitio al que tengamos acceso; recomendamos la creación del nuevo directorio dentro de la carpeta “/tmp/” puesto que su uso será temporal. En nuestro caso hemos creado la carpeta “file_rep”.
```
$ mkdir /tmp/file_rep
```
3. Seguidamente debemos crear el archivo “dislocker-file” con la ayuda de “dislocker-fuse”. El archivo “dislocker-file” contendrá la información descifrada de nuestra memoria USB.
```
$ sudo dislocker-fuse -v -V /dev/sdd1 -uclaveusb -- /tmp/file_rep
```

Ya solo queda montar el archivo con la información descifrada (dislocker-file) y acceder a ella. Para esto crearemos un directorio en “/mnt/” u otro al que tengamos acceso, y luego procedemos a montar en éste el archivo “dislocker-file”.

$ sudo mkdir /mnt/usb
$ sudo mount -o loop,ro /tmp/file_rep/dislocker-file  /mnt/usb

Es el momento de comprobar el contenido de nuestra carpeta. ¡Muy bien! ya podemos acceder al contenido de la memoria USB adecuadamente.

$ cd /mnt/usb
$ ls -l
total 1576
-rwxr-xr-x 1 root root   7124 ene  4 16:27 000.png
-rwxr-xr-x 1 root root 105720 ene  4 16:33 111.png
drwxr-xr-x 2 root root   4096 ene  4 13:15 Documentos
drwxr-xr-x 2 root root   4096 dic 20 12:48 FOUND.000
-rwxr-xr-x 1 root root 104299 ene  4 13:22 Hogar (1).jpg
-rwxr-xr-x 1 root root 140889 ene  4 13:22 Hogar (2).jpg
  ...

  ...
drwxr-xr-x 2 root root   4096 ene  4 13:15 Reservado
drwxr-xr-x 2 root root   4096 dic 11 12:26 System Volume Information
-rwxr-xr-x 1 root root 177838 ene  4 13:18 Viaje (1).jpg
-rwxr-xr-x 1 root root 127092 ene  4 13:19 Viaje (2).jpg
-rwxr-xr-x 1 root root 165127 ene  4 13:18 Viaje (3).jpg
/mnt/usb $

Otra forma de comprobar el contenido de la memoria USB es haciendo uso del gestor de archivos del sistema Linux y accediendo a la carpeta donde hemos realizado el último montaje.

Tras finalizar el uso de memoria USB, será recordable desmontarla.

$ sudo umount /mnt/usb

Esperamos que esta información os sea de utilidad. Por favor, coméntanos los temas sobre los que quieras que continuemos publicando.

La entrada Memorias USB: riesgos, protección y acceso a los datos aparece primero en Security Art Work.

Hace unos meses cambié mi antiguo router TP-LINK por uno de la marca ASUS. Es el primer dispositivo que tengo de ese fabricante, pero ya que lo recomendaba la operadora que tengo contratada decidí comprármelo para evitarme complicaciones.

Entonces llega una tarde de aburrimiento, o quizás por costumbre, y empiezas probando una comita aquí, un marquee como nombre de la red wifi, intentas concatenar un comando en el formulario de los tests de la red y así un largo etcétera. Al final, una cosa lleva a otra, te vas liando, y cuando eres consciente tienes Burp o ZAP abierto, te has repasado medio OWASP y llevas horas buscando algo con lo que jugar, algo interesante para ver cómo de seguro es tu nuevo y flamante router.

Entrando en detalles algo más técnicos, el router que adquirí es un ASUS DSL-N14U B1 cuyo firmware, en el momento en que se realizaron las pruebas, se encontraba en la versión “1.1.2.3_345” publicado el 04/09/2017.

En cuanto a las vulnerabilidades encontradas, la primera aunque la más aburrida, es un Cross Site Scripting (XSS) que aparece cuando se accede a un recurso inexistente sin haber iniciado sesión en el router. Concretamente ocurre al cargar la página de error resultante, y es en ésta donde se inyectara el código JavaScript.

Por ejemplo, al acceder al recurso:

https://<IP>/%22%3E%3Cscript%3Ealert(window.location.path)%3C/script%3E

El código HTML de la página de error resultante es la siguiente:

Siendo ejecutado el código que conforma el recurso accedido:

XSS en la página de error

Sobre la siguiente vulnerabilidad, durante las pruebas relacionadas con el análisis de seguridad web, una buena práctica es revisar todos los recursos que requieren de autenticación para ver si alguno de ellos, debido a una mala configuración o un descuido, realmente no requiere de esta.

En el caso de dicho dispositivo, uno de los pocos recursos que he identificado, y quizás uno de los más relevantes, es el de cambio de contraseña. Es decir, si se conoce como está formada la petición, es posible cambiar las credenciales de acceso de cualquier usuario como puede ser el usuario Administrador. Además, dichos privilegios se aplican a otras funcionalidades del router como es el servicio AiCloud del que hablaremos más adelante.

Siendo la petición de cambio de contraseña la siguiente:

Basta con modificar el campo http_passwd para modificar la contraseña del usuario administrador (admin). Esto implica que cualquier usuario que tenga acceso a la interfaz web de la aplicación puede cambiar la contraseña de cualquier usuario de ésta, y acceder al panel de administración del router.

Para simplificar el “complicado” proceso, el siguiente script en Python (3) nos permite cambiar la contraseña de administrador si ésta se nos ha “olvidado”:

Para ejecutar el script basta con pasarle como argumentos la ip, el usuario y nuevo password a establecer. Por ejemplo:

python3 asus-passReset.py https://192.168.1.1 admin raccoon

Pese a que la vulnerabilidad anterior es la más crítica, revisando uno de los servicios que ofrece ASUS en sus dispositivos, encontré un par de vulnerabilidades curiosas. El servicio en cuestión es AiCloud que en palabras de la propia ASUS permite:

“ASUS AiCloud te mantiene conectado a tus datos siempre que tengas una conexión a Internet. Conecta tu red doméstica y tu servicio de almacenamiento web en línea, y te permite acceder a los datos desde la aplicación para dispositivos móviles AiCloud de tu smartphone iOS o Android, o a través de una URL personalizada que introduces en tu navegador web…”

Formulario de acceso a AiCloud

Dicho servicio, deshabilitado por defecto, es accesible mediante el puerto 449 (por defecto):

Las vulnerabilidades, ambas son del tipo XML External Entity (XXE), permiten aprovechar una incorrecta validación en el análisis del XML recibido para, por ejemplo, acceder a ficheros del sistema.

Para ello, accedemos al recurso:

https://<IP>:<PUERTO>/smb/css/setting.html

Éste gestiona las distintas cuentas que tienen acceso al servicio AiCloud:

Interfaz de creación de cuentas

Al crear una:

Formulario de creación de cuenta

La información interesante aparece reflejada en la petición enviada al servidor:

La parte interesante aparece en el cuerpo de la petición POST, tratándose de un XML con la información de la cuenta. En este punto supongamos que, como en el caso anterior, hemos olvidado las credenciales de algún usuario del sistema. Para recuperarlas, podemos modificar dicho XML para, por ejemplo, mostrar el fichero /etc/passwd:

Siendo la respuesta del servidor un ‘200 OK’ puesto que el usuario que estamos creando no existe en la plataforma. A continuación, al volver a acceder al recurso de gestión de las cuentas (https://<IP>:<PUERTO>/smb/css/setting.html) aparecerá el contenido del fichero solicitado:

Resultado de explotar la vulnerabilidad XXE

La segunda vulnerabilidad de esta categoría es similar y se encuentra en el recurso:

Dicho esto, cabe decir que el modelo que he utilizado para las pruebas no es el único afectado. A partir de los modelos actualizados con parches similares, los siguientes routers también están afectados (puede que haya más):

DSL-AC51
DSL-AC52U
DSL-AC55U
DSL-N55U C1
DSL-N55U D1
DSL-AC56U
DSL-N10_C1
DSL-N12U C1
DSL-N12E C1
DSL-N14U
DSL-N14U-B1
DSL-N16
DSL-N16U
DSL-N17U
DSL-N66U
DSL-AC750

Timeline

18/09/2017 – Informo a ASUS de las vulnerabilidades.
18/10/2017 – Confirmación por parte del ASUS.
18/10/2017 – Parcheo de la vulnerabilidad del cambio de contraseña y publicado firmware beta.
24/10/2017 – Solucionadas las vulnerabilidades restantes y publicado firmware beta.
28/11/2017 – Publicada la versión final del firmware con las vulnerabilidades solucionadas.

Es importante también mencionar de forma positiva la gestión por parte de ASUS del incidente, pues su equipo de seguridad en todo momento demostró una correcta predisposición y una fluida interacción para resolver las vulnerabilidades.

Conclusión

He esperado un mes para publicar esta entrada, tiempo que a mi parecer, es suficiente para que se actualicen los dispositivos (no se hace automático). En caso de no haber actualizado, mi consejo es hacerlo con la mayor brevedad posible (a no ser que quieras conservar un método de cambio de contraseña alternativo).

¡Nos leemos en “breve”!

@aetsu

La entrada Alguna que otra vulnerabilidad en los routers de ASUS aparece primero en Security Art Work.

La tendencia de “estar permanentemente conectados” pone a nuestra disposición una serie de herramientas con las que “hacer nuestra vida más cómoda” pero esto, a su vez, nos expone a múltiples amenazas que pueden repercutir negativamente en nosotros como individuos o en nuestras organizaciones. Cabe pensar que esta cuestión está muy interiorizada por quienes se dedican de forma directa o indirecta al mundo de la seguridad. Sin embargo, la realidad nos lleva a descubrir que el número de anécdotas y noticias relativas a incidentes de seguridad sigue creciendo y, en muchos casos, los protagonistas son precisamente quienes se dedican a la seguridad.

En la entrada de hoy ponemos el foco en el impacto que ha ocasionado la información recabada y publicada a través de la herramienta Strava.

Breve resumen para quien no haya seguido las noticias: Strava es una herramienta dirigida principalmente a deportistas que permite posicionar y registrar el recorrido de un usuario como pudiera ser un corredor o un ciclista. Esto ha permitido conocer la posición de bases y centros de operaciones secretas de los servicios de defensa debido a que los soldados utilizaban dicha aplicación y la información de sus rutas se incorporaba a un mapa mundial disponible para todos los usuarios.

Analizando el caso con un poco de perspectiva podemos pensar que una fuga de información en Runtastic, Wikiloc, etc. podría sacar a la luz información muy similar. De hecho, han pasado ya cinco años desde que abrimos el debate sobre las repercusiones de registrar todos nuestros pasos en Internet (ver Pulgarcito y las migas digitales (I) (II)) y ya por entonces una gran mayoría creíamos conveniente reducir y controlar este hábito.

Sirva lo ocurrido para incentivar la reflexión y tengamos en cuenta los siguientes aspectos:

Dispositivos personales vs profesionales: aunque se haga una correcta separación entre el uso personal y profesional de los dispositivos, es necesario valorar la posibilidad de que el uso de nuestro dispositivo personal pueda desvelar información sensible. Por ejemplo, en lo que respecta a la localización de las bases secretas, poca relevancia tiene si la fuente de información era el dispositivo corporativo o el personal de los usuarios.
Configuración segura: muchas herramientas incluyen opciones para salvaguardar la privacidad de nuestra información. Antes de utilizar las aplicaciones con la configuración por defecto, conviene revisar y confirmar que las opciones de seguridad están debidamente ajustadas. En el caso de Strava, se recomienda establecer un radio de privacidad holgado respecto a donde vivimos, para mantener en el anonimato nuestro lugar de residencia.
Múltiples fuentes de información: podemos pensar a priori que los datos recabados a través de una aplicación como Strava no sean “tan sensibles” para un usuario convencional. Sin embargo, no hay que perder de vista que dicha información unida a la que se puede recabar de otros servicios (redes sociales, aplicaciones para pedir taxis, comida a domicilio, etc.) permiten generar un perfil personal muy detallado que sí preferiríamos salvaguardar.
Fugas de información: no existe sistema 100% seguro, por lo que aun siguiendo las mejores prácticas siempre existe la posibilidad de que pudiera haber una fuga de información. Dada esta situación, si tratamos información especialmente sensible conviene prestar más atención a los riesgos y evaluar las posibles consecuencias y repercusiones derivadas de una potencial fuga de información. Según hemos leído en diversas noticias, se instaba a los soldados a que gastaran la aplicación para incrementar su motivación y ganas de superarse. En este caso los “contras” superaban con creces las ventajas que aportaba. En vistas a lo ocurrido, seguro que los responsables de seguridad hubieran preferido que los soldados controlaran las series de entrenamiento con el clásico crono de mano en lugar de con las herramientas de tracking.

Las recomendaciones previamente referidas van dirigidas principalmente al usuario, pero naturalmente las organizaciones van a tener que actualizar sus normativas y protocolos de seguridad para hacer frente a dichas amenazas. No sería de extrañar que llegado su momento nos resulte familiar encontrar carteles informativos recordando que se prohíbe el uso de herramientas que utilicen geoposicionamiento.

Es evidente que para muchas organizaciones restringir el uso de estas aplicaciones deportivas no sea un aspecto prioritario. Sin embargo, sí puede ser un tema a contemplar en el corto plazo por aquellas compañías que tratan información muy sensible, como pueden ser aquellas cuyas instalaciones hayan sido designadas infraestructura crítica.

Esperamos que la lectura os haya resultado interesante y que si sois usuarios de este tipo de aplicaciones, os sirva para hacer un uso más seguro.

Un saludo.

[Sobre Samuel Segarra]

Enlaces relacionados:

La entrada Zona Restringida: Geoposicionamiento no permitido aparece primero en Security Art Work.

Destacado: CrossRat

Un mes más, desde el laboratorio de malware de S2 Grupo queremos compartir con vosotros lo que se está cociendo en el mundo del malware. Como siempre, comentaros que en este tipo de entradas encontraremos amenazas conocidas, vistas en otras fuentes o analizadas directamente en nuestro laboratorio, pero el objetivo del post es conocer qué tipo de amenazas están activas.

A continuación mostramos un diagrama con la información recopilada este mes desde el laboratorio:

Para poder observar de un modo más visual determinadas tendencias relativas a la infraestructura de algunas amenazas actuales, una vez más queremos mostraros unas gráficas que consideramos interesantes. La idea es sencilla y consiste en recopilar de diferentes fuentes abiertas y de fuentes propias, direcciones IP de Command and Controls (C2 a partir de ahora). Después, esta información recopilada la representamos de diferentes maneras como veremos a continuación:

TOP 5 C2

La primera consiste en el TOP 5 de C2 distintos encontrados por un mismo tipo de malware, lo cual nos ayuda a hacernos una idea de su nivel de actividad durante este mes:

Además, los diferentes colores identificados en la leyenda de la derecha, muestran el país al que corresponden cada una de las direcciones IP de dichos C2.

TOP10 de direcciones IP con dominios de C2

En segundo lugar, tenemos organizado el TOP10 de direcciones IP con mayor cantidad de dominios de C2 distintos que hemos recopilado.

Esta vez los colores nos muestran el tipo de malware al que corresponde cada dominio de dichas IP.

El Troyano multi-plataforma CrossRAT

Mucho se ha hablado este mes de esta nueva amenaza ya que, por el lenguaje en el que está desarrollado, puede ser ejecutado sobre cualquier sistema operativo capaz de ejecutar Java, y sus desarrolladores aprovecharon para desarrollar cada una de sus escasas funcionalidades, de forma que funcionasen en la mayoría de sistemas. Por una parte es destacable el hecho de que los actores detrás de esta amenaza son un grupo reconocido como grupo de APT que han realizado campañas entre las que destacan algunas orientadas a dispositivos Android.

Por otra parte, la amenaza en sí, no es nada del otro mundo. Un ejemplo es su persistencia, especialmente la alternativa que adopta para sistemas Windows, la cual consiste en la más clásica de todas, basada en la clave de registro estrella en lo que a estos fines se refiere:

Por otra parte cuenta con detalles como que para monitorizar el teclado y ratón utiliza una librería publica que se puede descubrir en primer lugar, analizando los “Strings” del fichero:

Y gracias a que no cuenta con ningún tipo de ofuscación o técnica anti análisis, mirando su código fuente, podemos observar como han cargado toda la librería, incluyendo hasta los ficheros con ejemplos que son totalmente irrelevantes a la hora de la utilización de esta:

La aparente simplicidad de esta herramienta no la hace menos peligrosa, ya que, en cuanto a funcionalidad, es capaz de realizar correctamente cada una de las tareas para las que está ideada, y gracias a esta metodología de desarrollo, pueden ser capaces de realizar herramientas rápido y modificarlas de forma fácil, lo que provoca que por no ser conocidas, pueden pasar inadvertidas durante un tiempo, sin demasiadas complicaciones.

Exploitkits (EK) más activos

Como siempre, repasamos la reciente actividad de los distintos ExploitKits (EK) con más impacto durante este mes. Durante este mes de Enero, la única actividad que hemos observado de forma destacable ha sido la del exploitkit RIG EK.

Este exploitkit ha aprovechado para infectar a sus víctimas con todo tipo de malware, ya que hemos visto desde RATs como Remcos o Ramnit, el reciente y especialmente activo ransomware GrandCrab y la nueva moda entre los distintos actores detrás de campañas de malware, un CoinMiner de Monero basado en el código público en GitHub de XMRig.

Como siempre, recordar que una de las mejores medidas para evitar infecciones a través de este vector de ataque, consiste en mantener actualizado tanto el navegador como cada uno de sus componentes.

Principales campañas de infección a través de malspam

Un mes más, las campañas de infección a través de correos SPAM, generalmente provenientes de distintas botnets como la de Necurs, han destacado en actividad sobre los ExploitKits.

De entre las dos principales técnicas de infección que solemos observar, las que se basan en exploits, se han decantado este mes por utilizar el CVE-2017-11882, a partir del cual, han intentado infectar a sus víctimas con el Stealer FormBook.

En cuanto al segundo método, generalmente más común dado que se refiere a documentos de office con macros, hemos podido encontrarnos con todo tipo de RATs, como gh0stRat, JRat, ZBot o NanoCore.

Los documentos con macros maliciosas requieren que el usuario interactúe con ellos, por lo que no confiar en documentos de orígenes desconocidos, especialmente que nos piden que habilitemos su contenido, supone una gran medida de seguridad al alcance de todo el mundo que puede evitar la mayoría de infecciones por estas vías.

Desde el laboratorio de malware esperamos que les sea de utilidad esta información que compartimos cada mes.

La entrada Tendencias de malware. Enero 2018 aparece primero en Security Art Work.

Ayer CCN-CERT publicó el comunicado relativo al relanzamiento del grupo CSIRT.es, foro que aglutina a los equipos de respuesta ante incidentes españoles o con ámbito de actuación en España, y cuyo objetivo es centralizar el intercambio de información y facilitar la coordinación entre estos mismos equipos.

Actualmente CSIRT.es lo componemos más de veinte equipos y, como se indicaba en el comunicado, están representados actores públicos y privados, de diferentes sectores, con diferentes objetivos… pero que tienen muchos puntos en común; el principal, por definición, dotar de una capacidad de respuesta a una comunidad determinada. Y esa capacidad hoy en día no puede funcionar si se pretende operar de manera independiente y aislada de otros equipos: requiere necesariamente de vías directas de colaboración con terceros. Más allá de foros como FIRST o TF-CSIRT, creemos que un punto que posibilite la colaboración entre CSIRT con ámbitos de actuación en España es más que interesante y necesario.

Por este motivo, y muchos otros, desde S2 Grupo CERT, miembro de la comunidad de CSIRT españoles, consideramos muy importante esta iniciativa, retomando el papel de CSIRT.es como foro que debe mejorar las relaciones de confianza entre grupos, las debe institucionalizar (al menos hasta cierto punto) y debe constituir un elemento de mejora común de las capacidades de los diferentes CSIRT que operan en España, cada uno con su casuística particular pero todos ellos con muchos elementos en común, como hemos indicado. Creemos que compartir experiencias y conocimiento y potenciar ese intercambio de información del que tanto se habla pero que, en la práctica, no siempre es tan perfecto (en PowerPoint funciona todo… en la vida real es más complicado ;), deben ser el motivo principal de la existencia del foro.

No vamos a extendernos en este post para no repetir lo ya dicho por CCN-CERT. Durante 2018, desde S2 Grupo CERT compartiremos con CSIRT-CV la coordinación del grupo, tarea para la cual nos apoyan con su experiencia tanto IrisCERT como CCN-CERT, y desde dicha coordinación confiamos en poder ayudar a lograr los objetivos del foro, apoyar la mejora de las capacidades nacionales y, sobre todo, intentar que todos aprendamos un poco más para que cuando se materialice el próximo WannaCry, o cuando se publique la próxima vulnerabilidad (con logo, que si no no es importante ;) podamos responder mejor. Y todo esto, a punto de que el Gusano de Morris, y poco después el primer CERT, cumplan treinta años. Ya ha llovido…

La entrada CSIRT.es aparece primero en Security Art Work.

(Esta entrada ha sido elaborada en colaboración con Ana Marzo, de Equipo Marzo, que proporcionó buena parte de la información).

Hace apenas un par de semanas se ponía en contacto conmigo Ana Marzo, de Equipo Marzo, una abogada por la que tengo un gran respeto profesional, para comentarme acerca de la publicación, no esperada (al menos por mí), de un nuevo reglamento de la Comisión relacionado con la Directiva NIS, que he llamado en un alarde de originalidad Reglamento de ejecución NIS.

En efecto, el pasado 30 de enero se publicó el Reglamento de Ejecución (UE) 2018/151 de la Comisión, de 30 de enero de 2018, por el que se establecen normas para la aplicación de la Directiva (UE) 2016/1148 del Parlamento Europeo y del Consejo en lo que respecta a la especificación de los elementos que han de tener en cuenta los proveedores de servicios digitales para gestionar los riesgos existentes para la seguridad de las redes y sistemas de información, así como de los parámetros para determinar si un incidente tiene un impacto significativo.

Al menos a mí me pilló por sorpresa (y estoy seguro de que a algunos de nuestros lectores les pasará lo mismo), ya que esperaba una transposición de la directiva, no un reglamento que emanara directamente de la Comisión (lo que no quita que, por supuesto, vayamos a disfrutar de nuestra propia legislación NIS-compliant, que al legislador hay que tenerlo ocupado…). Dado que, aunque en ambitos diferentes, ambos habíamos coincidido en un mismo cliente que encajaba en el concepto de proveedor de servicios digitales y por tanto podría verse afectado, nos preguntamos por la aplicabililidad del reglamento a este cliente en concreto. Por ejemplo, ¿está afectado un periódico online? ¿Y una web de venta online? ¿Un bingo online? ¿Y la compra-venta entre particulares? Derimir la respuesta a estas preguntas es el objeto de esta entrada.

La cuestión principal para determinar el alcance del Reglamento de Ejecución 2018/151 radica en determinar qué entiende este como “proveedor de servicios digitales”. Para ello, el primer punto pasa por analizar su objeto, que se establece en el artículo 1, y que referencia directamente a la Directiva 2016/1148 (a lo largo de este texto, la cursiva y la negrita son del autor, no del original):

El presente Reglamento precisa los elementos que han de tener en cuenta los proveedores de servicios digitales a la hora de establecer y adoptar medidas para garantizar un nivel de seguridad de las redes y sistemas de información que utilizan en el marco de la oferta de los servicios contemplados en el anexo III de la Directiva (UE) 2016/1148, y detalla los parámetros para determinar si un incidente tiene un impacto significativo en la prestación de dichos servicios.

Para identificar la naturaleza de dicha oferta de servicios, es necesario revisar lo que la Directiva 2016/1148, relativa a las medidas destinadas a garantizar un elevado nivel común de seguridad de las redes y sistemas de información en la Unión, actualmente en proceso de transposición a la legislación española y conocida en el sector como Directiva NIS, especifica en su anexo III:

Tipos de servicios digitales a efectos del artículo 4, punto 5, de la propia directiva:

1. Mercado en línea.

2. Motor de búsqueda en línea.

3. Servicios de computación en nube.

Si acudimos al artículo 4, punto 5, de la misma Directiva NIS, esta define “servicio digital” como:

[…] un servicio en el sentido del artículo 1, apartado 1, letra b), de la Directiva (UE) 2015/1535 del Parlamento Europeo y del Consejo que sea de uno de los tipos que figuran en el anexo III.

Y “proveedor de servicios digitales” como:

[…] toda persona jurídica que preste un servicio digital.

Si seguimos desenrollando la madeja y atendemos a lo que especifica el artículo 1, apartado 1, letra b de la Directiva 2015/1535, por la que se establece un procedimiento de información en materia de reglamentaciones técnicas y de reglas relativas a los servicios de la sociedad de la información, esta define “servicio” como:

[…] todo servicio de la sociedad de la información, es decir, todo servicio prestado normalmente a cambio de una remuneración, a distancia, por vía electrónica y a petición individual de un destinatario de servicios.

A efectos de la presente definición, se entenderá por:

i) «a distancia», un servicio prestado sin que las partes estén presentes simultáneamente,

ii) «por vía electrónica», un servicio enviado desde la fuente y recibido por el destinatario mediante equipos electrónicos de tratamiento (incluida la compresión digital) y de almacenamiento de datos y que se transmite, canaliza y recibe enteramente por hilos, radio, medios ópticos o cualquier otro medio electromagnético,

iii) «a petición individual de un destinatario de servicios», un servicio prestado mediante transmisión de datos a petición individual.

En el anexo I figura una lista indicativa de los servicios no cubiertos por esta definición;

Es especialmente interesante analizar las excepciones que el anexo I referencia, en concreto en lo referente al punto i):

1. Servicios no ofrecidos «a distancia»:

Servicios prestados en presencia física del prestador y del destinatario, aunque impliquen la utilización de dispositivos electrónicos:

a) revisión médica o tratamiento en la consulta de un médico con utilización de equipo electrónico, pero con la presencia física del paciente;

b) consulta en la tienda de un catálogo electrónico en presencia física del cliente;

c) reserva de billetes de avión a través de una red de ordenadores realizada en una agencia de viajes en presencia física del cliente;

Si además atendemos a lo que se especifican como excepciones a los puntos ii) y iii), realizando un análisis diferencial, parece claro que el concepto de “servicio” según lo entiende la Directiva NIS incluye, por defecto, la práctica totalidad de servicios web y comercio electrónico:

2. Servicios no ofrecidos «por vía electrónica»

— Servicios cuyo contenido es material, aunque se presten utilizando dispositivos electrónicos:

a) expendeduría automática de billetes (billetes de banco, billetes de ferrocarril);

b) acceso a redes de carretera, aparcamientos, etc., de pago, aun cuando en las entradas o salidas haya dispositivos electrónicos que controlen el acceso o aseguren el pago adecuado.

— Servicios fuera de línea: distribución de CD-ROM o de programas informáticos en disquetes.

— Servicios no prestados por medio de sistemas electrónicos de tratamiento o almacenamiento de datos:

a) servicios de telefonía vocal;

b) servicios de fax y télex;

c) servicios prestados por medio de telefonía vocal o fax;

d) consulta médica por teléfono o fax;

e) consulta jurídica por teléfono o fax;

f) marketing directo por teléfono o fax.

3. Servicios no prestados «a petición individual de un destinatario de servicios»

Servicios prestados mediante transmisión de datos sin petición individual y destinados a la recepción simultánea por un número ilimitado de destinatarios (transmisión punto o multipunto):

a) servicios de radiodifusión televisiva (incluidos los servicios de cuasivídeo a la carta) contemplados en el artículo 1, apartado 1, letra e), de la Directiva 2010/13/UE;

b) servicios de radiodifusión sonora;

c) teletexto (televisivo).

A más abundamiento, el Anteproyecto de Ley NIS establece en su artículo 2 como “Ámbito de aplicación”:

1. Esta ley se aplicará a la prestación de:

a) Los servicios esenciales dependientes de las redes y sistemas de información comprendidos en los sectores estratégicos definidos en el anexo de la Ley 8/2011, de 28 de abril, por la que se establecen medidas para la protección de las infraestructuras críticas.

b) Los servicios digitales, considerados conforme se determina en el artículo 3 e) que sean mercados en línea, motor de búsqueda en línea y servicios de computación en nube.

Si atendemos a la definición que de “servicio digital” hace el anteproyecto en el artículo 3, letra e, este se define como:

[…] servicio de la sociedad de la información entendido en el sentido recogido en la letra a) del anexo de la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico

Lo que la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSICE), define como:

a) “Servicios de la sociedad de la información” o “servicios”: todo servicio prestado normalmente a título oneroso, a distancia, por vía electrónica y a petición individual del destinatario.

El concepto de servicio de la sociedad de la información comprende también los servicios no remunerados por sus destinatarios, en la medida en que constituyan una actividad económica para el prestador de servicios.

Son servicios de la sociedad de la información, entre otros y siempre que representen una actividad económica, los siguientes:

1. La contratación de bienes o servicios por vía electrónica.

2. La organización y gestión de subastas por medios electrónicos o de mercados y centros comerciales virtuales.

3. La gestión de compras en la red por grupos de personas.

4. El envío de comunicaciones comerciales.

5. El suministro de información por vía telemática.

No tendrán la consideración de servicios de la sociedad de la información los que no reúnan las características señaladas en el primer párrafo de este apartado y, en particular, los siguientes:

[…]

Por tanto, queda claro que la naturaleza de los servicios afectados por el reglamento de ejecución objeto de este documento son, en un sentido amplio y además de muchos otros, todas las páginas dedicadas al comercio electrónico y la provisión de información al usuario, si esta está enmarcada en una actividad económica del responsable.

Sin embargo, la aplicación de las medidas especificadas supondría un coste desproporcionado e inasequible para un gran número de empresas, por lo que la Directiva NIS, en su artículo 16, apartado 11, “Requisitos en materia de seguridad y notificación de incidentes”, especifica que:

El presente capítulo no se aplicará a las microempresas y pequeñas empresas tal como se definen en la Recomendación 2003/361/CE de la Comisión.

La recomendación 2003/361/CE define en su artículo 2 a las pequeñas empresas y microempresas según los siguientes parámetros:

1. La categoría de microempresas, pequeñas y medianas empresas (PYME) está constituida por las empresas que ocupan a menos de 250 personas y cuyo volumen de negocios anual no excede de 50 millones de euros o cuyo balance general anual no excede de 43 millones de euros.

2. En la categoría de las PYME, se define a una pequeña empresa como una empresa que ocupa a menos de 50 personas y cuyo volumen de negocios anual o cuyo balance general anual no supera los 10 millones de euros.

3. En la categoría de las PYME, se define a una microempresa como una empresa que ocupa a menos de 10 personas y cuyo volumen de negocios anual o cuyo balance general anual no supera los 2 millones de euros.

Dado que el reglamento objeto de esta entrada (2018/151) contiene básicamente el desarrollo del artículo 16 de la Directiva NIS (artículos 2 y 3), cabe concluir que el Reglamento 2018/151 es de aplicación para, entre otras, aquellas empresas de prestación de servicios digitales (comercio electrónico, suministro de información por vía telemática en el marco de una actividad económica, publicidad online, etc.) que:

i) empleen a más de 50 personas o

ii) cuyo volumen de negocios o balance general anual supere los 10 millones de euros.

(Nótese que por las leyes de Morgan, la negación de la conjunción es la disyunción de las negaciones, o ¬(P ∧ Q) equivale a (¬P ∨ ¬Q), lo que tiene importantes implicaciones en la aplicabilidad).

Es decir, un buen número de empresas que probablemente desconocen que están afectados por el reglamento.

Para acabar, aunque no es mi intención analizar el reglamento de ejecución, que es tan corto como larga su descripción (apenas 2 páginas, si obviamos los considerandos), su aplicación (a partir del 10 de mayo) se resume grosso modo en un puñado de puntos:

Implantar un Sistema de Gestión de Seguridad de la Información.
Implantar un Sistema de Gestión de la Continuidad del Negocio.
Implantar un Procedimiento de Gestión de Ciberincidentes.

Lo que, dicho así, parece fácil, pero luego quizá sea algo más trabajoso.

Y hasta aquí, nuestra entrada de hoy. Dar de nuevo las gracias a Ana Marzo, y si alguno de ustedes ve algún error o está en desacuerdo con algo de lo expuesto, estaré encantado de discutirlo e incluso corregir mis palabras, que ya saben que excepto la muerte, nada ni nadie es infalible.

Pasen un buen día.

La entrada Publicación del Reglamento de ejecución NIS (para proveedores de servicios digitales) aparece primero en Security Art Work.

Aunque es probable que no sea una sorpresa para nadie, es bien sabido que muchas unidades de almacenamiento en red NAS tienen la posibilidad de compartir (de forma automática por UpnP) contenido multimedia a través de Internet. Esto es genial si te encuentras en casa de tu novia o novio y quieres enseñarle las fotos de las vacaciones o hacer noche de manta y peli con la última película que has comprado en formato digital. O por qué no, para compartir recursos por motivos laborales.

Pero, ¿qué pasa si no se configura correctamente el NAS? Pues…

Echándole un ojo a Shodan, sin necesidad de disponer de cuenta siquiera, es posible encontrar tronquis (Twonky) por todo el globo.

Ilustración 1: En la búsqueda se ha usado el término “Twonky”

Tal como se muestra en la imagen anterior, aparecen servidores Twonky sin tener que ser un experto en usar el buscador de Shodan. Además, si se observa la respuesta, se puede identificar fácilmente cuál es accesible, comprobando la respuesta de la petición HTTP (200 para las que interesan, 404 para los que no). Pero una vez identificada la dirección (de nuestro propio servidor, obviamente) viene lo bueno, y es que accederemos a todos los recursos que tengamos compartidos.

Ilustración 2: Dashboard

Si se accede a una carpeta para ver el contenido veremos algo como lo siguiente (obviamente los nombres de los ficheros pueden variar).

Ilustración 3: Contenido de la carpeta.

“Curiosamente”, al pinchar sobre el archivo para reproducirlo/descargarlo, se ve que la IP corresponde con lo siguiente (o algo similar, según el caso del fichero): http://127.0.0.1:9001/disk/DLNA-PNPV_DIVX_DX50-OP01-FLAGS01700000/O0$3$27I232976.avi

Sí, no hay nada mejor como el hogar. Obviamente apuntando al localhost del propio dispositivo no se accederá al contenido.

Ilustración 4: Nope, esa dirección no vale.

Sin embargo, si se cambia la URL y se pone la que corresponde a nuestro servidor…

Ilustración 5: “127.0.0.1” cambiado por la IP pública.

¡BINGO! Comenzará a descargar el fichero, en este caso un vídeo. En caso de que se trate de acceder a una imagen, el propio navegador la abrirá.

Ilustración 6: Ejemplo de imagen de otro de nuestros servidores, esta vez desplegado en el puerto 9000.

Pero no todo acaba ahí, porque nuestro buen Twonky (o Twink, como los pastelitos) tiene unas configuraciones muy chachis. A mi parecer la más interesante para el “buen usuario” es habilitar la agregación (Enable Aggregation), más aún si se selecciona el modo AutoCopy. Con el cual se copiará a este servidor el contenido compartido del resto de servidores que haya en la red.

Ilustración 7: Configuración de los modos de agregación.

Además de seleccionar qué es lo que se va a compartir del propio servidor.

Ilustración 8: Selección de carpetas a compartir.

Desde el punto de vista de un atacante (o de alguien que busque películas y series en vez de usar Netflix), se podría acceder a recursos con contenido sensible; todos recordamos lo ocurrido con diversas celebridades y las filtraciones de fotografías. Sin descartar fotografías de planos de futuros edificios, capturas de pantalla con información, e incluso grabaciones de audio, puesto que también se puede distribuir música.

La solución para evitar que esto esté accesible para todos es sencilla; deshabilitar el acceso desde fuera de la red interna. Y de paso establecer la configuración correctamente, con credenciales para el administrador para empezar.

Ilustración 9: Configuración del usuario administrador.

La entrada De cómo tu “tronqui” compartió su vida por Twonky aparece primero en Security Art Work.

Con este artículo me gustaría abrir una serie de entradas para que la gente que esté interesada en el sector de la seguridad informática y se esté iniciando en él, tenga un punto de partida e ideas para hacer sus propias herramientas o mejorar las actuales. La intención principal es que al final de la serie se hayan podido explicar varias herramientas relacionadas con la seguridad informática, tanto de ataque como defensa, de forma que cada cual pueda conseguir un laboratorio propio donde practicar sus habilidades.

Wifi GL-AR150 Pineapple Nano 2.0.2 “Enhanced”

El primer gadget de nuestro nuevo laboratorio será una Wifi Pineapple Nano hecha con un router GL.Inet GL-AR150 y una tarjeta de Wifi USB TP-Link TL-WN722N v1. Usaremos una máquina con Linux de 64 bits para este propósito.

¿Por qué un GL-AR150 y una TL-WN722N v1? Por sus características:

GL-AR150:
– Memoria RAM: 64MB
– Memoria Almacenamiento: 16MB Flash + MicroSD
– SoC: Atheros AR9331
– Conectividad: 2×10/100 Mbit Puertos Ethernet, 802.11 b/g/n Wi-Fi hasta 150Mbps
– Debug: Consola Serie via UART (GND,Tx,Rx)
– Puertos expansión: 6 GPIO, MicroSD ,5V, 3.3V y GND
– Miscelánea: Reset, Leds estado
– Alimentación: Micro USB 5V
TL-WN722N v1:
– Chipset: Atheros AR9271 802.11 b/g/n

Frente a:

Wifi Pineapple Nano Original:
– CPU: 400 MHz MIPS Atheros AR9331 SoC
– Memoria RAM: 64 MB DDR2 RAM
– Memoria Almacenamiento: 16 MB ROM + Micro SD (no incluida)
– Conexiones Wireless: Atheros AR9331 + Atheros AR9271, ambas IEEE 802.11 b/g/n
– Puertos: (2) RP-SMA Antenas, Ethernet over USB (ASIX AX88772A), USB 2.0 Host, Micro SD
– Miscelánea: Indicador LED y Botón Reset configurables
– Alimentación: USB 5V 1.5A

No hace falta decir que las similitudes entre las dos configuraciones son evidentes, así que no es muy descabellado pensar que podrían comportarse de forma similar.

Para ello lo que tenemos que hacer es:

Hacernos con el “firmware-mod-kit” de https://code.google.com/archive/p/firmware-mod-kit/wikis/Documentation.wiki siguiendo su how-to paso a paso
Extraer el firmware de la Wifi Pineapple original de su página oficial (https://www.wifipineapple.com/nano) con el “firmware-mod-kit” —> ./extract-firmware.sh upgrade-2.0.2.bin
Hacer un clone de la versión de OpenWRT del Github del equipo que desarrolla este firmware para el GL-AR150 —> clone https://github.com/domino-team/openwrt-cc/tree/73d51063bca71574206f2ce162f6bc6046f8e3ab/include
Copiaremos todo el contenido de los datos extraídos del firmware en la carpeta del firmware OpenWRT que estamos compilando —> cp -r firmware-mod-kit/fmk/rootfs/* openwrt-cc/files/
Borraremos los módulos de OpenWRT ya que estos no los necesitaremos —> rm -rf openwrt-cc/files/lib/modules/3.18.23/
Borraremos también los módulos en versión de prueba —> rm -rf openwrt-cc/files/sbin/modprobe
Finalmente podremos compilar nuestro firmware —> make menuconfig (y por último) make

Por si no tenéis claro los pasos a seguir podéis guiaros de esta lista de comandos:

#/bin/bash
apt-get update
# descargar firmware
wget https://www.wifipineapple.com/downloads/nano/2.0.2 -O upgrade-2.0.2.bin
#descargar e instalar Firmware Mod Kit
apt-get install git build-essential zlib1g-dev liblzma-dev python-magic
wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/firmware-mod-kit/fmk_099.tar.gz
tar -zxvf fmk_099.tar.gz
cd fmk
# Instalar Binwalk localmente y extraer el firmware
echo "BINWALK=binwalk" >> shared-ng.inc
./extract-firmware.sh ../upgrade-2.0.2.bin
cd ..
#descargar e instalar OpenWRT Chaos Calmer
apt-get install subversion build-essential git-core libncurses5-dev zlib1g-dev gawk flex quilt libssl-dev xsltproc libxml-parser-perl mercurial bzr ecj cvs unzip git
git clone https://github.com/domino-team/openwrt-cc.git
cp -r fmk/fmk/rootfs/* openwrt-cc/files/
rm -rf openwrt-cc/files/lib/modules/3.18.23/
rm -rf openwrt-cc/files/sbin/modprobe
cd openwrt-cc
git checkout 73d51063bca71574206f2ce162f6bc6046f8e3ab
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
make

Si tenéis problemas con el “make menuconfig” y os da el error de sync, para haceros la vida más fácil podéis usar mi archivo .config (incluido en el paquete .tar)

Tenemos que usar una máquina Linux de 64 bits para que la crosscompilación no falle a mitad de proceso en el target/Linux. Se puede fallar bastante en este paso si no utilizáis un Linux de 64 bits.

Si todo ha salido bien (después de unas horas crosscompilando) tendremos nuestro firmware en el directorio /bin dentro de la carpeta donde estemos trabajando. Habrá muchos ficheros pero los .bin que nos interesan son los que elegimos como target en el menuconfig, en nuestro caso GL.Inet-factory.bin y GL.Inet-squashfs.bin de los cuales solo usaremos el factory.

Ahora que estamos compilando el firmware de nuestra piña en la versión 2.0.2 (la más actualizada hasta la fecha) llega el momento de mejorarla. En la compilación de openwrt (make menuconfig) saldrán mensajes para instalar varios drivers de chipsets de tarjetas Wifi y tendrás que instalar el driver correspondiente a la tarjeta que quieras usar. De esta forma podrás hacer nuestra piña nano modificada compatible con más modelos y ser más versátiles. El motivo de usar la tarjeta de red TP-Link TL-WN722N v1 es que esta tarjeta posee el chipset AR9271 el cuál es nativo en la Wifi Pineapple original, pero añadiendo más drivers ampliaremos nuestras posibilidades (cuidado con el espacio que es limitado).

Para instalar el firmware que acabamos de compilar en nuestro GL-AR150 hay que seguir los pasos de este enlace: http://www.gl-inet.com/uboot-flashing/

Para familiarizarse con nuestro nuevo dispositivo, recomiendo echar un vistazo a este enlace: https://forums.hak5.org/topic/37196-wifi-pineapple-primer/

Si tenemos una versión anterior de la wifi pineapple instalada o por cualquier motivo el firmware actual no deja instalar el nuevo, habrá que flashear por bootloader, para ello:

En el router:
- Con el router sin encender, conecta un cable RJ-45 al puerto LAN o WAN del router directamente al PC
- Presiona el botón de reset mientras conectas el router a la corriente
- Deja que la luz roja parpadee 5 veces
- Deja de pulsar el botón de reset cuando la luz roja parpadee la 6ª vez (La luz verde central se encenderá en el sexto parpadeo)
- Después de soltar el botón, la luz roja parpadeará muy rápido por aproximadamente 1 segundo
- Si solo un led verde de uno de los laterales está encendido, el router estará en modo seguro bootloader
- Si los dos leds verdes están encendidos significa que te has pasado mucho tiempo presionando el botón reset y hay que empezar el proceso de nuevo.
En el PC:
- Configura tu tarjeta de red Ethernet para que use la IP 192.168.1.2 y máscara de red 255.255.255.0
- Abre un navegador y accede a 192.168.1.1
- Haz clic en “upload your firmware” y elige el archivo .bin que quieras flashear
- Haz clic en “apply”

Hecho esto, se “flasheará” el firmware nuevo en el router, y cuando termine el proceso podrás disfrutar de sus nuevas funciones.

Para acabar, después de haber leído todo el artículos, y a modo de resumen, os digo que todo el proceso anterior se puede hacer de una forma más fácil, GL.Inet pone a disposición de sus usuarios una versión limpia de OpenWRT aparte de sus versiones modificadas para diferentes propósitos. El proceso anterior nos sirve en el caso de que la Wifi Pineapple original se actualice, ya que no podemos usar el método original de actualización, si no que para instalar las actualizaciones nosotros tendremos que compilar un firmware con la nueva actualización y flashearlo por “uboot secure mode” (bootloader).

Es preferible usar el firmware que nos proporciona GL.Inet, ya que sabemos con certeza que funciona sin problemas, y a partir de él (ya instalado) podemos hacer modificaciones, como instalar los drivers que nos faltan y los archivos necesarios para hacer funcionar nuestra Wifi Pineapple. Recuerda que si instalas el firmware limpio, tienes que conectar el router a internet y descargar los módulos correspondientes a los drivers que quieras instalar ya que después de instalar la modificación de la Wifi Pineapple Nano no podrás modificar nada a no ser que instales de nuevo el firmware base.

En el siguiente paquete .tar tenéis a vuestra disposición el Firmware Limpio y el Binario Archivos Wifi Pineapple Nano 2.0.2.

Cuando terminemos de instalar los archivos de la Wifi Pineapple, tendremos que conectarnos a su wifi “WifiPineapple” abierta y conectarnos con un navegador a la IP http://172.16.42.1:1471/ para configurar por primera vez nuestro nuevo juguete.

Para empezar a usar los módulos en nuestra Wifi Pineapple Low Cost podemos guiarnos por la lista que hay en su página oficial, y pasarnos por el foro de Hak5 y su GitHub.

La entrada Laboratorio de Hacking (I): Wifi GL-AR150 Pineapple Nano 2.0.2 “Enhanced” aparece primero en Security Art Work.

Recientemente, la tecnología blockchain ha sido promovida como un elemento de cambio para muchas industrias. La tecnología de contabilidad distribuida que surgió de Bitcoin tiene aplicaciones prometedoras más allá de las monedas digitales.

Uno de los casos de uso más prometedores de la tecnología blockchain es la elaboración de contratos inteligentes.

Los contratos inteligentes son contratos autoejecutables, en los que los términos se especifican en el código. Básicamente, esto significa implementar contratos legales en código de ordenador, que los ejecuta automáticamente.

Si bien el concepto existe desde hace tiempo, al menos desde que Nick Szabo escribió el concepto en 1996, no fue hasta la llegada del blockchain de Ethereum con la capacitad de expresar cualquier computación (“Turing complete”), que el uso del contrato inteligente se hizo común.

Los contratos Ethereum existen en direcciones de contrato y pueden invocarse mediante llamadas de transacción.

Ejecutar contratos escritos en código y almacenados en un blockchain público inmutable crea ciertos riesgos y problemas, que discutiremos de forma general en esta publicación. En una próxima segunda parte, veremos ejemplos más específicos de vulnerabilidades de seguridad de contratos inteligentes.

Contrato inteligente

¿Código es ley?

Una interpretación literal de la idea del contrato inteligente lleva al paradigma “Código es Ley”, lo que significa que los contratos inteligentes son vinculantes y se interpretan como si fueran documentos legales. Cualquier ingeniero de software consciente de la imposibilidad de crear un código completamente libre de errores se echaría las manos a la cabeza ante la idea de que un programa informático sea legalmente vinculante. Hay una serie de problemas obvios:

El código contiene errores. Es extremadamente difícil escribir código libre de errores e incluso si se toman todas las precauciones posibles, siempre habrá rutas de ejecución inesperadas o posibles vulnerabilidades en un software razonablemente complejo.
Los contratos legales están sujetos a interpretación y arbitraje. Es muy difícil crear contratos herméticos. En cualquier contrato grande, los errores tipográficos pueden deslizarse y algunas cláusulas deben ser interpretadas y arbitradas. Eso es lo que hacen los tribunales en caso de disputa. Si en un contrato legal el precio de venta se especifica como $100 en 39 de 40 páginas y en una página se ingresa un cero adicional, un tribunal dictaminará “en el espíritu del contrato”. Un ordenador simplemente ejecuta la cláusula tal como está escrita. La inmutabilidad del blockchain se suma a este problema, ya que los contratos no se pueden modificar fácilmente.
3. Los ingenieros de software no son expertos legales y viceversa. . Se requiere un conjunto de habilidades diferente para redactar un buen contrato, no necesariamente compatible con la redacción de un buen programa informático.

Dos Ejemplos de Ataques a Contratos Inteligentes de Alto-perfil

El ataque DAO

Mucho se ha dicho sobre este caso, que no reiteraremos aquí. Una buena descripción del ataque y las consecuencias se puede encontrar aquí.

En resumen, en junio de 2016, un atacante logró desviar una gran cantidad de fondos de fuente colectiva (3.5M ETH, aproximadamente 15% del total de ETH en ese momento) en su propio contrato derivado (child DAO), en el cual los fondos se bloquearon durante 28 días, lo que llevó a una carrera a contra reloj para encontrar una solución.

El punto importante a tener en cuenta en este caso, es que el contrato fue atacado haciéndolo comportarse de una manera inesperada. En este caso particular, las vulnerabilidades de código reentrante se explotaron. Veremos este tipo de vulnerabilidad en detalle en una secuela a esta publicación.

El hackeo de parity

De hecho, este fue el segundo “ataque” al contrato de monedero multi-firma proporcionado por Parity. El contrato de monedero múltiple, utilizado por muchas start-ups, tenía la mayor parte de su lógica implementada en un contrato de biblioteca. Cada monedero consistía en un contrato de cliente ligero que se conectaba a este único punto de fallo.

Arquitectura de parity multisig

Hubo un error crucial en el contrato de biblioteca, que consistía en una función de inicialización que podía llamarse una vez.

En noviembre de 2017, alguien sí inicializó el contrato y al hacerlo se convirtió en el propietario del contrato. Esto le permitió invocar funciones de propietario, un privilegio que usó para llamar a la siguiente función:

// kills the contract sending everything to `_to`.
function kill(address _to) onlymanyowners(sha3(msg.data)) external {
    suicide(_to);
}

Esto es el equivalente de un botón de autodestrucción, que hace que el contrato sea inútil. Llamar a esta función provocó que todos los fondos de los contratos del cliente se congelaran, probablemente para siempre.

Al momento de escribir este artículo, aún no está claro si el incidente constituyó un ataque deliberado o si fue accidental, con el perpetrador afirmando acciones accidentales.

Ambos ataques muestran que incluso los contratos relativamente simples, escritos por los principales actores del ecosistema de blockchain, son propensos a errores básicos con graves consecuencias.

¿Qué se puede hacer?

La historia reciente ha demostrado que la ejecución de contratos inteligentes en blockchains públicos es peligrosa y en ningún lugar lo suficientemente segura como para sustituir los sistemas legales más tradicionales con su lenguaje preciso, espacio para la interpretación y el arbitraje.

Esto no significa que debamos abandonar los contratos inteligentes. Son herramientas extremadamente útiles y abren aplicaciones interesantes. Sin embargo, no deberíamos considerarlos sustitutos de contratos legalmente vinculantes, sino herramientas complementarias para la automatización.

Además, debemos tomar las siguientes precauciones para evitar vulnerabilidades:

Usar estándares de facto de código abierto y aceptados por la comunidad para los contratos de biblioteca, tales como los contratos de Open Zeppelin.
Utilizar los patrones recomendados y las pautas de mejores prácticas, como los que proporciona Consensys.
Considerar contratar una auditoría de sus contratos inteligentes por un proveedor acreditado.

En una próxima publicación de esta serie, veremos algunas vulnerabilidades conocidas, incluidos ejemplos de código, y cómo prevenirlas.

La entrada Seguridad de contratos inteligentes basados en Blockchain I aparece primero en Security Art Work.

Os propongo que imaginéis la siguiente situación ficticia:

Yo soy Pepito, un empleado descontento. Mi jefe me tiene explotado, no para de mandarme tareas, no me paga las horas extras y, además, no me agradece nunca el trabajo que hago… Un día, harto de la situación me dije: “este se va a enterar”. Y empiezo a planear: voy a “hackear” su ordenador y a robarle toda la información sensible que tenga. ¿Pero cómo? Después de darle alguna vuelta, ¡ya sé! Voy a ver si en los resultados de las auditorias de vulnerabilidades internas, a las cuales tengo acceso, su equipo tiene algún fallo de seguridad que pueda aprovechar.
¡Vaya! Lo tiene todo parcheado… y no tengo dinero para un 0 day. ¿Qué puedo hacer?

Un día mi jefe me pregunta si conozco algún programa gratuito para descomprimir archivos en sistemas operativos Windows y…

Por supuesto, le contesto que sí, y que se lo enviaré adjunto por correo. Y es cuando empiezo a preparar el “regalito”.

Como se que tenemos un buen antivirus y siempre está actualizado, utilizo la herramienta Shellter (https://www.shellterproject.com/) para cargar mi shellcode en el programa legítimo, que me ha pedido mi jefe, y ofuscarlo de tal forma que cuando lo ejecute, me abra una sesión en mi máquina hacia su ordenador.

Shellter, tal y como viene definido en su web, es una herramienta dinámica de inyección de shellcode. Que sea dinámico significa que Shellter ejecuta el fichero que deseo infectar y, una vez finalizada esta ejecución, me ofrece diferentes opciones para infectar el archivo, como y donde yo quiera.

Además, el shellcode a inyectar puede ser generado por mí mismo o a través de algún framework. En mi caso, echaré mano de Metasploit.

Abro Metasploit, genero mi payload y lo dejo escuchando:

Ahora me descargo 7-Zip (http://www.7-zip.org/), una aplicación que cumple con los requisitos pedidos por mi jefe, y ejecuto Shellter para introducir mi shellcode (remarcado en la imagen anterior).

Elijo el modo automático y le indico al programa la ruta del programa 7-Zip:

Activo el modo sigiloso, elijo el payload 7 de la lista y copio el código generado por Metasploit:

Y una vez se ha verificado la inyección, pulso Enter para finalizar con el proceso:

Antes de enviarle nada, compruebo que el antivirus corporativo no lo detecta como una amenaza. También, y a modo de interés personal, lo subo a Virustotal (https://www.virustotal.com/es/) para comprobar cuantos antivirus lo detectarían como malware:

Después de esto, ya con todo preparado, le contesto a mi jefe explicándole que puede utilizar el programa que le adjunto para descomprimir archivos sin tener que adquirir una licencia para su uso.

Ahora solo queda esperar… Si no os queréis perder lo que pasa después, atentos al blog.

La entrada Evadiendo AV con Shellter. También tengo Sysmon y Wazuh I aparece primero en Security Art Work.

Este pequeño aparato nos puede hacer la vida más fácil en nuestro laboratorio, ya sea con la configuración que viene de serie o instalándole nosotros OpenWRT para ganar funcionalidades.

ZSUN Wifi Card Reader

Memoria RAM: 64MB
Memoria Almacenamiento: 16MB Flash + MicroSD
SoC: Atheros AR7240 CPU (400Mhz) + Atheros AR9331 Chipset (Wifi Integrado)
Conectividad: 802.11 b/g/n Wi-Fi hasta 150Mbps
Alimentación: Puerto USB

El dispositivo tiene pines GPIO, y para acceder a algunos de ellos es necesario separar las dos placas, cosa que no es recomendable porque nos quedaríamos sin puerto microSD.

El dispositivo requiere de una tarjeta de memoria para su funcionamiento donde se guardarán los datos. Cuando lo enchufemos a un USB, el dispositivo creará una red Wifi sin contraseña a la que nosotros nos conectaremos y, bien con la aplicación (ZSun) o con un navegador normal conectándonos a la IP por defecto (10.168.168.1), accederemos al contenido de nuestra tarjeta microSD.

Vistas sus características, y lo que puede hacer de serie, vamos a ver qué cosas podemos hacer con él que nos sirvan para ampliar las capacidades de nuestro laboratorio.

Básicamente, tenemos dos opciones:

Opción 1: Usarlo como viene de serie

Para lo que vale y lo que ofrece de serie no está mal dejarlo como está. Como hemos mencionado anteriormente, será necesario una tarjeta microSD de buena capacidad y un conector USB para proporcionarle electricidad. Con eso ya podría funcionar. Eso sí, solo funcionará como servidor de archivos.

Opción 2: Instalarle OpenWRT

Otra opción es instalarle el firmware basado en Linux que ya usamos en el anterior artículo de esta serie. Se trata de OpenWRT. Con este firmware funcionando ampliaremos las capacidades del dispositivo.

Nota: Aunque es buena idea quedarse con la opción 1 y usarlo como el fabricante quiere, tengo que decir que el software por defecto del ZSun Wifi Card Reader viene cargado de fallos de seguridad, como por ejemplo cargar órdenes shell en los campos de texto y ejecutarlas, tener un acceso telnet en el puerto 11880, o que cada vez que se encienda levante un servidor SMB Windows Shared Folders. Así que recomiendo encarecidamente instalar OpenWRT. Precisamente esos fallos de seguridad se aprovechan para poder instalarle dicho firmware. Algunos de esos fallos se explican aquí.

Para instalar OpenWRT usad la guía que hay en este link que lo detalla bastante bien.

Después del flasheo del firmware, OpenWRT no montará la microSD automáticamente, pero puede leerla y montarla en el sistema de archivos (cosa que hay que hacer a mano). De todos modos, no funcionará como un pendrive cuando se conecta por USB a un ordenador.

Para usar la tarjeta en OpenWRT tendrás que usar un lector externo para copiar los archivos desde el ordenador a la tarjeta, y posteriormente introducir la tarjeta en el router para poder instalar lo que quieras. En la interfaz LuCI de OpenWRT, puedes ir a “Puntos de Montaje”, y seleccionar ahí la tarjeta, simplemente marcando la casilla de verificación y haciendo clic en “Guardar y Aplicar”.

Por defecto, la tarjeta se montará en el directorio /etc/sda1/, por SSH podremos conectarnos y usar las ordenes cd y ls -a para cambiar de directorio y listar los archivos respectivamente.

Con esta información ya podemos usar nuestra tarjeta microSD en el router. Más tarde podremos configurar nuestro servidor web para poder servir una página que esté almacenada en un directorio en la tarjeta.

Una vez que se le instala OpenWRT para gestionar quién controla el puerto de la microSD, basta con seguir los pasos de este artículo. Veremos si es el ZSun para usarlo como almacenamiento, o el puerto USB para que un ordenador lo use como un pendrive.

Si por cualquier motivo el dispositivo se brickea, (es decir, se queda inutilizado por una mala instalación) para entrar en el modo uboot tienes que soldar en el dispositivo un conector RJ-45. Así que aparte de lo poco estético que quedaría un RJ-45 saliendo de nuestro lector, sería bastante raro verlo y “difícil” de esconder, ya que casi sería más grande que él. Así que recomiendo que cuando se instale OpenWRT se haga con cuidado.

Una vez que le instalemos OpenWRT, las posibilidades son poco menos que infinitas. Por poner unos ejemplos, podemos usarlo como punto de acceso/cliente/repetidor Wifi, como un punto de acceso OpenVPN, como Nodo Tor, un PirateBox o para lo que estaba destinado (o casi); hacer de servidor de archivos al que puede que queramos añadirle algunos extras ejecutándose en segundo plano.

Una vez que tenemos nuestro ZSun con OpenWRT instalado, lo tenemos listo para seguir maquetando nuestra herramienta.

La ingeniería social también es una parte de la seguridad informática que intentaremos explotar un poco con este dispositivo. Para ello crearemos un portal cautivo que pedirá credenciales a los clientes y los conectará a una red Wifi legítima con acceso a Internet, impidiendo así sospecha alguna de los usuarios.

Para comenzar a hacer nuestro portal cautivo necesitaremos configurar SFTP y acceder al sistema de ficheros de OpenWRT. Podemos usar la orden opkg en modo offline e instalar nuestros paquetes desde la tarjeta microSD (recordad que nuestra tarjeta se monta en /mnt/sda1/).

Primero descargaremos los paquetes necesarios desde descargas OpenWRT

Guárdalos en una carpeta en la tarjeta SD ej: paquetes_opkg, vía lector de tarjetas desde tu ordenador.

Inserta la tarjeta en el ZSun, arráncalo y conéctate. Cambia a la carpeta donde están nuestros paquetes.

cd /mnt/sda1/paquetes_opkg

Instala los nuevos paquetes con la orden opkg install *

Veras algo como esto:

root@OpenWrt:/mnt/sda1/packages# opkg install *
Installing libopenssl (1.0.2g-1) to root...
Installing zlib (1.2.8-1) to root...
Installing openssh-sftp-server (7.1p2-1) to root...
Package zlib (1.2.8-1) installed in root is up to date.
Configuring openssh-sftp-server.
Configuring zlib.
Configuring libopenssl.
root@OpenWrt:/mnt/sda1/packages#

Ahora puedes usar, por ejemplo, Filezilla en nuestro ordenador para conectarte vía SFTP a nuestro OpenWRT en la IP 192.168.1.1 con nuestro nombre de usuario y contraseña. Hecho esto deberíamos ver las lista de carpetas para /root y poder explorar todo el sistema de OpenWRT, incluida nuestra tarjeta de memoria montada en /mnt/sda1/.

Una de las características de nuestro ZSun es que puede conectar de forma estable varios nodos y podemos explotar esta característica haciéndolo un repetidor puente de una red Wifi existente.

Para ello ya disponemos de una configuración wireless base que requiere de una Wifi existente, le da a OpenWRT acceso a Internet y también le proporciona a cualquiera conectado a OpenWRT acceso a Internet, cortesía de Piratebox.

Ya tenemos SFTP para editar los archivos, y tendremos que acceder al directorio /etc/config, y editar tres ficheros; firewall, wireless y network:

/etc/config/firewall

Reemplaza solo la entrada para la configuración de la zona WAN tal que:

config zone
option name wan
option network 'wan wan6 wwan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1

/etc/config/wireless

Vamos a levantar dos interfaces Wifi: -wwan, que conecta a tu red local Wifi (de donde obtienes Internet); y -lan, que proporciona Internet a la red OpenWRT. Para ello será necesario reemplazar el fichero /etc/config/wireless por este otro, realizando los cambios necesarios que se comentan a continuación:

La entrada “config wifi-iface” con “option network ‘wwan’” es donde configuramos la red Wifi que queremos conectar. Asegúrate de que reemplace “<TuPropiaWifi>” con su propio SSID de red WiFi.

Si tu red está protegida: descomenta las líneas “#option encryption” y “#option key” para esta entrada y reemplaza “<TuPropiaContraseña>” con la de tu red, y comenta la opción “option encryption ‘none‘”.

Hay que tener en cuenta que si OpenWRT no se puede conectar a la red Wifi que estamos configurando, no iniciará correctamente la segunda interfaz Wifi lo que significará que no podremos conectarnos a OpenWRT y tendremos que restablecer la configuración de fábrica.

Fichero /etc/config/wireless

config wifi-device 'radio0'
 option type 'mac80211'
 option channel 'auto'
 option hwmode '11g'
 option path 'platform/ar933x_wmac'
 option htmode 'HT20'
 option disabled '0'
 option txpower '30'
 option country 'US'

config wifi-iface
 option ssid ''
 option device 'radio0'
 option mode 'sta'
 option network 'wwan'
 option encryption 'none'
 #option encryption 'psk2'
 #option key '<TuPropiaContraseña>'

config wifi-iface
 option ssid 'OpenWrt'
 option device 'radio0'
 option mode 'ap'
 option network 'lan'
 option encryption 'none'
 #option encryption 'psk2'
 #option key 'TuSuperContraseñaSegura'

/etc/config/network

Permite que la interfaz wwan obtenga IP vía DHCP agregando un par de líneas al final del fichero /etc/config/network

config interface 'wwan'
option proto 'dhcp'

Después de hacer nuestras configuraciones, guarda todos los archivos, súbelos a /etc/config y reinicia el dispositivo ya sea quitándole la corriente o seleccionando “reinicio” en la interfaz LuCI.

Re-conéctate a OpenWRT y deberías tener acceso a Internet en el dispositivo.

Si por cualquier motivo la red OpenWRT no vuelve a aparecer, tendremos que hacer un restablecimiento de fábrica y verificar nuestra configuración de autenticación y SSID de Wifi en /etc/config/wireless.

¿Tienes conexión pero sin acceso a Internet?

Probablemente se deba a un conflicto de direcciones IP entre ZSun y la red Wifi a la que te estás conectando. Por lo general, al conectarse a un punto de acceso de iPhone o Android, esto no suele ser un problema pero la mayoría de los routers domésticos también se ejecutan con IP 192.168.1.1, como OpenWRT, y este conflicto impide que la conexión a Internet se puentee correctamente.

Deberás asegurarte de que tu router Wifi de origen no tenga la misma IP estática configurada que la interfaz LAN de OpenWRT; de lo contrario, el DNS fallará y no tendrás acceso a Internet.

Para hacer esto, configura OpenWRT para usar una IP alternativa para la interfaz lan cambiando la siguiente línea en su archivo /etc/config/network, bajo “config interface ‘lan’”:

option ipaddr '192.168.10.1'

Pon la dirección IP desde la que quieres que opere OpenWRT, p.e. 192.168.10.1 y guardarlo y súbelo al ZSun.
Ahora tendrás que acceder a OpenWRT por la nueva IP, que incluye SSH, SFTP y la interfaz LuCi.
Teniendo todo funcionando hasta aquí solo nos falta instalar un servidor PHP y configurar nuestro portal cautivo seguro para redireccionar a nuestros clientes.

(N.d.E.: En los próximos días seguiremos con la segunda parte de este artículo sobre Portal cautivo Zsun Wifi Card Reader. Mientras os damos tiempo para revisar todo lo que nos ha contado Iván hasta aquí).

La entrada Laboratorio de Hacking (II): Portal cautivo Zsun Wifi Card Reader (1ª parte) aparece primero en Security Art Work.

Después de lo visto en el primer post de esta historia, en este os seguimos contando lo que ocurre y vamos a conocer al jefe. Volveros a poner en esa situación que nos contaba Pepito en la primera parte.

“Hola, me presento. Soy Pepote, el jefe de Pepito. Soy consciente de que tengo muchos enemigos entre los que seguro está la competencia o incluso mis propios empleados. Físicamente nadie me puede tocar, siempre voy con mis guardaespaldas. Pero tecnológicamente, cualquiera podría intentar atacar mi equipo con el objetivo de robar información muy valiosa.

Es por esto que, además del antivirus corporativo, decidí añadir una capa más de seguridad en mi equipo con Sysmon y Wazuh.

Sysmon, es una herramienta de monitorización personalizable para sistemas Windows con capacidad para registrar eventos de la actividad del sistema.

Para instalar Sysmon, una vez descargado, abrí una consola con permisos de administrador y ejecuté el siguiente comando:

C:\Users\Pepote\Downloads\Sysmon> Sysmon64.exe –i sysmonconfig.xml –accepteula

Es muy recomendable instalar Sysmon con un archivo de configuración que solamente registre eventos de la actividad que me interese, ya que si no me puede llenar el disco de registros de actividad legítima de mi sistema.

Por otro lado, instalé en un servidor el servicio de Wazuh, un fork del HIDS Ossec, el cual es un sistema de detección de intrusos basado en host de código abierto y libre. Y, a este servidor, añadí mi máquina:

Y extraigo la clave del agente de mi equipo, ya que me hará falta para configurar el agente de Wazuh en mi sistema:

Con esta clave, me voy a mi equipo, me descargo el agente de Wazuh, lo instalo y añado la IP de mi servidor Wazuh y la clave del agente de mi equipo, generada anteriormente:

Le doy a “Save”, y antes de ejecutar el agente, voy a la pestaña de “View” y pulso en “View Config”. Este es el archivo de configuración de Wazuh de mi equipo, donde añado las siguientes líneas para que el agente también envíe los eventos generados por Sysmon al servidor:

<localfile>
<location>Microsoft-Windows-Sysmon/Operational</location>
<log_format>eventchannel</log_format>
</localfile>

Guardo el archivo, y ahora sí que ejecuto el agente desde la pestaña de “Manage” y pulsando en “Start”.

Para comprobar que el agente se ha instalado correctamente, puedo mirar en los logs del propio agente, en la pestaña “View > View Logs”, o en el servidor ejecutando el siguiente comando:

En este punto, mi equipo ya está enviando eventos al servidor y generando alertas según las reglas cargadas. Yo por mi parte, he creado algunas reglas adicionales para detectar actividad sospechosa en los eventos generados por Sysmon:

<rule id="184778" level="12">
<if_group>sysmon_event1</if_group>
<field name="sysmon.image">powershell.exe</field>
<field name="sysmon.commandline">-nop -w hidden</field>
<description>Sysmon - Ejecucion de Powershell sospechosa 1</description>
</rule>
<rule id="184779" level="12">
<if_group>sysmon_event3</if_group>
<field name="sysmon.image">powershell.exe</field>
<description>Sysmon - Conexion de red detectada desde Powershell</description>
</rule>

Se me olvidaba, Wazuh también nos permite visualizar las alertas generadas en una interfaz gráfica utilizando la pila ELK (Elasticsearch, Logstash y Kibana).

Así que, antes de finalizar mi jornada laboral, siempre entro en la interfaz web para ver las alertas generadas en mi equipo y actuar de manera rápida en caso de detectar una posible intrusión:

No veo ninguna alerta alta, de level 12 o superior (remarcado con un recuadro verde en la imagen anterior), así que me puedo ir tranquilo a casa.

Por cierto, se me ha agotado la licencia de WinRAR así que voy a pedirle a Pepito que me busque un software similar pero gratuito.”

(N.d.E.: En los próximos días publicaremos la tercera y última parte de esta interesante historia).

La entrada Evadiendo AV con Shellter. También tengo Sysmon y Wazuh II aparece primero en Security Art Work.

Vamos con la segunda parte del artículo sobre el portal cautivo Zsun Wifi Card Reader (ver 1ªparte).

Necesitamos que nuestra aplicación PHP sea la fachada de nuestra red Wifi pero también necesitamos acceder a OpenWRT para administrarlo debidamente. Esto podemos hacerlo si ejecutamos LuCI (la interfaz web de OpenWRT) en un puerto alternativo. Instalaremos Lighttpd y PHP para alojar nuestro portal, y moveremos uHTTP y LuCI en el puerto 8080. Hay que comentar que Lighttpd es capaz de manejar certificados SSL y reescrituras de URL para que podamos configurar nuestro portal cautivo.

Instalación de PHP

De acuerdo con https://wiki.openwrt.org/doc/uci/uhttpd y aprovechando que tenenos conexión a Internet en nuestro OpenWRT, tenemos que:

Conectarnos por SSH a OpenWRT y hacer log como root
Instalar los paquetes con “opkg install php5” y “opkg install php5-cgi”

Puedes hacer un chequeo “Hello World” con uhttpd para asegurarte de que PHP funciona correctamente de la siguiente manera:

En el archivo de configuración uHTTPd, agrega o elimina el comentario:
```
list interpreter ".php = /usr/bin/php-cgi"
```
Configura un archivo PHP básico de hello world en /www/yourphp/
Ve a http://192.168.1.1/yourphp/file.php

Recuerda que si has cambiado la IP de OpenWRT tendrás que cambiar 192.168.1.1 por la que tú hayas puesto.

Ahora aislaremos la interfaz LuCI de Lighttpd y pondremos en funcionamiento un sitio web desde la tarjeta microSD.

Para cambiar uhttpd al puerto 8080, en /etc/config/uhttpd en “config uhttpd ‘main’”, actualice la siguiente línea:

list listen_http '0.0.0.0:8080'

Reiniciaremos y ahora LuCI estará alojado en 192.168.x.x: 8080

Ejecutar: opkg update
Ejecutar: opkg install lighttpd

Si obtienes “cat: can’t open ‘/etc/lighttpd/conf.d/*.conf’: No such file or directory” no te preocupes, solo está intentando cargar configuraciones para plugins de lighttpd pero no existen todavía.

Ahora configuraremos lighttpd para ejecutarse desde el puerto 80 desde la tarjeta microSD:

Ejecuta: “opkg install lighttpd-mod-cgi”
Ejecuta: “mkdir /mnt/sda1/www” para crear un directorio www en la tarjeta
Pega el Hello World que creamos anteriormente “index.html” en /mnt/sda1/www para comprobar que lighttpd se está ejecutando.
Ejecuta: “mkdir /mnt/sda1/logs” para crear un directorio donde iremos guardando los logs en la tarjeta
Ejecuta: “mkdir /mnt/sda1/logs/lighttpd”

Toca configurar lighttpd para escuchar en el puerto 80 con raíz en el directorio /mnt/sda1/www. Haz esto editando /etc/lighttpd/lighttpd.conf con:

server.document-root = "/mnt/sda1/www"

Levanta Lighttpd en el arranque con “/etc/init.d/lighttpd enable”, reinicia el Zsun, conéctate a 192.168.1.1 o la IP que hubieras configurado y deberías tener un ‘Hello World’.

Configuraremos ahora PHP para ejecutarse desde Lighttpd.

En /etc/lighttpd/lighttpd.conf habilitaremos una directiva para archivos con la extensión .php

cgi.assign = ( ".php" => "/usr/bin/php-cgi" )

Agrega index.php a los nombres de archivo predeterminados, si aún no está configurado:

index-file.names = ( "index.html", "default.html", "index.htm", "default.htm", "index.php" )

Reinicia lighttpd con:

/etc/init.d/lighttpd restart

Si obtenemos este error: “Error: ‘Duplicate config variable’” significa que hay otra variable cgi-assign en otro fichero de configuración. Mira en /etc/lighttpd/conf.d/ a ver si algún archivo de configuración ya contiene esa variable. Para arreglar esto simplemente puedes agregar “”.php” => “/usr/bin/php-cgi””, no olvides quitar la variable conflictiva de nuestro archivo de lighttpd.conf

Finalmente, para que PHP funcione desde la tarjeta MicroSD, hay que comentar:

'doc_root' en /etc/php.ini, así:; doc_root = "/ www"

De lo contrario, php solo intentará ejecutar scripts en la carpeta /www

Configurar un portal cautivo HTTPS seguro

El objetivo es tener un portal cautivo seguro, y para que sea seguro necesitamos configurar un certificado SSL para un nombre de dominio en el que todos sean redirigidos.

Esto suena extraño, pero puede ser útil por una serie de razones. Deshace la advertencia de seguridad SSL de la mayoría de los navegadores. Si ZSun está desconectado y no hay acceso a Internet, nuestro portal nos permite “suplantar” un sitio web real, o mostrar una versión diferente del mismo.

Otra cosa útil es que permite a los usuarios marcar páginas en el portal que pueden corresponder a páginas reales una vez que obtienen acceso a Internet. También permite que nuestro portal funcione bajo HTTPS, lo que permite que WebRTC (webcams) funcione en ciertos navegadores, como Chrome.

Para ello necesitamos instalar el certificado SSL en lighttpd y configurar HTTPS

Partiendo de https://wiki.openwrt.org/doc/howto/owncloud#get_ssl_optional, cargaremos el certificado en el Router y daremos los siguientes permisos

	chmod 0600 /etc/lighttpd/ssl/midominio
	chmod 0600 /etc/lighttpd/ssl/midominio/certificate.pem

Los añadimos a etc/lighttpd/lighttpd.conf

Habilita SSL en el puerto 443 para HTTPS

Tienes que cargar el certificado y los certificados de la autoridad de certificación en una carpeta en el ZSun. Para una fácil administración recomiendo crear la carpeta y subirlos a /etc/lighttpd/ssl/[midominio]/, reemplaza [midominio] con el nombre de dominio para el que está firmado el certificado SSL.

Ahora añadiremos a nuestro /etc/lighttpd/lighttpd.conf:

Reemplaza [micertificado].pem con el nombre del archivo de certificado (pem) que contiene tanto la clave pública como la privada. Si tiene un montón de archivos .pem, es más probable que sea el que tiene dos entradas. Si tiene archivos de clave privados y públicos separados, puede cortar y pegar los dos juntos en un archivo.

Si tienes que incluir la cadena completa en la Autoridad de certificación (CA), simplemente elimine el comentario de la segunda línea del archivo ssl.ca y reemplace [micertificadoCA] con el nombre del certificado de tu Autoridad de certificación.

Ejecuta la siguiente línea para reiniciar Lighttpd

/etc/init.d/lighttpd restart

Puede que aparezca el error: “can’t resolve symbol ‘EC_KEY_new_by_curve_name‘”. Este error pasa por una función faltante, probablemente causada por tener una versión desactualizada de libopenssl.

Ejecutando lo siguiente debería desaparecer el error.

opkg update libopenssl

Reenrutado de solicitudes DNS a la IP de nuestro servidor Web

Para permitir esto, tenemos que configurar dnsmasq añadiendo unas entradas al archivo de configuracion /etc/dnsmasq.conf:

	address=/#/[DireccionIPDeTuOpenWRT]
	local-ttl=0

Reemplaza [DireccionIPDeTuOpenWRT] por la dirección del OpenWRT (normalmente 192.168.1.1 a no ser que se la hayas cambiado)

Nota: La línea “local-ttl=0” garantiza que el tiempo de vida de la reescritura de DNS sea cero, lo que garantiza que no se retenga ninguno de los registros redirigidos. Esto evitará el envenenamiento DNS, que es bastante molesto.

Para reiniciar lighttpd y que los cambios surjan efecto debe ejecutar:

/etc/init.d/lighttpd restart

En este paso toca redirigir todas las solicitudes HTTP a HTTPS, para ello tendremos que instalar mod-redirect con “opkg install lighttpd-mod-redirect” y añadir a /etc/lighttpd/lighttpd.conf esto:

Reiniciaremos lighttpd para que los cambios sean efectivos con:

/etc/init.d/lighttpd restart

Ahora vamos a redirigir dominios externos al nuestro
Añade a /etc/lighttpd/lighttpd.conf:

Asegurate de reemplazar “midominio” y de configurar las expresiones regulares.

Reinicia lighttpd:

/etc/init.d/lighttpd restart

Ahora añadiremos un controlador 404 que redireccione al sitio web principal de nuestro portal modificando /etc/lighttpd/lighthttp.conf añadiendo o modificando:

	server.error-handler-404 = "/"

Esto asegurará que si recibimos una petición que devuelva un error 404 al cliente, lo redirijamos a nuestro portal.

Reiniciaremos lighttpd para guardar los cambios:

/etc/init.d/lighttpd restart

¡Ya podemos probar (habilitar y deshabilitar) nuestro portal cautivo!

La redirección con dnsmasq solo funcionará cuando el Router no tenga conexión WWAN. Esto se debe a que las solicitudes se enrutan a través de WWAN a un DNS externo. Puedes configurar un bypass usando iptables, pero en realidad lo más fácil es deshabilitar la interfaz inalámbrica ‘wwan’.

Así que, básicamente, puedes activar el portal cautivo deshabilitando la interfaz inalámbrica de “wwan” en /etc/config/wireless comentando todo el bloque “config wifi-iface” que contiene “option network wwan”. Puedes desactivarlo comentándolo #.

Reinicia lighthttpd para que los cambios surtan efecto:

/etc/init.d/lighttpd restart

Para que todo funcione sin problemas añadiremos unas reglas personalizadas a Lighttpd. Para hacer esto ejecutaremos:

opkg install “lighttpd-mod-rewrite

Podrás encontrar algunos ejemplos de reglas aquí.

Reinicia lighttpd

/etc/init.d/lighttpd restart

Para terminar de dejarlo bonito podemos intentar mejorar un poco la ejecución de PHP con archivos pesados como imágenes, en /etc/php.ini modificaremos:

	default_socket_timeout = 180 upload_max_filesize = 20M max_execution_time = 180 	post_max_size = 0 (disabled) max_input_time = -1 (Default disabled) memory_limit = 	32M

La última línea permite que PHP use más memoria en el Zsun.

Este es solo un ejemplo de cómo hacer funcionar una aplicación de portal cautivo utilizando PHP, aunque puedes configurar cualquier plataforma que desees o duplicar algún sitio web existente en Internet o incluso duplicar un portal de administración de un Router, las posibilidades son infinitas.

La entrada Laboratorio de Hacking (II): Portal cautivo Zsun Wifi Card Reader (2ª parte) aparece primero en Security Art Work.

Después de los dos primeros post de la historia [1] [2] donde os contábamos las intenciones de Pepito y la seguridad que tiene Pepote, en este post os vamos a contar el desenlace. Poneros en situación de los dos personajes de la historia.

Pepito:

“Aquí sigo, esperando a que mi jefe ejecute el “programa” que me ha pedido y que le he preparado con especial cariño.

Después de una larga espera, al menos para mí, mi jefe ejecuta la aplicación y consigo en Metasploit, una sesión hacia su ordenador.

¡Bien! Ya estoy dentro.

Voy a ver que tiene por aquí…”

Por otro lado, veamos que hace el jefe.

Pepote:

“La verdad es que va muy bien el programa que me pasó Pepito. Ahora que lo pienso, es muy buen trabajador y nunca se lo agradezco. Voy a apagar el ordenador, que por hoy ya está bien, y le voy agradecer a Pepito todo lo que ha hecho por la empresa, y que la empresa se lo va a recompensar con una buena subida de sueldo. Pero bueno, como siempre hago antes de apagar, voy a hacer típica revisión de alertas de Wazuh.

¡¿PERO QUÉ ES ESTO?! ¿Cuatro alertas de nivel 12? A ver, a ver qué ha pasado aquí…

A partir de la ejecución del programa que me ha pasado Pepito, se ha ejecutado dicho comando de Powershell. Y posteriormente se ha abierto una conexión desde mi sistema (192.168.37.138) hacia la dirección IP 192.168.37.148, por el puerto 4444.

Miro en la CMDB (Configuration Management Database) y compruebo que dicha dirección IP, corresponde con la del equipo de Pepito, algo que ya me estaba oliendo.

Aún no quiero sacar conclusiones precipitadas, es posible que hayan subido un ejecutable malicioso a la página web de 7-Zip. Accedo a ella, me descargo la misma versión que me había pasado Pepito y calculo el MD5 de ambos ejecutables. Compruebo que, efectivamente, no es la misma.

Cada vez tengo más claro lo que está pasando aquí, pero antes de nada, voy a subir el ejecutable a Virustotal para comprobar si ya estaba subido y desde cuándo. ¡Bingo! Parece ser que alguien lo subió por primera vez justo antes de haberlo enviado Pepito a mí.

Accedo a los registros del proxy y veo que Pepito realizó dicha petición…”

La entrada Evadiendo AV con Shellter. También tengo Sysmon y Wazuh III. GAME OVER aparece primero en Security Art Work.

Hace unos días encontramos un malware Linux con elementos bastante conocidos hasta la fecha, sobretodo importados de Gafgyt. Sin embargo, ciertas modificaciones hicieron que le dedicáramos el tiempo de analizarlo.

En un primer momento, el malware lleva a cabo funciones de reconocimiento del entorno, obteniendo la IP pública del sistema o el Endianness, donde por defecto tomará little endian (recordemos que arquitecturas como ARM, PowerPC o MIPS pueden trabajar con ambos órdenes.)

A continuación, borra los registros de cara a dificultar un posible análisis forense:

Ejecutando el malware, observamos por pantalla la siguiente información del sistema:

Esta misma información es remitida al servidor a través de una conexión TCP, por lo que el motivo de que aparezca por pantalla puede estar provocado por un modo de debug no deshabilitado.
También podemos observar la dirección IP y el puerto del servidor C&C al que la víctima intenta comunicarse.

Una vez finalizada la fase de infección del equipo, ejecuta la función ProcessCMD, la cual lleva a cabo el escaneo de objetivos. Para ello utiliza cuatro funciones: MiraiScanner, PhoneScanner, MiraiHackaShit y BCMscanner.

En caso de detectar un posible acceso a un dispositivo, se conecta al mismo y ejecuta el siguiente script:

En cuanto a las opciones de denegación de servicio, encontramos en este malware 4 funciones relacionadas: SendHTTP SendUDP SendTCP y SendSTD.

A continuación se muestra la comunicación con el servidor C2, tanto reportando la información del sistema como las opciones que recibe para el ataque a través de la denegación de servicio.

Tal y como podemos observar, importa casi todo su código del malware Gafgyt y además, las pequeñas diferencias con la variante base ya han sido utilizadas con anterioridad.
Sin embargo, lo verdaderamente interesante del análisis nos lo encontramos a continuación.

Cuando realizamos un acceso a través de HTTP a la dirección IP donde contacta el malware, detectamos el siguiente portal:

Al parecer la Deep Web es demasiado mainstream y no quieren limitar el alcance su todavía precario imperio del cibercrimen, permitiendo el acceso no restringido desde cualquier punto de Internet.

Encontramos 3 accesos disponibles en el portal. Accediendo al Github relacionado, nos damos cuenta que todavía están en una etapa muy temprana en cuanto a su madurez como delincuentes, pues el usuario illsecurity se unió el 16 de febrero de 2018 (en el momento en el que se está escribiendo este post, únicamente han pasado 5 días).

Si accedemos a la pestaña “Files”, esta es la visualización obtenida:

Y el fichero test.text tiene el siguiente contenido:

Finalmente, accediendo a la pestaña “Shop”, vemos cómo se ofrece por el módico precio de $15, una botnet, ¡mejor que Mirai y Satori!

Así pues, el presente análisis no hace más que confirmar que la ciberdelincuencia juvenil va en aumento, sin que necesariamente la sofisticación vaya unida a ella. Al menos son precios económicos.

La entrada Análisis de Samouri: una botnet de noobs, para noobs aparece primero en Security Art Work.

En la parte anterior de esta serie sobre la seguridad de blockchain vimos los riesgos asociados con la implementación autónoma y la ejecución de contratos inteligentes en un blockchain público. También presentamos algunos ejemplos de alto perfil de ataques a contratos inteligentes que han causado la pérdida de grandes sumas de dinero y han cambiado la forma en que vemos las interacciones comerciales en la cadena de bloques.

En este episodio, repasaremos algunos problemas conocidos y vulnerabilidades.

Fuga de clave privada

El uso de claves privadas no seguras es realmente un error del usuario, en lugar de una vulnerabilidad. Sin embargo, lo mencionamos, como sucede sorprendentemente a menudo, y ciertos actores se han especializado en robar fondos de direcciones inseguras.

Lo que generalmente ocurre es que las direcciones de desarrollo (como las utilizadas por las herramientas de prueba, como Ganache/TestPRC) se utilizan en producción. Estas son direcciones generadas a partir de claves privadas conocidas públicamente. Algunos usuarios incluso han importado estas claves sin saberlo en el software de cartera virtual, al usar las palabras de semilla originales usadas en la generación de la clave privada.

Los atacantes están monitorizando estas direcciones y cualquier cantidad transferida a dicha dirección en la red principal de Ethereum tiende a desaparecer inmediatamente (dentro de 2 bloques).

Esta muy lucrativa actividad de “barrido” ha sido investigada en este interesante estudio, que encontró que una cuenta barredora había logrado acumular fondos por valor de $ 23 millones.

Código reentrante y condiciones de carrera

Las vulnerabilidades de reentrada consisten en un comportamiento inesperado, si se llama a una función varias veces antes de que se complete la ejecución.

Veamos la siguiente función, que se puede utilizar para retirar el saldo total del llamador de un contrato:

La invocación de call.value() hace que se ejecute código externo del contrato. Se puede suponer que el llamador es un software de cartera virtual de criptomoneda, pero también puede ser otro contrato.

Si el llamador es otro contrato, esto significa que se ejecuta la función fallback del contrato. El propósito de una función fallback es recibir fondos.

Un contrato deshonesto puede implementar una función fallback que llama a payOut() de nuevo recursivamente, antes de que el saldo se establezca a 0, obteniendo así más fondos de los disponibles.

La solución a esto es usar las funciones alternativas send() o transfer(). Esto evita las llamadas recursivas, al reenviar solamente el gas suficiente para una contabilidad básica y cualquier intento de llamar a payOut() nuevamente fallaría. Alternativamente (o adicionalmente), el orden de operación puede invertirse, es decir, establecer el saldo a 0 antes de realizar la transferencia de dinero.

El ataque DAO mencionado en la parte I usó una variación de esta vulnerabilidad.

Under-/Overflow

Los saldos suelen estar representados por números enteros sin signo, normalmente números de 256 bits. Cuando los enteros sin signo sufren un underflow or overflow, su valor cambia drásticamente. Veamos el siguiente ejemplo de un underflow más común (números acortados para la legibilidad):

0x0003
– 0x0004
———–
0xFFFF

Es fácil ver el problema aquí. Restando 1 más que el saldo disponible causa un underflow. El saldo resultante ahora es un gran número.

También tengamos en cuenta que la división aritmética de enteros es problemático, debido a errores de redondeo.

La solución es verificar siempre si hay underflow or overflow en el código. Hay bibliotecas seguras para ayudar con esto, como SafeMath by OpenZeppelin.

Suposiciones de orden de transacción

Las transacciones ingresan a un conjunto de transacciones no confirmadas y pueden ser incluidas en bloques por mineros en cualquier orden, dependiendo de los criterios de selección de transacciones del minero, que probablemente sea algún algoritmo destinado a obtener las máximas ganancias de las tarifas de transacción, pero podría ser cualquier cosa.

Así que, el orden de las transacciones que se incluyen puede ser completamente diferente del orden en que se generan. Por lo tanto, el código de un contrato no puede hacer suposiciones sobre el orden de transacción.

Además de los resultados inesperados en la ejecución del contrato, existe un posible vector de ataque, ya que las transacciones son visibles y su ejecución puede predecirse. Esto tal vez sea un problema en el trading, donde retrasar una transacción puede ser utilizada para ventaja personal por un minero deshonesto. De hecho, el simple hecho de estar al tanto de ciertas transacciones antes de que se ejecuten puede ser una ventaja para cualquier persona, no solo para los mineros. Las transacciones pueden “ser adelantadas” al pagar un precio de gas más alto, lo que incentiva a los mineros a incluirlas rápidamente.

Dependencias de Timestamp

En el blockchains, los timestamp son generados por los mineros. Por lo tanto, ningún contrato debe basarse en el timestamp del bloque para operaciones críticas, como usarlo como semilla para la generación de números aleatorios. Consensys da una regla de 12 minutos en sus directrices, que establece que es seguro usar block.timestamp, si vuestro código dependiente del tiempo puede manejar una variación de tiempo de 12 minutos.

Conclusión

Hasta ahora, hemos visto varios casos de alto perfil de ataques a contratos inteligentes basados en blockchain. También discutimos algunas vulnerabilidades comunes que fueron explotadas en el pasado. En una próxima publicación, cubriremos algunos ataques más complejos que dependen de la forma en que funcionan el blockchain y las operaciones específicas.

La entrada Seguridad de contratos inteligentes basados en Blockchain II – Vulnerabilidades y riesgos aparece primero en Security Art Work.

Hace unos días apareció en nuestros sistemas de detección un documento RTF a través de una regla bastante genérica que tenemos “para ver qué pilla”. Se trata de una regla que muchas veces nos genera falsos positivos, pero la cantidad es perfectamente asumible por los buenos resultados que nos da cuando acierta.

Llama la atención que siendo del típico correo tipo “Purchase Order”, hubiera pasado por varios filtros sin haber levantado sospechas. Tratándose de una amenaza genérica, no dirigida contra nadie en concreto, parece raro que estén utilizando alguna técnica o exploit novedoso.

En un primer vistazo rápido en estático no parece haber nada raro. El archivo tiene la típica ofuscación con caracteres de “espacio en blanco” en su interior, que, aunque simple, es efectiva para ocultarse ante la búsqueda de firmas. Dentro contiene un objeto identificado como ‘tFsqXa3iGNVxvyKH5LKGet0hQKeCl‘. Nada concluyente. La socorrida herramienta ‘strings’ tampoco es de mucha ayuda. Lo único que se puede identificar rebuscando algo más es una shell dentro de este último objeto tras extraerlo.

A todo esto, el documento ya era del dominio público, pero en el momento del análisis ningún AV me daba pistas sobre qué vulnerabilidad/funcionalidad de la que podría estar aprovechándose.

Del objeto contenido en su interior tampoco he podido obtener mucha más información en VT.

Paso entonces a comprobar si un análisis dinámico puede darme alguna pista para orientarme, porque no sé de dónde me vienen los tiros. Abro el documento y ciertamente veo que se genera una petición de red sospechosa… y en Process Monitor ha aparecido algo que me es familiar:

“EQNEDT32.EXE”, el ejecutable encargado de procesar las ecuaciones en los documentos de texto. ¿Se trataría de alguna de las vulnerabilidades que abusan de este viejo ejecutable tanto tiempo olvidado por Microsoft? Resulta raro que teniendo diferentes reglas para detectarlo no haya saltado ninguna. Reviso las reglas de los CVE-2017-11882 y CVE-2018-0802 para comprobar si alguno de los IOC que hay en ellas aparece aunque sea suelto. NADA.

Office tiene que saber de alguna manera que el objeto dentro del RTF tiene que abrirlo con “EQNEDT32.EXE”. Pero no encontraba de ninguna manera la típica cadena “Equations” que aparece en casi todos los documentos maliciosos de este tipo. Habrá que entrar un poco más a fondo en la estructura del documento para encontrar esos bytes que le indican a Word que tiene una ecuación ante sí.

Entiendo que no tengo que meterme a pelear con RTF, que en este caso actúa como un simple “envoltorio”, sino que mis cuentas las he de saldar con el objeto que se encuentra en su interior. Extraigo el objeto con ‘rtfobj’ de las Oletools y, según el comando ‘file’, se trata de un “Composite Document File V2 Document”, con la conocida firma “D0 CF 11 E0 1A 1B 1A E1”.

Tras buscar un poco llego a un documento del proyecto OpenOffice donde tienen documentada la estructura de este tipo de objetos. Comienzo a empaparme de su contenido. Al llegar a la octava página es hora de abrirlo a doble pantalla junto al editor hexadecimal destripando el objeto que se encontraba dentro del RTF. Por el momento no aparece nada interesante, sólo cómo está organizada la información en su interior.

Sigo avanzando páginas hasta llegar a la sección “Directory Entry Structure” (pág. 15), donde aparece al fin la sección dedicada a los objetos almacenados en el documento. El documento contiene un único objeto en la dirección 0x400. Voy entrada a entrada comprendiendo el significado de cada una hasta que llego al “Unique identifier”, que se encuentra en el offset 80 (0x50 en hexadecimal). Este identificador parece no referirse a la estructura de la información dentro del documento, sino que podría estar relacionado con el contenido del propio objeto en sí. Desconocía si era un identificador único generado aleatoriamente para, por ejemplo, unir distintos bloques separados en el documento, o si bien estaba relacionado con la información almacenada en su interior.

Pruebo suerte e invoco a San Google buscando estos 16 bytes tal y como aparecen en el objeto. Aparece solamente un único resultado. Se trata de unas reglas de ClamAV que parecen estar relacionadas con documentos maliciosos, concretamente con CVE-2017-11882 y CVE-2018-0802. Parece que voy por buen camino.

Pero me resulta raro que solo aparezca esta referencia en Google. Se me ocurre entonces buscar los primeros 4 bytes suponiendo que se encuentran en little endian “0002CE02”… et voilà! Ahora tengo más suerte y encuentro muchos más resultados, siendo el primero de ellos una entrada de Microsoft que habla sobre cómo deshabilitar el editor de ecuaciones en Office:

https://support.microsoft.com/es-es/help/4055535/how-to-disable-equation-editor-3-0

Parece ser que el CLSID {0002CE02-0000-0000-C000-000000000046} está relacionado con el editor de ecuaciones. De ahí que se utilice para deshabilitarlo a través de una entrada de registro.

¿Será este identificador el que utilice entonces Word para comprobar el tipo de objeto? Probémoslo viendo qué ocurre si cambiamos este identificador en el documento. Me voy al .doc original y modifico la zona de memoria donde aparece “02CE0200” y cambio una letra cualquiera.

En este caso he cambiado la tercera letra, una ‘C’, por una ‘D’. En la imagen no se ven los bytes “0002DE02” juntos debido a la ofuscación introducida, que intercala espacios en blanco (0x20), tabuladores horizontales (0x09) y saltos de línea (0x0A y 0x0D) que posteriormente son omitidos por el intérprete de RTF.

Con este único cambio, al abrir el documento con Word, la vulnerabilidad ha dejado de ser explotada, ya que no identifica el objeto como una ecuación.

Tengo entonces ya un buen indicador para comenzar a mejorar la detección de este tipo de vulnerabilidades. Esta regla Yara puede ser una buena primera base sobre la que empezar a trabajar identificando documentos que contengan ecuaciones que puedan llegar a intentar explotar vulnerabilidades en el viejo editor de ecuaciones de Office.

La entrada Detección de explotación del editor de ecuaciones de Office aparece primero en Security Art Work.

Hoy en SAW no vamos a hablar de seguridad sino de religión. De la religión verdadera, de la buena: de Unix. Y de sus dioses: Kernighan, Ritchie, Thompson… podríamos citar unos cuantos. Y de las herramientas que, en los años setenta, estos dioses nos enviaron a los pobres mortales, como el maná caído del cielo para el pueblo elegido. Y es que estos dioses crearon un sistema operativo de verdad, con unas herramientas técnicamente maravillosas y una filosofía muy sencilla: capacidades simples que combinadas hacen tareas complejas. La perfección. La vida es Unix ejecutando un script. Han pasado más de cuarenta años y nosotros, pobres mortales que éramos el pueblo elegido, ¿qué hemos hecho en este tiempo? Tratar de deshonrar ese legado divino con capas artificiales e inútiles (“de abstracción”, las llaman, para tratar de darles sentido) que introducen dos problemas innecesarios en cualquier entorno tecnológico “moderno”: complejidad, y por tanto probabilidad de error, y lentitud. Sirva de ejemplo el ejecutable “true”, al hilo de la historia que hace poco comentaba Rob Pike en Twitter:

$ >mytrue;chmod +x mytrue $ ./mytrue $ echo $? 0 $

Un programa cuya única finalidad es devolver siempre 0. Un ejecutable vacío. VACÍO. No puede haber algo más simple y que funcione, desde hace cuarenta años… pues bien, aquí entramos los mortales. Año 2018:

$ ls -l /usr/bin/true -rwxr-xr-x 1 root wheel 17760 29 abr 2017 /usr/bin/true $ file /usr/bin/true /usr/bin/true: Mach-O 64-bit executable x86_64 $ otool -L /usr/bin/true /usr/bin/true: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0) $ /usr/bin/true $ echo $? 0 $

Por supuesto, este es solo un ejemplo, y no de los graves, sobre cómo nos gusta complicarnos. Como dijo un profeta hace años, “Those who do not understand Unix are condemned to reinvent it, poorly.”. Me imagino el brainstorming inicial en un grupo que luego acaba sacando a la luz determinadas tecnologías:

– Tíos, vamos a hacer unas herramientas para manejar grandes conjuntos de datos que ahora están en ficheros planos.
– Pero, si ya tenemos awk, sed, grep…
– Funcionan demasiado bien y la gente no contrata mantenimiento. Escuchad, las llamaremos “bases de datos”.
– ¿Bases de datos? Irás de coña, ¿no?
– No, no, lo tengo todo atado: hacen que el fichero por debajo sólo se pueda procesar con nuestro programa metiendo varias capas de abstracción, pero realmente también están manejando archivos de texto, como hasta ahora…
– Jajajaja, ¡qué cabrón! ¡No hay huevos, Larry!
– Sujetadme la cerveza.

#define SELECT grep #define ALTER sed #define DELETE cut #define DROP “>” int make_program_look_bigger[1000000];

– Eres el puto amo, Larry. ¿Qué va a ser lo próximo, chicos? ¿Un lenguaje de programación que pueda convertir esta Sun 3500 en un 8086, con alguna excusa? ¿Qué se os ocurriría?
– Podemos meter un sleep en las líneas pares de nuestro código C y decimos que es independiente de plataforma.
– Jajajajajaja, no colará… Espera, ¿qué haces, James?
– Sujetadme la cerveza…

Evidentemente, situaciones como las anteriores se producen porque aunque sabemos que Unix es la religión verdadera, Kernighan, Ritchie y demás son sus dioses y algunos otros son sus profetas, aún así hay entre nosotros ateos (los llamaremos así para no ser crueles, aunque el nombre técnico es Human Malware), perfiles aparentemente técnicos que no han querido, sabido o podido ver la luz verdadera; los perfiles no técnicos están disculpados, porque Unix no ha iluminado sus vidas aún. Todos conocemos a algún ateo: son los que siempre buscan soluciones complejas a problemas triviales. Preguntadle a cualquier creyente cómo realizar una operación sobre, pongamos, un log, y con una línea de awk lo resolverá. Preguntadle a un ateo y definirá una estructura en base de datos, parseará el log con un programa en Java que tira de varias librerías bajadas de github para convertirlo en un XML, para luego insertarlo en la base de datos de antes, y montará un comité para determinar aspectos críticos, como elegir los tonos pastel para la interfaz gráfica o analizar la ubicación de los botones en una aplicación web que conecta vía API contra un servidor en cloud que a su vez aplica técnicas de machine learning sobre el puto log. ¿Y esto para qué? Para sacar las líneas que contienen la cadena “foo”. Ojo, en el tercer campo, ahí es nada.

Dentro de esa familia que estamos denominando amablemente “ateos” podemos diferenciar varios tipos característicos; son los siguientes:

– Proceseitor. Lo arregla todo con comités, procesos, procedimientos, controles, controles de los controles, seguimientos periódicos y derivados. Realmente esta subespecie no es un ateo, sino que es peor: está intentando convertir gente a otra religión, ITIL, considerada como secta destructiva en muchos entornos. Debe considerarse a proceseitor como ALTAMENTE PELIGROSO y, en caso de encontrase con uno, se recomienda no acercarse a él y avisar inmediatamente a las autoridades; también podemos cambiarles alguna de sus obras de cabecera, como Coaching for IT Strategists: a fist fucking approach, por un ejemplar de The Magic Garden Explained o The Design of the Unix Operating System, lo que conseguirá una combustión espontánea en cuanto comiencen la lectura.

– Visual developer. Programador que no sabe usar punteros y por tanto reniega de C; el scripting no es una alternativa porque “son ñapas”. Ante un problema (“especificación de requisitos” le llaman) analiza durante días la situación, hace comparativas entre varias tecnologías, monta unos entornos de desarrollo para realizar benchmarkings y, en seis meses, determina que va a desplegar diez capas de abstracción para empoderar al usuario en su relación con la tecnología y evitar así el tratamiento personalizado del dato. Ríete tú de ISO/OSI. Por supuesto el programa nunca funcionará, pero será por culpa de una especificación de requisitos incorrecta; en estos casos, invitar al ateo leer e interiorizar las Sagradas Escrituras, The C Programming Language y The Unix Programming Environment, puede ser útil, aunque no tanto como un disparo en la rodilla.

– Segurata. Acaba de actualizar su LinkedIn para poner que es “Senior Security Architect, Red Team Leader and Chief Strategist Hacker” porque se ha leído un manual de metasploit mientras acaba el máster y ya va a tope, con su Kali Linux y sus menús; por supuesto, prefiere ese manual al Computer Networks o al Modern Operating Systems de Tanenbaum, porque Tanenbaum no es jaker y además usa troff, y eso no es cool… Al contrario que en el caso anterior, el disparo en la rodilla suele ser contraproducente, porque el ateo seguiría molestando y encima se pondría paranoico, activando en su vida el modo MOSSAD_CLAIMS_FOR_ME y siendo aún más pesado; es más efectivo modificar su /etc/hosts para apuntar www.sgae.es a www.fsb.ru, convencerlo para atacar a la SGAE por el tema del canon de los CD, que nunca pasa de moda, y dejar que la naturaleza siga su curso.

– DevOps. Administra máquinas Ubuntu y se ha comprado una Raspberry, así que lo debemos considerar devops, porque cree que es un BOFH de verdad pero de vez en cuando se le escapan palabros como XML o agile. Acude regularmente a encuentros endogámicos donde algunos devops explican a otros devops cosas de devops, con dockers y tal, y cuenta la leyenda que una vez uno de ellos recompiló un núcleo Linux y no se lo contó a los demás. A Quarter Century of Unix History puede ser un buen detalle con estos ateos, para que sean conscientes de que muchas cosas no las han descubierto ellos, como también puede serlo un teclado sin intro, que nunca viene mal en estos casos. Y si además nos lo queremos pasar bien, tampoco está mal meterles el evil.sh en su .bash_profile.

– El usuario. Aunque se considera a sí mismo un perfil técnico porque una vez consiguió salir de vi y se hizo youtuber e instagramer a la vez, realmente sus conocimientos no son muy amplios y debemos considerarlo un usuario. De vez en cuando dice frases como “Nosotros, los técnicos” o “Aquí todos venimos de la parte técnica”, que te suenan como cuando los gibraltareños dicen “Nozotro lo ingleze”. Ante este tipo particular de ateo no podemos recomendar ninguna lectura, sólo comprensión y paciencia, y también hablarles despacito para que no hagan swap; por otro lado, es fácil -y divertido, hay que decirlo- entretenerlos con algunos palabros sabiamente combinados para que no molesten, como “Es que en el red team estamos trabajando con una VPN a través de USB que envía paquetes TCP a dispositivos IoT”. Ale, a procesar, campeón.

¿Qué hacemos con esta gente? Guardad el AK-47, por favor, que os veo venir y no debemos legislar en caliente. La situación es compleja, principalmente porque los ateos no tienen depredadores naturales y, sobre todo en los últimos años, se han dedicado a reproducirse de manera exponencial; si os cruzáis con uno podéis regalarle condones para frenar su tendencia reproductiva, pero un consejo: jamás os hagáis los héroes, que esta gente ya no tiene nada que perder, como los administradores de Lotus Notes, y pueden incluso ponerse agresivos. Por ejemplo, a proceseitor le molestan especialmente cosas como que alguien se salte el paso 3, punto 3.8, apartado 3.8.A, párrafo 3.8.A.c, línea 3.8.A.c.XVI, del procedimiento “Gestión de recursos informáticos corporativos en plena sinergia con el negocio”, que dice que todo renice debe ser aprobado mediante un burofax con el sello oficial, firmado por el IT Manager y dirigido al Business Strategist de la organización. Se pone nervioso, le da vueltas la cabeza y empieza a hablar en ITIL.

En SAW no tenemos la solución mágica para hacer frente al colectivo de ateos que pululan en las organizaciones; algunos ingenuos piensan que se pueden recuperar con iniciativas sencillas, por ejemplo con campañas donde se use el hashtag #AdoptaUnAteo (#AdoptALuser) para enviarles indirectas simpáticas que traten de marcarles el buen camino, del tipo “biff también avisa de nuevos mensajes… desde hace 40 años y sin soniditos ridículos, imbécil #AdoptaUnAteo”, “Menos stackoverflow y más RTFM #AdoptaUnAteo” o “No abras ficheros CSV con Excel, hijo de puta! #AdoptaUnAteo”. Pero nosotros sabemos que esto no funcionará: ni devolverá al ateo al camino verdadero ni tampoco conseguiremos que convierta el agua en vino. Por eso miramos a la Historia: ¿qué se ha hecho de siempre con la gente que abandona la religión verdadera? Dos cosas: exorcismos y sacrificios humanos. Punto.

Si vamos a exorcizar ateos, por ejemplo poseídos por systemd, debemos ir con cuidado; desde SAW recomendamos que un exorcismo lo ejecuten sólo profesionales, porque si sale mal nos confiamos, creemos haberlo recuperado y un día nos encontramos al falso creyente diciendo en un foro que ifconfig está deprecated. Cuando se dé cuenta de que vamos a exorcizarlo, el ateo tratará de confundirnos para hacernos creer que ha visto la luz verdadera; puede decir cosas en idiomas desconocidos, fruto de la posesión, del tipo “Powered by Solaris…” o “alias nano=‘rm -f’”, pero no nos dejemos engañar: al acercarle el Essential System Administration, su solo contacto le producirá quemaduras, comenzará a girar la cabeza 180 grados, a escupir espuma por la boca y a soltar blasfemias como “Has visto lo que ha hecho la cerda de tu hija”, “Tómame, tómame” o “Yo soy el Maligno y capturo SIGKILL”. Cuidado. Aquí es cuando el exorcista, un profesional, arrojará varios SIGTERM contra el PID del ateo y pronunciará unas palabras sagradas para liberar su alma:

Te exorcizamos Espíritu Inmundo, quienquiera que seas, Java, XML o Word. En el nombre de Unix seas arrojado de las almas de la religión verdadera. No oses oscurecer a los elegidos a quienes pretendes hacerte semejante; te lo ordena Brian, te lo ordena Dennis, te lo ordena Rob, que se hicieron carne y habitaron entre nosotros. Que los descendientes de MULTICS se apiaden de ti, que la pureza de un buen script limpie tu alma, que uses goto cuando tengas que usarlo. Unix es la senda y yo soy su pastor, así está escrito en mi GECOS. Hosanna, K&R, limpiad esta alma.

En este momento el ateo debe mostrar signos de reconversión, por ejemplo desinstalando la máquina virtual de Java o recitando de memoria la página man de getpwent(3). Si no es así ya debemos rociarlo de SIGKILL o, directamente, ejecutar un shutdown, que es el último recurso del exorcista antes de pasar a mayores: si el exorcismo no funciona ya sólo nos queda el sacrificio humano. Por ejemplo, en SAW, desde el fallecimiento de Ritchie hace más de siete años, mensualmente sacrificamos en su honor a un ateo en la hoguera, a la antigua, con encanto; lo hemos puesto en el cron y así no falla, que si no luego se reencarnan en consultores ISO y la liamos. Pero no penséis que es un simple kill -9, no: antes de quemarlo lo abrimos en canal con un CD donde están las fuentes de System V, nos comemos sus vísceras, bebemos su sangre y rezamos dos scriptnuestros para que aquellos dioses que se hicieron carne en los 70 vuelvan a poner cordura en este mundo 4.0 que nos rodea. Todo esto en honor a los creadores de maravillas como Unix, C o awk y, por qué no, también porque nos gusta.

DISCLAIMER: Todo este post está basado en hechos ficticios y no refleja en ningún momento opiniones personales del autor, efectivamente y no. Cualquier parecido con la realidad es pura coincidencia.

La entrada Las herramientas de los dioses aparece primero en Security Art Work.

(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XI Jornadas STIC del CCN-CERT aquí )

Otro día más en la oficina, con una lista de tareas pendientes a planificar más larga que la barba de Richard Stallman y ninguna de ellas entretenida: informes, documentación de un par de proyectos y la preparación de una reunión es lo que depara el menú del día para casi toda la semana.

Por suerte, el dicho de que “ningún plan sobrevive al contacto con el enemigo” en este caso juega a nuestro favor. Suena el teléfono, y mi jefe va directo al turrón: “Ha saltado una regla YARA del grupo ATD en la CARMEN de [Redacted] (entidad cuya identidad vamos a dejar en el anonimato denominándola a partir de ahora “la Organización”). Coge tus cosas y ve para allí a la carrera”.

El subidón ante la emoción de la caza es instantáneo: ATD es nuestra denominación interna de un grupo de atacantes que cazamos hace unos meses en otro cliente, y nuestros reverser destriparon el malware de arriba a abajo sin piedad. El análisis permitió detectar una serie de “irregularidades” particulares en su forma de actuar, lo que nos permitió generar una serie de reglas de YARA de alta fidelidad (es decir, falsos positivos prácticamente nulos). Si ha saltado en CARMEN (nuestra herramienta de detección avanzada de intrusos), es que tenemos “trufa” al 99%.

Portátil, disco duro de 4Tb para las capturas forenses, bloqueador de escritura, memorias USB con herramientas de análisis en caliente y live CD, lanzallamas… la mochila de respuesta ante incidentes está lista. Un puñado de caramelos del bote (los incidentes sabes cuándo los empiezas pero no cuándo los terminas) y nos montamos en un taxi derechos a [Redacted].

María (la técnico de seguridad de la Organización) ha hecho un excelente trabajo obteniendo más información sobre el posible ataque, y nos ofrece estos datos preliminares:

La alerta de YARA ha saltado en un adjunto de correo, y hacía referencia a un evento internacional que ocurre dentro de dos semanas (una técnica muy habitual en ataques de spear-phishing avanzados).
El correo ha sido enviado a un directivo de la Organización, que con las dos líneas de cargo que tiene se asume que es muy probable que tenga acceso a información sensible.

La suerte nos sonríe de nuevo ya que el directivo está de viaje por el extranjero y solo lee el correo en el móvil (donde las posibilidades de infección son mucho más reducidas). Localizamos al directivo, le contamos a grandes rasgos lo sucedido y obtenemos su autorización para solicitar a Sistemas la recuperación del correo de su buzón de usuario (mucho cuidado con hacer estas cosas sin los consentimientos adecuados o la ira de la LOPD/RGPD caerá sobre vosotros, avisados estáis).

El adjunto (un documento de Word) no tiene nada nuevo: información sobre una reunión comercial internacional sobre bla bla bla… y un adjunto a todas luces malicioso. Medio segundo de YARA sobre el adjunto confirma la regla, y otros cinco con las oletools permite identificar que el correo contiene una macro maliciosa. El Word es prontamente explotado en una máquina virtual de Windows 7 con dnschef para emular la conectividad a Internet, y nos escupe sin ofrecer resistencia una URL (según lo que sabemos de este grupo a día de hoy, la macro actúa como un dropper, descargándose el malware real de esta URL).

Capturamos la URL, y falseando el User-Agent de la petición (por si las moscas) nos descargamos el ejecutable desde la Wifi de la Organización (para intentar parecer que el directivo ha abierto el correo, por si los atacantes están monitorizando los logs de su servidor).

Comprimimos con contraseña, ciframos con PGP y enviamos a nuestro reverser de guardia con asunto “ATD – Revisar ASAP”. Mientras tanto proseguimos con las tareas de contención buscando la URL en los logs (para comprobar que no han mandado más correos con malware apuntando a esa URL). A continuación revisamos los logs de la pasarela de correo, con el fin de identificar la dirección falsa desde la que ha venido el correo electrónico y sobre todo el servidor.

Este paso es muy importante porque realimenta nuestra operativa de inteligencia de amenazas (los atacantes suelen reutilizar infraestructura, por lo que siempre es bueno conocerla), y sobre todo porque son muy buenos IOC (Indicators of Compromise o Indicadores de Compromiso). Esta información puede (y debería) ser compartida con otras entidades (CCN-CERT o INCIBE/CNPIC), para que avisen a otras organizaciones que puedan ser a su vez víctimas del mismo ataque.

Rebuscamos en los logs de la pasarela de correo mientras rumiamos “con SPF esto no habría pasado”… y nos sorprende no encontrarlo. Extraño. Revisamos los datos del correo por si nos hemos equivocado en la fecha, pero es la correcta. Repetimos la búsqueda (los grep a veces los carga el diablo), y seguimos sin encontrar el correo de marras.

Toca empezar a revisar otras alternativas. Pedimos a María que localice a la persona que supuestamente ha enviado el correo (al parecer, del área de administración del departamento del directivo). Ésta asegura rotundamente que “por supuesto que no lo ha mandado”, pero en cuanto le leemos el asunto y una parte del adjunto lo reconoce como suyo. Afirma con seguridad que corresponde a un evento que tienen que organizar… pero que el correo es un borrador que todavía no ha sido enviado a la lista de usuarios en la que se tratan estos asuntos.

La conclusión a la que llegamos es que es un correo interno de la Organización. Este hecho aclara dos cosas: en primer lugar, explica que no aparezca en los logs de la pasarela de correo externa, ya que es un correo puramente interno. Y en segundo lugar, que nuestros atacantes han comprometido al menos dicho equipo, lo que indica que el incidente no va a ser tan fácil de resolver como parece…

Volvemos a la fase de identificación del incidente (no sin antes compartir los IOC que ya hemos obtenido del incidente para agilizar la respuesta en otras organizaciones), y lo primero que hacemos es localizar el equipo del usuario que ha enviado el correo. Por suerte para nosotros (es un decir) son casi las 18.00h, por lo que podemos aprovechar que el usuario termina su jornada laboral para caer sobre su equipo cual fox-terrier hambrientos.

Aplicamos el procedimiento estándar: desconexión de la red, captura de RAM con DumpIt, obtención de datos de triage con Bambiraptor (el nombre puede sonar a chiste, pero la herramienta es magnífica) y apagado del equipo tirando del cable para una sesión de dc3dd del disco duro bloqueador de escritura mediante. A efectos de los atacantes, el usuario ha apagado el equipo y se ha ido a su casa (regla nº7 de la respuesta ante incidentes: no dejar nunca que los atacantes sepan que sabemos que están ahí).

La copia forense está comenzando cuando una compañera entra por la puerta (en incidentes serios, cuanta más gente puedas poner sobre el terreno lo más pronto posible, mejor), así que hacemos consejo de guerra frente a la máquina de café y la pongo al día del incidente. Hacemos el (tradicional) piedra-papel-tijera para ver cómo nos repartimos el trabajo, y yo me quedo con la captura de RAM mientras ella empieza a rebuscar en los logs de eventos, registros de Windows y MFT en busca de rastros de los atacantes.

Volatility, ahí vamos. Lo primero que hacemos es tirar nuestro conjunto de reglas de YARA para ATD sobre la RAM con yarascan, porque deberíamos identificar rápidamente el proceso infectado por el malware. Cinco minutos más tarde nos devuelve parcos resultados: cero. Vaya, nuestros “amigos” han debido evolucionar su malware. Toca remangarse la camisa.

El siguiente quick win suele ser malfind: lo lanzamos sobre la RAM para que detecte código oculto o inyectado en la memoria, pero tampoco nos devuelve nada interesante. Toca lanzar toda la artillería: pslist, pstree, psscan, cmdscan, netscan, handles, etc… Un buen rato después, no hemos podido encontrar nada malicioso en el equipo.

Miro de reojo a mi compañera, que está rebuscando furiosamente en los ficheros de log en busca de alguna pista, algún rastro que hayan dejado los atacantes, pero tampoco tiene éxito. Si la RAM o el triage no nos han dado resultado, nos va a tocar ir a por el disco duro.

Podemos tirar de Autopsy para la recuperación de datos, o hacer una línea temporal con Plaso, pero antes queremos comprobar una cosa: necesitamos ver el correo malicioso enviado con nuestros propios ojos. Localizamos el fichero .ost que almacena el buzón del usuario (la Organización tiene un Exchange corporativo sincronizado por MAPI con los clientes, por lo que en lugar de .pst tenemos .ost como almacenamiento de los correos).

Abrimos el fichero .ost con la utilidad Kernel OST Viewer y buscamos por el correo malicioso… de nuevo sin encontrarlo. Bueno, puede haber sido borrado. Al final un fichero .ost acaba siendo una especie de base de datos, y si no ha sido compactado podemos recuperar información con herramientas del estilo de OST Recovery Tool. Lanzamos la herramienta sobre el .ost extraído y el correo sigue sin aparecer.

“En igualdad de condiciones, la explicación más sencilla suele ser la más probable”, dice el principio de la navaja de Ockham. El correo no parece haber salido de este equipo (dejamos Autopsy corriendo para que nos busque otros ficheros borrados por si acaso), por lo que la siguiente opción es comprobar si ha sido enviado por otros medios.

María nos confirma que la Organización dispone de un OWA (Outlook Web App, un webmail corporativo), así como de un acceso de correo para los móviles corporativos vía ActiveSync. Sin embargo, el usuario afectado es de nivel administrativo y no tiene acceso a ninguno de los dos recursos (el OWA está detrás de una VPN para la que no tiene credenciales, y no tiene teléfono corporativo).

La investigación nos deja un único camino para investigar: el propio servidor de correo, un Microsoft Exchange 2010. El análisis, lo que encontremos (y lo que no), lo veremos en el siguiente artículo…

La entrada Exchange forensics: El misterioso caso del correo fantasma (I) aparece primero en Security Art Work.

Dejamos el anterior artículo con nuestras miras puestas sobre el servidor de correo de la Organización, un Microsoft Exchange 2010. Lo primero que podemos hacer es solicitar a Sistemas que haga un message tracking (seguimiento del mensaje) del correo, que mediante una herramienta gráfica (aunque también podemos hacerlo por consola) nos localiza el histórico de un correo a alto nivel dentro de Exchange.

Primer intento, y el correo sigue sin aparecer. Repetimos las direcciones y el técnico de Sistemas repite la búsqueda sin éxito. El correo tiene que estar por fuerza, así que le pedimos que busque de nuevo en todo el día completo… y por fin lo encontramos, 14 minutos más tarde de cuando tenía que haber sido enviado.

Al parecer la Organización no tiene bien implementada su estrategia de sincronización de tiempos, y tenemos una deriva de 14 minutos entre el servidor Exchange y los clientes (nota mental: insistir en la necesidad de desplegar un servidor NTP lo antes posible), pero al fin hemos localizado el correo. El pantallazo enviado por Sistemas sería algo similar a este (por temas de confidencialidad no podemos poner ninguno de los originales):

Lo más interesante del seguimiento del mensaje es que nos permite extraer el ItemEntryId, que dentro de Exchange constituye un identificador único que permite buscar en la EventHistoryDB, una tabla interna de Exchange que recoge de forma exhaustiva TODA la actividad del ciclo de vida de un correo (desde cuándo se crea el mensaje pasando por cuándo ha sido guardado como borrador, o con qué medio ha sido enviado). Exchange por defecto solo guarda esta información durante 7 días, pero en este caso tenemos tiempo de sobra, por lo que podremos extraer toda la información que necesitemos.

Extraemos el ItemEntryId, y le pedimos a Sistemas que nos extraiga toda la información relevante. En este caso no tenemos herramienta gráfica y les toca emplear un poco de Powershell:

El resultado debería de ser algo parecido a esto:

Con una entrada para cada actividad del buzón de correo en cuestión. En nuestro caso, un fichero de texto de unos 50Mb (el usuario está claro que enviaba correos). Desgraciadamente, nuestra búsqueda del ItemEntryId nos devuelve de nuevo un NULL como respuesta. La cosa empieza a tomar un cariz un tanto desagradable: el correo no está en el equipo del usuario, y tampoco lo encontramos en el Exchange.

Hay que empezar a considerar seriamente la posibilidad de que los atacantes hayan comprometido el Exchange ya que forma parte de su repertorio de TTP (Técnicas, Tácticas y Procedimientos). Si lo han hecho, el incidente va a tener un impacto crítico: los atacantes pueden leer todos los correos de la Organización, así como capturar todas las contraseñas de acceso (que habitualmente suelen ser las del dominio Windows). Y… ¿qué mejor forma de exfiltrar información que por un simple e “inocente” correo?

Sin embargo, antes de plantearnos el “quemar” el servidor de correo de la Organización (con una cantidad considerable de buzones de correo) necesitamos encontrar pruebas sólidas y contundentes, lo que nos obliga a agotar todas las vías de investigación posibles.

En primer lugar, podemos comprobar si el buzón del usuario tiene la auditoría activada, lo que nos permitiría comprobar con detalle los posibles accesos. El comando en Powershell sería muy similar a este:

… y los resultados son negativos (la auditoría consume recursos del sistema, estando por ello desactivada por defecto para todos los buzones).

Si no tenemos auditoría no vamos a poder controlar las delegaciones de buzones, algo bastante frecuente en entornos corporativos cuando una persona necesita acceder al buzón de otra (o se tienen buzones genéricos compartidos). Sin embargo, otra llamada a Sistemas nos confirma que el buzón de este usuario no tiene delegaciones, por lo que otra puerta más que cerramos en nuestra investigación.

Nos queda una opción: recuperar el buzón completo del usuario del Exchange. Aunque en el cliente de escritorio o de móvil pensemos que tenemos un acceso completo a nuestros datos, en realidad Exchange guarda una buena cantidad de información extra, siendo nuestro objetivo una carpeta en especial: la de Elementos Recuperables.

Esta carpeta hace las funciones de papelera, y TODOS los correos que se borran quedan almacenados en dicha carpeta durante 14 días o hasta que dicha carpeta tiene un tamaño de 30Gb (lo que suceda antes). Por lo tanto, en un entorno corporativo en el que los clientes tengan los buzones sincronizados vía MAPI (fundamental para poder tener acceso al correo desde OWA o los móviles), si el usuario borra un correo en su cliente de escritorio el cambio se reflejará en su buzón… pero el correo pasará a esta carpeta. Adicionalmente, esta carpeta es inaccesible por el usuario (y probablemente, tampoco pueda haber sido manipulada por los atacantes a menos que hayan comprometido el Exchange entero).

Pasan de las 22.00h, pero María está de acuerdo en que el incidente tiene prioridad máxima, así que llamamos por teléfono al usuario y le solicitamos su permiso para realizar una exportación de su buzón de usuario (insistimos: aunque la política de seguridad de la Organización pueda autorizar la monitorización de los correos, siempre es mejor informar y solicitar el consentimiento para ser escrupulosamente cumplidores con los derechos a la privacidad de los usuarios).

El usuario es totalmente cooperativo y nos facilita dicha autorización, por lo que hablamos con Sistemas para la exportación completa del buzón del usuario, algo que se realiza en Powershell con este comando:

La exportación nos da el buzón completo que podemos cargar de nuevo en Kernel Outlook PST Viewer. Una búsqueda rápida nos da una alegría: ¡el correo está en la carpeta de Elementos Recuperables! Por fin tenemos una pista sólida de lo que puede estar pasando. Si revisamos el correo cuidadosamente encontramos varios datos de interés:

El correo ha sido borrado (lógico, está en la carpeta de Elementos Recuperables). Si no lo ha hecho el usuario, alguien ha tenido que borrarlo por fuerza.
Podemos localizar el documento original, empleado para generar el documento malicioso, unos días antes en el buzón del usuario.
La firma del correo malicioso es ligeramente distinta a la original (los cargos no están completos, y falta una imagen en la firma).
El correo ha sido escrito en idioma inglés (cuando el idioma por defecto de la Organización es el español).

Pasa la medianoche y no tenemos más líneas directas de investigación. Todo parece apuntar a que los atacantes han comprometido el Exchange de la Organización, por lo que mañana tocará empezar a analizar los cuatro servidores que conforman el cluster de correo. Dejamos el Autopsy trabajando sobre la imagen forense y nos retiramos hasta mañana.

El análisis continuará, pero en el capítulo siguiente…

La entrada Exchange forensics: El misterioso caso del correo fantasma (II) aparece primero en Security Art Work.