Ya hace tiempo que no hablamos de aleatoriedad. En este caso vamos un paso más allá y traemos este ‘draft’ sobre las consecuencias de tener determinados identificadores en algunos protocolos: Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols.

La mayoría de los problemas han tenido que ver, tradicionalmente, con la predicibilidad tanto en números de secuencia, como en otros identificadores necesarioes en los protocolos.

En este momento va por la versión tercera y se analizan algunos algoritmos frecuentes de generación de estos identificadores (Sección 8), con los problemas de unicidad, predictibilidad. También las vulnerabilidades frecuentes (Sección 9).

Estos identificadores utilizados en protocolos deberían:

• Estar bien identificadas las cuestiones relacionadas con la interoperabilidad.
• Proporcioncionarse un análisis desde el punto de vista de seguridad y privacidad
• Recomendar algoritmos que mitiguen los problemas indentificados.

Un tema que no siempre se tiene presente y que tiene su importancia.

Lo miremos como lo miremos, somos gente confiada. Queremos compartir y lo hacemos con pocas precauciones. O esa es la conclusión habitual, que ya no nos sorprende mucho. En Keys, tokens and too much trust found in container images hablaban del tema relacinado con la compartición de contenedores.

Comprobaron las 1000 imágenes de contenedores más populares para ver qué encontraban por ahí y encontraron que al menos el 67% de las imágenes contenían, al menos, un secreto:

To get a taste of the prevalence of such secrets, we scanned the top 1,000 most popular container images found on public registries. We were not only looking for default passwords, but mostly for less obvious examples of secrets. We selected only the latest images, from the top starred public repositories. What we found convinced us that the risk is very real, as 67% of images had at least one form of a secret.

Tokens de acceso, certificados, máquinas no confiables aceptadas como si lo fueran, ficheros de autorización de contraseñas (authorized_keys), etc.

Compartir es bueno. Pero hay que hacerlo con cuidado.

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.