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.

A veces las ideas más simples son las más útiles. En Pwned or Bot Troy Hunt nos contaba omo su base de datos de cuentas robadas puede servir para detectar usuarios leg´timos: si tu correo nunca ha aparecido en un volvado de datos de algún problema de seguridad de una empresa, es bastante probable que no sea legítimo, o que haya sido creado recientemente para tratar de engañar a alguien.

If an email address hasn’t been seen in a data breach before, it may be a newly created one especially for the purpose of gaming your system.

Está claro que el argumento tiene fallos: puedes tener tu correo muy bien protegido, o ser un usuario nuevo que lo ha creado recientemente, … No estar en uno de esos listados es un indicio, pero no garantiza nada.

Absence of an email address in HIBP is not evidence of possible fraud, that’s merely one possible explanation.

Por el contrario, si un correo está en alguna de las divulgaciones de datos robdos en el pasado, podemos decir con un nivel de confianza alto, que es un correo legítimo.

However, if an email address has been seen in a data breach before, we can say with a high degree of confidence that it did indeed exist at the time of that breach.

Al final, claro, no se trata de un indicador perfecto, sino un elemento más a la hora de evaluar la probabilidad de que estemos ante una dirección de correo más o menos falsa, que trata de abusar de nuestro servicio.

Think of breach history not as a binary proposition indicating the legitimacy of an email address, rather as one of assessing risk and considering “pwned or bot” as one of many factors

Curioso.

Ya hemos hablado algunas veces de fuzzing para tratar de mejorar la calidad de las aplicaciones: la idea es probar a enviar entradas aleatorias (basura) a nuestras aplicaciones y estudiar como fallan. Traemos hoy aquí un artículo donde se habla de How eBay’s Notification Platform Used Fault Injection in New Ways. No se trata exactamente de inyección de entradas aleatorias, pero sí de provocar fallos de manera deliberada, con el objetivo de observar cómo se comporta la plataforma.

Fault injection is the process by which we deliberately introduce faults into the system. We can observe the system behavior with the injected faults to identify the weakness of the system.

Como se trata de una plataforma de la que dependen otras, el objetivo es ver qué sucederá al introducir los problemas cuando estos sistemas reciban las respuestas defectuosas provacadas por los fallos.

Any faults in these dependent services will directly impact the stability of the system, so it’s quite valuable to run experiments in the system containing the failures of these dependencies, in order to understand the behaviors and mitigate any weaknesses.

El tipo de fallos de los que estamos hablando son muy diversos: desde fallos de red (desconectar la conexión temporalmente, por ejemplo), llenar un sistema de ficheros (para provocar fallos de falta de espacio), a nivel de infraestructura.

For example, to introduce the http disconnection or timeout error, one option is to turn off the network or shut down the downstream services temporarily; to introduce the disk full error, one option is to create a bunch of files in the file system.

Pero también podemos pensar en crear fallos a nivel de la aplicacion. En lugar de desconectar una interfaz de red, insertar en la biblioteca correspondiente algún retraso significativo. O, directamente, un código de respuesta de error.

For example, to inject the http timeout fault, we add the latency in the http client library; to simulate the internal service error, we simulate the response code with 500 http status code. The faults are restricted to the API level and do no harm to the underlying infrastructure resources.

Para conseguir este tipo de fallos lo que se hace es instrumentar las bibliotecas correspondientes (esto es, modificarlas para que contengan las respuestas que nos interesa que aparezcan).

To simulate the faults for the client libraries by instrumentation is challenging. Our main task is to force the invoked methods to experience failures. One method to do this is to inject failure directly into the method, by, for example, throwing the exception in the method body.

Fundamentalmente, se utilizan tres métodos: bloquear o interrumpir la lógica del método, cambiar el estado de los parámetros del método, o reemplazar el valor de los parámetros del método.

1. Block or interrupt the method logic
2. Change the state of method parameters
3. Replace the value of method parameters

Para poder manejar todo esto con cierta soltura parece imprescindible poder cambiar el contexto con facilidad, y para eso es necesaria una buena gestión de configuraciones.

To dynamically change the configuration for the fault injections in the runtime, we have implemented a configure management console in the Java agent.

Muy interesante.