Latch, SSH y backups

Jesús Cea Avión

2014-05-14 12:16

Latch es un producto de Eleven Paths publicado a finales de 2013. Se trata de un producto curioso: Es un mecanismo de seguridad adicional que permite que un usuario active y desactive el acceso a funciones arbitrarias proporcionadas por un tercer jugador. Dicho tercer jugador consulta a Latch cuando un usuario quiere hacer una acción protegida, para verificar si dicho usuario se ha cerrado a sí mismo el acceso o no. Y el usuario controla Latch desde su móvil.

Confieso que no le presté ninguna atención cuando salió la noticia. No le veía el interés para mí. Pero durante la RootedCON 2014 estuve charlando un rato con Chema Alonso y me dio un par de casos interesantes que despertaron mi interés (control de pagos por Internet con la tarjeta de crédito, por ejemplo). Luego la charla de Chema en la RootedCON, siendo el showman consumado que es, metió el gusanillo en la audiencia. Servidor incluído. El manejo desde el móvil me enamoró.

El día siguiente a la RootedCON me colapsé en la cama todo el día, tras una semana de gripazo, medicación en vena y madrugones desacostumbrados. Físicamente agotado, pero con la mente despierta (y hambrienta, puñetera maldición), me pasé la tarde entera empapándome de Latch, sus SDK, su API, etc.

He de decir que lo que vi no me gustó. El código publicado parece apresurado y da la impresión de que no está siendo mantenido de forma activa. El SDK Python no verifica el certificado SSL del servidor. La aplicación iOS era muy limitada comparada con lo que mostró Chema Alonso en su presentación (él mostraba la versión Android, y en honor a la verdad la versión actual de iOS ha mejorado bastante). Lo cierto es que tengo mucho que decir sobre todo esto, pero me lo reservaré para un futuro artículo. Una cosa que sí puedo decir es que mis quejas, en su inmensísima mayoría, son muy fáciles y rápidas de resolver si Eleven Paths está por la labor. Es decir, no son defectos estructurales de Latch, sino problemas concretos y solucionables con muy poco trabajo. Con todo, Latch es un producto intrigante.

Pero, como digo, ese rant tendrá que esperar algún tiempo. Siento dejaros con los dientes largos y los cuchillos a punto :-). Soy una mala persona, lo sé. Chincha :-). En este artículo me centraré en un experimento concreto que he hecho con Latch.

Estaba postrado en la cama, como decía (démosle un poco de dramatismo al asunto). Pagando los excesos de la RootedCON con mi cuerpo. Ejem. Bueno, que no tenía la cabeza para hacer nada serio y productivo. Pero Chema Alonso tiene el don de la seducción y había despertado mi interés cuando me dijo que la integración de Latch con SSH se hacía vía PAM, cosa que me intrigó y me decidió a echar un vistazo al código publicado en GitHub. Mis impresiones fueron ambivalentes y me las reservo para otro artículo futuro. Adelanto que los problemas que tengo con la implementación actual de Latch se pueden arreglar fácilmente. No son problemas inherentes a Latch. Pero molestan.

Al grano.

Mis backups son bastante sofisticados (de hecho lo que describo en mi articulo de backups es solo uno de mis cuatro niveles de respaldo, es una historia compleja), y algo que me preocupa es que la clave SSH utilizada por el servidor de backup es dios en todas mis máquinas. Es decir, con esa clave podemos hacer lo que nos de la real gana. Una opción simple sería utilizar .ssh/authorized_keys para cablear un comando concreto para estas claves SSH, pero lo cierto es que voy refinando el backup constantemente a medida que instalo cosas, excluyo directorios, etc., y mantener esos comandos cableados en cada servidor es bastante inconveniente (aunque es lo que recomiendo que hagan mis clientes. En casa del herrero... en fin). Latch puede ser muy conveniente aquí: puedo condicionar el acceso de la clave SSH de backup a que Latch esté abierto o cerrado, con la ventaja adicional de que si se intenta usar dicha clave cuando Latch está cerrado me va a llegar una notificación instantanea al móvil.

Tras verificar que la integración SSH proporcionada por Eleven Paths no me sirve ni de referencia siquiera, escribo el siguiente código:

Este código se libera como dominio público. Haced con él lo que queráis, aunque me gustaría que me contéis qué cosas interesantes sacáis.

     #!/usr/local/bin/python3

     # 2014 jcea@jcea.es - http://www.jcea.es/
     # Código liberado como Dominio Público.
     # Haz con él lo que quieras.

     import sys, socket, os, shlex
     sys.path.append('/home/latch/latch-sdk-python-master')
     import latch

     socket.setdefaulttimeout(10)

     def is_latch_open() :
         app_id = 'XXXXXXXX'
         secret_key = 'XXXXXXXX'
         accountId = \
             'XXXXXXXX'
         operationId = 'XXXXXXXX'
         api = latch.Latch(app_id, secret_key)
         reply = api.operationStatus(accountId, operationId)
         reply = reply.get_data()
         return reply['operations'][operationId]['status'] == 'on'

     if __name__ == '__main__' :
         ssh_original_command = os.environ.get('SSH_ORIGINAL_COMMAND', None)
         if ssh_original_command is None :
             sys.exit('No tenemos variable de entorno "SSH_ORIGINAL_COMMAND"')
         if not is_latch_open() :
             sys.exit('Latch cerrado')

         # Por si el comando contiene parámetros con espacios, comillas, etc.
         cmd = shlex.split(ssh_original_command)

         # Usamos la versión con el sufijo "p" para que
         # busque el comando en "os.environ['PATH']".
         os.execvp(cmd[0], cmd)

En 30 líneas de código implemento una medida de seguridad importante para mis backups. Una de las bondades de Latch es que la integración es muy fácil. ¡Bravo por ello!.

Algunos detalles:

La integración con SSH se realiza a través de .ssh/authorized_keys. Algo del estilo:

command="/home/latch/z.py",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3N...

El SDK no verifica el certificado SSL del servidor Latch. Pero bueno, a las malas un atacante haciendo MITM podría a) denegarme la realización de los backups, lo que sería detectable y nada crítico, o b) abrirse el Latch a sí mismo, lo que no sería peor que no utilizar Latch en absoluto.

La captura de credenciales se gestiona mediante la firma de la petición, al estilo de OAuth 1. (No, Jesús, muérdete la lengua. Deja el rant para ese próximo artículo. Respira hondo. Relax...)
Si Latch falla, no puedo hacer backups. Pero si Eleven Paths discontinua el servicio, simplemente elimino esta integración y ya está. No me quedo fuera permanentemente (como ocurre con la integración SSH de referencia del SDK. ¡Maldición, no spoilees tu próximo artículo, Jesús! O:-).

Cuando hago backups, ahora, primero lanzo el backup con el Latch cerrado. La copia de seguridad terminará inmediatamente con un error Latch cerrado y me llegará un aviso al móvil. Bien, eso me da seguridad. A continuación abro el Latch durante una hora con el móvil, y vuelvo a lanzar la copia de seguridad. Naturalmente en esta ocasión todo irá bien (glup :-) y la copia de seguridad terminará correctamente en unos 40 minutos. El Latch se cerrará automáticamente a la hora, permitiéndome dormir marginalmente mejor :-).

En resumen, integrar Latch es muy muy muy fácil. Es su gran ventaja. Le veo problemas, pero son solucionables de forma simple. Tema de futuro artículo.

Lo que está por ver es si Chema Alonso y Eleven Paths pueden rentabilizar el servicio con el modelo de negocio planteado. Como ya he dicho, me resulta intrigante. Creo que los más interesados en integrar algo así, como los bancos, ya tienen sus propias aplicaciones para el móvil y podrían proporcionar un servicio similar de forma autónoma.

Intrigante, sí. Tengo curiosidad por ver qué les depara el futuro.

En todo caso, ¡¡buena suerte!!.