Algunas cuestiones que hay que tener en cuenta con el modelado de amenazas

Modelando La seguridad absoluta no existe. Además no tiene sentido protegerse contra problemas que no tenemos, u olvidarse de los que tenemos porque no salen en los libros o en las listas de consejos. Por eso nos centramos en riesgos y cómo evitarlos/mitigarlos. Para ello podemos usar el modelado de amenazas para nuestro producto y tratar de determinar qué es lo importante aquí y cómo puede afectarnos, para tomar las decisiones adecuadas.

En Threat Modeling 101: Ten Common Traps Not to Fall Into hablan del modelado de amenazas (‘threat modelling’) y algunos trampas en las que se puede caer y que conviene tener en cuenta:

  • Usar nuestros sentimientos

Está bien que conozcamos el negocio y todo eso, pero nuestras sensaciones no son suficientes para justificar decisiones. Sobre todo por lo que podemos dejarnos en el camino.

  • Nunca terminas de hacer modelado de amenazas.

Puede ser cierto, siempre hay más cuestiones que considerar. Sugieren seguir los pasos: modelar, identificar amenazas, mitigar, validar.

  • La forma de hacer modelado de amenazas es X

Como casi siempre, la forma perfecta de hacer las cosas no existe, depende del contexto, de quién lo hace, los medios disponibles,…

  • Se trata de una capacidad (‘skill’)

En realidad se trata de un conjunto de técncias y herramientas para mejorar en nuestra habilidad de llevar a cabo el trabajo. También la lectura y formación adecuadas.

  • El modelado de amenazas se sabe, no se aprende

Como todo, se trata de aprender, practicar, perfeccionar…

  • Foco incorrecto

A veces se piensa que el objetivo es encontrar amenazas cuando en realidad se trata de mitigarlas y/o solucionarlas.

  • El modelado de amenazas es para especialistas.

En realidad cualquier desarrollador debería incluir en su proceso de desarollo estas ideas, para hacer sus programas mejores.

  • El modelado de amenazas de manera aislada.

En realidad puede ser otra forma más de ayudar a comunicar a los distintos agenets en el procseo.

  • Excesivo foco en las amenazas.

En realidad los ataques, elementos de mitigación y requisitos van de la mano. Unos pueden ayudar a comprender mejor los otros e incluso pueden obligar a tener que adaptarlos.

  • Modelado de amenazas en el momento incorrecto.

Como siempre, pensar en la seguridad al final del proceso es la receta segura para que haya cosas que ya no tengan remedio.

Se puede ver una retransmisión de la charla en Threat Modeling: Lessons from Star Wars - Adam Shostack aunque a lo mejor con las ideas principales ya nos parece suficiente.

El copyright puede facilitar algunos fraudes

Un Volskwagen en la carretera Ya hacía tiempo que no hablábamos de copyright y coches. En Draconian US copyright rules made it easier for Volkswagen to cheat reúnen el tema de las restricciones sobre el acceso a la información de nuestros vehículos y un escándalo tan sonado como es el engaño por parte del fabricante Volskwagen con respecto a las emisiones de sus vehículos.

El titular lo dice todo y no hay mucho más que añadir: puesto que ni siquiera los propietarios de los vehículos tienen acceso a sus interioridades, es bastante difícil que esa parte de la auditoría que vendría del público interesado sea realizada. Recordemos que el fraude vendría porque los parámetros del vehículo podían cambiar de la mano de algunos programas instalados que serían capaces de determinar en que circunstancias se encontraba el mismo y, en particular, cuando estuviese siendo sometidos a las pruebas de emisiones.

In the case of Volkswagen, cars with diesel engines were equipped with software that determined when they were undergoing Environmental Protection Agency testing for carbon emissions. During a test, the software would turn off mechanisms that increased engine performance, thus decreasing emissions; under normal driving conditions, the performance enhancement would be turned on and emissions were higher.

Como nota lateral, también nos alerta contra los procedimientos excesivamente fijos y automatizados que permiten que un programa pueda detectarlos y modificar este comportamiento. Un buen probador debería tener un guión, pero también debería poder incluir actividades ‘no programadas’ e imprevistas que puedan consegui saltarse el guión previsto por el que realizó el producto. Porque conviene no olvidar que esos ojos mirando podrían haber encontrado el problema, pero también podría haber ocurrido que nadie mirase en el lugar adecuado (Más fallos con una larga historia).

Ataques por ocupación de nombres de paquetes en diversos lenguajes

Paquete Queremos que todo sea fácil: descubrir algo, instalarlo, que se ejecute sin problemas y pasar a pensar en otra cosa. Basándose en la idea del typosquatting basado en DNS (esto es, cuando tecleamos de manera incorrecta el nombre de un sitio web), Nikolai Philipp Tschacher pensó en explorar la posibilidad de hacer algo parecido con los repositorios de código de diversos lenguajes: se crean paquetes con nombres parecidos a los de algunos de uso frecuente y se monitoriza el número de instalaciones de los mismos.

Lo cuenta en Typosquatting programming language package managers y desde allí se puede acceder a un documento completo en pdf.

Los resultados son interesantes: más de 17.000 máquinas instalaron esos paquetes y ejecutaron el código, siendo alrededor de la mitad las instalaciones realizaddas con permisos de administrador.

As a sample data set I will make use of my workout progress data between May 2016 and August 2016.

  • 17000 computers were forced to execute arbitrary code by typosquatting programming language packages/libraries
  • 50% of these installations were conducted with administrative rights
  • Even highly security aware institutions (.gov and .mil hosts) fell victim to this attack
  • a typosquatting attack becomes wormable by mining the command history data of hosts
  • some good defenses against typosquatting package managers might look like

Es cierto que los investigadores de seguridad se dieron cuenta con cierta rápidez de que estaba ocurriendo el problema (unos días). El experimento se realizó entre noviembre de 2015 y enero de 2016, subiendo un cierto número de paquetes de los que más de la mitad se había generado el nombre de manera aleatoria. Los lenguajes elegidos para el ataque fueron Python, Node.js (recuerden el incidente con aquél paquete …) y Ruby, aunque otros podrían tener problemas similares con los repositorios análogos (con GitHub y otros alojamientos podrían pensarse ataques similares, si alguien se toma la molestia).

Dice el autor que los requisitos para que un ataque así funcione se basa en:

  • Posibilidad de registrar cualquier nombre de paquete y subir código sin supervisión.
  • Posilibidad de conseguir ejecución de código con el paquete descargado.
  • Accesibilidad y disponibilidad de buena documentación para subir y distribuir paquetes en los repositorios.
  • Dificultad para aprender rápidamente el lenguaje objetivo.

Por supuesto, la ejecución del código no es imprescindible si pensamos en paquetes de infraestrcutura, bibliotecas y módulos, etc., que terminarán siendo ejecutadas por los programas que las invocan.

Entre las contramedidas, habría que evaluar la prohibición de determinados nombres (en particular, paquetes importantes cuyo nombre cambió con el tiempo y paquetes del core), reducir el número de caracteres disponibles para el nombre de los paquetes, añadir espacios de nombres y, claro, hacer las cosas más difíciles evitando la ejecución directa de código en la ejecución.

También se puede utilizar lo aprendido en los gestores de paquetes de código (por ejemplo, los de algunas distribuciones de Linux), así como analizar los errores que comenten los usuarios para tratar de poner las contramedidas adecuadas.

En el apartado de anécdotas y sucesos, parece que poca gente prestó atención al experimento aunque se lanzaban los avisos adecuados aunque sí que hubo alguien que lanzó un contra-ataque tratando de explotar alguna vulnerabilidad mediante inyección de SQL. También había usuarios (IPs) que realizaban instalaciones repetidas, invistiendo en el error.

Primeros pasos con Pine64

Caja del Pine64 Como decíamos el otro día, tenía pendiente de terminar de poner en marcha mi Pine64.

El Pine64 llegó hace bastantes días pero no había encontrado la ocasión de ponerme y cuando la encontré no lo conseguí a la primera. Desde luego, no es un proyecto tan bien acabado como el C.H.I.P. Primeros pasos con el C.H.I.P. y tampoco le había dedicado tiempo suficiente. El primer problema que tuve con una distribución Ubuntu que puse en una tarjeta de memoria era que intentaba buscar una conexión ethernet; como no le había puesto el cable, se quedaba atascado hasta que expiraba el tiempo correspondiente (timeout): eso me hizo perder algún rato pensando que la imagen estaba defectuosa.

Cuando por fin me di cuenta y arrancó, configuré la red y seguí teniendo problemas de conexión en la red local (no me detuve mucho a ver qué pasaba, decidí probar otra distribución).

Tampoco ayudó mucho esta entrada negativa Pine64: the un-review que exponía bastantes quejas sobre la placa.

A primera vista es una placa gigantesca: ocupa casi el mismo espacio que tres Raspberry Pi (que a la vista de los últimos dispositivos que vamos consiguiendo ya se nos hace algo grande). Además es exigente en cuanto a la alimentación necesaria (no nos servirá cualquier cargador) y la base no está muy refinada (si lo apoyamos en nuestro típico brazo de sillón de casa se enganchará).

Una de las web de referencia sería Pine64 y allí se puede ver información. En Downloads hay recopiladas diversas imágenes con sistemas operativos que incluyen Android, Remix OS, Debian (la que finalmente instalé), Ubuntu y otras…

Pine 64 al lado de la Raspberry Pi y un Arduino

Una vez que conseguimos que arranque disponemos de un sistema funcionando que configuramos a nuestro gusto y podemos empezar a trabajar. En unas pruebas sencillas se ve que es más rápida que el C.H.I.P. y la vieja Raspberry pero en la práctica la sensación no es de mucha soltura (si me preguntaran sin haber hecho alguna prueba habría dicho que el C.H.I.P. iba más fluído). Eso a pesar de tener un procesador a priori más capaz y cuatro cores.

Seguimos aprovechándonos de la copia de configuraciones desde otras máquinas para poder conectarnos en diferentes sitios y ya podemos gestionarla desde un portátil mediante ssh.

El escritorio:

Pine64 Desktop

En el apartado negativo, pedí dos módulos adicionales y sólo ha llegado uno. Aparentemente están (o han estado colapsados) y sigo sin la cámara que pedí. Confíoen que cuando se normalice todo terminaré recibiéndola.

Entre sus características

  • Procesador 1.2 Ghz Quad-Core ARM Cortex A53 64-Bit con Dual core Mali 400 MP2 GPU.
  • 512 Mb, 1Gb o 2Gb de RAM (yo tengo la de 1Gb)
  • Bluetooth 4.0 and 802.11BGN (vendida como añadido aparte).
  • Salida de vídeo HDMI 920×1200 HDMI v1.4 hasta 4K.
  • Dos puertos USB y puerto micro USB OTG (se usa para alimentación)

A ver si damos con algún proyecto adecuado para este chisme.

Primeros pasos con el C.H.I.P.

C.H.I.P. Durante el último año he apoyado algunos proyectos en Kickstarter. Por ser más concreto, el MeARm que lo tengo en dique seco, PiJuice que sigue sufriendo retrasos, Pine64, que llegó hace algunas semanas pero todavía no he podido ponerlo a funcionar (comentaré, supongo, sobre ello más adelante). Además compré un par de C.H.I.P. que no era en Kickstarter pero si ha seguido el modelo de compra anticipada y ya lo recibirás. Entre los inconvenientes de este modelo de compra es que el momento en que decides apostar por un proyecto no tiene nada que ver con el momento en el que recibes el resultado.

El C.H.I.P. llegó la semana pasada y me encanta: buena documentación, todo bien pensado para trabajar rápido y unas prestaciones adecuadas (que nadie espere supercomputación, claro).

Frente a otras placas y sistemas que nos hacen esforzarnos un poco al principio, este aparatito de 9 dólares está muy bien pensado: lo conectamos a nuestro ordenador, arranca y abre un puerto serie a través del que podemos empezar a trabajar (para los que lo prefieran, también se puede conectar a una pantalla o a la televisión para configurarlo):

If everything went OK, you can now power up your CHIP again and connect via serial as a USB gadget:

  screen /dev/ttyACM0 115200

Ya imagino que esto puede ser un freno para muchos así que tranquilos, que también se puede usar con la tele o con una pantalla y usar el ratón:

C.H.I.P. on TV

Y desde allí configurar la red (sin más cables que un USB), el ssh, el usuario de trabajo y ponerse a funcionar la próxima vez que arranque. También tiene (por si fuera necesario) un gestor de conexiones basado en texto (nmcli) y sólo si queremos redes más complicadas (de tipo empresarial) necesitaremos trabajar un poco más. Aunque gracias a eso he ‘descubierto’ las ventajas de copiar y pegar las configuraciones entre sistemas (con cuidado) e incluso se me ha ocurrido un posible proyecto: Sharing WiFi configuration files over diffferent computers. También que, aparentemente, es un tema que ya está bien resuelto en Windows 10 y en Mac OS. Tenemos que espabilar.

El escritorio:

C.H.I.P. Desktop

No he tenido tiempo de mucho más (instalar el Python, el pyenv y fantasear sobre hacer algunas pruebas con el MeArm (ahora sí).

En el apartado negativo: C.H.I.P. es un mal nombre. Buscar en internet algo que se llama chip es perder el tiempo y la paciencia (no ayuda tampoco, claro, que es un proyecto relativamente nuevo y con poca difusión). Otra pequeña pega es que cuando añades un disco USB no lo monta automáticamente (con el esritorio sí, pero no quiero usarlo con una pantalla).

Entre sus características (copiadas y traducidas de [The PocketC.H.I.P. Is the Handheld Linux Machine I’ve Been Looking For)[http://lifehacker.com/the-pocketc-h-i-p-is-the-handheld-linux-machine-ive-be-1783247338])

  • Procesador Cortex A8 R8 a 1Ghz con una GPU Mail-400
  • 512 Mb de RAM
  • 4 Gb de memoria flash
  • Wifi 802.11 b/g/n y Bluetooth 4.0
  • Salida de vídeo con conector de 3.5mm para vídeo compuesto y audio.
  • Puerto USB y puerto micro USB OTG (se usa para alimentación)

Interesante