En Jugando con técnicas anti-debugging José Manuel Fernández hace una panorámica de las ténicas anti depurado que utilizan los programas maliciosos para evitar que su detección y análisis.

En particular en esta entrada hablaba de la función IsDebuggerPresent.

En Jugando con técnicas anti-debugging (II) comenta sobre el campo NtGlobalFlag.

Finalmente, en Jugando con técnicas anti-debugging (III) se habla de las técnicas basadas en tiempo (un programa ejecutándose en condiciones normales no debería tardar más de … Si tarda más, a lo mejor alguien lo está ejecutando paso a paso, o haciendo algo ‘indebido’ con él). En este caso la función es GetTickCount().

Como bola extra, la lectura recomendada de [PDF] The ultimate Anti-debugging Reference y los programas utilizados como ejemplo en reverc0de/saw-anti-debugging. Muy interesante.

Uno de los problemas e utilizar SSL (TLS hoy en día) es el coste computaional: con muchas visitas las conexiones cifradas pueden ser un sobrecoste que no estemos dipuestos a asumir.

En Universal SSL: How It Scales Nick Sullivan de CloudFlare nos habla de su proyecto (ya tiene más de un año) de proporcionar HTTPS para todos los sitios albergados por ellos (que es una decisión a la que parece que se está dirigiendo mucha más gente cada vez) y hablan de este sobrecoste:

People have asked us, both in comments and in person, how our servers handle this extra load. The answer, in a nutshell, is this: we found that with the right hardware, software, and configuration, the cost of SSL on web servers can be reduced to almost nothing.

Alguno de los trucos está basado en cuestiones como retomar sesiones:

For returning visitors of a site we have a shortcut that eliminates the need for our servers to perform these expensive operations. The shortcut is called session resumption and it’s built into the TLS specification.

Otras medidas utilizadas son el Lazy Loading:

Lazy loading of certificates helps relieve that bottleneck. Using custom modifications to nginx by CloudFlare engineer Piotr Sikora, we are able to dynamically load certificates into memory only when they’re needed. Now, if one site changes their certificate, the server does not have to reload every certificate. This change allows our servers to scale up to handle millions of HTTPS sites.

Todo ello combinado con algoritmos modernos (Criptografía de curvas elípticas, ECDSA) y hardware actualizado:

All Intel CPUs based on the Westmere CPU microarchitecture (introduced in 2010) and later have specialized cryptographic instructions.

Me repito. Pero cuando salen fallos de seguridad relacionados con los temas típcos no podemos dejarlos pasar sin comentarlos. En este caso se trata de desbordamientos de enteros (lectura clásica recomendada: Basic Integer Overflog).

El primero se trata de un desbordamiento de enteros en `strncat’ Integer overflow in strncat.

I didn’t look into the details but it looks like strncat(s1, s2, n) misbehave when n is near SIZE_MAX, strlen(s2) >= 34 and s2 has specific offset.

Hay algunos comentarios interesantes en Integer overflow in glibc strncat donde no queda claro del todo si es fallo o característica, pero vale la pena leerlos, sobre todo si nos gusta o no sinteresa el lenguaje C.

Por otro lado, leíamos el otro día en Desbordamiento de entero en PuTTY y en PuTTY vulnerability vuln-ech-overflow sobre un desbordamiento de enteros en PuTTY. En este caso el atacante debería ser capaz de insertar una secuencia de escape sofisticada que afectaría a una variable que almacena el número de caracteres que hay que borrar en determinadas condiciones.

The vulnerability arises because PuTTY uses signed integer variables to hold the number of characters to be erased and doesn’t adequately check for overflow. This means that by passing a very large parameter to ECH, an attacker could cause check_boundary to inspect memory outside the terminal buffer.

Recientemente se ha cumplido un año que estamos escribiendo en este sitio Cuata Etapa. Me viene bien recordarlo porque recientemente leíamos Eight lessons learned hacking on GitHub Pages for six months en el que nos cuentan algunos principios generales aprendidos desarrollando el servicio.

El primero de ellos (previo, más bien) es ser usuario de tu propio servicio para conocerlo bien, conocer sus virtudes, encontrar sus defectos…

Y luego la lista:

• Test, test, and then test again

Desarrollo basado en pruebas, para estar seguros de que cuando se introducen cambios nada va a fallar.

• Use public APIs, and when they don’t exist, build them

En la línea del principio ‘previo’ no utilizar componentes secretos o privados y si se detecta la necesidad de algo que no existe, ponerlo a disposición de los usuarios.

• Let the user make the breaking change

Permitir a los usuarios que controlen los cambios importantes que pueden afectar a sus sitios.

• In every communication, provide an out

Cuando se comunican los errores se informa al usuario no sólo del problema sino también de dónde tiene que mirar para solucionar el fallo.

• Optimize for your ideal use case, not the most common

No hay que olvidar que el servicio es para dar a conocer los proyectos. Eso debería ser lo más fácil de hacer, independientemente de lo que la gente esté haciendo.

• Successful efforts are cross-team efforts

Como tantos proyectos, no son cosa sólo de un equipo que se encarga de ellos, sino que, seguramente, hará falta hablar y trabajar con otros equipos.

• Match user expectations, then exceed them

Que los usuarios tengan lo que esperaban del proyecto, pero mejor. No hay mucho que añadir aquí.

• It makes business sense to support open source

Una parte de su producto está basado en Jekyll, que es software libre y que ha ganado su propio espacio como producto independiente, que siguen apoyando y en el que siguen participando.

Cuando explicamos las condiciones de carrera siempre nos quedamos con la duda de si es un tema que ya todo el mundo conoce y también si no sería mejor dedicar ese tiempo a explicar otras cosas. De pronto, una entrada como Race conditions on Facebook, DigitalOcean and others (fixed) nos demuestra que más vale no olvidarlos.

Las condiciones de carrera ocurren en sistemas concurrentes, cuando dos actores acceden a o modifican una determinada información y el tiempo y la forma de acceso son importantes, porque lo que haga uno de ellos afecta a lo que el otro debería poder hacer. Se puede ver una explicación en Practical Race Condition Vulnerabilities in Web Applications y también en Condición de Carrera

En la entrada se comenta sobre varios fallos de sitios de alto nivel (que, al final, es lo que hace que valga la pena comentarlos aquí). Son secuencias de pasos para fallos de Facebook (en este caso aumentar el número de revisiones de una página o crear varios nombres de usuario para una cuenta), DigitalOcean (añadir crédito a nuestra cuenta), y LastPass (con un fallo parecido al de DigitalOcean).