Más sobre borrado seguro de datos

Discos Ya hace tiempo hablábamos del tema en Borrar datos es difícil donde se cuentan algunos detalles sobre lo difícil que puede ser eliminar completamente cualquier rastro de datos de nuestros discos.

En 48 Percent of Used Hard Drives Sold Online Contain Residual Data publicaban algunas estadísticas de recuperación de información en discos usados que se encuentran a la venta por ahí. Todo el mundo intenta alguna forma de borrado antes de desprenderse del disco, pero pocas son eficaces:

“One of the more glaring discoveries from our study is that most people attempt in some way or another to delete their data from electronic equipment. But while those deletion methods are common and seem reliable, they aren’t always effective at removing data permanently and they don’t comply with regulatory standards.”

Hacen referencia al estudio A study on data security in used mobile devices & hard drives.

Además, en ¿Seguro que lo has borrado? David García nos hace un breve resumen del tema y una presentación de algunas herramientas para borrado seguro.

Recuperación de contraseñas con preguntas personales

Intento de robo de credenciales

Tengo que reconocer que me encanta el tema de las contraseñas, gestión, almacenamiento, recuperación… También que se leen muchas cosas por ahí y que no siempre están respaldadas por información actualizada y obtenida por medios más o menos rigurosos. Por eso me he leído rápidamente un artículo de Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson y Mike Williamson, Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google donde se habla de algunos datos obtenidos en Google sobre la validez y gestión de los sistemas de recuperación de cuentas basados en preguntas secretas. Recordemos que el ‘folklore’ suele decir que una pregunta secreta sólo es una contraseña más débil.

Su análisis parece confirmar que la pregunta de seguridad rebaja el nivel de seguridad y esto sucede, curiosamente, porque los usuarios no son sinceros y tratan de inventarse las respuestas para hacerlas más seguras (lo que, en agregado, hace que sean peores). También muestran que es casi imposible conseguir preguntas cuyas respuestas sean fáciles de recordar y que a la vez sean seguras.

Abstract: We examine the first large real-world data set on personal knowledge question’s security and memorability from their deployment at Google. Our analysis confirms that secret questions generally offer a security level that is far lower than user-chosen passwords. It turns out to be even lower than proxies such as the real distribution of surnames in the population would indicate. Surprisingly, we found that a significant cause of this insecurity is that users often don’t answer truthfully. A user survey we conducted revealed that a significant fraction of users (37%) who admitted to providing fake answers did so in an attempt to make them “harder to guess” although on aggregate this behavior had the opposite effect as people “harden” their answers in a predictable way. On the usability side, we show that secret answers have surprisingly poor memorability despite the assumption that reliability motivates their continued deployment. From millions of account recovery attempts we observed a significant fraction of users (e.g 40\% of our English-speaking US users) were unable to recall their answers when needed. This is lower than the success rate of alternative recovery mechanisms such as SMS reset codes (over 80%). Comparing question strength and memorability reveals that the questions that are potentially the most secure (e.g what is your first phone number) are also the ones with the worst memorability. We conclude that it appears next to impossible to find secret questions that are both secure and memorable. Secret questions continue have some use when combined with other signals, but they should not be used alone and best practice should favor more reliable alternatives.

Hay muchos más hallazgos y vale la pena leer el artículo; por ejemplo, algo que no nos soprenderá: la respuesta a las preguntas secretas es peor conforme pasa el tiempo porque no la recordaremos.

Hace algún tiempo comentábamos en Las claves sobre los sistemas de recuperación y el entrevistado los defendía, si se seleccionaban adecuadamente las preguntas secretas. Por cierto, en la Forgot Password Cheat Sheet sigue incluyendo la parte de las preguntas aunque habla más bien de asegurarse de la identidad, lo que significa que el enfoque también ha cambiado un poco.

¿La apuesta de Google hoy en día? Recuperación a través del móvil (SMS) y el correo.

Aunque los malos ya se lo han aprendido (Si Google te envía un SMS para decirte que alguien ha accedido a tu cuenta… ¡Cuidado! y seguramente veamos dentro de poco más ataques sobre estos sistemas (sin olvidar que son muy poco fuera de banda, al estar muchas veces en el mismo dispositivo que las apps que intentan autentificarse).

Mala seguridad, routers y ataques

Antenas

Otra entrada sobre un ataque (esta vez a gran escala) por malas prácticas de seguridad. En Lax Security Opens the Door for Mass-Scale Abuse of SOHO Routers nos cuentan algunos erores de seguridad que llevaron a tener conectados a internet en casa de mucha genet routers con configuraciones inseguras. Gracias a eso, fue posible orquestar ataques distribuidos de denegación de servicio (DDOS) con una cierta incidencia.

Se trataba de routers SOHO cuya interfaz de configuración estaba accesible a internet sin problemas, y configurados con claves elegidas por defecto por el proveedor (amiguitos, cambiad la clave de vuestro router. ¡Ya!):

However, further inspection revealed that all units are remotely accessible via HTTP and SSH on their default ports. On top of that, nearly all are configured with vendor-provided default login credentials.

En este caso estas vulnerabilidades no se utilizaban para atacar a los propios usuarios (aunque seguramente en algunos casos también) sino para infectar los propios routers y lanzar los ataques desde allí. Naturalmente, esto también implicaba la idea de infectar nuevos routers que pudieran estar a su alcance.

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.

Aleatoriedad y juego en línea

Casino físico

Si alguien nos preguntase sobre si la aletoriedad es importante en seguridad, seguramente diríamos que sí. Si luego nos preguntaran cuánta atención habíamos dedicado a ella en nuestros proyectos tengo serias dudas sobre las respuestas. En este sitio se nos van acumulando ya las lecturas sobre el tema, pero siguen apareciendo nuevas. Y nos gusta referenciarlas.

Ahora es The Role of Randomness in Online Gambling. En este caso el artículo me ha gustado porque no incide tanto en la parte más teécnica como en los aspectos relacionados con el juego y los jugadores.

Sobre la percepción de la necesidad:

We intuitively recognize that, if the chance element of the game was not truly random—and if some players had knowledge of the non-randomness—then informed players would have an unfair advantage over uninformed players.

Sobre la forma de medirla:

Often randomness is asserted through the results of statistical analysis. Software like Dieharder will take a sample of output from a supposedly random source and identify statistically improbable outcomes. The result is confidence (not proof) that a given result set is random.Predictability has to do with whether or not the outcome of a random event can be known in advance (partially or completely).

No todo es aleatorio todo el rato:

Consider poker: there is exactly one random event in a game of poker. The deck is shuffled randomly. That’s it. The rest of the game is down to the actions of the players.

Últimamente hemos hablado de aleatoriedad en.

Números aleatorios seguros en Java

Generador de números aleatorios de Intel

Un informe sobre ciberseguridad en Europa

Mandos

El verano es para ponerse al día con las lecturas pendientes (que es algo que no he conseguido). En este caso, a título de inventario un informe: EU Cybersecurity Dashboard de la BSA - The Software Alliance. Interesante para comparar unos países con otros, ver las cosas que se están haciendo (y las que no).

El resumen para España:

Spain adopted the National Cyber Security Strategy in 2013. It is a comprehensive document, which sets objectives and targeted lines of actions. It is compatible with, and references, both the National Security Plan and existing security laws; and these plans and laws work together as a package.

Spain has established two CERTs, INTECO-CERT and CCN-CERT, and the National Centre for Critical Infrastructure Protection (CNPIC). The latter appears to be the premier agency for information security and cybersecurity, while the role of the CERTs is limited to dealing with cybersecurity incidents. CNPIC is responsible for ensuring coordination and cooperation between the public and private sector. It also runs sectoral working groups and is working toward the development of sector-specific cybersecurity plans.

Additionally, cooperation with the private sector is formalised through the National Advisory Council on Cybersecurity, established in 2009, whose members are private sector representatives. The council is tasked with providing policy advice to the government, although its current status is somewhat unclear. Private sector associations are also active, with two prominent bodies dedicated specifically to cybersecurity and information security, as opposed to general IT matters.