Borrado remoto de datos en relojes Pebble

Pebble

Mucho se está hablando últimamente de los relojes inteligentes, sobre todo con la puesta a la venta del Apple Watch. La inteligencia de esos aparatos viene de que son ordenadores y, como tales, pueden ser el objetivo de los atacantes y víctimas a través de diveras vulnerabilidades.

En Un atacante remoto puede borrar todos los datos del reloj Pebble nos contaban el caso de los relojes Pebble, uno de los primeros casos de éxito.

En este caso el problema parecía ser una denegación de servicio cuando se reciben demasiados mensajes (que podría ser una simple olestia) que se convierte en borrado de datos porque se produce una restauración del dispositivo a su estado inicial.

No es la primera vez que nos encontramos con fallos en los mensajes: SMS y fallos. Ahora en Windows Phone y Nuevos ataques con SMSs. Hay más. Pero yo me he acordado de uno bastante más viejo: Hackeando una red de telefonía con SMS’s. En este se exploraban los límites de los teléfonos de la época (mucho menos capaces que ahora, era el año 2005) y las propias redes.

En DoSing Pebble SmartWatch And Thus Deleting All Data Remotely se puede leer algún detalle más.

Publicar en Linkedin las entradas de este sitio usando Python

Seguimos tratando de difundir el contenido de este sitio en diferentes redes sociales. Me da la impresión de que Google no presta demasiada atención a estos blogs (tampoco estoy muy seguro de que nadie fuera a buscar esto, en cualquier caso) pero sí que creo que se les puede dar (algo de) visibilidad en diferentes redes sociales.

Ya hicimos el acercamiento a Twitter (Publicar en Twitter las entradas de este sitio usando Python) y Facebook (Publicar en Facebook las entradas de este sitio usando Python).

Enlaces en Página de Facebook

Suelo compartir en Linkedin (y en los otros sitios) entradas de mi bitácora de enlaces, Notas Rápidas. Normalmente se trata de información que voy viendo por ahí; muchas veces la pongo incluso antes de leerla. De vez en cuando, alguien comenta, re-comparte… Pensé que también tendría sentido publicar allí lo que voy poniendo en mis blogs.

LinkedIn utiliza Oauth para la autentificación. En la sección de desarrolladores explican estas cosas y en Share on Linkedin explican la parte de publicar allí. En Authenticating with OAuth 2.0 nos indican qué cosas hay que configurar: dar de alta la aplicación en nuestro espacio de trabajo, lo que generará las correspondientes “API Key” y “Secret Key” y también los tokens “OAuth 1.0a User Token” y “OAuth 1.0a User Secret” que podremos incluir en nuestro programa (esto es, por ahora no necesitamos utilizar los tokens de la versión 2 de OAuth). También podríamos pasar por el proceso de autorización con el programita (que es algo que no he hecho) o bien utilizar las herramientas que nos proporcionan otros.

Una búsqueda rápida de algún módulo para interactuar con LinkedIn en Python nos conduce a python-linkedin.

Con este módulo todo se parece a los programas que hemos hecho en otras ocasiones (y me saltaré los detalles aquí). Se puede ver el código en su versión actual en rssToLinkedin.py.

  • Se leen los blogs que estén configurados (igual que otras veces) y se selecciona uno para publicar.
  • Se obtiene el título, el contenido y el enlace de la última entrada.

Una nota para el contenido: LinkedIn tiene límites sobre lo que se puede poner (actualmente 700 caracteres), así que hay que tener cuidado. Reservamos 7 caracteres para indicar que el texto sólo es un resumen.

print theSummary.encode('utf-8')[0:693].rsplit(' ', 1)[0]+" [...]"
  • Luego se busca una imagen y se incluye si la hay.

A partir de aquí comienza el proceso de autentificación:

authentication = linkedin.LinkedInDeveloperAuthentication(
			config.get("Linkedin", "CONSUMER_KEY"),
			config.get("Linkedin", "CONSUMER_SECRET"),
			config.get("Linkedin", "USER_TOKEN"),
			config.get("Linkedin", "USER_SECRET"),
			config.get("Linkedin", "RETURN_URL"),
			linkedin.PERMISSIONS.enums.values())

Seguidamente ponemos un texto (en mi caso ‘Publicado’) a modo de introducción y luego publicaremos el resto:

comment='Publicado!'

application.submit_share(comment, theTitle, theSummary, theLink, imageLink)

Con el trabajo desarrollado para los programas anteriores lo que hay que hacer aquí es simplemente utilizar el método adecuados para publicar.

Siguientes pasos: tengo tres programas para publicar en diferentes redes sociales y me pregunto si debería unificarlos para utilizar las partes comunes (esencialmente selección del blog porque el resto tiene pequeñas diferencias), o pensar en una mejor organización.

Pero esto será algo para pensar más adelante.

Algunos artículos sobre pruebas

Bugs Suelo echarle un vistazo a la revista CrossTalk. Como ya comentábamos hace algún tiempo en Desarrollo ágil y algunos problemas que aparecen a veces se ttrta de una revista sobre ingeniería del software militar), donde tratan temas actuales con un punto de vista de gestión. Suelen ser articulitos cortos que se leen fácil y aportan puntos de vista interesantes a veces.

En el último número hablan sobre Test and Diagnostics y a mi me han interesado especialmente:

Hemos hablado bastante de fuzzing (ver (tag fuzzing)[https://mbpfernand0.wordpress.com/tag/fuzzing/] en el blog antiguo) y Coches y ataques en este mismo blog.

Bugs con una larga historia. El caso de LZO

Bugs En Raising Lazarus - The 20 Year Old Bug that Went to Mars otra historia de esas que nos recuerda que hacer software seguro (o bien) es difícil. En este caso es una fallo sutil que ha escapado durante años a las revisiones que se hayan podido hacer (si es que se hicieron, que es otro de los temas que aparecen de vez en cuando relacionadas con el desarrollo de programas).

En esta ocasión se trata de diversos desbordamientos de enteros a la hora de ir almacenando valores y contabilizando el espacio que ocupan.

En este caso, además, se añade el interés de que hay varias implementacionesd el algoritmo LZO (Lempel-Ziv-Oberhumer) que comparten algunas partes de su código.

Ya habíamos hablado de El mito de los miles de ojos y más fallos con historial largo: Un fallo de 17 años, Alguien puso un troyano en mi servidor de IRC y Diaspora: lecciones de seguridad.

OAUTH y seguridad

Identificación Últimamente es raro el sitio que no permite identificarse con nuestra cuenta de Google, Facebook, Twitter u otras. La ventaja para el desarrollador está clara: desde un punto de vista de usuarios que re-utilizan contraseñas y que no son muy fiables a la hora de gestionar correctamente sus credenciales, delegamos ese trabajo en empresas más pontentes y que seguramente lo harán mejor que nosotros. Aunque puede que no sea una ventaja completa porque queramos tener un sistema de acceso para todas aquellas personas que no quieran utilizar este tipo de mezclas. Desde el punto de vista del usuario también está clara la ventaja: no tenemos que andar dándonos de alta en montones de sitios, con contraseñas (idealmente) diferentes y cofiando en administradores de plataformas que apenas conocemos.

Del tema de delegar la gestión de cuentas en otros se hablaba en Introducing the “Secure Account Management Fundamentals” course on Pluralsight que enlazamos en su momento desde Fundamentos de gestión de cuentas.

Para estas cosas se utiliza, entre otros OAuth que es un protocolo bastante completo y que permite cosas más sofisticadas. Nosotros lo hemos visto de pasada cuando hemos hablado de Publicar en Facebook las entradas de este sitio usando Python, Publicar en Twitter las entradas de este sitio usando Python, porque estos sitios no permiten que utilicemos la contraseña directamente, sino que prefieren que nos identifiquemos a través de OAuth.

Esencialmente se basa en que nos autentificamos una vez en el sitio proveedor (o más, si fuera necesario en el tiempo) y este nos proporciona unos tokens de acceso que permiten realizar ciertas operaciones en el propio sitio o, simplemenete nos reconoce como usuarios y eso le basta al sitio de origen como identificación.

El historial de seguridad de este protocolo ha tenido sus incidentes y por eso me gustó encontrar OAuth Security Cheatsheet que nos da las ideas principales sobre el flujo de datos y las precacuciones que debemos tomar a la hora de implementarlo/utilizarlo.

Los nombres y las cosas

Cerrado Una fuente frecuente de problemas de seguridad son los nombres: cuando esperamos que algo se llame de una determinada forma y también se puede referenciar con nombres alternativos (que no tuvimos en cuenta) es posible que se produzcan problemas: eso incluye la utilización de paths, diversas codificaciones, …

En la propia historia dicen que es un rumor (o algo que se dice) pero sirve como un ejemplo de lo que podría haber pasado (sin saber si es cierto o no): Windows 9 Reportedly Skipped as Name Would Have Created Code Bugs: la idea sería que en algunos casos se habrían utilizado búsquedas del nombre para identificar el sistema Operativo del estilo de ‘if(version,startswith(“windows 9”) que inevitablemente producirían confusiones en el caso de que se hubiera lanzado un hipotético Windows 9.

Sea cierta o no, una buena historia para un sábado. Y un recordatorio para los casos en que, efectivamente, los nombres han sido un problema.

Seguridad y principio del mínimo privilegio

Cerrado El principio del mínimo privilegio consiste esencialmente en conceder a las aplicaciones y usuarios los permisos necesarios para realizar las acciones que tengan que llevar a cabo, pero no más. Esto durante el tiempo necesario.

En Improving security through least-privilege practices hablan del tema introduciendo las ideas generales y la motivación.

Me quedo con esta frase:

A tip I often give my clients is to not see accounts as privilege but see privilege as accounts. What I mean by this is an account that is used for backup administration, or an account that is used to create users on a domain should be used as such and not for anything else. If your user’s accounts have these privileges then you have lost control of your network, data and systems and any malicious user or application will eventually exploit this vulnerability.

Aprender programación en 2014

Seguridad y cultura En Teaching Code in 2014 algo que ya llevamos tiempo diciendo: se sigue enseñando a programar (no a nivel básico, sino incluso después) sin tener en cuenta la seguridad.

Los consejos que da tienen que ver con:

  • No hay excusa para utilizar ejemplos inseguros
  • La seguridad debería estar integrada, no añadida
  • Usando Node.js también hay que tener en cuenta la seguridad
  • Hay que cambiar la forma de enfrentarse a este problema

En definitiva, hay que enseñar buenas prácticas, incluir ejemplos no sólo correctos desde el punto de vista de la funcionalidad sino también pensando en la seguridad.

Consejos sobre claves

Barrera Aunque de vez en cuando se anuncia la sustitución de las contraseñas con diversas tecnologías, lo cierto es que parece que vamos a convivir con ellas durante una buena temporada. En Passwords: Real-world issues, tips and alternatives se entrevista a Per Thorsheim y hablan sobre el tema. Se habla de las contraseñas, algunas alternativas, mejorar la facilidad de uso. Thorsheim es el organizador de la PasswordsCon, un encuentro centrado en estas cuestiones.

Da la casualidad de que tengo por una de las pestañas de mi navegador el resumen sobre gestores de contraseñas que hacían recientemente en Lifehacker Faceoff: The Best Password Managers, Compared. Hace un poco más leíamos Top password managers compared.

También podíamos leer el otro día un texto generalista y orientado a audiencias más amplias, con consejos que incluso algunos que deberían saber mejor estas cosas olvidan a veces Web Security for the Tech-Impaired: Passwords that Pass the Test:

  • Utilizar claves diferentes para sitios diferentes
  • Tu clave no debería tener menos de 12 caracteres
  • Utilizar una mezcla de minúsculas, mayúsculas, números y caracteres especiales
  • No utilizar secuencias predecibles a la hora de organizar estas mezclas.

Ya hemos hablado más veces de contraseñas por aquí, por ejemplo en Algunos enlaces interesantes sobre claves y allí había más enlaces.

Seguridad e Internet de las cosas

Cosas conectadas En 6 Tips for Developing Secure IoT Apps un nuevo recordatorio: los aparatos conectados a la red programables son peligrosos, sobre todo si no se tiene en cuenta que la conectividad cambia el contexto y aparecen nuevos riesgos.

Los consejos: contratar desarrolladores con conocimientos adecuados, utilizar plataformas probadas, comprobar las actualizaciones del firmware de los dispositivos, asegurarse de que los datos están seguros frente a ataques físicos y utilizar componentes de hardware seguros.

Se hace referencia a un estudio de HP: [PDF] Internet of Things Research Study y seleccionamos algunos comentarios.

Hay muchos dispositivos que fallan:

It found that every one of 10 popular Internet-connected security systems – which include video cameras and motion detectors – had significant security vulnerabilities which would allow hackers to access the devices and control them remotely.

Sobre esto, suelo emplear una referencia relativa a dispositivos WiFi y Bluetooth, [PDF] CODENOMICON WHITE PAPER. Wireless Security: Past , Present and Future para hacer notar que los fallos de seguridad no sólo aparecen en los programas, sino también en dispositivos. La cantidad de evidencias y casos sigue aumentando.

Las vulnerabilidades y los fallos no son nuevos:

They are well understood, and most of the specific vulnerabilities could probably be easily avoided by following best practices and recommendations for secure coding. The problem, according to Miessler, is that many IoT developers simply don’t follow them.

Las aplicaciones inseguras vienen de los propios fabricantes:

It’s noticeable that many of the insecure IoT applications (such as some of those in HP’s study) come from IoT hardware device vendors who offer software to work with their products.

Ya hemos hablado en el pasado de seguridad y aparatos ‘domésticos’. La internet de las cosas es un nuevo episodio:

Seguridad ‘hogareña’ Coches e informática Y unas cuantas más, por ejemplo relacionadas con coches, hogar . Hace nada volvíamos a hablar de coches en: Desbordamientos de memoria y Toyota y en Coches y ataques

También recientemente conocíamos la noticia de cómo hacía falta actualizar un montón de coches BMW actualiza el software de más de 2 millones de automóviles por una vulnerabilidad o el también reciente de las ‘televisiones espía’: It’s not just smart TVs. Your home is full of gadgets that spy on you: How internet giants are collecting your personal data through their high-tech devices y alguno más que van ocurriendo cada día.