En How we protect our most sensitive secrets from the most determined attackers un buen repaso de medidas y estrategias destinadas a proteger los secretos de un banco.

As a bank, we have a lot of secrets we need to protect to keep our customers and ourselves safe. These include private keys that only we know, which we use to digitally sign requests as coming from us (sort of like a private password).

Las amenazas, nos dicen, pueden venir de la cadena de suministro (la gran tendencia desde este verano), un atacante externo o uno interno (¿nos acordamos de estos últimos?)

Valdrá la pena leer tambień How our security team handle secrets y Securely delegating trust with digital signatures and secret storage systems.

Ya hemos hablado a veces de las herramientas de fuzzing y cómo podían permitir encontrar fallos de seguridad. También hemos hablado de los parámetros del protocolo HTTP y algunas manipulaciones. En esta ocassión podemos hablar de la reunión de ambos mundos. En New differential fuzzing tool reveals novel HTTP request smuggling techniques nos contaban cómo unos investigadores habían descubierto nuevos fallos utilizando herramientas de fuzzing.

In a white paper the researchers discuss how they discovered a wealth of new vulnerabilities using the fuzzing tool, which they said can be used by bug bounty hunters and researchers alike.

Nos recuerda el fallo de manipulación de peticiones HTTP del que se empezó a hablar en 2005.

HTTP request smuggling, which first emerged in 2005, interferes with how websites process sequences of HTTP requests received from users.

Los fallos a los que se refieren aparecen cuando hay balanceadores de carga y reenvíos de cabeceras, que pueden ser utilizados para hacer pasar algunas peticiones a través de esa infraestructura.

If there is a discrepancy between the front- and back-end servers, it can allow attackers to smuggle hidden requests through the proxy.

Es un ejemplo de lo que se llama interacción insegura entre componentes seguras: cada una de ellas puede ser perfectamente válida, pero las diferencias entre ellas pueden provocar problemas.

The paper reads: “These processors may not necessarily be individually buggy; but when used together, they disagree on the parsing or semantics of a given HTTP request, which leads to a vulnerability.

Las técnicas se basan en enviar ligeras variaciones entre peticiones HTTP para detectar inconsistencias y posibles problemas.

It exercises two target servers with the same mutated request, and compares the responses to identify discrepancies that lead to smuggling attacks.

En definitiva, tener componentes seguras no garantiza la seguridad de un sistema, porque la seguridad tiene que ser una propiedad del sistema completo.

“Secure components do not necessarily make a secure system; security is an emergent property of the system as a whole.

Muy interesante.

Ya hace muchos años que descubrimos las APIs abiertas (por ejemplo, en Flickr) y las posibilidades que ofrecían. Sin embargo (igual es mi impresión) en los últimos años se está hablando más, y hay quién lo hace mejor y quién lo hace peor. Recordemos aquí que un API es un mecanismo para desarrollar programas con los servicios de alguien: nos proporciona una forma de llamar a sus ‘primitivas’ básicas y, en consecuencia, hacer programas para nuestro uso (y el de otros) con las herramientas de su plataforma.

Slack es uno de esos casos donde permiten la creación de bots y diversos autoamtismos sobre su plataforma y en How We Design Our APIs at Slack hablan del diseño de sus APIs.

La motivación tiene con que sean cómodas de usar, los desarrolladores tengan ganas de hacerlo y generen proyectos interesantes.

If APIs are designed well, developers will love them, and can become the most creative innovators using your APIs. They will invest heavily, and sometimes even become evangelists for your APIs. We also value a developer’s time and the resource they risk by building on our platform. Bad API design leads to a bare minimum adoption, and even frustration. Bad APIs become a liability for a company.

Y luego nos dan sus principios:

Hacer una cosa y hacerla bien.

1. Do one thing and do it well

Hacer fácil y rápido el comienzo.

1. Make it fast and easy to get started

Preouparse de la consistencia intuitiva.

1. Strive for intuitive consistency

Devolver errores con significado.

1. Return meaningful errors

Diseñar para el crecimiento y las prestaciones.

1. Design for scale and performance

Evitar cambios disruptivos (que rompan cosas)

1. Avoid breaking changes

Luego hablan del proceso de diseño, en cuatro pasos: escribir una especificación, revisarla internamente, recibir realimentación de los primeros colaboradores y tener una fase de pruebas

1. Write an API spec
2. Internal API review
3. Early partner feedback
4. Beta testing

Interesante.

Ya hemos hablado más veces de los canales laterales para robar información. En Crean señales inalámbricas con un cable Ethernet para robar datos nos contaban la posibilidad de utilizar los omnipresentes cables para:

generar emisiones electromagnéticas en las bandas de frecuencia de 125 MHz que luego son moduladas e interceptadas por un receptor de radio cercano.

Se han hecho pruebas de concepto:

los datos transmitidos desde una computadora con espacio de aire a través de su cable Ethernet se recibieron a una distancia de 2 metros.

Claro, esto requiere infectar la máquina en cuestión y luego poder sacar provecho del mecanismo pero, desde luego, teóricamente es posible.

Hay una broma recurrente por ahí que habla de que los programadores ya no tienen que saber casi nada. Todas las soluciones están, nos dicen, en StackOverFlow y otros foros similares.

Sin embargo, y no es la primera vez que hablamos de ello, lo cierto es que muchsas veces es mala idea copiar código incluso de los libros, sobre todo si nos preocupa la seguridad.

En If you copied any of these popular StackOverflow encryption code snippets, then you coded it wrong hablan del tema.

El autor revisa código y encuentra fragmentos de código que están mal y que ha encontrado en ese foro:

Security code reviews is a task that I do on a daily basis, and have been doing for the last thirteen and a half years. In this time, I have reviewed several hundred code bases, and have come across cryptographic code many times. More often than not, there have been security issues in cryptography code that I have reviewed. Very often I have traced these bogus code snippets to StackOverflow answers that got highly upvoted.

La entrada se dedica a mostrar varios ejemplos, con contraseñas en el código al utilizar criptografía, por ejemplo. También semillas y otros fallos de más alto nivel. A veces, incluso como soluciones con mayor número de votos positivos. Que contienen errores.

The current highest voted issue has 187 upvotes at the time of writing. This answer gives a nice overall education about how to do encryption properly, and it is definitely worth a read. The only niggle I have is the SecureRandom( ) confusion …

Muy interesante. Y un recordatorio de que no hay que fiarse de soluciones más o menos cómodas que encontremos por ahí.