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.

Otro tema que sigue apareciendo de vez en cuando por aquí: tenemos muchos datos que a veces queremos compartir para análisis estadísticos y de otro tipo. El problema: la privacidad. En How do you anonymize personal databases and protect people’s privacy – over to you, NIST comentan sobre la guía de US National Institute of Standards and Technology (NIST), que se puede ver en [PDF] De - Identi fi cation of Personal Information.

Se trata de un documento en fase de comentarios y revisión con algunas lecciones interesantes:

• El balance entre proporcionar información útil y privacidad no es fácil.

• Hay mucho trabajo, y debe hacerse

Además, como se podía esperar, la privacidad de los famosos todavía es más complicada de proteger.

Para proteger los datos se pueden utilizar métodos sobre los propios datos, o sobre la forma de proporcionarlos.

Se pueden ver comentarios anteriores sobre anonimización y des-anonimización, por ejemplo en Sobre re-identificación de datos anónimos y seguir los enlaces, porque no es este el primer informe sobre el tema que recomendamos.

Este tema aparece por aquí de vez en cuando: en este caso, desde el punto de vista del atacado ¿son las empresas responsables de los ataques que sufren?. En 90% of directors believe regulators should hold firms liable for hacks dicen que sí.

El matiz es que se haya prestado la debida atención (‘due care’) o no:

Nine out of 10 of those surveyed believe regulators such as the FTC should hold businesses liable for cyber breaches if due care has not been followed

También es cierto que se trata de responsables concienciados, que están tomando medidas o piensan tomarlas próximamente:

While 94 percent of respondents have increased or are planning to increase their security assessments to address liability concerns, two-thirds of respondents say they have also begun or are planning to insert liability clauses into contracts with their third-party providers.

La última vez que hablamos de este tema fue en Seguridad y aseguradoras