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.

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.