Números aleatorios desde el espacio

La suerte (?) El día que consiga que vuelvan a funcionar las categorías y las etiquetas se podrá ver cómo hemos hablado bastantes veces de aleatoriedad. Traemos hoy aquí Random Numbers From Outer Space donde hablan del tema desde otra perspectiva.

Siempre decimos lo importantes que son los números aleatorios en seguridad y en este caso hablan de usar la radiación de fondo. Se usa un detector de muones, que son partículas subatómicas más pesadas.

Muons are subatomic particles that are like electrons, but much heavier, and are created when pions enter the atmosphere and undergo radioactive decay. The Geiger-Müller tube, mainstay of Geiger counters the world over, detects these incoming muons and uses them to generate the number.

Curioso.

Reducción de costes para un servicio en la nube

Dinero La promesa de la nube (ajena) es ahorro en costes (no tener que adquirir, instalar, ni mantener infraestructura). No obstante, eso no significa que no haya costes que haya que vigilar y tratar de mejorar. De eso nos habla Three ways to reduce the costs of your HTTP(S) API on AWS.

Empiezan hablando de sus medidas: reciben, almacenan y procesan eventos relacionados con juegos de 1200 millones de jugadores en cerca de 90,000 juegos.

Here at GameAnalytics, we receive, store and process game events from 1.2 billion monthly players in nearly 90,000 games.

Esto se traduce en alrededor de cinco mil millones de peticiones diarias, cada una de ellas con dos o tres eventos de unos pocos kilobytes.

We get approximately five billion requests per day, each typically containing two or three events for a total of a few kilobytes.

Y eso tiene un coste, claro:

So what would you guess is the greatest cost associated with running this system on AWS, with a fleet of EC2 instances behind a load balancer?

La mayoría, datos que van hacia afuera:

We wouldn’t have guessed that the greatest part of the cost is for data transfer out. Data transfer in from the Internet is free, while data transfer to the Internet is charged between 5 and 9 cents per gigabyte.

Los trucos son sencillos, en algunos casos:

  • Reducir las cabeceras HTTP, para bajar de 333 bytes a 109

Sending 109 bytes instead of 333 means saving $56 per day, or a bit over $1,500 per month.

  • Reducir la negociación del TLS, basado en la recuperación de sesiones TLS.

That leaves reducing the number of handshakes required by reducing the number of connections that the clients need to establish. […] This reduced data transfer costs by an additional 8%.

  • Verificar los certificados, que típicamente también son demasiado grandes. Sobre todo si hay una cadena de confianza para establecer la validez del nuestro.

So given that the clients establish approximately two billion connections per day, we’d expect to save four terabytes of outgoing data every day. The actual savings were closer to three terabytes, but this still reduced data transfer costs for a typical day by almost $200.

Una lectura interesante.

Cuidado con los consejos sobre contraseñas

Los dados del r5 Últimamente se ha empezado a dar relevancia a las contraseñas y a los consejos sobre cómo construirlas. Se utilizan con cierta frecuencia consejos que ya no deberían darse y en Your xkcd passwords are pwned habla de uno de ellos en particular, que no es muy recomendable.

En primer lugar, recordar que las contraseñas es algo que todo el mundo cree que comprende, pero es algo mucho más difícil de lo que pensamos, fundamentalmente porque no tienen en cuenta a los atacantes de verdad:

Passwords are incredibly hard to “get right.” In fact, there’s a pretty solid argument to be made that they can never be right (at least when used as a sole authN factor.) Yet we are inundated with “experts” telling us fantastic stories about how secure the right password policy can be. The biggest problem here is these policies aren’t modeling real world attackers

Los consejos habituales son: más de 8 caracteres (más mejor), tener una mayúscula, una minúscula y un número.

Pero la fortaleza de una contraseña, ¿de dónde viene? En realidad una contraseña es mejor si es más complicado obtenerla para un atacante, que no es algo fácil de medir:

Ideally, the strength of a password should be the approximate measure of how difficult it would be for an attacker to recover said password. Except it gets a little more complicated than that. How do we determine something is even difficult?

Las últimas recomendaciones, además, contradicen cosas que se han dicho siempre: ya no se debe forzar la complejidad, no se deben caducar y algunas reglas más de las que ya hemos hablado a veces:

We now have some recommendations like: * no complexity requirements * no password expiration period * no password hints * no truncation of secrets * tagging SMS OTPs as “RESTRICTED” * and some other good things…

El consejo del conocido cómic tiene una cosa buena: aleatoriedad real (con dados).

Tiene cosas malas, relacionadas con la dificultad de elegir buenas combinaciones de palabras, pero también la medición de entropía (que es compleja); otro error es asumir que los ‘malos’ utilizan sólo la fuerza bruta y, finalmente, cuatro palabras seguramente son pocas en este momento.

También cosas feas: al final la gente elige las palabras según su criterio, y eso reduce mucho las posibilidades, llegando a adivinar las contraseñas en unos días:

If you haven’t already guessed, I got a password in less than that. After 6 days, I cracked the password for a senior systems administrator who held highly sensitive privileges to the entire infrastructure. (This was definitely an epic moment for me.)

Termina dando los siguientes consejos: si queremos utilizar el método, deberíamos utilizar 6 palabras como mínimo, con una buena cantidad de palabras para elegir, de forma aleatoria y añadiendo espacios entre ellas.

Also, if you’re going to use diceware, make sure you do it right: Use a minimum of 6 base words. Use a decently sized pool of candidates for selection (Diceware’s recommendation of 6^5 seems like a good bar.) Make sure your selections are chosen at random. (Do not pick them yourself.) Go ahead an use spaces in your passwords. Use all the spaces! It really does make a difference

Igual lo he resumido excesivamente, vale la pena leerlo.

Algunos datos sobre la seguridad en los dominios más importantes

Rimas populares En Email authentication: SPF, DKIM and DMARC out in the wild un repaso de las distintas tecnologías de autentificación de correo y su uso por ahí.

Empieza recordando que el correo utiliza protocolos muy antiguos y que nacieron en épocas más ‘apacibles’ de la red.

Email authentication has had a turbulent history - SMTP did not have a native form of authentication when it was designed, and all modern authentication methods are built on top of that system.

Hay una cantidad de métodos que permiten mejorar la cosa, como SPF, DKIM, y DMARC y el objetivo era verificar cuánto se utilizan.

Since then we’ve got a variety of tools to attempt to verify emails, including SPF, DKIM, and DMARC, and I wanted to explore the actual usage of these authentication methods by the most popular sites

SPF (Marco de política de remitente, Sender Policy Framework permite al propietario de un dominio especificar los servidores desde los que envía correo y al receptor verificar los remitentes de un determinado dominio:

SPF, or Sender Policy Framework, is a protocol that allows the owner of a domain to specify which mail servers they’ll be sending mail from.

Sin embargo, de los 100 dominios más importantes casi todos lo usan con ‘suavidad’:

For the top 100 domains, 50 of them have all set to softfail, whose intended action is accept but mark - this effectively says that any email received from a non-designated sender should be accepted but “marked” (which has no specific action associated - some providers drop the email, others send to junk, and others send to inbox).

Y algo parecido sucede con las 500 empresas más importantes según Fortune.

DKIM (Correo Identificado con Claves de Dominio, DomainKeys Identified Mail) utiliza claves que se publican en el DNS y que también pueden utilizarse para verificar que los correos vienen de donde deben. Desafortunadamente no es fácil verificar su uso en un análisis como el que se realizó.

Finalmente, DMARC (Autentificación, Informe y Conformidad basada en el dominio de un mensaje Domain-based Message Authentication, Reporting and Conformance) es otro mecanismo que permite publicar una política en el DNS para especificar qué mecanismo se utiliza de los anteriores.

De los 100 dominios más importantes sólo 74 lo tienen activado:

Of the top 100, only 74 of them have DMARC policies set up.

Y para las empresas del Fortune 500 la cosa baja un poco:

Of the fortune 500, only 329 of them have DMARC policies set up, or a 66% implementation rate.

Otra herramienta sería el DNSSEC (DNS seguro) y en este caso, sólo un 6% de los 100 más importantes lo tienen y para el Fortune 500 estaríamos hablando de un 2.8%.

For the Top 100 sites, only 6 of them are using DNSSEC (a 6% implementation rate). For the Fortune 500, it’s even worse, at 14, or a 2.8% implementation rate.

En definitiva, una tasa baja de adopción y en los casos que se adopta, sin demasiado interés.

I was fairly surprised at the low adoption rates for the various security features above. If I had to guess it’s because of the haphazard nature of email systems growth. When there wasn’t one standardized security methodology from the beginning, each system will slowly build out its own, becoming a frankenstein monster of proprietary software and incorrectly implemented standards.

Técnicas de Facebook para evitar el bloqueo de la publicidad

Anuncio de baja tecnología En How Facebook Avoids Ad Blockers un poco de web y cómo la conocida empresa evita que bloqueemos sus anuncios.

Hoy en día es bastante habitual que naveguemos con algún sistema para evitar ver anuncios. En el caso de Facebook, se utilizan algunos trucos para que no tengamos otro remedio que verlos.

Por ejemplo, la etiqueta de anuncio está separada carácter a carácter:

At first glance blocking these ads seems simple. Look for elements with the text containing ‘Sponsored’. […] First, Facebook doesn’t actually have ‘Sponsored’ in their HTML. At least, not together as we would think. In the DOM, ‘Sponsored’ is actually broken up character by character.

No sólo eso, sino que la ‘esconde’ en los atributos de las etiquetas:

<span>
  <span data-content="S"></span>
  <span data-content="p"></span>
  <span data-content="o"></span>
 ...

Y también utiliza otras técnicas de ofuscación, insertando textos intermedios y otras ‘diabluras’, como caracteres invisibles:

These values are entirely random characters, with a random number of DOM nodes between them. Invisible characters.

Curioso.

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