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 https://github.com/yyuu/pyenv-installer 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 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

Amazon. Elogio de los métodos formales

Bug Cuando hablemos de métodos formales en informática enseguida nos tacharán de teóóricos, alejados de la realidad y poco prácticos. Tal vez sea así para programas sencillos y poco comprometidos, pero a partir de cierto nivel de complejidad una herramienta más siempre ayudará. En How Amazon Web Services Uses Formal Methods (no se si está accesible públicamente, tal vez este sí que sea fácil de leer [PDF] Use of Formal Methods at Amazon Web Services).

En concreto nos hablan de modelos formales y ‘model checking’ para ayudar a rseolver problemas difíciles de diseño en sistemas críticos. Las herramientas estándar de la industria se quedan cortas en algunos casos:

We have found the standard verification techniques in industry are necessary but not sufficient. We routinely use deep design reviews, code reviews, static code analysis, stress testing, and fault-injection testing but still find that subtle bugs can hide in complex concurrent fault-tolerant systems.

Las limitaciones de las pruebas (‘testing’):

We have found that testing the code is inadequate as a method for finding subtle errors in design, as the number of reachable states of the code is astronomical.

Tampoco es que lo utilicen de manera extensiva, claro. Lo usan para encontrar fallos sutiles y también para mejorar la comprensión y la confinanza en las mejoras que aplican en unos cuantos sistemas:

At the time of this writing, Amazon engineers have used TLA+ on 10 large complex real-world systems. In each, TLA+ has added significant value, either finding subtle bugs we are sure we would not have found by other means, or giving us enough understanding and confidence to make aggressive performance optimizations without sacrificing correctness.

En varios equipos y con apoyo al máximo nivel:

Amazon now has seven teams using TLA+, with encouragement from senior management and technical leadership.

Yo creía que esto sólo les pasaba a los principiantes, pero parece que es algo común: nos centramos en los casos normales, sin pensar en que puede haber fallos y errores.

Engineers naturally focus on designing the “happy case” for a system, or the processing path in which no errors occur.

La forma de enfrentarse al problema: cómo debería funcionar, en lugar de pensar en lo que podría ir mal:

We find this rigorous “what needs to go right” approach to be significantly less error prone than the ad hoc “what might go wrong” approach.

Para evitar fallos es necesario que todo el mundo comparta la misma visión del sistema, que debe ser correcta, ajustada, precisa, completa …:

To avoid creating subtle bugs, we need all engineers to have the same mental model of the system and for that shared model to be accurate, precise, and complete.

Los métodos formales también tienen sus inconvenientes, claro: es difícil evaluar (al menos para ellos en este momento) los fallos que provocan degradación del sistema y que se realimentan:

… surprising “sustained emergent performance degradation” of complex systems that inevitably contain feedback loops

También se habla de la forma de comenzar, los aspectos ‘sociales’ (el lenguaje utilizado):

Engineers think in terms of debugging rather than “verification,” so we called the presentation “Debugging Designs.

We initially avoid the words “formal,” “verification,” and “proof” due to the widespread view that formal methods are impractical.

¿Qué proporcionan los métodos formales? Según los usuarios ayudan a obtener buenos diseños (‘Get design right’), comprender mejor el sistema (‘Gain better understanding’) y también a escribir código mejor (‘Write better code’).

Lectura muy interesante.

Seguridad, usabilidad e incentivos

Robusto pero incómodo En Usable Security: How to Get It un artículo sobre usabilidad y seguridad. Se habla de la seguridad por culpa de los fallos, pero también se nos recuerda que muchas veces tenemos menos seguridad de la debida porque preferimos la comodidad:

Conflicts: Even more important, security gets in the way of other things you want. In the words of General B.W. Chidlaw, “If you want security, you must be prepared for inconvenience.”a For users and administrators, security adds hassle and blocks progress. For software developers, it interferes with features and with time to market.

También se habla de la seguridad como gestión de riesgos, y hay que tener en cuenta todos los costes:

Security is really about risk management: balancing the loss from breaches against the costs of security. Unfortunately, both are difficult to measure. Loss is the chance of security breaches times the expense of dealing with them. Cost is partly in dollars budgeted for firewalls, software, and help desks but mostly in the time users spend typing and resetting passwords, responding to warnings, finding workarounds so they can do their jobs, and so forth. Usually all of these factors are unknown, and people seldom even try to estimate them.

Porque, en definitiva, estamos hablando de economía:

More broadly, security is about economics.2 Users, administrators, organizations, and vendors respond to the incentives they perceive. Users just want to get their work done; …

Las organizaciones tienden a valorar sólo una parte de la ecuación:

They don’t measure the cost of the time users spend on security and therefore don’t demand usable security.

Pero todo depende de los incentivos:

People think that security in the real world is based on locks. In fact, real-world security depends mainly on deterrence, and hence on the possibility of punishment.

Lectura interesante

Sobre la autentificación de dos factores

Enséñame la patita. Vale, no tenía otra foto con patitas. Llevamos una temporada en la que uno de los mantras de los de seguridad en temas de autentificación es: ‘utiliza autentificación de dos factores’. Ya saben: normalmente una contraseña que nos sabemos y algo más (típicamente un mensaje que recibimos de alguna forma o algún dato generado de alguna forma). Aunque los beneficios están claros, me resisto a recomendarla abiertamente porque cuando funciona lo hace muy bien, pero cuando falla estamos fuera (ese SMS/correo que no llega, justo cuando más lo estamos necesitando o ese canal alternativo que en ese momento no está disponible). Sin ponernos en el caso de que alguien sea capaz de interceptar los mensajes de ese canal secundario, como nos recordaban recientemente en SMShing para robar tu 2nd Factor Authentication en tus cuentas Google o Apple #SMShing #Google #Apple. Y sin olvidar que ese canal alternativo (típicamente el teléfono móvil) se ha convertido en canal unitario.

A lo que vamos, en Why You Don’t Need 2 Factor Authentication nos lanzaban una serie de argumentos contra el sistema, que me gusta traer aquí:

  • Mito 1: lo que sabes, lo que tienes, bla, bla, bla

El autor dice que no todo es tan sencillo y que hay más categorías y más que centrarnos en esa clasificación deberíamos preocuparnos de los factorse utilizados y sus características.

  • Mito 2: la autentificación de dos factores hace mi cuenta más segura, sin consecuencias negativas

En realidad, perdemos tiempo en esa parte del proceso, la aplicación es más compleja, y no evita otros inconvenientes.

Al final, la autentificación de dos factores es un gestor de contraseñas para ‘perezosos’ (porque lo gestiona el proveedor del servicio). Me parece un punto de vista interesante, aunque conociendo la tendencia a la pereza de los usuarios igual es la única solución viable.

Manifiesto ágil para el desarrollo seguro

Agile Security Manifesto No es la primera vez que hablamos de desarrolo ágil y seguridad (Seguridad en proyectos ágiles y DevOps y seguridad. En esta ocasión nos referiremos a The Agile Security Manifesto de la empresa Cigital, que propone los siguientes principios:

  • Confiar en los desarrolladores y probadores más que en los especialistas en seguridad
  • Asegurar mientras desarrollamos mejor que cuando el trabajo está hecho
  • Implementar las características de manera segura mejor que añadir características de seguridad.
  • Mitigar los riesgos mejor que arreglar los fallos.

Interesante.

Desarrollar software cuando el software no es tu objetivo

ADN En The myths of bioinformatics software algunos comentarios sobre los programas que se utilizan en bioinformática pero que creo que se puede extender a casi cualquier rama del conocimiento: poco pensado para ser publicado y reutilizado, desarrollado muchas veces por personas sueltas o equipos muy pequeños y un poco a salto de mata, que luego es difícil de leer/modificar/mantener por otros.

También comenta con que las licencias permisivas no son una ayuda cuando se desarrolla con esa precariedad (y esos objetivos). También habla de la posibilidad de vender los programas y hasta qué punto podemos estar subvencionando a empresas privadas si les cedemos de manera gratuita los programas para uso comercial y algunas cosas más.

No estoy seguro de estar de acuerdo con todo, pero es interesante leer el punto de vista de alguien que desarolla software pero no es su misión principal.

Seguridad para usuarios no interesados en seguridad

Palabras Transmitir conceptos de seguridad a gente ya preparada es más fácil (aunque hasta en eso tengo dudas). Pero cuando hablamos de usuarios finales tenemos realmente un problema. Yo suelo decir que los usuarios (y muchos profesionales) conocen sobre seguridad lo que escuchan/leen en las noticias y esto es bastante preocupante.

De eso hablaban en Escape the Echo Chamber: Educating End-Users and Non-Security People.

El autor lleva tiempo dedicándose al tema, incluso ha escrito un libro:

Since that day in March (2014), I have studied this problem and what began as a set of practices for my family has evolved into a new book, How Not To Be Hacked. Below, I share the barriers that I discovered in educating regular people and how you can carry this forward within your own organization.

Las barreras serían:

  • Los usuarios no quieren convertirse en expertos en seguridad.

No hay mucho que comentar sobre esto. Cada uno quiere hacer su tarea, acabarla pronto y bien.

  • Demasiado preciso no es suficientemente preciso.

Si le preguntamos a algún técnico sobre algo la respuesta suele ser: ‘depende’ y esto es algo que al usuario no le sirve para nada al final. Tendríamos que cambiar este tipo de respuestas por las que sean suficientemente buenas (en lugar de perfectas).

  • Falta de inteligencia emocional.

Tenemos que empatizar con los usuarios de tecnología, ayudarles, explicarles, y simplificarles los problemas.

Creo que compraré el libro.

Un informe sobre productos criptográficos

Escondido En A Worldwide Survey of Encryption Products podemos leer un interesante informe en el que se puede leer la prometida lista de productos pero también una introducción donde se sugieren algunas ideas interesantes.

Se identifican 587 productores de este tipo de software:

The new survey also identified 587 entities that sell or give away encryption products, and of those, two-thirds are outside the US.

Se comenta sobre la eficacia de las instrucciones para añadir puertas traseras a los productos criptográficos que algunos gobiernos imponen:

Schneier argues in the paper that the survey findings call into question the efficacy of any US mandates forcing backdoors for law-enforcement access. He asserts that they show that anyone who wants to avoid US surveillance has hundreds of competing products to choose from. The report findings indicate that foreign products offer a wide variety of secure applications—voice encryption, text message encryption, file encryption, network-traffic encryption, anonymous currency—providing the same levels of security as US products do today.

Los mayores productores de criptografía serían, después de EEUU:

The most common non-US country for encryption products is Germany, with 112 products. This is followed by the United Kingdom, Canada, France, and Sweden, in that order.

Entre los datos se pueden encontrar siete productos identificados como españoles de, si no cuento mal, seis empresas diferentes:

Mirando los enlaces veo que algunas de estas empresas tienen más productos y tampoco es fácil determinar el origen así que, como decíamos arriba, igual lo más interesante son las primeras páginas del informe y echarle un ojo a la lista para hacerse una idea.