¿Depende tu sistema de programas vulnerables?

¡Oh! ¡Qué bonito! Cada vez vivimos un mundo más cómodo en informática: ya no hay que descargarse un código fuente y seguir las instrucciones de compilación e instalación sino que cada vez el modelo ‘tienda’ se extiende más y todo se basa en sistemas que nos evitan este trabajo. Hace algún tiempo hablábamos de Los nombres y la seguridad. El caso de Python y PyPi donde el caso se daba en un conocido sitio de descarga de módulos en Python y ahora podemos hablar de Small world with high risks: a study of security threats in the npm ecosystem. En este caso se habla de las dependencias entre distintos paquetes y cómo eso puede hacer problemáticos un montón de desarrollos.

Nos hablan de un estudio sobre ‘npm’ (el sistema de paquetes para JavaScript) donde podemos ver el grafo de paquetes y sus mantenedores a lo largo del tiempo.

This is a fascinating study of the npm ecosystem, looking at the graph of maintainers and packages and its evolution over time.

Un gran poder, una gran responsabilidad. Esto es, se habla de las cosas malas que pueden pasar cuando dependemos de un ecosistema que se mueve demasiado rápido.

… the high risks involved in depending on a open and fast-moving ecosystem.

Con algunos paquetes como dependencias de … demasiados paquetes.

Looking at this in the other direction, we can consider the package reach of a package as the number of other packages that directly or indirectly include it. In other words, if a given target package is compromised, how big is the blast radius? The average blast radius for a package has also been growing over time

¿Y cuando hay problemas de seguridad? Pues se heredan, claro Se estima que hasta un 40% de paquetes podrían depender de paquetes vulnerables.

Just looking at known published vulnerabilities, the authors estimate that up to 40% of all packages rely code known to be vulnerable

No hay que olvidar que uno de los consejos de seguridad que se dan habitualmente es comprobar las dependencias de nuestros productos OWASP Dependency-Check. Porque ya lo decían en el Top 10 de OWASP en 2013. El A-9 era utilizar componentes con vulnerabilidades conocidas.

A9-Using Components with Known Vulnerabilities

Hay que estar atentos.

Aleatoriedad y bloqueos en el kernel de Linux

 La suerte (?) En esta ocasión traemos una entrada un poco técnica que habla de aleatoriedad. Se trata de Really fixing getrandom() y habla de las herramientas disponibles en el núcleo de Linux para generar aleatoriedad.

Es un tema que parece que se ha discutido con amplitud:

The final days of the 5.3 kernel development cycle included an extensive discussion of the getrandom() API and the reversion of an ext4 improvement that was indirectly causing boot hangs due to a lack of entropy.

Y los problemas venían del bloqueo de getrandom() cuando en el sistema no había entropía suficiente:

The root of the problem in 5.3 was the blocking behavior of getrandom(), which will prevent a caller from proceeding until enough entropy has been collected to initialize the random-number generator.

No son cambios que se puedan hacer de cualquier forma, porque hay sistemas que confían en que estas funciones se comporten adecuadamente:

This behavior was subjected to a fair amount of criticism, and few felt the need to defend it. But changing getrandom() is not easy; any changes that might cause it to return predictable “random” numbers risks creating vulnerabilities in any number of security-sensitive applications.

Para evitar este bloqueo, se proponía asegurarse de que habría suficiente entropía para evitar los bloqueos.

There is another way to ensure that getrandom() doesn’t block during the bootstrap process: collect enough entropy to ensure that the random-number generator is fully initialized by the time that somebody needs it.

Una posibilidad era utilizar los mecanismos de la CPU cuando estuvieran disponibles:

If the CPU has a hardware random-number generator, that can be used; some people distrust this solution, but mixing entropy from the hardware with other sources is considered to be safe by most, even if the hardware generator is somehow suspect.

Aunque esto no siempre es posible.

También se podría emplear una función que lee valores del contador de tiempos:

On most architectures, random_get_entropy() just reads the timestamp counter (TSC) directly. The TSC increments for every clock cycle, so two subsequent calls should always return different values. Just how different they will be, though, is where the unpredictability comes in.

Y luego añadir un temporizador que expire los valores, de forma que todo sea un poco más complejo y, por lo tanto, menos predecible:

The timer declared above is armed to expire in the near future (the next “jiffy”, which be anytime between 0ms and 10ms); that expiration will happen by way of an interrupt and may occur on a different CPU.

Se calcula que esto añade un bit de entropía en cada expiración:

In other words, every time the timer expires, the entropy pool is deemed to have gained one bit of entropy.

Si el sistema espera al arrancar podría provocar pausas apreciables:

… potentially just over one second on a system with a 100HZ tick frequency — if the system in question has no other sources of entropy. That could result in a perceivable pause during the boot process, but it is far better than blocking outright.

En definitiva, un artículo que se siguen bien para un problema interesante al que no siempre prestamos la debida atención. o

Posteriormente se ha publicado Removing the Linux /dev/random blocking pool continuando con el debate, aunque en términos ya menos técnicos.

Scrapping con Google Sheets. Obteniendo información de la web

 Araña Entre las múltiples utilidades de GoogleSheets que uno no esperaba encontrar está la del scraping (¿’arañado’?; se trata de descargarse una página web y extraer la información que nos interese de allí. Hay muchas herramientas pero para algunas cosas pueden bastarnos lo consejos que aparecen en Web Scraping with Google Sheets: The Definitive Guide.

Esencialmente nos da pistas para manejar tablas, listas, información en XML y alguna cosilla más. Todo ello sin demasiado esfuerzo.

¿Puedo tener problemas de seguridad utilizando Python? Puedo tener problemas de seguridad utilizando Python

Serpiente No se suele hablar mucho de la seguridad en los lenguajes que se consideran más o menos seguros. Nada hay como el C y otros para meter la pata y tener problemas; pero eso no impide que tengamos que tener en cuenta algunas cosas y de eso hablaban en 10 common security gotchas in Python and how to avoid them.

Empieza hablando de que cuando aprendemos a programar aprendemos cómo se supone que debe usarse un lenguaje o lo que sea; sin embargo, cuando hablamos de seguridad tenemos que cambiar a pensar en cómo podría ser usado para conseguir algo malo.

… you learn how it supposed to be used. When thinking about security, you need to think about how it can be misused

Y, claro, aunque hablemos de lenguajes seguros, algunas cosas malas siguen siendo posibles. La lista:

  • Inyección de entrada
  • Problemas al analizar XML
  • Instrucciones ‘assert’
  • Ataques basados en el tiempo
  • Paquetes maliciosos o el lugar desde donde se importan
  • Ficheros temporales
  • Problemas al cargar ficheros YAML
  • Datos serializado
  • Problemas del entorno Python por no estar actualizado
  • Problemas por no tener actualizadas las dependencias

Como puede verse, algunos son bastante específicos (aunque casi todos aplicables a diversos lenguajes) pero otros son completamente genéricos.

En todo caso, un buen repaso generalista.

Sobre aprender a programar y la frase 'independiente del lenguaje'

Sobre programación En We Should Stop Saying ‘Language Independent.’ We Don’t Know How To Do That una nota interesante sobre la famosa frase ‘independiente del lenguaje’ y cómo el lenguaje en el que aprendemos nos influye.

Habla de la investigación de Allison Elliott Tew y Miranda Parker sobre estudiantes de programación con diferentes lenguajes y cómo los errores que se comenten en unos se parecen más a algunos otros que a la generalidad:

Notice that the most common wrong answer is exactly the same. The 2nd most common wrong answer in Java is idiosyncratic (which is interesting), but the 2nd most common wrong answer for both MATLAB and Python is the 3rd most common wrong answer for Java. The 4th most common wrong answer for Java is the same as the 5th most common wrong answer for Python. We didn’t see that wrong answer in MATLAB, but surprisingly, there were only 4 wrong answers for MATLAB.

Lo que dice el autor es que tenemos lenguajes diferentes porque creemos que eso tiene algún valor (marca alguna diferencia).

We have different languages because we think that those differences make a difference. For an assessment to be language independent, it would have to be measuring something deeper than those differences.

Interesante.

Almacenamiento de información sobre nuestra navegación: cookies y LocalStorage

Galletas Un artículo técnico pero no demasiado sobre cómo almacenan información los navegadores: Cookies vs. LocalStorage: What’s the difference?.

Todos hemos oido hablar de las ‘cookies’ (de manera irremediable por la absurda regulación sobre los avisos y esas cosas que tanto dolor causan en nuestra navegación diaria). No es tan habitual haber escuchado hablar de ‘LocalStorage’, otro sistema de almacenamiento de información (siempre local, otra cosa es lo que se haga con esa información después, claro).

Sobre las cookies, lo de siempre: un poco de información que se utiliza principalmente para hacer seguimiento de nuestra navegación mediante algún tipo de identificador que se nos asigna.

So, what are cookies? According to whatarecookies.com, they are small text files that are placed on a user’s computer by a website.

Que las hay persistentes y de sesión, las primeras tienen fecha de caducidad y las segundas expiran en cuanto cerramos la ventana del navegador (o la pestaña, o lo que sea). Las persistentes quedan almacenadas en nuestro sistema y son las que permiten que no tengamos que identificarnos una y otra vez en los sitios que usamos habitualmente.

Sobre LocalStorage, se trata de un mecanismo introducido con HTML5, que tiene la ventaja de que no es necesario que viaje de un sitio para otro en nuestra navegación en cada enlace que pinchamos (está orientado a almacenar información localmente).

This is because data is stored on the user’s local disk and is not destroyed or cleared by the loss of an internet connection.

Para repasar.

Seguridad en entornos corporativos con sistemas tradicionales

Ordenador grandote No es habitual que tengamos acceso a un ‘mainframe’, uno de esos sistemas grandes capaces de procesar muchísimas transacciones, que en muchos casos han sido sustituidos por infraestructuras más ligeras y a las que sí que tenemos acceso con más facilidad.

En Top Five Security Focus Areas for Mainframes hablaban de estos equipos y resumen los problemas fundamentales de seguridad en cinco.

  • Políticas de contraseñas.
  • Datos olvidados
  • Usuarios con demasiados privilegios
  • Protocolos no cifrados
  • Aplicaciones inseguras

Nada que no podamos esperar encontrar en un sistema basado en otro tipo de comopnentes, pero en estos sistemas parece que no es raro encontrar los problemas por su dificultad de gestión, el tipo de operaciones que se realizan con ellos y laforma en que tradicionalmente se han considerado dentro de las empresas.

Esto es, habitualmente estaban aislados y protegidos físicamente.

First, mainframes were historically physically isolated in what was considered a “secured” space with layers of security controls, so companies assumed they would not be tampered with.

Típicamente están dedicados a tareas de producción y es un problema hacer otras cosas con ellos.

Second, mainframes are typically excluded from security testing because they almost always run production operations.

No hay demasiados expertos en la seguridad en este contexto.

Finally, there is limited mainframe testing expertise

Las herramientas sencillas también nos pueden ayudar a encontrar problemas de seguridad

Un fallo cualquiera Cuando yo empecé a interesarme por el desarrollo seguro de aplicaciones las únicas herramientas que había eran buscadores de cadenas más o menos potentes; estas herramientas no podían ‘comprender’ el flujo del código ni hacer seguimiento de las variables (lo más parecido a eso era el Taint mode de Perl. Posteriormente las herramientas han ido mejorando (y encareciéndose) y ahora son capaces de cosas mucho más interesantes.

Sin embargo, la búsqueda de patrones sigue siendo una herramienta más y de eso habla Don’t Underestimate Grep Based Code Scanning que empieza hablando de las herramientas y cómo el mercado está copado por unos pocos fabricantes de herramientas bastante caras:

The SAST market is dominated by a small number of big players that charge high licencing fees for tools that do sophisticated analysis. One of the main features of such tools is the data flow analysis, which traces vulnerabilities from source to sink, potentially going across a number of files.

Sigue habiendo herramientas más sencillas (y económicas) que también son más eficientes:

There are lower cost, more efficient SAST tools, but they typically do lack the sophistication in terms of quality of security bug findings. Perhaps the most popular low-cost alternative is SonarQube,…

A pesar de todo, como decíamos, se puede usar la búsqueda de patrones (la herramienta prototípica sería grep):

In this blog, we’re going to talk about grep-based code scanning, which is an old fashioned way of SAST scanning — but we argue that good grep based scanning can do reasonably well compared to expensive SAST tools in terms of quality of bugs found.

Y después hace unas cuantas consideraciones para pasar a indicarnos qué buscar, con cadenas como: “password, passwd, credential, passphrase”, o “sql, query(“. Sin olvidar las funciones inseguras como “strcat, strcpy, strncat, strncpy, sprintf, gets” y otras muchas cadenas que pueden darnos indicios de que algo puede que no vaya bien del todo. O, al menos, que tal vez deberíamos mirar allí.

Curioso.

En informática los nombres largos son una mala idea

Sobre nombres Un asunto importante en la informática es el nombre de las cosas. En Long Names Are Long me gustó leer los consejos que dan y por eso lo traigo aquí.

Habla del sistema de revisión de código en Google y también de la importancia que le dan a la legibilidad, para centrarse en la longitud de los nombres (identificadores):

What I want to talk about is something I see in a lot of code that drives me up the wall: identifiers that are too damn long.

Las metas para elegir un buen nombre deberían se la claridad (saber a qué se refiere el nombre) y la precisión (saber a qué no se refiere). Y los consejos:

Omitir nombres obvios para una variable o tipo de parámetro (por ejemplo, incluir el tipo de la variable en el nombre sería desaconsejable).

  1. Omit words that are obvious given a variable’s or parameter’s type

Evitar palabras que no ayudan a eliminar ambigüedades (por ejempo, calificativos redundantes).

  1. Omit words that don’t disambiguate the name

Evitar palabras que se conocen del contexto (por ejemplo, en un método que calcula un valor anualizado, ¿tiene sentido hacer referencia a la anualización en la variable correspondiente?).

  1. Omit words that are known from the surrounding context

Evitar palabras que no significan mucho (o nada). Ejemplos: datos, estado, valor, …

  1. Omit words that don’t mean much of anything

Interesante.

Como bola extra, un viejo artículo sobre el nombrado y como (según Joel Spolski) se pervirtió la idea de la notación húngara (que se nombra en el otro artículo) hasta convertirla en algo absurdo Making Wrong Code Look Wrong.

Identificación de características basada en el tiempo

Reloj Una clase de fallos especialmente sugerente y a los que no siempre se presta atención son los relacionados con el tiempo: un ejemplo serían las condiciones de carrera (cuando algo cambia entre el momento de verificar que una operación está permitida y el momento en que la operación se realiza); el que traemos hoy aquí tiene que ver con el tiempo que se tarda en realizar alguna operación dependiendo de las circunstancias que rodean a nuestro sistema. Un ejemplo clásico de este tipo de errores era cuando buscamos algo: típicamente es más rápido cuando lo encontramos que cuando no está (y eso da pistas sobre valores de algunos datos).

En esta ocasión traemos Detecting incognito mode in Chrome 76 with a timing attack que habla justamente de un problema de este tipo. En Chrome 76 era posible determinar si el usuario utilizaba el modo incógnito por la velocidad de escritura, al utilizar APIs diferentes.

Había un precedente, basado en la cantidad de espacio disponible para poder utilizarse (en Bypassing anti-incognito detection in Google Chrome)

Recently, security researcher Vikas Mishra discovered that we can infer incognito state based on the amount of space which the API makes available.

Y el autor habla de la medición de escrituras, en este nuevo tipo de fallo, que se basa en medir el tiempo que cuesta escribir repetidamente cadenas de caracteres largas:

In this blog post, I present a proof-of-concept of a technique which websites could use to detect incognito users by measuring the speed of writes to the API.

The setup is relatively simple: benchmark the filesystem by repeatedly writing large strings to it and measuring how long that takes. Because memory is faster than disk, we should be able to tell by the speed whether the site visitor is in incognito.

Interesante.