Dar un curso de desarrollo seguro (y de seguridad en general) es bastante ‘agradecido’ desde el punto de vista de encontrar ejemplos, porque la actualidad siempre nos trae sorpresas.

Estábamos hablando en clase sobre los problemas de los nombres y de tomar decisiones sobre ellos y justo aparece el fallo en git: Vulnerability announced: update your Git clients

The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem.

La negrita la he puesto yo.

Se puede leer también el anuncio en la lista de desarrollo de git, [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks) y Git 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land.

Si nos interesa ver el código, al menos a una parte, podemos echarle un vistazo a path: add is_ntfs_dotgit() helper, donde hablan de:

On NTFS (and FAT32), there exist so-called “short names” for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As “.git” is not an 8.3 compliant name, a short name is generated automatically, typically “git~1”

Y también a: read-cache: optionally disallow HFS+ .git variants donde se ven las invocaciones a la función añadida y alguna cosa más.

Esta entrada se ha publicado orginalmente en Cuidado con la gestión de nombres.

En Watering hole: nuevos términos para ¿nuevos? ataques se habla del nombre que se ha empezado a dar a los ataques dirigidos realizados desde sitios web más o menos comunes (‘watering hole’ sería el bebedero a donde acuden los animales a saciar su sed).

La analogía sería un sitio web frecuentado por un determinado número de personas, entre las que se encuentra el objetivo. Como se trata de un sitio que seguramente visitaría con frecuencia, relajaría las condiciones de acceso y sería menos precavido.

Ya habíamos hablado de Ataques a objetivos concretos y Puedes estar vigilado. También de los ‘bebederos’, en un ataque a Facebook: Ataques dirigidos: el caso de Facebook.

En Un compilador que infecta los binarios hablábamos de la confianza y recuperábamos una lectura clásica sobre el tema de en qué podemos confiar y cómo en algún momento cedemos el control.

Se me había pasado la técnica que propuso David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers donde habla de cómo se podría mejorar la confianza en los binarios que generemos, mediante doble compilación diversificada, “Diverse Double-Compiling” (DDC). En el resumen:

In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Hay un vídeo sobre la PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling

Hay esperanza. Pero … ¿Estamos dispuestos a pagar el precio de la complejidad añadida?

Los números aleatorios son una componente importante en cualquier desarrollo que tenga que ver con la seguridad. En Intel® Digital Random Number Generator (DRNG) Software Implementation Guide podemos leer la documentación del generador de Intel y algunos comentarios interesantes.

Ya habíamos hablado de Números aleatorios y seguridad y las consecuencias de usar números aleatorios de calidad insuficiente en Algunas debilidades de HTTPS.

En We scanned the Internet for port 22 un estudio sobre el puerto 22 y su utilización.

Yesterday (Sept. 12) we scanned the entire Internet for port 22 – the port reserved for “SSH”, the protocol used by sysadmins to remotely log into machines. Unlike our normal scans of port 80 or 443, this generated a lot more “abuse” complaints, so I thought I’d explain the scan.

De los resultados, se puede ver:

In other words, the top result of 1,730,887 systems on the Internet show an SSH banner of “SSH-2.0-OpenSSH_4.3”. (Note: this is actually only 60% of the Internet, I’ve got corruption in the files for 40% of the results that I need to fix).

También es interesante ver como hay quien se enfada por recibir este tipo de pruebas y quien anima a realizarlas.