Obsolescencia de algoritmos criptográficos vs realidad

 Algunos trucos para esconder programas maliciosos En SHA-1 Deprecation: No Browser Left Behind nos hablan sobre la obsolescencia del algoritmo de hash criptográfico SHA1 con algunos datos como lo que costaría hoy en día generar colisiones (recordemos que en un algoritmo de hash el poder genera un mensaje diferente que tenga el mismo ‘resumen’, esto es, encontrar colisiones es uno de los principales problemas de seguridad):

Computers keep getting faster and now SHA-1 is increasingly vulnerable to potential collision attacks. The estimate today is that it would likely cost around USD$700,000 to generate a SHA-1 collision. By 2021, the price is forecast to fall to just USD$43,000.

También hacen algunos cálculos de cuánto se utiliza su sucesor, [SHA2]/(https://en.wikipedia.org/wiki/SHA-2):

To understand the impact, we spent the last few weeks testing browser connections to CloudFlare’s network for SHA-2 support. We see approximately 1 trillion page views for more than 2.2 billion unique visitors every month, which gives us a pretty representative sample of global traffic.

Y la conclusión es que podrían utilizar este algoritmo un 98.1% de los navegadores observados por ellos que puede parecer mucho pero, en sus cuentas, deja fuera a un nada despreciable número de más de 37 millones de personas. En Estados Unidos la cosa sería un poco mejor:

The United States has 99.26% SHA-2 support, making it the 15th most modern browser market (out of more than 190 countries we saw traffic from during our test). In fact, SHA-2 support in Western Europe and North America is universally over 99%.

pero, desde luego, no el mejor de los sitios con acceso a esta tecnología (15 puesto en el ranking de navegadores más modernos).

Lamentablemente, en la cola de esta lista están algunos de los países que probablemente necesitarían tener mejores sistemas de seguridad.

Unfortunately, this list largely overlaps with lists of the poorest, most repressive, and most war torn countries in the world. In other words, after December 31st most of the encrypted web will be cut off from the most vulnerable populations of Internet users who need encryption the most.

Y, claro, esto tiene como consecuencia que sitios como Alibaba o Facebook que quieren tener clientes en esas zonas menos protegidas admitan utilizar los algorimtmos menos seguros (lo que puede afectar a todo el mundo).

For instance, Alibaba, the Chinese Internet commerce giant, supports SHA-1 fallback across many of its sites. That’s not surprising given more than 6% of their Chinese customers could not securely buy from their online store if they only supported SHA-2.

Facebook also supports SHA-1 fallback across many of their sites.

Interesante.

Condiciones de carrera

Carrera Un texto introductorio sobre las condiciones de carrera: cuando varios procesos acceden a un recurso compartido de forma que se pueden producir resultados diferentes según la temporización con que se ejecute el código. Lo cuentan en Practical Race Condition Vulnerabilities in Web Applications y me pareció un texto que valía la pena guardar por las explicaciones, ejemplos y métodos de resolución para evitar el problema.

Compartir la WiFi sin precauciones

WiFi Hace bastante tiempo solía tener mi WiFi casera abierta: pensaba que algún paseante que pudiera necesitarla le vendría bien poder conectarse un rato. La cerré por varios motivos: siempre había alguien que abusaba y se ponía a descargar utilizando mi ancho de banda y provocando molestias. El otro era una cuestión de seguridad: cuando va habiendo más dispositivos conectados en mi red, es más delicado vigilar que todo va bien y que un atacante casual (intencionado o troyanizado) no provoque un desastre.

Hace mucho menos bromeaba sobre cuánto tiempo es ‘prudente’ esperar cuando uno lllega a una casa ajena para pedir la contraseña de la WiFi sin parecer descortés.

Como visitantes, también deberíamos ser cuidadosos a la hora de conectarnos a redes extrañas, que nunca sabemos lo que puede haber entre internet y nosotros.

Por los motivos señalados arriba, me sentí muy reforzdo por No, you can’t join my wifi network Troy Hunt nos explica que no deja utilizar su WiFi a los invitados y sus motivos para ello.

La primera es que, aunque confíes en tus invitados (como personas, se entiende), no puedes confiar en que sus dispositivos sean seguros y que se comportarán adecuadamente.

That might mean as a result of introducing an infected machine into the network or picking up something unsavoury while they’re browsing around behind the confines of your firewall.

También habla de la variedad de dispositivos que tenemos hoy en día conectados a nuestra red y la información que un atacante podría obtener:

Think about what’s discoverable on your own network once a device joins it: all the devices and open ports just for a start. Your NAS, your media server, your security cameras and all manner of IoT things with nothing more than software to protect them. Just as with a corporate environment, you have to work on the assumption that any machine introduced to the network is malicious and frankly, I want to minimise that risk as far as possible.

Además nos recuerda que para visitantes casuales las conexiones móviles han evolucionado mucho y lo normal es tener buena velocidad y una tarifa con suficiente cantidad de datos para no tener que pedir prestado.

En caso de que queramos compartir la WiFi (y también es un consejo que suelo dar para pequeños negocios y sitios donde compartir la WiFi es algo que se espera), deberíamos una red para invitados en la que no haya nada que nos pueda preocupar desde el punto de vista de nuestros datos:

Of course you could always just defer to your wireless access point’s guest network (if you have that capability — and many do not), that’s what it’s designed for, right? The basic premise is that a guest network is a logically isolated network for exactly what the name suggests – giving guests access. This keeps them separated from your primary network which is a good thing, except the implementation can be kind of sucky.

Los empleados y las contraseñas

Encuestas En Half of U.S. Enterprise Employees Reuse Work-Related Passwords nos recuerdan uno de los problemas más importantes en la seguridad de las empresas: la falta de preocupación por parte de la gente que trabaja en ellas.

Se basa en una encuesta entre más de 1000 empleados de empresas en EEUU de los que casi la mitad afirmaban que re-utilizaban las contraseñas para cuentas relacionadas con el trabajo. La noticia no es negativa del todo porque en el caso de las contraseñas personales la re-utilización sube a las 2/3 partes.

A recent Ping Identity survey of more than 1,000 enterprise employees in the U.S. has found that almost half of respondents admit that they’re likely to reuse passwords for work-related accounts, and almost two-thirds reuse passwords for personal accounts.

Un 66% afirman que no las darían a cambio de nada, pero hay alrededor de un 20% que las cambiarían por dinero para la hipoteca, préstamos de estudios y otras necesidades.

And while 66 percent of respondents said they wouldn’t trade their personal email login credentials for anything, 20 percent said they would trade them for a paid mortgage or rent for one year, and 19 percent would trade them to pay off student loans or higher education tuition.

Hace algún tiempo hablábamos de encuestas similares donde la preocupación de los empleados no es suficiente cuando se trata de las contraseñas utilizadas en el trabajo (y las personales, según este estudio, todavía peor).

El juramento del programador

Teclados En Uncle Bob Proposes an Oath to Programmers justamente eso. Robert C. Martin, conocido como Uncle Bob (tío Bob) propone (traducción aproximada):

  1. No produciré código dañino
  2. El código que produzca será siempre el mejor posible. No entregaré a sabiendsas código defectuoso en su comportamiento o en su estructura.
  3. Realizaré en cada entrega una comprobación segura y repetible de que cada elemento del código hace lo que debería.
  4. Haré entregas pequeñas y frecuentes, para no obstaculizar el trabajo de otras personas.
  5. Mejoraré el código sin temor y sin descanso cada vez que sea posible. Nunca empeoraré el código.
  6. Haré todo lo posible para mantener mi productividad y la de otras personas tan alta como sea posible. No haré nada que reduzca esa productividad.
  7. Me aseguraré de forma continua que otros pueden cubrir mi trabajo y que yo puedo cubrir el suyo.
  8. Produciré estimaciones que son honestas tanto en magnitud como en precisión. No haré promesas sin certidumbre.
  9. Nunca dejaré de aprender ni de mejorar mis habilidades.

El original del juramento se puede leer en The Programmer’s Oath.

En la entrada se añden algunos comentarios recibidos en su momento en Twitter después de la publicación del juramento y se recuerda el manifiesto del software robusto The rugged manifesto sobre el que comentamos en su momento en Manifiesto del software robusto.

¿Quién actualizará los juguetes de los niños?

Juguetes Si los dispositivos no son seguros Estudio sobre vulnerabilidades en el firmware de dispositivos, ¿qué podría hacernos pensar que los dispositivos que se incluyen en los juguetes lo serán?.

En When children are breached – inside the massive VTech hack nos hablan con cierto detalle de las vulnerabilidades encontradas en esos ordenadorcitos parecidos a tabletas que están pensados para los niños pequeños:

Inyección de SQL:

Why they’re returning a SQL statement is absolutely beyond me. Lorenzo was told by the person that provided him with the data that the initial point of compromise was due to a SQL injection attack and even without seeing the behaviour above, I would have agreed that was the most likely attack vector. On seeing the haphazard way that internal database objects and queries are returned to the user, I’ve no doubt in my mind that SQL injection flaws would be rampant.

Desarrollo poco cuidadoso (sobre todo teniendo en cuenta quién va a utilizar el producto):

But what really disappoints me is the total lack of care shown by VTech in securing this data. It’s taken me not much more than a cursory review of publicly observable behaviours to identify serious shortcomings that not only appear as though they could be easily exploited, evidently have been.

Si los ‘juguetes’ de los mayores se actualizan poco, ¿quién actualizará los de los niños?

¿Cómo encajan las actualizaciones en los procedimientos actuales?

Reiniciando Esta entrada no será muy novedosa para casi nadie pero viene bien recordarla aquí. En The Problem with Patch Management: All the Humans hablan de las actualizaciones y de los problemas que nos causan: tenemos muchas cosas de las que ocuparnos, no es fácil siempre determinar si realmente nos afectan o no, tampoco es sencillo saber si afectarán a otros de nuestros procesos…

Necesitaríamos una forma de conocer las actualizaciones disponibles para nuestros dispositivos y sistemas y que pudieran ser aplicadas de forma que el impacto fuera mínimo:

What’s needed is a way to detect available updates across every operating system and all firmware on physical devices. All verified updates need to be applied in a way that minimizes or eliminates downtime. The updates must be introspectable, auditable, and repeatable. The process should minimize human interaction and required expertise.

Las actualizaciones deberían integrarse bien en los procesos modernos de integración continua:

Modern practices such as continuous delivery make this practical by constantly ensuring incoming change results in the desired behavior. Software updates should be treated as just another incoming change.

Estudio sobre vulnerabilidades en el firmware de dispositivos

Ordenador Esta es casi una continuación de la entrada anterior. En Many embedded devices ship without adequate security tests, analysis shows hablan del análisis realizado al firmware de un montón de dispositivos y las vulnerabilidades encontradas. Se analizaron 1925 dispositivos de más de 50 fabricantes.

De ellos sólo consiguieron arrancar alrededor de 250 servidores web:

The researchers started out with a collection of 1,925 Linux-based firmware images for embedded devices from 54 manufacturers, but they only managed to start the Web server on 246 of them. They believe that with additional work and tweaks to their platform that number could increase.

Intentaban encontrar problemas en las interfaces web de los dispositivos. Las encontraron, pero también en el código PHP utilizado en algunos dispositivos, inyecciones de SQL, cross-site scripting,… O sea, lo típico que suele encontrarse en cualquier sistema de complejidad mediana.

Y un aviso (más) a los usuarios/gestores/administradores que utilizan estos dispositivos.

Estudio sobre reutilización de certificados en dispositivos

Puerta cerrada La semana pasada ocurrió un ataque distribuido de denegación de servicio (DDOS) que afectó a sitios tan importantes como Twitter, Netflix, The New York Times, o GitHub (no lo comprobé, pero seguramente esta bitácora se vió afectada, al estar albergada en este último). Estaba provocado por un ataque a los servidores de nombres (DNS). Aparentemente estaría basado en la fragilidad de la seguridad de muchos dispositivos de la internet para las cosas (IoT) que casi siempre vienencon las mismas claves configuradas por defecto o con escasas características de seguridad (por lo que son fáciles de conocer por alguien interesando). Se puede leer sobre esto en Un ciberataque masivo deja inaccesibles destacadas webs de internet como Twitter o Spotify, Today’s Brutal DDoS Attack Is the Beginning of a Bleak Future, o -más técnico- DDoS on Dyn Impacts Twitter, Spotify, Reddit. Además estos dispositivos no suelen tener mecanimos sencillos de actualización, gestión, etc…

La cosa está mal y ya llevamos una temporada leyendo sobre estos temas. Yo tenia guardado House of Keys: Industry-Wide HTTPS Certificate and SSH Key Reuse Endangers Millions of Devices Worldwide donde se habla de dispositivos para los que se tiene prevista la utilización de criptografía más avanzada (incluyendo certificados digitales). Y son dispositivos de todo tipo. En un análisis de más de 4000 dispositivos de más de 70 fabricantes se encontraron solamente 580 claves únicas, lo que nos indica que hay reutilización de estas claves en diferentes dispositivos (típicamente incluídas en el firmware) e incluso estarían repetidas entre diferentes marcas, simplemente por el hecho de reutilizar entornos de desarrollos y otras herramientas. Si a eso le sumamos que muchos de estos dispositivos están conectados directamente a internet tenemos la receta segura para el desastre.

Software libre en tu empresa, ¿todo tu código es realmente tuyo?

Código Un informe que gustará incluso a los más perezosos: [PDF] OPEN SOURCE SECURITY ANALYSIS The State of Open Source Security in Commercial Applications

Aunque ya hace mucho tiempo que no es cierto, mucha gente sigue creyendo que el software no ha ‘entrado en su vida’. En este informe se habla del tema, en un aspecto en el que probablemente todavía menos gente piensa: el código libre que se ‘cuela’ en nuestras aplicaciones (por comodidad, conveniencia y lo que sea). Se dan algunas cifras como:

  • Black Duck encuentra dependencias o incluso código libre en las aplicaciones corporativas en un 95% de las aplicaciones que analizan.
  • Una aplicación comercial típica incluye un 35% de código libre.
  • Naturalmente, eso incluye las vulnerabilidades que ese código pueda tener.

Los consejos serían:

  • Tener políticas de uso de software libre
  • Hacer seguimiento de ese código y cumplir (y hacer cumplir) las políticas
  • Estar atentos a las vulnerabilidades que puedan provenir de este camino