Entre lo poco que escribimos aquí y que hacía ya algún tiempo que no nos encontrábamos una lectura interesante ha pasado tiempo desde la última vez que hablamos de generadores de números aleatorios.
En An RNG that runs in your brain encontré un generador ‘sencillo’ e interesante. No sería válido para aspectos criptográficos y de seguridad, pero nos puede ayudar a comprender mejor el concepto. El proceso es:
Elegir un número de 2 cifras, por ejemplo 23, la ‘semilla’
Generar un nuevo número de dos cifras a partir del primero: a las decenas les sumamos 6 veces las unidades.
su periodo es el orden del multiplicador, 6, en el grupo de los residuos primos relativos al módulo, 10. (59 en este caso).
Los “dígitos aleatorios” son las cifras unidad de los números de dos cifras, esto es: 3,0,2,2,3,9,5,… la secuencia módulo 10.
La pregunta ahora es, ¿cómo de buenos son los números generados de esta forma?, y el autor nos muestra algo de la teoría (y algunas pruebas) que hay detrás del métido.
Y la siguiente, ¿con qué semillas y otras combinaciones de números funcionaría?
No vamos a entrar en ello, pero me gustó porque me parece un ejercicio sencillo (pero no trivial) de programación, que además nos ayuda a pensar un poco en los temas relacionados con la aleatoriedad en los sistemas informáticos.
No conozco suficientemente bien Flask, pero en Best practices to protect your Flask applications nos hablan de cómo proteger aplicaciones desarrolladas con este entorno de trabajo (framework) y me quedo con la idea de que vale la pena guardarlo por si acaso. Y aprovechar las ideas obtenidas con su lectura en otros contextos.
Habla del OWASP Top 10, y de cómo algunas de las características básicas de seguridad ya están incluidas:
Basic security practices are fundamental for Flask, such as employing strong cryptographic hashes for password storage, implementing protections against Cross-Site Request Forgery (CSRF) and Cross-Origin Resource Sharing (CORS), and protecting against SQL injection attacks.
Pero siempre hay que ir más allá, y se preocupa de temas como el uso de paquetes externos (no lo he dicho antes, Flask es un entorno para el lenguaje Python), aseguramiento de los formularios, validación en el servidor (en el cliente ayuda, pero no es ‘la buena’), algunos mecanismos disponibles contra el cross site scripting, XSS y el cross site request forgery, CSRF, y temas de más actualidad como la protección de APIs.
En Operation Triangulation: The last (hardware) mystery una lectura intensa (es posible que hasta se nos escapen algunos detalles) pero que nos da una idea de lo sofisticados que pueden llegar a ser los ataques, a pesar de las defensas que se puedan poner para atenuarlos.
What we do know—and what this vulnerability demonstrates—is that advanced hardware-based protections are useless in the face of a sophisticated attacker as long as there are hardware features that can bypass those protections.
También como la ‘seguridad por la oscuridad’ no suele terminar bien. Es frecuente encontrarla en las aproximaciones basadas en la parte física (hardware).
Hardware security very often relies on “security through obscurity”, and it is much more difficult to reverse-engineer than software, but this is a flawed approach, because sooner or later, all secrets are revealed. Systems that rely on “security through obscurity” can never be truly secure.
“EtherHiding” presents a novel twist on serving malicious code by utilizing Binance’s Smart Chain contracts to host parts of a malicious code chain in what is the next level of Bullet-Proof Hosting.
La idea se basa en atacar un sitio cualquiera, con un mensaje que nos invite a actualizar el navegador para acceder a la información. Una vez hecho esto, tenemos instalado un programa malicioso de los que roban información…
In the attack flow, a site is defaced with a very believable overlay demanding a browser update before the site can be accessed. The fake “update” turns out to be vicious infostealer malware like RedLine, Amadey, or Lumma.
Pero la cosa va más allá, puesto que los atacantes alojan su código malicioso de manera anónima y sin limitaciones, mediante cadenas de bloques.
Yet, in this evolution of “ClearFake”, we see that threat actors have introduced a novel method of hosting malicious code both anonymously and without any limitations — a real “Bullet Proof” hosting facilitated by the Blockchain.
El código malicioos crea un contrato, con una dirección de la cadena de bloques concreta e incluye una solicitud de código, que es lo que se utilizar para transferir los programas dañinos, get(), y ejecutarlos, eval().
Yet, in this evolution of “ClearFake”, we see that threat actors have introduced a novel method of hosting malicious code both anonymously and without any limitations — a real “Bullet Proof” hosting facilitated by the Blockchain.
De esta forma el código malicioso se aloja y se proporciona de forma imposible de bloquear.
This is what we see here in this attack — malicious code is hosted and served in a manner that can’t be blocked. Unlike hosting it on a Cloudflare Worker service as was mitigated on the earlier variant. Truly, it is a double-edged sword in decentralized tech.
La cosa, nos dicen, no tiene porque terminar allí echándole imaginación a nuevos usos que permiten las cadenas de bloques, desde propagación de programas maliciosos a obtención de datos o credenciales y ficheros, eludiendo los métodos tradicionales de los sistemas de protección de las fuerzas y cuerpos de seguridad o de los jueces, que permiten apagar fácilmente los proveedores de alojamiento en caso de que estén siendo dañinos.
Beyond this specific exploit, blockchain can be misused in myriad ways, from malware propagation stages to data exfiltration of stolen credentials and files, all eluding traditional law enforcement shutdown methods.
@fernand0 de @unizar ‼️“separar, aislar y pensar que las cosas han fallado, fallan y fallarán” 👉“Copias de #seguridad automáticas, estrategias adecuadas como el 3,2,1 y si no has comprobado nunca tu copia de seguridad, hazlo” ‼️" No protegemos los equipos, protegemos el negocio” pic.twitter.com/MlQdrMjYu6
— Ingenieros Industriales-Aragón y La Rioja (@COIIAR) March 14, 2024
El 14 de marzo se celebró el Congreso Industria 4.0, organizado por el Colegio de Ingenieros Industriales de Aragón y La Rioja y el Colegio de Ingenieros de Telecomunicaciones de Aragón.
Mis compañeros José Ángel Castellanos Gómez y Ángel Fernández Cuello, como directores de la Cátedra de Transformación Industrial colaboraban con el congreso y me invitaron a hablar de seguridad. Les propuse hablar de ciberseguridad industrial con algunos ejemplos que podrían permitirnos sacar algunas conclusiones y algunas recomendaciones y allí estuvimos.
Hablamos de tres ejemplos lejanos (en tiempo y en distancia algunos, otros sólo en distancia):
El caso de STUXNET (2010)
El ataque a las centrales energéticas de Ukrania (2015)
El ataque a SolarWinds (2019-2020)
Todos ellos en instalaciones más o menos protegidas, más o menos lejanos, pero con aparatos, tecnología y herramientas muy parecidas a las que puede haber en cualquier fábrica de nuestro entorno.
Sobre el último ataque, además se puede comentar la introducción por parte de la Presidencia de EEUU de la (Software Bill of Materials, SBOM) como una manera de, por lo menos, conocer qué problemas podemos tener ante un ataque a la cadena de suministro.
También aprovechamos para contar que todo esto ahora es un negocio, existe un mercado donde se compran y se venden las herramientas para realizar los ataques, las vulnerabilidades, … y cómo las personas somos el eslabón débil y lo fácil que es engañarnos o hacernos reaccionar en beneficio de los atacantes.
Aprovechamos para comentar un par de artículos uno de los cuales ya lo habíamos comentado en El phishing: los usuarios lo tienen realmente difícil que dicen justamente eso: es difícil para un usuario normal detectar todos los posibles fraudes que le pueden llegar.
Luego comentamos algunos ataques que están vigentes y que son especialmente en el contexto del que hablábamos: botnets con dispositivos poco vigilados, secuestro de información (RansomWare) y, ya en el contexto más de la oficina, la sustitución de facturas (que parece que es un ataque que se está produciendo bastante últimamente).
Finalmente, tres recomendaciones:
Conocer y hacer mapas de nuestro entorno, para ver qué hay en nuestras redes.
Compartimentalizar y segmentar, para que los fallos que pueda haber en algún sito no afecten a todos nuetros sistemas.
Estar preparados para lo peor, haciendo copias de seguridad (y conocerlas, y comprobarlas,…).
Terminamos con una brevísima mención a que hay leyes (y que seguramente habrá más).
Un rato muy agradable en el que pudimos hablar de cosas que nos gustan en un entorno en el que creo que fueron bien recibidas.
