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.
En Introduction to Cross-Site Leaks (XS-Leaks) – Attacks and Mitigations hay una introducción a este ataque, que sirve para recolectar información acerca de los usuarios, a través de fallos de programación cruzada (Cross-site scripting (XSS)) y la utilización estos fallos para acceder a información como atributos de los usuarios, permisos, papeles (roles). Y también al historia de palabras de búsqueda y otras informaciones que se almacenan en memorias temporales (caches).
XS-Leaks then allow attackers to collect information about website visitors that is usually not available. This information can give the attacker clues about the user’s identity. This can include if the victim is logged into other web applications allowing access to user attributes, permissions, or roles. Additionally, a victim’s keyword search history can be queried as well as privately cached browser objects, such as images, based on how the website caches these resources.
Si vuestros sistemas son tan 'seguros' que se convierten en difíciles o incómodos de usar, la gente utilizará alternativas. Para cosas del trabajo. Aplica especialmente al correo y sistemas de mensajería
Creo que ya lo he dicho aquí pero no me importa repetirme: la ciberseguridad tiene que ir de la mano de la usabilidad (ergonomía, comodidad, facilidad de uso ,…) y de la economía (¿cuánto cuesta? en todos los sentidos, se entiende). Y por ello nombro siempre que puedo Symposium on Usable Privacy and Security (SOUPS) y Workshop on the Economics of Information Security (WEIS). Trato de leer todos los años unos cuantos de los artículos que allí se publican.
Hoy solo hablaremos de la parte de comodidad de uso. La economía queda para otro día.
Both conferences were attended by experts in usability, security, and privacy. Both conferences emphasized that if we ever are to have systems with adequate security and privacy that people are willing to use, then the three fields must work together as a team. Without usable systems, the security and privacy simply disappears as people defeat the processes in order to get their work done.
Muchas veces las recomendaciones de seguridad son arbitrarias, y además los profesionales se las saltan sin demasiados problemas, nos dice:
We are being sent a mixed message: on the one hand, we are continually forced to use arbitrary security procedures. On the other hand, even the professionals ignore many of them.
Necesitamos mejor comprendes los problemas, las herramientas que proporcionamos a los desarrolladores y al resto de personas que interactuarán con los sistemas.
If this endeavor is to be successful, we need more understanding of the issues, better toolkits to deliver to developers, and a comprehensive set of tools, scripts, and templates to provide the administrative support staffs around the world so that the rules and polices they develop will be consistent both with one another and with best practices of the security and privacy community.
¿Es necesario que mejorar la seguridad haga todo más difícil de usar? Cuando sean necesarios pasos adicionales, ¿la gente se quejará?
No necesariamente.
Does added security make things more difficult to use? Will people always resent the extra steps? The answer to both questions is the same: Not necessarily.
Más tarde comenta sobre uno de los fallos de este tipo, relacionado con las contraseñas: mitos, sobreactuación, …
Want a classic example of a failure? Passwords. There are several myths in the world about security, but the most pervasive of these has to do with password security. Look at Northwestern University’s password requirements: an over-reaction to the problem of password discovery through brute-force attacks.
Dice muchas más cosas. Lectura interesante.
Me he autocitado en el tuit de arriba porque el otro día me encontré un caso de una organización que ponía tantas dificultades a sus usuarios para utilizar el correo corporativo que terminábamos comunicándonos con ellos a través de sistemas alternativos de correo.
Eso no es seguridad.
