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.

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.

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.

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

Aunque este tipo de artículos son algo técnicos, me gustó leer An Example of Common String and Payload Obfuscation Techniques in Malware que utiliza tácticas diferentes para saltarse las posibles protecciones: una lista de programas que se pueden utilizar en el análisis dinámico, cifrado de cadenas de texto para que no sea fácil encontrarlas y comunicación cifrada con el centro de control (command & control). Todo ello sin utilizar técnicas muy sofisticadas pero de eficacia suficiente.

También nos viene bien a nosotros porque es fácil de seguir y comprender los trucos que utilizan los malos a veces.