Anatomía de un ataque

Intento de robo de credenciales

Una fuente habitual de los problemas de seguridad es la interacción insegura entre sistemas que pueden ser (más o menos) seguros. También puede ocurrir que no lo sean, claro. En Anatomy of a Hack nos contaban el caso de Partap Davis:

In the early morning hours of October 21st, 2014, Partap Davis lost $3,000. He had gone to sleep just after 2AM in his Albuquerque, New Mexico, home after a late night playing World of Tanks. While he slept, an attacker undid every online security protection he set up. By the time he woke up, most of his online life had been compromised: two email accounts, his phone, his Twitter, his two-factor authenticator, and most importantly, his bitcoin wallets.

Davis había seguido todos los consejos de seguridad habituales (claves fuertes, doble factor, ….). Pero a través de un fallo en su proveedor de correo (mail.com) el atacante va haciéndose con el control de otras cuentas del usuario hasta hacerse con su cuenta de Bitcoins (que supone coste económico, claro).

Me ha recordado otro que comentamos hace tiempo en Los riesgos de la nube donde se contaba otro ataque similar.

Cuando alguien va a por nosotros (o tenemos mala suerte y alguien nos dedica atención) tenemos pocas posibilidades.

¿Te puedes fiar del vendedor de tu ordenador?

Web

Si has estado atento a las noticias de informática en los últimos meses seguramente has oído/leído algo sobre Superfish. Con la intención de ofrecer productos similares a los que los usuarios supuestamente podrían estar interesados Lenovo introdujo una herramienta para interceptar el tráfico web (y, en particular, el tráfico cifrado).

Traigo aquí un resumen en A third-party, man-in-the-middle proxy used by Superfish is also used in other apps donde nos alertaban. No solo de lo mala que era la idea en sí sino también, claro, de las consecuencias laterales (y no previstas): que otras aplicaciones traten de sacar partido de este ‘truquillo’.

La explicación del modo de funcionamiento, un proxy que se colocaba entre nuestra conexión y los sitios que queríamos visitar:

Superfish uses a man-in-the-middle proxy component to interfere with encrypted HTTPS connections, undermining the trust between users and websites. It does this by installing its own root certificate in Windows and uses that certificate to re-sign SSL certificates presented by legitimate websites.

La utilización de un certificado común para todos los sistemas:

Security researchers found two major issues with this implementation. First, the software used the same root certificate on all systems and second, the private key corresponding to that certificate was embedded in the program and was easy to extract.

Y, finalmente, la utilización de componentes de terceras partes para toda esta maniobra, lo que haría posible su utilización por parte de otros programas

But it gets worse. It turns out Superfish relied on a third-party component for the HTTPS interception functionality: an SDK (software development kit) called the SSL Decoder/Digestor made by an Israeli company called Komodia.

Para eliminarlo hay instrucciones en Superfish, Komodia, PrivDog vulnerability test (updated again!) y también la propia Lenovo proporciona herramientas: SuperFish Uninstall Instructions.

A lo mejor lo más directo sería borrar el sistema e instalar uno limpio (con la ventaja de que, seguramente, quitaríamos otras cosas que no sean tan peligrosas, pero puedan ser molestas o poco convenientes).

Ya hemos hablado algunas veces de confianza por aquí y siempre conviene recordar el clásico Reflections on trusting trust y uno más reciente del que hablábamos en La confianza.

Algunos problemas de la biometría

Dedo

Recientemente hemos visto alguno de los problemas de la biometría: una vez que te roban, no puedes cambiar de huellas dactilares 5.6 million reasons fingerprints shouldn’t be used as passwords

Este verano se celebró el Black Hat USA 2015 y entre las presentaciones disponibles en la web acabo de ver una que habla de más problemas: [PDF]Hidden Risks of Biometric Identifiers and How to Avoid Them donde el autor hace una buena presentación del tema.

Según él, los riesgos son:

  • Confiabilidad de la biometría la percepción que tenemos de ella.
  • Falta de discusión sobre las consecuencias de los errores.
  • Irreversibilidad de los datos biométricos y sus implicaciones.
  • Nuestros datos biométricos pueden ser obtenidos sin nuestro consentimiento
  • Nuestro comportamiento puede delatarnos - a veces de manera incorrecta
  • Proporcionar nuestros datos biométricos y comportamentales puede llegar a ser obligatorio (al menos, de facto).
  • Ladrones de datos biométricos y agregadores

Hace algún tiempo comentamos las “Guías sobre biometría del INTECO” con algunos enlaces más.

Informe sobre la seguridad de datos en empresas

Patching

Hoy traemos un informe sobre seguridad de datos en las empresas, patrocinado por Oracle: [PDF] DBA-Security superhero lo que más me ha gustado (o llamado la atención) es una de las últimas gráficas. Concretamente la figura 32: en ella podemos ver que casi un 50% de los que respondieron a la encuesta actualizan los parches críticos dentro del ciclo o en el siguiente. Lo que nos deja con algo más del 50% que irían con un retraso de más de 9 meses y un nada despreciable 15% que no actualizan nunca o se encuentran en otra situación.

Ya hemos hablado de Las actualizaciones o en Los parches hay que aplicarlos.

Sobre GCC, LLVM, competencia, obsolescencia y avances

Obsolescencia

Hace mucho que no se habla demasiado de compiladores. Sin embargo, ya lleva entre nosotros una temporada The LLVM Compiler Infrastructure que es una plataforma para desarrollar un compilador reutilizable que, además, permitiría la construcción de compiladores no libres sobre su infraestructura (lo que lamentaba Richard Stallman en Re: clang vs free software.

En todo caso, para los amantes de la velocidad y la mejora la competencia es buena y, en ese sentido, es posible que merezca la pena darle una oportunidad para algunos proyectos.

En todo caso, traigo aquí Defending GCC considered futile donde Eric S. Raymond donde hace autocrítica sobre el GCC:

The reason has nothing to do with any philosophical issue but merely the fact that compiler technology has advanced significantly in ways that GCC is not well positioned to exploit.

En parte refuerza el argumento anterior, la competencia nos hace reconsiderar algunas posturas; por otra parte, iniciar un proyecto nuevo nos libera de decisiones pasadas.

Interesante, aunque no te intersen para nada los compiladores.