Actualizando. Espere

Actualización Como por efecto mágico, nuestro sistema siempre decide actualizarse cuando menos conviene. Es paradigmático y forma parte de casi cualquier acto que se organiza cuando esos PCs proporcionados por la organización empiezan a mandar avisos diversos, muchos de ellos de actualizaciones de programas.

En este caso no sabemos si es la típica excusa (‘mi perro se comió los deberes’, ‘falló el ordenador’) pero nos contaban en German pro basketball team relegated to lower division due to Windows update de un equipo de baloncesto que habría visto afectada su participacińo en la liga cuando el equipo que manejaba el marcador comenzó a actualizarse antes de empezar el partido y retrasó todo.

“But as both teams warmed up, the computer crashed,” he said. “When we booted it again at 7:20pm, it started automatically downloading updates. But we did not initiate anything.”

After all the updates were installed, Paderborn was ready to start the game at 7:55pm.

¿Quién no tiene alguna anécdota que contar relacionada con las actualizaciones?

Confíamos en que los equipos están allí dispuestos para atender nuestras necesidades sin proporcionales ni prestar atención a las suyas más básicas.

Al final, no es más que dedicar tiempo e incluir en nuestros procesos el mantenimiento para que no nos sucedan estas situaciones desagradables

Elogio de Python por el equipo de ingeniería de PayPal

Portada Libro Python Desde hace algún tiempo, cuando tengo que hacer un programita para resolver un problema de manera rápida mi lenguaje elegido es Python. También voy encontrándome mis limitaciones, esencialmente por no dedicarle atención suficiente a todo el entorno que ofrece para trabajar. De hecho, ya algunas entradas sobre Python en esta bitácora. Principalmente desarrollos que he ido haciendo pequeñitos que tal vez podrían servirle a alguien más alguna vez.

Por eso me gustó leer 10 Myths of Enterprise Python que es un elogio por parte del equipo de ingeniería de PayPal, tratando de aclarar algunas ideas erróneas sobre el lenguaje. Las listo:

  1. Python is a new language
  2. Python is not compiled
  3. Python is not secure
  4. Python is a scripting language
  5. Python is weakly-typed
  6. Python is slow
  7. Python does not scale
  8. Python lacks good concurrency support
  9. Python programmers are scarce
  10. Python is not for big projects

Vale la pena leerlas y echarles un vistazo para ver los argumentos.

Mi relación con Python se basa fundamentalmente en que es rápido para hacer pruebas (con la ventaja del intérprete para terminar de comprender cosas que no tienes muy controladas) y, a la vez, permitiría evolucionar a proyectos más grandes (que con scripts de shell no es trivial). También sus ‘batteries included’ con bibliotecas disponibles casi para cualquier cosa que podamos querer hacer.

Mis quejas con el lenguaje, que también las hay, tendrían que ver con su incómodo sistema de gestión de codificaciones (quién no se haya enfrentado nunca al problema que nos diga como lo hizo), y la transición a Python 3 que no termina de llegar del todo.

Entre mis carencias, la gestión y pruebas con distintas versiones del lenguaje y el lío que (creo que) tengo montado en mis sistemas con la instalación de bibliotecas de terceros de manera poco adecuada. Estoy empezando a explorar Virtual Environments y pyenv para ver si controlo estas cosas un poco mejor.

Demandas por fallos de software: los coches

Portada Geekonomics De ven en cuando se habla de la responsabilidad de los desarrolladores de programas informáticos. El otro día preparando una clase recuperaba y actualizaba un par de enlaces sobre el tema: Is It Time For Software Liability? y Should Software Companies Be Legally Liable For Security Breaches? al que añadiré este que comento aquí. También se publicó hace unos años el libro Geekonomics: The Real Cost of Insecure Software (es un extracto del primer capítulo) donde se hacía un análisis sobre el tema desde diversas perspectivas.

En Lawsuit seeks damages against automakers and their hackable cars hablan justamente del tema en la industria del automóvil basándose en que los fabricantes no han tomado las medidas necesarias para proteger los vehículos de los atacantes. Incluso un Senador de los EEUU respaldaría esa idea:

The lawsuit also cites a study released last month by Sen. Edward Markey (D-Mass.) that claims automakers have fallen far short in their responsibility to secure their vehicles’ electronics

El informe está en [PDF] Analysis of automobile manufacturers’ efforts reveals security and privacy gaps Tracking & Hacking: Security & Privacy Gaps Put American Drivers at Risk.

Eso sin hablar de las limitaciones informáticas de los coches modernos, en los que normalmente (y afortunadamente, si hacemos caso a los riesgos aparecidos) hay muy pocas de las posibilidades que nos ofrece un ordenador aprovechadasa adecuadamente:

“You can get into five-year-old luxury car and it…feels like a Nintendo game…compared to the experience on your smartphone,” Morrison said in an earlier interview with Computerworld.

Que también tiene que ver con lo rápido que se quedarían anticuados (¿imaginas una pantalla como la de tu teléfono móvil de hace 5 años para tener en el vehículo durante otros cinco años más?).

En Senate Bill Seeks Standards For Cars’ Defenses From Hackers nos cuentan los planes sobre cómo abrodar el problema. Sin embargo, parece que las propuestas irían más bien en la línea de buscar ‘standards’ y buenas prácticas que las propias leyes (que era algo que se comentaba también en Informe sobre ciberseguridad nacional en EEUU.

No se cómo andará la reclamación legal pero desde luego parece que hay un problema y ya han aparecido los primeros intentos de soluciones legales. Hemos hablado de coches en mbpfernand0 y coches en esta bitácora.

Al final, todo tiene mucho que ver con las consecuencias económicas que tendrían ciertas consecuencias drásticas: probablemente la informática costaría más (dinero y/o tiempo) y todo tendría que ir algo más despacio tomando, tal vez, menos riesgos. Pero seguramente este es un debate que vamos a seguir presenciando en los próximos tiempos.

Command and Control con GMail

Cuadro de mandos Una de las tareas que tienen los ‘malos’ para organizar sus ataques es la gestión de los equipos comprometidos. No hace tanto esto se hacía mediante canales de IRC, y la cosa ha ido evolucionando hacia redes sociales y otros sistemad de comunicacación (nuestro propio bot -no malicioso-, del que hemos hablado a veces no es más que un sistema de control de un computador remoto, mediante XMPP Segundo bot: avanzamos). Un ataque de este tipo sólo necesita que el programa malicioso pueda escuchar de alguna manera las instrucciones y pueda comunicarnos las respuestas.

En este caso podíamos leer hace algún tiempo ¿Gmail como server de C&C? OMG! – Parte I. Lamentablemente la parte II no se ha llegado a materializar aún donde se comenta sobre Pyexfil - Using Python to make Gmail a C&C server .

Se trata de un programa en Python que permite controlar un equipo infectado mediante el envío y recepción de mensajes de correo electrónico. El programa es capaz de leerlos, ejecutar las instrucciones y responder, si es necesario. Si conseguimos hacer que se ejecute en el equipo de vez en cuando tendremos un mecanismo para comunicarnos que además puede ser bastante sigilioso (¿cómo va a despertar la sospecha una consulta a un servidor de correo de amplia implantación?).

Curioso.

Informe sobre ciberseguridad nacional en EEUU

Portada del informe Seguimos con informes. Este es de julio del año pasado y se puede conseguir en varios formatos desde Surviving on a Diet of Poisoned Fruit: Reducing the National Security Risks of America’s Cyber Dependencies

… offers key insights about how to improve U.S. national security policymaking to address cyber insecurity. In the report, the author examines existing information technology security weaknesses and provides nine specific recommendations for the U.S. government and others to cope with these insecurities.

Los consejos:

  1. Suponer que los sistemas gubernamentales críticos tienen vulnerabilidades y compensar mediante una estrategia basada en: reducir las capacidades a lo esencial para minimizar las vulneratbilidades, añadir medidas no informáticas en los sistemas informáticos (evitaría la excesiva automatización), añadir diversidad (para que un fallo no afecte a todos los sistemas de manera global), e invertir en capacidades de descubrimiento y recuperación.
  2. Identificar sistemas no gubernamentales críticos y utilizar incentivos, estándares, información de ataques y autoridades regulatorias para mejorar la situación. Sin olvidar la difusión de información.
  3. Permitir las decisiones del sector privado sobre ciberseguridad para sistemas que no sean críticos o que sean suficientemente capacidad de recuperacion.
  4. Reconocer que las normas y regulaciones quedan obsoletas rápidamente, mejor utilizar incentivos y formación. Cuando sea necesaria la regulación, concentrarse en los objetivos antes que en las medidas.
  5. Buscar el desarrollo de normas y restricciones limitando el uso de ciber-armas para alcanzar efectos en el mundo físico.
  6. La ciberseguridad no es solo un problema técnico, es necesario invertir también en investigación socioeconómica, para comprender mejor el comportamiento de la industria y sus incentivos, así como el de los posibles atacantes. Evaluar sistemáticamente las respuestas de otros gobiernos ante los problemas de seguridad.
  7. Financiar un consorcio de recolección de datos para comprender mejor la magnitud del problema de ciberseguridad, siguiendo el modelo de incidentes en aviación. Desarrollar terminología y métricas.
  8. Invertir en investigación y desarrollo junto a la industria y otros países para hacer las arquitecturas informáticas más robustas.
  9. Evitar la falsa ilusión de que una agencia central de control o un ‘zar’ son alcanzables o deseables. Aumentar la capacidad reforzando las capacidades de la Casa Blanca con el objetivo de aportar fortaleza a la ciberseguridad civil que ha sido menos considerada por estar la mayor parte de la gestión orientada a los aspectos militares y de defensa.

Infecciones e internet

Gusano 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.

Ya hablamos hace tiempo del bloqueo de usuarios infectados por parte de sus proveedores de internet ¿Deberían los proveedores de acceso desconectar a los usuarios infectados?. La propuesta allí era ponerlos en cuarentena más allá de los avisos que algunos ya mandan: al final, el tráfico pasa a través de sus redes y tienen cierta capacidad de ver cuándo algunas cosas van mal: It’s time to quarantine infected computers

ISPs on an on-going basis should take advantage of the threat intelligence feeds of the security industry to identify compromised systems connected to their networks. Those systems should be moved to quarantine, the account owners should be contacted and directed to resources which will enable them to clean up and rectify the situation. Until such time as the infection is remediated the computer should be able to access only limited Internet resources. Don’t care will be made to care.

Esto tiene algunos problemas (inspección del tráfico, pérdida de productividad si nos desconectan…), en algunos casos no triviales.

También habíamos hablado del caso de Australia ¿Tienes malware? ¡Te desconectamos! y de algunas empresas Gusanos: las defensas de IBM y HP .

Recientemente hemos conocido alguien que da un paso más allá, New vigilante malware protects your computer from the bad guys. Se trata de un troyano llamado Linux.Wifatch que elimina algunas familias conocidas de ‘malware’ que habitualmente se pueden encontrar en routers caseros. Parece que el propio troyano está protegido contra posibles usos maliciosos:

As far as the researchers have found after months of investigation, however, Wifatch’s creator has yet to do anything malicious. In fact, using cryptographic signatures, the malware’s creator has even programmed the virus to guard against other hackers surreptitiously using the same network or backdoors.

Ya sabemos que mantener actualizados determinados dispositivos es difícil, porque los fabricantes y proveedores no nos dan demasiadas facilidades. Y también sabemos que es bastante frecuente encontrarse con casos de ataques como contábamos el otro día en Mala seguridad, routers y ataques pero como también podíamos leer sobre ataques lanzados utilizando cámaras de vigilancia Attackers hijack CCTV cameras and network-attached storage devices to launch DDoS attacks así que uno no sabe si tener miedo de estos ‘héroes’ que nos protegen o agradecer su trabajo para que las infecciones no se propaguen más.

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.