En How a single line of code brought down a half-billion euro rocket launch la historia del lanzamiento en 1996 del cohete Arianne 5 y su explosión 40 segundos después del lazamiento.

Just 40 seconds after take-off, however, huge chunks of metal and burning fragments of Ariane Flight 501 are crashing down over the launch area. A shocking disaster for the ESA and a rough setback for the mission.

¿El problema? Un trozo de código, que provenía de la misión Arianne 4 y que ni siquiera se utilizaba.

The cause? A simple, and very much avoidable coding bug, from a piece of dead code, left over from the previous Ariane 4 mission, which started nearly a decade before. Here’s what happened exactly.

El problema se debió a un fallo típico de desbordamiento pero de los que ni siquiera se suele hablar mucho: cuando se convierte un número real de 64 bits en uno de 16 bits con signo.

To achieve this, the guidance system converts the velocity readings, from 64 bit floating point to 16 bit signed integer.

Si hacemos las cuentas, con 16 bits podemos almacenar cualquier número entre 0 y 65535 sin signo, y entre -32768 y 32767 si contemplamos números con signo.

With 16-bit unsigned integers, you can store anything from 0 to 65,535. If you use the first bit to store a sign (positive/negative) and your 16-bit signed integer now covers everything from -32,768 to +32,767 (only 15 bits left for the actual number). Anything bigger than these values and you’ve run out of bits.

Por otra parte, los números reales se almacenan de manera diferente porque tṕicamente almacenan números más grandes y, además, deben gestionar la parte decimal (me gustó como lo cuentan en Examples of floating point problems, por ejemplo).

En el caso del cohete, al almacenar un número real en las posiciones reservadas para un número entero se quedó sólo con la primera parte del mismo, generando un desbordamiento de enteros.

Well, in this case, when the 16-bit signed integer was used, the conversion from float to integer wrapped around to the beginning again and finally ran into the very familiar integer overflow. Riight, so back to the rocket story.

El sistema de control detecta que los datos son inconsistentes, trata de arreglar el problema y (aquí viene el segundo problema) lanza el sistema secundario que ejecuta exactamente el mismo código.

But wait a minute, there might be a saving chance! The system is designed to have a backup, standby system, which unfortunately, runs the exact same code. It tries the same conversion, gets the same error and just 72 milliseconds later, promptly crashes.

El sistema de control da por bueno el resultado, y el cohete recibe las instrucciones incorrectas.

Sin embargo, si este sistema ya se usaba anteriormente, ¿por qué no había fallado antes? Parece que el problema en este caso era que en las versiones del cohete la velocidad era menor y, por lo tanto, no tenían este problema.

The same software was designed and used successfully on many flights previously, on the Ariane 4 rockets, which were much smaller. But the new Ariane 5 model was designed to fly faster than the systems engineers had planned when that code was originally created.

Finalmente, el código no era necesario después del despegue, así que no debería haber estado ejectutándose, pero para evitar reconfiguraciones en ese momento permitieron que ese código siguiera ejecutándose un poco más, ¡esos 40 segundos!

The worst part? The code wasn’t necessary after takeoff, it was only part of the launch pad alignment process. But sometimes a trivial glitch might delay a launch by a few seconds and, in trying to save having to reset the whole system, the original software engineers decided that the sequence of code should run for an extra… 40 seconds after the scheduled liftoff.

Uno de los problemas del internet de las cosas y sus dispositivos mínimos es la criptografía; al fin y al cabo, los algoritmos criptográficos suelen utilizar operaciones matemáticas costosas, que no siempre son posibles en estos aparatitos.

Tratando de aligerar el problema conocíamos la noticia de que el NIST Selects ‘Lightweight Cryptography’ Algorithms to Protect Small Devices.

Se trataría de proteger la información en estos dispositivos de capacidad escasa con algún mecanismo de lo que llaman criptografía ligera.

The chosen algorithms are designed to protect information created and transmitted by the Internet of Things (IoT), including its myriad tiny sensors and actuators. They are also designed for other miniature technologies such as implanted medical devices, stress detectors inside roads and bridges, and keyless entry fobs for vehicles. Devices like these need “lightweight cryptography” — protection that uses the limited amount of electronic resources they possess.

Los parámetros considerados eran la seguridad, claro, pero también prestaciones y flexibilidad en términos de velocidad, tamaño y utilización de la energía.

“We considered a number of criteria to be important,” McKay said. “The ability to provide security was paramount, but we also had to consider factors such as a candidate algorithm’s performance and flexibility in terms of speed, size and energy use.

El anuncio está en Lightweight Cryptography Standardization Process: NIST Selects Ascon y se trata de la estandarización de la familia de algoritmos criptográficos denominada Ascon desarrollada en 2014 por un equipo de criptógrafos de Graz University of Technology, Infineon Technologies, Lamarr Security Research y Radboud University.

Las APIs permiten el acceso a nuestros programas (y, al final, a los datos) de manera alternativa a la tradicional de las interfaces web o mediante programas. Últimamente veo bastantes lecturas relacionadas con la seguridad. En parte, probablemente, porque al tratarse de accesos más controlados (o aparentemente más controlados) no siempre están tan bien aseguradas como deberían.

En Quick way to Secure API Keys for the Frontend nos hablan de un problema interesante, que tiene que ver con el acceso a estas APIs a través de diversos frontales (frontends) y la gestión de las contraseñas (que pueden estar incluso en el código).

We all know that API keys and connections can not be secured on the client side of an application. Hard coding API keys on the frontend is a quick and surefire way to have your API connection shutdown, API keys stolen, and have your API provider’s bill skyrocket.

Hay formas de evitar exponer secretos de esta forma y las tres que proponen son:

• Funciones serverless que interactúan con algún servicio que gestiona las contraseñas (por ejemplo AWS Lambda).
• Funciones de Netlify. En este caso es un servicio, que interactuaría con el verdadero almacén (nuevamente AWS Lambda).
• Otro servicio, KOR Connect que permite gestionar los accesos sin que las credenciales aparezcan el código de nuestro frontal.

Igual es demasiado técnico (y orientado a productos) pero creo que nos puede ayudar a pensar en las nuevas necesidades que provoca hacer las cosas de una forma determinada.

Otra forma curiosa de espionaje: EarSpy: Spying on Phone Calls via Ear Speaker Vibrations Captured by Accelerometer.

Investigadores de Texas A&M University, Temple University, New Jersey Institute of Technology, Rutgers University, y la University of Dayton han publiado un artículo ([PDF] EarSpy: Spying Caller Speech and Identity through Tiny Vibrations of Smartphone Ear Speakers) donde proponen observar el altavoz que se pone en el oído y el acelerómetro del terminal para capturar las vibraciones y espiarnos.

EarSpy relies on the phone’s ear speaker — the speaker at the top of the device that is used when the phone is held to the ear — and the device’s built-in accelerometer for capturing the tiny vibrations generated by the speaker.

Ya había propuestas basadas en los altavoces del teléfono, pero la novedad aquí parece ser que no es necesario recurrir a elementos externos para realizar el espionaje. Sin olvidar que cada vez es más complicado en Android obtener los permisos necesarios para realizar otros ataques, para otros ataques más obvios (grabar la conversación del teléfono directamente).

Porque parece que obtener los datos de los sensores de movimiento del teléfono no necesita ningún permiso especial.

On the other hand, accessing raw data from the motion sensors in a smartphone does not require any special permissions. Android developers have started placing some restrictions on sensor data collection, but the EarSpy attack is still possible, the researchers said.

Sí que haría falta, claro, algún tipo de programa (malware) que hiciese este trabajo.

Todo se basa en que estos altavoces para escuchar las llamadas son cada vez mejores (incluso los hay que son estéreo).

Entre los resultados, se puede distinguir el género con un 98% de precisión, y la identidad con hasta un 92%.

In the gender recognition test, whose goal is to determine whether the target is male or female, the EarSpy attack had a 98% accuracy. The accuracy was nearly as high, at 92%, for detecting the speaker’s identity.

En cuanto a la posibilidad de escuchar la conversación la precisión se reduce a un 52% para reconocer dígitos en una conversación.

When it comes to actual speech, the accuracy was up to 56% for capturing digits spoken in a phone call.

Puede parecer poco, pero multiplica por 5 la prueba de valores de modo aleatorio.

Curioso.

Si hay un invariante en ciberseguridad es que da igual que seas grande o pequeño puedes tener incidentes de seguridad. En PayPal accounts breached in large-scale credential stuffing attack nos hablan de un ataque para conseguir credenciales de usuarios de PayPal. El método utilizado es viejo, pero eficaz, si uno tiene tiempo y ganas: ir probando usuarios y contraseñas obtenidos de diversos ataques anteriores, donde ya se han divulgado los datos.

Credential stuffing are attacks where hackers attempt to access an account by trying out username and password pairs sourced from data leaks on various websites.

La cuestión es que cuando tienes un número de usuarios importante es bastante seguro que habrá algunos de ellos que reciclen sus credenciales (esto es, que usen las mismas en varios sitios).

El ataque se produjo en diciembre del 2022 y se vieron afectados casi 35000 usuarios.

According to the data breach reporting from PayPal, 34,942 of its users have been impacted by the incident. During the two days, hackers had access to account holders’ full names, dates of birth, postal addresses, social security numbers, and individual tax identification numbers.

Parece raro que PayPal no se diera cuenta antes del ataque, pero a veces las cosas son así.

Como medida de prevención, en este caso, está clara: utilizar doble factor de autentificación. Ya sabemos que aún así habría gente afectada, pero seguramente muchos menos.

Moreover, PayPal advises users to activate two-factor authentication (2FA) protection from the ‘Account Settings’ menu, which can prevent an unauthorized party from accessing an account, even if they have a valid username and password.

Y, por supuesto, no usar la misma contraseña en varios sitios.