miércoles, 30 de agosto de 2017

Seguridad en ChatBots

La industria de la Inteligencia Artificial está en pleno apogeo, se han depositado muchas esperanzas en ella y se está trabajando en muchos laboratorios creando nuevos “cerebros”.
El “Machine Learning” es un camp que está disfrutando de una época dorada gracias a la nube y el crecimiento de información disponible preparada para ser procesada. Estas evoluciones crearán pronto inteligencias que, según Stephen Hawking, acabarán con nosotros ya que podrán evolucionar más rápido y pronto serán más inteligentes.
Puede que eso suceda o puede que no, por el momento la representación más “a pie de calle” que existe sobre la IA son los ChatBots. ¿Quién no ha sido respondido nunca por uno en Telegram? ¿Quién no ha abierto una página web y una ventana de Chat con un amable señor/señora le pregunta si puede atenderle?
Resultado de imagen de chatbot
Es la versión más light de Inteligencia Artificial, pero ya se puede hacer mucha operativa interesante con ellos, por ejemplo encargar pizza, hablar de fútbol, ser tu entrenador personal, buscarte los mejores precios del producto que quieras por cientos de webs, ser tu shopping assistant,... Como se pueden ver las opciones ya son miles, por si queréis conocerlos y probarlos os referencio a BotList una web que colecciona ChatBots de todo tipo.
Pero los ChatBot no son ninguna excepción y tienen problemas que hay que revisar en cuanto a seguridad. Dejando de lado el ciclo de desarrollo seguro es un pequeño decálogo para que podáis evaluar en vuestros robots.

1.- ChatBot aislado
El sistema que contiene el ChatBot tendría que estar aislado. Lo ideal es una máquina que contenga solo al Bot y no esté conectada con el resto de la red corporativa.
2.- ChatBot que nunca llama a teleoperadoras.
Si tu sistema de ChatBot te da la posibilidad de poder contactar con una teleoperadora el sistema más seguro para hacerlo es que el usuario indique el número al que se le quiera llamar y que sea una operadora el que le llame a él. Si es el chatbot el que lanza la llamada para conectar de forma directa un atacante podría lanzar miles de peticiones haciendo un ataque de DoS contra la centralita bloqueandola con miles de llamadas entrantes y dejando a los verdaderos clientes en espera e incluso desconectados. Esto haría daño reputacional y puede que se perdieran potenciales clientes.
3.- Sistema contra suplantación.
Un atacante puede que trate de suplantar nuestro ChatBot en otras páginas. Dependiendo que tipo de operativa haga dicho bot puede resultar muy fructífero. Dependiendo en qué plataforma tengamos nuestro ChatBot podría ser más o menos fácil implementar técnicas contra la suplantación. En el entorno Web podrían ser las mismas que contra un phising, en Telegram saludar de forma personalizada a nuestro cliente, de forma que sepa que solo nosotros podemos conocer esa información u otro tipo de medidas creativas que en función de las características de nuestro ChatBot podemos poner.
4.- Canal cifrado.
Esto es un máxima, en todo momento que el canal de la conversación este cifrado. Esto en Telegram puede ser un problema ya que (hasta hace poco) no soportaba establecer canal seguro para bots. Pero en el resto de casos debería ser obligatorio para nuestra tranquilidad.
5.- No almacenar información.
Nunca almacenes las conversaciones, en primer lugar por la privacidad de tu usuario y en segundo lugar porque almacenar la información puede suponer que un atacante te llene la memoria provocando, en el mejor de los casos, la caída de tu servidor.
Si necesitas almacenar la información por logs o seguridad en la operativa ten unas reglas muy bien definidas.
6.- Sanitiza los datos
Nunca sabes lo que un usuario o un atacante puede intentar meter en el chat por lo que sanitizar los datos para que no puedan intentar ejecutar una inyección de código es una idea muy saludable.
7.- Deshabilita los comandos que no quieras usar.
Los chatbots tienen muchos comandos con funcionalidades muy diversas y no siempre necesitamos todas las disponibles por lo que os recomiendo que aquellas que no queréis/necesitáis se eliminen o comenten o hagáis lo que queráis pero que en ningún caso sean accesibles.
8.- No permitas que el ChatBot ejecute comandos de sistema
Tenemos aislado el sistema y controlado que datos guardamos pero sigue siendo muy importante que nuestro ChatBot en ningún momento pueda ejecutar comandos en el sistema que lo aloja.
9.- Prueba de vida.
Esto también depende mucho de la plataforma sobre la que tengamos nuestro bot pero es muy interesante poner un sistema que valide que el usuario está vivo. Puede que, un Captcha para los entornos web o preguntas en entornos Telegram, sean alguna buena idea para esto. Nos ahorraremos muchos dolores de cabeza contra ataques por fuerza bruta.
10.- Agrega un TTL
Agregar un TTL puede salvarte de problemas muy diversos. Si tu ChatBot genera sesión con el usuario, que esa sesión tenga un tiempo máximo de vida. Poner un TTL entre interacción e interacción también es interesante.

Solo revisando estas pequeñas pautas ya se puede intuir que hay ChatBots con características muy diversas. Dependiendo en que plataforma lo queramos implementar y dependiendo de lo sensibles que sean las funcionalidades queramos que haga hay que pensar diferentes medidas.
Todo esto pensando en los ChatBots cuya lógica aún es muy sencilla, el día que tengan un motor potente de IA por detrás puede que (aquí me sale mi ramalazo de ciencia ficción) existan vulnerabilidades a través del razonamiento.

Queda mucho campo por delante para recorrer.

miércoles, 23 de agosto de 2017

Lectura de Verano 2

Este verano me estoy metiendo de lleno en el mundo del Blockchain, por aventuras de las que ya os hablaré más adelante (aún está la cosa muy verde) estoy leyendo todos los libros y paper que caen en mis manos sobre la materia.
Quería traeros otra recomendación para estas vacaciones, de entre todos los que me he leido por ahora quería destacar el de “Melanie Swan”, iba a comentaros un poco sobre su contenido pero da la casualidad que revisando mi feedreader he ido a topar con este post de Alaxei Manalov (Kaspersky) donde, referenciando a este mismo libro, nos hablan de los seis mitos de Blockchain.
Por lo que para quienes estén interesados en este campo os dejo tres referencias de interés:

viernes, 18 de agosto de 2017

Autenticación y biometría: Retos y posible solución



Hace tiempo que muchas grandes empresas buscan alternativas para la autenticación de sus clientes/usuarios. Algunos de los sistemas que usan para poder realizar autenticación son:
  • Contraseñas, las cuales se consideran por defecto como vulneradas o fáciles de obtener vía phising, compradas en el mercado negro o cualquier otro imaginativo método.
  • SMS: En muchos países es muy sencillo poder hacer un duplicado de SIM por lo que el SMS no es suficiente para ayudar en un proceso.
  • Authenticator: Esos códigos numéricos que duran solo un breve lapso de tiempo, en mi opinión bastante útiles pero si es cierto que si te han vulnerado el correo o la cuenta con la que pidas esos códigos estamos igual.
  • Tarjetas de coordenadas: Los grupos organizados hacen campañas de phising pidiendo tarjetas completas las cuales los usuarios, pacientemente, meten. No quiere decir que tengan todas vulneradas, pero sí que es una medida temporal y que si se proponen pronto tendrán todo el parque de tarjetas en su conocimiento.
  • Correo electrónico: Las cuentas de correo se consideran como vulneradas, los usuarios suelen usar contraseñas sencillas, predecibles o siempre las mismas por lo que en alguna BBDD de contraseñas robadas puede estar la del usuario.
La situación es bastante crítica para las grandes empresas por lo que pensando una posible solución se llegó a que era el momento de invertir en biometría. El futuro estaba en pasar del “lo que tengo” o “lo que sé” al “lo que soy”.
Referencia de la imagen

No voy a explayarme contando como funciona, en YouTube hay muchos vídeos sobre biometría (facial, táctil, voz, iris,...) pero éstos planteaban nuevos problemas.
Las principales biometrías estudiadas son:
  • Facial: Se dispone del Hardware necesario ya que todos (o la inmensa mayoría) los móviles tienen cámara las cuales no se necesita que sean muy potentes, por lo que la convierte en el candidato perfecto.
  • Táctil: La famosa huella dactilar. Este sistema tiene dos problemas principales. El primero es que no se controla el hardware ni el proceso de obtención en ningún momento, hay que confiar en el dispositivo móvil y éstos por definición no son confiables. En segundo lugar huellas solo tenemos 10, si el crimen organizado decide invertir recursos en ésto y se dispone a robar huellas cuando tenga tus 10 estarás vulnerado (y no creo que quieras poner las de tus pies).
  • Voz: Demostrado que es la biometría más sensible y difícil de emular, el problema es que necesita un micrófono muy potente para poder grabar todos los indicadores que te van a diferenciar.
  • Iris: Descartado por defecto, necesita una cámara muy potente de la cuales el grueso de los usuarios no dispone.
  • Reconocimiento de firma escrita: Ya se ha hablado hace tiempo sobre cómo poder vulnerar este sistema. Referencia 1 || Referencia 2
Bien pues visto el panorama las empresas decidieron invertir en biometría facial, el problema es que éste sistema va a nacer marcado de muerte. Ya se han realizado pruebas por las cuales el crimen organizado puede industrializar el hacerse pasar por otra persona, con movimientos incluidos (os adjunto el vídeo porque es sorprendente), por lo que nos plantamos ante un nuevo reto ¿como podemos autenticar de forma segura a nuestros usuarios?
Dado este planteamiento muchos apostaran por el “lo que soy” + “lo que sé” ó “lo que soy” + “lo que tengo” pero de una forma poco acertada combinando los sistemas que hemos visto anteriormente:
  • Biometría + usuario/contraseña → Vulnerado
  • Biometría + SMS → Vulnerado
  • Biometría + Authenticator → Menor riesgo pero vulnerado
Resultado de imagen de facial biometric authentication
Referencia de la imagen
Creo que con esto entendemos el problema ante el que están las grandes empresas ¿solución?
Hace poco cayó en mis manos un paper curioso: “SMAUG: Secure Mobile Authentication Using Gesturesen este estudio proponen un sistema para autenticación segura de usuarios combinando el sensor de huellas con el giroscopio y el acelerómetro de forma que puedas hacer una combinación con tus huellas+movimiento del móvil y así crear un patrón que te identifique. El documento no tiene desperdicio, es un estudio muy completo pero nace con problemas de base:
  • No tenemos control sobre el lector de huellas y el proceso de lectura de las mismas en los dispositivo móviles. Ésto es 100% realizado por el SO y solo nos devuelve un true/false, pensemos en dispositivos móviles rooteados ¿Seguís tranquilos con la idea?
  • No tenemos control sobre cómo realiza el alta de ese patrón. Si no somos capaces de identificar al usuario durante el alta puede estar haciéndolo otra persona en su lugar generando un patrón desconocido para nuestro cliente.
  • ¿Que podemos guardar nosotros? Al no tener control sobre el táctil no podremos controlar fácilmente el patrón
Pero la idea es buena, es muy buena. ¿Que tal si fuéramos un paso más allá?
Dado que las grandes empresas tienen (o están trabajando) sobre un sistema de biometría facial ¿porque no combinar patrones con dicho sistema?
Pero cuando digo patrones no me refiero solo a gestos con la cara (eso ya está muy visto) sino que puedas hacer un gesto con la cara, luego girar la cámara y hacer otro gesto con tu mano o un movimiento con el dispositivo que lo pueda captar el giroscopio…
Combina biometría facial, con giroscopio y acelerómetro puede dar lugar a una combinación muy atractiva de patrones muy diversos que logren hacer un nuevo concepto de “lo que soy” + “lo que sé” ya que la biometría capta lo que soy y el patrón capta lo que sabes.

De ese modo si nos roban nuestra cara y puede emular los gestos nos va a dar igual, tienen que conocer también nuestros movimiento y la velocidad con que lo hacemos. El más difícil todavía para que nos vulneren la autenticación.

viernes, 11 de agosto de 2017

Lectura de verano

Todos los veranos hago “la carta a los reyes magos”, esa lista con decenas de cosas que quiero hacer aprovechando la jornada reducida. Lo que normalmente sucede es que llegas a casa muerta de hambre y luego sucumbes a la siestecita por lo que esa lista siempre me ha quedado incumplida.
Este año con el doctorado ha sido muy distinto, he aprovechado mucho las tardes libres y, entre otras cosas de la que ya os hablaré he podido leer varios libros y hoy quiero traeros uno que me ha encantado.
Todo un clásico ¿Quién no conoce a Tanenbaum? El gran profesor que enseña sistemas con Minix (quien quiera sabe de dónde viene Linux que revise la historia de este SO).
Resultado de imagen de redes de computadoras tanenbaumQuería darme un repaso sobre redes y protocolos, sentía que era un aspecto que tenía olvidado y abandonado así que hace un par de semana compré el libro de Redes de computadoras.
Una maravilla, un libro que su primera edición es de 1980 y durante cada una de sus nuevas ediciones ha sido revisado y ampliado al completo, por lo que la profundidad con la que explica las capas de red, protocolos y la historia de internet es asombrosa.
Por ponerle una pega, la quinta edición es de 2012 y puede que se eche en falta una nueva actualización en algunos puntos.
A mi me ha valido para dar un repaso completo a lo que tenía ya olvidado, he aprendido muchas cosas nuevas y entre sus páginas se me han ocurrido varias ideas para trastear.
Que no os asusten sus casi 1000 páginas, os prometo que es toda una joya informática.

jueves, 3 de agosto de 2017

Primer intento de regulación en Seguridad en IoT, empieza la fiesta

El pasado 1 de Agosto Reuters lanzaba una noticia que, en mi opinión, es un gran paso en la evolución del IoT.
Los Republicanos Cory Gardner y Steve Daines junto con los Demócratas Mark Warner y Ran Wyden lanzaron una propuesta para comenzar a legislar la seguridad en las “cosas” que forman IoT.
Este paso es muy importante ya IoT está creciendo no solo en tecnologías propuestas (Zigbee, Z-Wave, MQTT, RFID, 6LoWPAN,...) sino también en asociaciones/empresas que comienzan a lanzar propuestas con compendios de seguridad para las “cosas” (OWASP, OneM2M, IETF, IoT Security Foundation, IoT Manifesto, Online Trust Alliance,...) pero todos esos esfuerzos son en vano si quienes producen las cosas no hacen caso a la seguridad.
Hay mucho camino por recorrer en la seguridad para IoT ya que en este entorno las reglas cambian ya que los requisitos de software/hardware son muy variopintos y, en muchos casos, muy limitados. Pero si no existe una obligación a nivel gubernamental igualmente no hay predisposición por solucionar estos problemas.
Se puede ver aquí la propuesta que han lanzado, con puntos tan interesantes como este pequeño extracto:


“IN GENERAL
.—A clause that requires the contractor providing the Internet-connected device to provide written certification that the device—
(I) except as provided under clause
(ii), does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security  vulnerabilities or defects listed in—
(aa) the National Vulnerability Database of NIST; and
(bb) any additional database selected by the Director that tracks security vulnerabilities and
defects, is credible, and is similar to the National Vulnerability Database;
(II) relies on software or firmware components capable of accepting properly authenticated and trusted updates from the vendor;
(III) uses only non-deprecated industry-standard protocols and technologies for functions such as
aa) communications, such as standard ports for network traffic;
(bb) encryption; and
(cc) interconnection with other devices or peripherals; and
(IV) does not include any fixed or hard-coded credentials used for remote administration, the delivery of  updates, or communication.”


Si esta normativa es aprobada estamos ante una era, en que habrá que correr por poder brindar soluciones a muchos retos pendientes en seguridad IoT. Empieza la fiesta.