GitHub Copilot y el debate de la Propiedad Intelectual

Ya llevo un tiempo hablándoos de Inteligencia Artificial y de algunas de sus innovadoras respuestas a problemas de la vida cotidiana y de cómo pueden afectar al futuro de nuestra sociedad. Hoy toca hablar de uno de los últimos casos polémicos en los que ha estado involucrada la Inteligencia Artificial, en este caso, de cómo GitHub Copilot ha abierto un debate acerca de si la inteligencia artificial en casos de uso como estos infringe los derechos de autor de los programadores al utilizar el código escrito por ellos para entrenarse.

Figura 1: GitHub Copilot y el debate de la Propiedad Intelectual

Si no conoces GitHub Copilot te lo presentamos brevemente. Copilot es un asistente de código diseñado para ayudar a los programadores y que funciona con Codex, un innovador sistema creado por Open AI que utiliza la inteligencia artificial para comprender el contexto del código que los programadores están haciendo para sintetizar código que coincida con el resto del programa. De hecho, Copilot es capaz de proponer a sus usuarios desde líneas de código hasta funciones completas.

Figura 2: Copilot, asistente de programación.

GitHub Copilot cuenta es de una gran velocidad, y es capaz de proponerte otras alternativas a tu código mientras escribes, además funciona como una extensión de Visual Studio Code, lo que quiere decir que podremos utilizarlo tanto en nuestro equipo como en la nube o en el entorno de desarrollo instantáneo de GitHub. Copilot también trabaja con una gran cantidad de idiomas y lenguajes de programación entre los que se encuentran Python, JavaScript, Ruby y Go, aprendidos con sus algoritmos de "Machine Learning", lo que hace que sea una herramienta capaz de orientar a la mayoría de los programadores. 

Figura 3: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández.

Como os hemos dicho antes y como su propio nombre indica, la función de esta herramienta es asistir durante la programación, aunque la herramienta pueda ofrecer interesantes alternativas para optimizar el código el programador será siempre el que tenga la última palabra. Con esto se logra ajustarse a las necesidades de cada usuario, ayudándole cuando lo necesite y dejando que escriba código de forma “tradicional” cuando quiera.

Figura 4: Funcionamiento de GitHub Copilot.

Otra de las grandes ventajas de Copilot es que ofrece la posibilidad de convertir un comentario en código. Solo hay que escribir un comentario en el que se describa la lógica deseada y esperar a que la inteligencia artificial haga su trabajo y ensamble el código por nosotros. Del mismo modo Copilot también es capaz de autocompletar patrones de código repetitivo. Esto quiere decir que si generamos un ejemplo la herramienta es capaz de generar el resto del código haciendo que solo tengamos que decidir con que partes queremos quedarnos. 

Durante la programación es común utilizar pruebas para comprobar que el software que se esta construyendo funciona correctamente y cuenta con unas bases sólidas, con GitHub Copilot es posible importar un paquete de prueba unitaria y dejar que la IA sugiera pruebas que coincidan con el código introducido para comprobar su efectividad.

Figura 5: Ejemplo de prueba para el código propuesta por Copilot.

Pero si GitHub Copilot es tan bueno, ¿por qué ha habido una creciente polémica acerca de la herramienta durante estas últimas semanas? La respuesta es sencilla, Copilot es capaz de programar gracias al código Open Source de la plataforma, código que han compartido otros programadores. Hasta aquí no hay ningún problema, el problema surgió cuando Microsoft anunció que el sistema sería de pago, lo que ha sentado mal a muchos desarrolladores. El código que ha utilizado y sigue utilizando GitHub Copilot se encuentra bajo licencias GPL, esto quiere decir que el código de la plataforma puede utilizarse para generar código derivado pero este nuevo código debe de ofrecerse bajo las mismas condiciones.

El debate de la Propiedad Intelectual

Varios programadores ya han expresado su malestar tanto en las redes sociales como en la propia plataforma ante el hecho de que se haya utilizado una Inteligencia Artificial para generar una rentabilidad comercial al código que ellos, y muchos otros, han compartido desinteresadamente. Esto ha abierto un gran debate acerca de como deberían aplicarse las leyes del Copyright en un caso como este. Según la OMPI (Organización Mundial de Propiedad Intelectual) las obras creativas gozan de la protección del derecho de autor si son originales, sin embargo, en la mayoría de las definiciones relativas a la originalidad se hace referencia a un autor humano, por lo tanto, a pesar de que la Inteligencia Artificial generase código no podría considerarse como un autor.

Figura 6: Organización Mundial de la Propiedad Intelectual (OMPI/WIPO).

Ante esta situación varios expertos han compartido sus distintas perspectivas acerca de las leyes de derechos de autor sobre este caso de uso de la IA. Algunos expertos se han mostrado a favor de que corporaciones como Microsoft utilicen el código abierto para su propio interés, argumentando que evitar su uso con estos fines supondría ir en contra de las bases del código Copyleft, y esto podría derivar en futuras leyes de Copyright cada vez mas restrictivas. También se ha planteado que a pesar de que la Inteligencia Artificial Copilot utilice este código abierto para generar nuevos fragmentos de código, no quiere decir que esto sea un trabajo derivado, y por lo tanto no debería de estar cubierto por las leyes de propiedad intelectual.

Por otro lado, muchos programadores no quieren que se utilice su código para entrenar a la Inteligencia Artificial Copilot. Si este es el caso, GitHub ofrece un detector de duplicación que alertaría a los usuarios de Copilot de que el código propuesto en cuestión se trataría de un duplicado de otro autor y ofrecería la posibilidad de atribuirle esa parte del código, o buscar otra opción. Esta solución planteada por la plataforma no acaba de convencer a aquellos programadores que no quieren que Microsoft utilice la IA para monetizar un trabajo que ellos han compartido de forma gratuita. 

Figura 7: Porcentaje de regurgitación de código tras un análisis de la herramienta

(aproximadamente un caso por cada 10 semanas de uso).

De hecho, en los términos de Licencia de GitHub se explica claramente que al compartir tu código a través de la plataforma se le da permiso para incluirlo en sus bases de datos e índices de búsqueda para que otros usuarios puedan acceder a él y así ayudarles en sus proyectos, pero no venderlo a terceros.

Por el momento no podemos saber cómo concluirá este debate debido a estos pequeños vacíos legales en la ley de Copyright en lo que a Inteligencia Artificial se refiere. Y tampoco sabemos que sucedería en el caso de que un programador demandase a Copilot o Microsoft por el uso de su código ya que, según GitHub, aunque el código que se comparte en la plataforma pueda ser utilizado por otros usuarios sigue perteneciendo a la persona que lo hizo. 

Sin duda alguna, este tema dará mucho que hablar durante los próximos meses e incluso podría llevar a una nueva reforma en la ley de propiedad intelectual.

 

Saludos,
 

Autor: Sergio Sancho, Security Researcher en Ideas Locas.

Contactar con Sergio Sancho en MyPublicInbox

SuperLatch Docker: Integrar Latch con Docker y Kubernetes en tus aplicaciones (3 de 3)

Al finalizar la segunda parte de este artículo habíamos visto como las aplicaciones en Go y Java están Up & Running, al mismo tiempo que teníamos pareadas ambas con el SuperLacth Docker en nuestra aplicación móvil.

Figura 17: SuperLatch Docker: Integrar Latch con Docker y Kubernetes en tus aplicaciones (3 de 3);

A partir de este momento podemos ver que cuando activamos Latch para poner el estado en OFF de nuestra app SuperLatch Docker las aplicaciones pasan a estar deshabilitadas y no funcionan, tal y como se puede ver en las imágenes siguientes.

Figura 18: Aplicación Go se deshabilita porque el SuperLatch Docker está cerrado

Figura 19: Aplicación Java deshabilitada también desde el SuperLatch Docker

El funcionamiento descrito en este proceso está disponible en el siguiente vídeo, donde se puede observar todo el proceso activación y bloqueo de la aplicación utilizando Latch:

Figura 20: Demo de Activación y Desactivación de SuperLatch Docker

Como podéis observar, cada segundo (tiempo preestablecido para que la aplicación compruebe el estado) se activa el popup en la aplicación Latch, indicando que se ha bloqueado una aplicación. Esto ocurre porque estamos utilizando la versión Comunidad de Latch (en la versión comercial se puede desactivar este popup con un simple flag).

SuperLatch en Kuberneters

Para correr esta misma idea sobre kubernetes, usaremos minikube. Uno de los cambios que haremos con respecto a la versión de docker-compose es que los valores que necesitamos para conectar con Latch (secret, account_id y app_id) se almacenarán en secretos de kubernetes, en vez de en variables de entorno. Para ello tenemos que modificar el fichero secrets.yaml que se encuentra dentro del directorio kube.

Figura 21: Arquitectura de SuperLatch Kubernetes

Los datos de los secretos se asignan codificados en Base64, así que lo primero que necesitamos hacer es codificar nuestros valores:

Account id:

echo -n "QNmcFJuPdqG3fdAUy2GqBw2Ehn2VF8ranuzFbvMHj2h27WPgbrnMmyGTwzqBFvda" | base64 UU5tY0ZKdVBkcUczZmRBVXkyR3FCdzJFaG4yVkY4cmFudXpGYnZNSGoyaDI3V1BnYnJuTW15R1R3enFCRnZkYQ==

app_id:

echo -n "PAyrhmA3Hb8Qmf84N2Js" | base64 UEF5cmhtQTNIYjhRbWY4NE4ySnM=

secret key:

echo -n "isiBUL6PMXgc7EfkVkZgbZirwfK9d7gPtfDVKrDt" | base64 aXNpQlVMNlBNWGdjN0Vma1ZrWmdiWmlyd2ZLOWQ3Z1B0ZkRWS3JEdA==

Ahora ponemos esos valores en nuestro secrets.yaml:

apiVersion: v1
kind: Secret
metadata:

name: latch-secret

type: Opaque
data:

app_id: UEF5cmhtQTNIYjhRbWY4NE4ySnM=
account_id: UU5tY0ZKdVBkcUczZmRBVXkyR3FCdzJFaG4yVkY4cmFudXpGYnZNSGoyaDI3V1BnYnJuTW15R1R3enFCRnZkYQ==
key: aXNpQlVMNlBNWGdjN0Vma1ZrWmdiWmlyd2ZLOWQ3Z1B0ZkRWS3JEdA==

Una vez tenemos dicho fichero modificado y grabado, lo siguiente sería crear nuestros objetos. Para ello asegúrate que minikube está arrancado:

minikube start 
Starting local Kubernetes v1.10.0 cluster... 
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs... 
Connecting to cluster... 
Setting up kubeconfig...
Starting cluster components... 
Kubectl is now configured to use the cluster. 
Loading cached images from config file. 

Una vez minikube esté arrancado, ejecutamos:

kubectl create -f secrets.yaml -f deployment.yaml -f service.yaml

Asumiendo que estamos situado dentro del directorio kube, si estamos en otro directorio distinto al de nuestros ficheros yaml, pues tendrás que prefijar el fichero con la ruta correcta. Para comprobar que nuestro Pod se ha creado de forma correcta:

kubectl get pod 

NAME                                    READY   STATUS    RESTARTS  
 
latch-poc-deployment-66d8f6c966-vslf7   3/3     Running   0     
     

Como se puede observar en la columna READY, los tres contenedores están corriendo (3/3). Una vez echo esto pues acceder a los servicios, para ello tenemos que ver que puertos a mapeado kubernetes:

minikube service list
|-------------|----------------------|--------------------------------|
|  NAMESPACE  |         NAME         |              URL               |
|-------------|----------------------|--------------------------------|
| default     | kubernetes           | No node port                   |
| default     | latch-poc-service    | http://192.168.99.100:30823    |
|             |                      | http://192.168.99.100:31723    |
| kube-system | kube-dns             | No node port                   |
| kube-system | kubernetes-dashboard | No node port                   |
|-------------|----------------------|--------------------------------|

Vemos que el servicio latch-poc-service tiene dos puertos mareados, pero no sabemos cuál es cuál. Podemos abrir nuestro navegador y probar a ver que puerto esta mapeado al servicio Java y cuál al servicio Go. O podemos ver la descripción del servicio:

kubectl describe service latch-poc-service             
Name:                     latch-poc-service
Namespace:                default
Labels:                   
Annotations:              
Selector:                 app=latch-poc-deployment
Type:                     NodePort
IP:                       10.99.73.112
Port:                     java-port  8080/TCP
TargetPort:               8080/TCP
NodePort:                 java-port  30823/TCP
Endpoints:                172.17.0.5:8080
Port:                     go-port  8081/TCP
TargetPort:               8081/TCP
NodePort:                 go-port  31723/TCP
Endpoints:                172.17.0.5:8081
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Aquí podemos ver que el servido Java está mapeado al puerto del nodo 30823 y el de Go al 31723. A continuación podéis ver un vídeo completo de la PoC de SuperLatch Kubernetes:

Figura 22 : PoC de SuperLatch Kubernetes

En el caso de kubernetes estamos desplegando los tres contenedores en un mismo Pod. Si el servicio latch-master estuviera protegiendo sólo un servicio, desplegar ambos contenedores en un mismo Pod sería aceptable. En este caso donde tenemos dos contenedores (servicios) que proteger, idealmente se desplegaría cada contenedor en un Pod distinto y el volumen se haría global (PersistentVolume) o el estado de latch se almacenaría en algún lugar global dentro del cluster. En nuestro caso y para mostrar la prueba de concepto, lo consideramos aceptable poner todos los contenedores en un mismo Pod por temas de simplicidad.

Conclusiones finales

En esta prueba de concepto no sólo podemos ver como añadir una capa más de seguridad protegiendo nuestros contenedores con Latch, si no que además, como los contenedores que queremos proteger sólo necesitan leer de un fichero del sistema y no tienen que acceder a los servidores de Latch para comprobar el estado del mismo, a menos que estos se tuvieran que conectar con otros servidores externos, podrías bloquear las conexiones outbound, es decir, que no podrían salir a Internet como comentamos al principio de este artículo, lo cual añade una capa más de seguridad.

Otro beneficio que esta PoC nos muestra, éste desde el punto de vista del programador, es al ahorro en código y dependencias. Es decir, los servicios protegidos por Latch cómo no necesitan conectar y hablar el “protocolo Latch”, no tienes que añadir las dependencias de las SDK de Latch y por lo tanto no tienes que escribir código para integrar la misma. Esto, además, nos permitiría proteger con Latch cualquier servicio ser necesario un SDK de Latch específico para el lenguaje utilizado. Vamos que podrías crear un servicio en COBOL y protegerlo con Latch sin ningún tipo de problemas :)

Esperamos que esta PoC sirva tanto como idea para implementarlo en alguna aplicación con Docker o como simplemente una forma de aprender un poco más de Docker y kubernetes. Y por supuesto, en nuestro libro Docker: SecDevOps también puedes aprender más de Docker y kubernetes ;)

Happy Hacking Hackers!!!

***********************************************************************************
- SuperLatch Docker: Integrar Latch con Docker y Kubernetes en tus apps (1 de 3)
- SuperLatch Docker: Integrar Latch con Docker y Kubernetes en tus apps (2 de 3)
- SuperLatch Docker: Integrar Latch con Docker y Kubernetes en tus apps (3 de 3)
***********************************************************************************

Autores:

Fran Ramírez, (@cyberhadesblog) miembro del equipo de Crazy Ideas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Rafael Troncoso (@tuxotron) es DevOps Tech Lead en USCIS/DHS, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Bettercap 2: La evolución de la navaja suiza de red y el poder de los Caplets

Hace un par de años hablé sobre Bettercap y MITMf dos herramientas que permiten llevar a cabo pruebas de ataques en redes IPv4 & IPv6 modernos. Con Bettercap hablamos de la facilidad de uso y de la facilidad de extensión. Respecto a MITMf, quizá una de mis favoritas, hablamos sobre todas las posibilidades que la herramienta ofrece. La primera escrita en Ruby, la segunda en Python. El autor de Bettercap decidió migrar la herramienta al lenguaje Go, dejando atrás a Ruby. Además, la herramienta ha sufrido un cambio de repositorio oficial.

Figura 1: Bettercap 2: La evolución de la navaja suiza de red y el poder de los Caplets

En febrero de este año Evilsocket, investigador de seguridad autor de Bettercap, lanzó un comunicado en su sitio web. Estaba lanzando la segunda generación de Bettercap con el cambio de lenguaje y la reimplementación de la mayoría de funcionalidades.

Figura 2: Comunicado de BetterCap 2.0

Lo interesante de la nueva generación de Bettercap no era solo el disponer de ataques MITM de red modernos, si no poder monitorizar y hacer ataques 802.11 y BLE, incluso desde un macOS. Esto es algo que me llamó la atención, por lo que quise encontrar hueco para probarlo.

¿Qué cosas ha cambiado Bettercap 2?

Realmente son más de las que uno puede pensar. En principio, uno puede pensar que ha perdido en flexibilidad, ya que ahora la herramienta no se ejecuta con parámetros, se ejecuta de forma interactiva como veremos más adelante. Esto realmente la hace más flexible, más configurable, pero uno debe aprender un poco la sintaxis para interactuar.

¿Qué son los Caplets?

Quizá la cosa más interesante, junto a los ataques BLE y WiFi, sea la posibilidad de utilizar Caplets. Un Caplet es un fichero con extensión .cap que implementa un script de Bettercap. No deja de ser un fichero de texto que por cada línea dispone de una instrucción a ejecutar, tal y como ocurre con los ficheros RC de Metasploit.

Figura 3: Caplets en Bettercap 2.0

Dentro del proyecto Bettercap podemos encontrar un repositorio con un gran número de Caplets, que entiendo irá creciendo con el paso del tiempo. Sin duda, una forma sencilla de poder implementar ciertas configuraciones y ataques. Obligatorio echar un ojo al código y a las instrucciones que ejecutan estos caplets.

Interactuando y entendiendo el nuevo Bettercap

Cuando se ejecuta Bettercap aparece un prompt que indica la dirección IP. Si tabulamos en el prompt veremos las diferentes opciones, entre las que encontraremos caplets, de los cuales hablaremos más adelante. Principalmente encontramos módulos como:

• Events. Con este módulo podemos controlar el tipo de información visualizamos, aplicar filtro sobre ésta, etcétera. 

• Arp. Con este módulo podemos realizar ataques de ARP Spoofing. 

• Wifi. Con este módulo se puede monitorizar el estado de redes y montar puntos de acceso de tipo Rogue. 

• Wol. Generación de tramas de tipo Wake On Lan. 

• http y https proxy. Este tipo de soluciones implementan proxies http y https con diferentes opciones como la inyección de código Javascript, manipulación de tráfico, generación de certificados, SSL Strip, etcétera. 

• Net. Este módulo permite sniffar la red a través de una interfaz o de otras. Se puede almacenar la información en un PCAP y mostrar en la interfaz el tipo de tráfico obtenido.  

• Servidores Rogue. de tipo MySQL y http. 

• Compatibilidad con IPv6. Perfecto para probar todos los ataques del libro de Ataques en rede IPv4 & IPv6.

Figura 4: Funciones de Bettercap 2.0

A modo de ejemplo y de facilidad de uso configuraremos un ataque de tipo ARP Spoofing. Con dos líneas en Bettercap obtenemos el efecto deseado. El comando set, configura el parámetro targets dentro del módulo Spoof, tal y como se puede ver en la imagen siguiente. Una vez configurado los targets se puede arrancar el envenenamiento a través de la instrucción arp.spoof on.

Figura 5: Configurando un arp spoofing

Con la opción help se pueden ver los módulos que hay en ejecución y cuáles no. Es un interesante comando para poder los módulos que disponemos en la herramienta.

Figura 6: Módulos de la herramienta

Ahora si queremos activar el proxy http podemos configurar los siguientes parámetros. Se puede configurar el puerto del proxy, la dirección a la que hacer bind, configurar si queremos SSL Strip a través del proxy, si queremos inyectar código Javascript en el HTML con la opción http.proxy.injectjs o si queremos ejecutar algún tipo de script con la opción http.proxy.script.

Figura 7: Configuración de proxy http

En la siguiente imagen se puede ver cómo se puede configurar el proxy y cómo se activa el sniffer para poder visualizar el tráfico o volcarlo en un fichero.

Figura 8:  Volcado de info de proxy

Aquí se puede jugar con events.stream, ya que si lo configuramos a false no se visualizará por pantalla, pero podemos indicar a net.sniff con el comando set net.sniff.output dónde queremos volcar el buffer de red a un fichero PCAP.

PoC: Funcionando con Caplets

Los caplets son scripts que están para facilitarnos la vida. Es muy interesante abrirlos y ver cómo están configurando Bettercap. Para este pequeño ejemplo vamos a utilizar uno que utiliza el Proxy http para volcarnos el contenido de las peticiones http. Desde el terminal se hace uso del parámetro caplet para indicar el script que queremos utilizar, mientras que con el parámetro eval se puede indicar una serie de instrucciones que queremos ejecutar, serán complementarias a lo que marca el caplet.

Figura 9: Usando un caplet

En este caso, tenemos ahora mismo funcionando el proxy y se ha realizado a través del parámetro eval un ataque de ARP Spoofing como el anterior. Como se puede ver en la imagen, se muestran las cabeceras http y el contenido de formularios y cualquier cosa que vaya en el protocolo.

Figura 10: Caplet funcionando

Por último, indicar que con la opción caplets.update podemos actualizar los scripts disponibles y que automatizan el uso de la herramienta. No dudes en estudiarlos y poder ampliar funcionalidades a través de ellos. Por otro lado, la opción show de caplets permite mostrar el número de caplets disponibles en la máquina por Bettercap2.

Figura 11: Caplets disponibles

Sin duda, una herramienta para estudiar y practicar. Hay que llevarla en la mochila en cualquier Ethical Hacking, ya que su segunda generación aporta una frescura y un potencial más que interesante. Parece que Bettercap es un proyecto muy vivo.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

Aprende a crear aplicaciones GO protegidas con Latch en 1 hora

Durante el mes de Agosto os dejé publicado por aquí información del nuevo SDK de Latch para GO que habían hecho mis compañeros, para que pudieras añadir a tus aplicaciones en GO! una capa de protección de Latch.

Figura 1: Aprende a crear aplicaciones GO protegidas con Latch en 1 hora

Durante este mes de Septiembre Fran Ramírez y Rafael Troncoso - nuestros escritores de Microhistorias: Anécdotas y curiosidades de la historia de la informática - han hecho una CodeTalk for Devs que explica en detalle cómo se puede utilizar durante una sesión en vídeo de una hora y poco en la que se sigue el uso del SDK de Latch para GO desde el principio hasta su funcionamiento final en las apps.

Figura 2: CodeTalk4Devs: Latch en Go!

Como sabéis, seguimos haciendo las ElevenPaths Talks y también las CodeTalks for Devs, con nuevas temáticas, y si quieres formarte un poco más, este jueves puedes seguir el Security Innovation Day 2017 por Streaming.

Saludos Malignos!

Friends, tenemos un nuevo SDK de Latch para Go!

Tanto mi gran amigo Rafael Troncoso (@tuxotron) como yo, somos dos usuarios de Latch y llevábamos mucho tiempo queriendo implementarlo a nivel de desarrollador en algún proyecto propio. Aunque hemos hecho algunas pruebas para integrarlo en Raspberry Pi y otros proyectos relacionados con el IoT, finalmente nos hemos decidido por un SDK en uno de los lenguajes que mayor popularidad está ganando en los últimos meses. Hablamos del lenguaje Go, desarrollado por Google. Antes de nada, indicar que esta versión de SDK Latch para Go no es oficial de ElevenPaths.

Figura 1: Friends, tenemos un nuevo SDK de Latch para Go!

Rafael ha creado una primera versión de este SDK y hemos estado realizando varias pruebas sobre él para comprobar que las funciones básicas funcionan correctamente. Pero antes de entrar en materia queremos explicar por qué nos hemos decidido por el lenguaje Go. Primero porque si el legendario Ken Thompson, uno de los padres del Lenguaje C, es uno de los desarrolladores y por lo tanto hay que prestarle mucha atención. De hecho, otra de sus ventajas es su sintaxis, la cual es bastante parecida al Lenguaje C por lo que no será difícil acercarte a Go si tienes conocimientos de este lenguaje. Además, ha heredado la mayoría de las características (y mejorando otras) que han hecho del Lenguaje C una referencia en el sector.

Figura 2: SDK de Latch para Go (no oficial)

Antes de comenzar, suponemos que tienes ya una cuenta de Latch como desarrollador. También será necesario que tengas instalado Go para el sistema operativo que estés utilizando Windows, Linux o macOS. El último paso es tener instalado Latch para tu Smartphone. Esto puedes hacerlo directamente desde la tienda de la plataforma que utilices o desde este enlace.

Utilizar el SDK de Latch para Go

Nosotros haremos las pruebas desde un ordenador con Linux. Utiliza el siguiente comando para instalar el SDK Latch para Go:

# go get github.com/tuxotron//latch-sdk-go

Finalmente estará instalado en la siguiente ruta:

$GOPATH/src/github.com/tuxotron/latch-sdk-go/

Es fundamental obtener los valores Application ID y Secret, desde la consola de administración web de Latch, en el menú Manage Applications. Sobre la aplicación que queramos proteger pulsamos la opción Edit, tal y como se muestra a continuación:

Figura 3: Menú de Latch donde podemos ver el ApplicationID y el Secret

En nuestro ejemplo, obtenemos los siguientes valores:

• Application ID: 7p9hrnmiWLf8EpbNcPFNfkaCrzPjW3kzTt2rrW9c
• Secret: YkmAJAX2W4v4JU9jP3Ce

Ahora procederemos a hacer algunas de las llamadas básicas de Latch utilizando el SDK de Latch para Go. Utilizaremos un fichero que hemos llamado main.go que puedes ver a continuación:

Figura 4: Fichero main.go en el SDK de Latch para Go

El código de este programa creará una instancia en Latch de nuestro servicio. Añadiremos en Latch desde la aplicación del Smartphone, un nuevo servicio para poder asociar nuestra aplicación. Luego lo pareamos con la opción Pair with Latch:

Figura 5: Opción de Latch donde podemos activa "Pair with Latch"

Esta opción nos devolverá un token temporal de pareado de 6 dígitos.

Figura 6: Token Temporal de Pareado devuelto por Latch

Ahora tendremos que añadir la llamada para realizar el pareo en nuestro código anterior. El código añadido son las líneas 3,12,13,14,15,16,17,18 y 19 en el fichero main.go.

Figura 7: Configuración de pareado con Latch

La línea 12 realiza una llamada a la función pair con el token recibido en la aplicación móvil. El resto del código se encarga de imprimir por pantalla el resultado de la llamada. Finalmente, cuando ejecutemos go run main.go devolverá el accountId, que será parecido al que mostramos a continuación:

OK {"accountId":"zZhqg7H9pabaZDDJg4y2HcFWCjZtDm6yXBg7QDdrKNjBJfreirxzjY74R2dtxbta"}

Este valor de accountId es necesario para comprobar el estado de nuestra aplicación desde Latch. Una vez realizado el pareo no necesitaremos más la opción PairWithToken(...) así que la comentamos en el código (línea 12) y añadimos una nueva línea para comprobar el estado de Latch status(...) que puedes ver en la línea 13:

Figura 8: Accediendo al estado de un accountID en Latch

La llamada status recibe tres parámetros, accountId, el cual recibimos cuando hicimos el pareado y los otros dos son valores booleanos (ver documentación Latch). Si ejecutamos nuestro código ahora y no tenemos nuestra aplicación bloqueada con Latch tendríamos que ver una salida parecida a la siguiente:

OK{"operations":{"WcqfYQErkANrk7wfijgv":{"status":"on"}}}

Recibimos el ID de la operación y el estado de Latch, que en este caso está activada, es decir, no bloqueada.

Figura 9: Activación de Latch sobre nuestro servicio

Cuando bloqueamos nuestra aplicación desde Latch, obtendremos una salida similar a la siguiente:

OK{"operations":{"WcqfYQErkANrk7wfijgv":{"status":"off"}}}

La aplicación está bloqueada por Latch y como hemos incluido el parámetro silent con el valor falso, recibiremos una alerta en nuestro smartphone como esta:

Figura 10: Aviso de alerta de acceso a Latch

A modo de resumen, estos son los pasos que tenemos que realizar para poder proteger un servicio Latch:

1. Obtener Applicaction ID y Secret 

2. PairWithToken con el token obtenido en la aplicación móvil. 

3. Llamar a la función status con el accountId, y comprobamos si el estado (status) está a ON (permitido) , si el estado está a OFF evitamos la ejecución de la operación y notificamos al usuario con el algún tipo de error.

Finalmente, para quitar el pareo de la aplicación podemos usar la función Unpair, y le pasamos como parámetro el accountId:

Figura 11: Opción de Unpair en linea 12

Recibiremos una alerta en el móvil indicando que todo ha ido bien:

Figura 12: Alerta recibida una vez hemos hecho el Unpair del servicio

Esperamos que os haya gustado esta primera introducción al SDK Latch en Go. Seguro que haremos más pruebas e implementaremos más funciones que compartiremos con todos vosotros.

Autores: Fran Ramírez (@cyberhadesblogç), Investigador de ElevenPaths y escritor del libro “Microhistorias: anécdotas y curiosidades de la Informática” y  Rafael Troncoso (@tuxotron),  co-fundador del blog CyberHades y escritor del libro “Microhistorias: anécdotas y curiosidades de la Informática”

Cómo usar Latch en tu día a día: Ejemplos, códigos y Tutoriales

Ya os había avanzado que los premios para el último Latch Plugin Contest han sido concedidos, pero algunas de las ideas que nos han presentado merecen la pena revisarlas en detalle. En este artículo os voy a dejar información de seis Plugins y un SDK que tal vez te estimulen intelectualmente para crear algo nuevo, o te den idea para un Proyecto de Fin de Grado o de Máster, o para que lo uses como forma de fortificar algún sistema de seguridad en tu empresa.

Figura 1: Cómo usar Latch en tu día a día: Ejemplos, códigos y tutoriales

TwLatch: Un hack de Latch para Twitter

El primer premio del concurso se lo dimos a TwLatch, un hack que controla lo que se publica en tu cuenta Twitter para evitar que una app maliciosa, o un Community Manager "descontrolado", publique twitts en tu time-line sin tu consentimiento. Es un hack que nos ha gustado en su idea e implementación, y por eso le dimos el primer premio. Este es el vídeo que lo explica y el código lo tienes disponible en GitHub: TwLatch.

Figura 2: TwLatch - Hack de Latch para Twitter

SDK de Latch para GO y Latch CMD

El segundo premio se lo dimos a este proyecto doble, en el que primero se construyó un SDK de Latch para el lenguaje GO (GoLatch) y después, con él, se creo Latch CMD, que permite controlar por medio de comandos tus aplicaciones Latch. De esta forma puedes automatizar las tareas en script, automatizar el control de cada Latch en función de flujos de tareas, etcétera. Este es el vídeo de Lath CMD:

Figura 3: Latch CMD usando SKD de Latch para GO
Tienes los códigos en las siguientes URLs:

- SDK de Latch para GO
- Latch CMD

Latch Proxymity: Zonas físicas de seguridad con Latch

Este plugin permite, utilizando la API de desarrolladores de Latch, evitar que un usuario pueda desbloquear su Latch si no está en una zona de seguridad. Para ello, se utiliza una Raspberry Pi en la que se carga Latch Proximity (escrito en Python) que monitoriza el estado de Latch de un usuario y cuando se cambia el estado se verifica si está cerca el dispositivo físico. Si no está, se usa la API de desarrollador y se le bloquea el Latch al usuario, tal y como se explica en este vídeo donde se ve la banda naranja indicando el cambio.

Figura 4: Funcionamiento de Latch Proximity

LatchWake: Controlar el apagado y encendido de redes de ordedores

Este es otro plugin que hace uso de una Raspberry Pi para cargar un plugin que verifica cuál es el estado de Latch. Cuando el estado es abierto, LatchWake enciende los ordenadores de una red de equipos. Esto - si has leído el libro de Wardog y el mundo te sonará de una historia -. Este vídeo explica el funcionamiento.

Figura 5: Funcionamiento de LatchWake
Latch para NUXEO

La plataforma NUXEO es para gestionar sitios web con alto contenido multimedia. Por supuesto, tiene gestión de usuarios, y con este plugin puedes poner un Segundo Factor de Autenticación usando Latch a las cuentas de usuario. Aquí tienes un ejemplo de funcionamiento de Latch para Nuxeo.

Figura 6: Latch para NUXEO
Lockifi: Apaga y enciende la WiFi con con Latch

Este plugin se basa en un programa Windows con un script para conectarse al router y apagar o encender la red WiFi. Para decidir qué script debe lanzar, se verifica el estado de una cuenta de Latch pareada con el servicio. Aquí tienes el código de Lockifi y en el siguiente vídeo la explicación de su funcionamiento.

Figura 7: Lockifi para controlar tu red WiFi con Latch

Latch para MediaWiki

Este plugin sirve para añadir un 2FA a todas las cuentas de usuario de las plataformas MediaWiki usando Latch. Tienes una explicación detallada del plugin en este artículo: Fortificar Mediawiki con Latch y en este vídeo tienes un ejemplo de uso.

Figura 8: Latch para MediaWiki

Al final, el uso del pestillo digital de Latch tiene muchas utilidades, muchas más de las que se nos ocurren a nosotros mismos. Puedes adaptar las cosas al control de tu Latch. Si quieres hacer algo, puedes consultar con nuestros técnicos en la Comunidad Latch en Eleven Paths, y si quieres hacer un proyecto y necesitas ayuda extra ponte en contacto con nosotros que intentaremos resolver tus dudas.

Saludos Malignos!

Latch^3: Ganadores de Latch Plugin Contest 2015, charla de Latch en IoT y la integración de Latch con Spamina.

Después de mucho tiempo metidos en decenas de proyectos diferentes, esta ha sido una semana muy "Latch" en Eleven Paths, pues no solo hemos tenido integraciones con varios clientes nuevos, sino que además se nos han concentrado muchos anuncios y actividades en una sola semana. Primero el lanzamiento del plugin de Latch para Jenkins, luego la charla de Eleven Paths Talks dedicada a Latch para el mundo de IoT (Internet of Things), luego el anuncio de los ganadores del concurso Latch Plugin Contest 2015 y por último el anuncio de la integración de Latch en el servicio de Clean e-Mail. 

Figura 1: Latch^3. Ganadores del Latch Plugin Contest, Latch & IoT y Spamina

Para completar la información que ya os había dejado por aquí, os dejo en primer lugar la sesión de la charla que dio nuestro CSA Jorge Rivera sobre cómo integrar Latch en el mundo IoT. Como ya os he publicado, hay ya muchas demostraciones del partido que se le puede sacar a Latch en el mundo físico.

  Figura 2: Sesión dedicada a la aplicación de Latch en el mundo IoT

En segundo lugar os dejo la lista de los ganadores del Latch Plugin Contest 2015. Ya os publicaré en detalle los vídeos, los enlaces a los repositorios de código y los manuales por si quieres probar los trabajos realizados por los ganadores. El próximo 26 de Mayo, dentro de nuestro próximo evento "Security Day 2016", le dedicaremos a los plugins una sesión.

Figura 3: Latch Plugin Contest 2015

Primer premio [5.000 USD] para Daniel Crespo por Twlatch (Twitter + Latch) 

Descripción: Twlatch (Twitter + Latch) permite en cierta forma crear un Latch sobre Twitter basado en aun aplicación para la plataforma. Si bien no bloquea el acceso directamente, sí permite eliminar inmediatamente los nuevos Tweets cuando se bloquea el Latch. Si bien no es una solución perfecta en algunos sentidos, sí que se ha encontrado una forma interesante de acercarse a una plataforma tan popular como Twitter sin necesidad de "hacks".

Segundo premio [2.000 USD] para Mikel Pintor por Latch para Go

Descripción: Implementa en el lenguaje Go, un sistema para utilizar Latch de forma cómoda por línea de comando en cualquier plataforma, lo que facilita su uso en scripts y otros programas. Como "efecto colateral" ha creado un SDK en Go. Latch para Go facilita el uso en otros entornos y a través de la línea de comando. Además, se ha implementado un nuevo SDK en un lenguaje de interés.

Tercer premio [1.000 USD] para Jorge García Bueno por meta Latch

Descripción: Se trata de un "meta Latch" que permite que los latches funcionen solo cuando se está dentro de una zona física de "proximidad" a un dispositivo que se conecta con Bluetooth. Una vez en la zona, se puede bloquear o desbloquear los latches automáticamente gracias a un token que porte el usuario. Lo que nos ha gustado es que trata de una capa de seguridad adicional que, si bien no es perfecta, aporta fórmulas interesantes aplicables a la vida real donde se facilita aún más, si cabe, el uso de la tecnología Latch.

Mis felicitaciones a los ganadores por el trabajo y esperamos que hayan disfrutado con el reto a la vez que aprendido cosas nuevas. Ahora, con el premio, a darse un buen capricho que os lo habéis ganado.

Por último, como ya anunciamos el viernes en el blog de Eleven Paths, el servicio de Clean e-Mail que damos desde Telefonica a través de nuestra alianza estratégica con Spamina, permite ahora a los 40.000 clientes de este servicio de seguridad para el correo electrónico que pueden usar Latch para controlar aún más los mecanismos de protección de su buzón.

Figura 4: Los clientes de Clean e-mail pueden usar Latch con Spamina

Si quieres ver las posibilidades de integrar Latch en algún sistema, no dudes en ponerte en contacto con nosotros que te asesoraremos y ayudaremos en todo. Además, recuerda que siempre puedes preguntar en la sección Latch en nuestra comunidad técnica en Eleven Paths.

Saludos Malignos!