Técnicas novedosas de exfiltración de información: la vibración de los ventiladores

Libro. Un médico novato Casi a título de inventario. Hay gente que se dedica a ver cómo se puede extraer información de un sistema a través de diversas aproximaciones ‘laterales’ (el reflejo de la pantalla, el ruido del teclado, …). En el propio artículo hay una buena lista. En Academics steal data from air-gapped systems using PC fan vibrations hablan de utilizar las vibraciones del ventilador del PC.

La idea es que pueden robar información a través de ventiladores instalados en un PC para crear vibraciones controladas.

Academics from an Israeli university have proven the feasibility of using fans installed inside a computer to create controlled vibrations that can be used to steal data from air-gapped systems.

El objetivo es tratar de extraer información sin ser detectado.

Guri’s research doesn’t look at ways of compromising and planting malware on these super-secure systems but instead focuses on innovative and never-before-seen ways of getting the data out, without being detected, and through methods that network defenders are not aware of.

En este caso se instala software malicioso, que puede controlar la velocidad del ventilador (en particular, rebajarla) y utilizarla para transmitir información del mismo.

Guri says that malicious code planted on an air-gapped system can control the speed at which fans work. By moderating fan speed up and down, the attacker can control the frequency of the vibrations coming off the fan.

Un atacante cercano puede grabar esos cambios en las vibraciones y decodificar la información ‘transmitida’.

Guri says that a nearby attacker can record these vibrations using accelerometer sensors found in modern smartphones, and then decode the information hidden in the vibration pattern to reconstruct the information stolen from the air-gapped system.

Este método no sería muy rápido pero, desde luego, abriría una vía de escape para la información.

However, while the AiR-ViBeR technique is some pretty innovative work, transmitting data through vibrations is extremely slow.

Aunque, también reconocen que no es muy realista pensar que sea una buena solución.

While the AiR-ViBeR attack might be deemed “feasible,” it is highly unrealistic that attackers would ever use it in the wild, as they would most likely opt for other techniques that exfiltrate information at faster speeds.

Zoom, seguridad, comodidad y campañas de 'información'

El trípode de Samuel Zoom es el grán éxito de la temporada, casi hasta el punto de convertirse en genérico. Es un sistema de videoconferencia que ha gozado de gran éxito y que ha aumentado su número de usuarios de una forma espectacular. Ya hablamos aquí de un Análisis de amenazas de un sistema de cifrado entre extremos para videoconferencia pero ahora traemos el análisis de otro experto, Daniel Miessler, que dice que This Zoom Hate is Silly.

Es cierto que tiene (o tenía) problemas de seguridad, pero la respuesta que hubo en algunos ámbitos no tenía mucha lógica.

I get there are security issues. And some seem pretty bad. But the amount of highly-coordinated PR against the company feels more like an operation than regular criticism…

La competencia era abundante y notable. Skype, Hangouts, Webex , …

Lots of companies had competing products much earlier than them. Years earlier. Skype, Hangouts, Webex—they all had their shot. But Zoom comes in and makes something people actually want to use.

Pero… ¿seguro que no tenían sus propios problemas de seguridad?

But if you’ve been in security a while you know that vulnerabilities aren’t absent just because they aren’t being talked about. If you looked at Hangouts, or WebEx, or any of these other options the same way we’re looking at Zoom, it’d likely be just as nasty.

Pero claro prohibir una herramienta que ya mucha gente usa supone dejarlos a buscar sus propias alternativas y desperdiciar su esfuerzo.

Banning Zoom requires that the risk to people is as bad or worse than what’s gained from its use. And during a pandemic when most other solutions are nowhere near as approachable, that’s a very high bar.

La seguridad es un compromiso, entre facilidad de uso, comodidad, seguridad… Y, en este caso, tal vez dejar a alguien sin posibilidad de comunicarse.

Everything in security is a tradeoff. The only question is whether you’re properly measuring both sides to make an informed choice.

For people banning Zoom all over the place right now, the tradeoff is not communicating easily with people in a moment of intense need. Not. Communicating. During. Intense. Need. That’s on one side of the balance.

Hay que establecer un balance entre ventajas e inconvenientes.

En esLibre, hablando de mi chatbot como gestor de información personal

Presentación en esLibre Una de las cosas que voy haciendo en mi tiempo libre es programar. En los últimos años el trabajo no me da muchas oportunidades de hacerlo y he descubierto que me relaja y me entretiene. Ya hace unos años que compré una Raspberry Pi y en su momento empecé a pensar qué hacer con ella. De allí salió la idea de manter un gestor de información personal (Personal Information Manager, PIM) y hacerlo mediante un bot: en un contexto de movilidad, donde uno no siempre tiene un ordenador a mano, o no puede sacarlo con comodidad, parece adecuado tener servicios similares con una intervaz más adecuada.

Me hubiera gustado presentarlo el año pasado en esLibre, que era en Granada pero las fechas no eran adecuadas para mi. Este año esLibre era en Madrid y pensé que podría hacer una escapadita aunque fuera en el día y presenté mi propuesta, Un bot (no inteligente) multi-interfaz y distribuido como asistente personal que fue aceptada.

Lamentablemente, luego vino la pandemia y el encuentro se canceló, hasta que los organizadores (¡bravo por ellos!) decidieron lanzarse a la organización telepresencial. Con esto hemos perdido la cercanía, las charlas de café… Pero hemos ganado que mucha gente que de otra forma no habría podido, asista. Y también disponer de la grabación en video de la presentación. Es posible que más adelante escriba las ideas principales pero de momento nos conformaremos con poner el vídeo

También la presentación utilizada:

Un bot (no inteligente) multiinterfaz y distribuido como asistente personal from Fernando Tricas García

Espero que les guste.

Dropbox, Python y la comprobación de tipos

Museo Pedagógico de Aragón. tipos En programación existen varias discusiones eternas. Una de ellas es la comprobación de tipos. Hay lenguajes más exigentes y (nos dicen) por ello mucho más seguros y robustos y otros mucho menos y (nos dicen) por ello mucho más productivos y eficaces.

En Our journey to type checking 4 million lines of Python nos hablan de Dropbox, y su esfuerzo para mejorar la verificación de tipos en sus programas escritos en Python.

Dropbox is a big user of Python. It’s our most widely used language both for backend services and the desktop client app (we are also heavy users of Go, TypeScript, and Rust). At our scale—millions of lines of Python—the dynamic typing in Python made code needlessly hard to understand and started to seriously impact productivity.

Python es un lenguaje con tipado dinámico (esto es, una variable puede tener un tipo en un momento dado y más adelante tener otro). Eso es cómodo, porque nos quita preocupaciones cuando programamos pero puede ser un inconveniente cuando el código crece y empezamos a no entender lo que sucede.

Once your project is tens of thousands of lines of code, and several engineers work on it, our experience tells us that understanding code becomes the key to maintaining developer productivity. Without type annotations, basic reasoning such as figuring out the valid arguments to a function, or the possible return value types, becomes a hard problem.

¿Qué puede devolver esta función? ¿Cómo debería ser este argumento? ¿Qué puede significar este nombre?

Puede que haya documentación, pero que sea ambigua o poco precisa.

Even if there is a docstring, it’s often ambiguous or imprecise, leaving a lot of room for misunderstandings.

Si definimos los tipos y podemos verificarlos, tenemos algunas ventajas: no poner datos en lugares donde no serán bien recibidos, por ejemplo. Pero también, por ejemplo, poder cambiar el código (refactorizar) más fácilmente:

Refactoring is much easier, as the type checker will often tell exactly what code needs to be changed.

El trabajo se ha desarrollado sobre casi 5 millones de líneas de código y ha permitido mejorar la situación:

It has been a long journey from the early prototypes to type checking 4 million lines in production. Along the way we’ve standardized type hinting in Python,…

La organización ha asumido este trabajo como propio y ya se da por supuesto, pero aún queda camino por recorrer:

Even though type checking is already taken for granted at Dropbox, I believe that we are still in early days of Python type checking in the community, and things will continue to grow and get better

Intersante.

Análisis de amenazas de un sistema de cifrado entre extremos para videoconferencia

Cámara Zoom ha sido uno de los vencedores de la pandemia. Es una plataforma de videoconferencias sencilla de usar, que funciona bastante bien (casi todas hoy en día, esa es la verdad) y que para mucha gente ha sido un verdadero hallazgo.

En Trusting Zoom? que no me importan tanto por la plataforma en sí, sino por el análisis que hace de algunas prevenciones que se comentaron durante el inicio de la pandemia. Ya digo que algunas cosas habrán cambiado (y sigue habiendo polémicas sobre la plataforma, al máximo nivel Zoom lied to users about end-to-end encryption for years, FTC says).

Lo primero que dice es que, a pesar de los puntos débiles, la plataforma proporciona un servicio con unos beneficios tan importantes en aquel momento que superarían los inconvenientes, salvo que perjudicasen notablemente a alguien:

In other words, the benefit of using Zoom is considerable, and I have an ethical obligation to do it unless the risks to me, to my students, or to the university are greater.

Prefiere la aplicación porque no se fía de los navegadores:

My reasoning for not using the browser option is a bit different: I don’t trust browsers enough to want one to have the ability to get at my camera or microphone.

Sobre todo porque cualquier fallo le pondría en un compromiso sólo cuando utilizara la aplicación y no el navegador, que lo usa mucho más:

But apart from my serious privacy reservations, flaws in the Zoom app put me at risk while using Zoom, while flaws in a browser put me at risk more or less continuously.

Sus clases, al final son públicas (para su audiencia, e incluso cuelga materiales de manera pública)

But apart from my serious privacy reservations, flaws in the Zoom app put me at risk while using Zoom, while flaws in a browser put me at risk more or less continuously.

Y luego se pregunta si las debilidades de Zoom son suficientemente importantes para evitar su uso:

Are Zoom’s weaknesses sufficiently serious that my university—and I—should avoid it?

Sobre los métodos criptográficos utilizados, sin ser los mejores, parecen suficientes para lo que se está haciendo:

That’s already a substantial part of the answer: I’m not worried about the Andromedan cryptanalysts trying to learn about my students’ personal tragedies. Yes, I suppose in theory I could have as a student someone who is a person of interest to some foreign intelligence agency and this person has a problem that they would tell to me and that agency would be interested enough in blackmailing this student that they’d go to the trouble of cryptanalyzing just the right Zoom conversation—but I don’t believe it’s at all likely and I doubt that you do.

Por otra parte, ese atacante tendría que tener acceso de alguna forma al tráfico de la red:

There’s another part of the puzzle for a would-be attacker who wants to exploit this flaw: they need access to the target’s traffic. […] Routing attacks don’t require a government-grade attacker, but they’re also well up there on the scale of abilities.

Por lo que atacar y sacar partido del cifrado entre extremos sería algo complejo:

What it boils down to is this: exploiting the lack of true end-to-end encryption in Zoom is quite difficult …

Finalmente, destaco que el autor trata de hacer todo su contenido académico público, así que tampoco teme los robos. Puede haber excepciones:

Nothing that I personally do would seem to meet that first criterion—I try to make all of my academic work public as soon as I can—but there are some plausible university activities, e.g., development of advanced biotechnology, where there could be such governmental interest.

Como decía, me pareció una lectura interesante.

Esquema del sistema de ficheros en un sistema Linux

Fichas para perforar Hace no mucho he descubierto dev.to, una comunidad de desarrolladores que van compartiendo conocimiento e información. Muchas veces, casi a modo de recetas. En esta ocasión traigo Navigating files in Linux que habla del sistema de ficheros de Linux y cómo se organizan algunas cuestiones alrededor de él.

En Linux todo es un fichero:

On Linux, everything on the system is represented with a file—Keyboards, disk drives, robotic arms, running programs and the rest: All files. Naturally, a Linux system needs a lot of files—And a sensible way to organize them.

Y luego pasa a detallar la estructura de un sistema de ficheros y qué podemos esperar encontrar en cada sitio. Interesante.

Si quieres tener la información correcta en el avión, apaga y vuelve a encender

Alavionismo El viejo truco informático, sobre todo en sistemas domésticos o poco comprometidos, es apagar y volver a encender el sistema en cuestión antes de dar ningún otro paso. Eso no siempre es posible, y uno esperaría que en sistemas más profesionales esto no fuera necesario. Sin embargo, y en el apartado de cosas que uno no esperaría que puedan suceder en este curioso artículo Boeing 787s must be turned off and on every 51 days to prevent ‘misleading data’ being shown to pilots nos cuentan que los sistemas informáticos de estos aviones necesitan apagarse y volverse a encender para estar seguros de que mostrarán la información correcta a los pilotos.

Como anécdota personal, en cierta ocasión no funcionaba el sistema de entretenimiento (la pantallita) y la azafata la arregló apagando y volviendo a encender mi ordenadorcito, no sin insistir un poco porque no parecía darle importancia.

Esta necesidad viene en forma de orden de la Administración Federal de Aviación de EEUU:

The US Federal Aviation Administration has ordered Boeing 787 operators to switch their aircraft off and on every 51 days to prevent what it called “several potentially catastrophic failure scenarios” – including the crashing of onboard network switches.

El problema sería que los pilots podrían ver información incorrecta:

According to the directive itself, if the aircraft is powered on for more than 51 days this can lead to “display of misleading data” to the pilots, with that data including airspeed, attitude, altitude and engine operating indications. On top of all that, the stall warning horn and overspeed horn also stop working.

Por devolver la fe sobre estas cosas siempre le podemos echar la culpa en el caso del Boeing a que se trata de sistemas antiguos. El otro día podíamos leer U.S. Air Force Performs First Ever Code Change On A Flying U-2 Spyplane Running Kubernetes. Allí nos explican un caso de un avión espía U-2 actualizando código mediante este sistema de contenedores, en vuelo. Eso sí, no está claro el alcance de la actualización.

We don’t have the whole details here, so the extent of the “update” is not clear (actually, the deployment of a new container in Kubernetes can be seen more like a configuration update than a code change). Anyway, the achievement of the latest milestone proves that the U.S. Air Force is continuing to advance in its program to give its weapons system the ability to leverage the power of containerization.

Interesante.

Actualización (2020-11-03): En otros modelos de la casa, nos enteramos de que Boeing 747s still get critical updates via floppy disks.

Pen Test Partners discovered a 3.5-inch floppy disk drive in the cockpit, which is used to load important navigation databases. It’s a database that has to be updated every 28 days, and an engineer visits each month with the latest updates.

Algoritmos de diferencias y git

2013-10-11-facebook Los sistemas de control de versiones se basan en poder calcular de manera eficiente la diferencia entre dos ficheros. En How different are different diff algorithms in Git? hablan justamente de eso.

Identifican tres casos de uso de estas diferencias y comparan sus prestanciones.

From our systematic mapping, we identified three popular applications of diff in recent studies.

Fundamentalmente: recolección de métricas, identificar la introducción de fallos (bugs) y obtener parches (patches). Con dos algoritmos, Myers e Histogram.

In our empirical analyses, we conduct three comparisons based on the most popular usages of git diff found in our mapping study: collecting metrics, identifying bug introduction, and getting patches. We investigate the disagreement between two diff algorithms: Myers and Histogram, and take a manual measurement of their quality in generating the diff lists.

Lectura interesante.

Pruebas y verificación de programas

CEDI. The ideal of Verified Software. Un ejercicio curioso en Getting a program right, in nine episodes donde Bertrand Meyer nos acompaña donde desarrolla un programa sencillo y lo va mejorando mediante técnicas de verificación formal.

Aunque el testing ha ganado muchos adeptos hay que recordar lo que decía Dijkstra: las pruebas pueden demostrar la presencia de errores, no su ausencia.

in fact, I have always thought that the inevitable Dijkstra quote about testing — that it can only show the presence of errors, not their absence

Esto no es hablar mal de las pruebas, es sensacional poder encontrar partes de nuestros programas que están mal.

La verificación aporta otro tipo de valores, y de eso va lo que se puede leer allí. El programa es una búsqueda binaria, que es un concepto fácil de entender, pero no tan sencillo de hacer complemtamente bien.

Interesante.

Vulnerabilidades frecuentes en 'smart contracts'

Libro. Contrato con Dios De la mano de blockchain han venido los smart contracts: se trata de ‘programas’ o ‘codificaciones’ de intenciones, condiciones y consecuencias que gracias a esta tecnología permitirían que determinados contratos puedan ejecutarse sin necesidad de que los humanos intervengan (en la realización de los hechos del contrato en sí, se entiende).

Desde la ignorancia informada, uno siempre ha pensado que si se ha de codificar determinadas condiciones de la vida en un contrato la cosa ya es suficientemente compleja. Si a eso le añadimos la ejecución automatizada, es probable que haya que hilar más fino. Y, claro, aparecen los bugs y las vulnerabilidades.

De esto hablaban en Las 5 vulnerabilidades más habituales de los Smart Contracts y lo más gracioso es que los fallos se parecen mucho a los de los programas ‘normales’.

  • Errores aritméticos con números enteros

Desbordamientos, falta de precisión, …

  • Vulnerabilidades del límite de block gas

El límite de block gas es la forma que tiene Ethereum de asegurarse de que los bloques no crezcan demasiado. Simplemente significa que los bloques están limitados en la cantidad de gas que las transacciones contenidas en dichos bloques pueden consumir. En pocas palabras, si una transacción consume demasiado gas nunca cabrá en un bloque y, por lo tanto, nunca se ejecutará.

En determinadas circunstancias esto provoca que haya instrucciones de los contratos que nunca llegan a ejecutarse.

  • Falta de parámetros o controles de precondición

Si hace falta que algo se cumpla a la hora de ejecutar un contrato, debemos estar seguros de que los datos que se reciben son adecuados.

  • Frontrunning

El frontrunning potencial es probablemente el tema más difícil de prevenir en nuestra lista de vulnerabilidades comunes. Este puede definirse como la apropiación de una transacción no confirmada, y es consecuencia de la propiedad de transparencia del blockchain.

  • Bugs de lógica simples.

No hace falta buscar, de todas formas, fallos muy sofisticados. Parece que es frecuente encontrar:

… el problema más común que detectamos es la presencia de errores simples en la lógica del smart contract. Estos errores pueden ser el resultado de una simple errata, una mala comprensión de la especificación o un error de programación mayor …

Interesante.