Cuando estamos en una videoconferencia mucha gente dedica su tiempo a realizar otras actividades, además de participar más o menos activamente en la reunión. Se hace con cierta ligereza, porque estamos bastante seguros de que nadie sabrá lo que ocurría. A veces, hay accidentes, como que tenemos el sonido abierto y se escucha el teclado, nuestros comentarios, …

En Experts Find a Way to Learn What You’re Typing During Video Calls nos cuentan cómo se puede extraer cierta información de los movimientos corporales mientras tecleamos.

A new attack framework aims to infer keystrokes typed by a target user at the opposite end of a video conference call by simply leveraging the video feed to correlate observable body movements to the text being typed.

Nada impide que esto se haga con vídeo en directo, sino que alguien podría procesar vídeos disponibles por ahí y tratar de averiguar lo que sucedía.

… who say the attack can be extended beyond live video feeds to those streamed on YouTube and Twitch as long as a webcam’s field-of-view captures the target user’s visible upper body movements.

Casi nada que hacemos está aislado completamente, así que se puede tratar de decucir palabras teniendo en cuenta lo que ha sucedido anteriormente y posteriormente.

Word prediction, where the keystroke frame segments are used to detect motion features before and after each detected keystroke, using them to infer specific words by utilizing a dictionary-based prediction algorithm

Si escribimos mirando al teclado y buscando las teclas, y además llevamos ropa sin mangas, será más fácil ver lo que estamos haciendo, nos dicen.

The findings showed that hunt-and-peck typers and those wearing sleeveless clothes were more susceptible to word inference attacks

Si tenemos información adicional sobre la actividad del usuario, todavía es más fácil tener éxito. Por ejemplo, nombres de usuarios, correos electrónicos…

The tests were repeated again with 10 more participants (3 females and 7 males), this time in an experimental home setup, successfully inferring 91.1% of the usernames, 95.6% of the email addresses, and 66.7% of the websites typed by participants, but only 18.9% of the passwords and 21.1% of the English words typed by them.

Curioso.

Hace unos días hablábamos de la seguridad de Java (en ¿Java es un lenguaje seguro? . En cualquier caso, el récord como lenguaje problemático (aunque seguramente lo sea todavía más la programación en shell) lo tiene el lenguaje C.

En half of curl’s vulnerabilities are C mistakes nos hablaban justamente de eso, para el caso de curl, la conocida herramienta que nos permite una amplia gama de posibilidades de transferencia de datos mediante URLs (que es una forma complicada de decir que puede hacer muchas de las cosas que hace un navegador; y algunas más, porque al poder integrarse en scripts tiene algunas ventajas interesantes). Viene de Would Rust secure cURL? donde se muestran los errores que provienen de las dificultades de C.

Daniel Stenberg, el responsable de curl se toma el trabajo de confirmar o desmentir estas ideas y llega a la conclusión de que la entrada proporciona datos ciertos (con pequeños matices de conteo).

51 out of 98 security vulnerabilities are due to C mistakes

That’s still 52%.

Pero claro, dice, el análisis se ha hecho sobre 98 fallos de los 6682 que ha tenido curl en su historia (un 1,46%).

The curl changelog counts a total of 6,682 bug-fixes at the time of this writing. It makes the share of all vulnerabilities to be 1.46% of all known curl bugs fixed through curl’s entire life-time, starting in March 1998

Luego nos cuenta cuáles son los tipos de fallos detectados: hay lectura fuera del espacio de memoria reservada (buffer overread), y escritura, desbordamientos de memoria, (buffer overflow). También hay usos de la memoria después de liberarla (user after free) y liberaciones innecesarias (porque ya estaban hechas, double free). Finalmente, fallos relacionados con el NULL (NULL mistakes).

Sin embargo, nos dice, también es verdad que parece que las vulnerabilidades relacionadas con el lenguaje se encuentran antes que otros tipos de fallos.

C mistake vulnerabilities are found on average at 80% of the time other mistakes need to get found. Or put the other way around: mistakes that were not C mistakes took 25% longer to get reported – on average. I’m not convinced the difference is very significant.

Un poco de numerología y también un recordatorio que los fallos de seguridad no siempre tienen que ver con los fallos del lenguaje, hay más posibilidades de equivocarse y son más difíciles de encontrar.

La contaminación de parámetros de HTTP es un fallo que ya tiene un tiempo (descubierto en 1999). Se trata de aprovechar que algunos entornos ponen a disposición del entorno esos parámetros para atacar una aplicación.

En A Look at HTTP Parameter Pollution and How To Prevent It repasan las ideas principales y nos ofrecen consejos para evitarlos.

With HTTP Parameter Pollution (HPP) attacks, threat actors can hide scripts and processes in URLs. First discovered in 1999, this technique can also allow threat actors to pollute the parameters in the URL and the request body. This could lead to behavior changes in the app, such as cross-site scripting, privilege changes or granting unwanted access.

Nos dicen que se pueden clasificar en los del lado del cliente y los del servidor. Esto se debe a que diferentes entornos procesan los valores de formas diferentes.

HPP can be classified into two types: client side or server side. Different web servers behave in different ways when they receive multiple parameters with the same name since ways to parse parameters vary. Client-side or server-side HPP attacks are possible depending on the way requests are handled.

En el lado del cliente, afectarán a las acciones del usuario y podrían forzar la realización de acciones sin su conocimiento.

A client-side HTTP Parameter Pollution attack is related to the client or user environment, meaning the user’s actions are affected and will trigger a malicious or unintended action without their knowledge.

Por otro lado, las del lado del servidor afectarán a terceros: acceso a datos, realización de acciones…

So, the goal of the attacker in a client-side attack is to attack other users. In the server-side variant the attacker could use an at-risk web app in several ways. They could access protected data or perform actions that either are not permitted or not supposed to be run on the server side.

La protección pasa por la validación de la entrada (validación, no saneamiento) y observación clara de lo que recibimos.

There are several ways to protect against HPP. Make sure to perform an extensive and proper input validation. All user-supplied data, which is reflected in the HTML source code of the HTTP response, should be encoded according to the context in which they are reflected.

Buena lectura, para recordar un viejo problema.

Cuando se habla de programación segura, suele decirse aquello de: ‘utiliza un lenguaje que sea seguro’ y, a veces, se pone como ejemplo Java (fundamentalmente por su gestión automática de la memoria, en contraposición con C; en este último la memoria se gestiona de manera manual por parte del programador).

En No, Java is not a Secure Programming Language el autor argumenta que Java no es tan seguro como suele decirse.

En particular, nos cuenta, tiene muchos problemas debidos a los valores por defecto.

Many Java security bugs are due to insecure defaults. As a consequence, developers need to have advanced development knowledge just to write simple code that cannot be easily exploited.

Y también porque la documentación no es muy buena.

Java has really poor documentation: it is not hard to make things work, but it is often very unclear how to do things the ‘right way.’

Luego detalla el tratamiento de los diferentes problemas que aparecen en el OWASP Top 10, y con cuatro de ellos en particular: las entidades XML externas (XML External Entity), las vulnerabilidades de deserialización, los problemas de ‘cross site scripting’ y la exposición de datos delicados.

Posteriormente detalla otros problemas.

Lectura interesante.

En What am I running inside my bash? una entrada bastante técnica (con código y todo) sobre la accidentada recuperación de una línea que el autor escribió en su línea de órdenes hace unos meses.

I desperately needed to extract the complete (and very lengthy) command line I had written 6 months ago in a bash shell - which was still running under screen. Read on to see how I eventually made it…

Se trata, ni más ni menos de recuperar una línea de código ejecutada en una instancia que sigue en ejecución:

You download the bash source code, untar, and hoping you can somehow recover the history information kept inside the running instance of bash, …

Lanzamos el gdb para que se asocie al proceso en cuestión y podemos empezar a buscar.

Spawn GDB - and activate God mode! That is, attach to the running bash, and call write_history on our own - it conveniently takes the filename to save in as an argument!

La cosa se complica un poco más porque en la máquina remota había algunas actualizaciones posteriores (el binario ya no era el mismo).

Curioso.