Hace unos meses podíamos leer Staying ahead of threat actors in the age of AI que me gustó porque nos da algunas pistas de algunos de los aspectos peligrosos de la inteligencia artificial, desde el punto de vista de la seguridad informática.

Proporcionan una lista de diversas organizaciones que aparecen frecuentemente en diversos ataques y los usos que han observado de la inteligencia artificial para estos fines. No entraremos en esos detalles (aunque puede ser interesante echar un ojo) sino que nos centraremos en el final del artículo, donde se hace un resumen.

• Reconocimiento (LLM-informed reconnaissance): esto es, obtener información sobre tecnologías y vulnerabilidades.
• Mejora de los programas (LLM-enhanced scripting techniques): se pueden utilizar los modelos de lenguaje grandes para generar programas o mejorar los que ya tenemos.
• Desarrollo asistido de programas (LLM-aided development:): parecido al anterior, pero ya integrado en el ciclo de vida de nuestros desarrollos.
• Ingeniería social mejorada (LLM-supported social engineering): se puede usar para mejorar las traducciones y los mensajes que se utilizan para manipular a los objetivos.
• Investigación de vulnerabilidades asistida (LLM-assisted vulnerability research): utilizar estos sistemas para comprender mejor las vulnerabilidades en los programas y en los sistemas.
• Optimización del desarrollo de payloads (LLM-optimized payload crafting): seguimos con ideas parecidas, cuando necesitamos generar o mejorar algún trozo de código que utilizaremos en un ataque.
• Evasión mejorada de los sistemas de detección de anomalías (LLM-enhanced anomaly detection evasion): ayuda para tratar de hacer pasar nuestros ataques dentro de la actividad normal de nuestro objetivo.
• Saltar las características de seguridad (LLM-directed security feature bypass): ayuda en la búsqueda de formas de evitar los mecanismos de seguridad (doble factor, CAPTCHAS, …)
• Recomendaciones en el desarrollo de recursos (LLM-advised resource development:): no sólo desarrollo de herramientas, sino también modificación e incluso planificación estratégica.

Interesante.

Soy un usuario bastante básico de WordPress: algún sitio de los que ofrecen gratis y alguno más de los que nos proporcionan en el trabajo para diversos asuntos. Pero los fallos de seguridad siempre son interesantes, porque casi siempre se pueden extraer conclusiones y enseñanzas para nuestro contexto. Incluso cuando no sea el mismo.

Por eso hoy traemos The Real Attack Vector Responsible for 60% of Hacked WordPress Sites in 2023 donde se habla de los plugins desactualizados como punto principal de los ataques a sitios de WordPress.

A particularly pervasive one is the unsubstantiated claim that “95% of WordPress hacks are due to outdated plugins or themes.“

Esencialmente, alguien contrata la realización de su web, se la hacen con esta tecnología y luego vienen los problemas: o no se contrata el mantenimiento, o éste es deficienten….

Luego entra en detalles sobre el tipo de problemas que suelen ocurrir:

• Fallos en la autentificación

Authentication Compromise (stolen session cookies + compromised credentials) and

Los robos de cookies tienen que ver algunas veces con el acceso local con algún tipo de sistema de robo.

Los robos de usuarios y contraseñas se pueden producir de formas similares, y también son frecuentes.

• Fallos en los plugins, los ‘temas’ y las funcionalidades básicas.

Plugin, Theme & Core vulnerabilities

En este caso, cuando aparecen vulnerabilildades está bastante claro que después aparecerán los ataques.

Meaning, we can clearly tie the presence of a vulnerability to a potential exploit of the vulnerability.

Los consejos: desconectarse del sitio cuando terminsmos, logout, para evitar el robo de sesiones, utilizar doble factor de autentificación, actualizarlo todo cuando toca…

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.