El análisis de una aplicación (web o no) para detectar problemas de seguridad es una tarea inexcusable que puede llevar una buena cantidad de tiempo. Hay herramientas pero, como siempre, llegan hasta donde llegan y eso puede ser un problema.

En The Blind Spots of Automated Web App Assessments nos hablaban un poco de este asunto y de la importancia de la revisión manual.

This post illustrates the importance of manual code review when doing application security. Relying heavily on automated tools can give you some grim blind spots that pose a significant risk to the application.

Para ello, seleccionan varios fallos habituales y ven cómo se comportan diversos analizadores. El problema fundamental que detecta es que los analalizadores no suelen ser capaces de determinar el contexto ni la lógica de negocio, con lo que algunos fallos pueden pasarse por alto.

The scanners simply can’t do this. All of these rules are application logic which is laws defined by the programmer. One application might have a friend invitation system where you actually are allowed to view other users profiles. Another is a private application where you are only supposed to see your own profile. How does the scanner distinguish between these rules that are man made on a project-to-project basis?

Sin embargo, esto no es una llamada a dejar de usar ese tipo de herramientas, sino a ser conscientes de sus limitaciones.

We’re not here to tell you to stop using automated tools. They’re great for the job, but you should use them with an understanding of what might be missed if you don’t couple them with manual assessments by a vetted application security professional.

Interesante.

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.

El resultado con nuestra semilla sería: 23 –> 20 –> 02 –> 12 –> 13 –> 19 –> 55 –> 35 –> …

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.

Para repasar.

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.

Muy interesante.

En “EtherHiding” — Hiding Web2 Malicious Code in Web3 Smart Contracts nos cuentan cómo se puede difundir contenido malicioso a través de contatos inteligentes (smart contracts).

“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.

Tiempos emocionantes.