Es frecuente criticar a los usuarios por caer en las trampas más burdas y perjudicar la seguridad de la organización. Sin embargo, cualquier experimento que se haga muestra que los usuarios (de los más diversos perfiles) caen. Así que algo tendremos que hacer los técnicos para evitarlo.

En Here’s How Easy It Is to Get Trump Officials to Click on a Fake Link in Email hablan de un experimento contra políticos de perfil alto:

So, three weeks ago, Gizmodo Media Group’s Special Projects Desk launched a security preparedness test directed at Giuliani and 14 other people associated with the Trump Administration. We sent them an email that mimicked an invitation to view a spreadsheet in Google Docs.

¿Qué sucedió?

Algunos ignoraron el correo (decisión correcta), pero más de la mitad pincharon en el enlace, algunos varias veces:

Some of the Trump Administration people completely ignored our email, the right move. But it appears that more than half the recipients clicked the link: Eight different unique devices visited the site, one of them multiple times.

Aparentemente nadie introdujo datos (pero había avisos) y ya sabemos que el solo hecho de pinchar puede ser problemático. Un par de personas preguntaron para no pinchar sin saber (bien).

Curioso.

Lo leí en algún libro (creo que en el de John Viega y Gary McGraw, ‘Building Secure Software’). Allí se decía que no sólo no se enseñaba el tema del desarrollo seguro sino que, además, los ejemplos que se podían ver en los libros de programación (en aquella época libros, fundamentalmente) eran de dudosa calidad desde el punto de vista de la seguridad. También se discutía (creo) sobre los ejemplos y sobre los ficheros de configuración. Desde entonces es un tema que suelo comentar (lo hice, por ejemplo, en la charla del otro día Una charla sobre seguridad en aplicaciones web: principios y más. Casi 20 años después seguimos igual: en Top-ranked programming Web tutorials introduce vulnerabilities into software nos dicen algo muy similar. Los tutoriales más importantes de desarrollo web incluyen ejemplos y soluciones vulnerables.

La forma de obtener el dato es curiosa: navegan por el repositorio GitHub y encuentran vulnerabilidades que pueden encontrarse en algunos textos introductorios disponibles por ahí.

Researchers from several German universities have checked the PHP codebases of over 64,000 projects on GitHub, and found 117 vulnerabilities that they believe have been introduced through the use of code from popular but insufficiently reviewed tutorials.

Utilizan la búsqueda en el repositorio de patrones bien conocidos de fallo, que se pueden encontrar en los tutoriales. Y encuentran problemas, claro:

Thanks to our framework, we have uncovered over 100 vulnerabilities in web application code that bear a strong resemblance to vulnerable code patterns found in popular tutorials. More alarmingly, we have confirmed that 8 instances of a SQLi vulnerability present in different web applications are an outcome of code copied from a single vulnerable tutorial,” they noted. “Our results indicate that there is a substantial, if not causal, link between insecure tutorials and web application > vulnerabilities.”

Casi nada. En un caso concreto 8 ejemplos de un fallo que proviene de uno de estos tutoriales.

Proporcionan sus herramientas GithubSpider para hacer las búsquedas, y ccdetection para hacer la detección de código similar.

Si haces cursos y tutoriales, o si ya tienes algunos publicados, tienes una responsabilidad.

También tengo que decir que hace años propuse algo así (cuando pensábamos en temas de propagación de información) relacionado con la propagación de errores en los programas a través de ejemplos, copia, etc. en una presentación que nunca llegué a publicar, así que pueden creerme o no sobre el tema.

El otro día mi amigo Gabriel del Molino (@gmolino) me invitó a dar una charla a sus alumnos de un curso de formación para desempleados donde reciben una panorámica de desarrollo web. La propuesta era abierta pero estaban especialmente interesados en temas de seguridad.

Como se trataba de una sesión única y no era plan de entrar en detalles técnicospreferí presentar algunos principios y completarlo con una introducción motivadora, algunas ideas sobre identificación y autentificación y, finalmente, recordar que nuestro trabajo casi siempre tiene que ver con la economía y con las personas.

Dejo aquí la presentación por si a alguien puede servirle de algo.

Se habla con mucha frecuencia de la autentificación, y de los diversos sistemas disponibles, pero no hay que olvidar que si queremos estar seguros no podemos confiar sólo en ellos. Cada vez más tenemos que utilizar la información adicional de la que dispongamos para estar seguros de que el usuario es quién dice ser.o

En Trust, but Verify: Authentication Without Validation Is Naïve daban algunas ideas sobre ello.

Primero, alguna paradoja: es más probable que las preguntas de seguridad las responda adecuadamente un atacante que el legítimo propietario de la cuenta:

Gartner research, however, found that users fail to answer their knowledge-based questions 15–30 percent of the time, while fraudsters answer correctly 60 percent of the time. Malicious actors often find this information on social networks or through phishing schemes.

Si confiamos en dispositivos como los teléfonos para la validación también nos podemos encontrar problemas:

his practice has shifted to mobile phones, with OTPs being sent as text messages. However, mobile malware can intercept these messages and forward them to fraudsters.

Y, desde luego, la biometría también tiene sus problemas:

… which has led to the exponential growth of fingerprint reader-enabled devices. It didn’t take long, however, for cybercriminals to circumvent this technology

¿Entonces? Como decíamos, hay que ser capaces de utilizar la información extra de la que dispongamos. Por ejemplo, sobre el comportamiento, y otros identificadores.

Parece que el tema de la generación informática de números aleatorios ha ganado interés en los últimos años. Hoy lo decimos por el contenido de A Brief History of Random Numbers donde se habla del tema desde una perspectiva histórica: la aleatoriedad es algo muy abundante en la naturaleza, pero no es sencilla de obtener con herramientas humanas:

The randomness so beautifully and abundantly generated by nature has not always been easy for us humans to extract and quantify.

Los primeros intentos informáticos parecen datar de los años 40, de la mano de RAND Corporation:

… the modern world demanded a lot more random numbers than dice or yarrow stalks could offer. RAND Corporation created a machine that would generate numbers using a random pulse generator.

Posteriormente hubo algunos intentos más, hasta que surgió la idea de los generadores de números seudoaleatorios (pseudorandom number generator, PRNG). Se comentan algunas de las aproximaciones algorimicas y también curiosidades como LavaRand, diseñado por Silicon Graphics, y basado en un par de lámaras de lava y una cámara tomando imágenes. Por cierto, el método sigue vigente, según nos contaban en 10% of the Internet Is Encrypted with Lava Lamps, hablando del proveedor Cloudflare.

También se comenta sobre iniciativas como los servicios proveedores de números aleatorios, como Random.org y cómo, finalmente, Intel añadió en 1999 un generador en su chipset i810 para servidores, basado en el ruido térmico de los procesadores:

In 1999, Intel added an on-chip random number generator to its i810 server chipset. Finally, new servers had a good local source of randomness from thermal noise — a true random number generator (TRNG).

Sin embargo, no hay que olvidar que no sólo necesitamos números aleatorios, sino que los necesitamos a velocidad adecuada; y no sólo necesitamos números seudoaleatorios, sino que necesitamos números seudoaleatorios seguros (Aleatoriedad y juego en línea. No sólo para juegos, claro).

Finalmente, se habla (habiendo pasaro por otros temas) de las discusiones sobre qué esquemas de generación utilizar, cuando hablamos de programas con la seguridad en mente, o simplemente de otros usos menos comprometidos.