Seguir la corriente resolviendo problemas y la seguridad

Seguir la corriente Ya hace años que es una queja frecuente en el mundillo de la seguridad: cuando te enseñan a programar, no sólo no te enseñan seguridad sino que los ejemplos que te muestran son en muchos casos una muestra de lo que no debe hacerse si te preocupa la seguridad.

Ya pasaba en los libros pero ahora hay un estudio sobre el mismo tema con los ejemplos en foros bien reconocidos de programadores. Nos lo contaban en Try Catch Stack Overflow y hablan de un estudio ([PDF] Secure Coding Practices in Java: Challenges and Vulnerabilities) donde han analizado la calidad del código que podemos encontrar en el conocido sitio StackOverflow y otros similares donde se reproduce el mismo patrón. Algunas respuestas populares y bien calificadas contienen vulnerabilidades desde el punto de vista de la seguridad.

Basado en el estudio sobre las preguntas y respuestas dadas en torno al lenguaje y plataforma Java, los investigadores han encontrado multitud de errores en respuestas populares que contienen vulnerabilidades de seguridad. El problema, señalan, no se encuentra en las librerías usadas –que no deja de ser reutilización legítima de código-, sino en que estas no se usan de forma segura, dando lugar a la exposición de riesgo por falta de pericia en su uso.

Naturalmente, no es una crítica al sitio, que es un recurso maravilloso cuando uno no sabe muy bien cómo avanzar. Pero debemos mantener el espíritu crítico y no seguir los consejos ciegamente, porque tendremos problemas.

La gestión de secretos: más cerca y más lejos de lo que crees

Escondido Por el motivo que sea, todos creemos que podemos esconder algo de manera más o menos eficaz en un sistema informático: bien porque creemos que no es tan importante y nadie lo buscará, bien porque pensamos que los que lo buscarán no son tan listos como para seguir nuestra línea de pensamieno. A veces también porque no nos damos cuenta de lo que tiene que ser (o directamente es) secreto. Y, claro, nos equivocamos.

Por eso es interesante leer Secrets Management: New Series. La serie se compone de tres capítulos:

Aquí se hace una panorámica por los accesos a diferentes APIs y la gestión de claves de acceso, los servicios automáticos, la automatización en el desarrollo (compilación, prueba, …), los datos cifrados y la información compartida.

Aquí se habla del almacenamiento de los secretos, la gestión de identidad y de accesos, los propios acceso y el uso y nuevamente la información compartida (en este caso, los propios secretos).

En el despliegue, hay que tener en cuenta si hablamos de servidores aislados, o arquitecturas cliente-servidor y, por supuesto, los temas de integración.

La aleatoriedad y algunas ayudas de la física

Lava de la de verdad Ya hemos hablado unas cuantas veces de la necesidad de números aleatorios en lostemas relacionados con la aleatoriedad. Fundamentalmente se obtienen mediante algoritmos, con la prevención de seleccinar las semillas de fuentes aleatorias (entropía obtenida alrededor de la actividad del computador). También se venden tarjetas criptográficas que incluyen algún tipo de generador de números aleatorios.

Por eso fue una noticia curiosa de leer la de que 10% of the Internet Is Encrypted with Lava Lamps. Esto es, uno de los proveedores más grandes de internet (Cloudfare), que necesita generar una buena cantidad de números aleatorios recurre a la vieja física del mundo real y a las lámparas de lava. En este caso la dinámica de fluidos (difícil de modelizar y predecir) juega a nuestro favor.

Según nos contaban en The Hardest Working Office Design In America Encrypts Your Data–With Lava Lamps Cloudfare tendría un muro lleno de lámparas de este tipo:

Inspired by an idea from engineers at Sun Microsystems, who thought that lava lamps could help generate randomness since modeling how fluid moves within the lamps is incredibly difficult, Prince decided to create an entire wall of lava lamps. Cloudflare calls it the “Wall of Entropy.”

Fotografían el muro cada milisegundo y mediante un sistema de análisis de la imagen utilizan ciertos parámetros para la generación de los números aleatorios. Esta información se añadiría a los otros sistemas que utilizan (al final, una fotografía cada milisegundo no es mucho, para lo que pueden llegar a necesitar).

Curioso.

Programas de línea de instrucciones y algunos consejos de seguridad

Teclados ¿Cuánto hacía que no oían hablar de los programas de línea de instrucciones? Yo reconozco que mucho. No quiere decir que no los use, porque a veces uno puede resolver un problema más o menos complejo con unas cuantes instrucciones adecuadamente empaquetadas. Pero no es un tema de actualidad en las páginas de referencia ni en las de noticias.

Y estando en eso, nos encontramos con A Production Quality Shell Script que habla justamente del tema. Desde la selección del intérprete (shell), pasando por la sintaxis, el uso de ficheros temporales y las implicaciones de seguridad, tan frecuentemente olvidadas.

Un recordatorio interesante.

El uso de algoritmos evolutivos en Facebook para buscar fallos

Fallo Hace mucho que no hablamos de algoritmos evolutivos y su utilización para buscar fallos. En Facebook’s evolutionary search for crashing software bugs nos contaban como utilizan en Facebook estas ideas.

Cuando hacemos análisis de software hay fundamentalmente dos aproximaciones: análisis estático (recorremos el código buscando indicios de que algo puede ir mal) o dinámico (ejecutamos el programa con entradas diversas y vemos si falla).

En este segundo caso, el problema es encontrar entradas adecuadas. Ya hemos hablado del fuzzing (entradas aleatorias, para encontrar respuestas inesperadas o no suficientemente planificadas). Pero si estamos interesados en buscar fallos (y no simplemente esperar a ver si aparecen con pruebas aleatorias) puede ser interesante hacer pruebas con más ‘intención’.

There are a lot of dynamic analysers out there, but none like Sapienz, according to Facebook. The biggest problem with dynamic testing is finding the right inputs that cause an app to crash.

Y aquí entran en juego los algoritmos evolutivos: orientar la búsqueda con parámetros adecuados para probar lo que nos pueda interesar más, que es encontrar fallos en el programa.

Como tiene que ser, el proyecto tiene información en Sapienz: Intelligent automated software testing at scale y no dan muchos detalles, pero cuentan como el sistema es capaz de determinar entradas adecuadas para encontrar posibles fallos.

Sapienz samples the space of all possible tests, using intelligent computational search and an approach called search-based software testing. An important design principle is that Sapienz tests through the UI, so issues Sapienz reports to engineers can be found through the UI. This avoids the false positives that bedevil many test design approaches, but it makes it more challenging to provide guidance to the computational search.

Los algoritmos evolutivos, me permito recordar, nos permiten explorar espacios de búsqueda favoreciendo algunos tipos concretos de soluciones con un grado de efectividad bastante alto.

El uso de las cabeceras de los sitios web populares para aprender de seguridad

Navegación No es la primera vez que traemos un caso similar. En Analysis of the Alexa Top 1M sites la gente de Mozilla nos contaba cómo habían examinado las cabeceras de seguridad del primer millón de sitios más importantes según Alexa y los resultados son esclarecedores. Los sitios van mejorando, aunque la mayoría de las cabeceras tienen un uso puramente testimonial.

Habrá a quien le tranquilice esto: ‘ellos tampoco las usan’. Sin embargo, y tratando de sacar partido de la información, el visitante menos acostumbrado podrá sacar partido de la lista de cabeceras examinada que, además de servirle para el descubrimiento de nuevas fuentes de preocupaciones, le ayudará a pensar en la configuración de su próximo proyecto.

Interesante.

El uso de identificadores en protocolos, la seguridad y la privacidad

Números 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.

Secretos compartidos. Cuidado con la confianza.

Oculto 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.

Phishing y políticos de alto nivel

Pescando 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.

Aprender a programar con fallos de seguridad

En la pizarra 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.