El uso de identificadores en protocolos, la seguridad y la privacidad

Números Ya hace tiempo que no hablamos de aleatoriedad. En este caso vamos un paso más allá y traemos este ‘draft’ sobre las consecuencias de tener determinados identificadores en algunos protocolos: Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols.

La mayoría de los problemas han tenido que ver, tradicionalmente, con la predicibilidad tanto en números de secuencia, como en otros identificadores necesarioes en los protocolos.

En este momento va por la versión tercera y se analizan algunos algoritmos frecuentes de generación de estos identificadores (Sección 8), con los problemas de unicidad, predictibilidad. También las vulnerabilidades frecuentes (Sección 9).

Estos identificadores utilizados en protocolos deberían:

  • Estar bien identificadas las cuestiones relacionadas con la interoperabilidad.
  • Proporcioncionarse un análisis desde el punto de vista de seguridad y privacidad
  • Recomendar algoritmos que mitiguen los problemas indentificados.

Un tema que no siempre se tiene presente y que tiene su importancia.

Secretos compartidos. Cuidado con la confianza.

Oculto Lo miremos como lo miremos, somos gente confiada. Queremos compartir y lo hacemos con pocas precauciones. O esa es la conclusión habitual, que ya no nos sorprende mucho. En Keys, tokens and too much trust found in container images hablaban del tema relacinado con la compartición de contenedores.

Comprobaron las 1000 imágenes de contenedores más populares para ver qué encontraban por ahí y encontraron que al menos el 67% de las imágenes contenían, al menos, un secreto:

To get a taste of the prevalence of such secrets, we scanned the top 1,000 most popular container images found on public registries. We were not only looking for default passwords, but mostly for less obvious examples of secrets. We selected only the latest images, from the top starred public repositories. What we found convinced us that the risk is very real, as 67% of images had at least one form of a secret.

Tokens de acceso, certificados, máquinas no confiables aceptadas como si lo fueran, ficheros de autorización de contraseñas (authorized_keys), etc.

Compartir es bueno. Pero hay que hacerlo con cuidado.

Phishing y políticos de alto nivel

Pescando Es frecuente criticar a los usuarios por caer en las trampas más burdas y perjudicar la seguridad de la organización. Sin embargo, cualquier experimento que se haga muestra que los usuarios (de los más diversos perfiles) caen. Así que algo tendremos que hacer los técnicos para evitarlo.

En Here’s How Easy It Is to Get Trump Officials to Click on a Fake Link in Email hablan de un experimento contra políticos de perfil alto:

So, three weeks ago, Gizmodo Media Group’s Special Projects Desk launched a security preparedness test directed at Giuliani and 14 other people associated with the Trump Administration. We sent them an email that mimicked an invitation to view a spreadsheet in Google Docs.

¿Qué sucedió?

Algunos ignoraron el correo (decisión correcta), pero más de la mitad pincharon en el enlace, algunos varias veces:

Some of the Trump Administration people completely ignored our email, the right move. But it appears that more than half the recipients clicked the link: Eight different unique devices visited the site, one of them multiple times.

Aparentemente nadie introdujo datos (pero había avisos) y ya sabemos que el solo hecho de pinchar puede ser problemático. Un par de personas preguntaron para no pinchar sin saber (bien).

Curioso.

Aprender a programar con fallos de seguridad

En la pizarra Lo leí en algún libro (creo que en el de John Viega y Gary McGraw, ‘Building Secure Software’). Allí se decía que no sólo no se enseñaba el tema del desarrollo seguro sino que, además, los ejemplos que se podían ver en los libros de programación (en aquella época libros, fundamentalmente) eran de dudosa calidad desde el punto de vista de la seguridad. También se discutía (creo) sobre los ejemplos y sobre los ficheros de configuración. Desde entonces es un tema que suelo comentar (lo hice, por ejemplo, en la charla del otro día Una charla sobre seguridad en aplicaciones web: principios y más. Casi 20 años después seguimos igual: en Top-ranked programming Web tutorials introduce vulnerabilities into software nos dicen algo muy similar. Los tutoriales más importantes de desarrollo web incluyen ejemplos y soluciones vulnerables.

La forma de obtener el dato es curiosa: navegan por el repositorio GitHub y encuentran vulnerabilidades que pueden encontrarse en algunos textos introductorios disponibles por ahí.

Researchers from several German universities have checked the PHP codebases of over 64,000 projects on GitHub, and found 117 vulnerabilities that they believe have been introduced through the use of code from popular but insufficiently reviewed tutorials.

Utilizan la búsqueda en el repositorio de patrones bien conocidos de fallo, que se pueden encontrar en los tutoriales. Y encuentran problemas, claro:

Thanks to our framework, we have uncovered over 100 vulnerabilities in web application code that bear a strong resemblance to vulnerable code patterns found in popular tutorials. More alarmingly, we have confirmed that 8 instances of a SQLi vulnerability present in different web applications are an outcome of code copied from a single vulnerable tutorial,” they noted. “Our results indicate that there is a substantial, if not causal, link between insecure tutorials and web application > vulnerabilities.”

Casi nada. En un caso concreto 8 ejemplos de un fallo que proviene de uno de estos tutoriales.

Proporcionan sus herramientas GithubSpider para hacer las búsquedas, y ccdetection para hacer la detección de código similar.

Si haces cursos y tutoriales, o si ya tienes algunos publicados, tienes una responsabilidad.

También tengo que decir que hace años propuse algo así (cuando pensábamos en temas de propagación de información) relacionado con la propagación de errores en los programas a través de ejemplos, copia, etc. en una presentación que nunca llegué a publicar, así que pueden creerme o no sobre el tema.

Una charla sobre seguridad en aplicaciones web: principios y más

En clase El otro día mi amigo Gabriel del Molino (@gmolino) me invitó a dar una charla a sus alumnos de un curso de formación para desempleados donde reciben una panorámica de desarrollo web. La propuesta era abierta pero estaban especialmente interesados en temas de seguridad.

Como se trataba de una sesión única y no era plan de entrar en detalles técnicospreferí presentar algunos principios y completarlo con una introducción motivadora, algunas ideas sobre identificación y autentificación y, finalmente, recordar que nuestro trabajo casi siempre tiene que ver con la economía y con las personas.

Dejo aquí la presentación por si a alguien puede servirle de algo.

Seguridad aplicaciones web from Fernando Tricas García

Autentificación, validación e identificación de los usuarios. Cada vez un poco más allá.

Huella Se habla con mucha frecuencia de la autentificación, y de los diversos sistemas disponibles, pero no hay que olvidar que si queremos estar seguros no podemos confiar sólo en ellos. Cada vez más tenemos que utilizar la información adicional de la que dispongamos para estar seguros de que el usuario es quién dice ser.o

En Trust, but Verify: Authentication Without Validation Is Naïve daban algunas ideas sobre ello.

Primero, alguna paradoja: es más probable que las preguntas de seguridad las responda adecuadamente un atacante que el legítimo propietario de la cuenta:

Gartner research, however, found that users fail to answer their knowledge-based questions 15–30 percent of the time, while fraudsters answer correctly 60 percent of the time. Malicious actors often find this information on social networks or through phishing schemes.

Si confiamos en dispositivos como los teléfonos para la validación también nos podemos encontrar problemas:

his practice has shifted to mobile phones, with OTPs being sent as text messages. However, mobile malware can intercept these messages and forward them to fraudsters.

Y, desde luego, la biometría también tiene sus problemas:

… which has led to the exponential growth of fingerprint reader-enabled devices. It didn’t take long, however, for cybercriminals to circumvent this technology

¿Entonces? Como decíamos, hay que ser capaces de utilizar la información extra de la que dispongamos. Por ejemplo, sobre el comportamiento, y otros identificadores.

Una historia de los números aleatorios en informática

Dados Parece que el tema de la generación informática de números aleatorios ha ganado interés en los últimos años. Hoy lo decimos por el contenido de A Brief History of Random Numbers donde se habla del tema desde una perspectiva histórica: la aleatoriedad es algo muy abundante en la naturaleza, pero no es sencilla de obtener con herramientas humanas:

The randomness so beautifully and abundantly generated by nature has not always been easy for us humans to extract and quantify.

Los primeros intentos informáticos parecen datar de los años 40, de la mano de RAND Corporation:

… the modern world demanded a lot more random numbers than dice or yarrow stalks could offer. RAND Corporation created a machine that would generate numbers using a random pulse generator.

Posteriormente hubo algunos intentos más, hasta que surgió la idea de los generadores de números seudoaleatorios (pseudorandom number generator, PRNG). Se comentan algunas de las aproximaciones algorimicas y también curiosidades como LavaRand, diseñado por Silicon Graphics, y basado en un par de lámaras de lava y una cámara tomando imágenes. Por cierto, el método sigue vigente, según nos contaban en 10% of the Internet Is Encrypted with Lava Lamps, hablando del proveedor Cloudflare.

También se comenta sobre iniciativas como los servicios proveedores de números aleatorios, como Random.org y cómo, finalmente, Intel añadió en 1999 un generador en su chipset i810 para servidores, basado en el ruido térmico de los procesadores:

In 1999, Intel added an on-chip random number generator to its i810 server chipset. Finally, new servers had a good local source of randomness from thermal noise — a true random number generator (TRNG).

Sin embargo, no hay que olvidar que no sólo necesitamos números aleatorios, sino que los necesitamos a velocidad adecuada; y no sólo necesitamos números seudoaleatorios, sino que necesitamos números seudoaleatorios seguros (Aleatoriedad y juego en línea. No sólo para juegos, claro).

Finalmente, se habla (habiendo pasaro por otros temas) de las discusiones sobre qué esquemas de generación utilizar, cuando hablamos de programas con la seguridad en mente, o simplemente de otros usos menos comprometidos.

Las reglas para creación de contraseñas son basura

Cerrojo Personalmente, hace algún tiempo que dejé de dar consejos sobre la creación de contraseñas. Creo que la solución para cualquier usuario es utilizar un gestor de contraseñas y eso es lo que recomiendo cuando alguien me pregunta. O cuando med dejan decirlo sin que me pregunten. También digo, si alguien se empeña en crearlas y recordarlas que lo mejor es que sean largas (desde luego, más de 10 o 12 caracteres, en este momento).

Las normas de creación de contraseñas pueden tener sentido si se hacen bien, pero es bastante fácil que hagamos recomendaciones malas (he visto algunas horribles y otras que, en lugar de ayudarnos a mejorar nos perjudican) y que, aunque sean buenas, se sigan mal.

De ello hablaba Jeff Atwood en Password Rules Are Bullshit

Desde el otro lado, los consejos que da son:

  • Las reglas son una basura
  • Fuerza una longitud mínima (en Unicode)
  • Verifica que no se utilizan contraseñas comunes
  • Verifica que tienen una mínima diversidad (entropía)
  • Verifica casos especiales (usuario, correo, … No deberían ser contraseñas)

Interesante.

Colisiones en el sistema de resumen SHA1

Colisiones ensistemas de resumen En una bitácora como esta, que no sólo no es de actualidad sino que suele traer temas con bastantes meses, no se si tiene mucho sentido traer estas cosas pero me gusta guardarlas para tenerlas en algún sitio recopiladas.

Por eso traigo Announcing the first SHA1 collision que habla de una colisión en un sistema de firma (hash). La idea de estos sistemas es sencilla: no debería ocurrir que dos ‘mensajes’ diferentes produzcan el mismo resumen. En este caso anunciaban una forma de generar una colisión para el algoritmo SHA1. Para el común de los mortales esto significa, esencialmente, que ya podemos ir pensando en dejar de usarlo (si es que lo hacíamos). También es un recordatorio de que los ‘estándares’ que alguien nos recomendó en algún momento van quedando obsoletos y que no podemos dejarnos llevar por la costumbre y la comodidad.

A collision occurs when two distinct pieces of data—a document, a binary, or a website’s certificate—hash to the same digest as shown above. In practice, collisions should never occur for secure hash functions. However if the hash algorithm has some flaws, as SHA-1 does, a well-funded attacker can craft a collision.

En esa entrada nos recomendaban utilizar SHA-256 y SHA-3.

Comunicación de bots usando Slack

Mensajes Ya hemos hablado en alguna ocasión de las pruebas que voy haciendo con un bot conversacional (aviso: nada de inteligencia artificial ni procesado del lenguaje: sólo un conjunto de instrucciones predefinidas por mi mismo). Se puede ver un ejemplo en Segundo bot: avanzamos. Creo más en el concepto de Un chatbot como asistente personal que en otras ideas que podemos ver por ahí. Para estos desarrollos me gusta mucho el proyecto Errbot que nos proporciona una infraestructura para desarrollar bots conversacionales porque se desarrolla en Python, tiene un mecanismo de plugins para añadir instrucciones, una comunidad bastante amistosa y además mecanismos para interactuar a través de diversos canales.

Pero (siempre hay un pero) los desarrolladores no han contemplado la posibilidad de que un bot pueda escuchar en distintos canales a la vez. Yo empecé con un bot que escuchaba XMPP, pero los clientes no son muy cómodos y terminé pasándolo a Telegram: hay clientes para el teléfono móvil, para el escritorio, …

A veces preferiría enviar instrucciones al bot a través de un sistema basado en texto (tal vez la línea de instrucciones) y decidí probar con el IRC.

Algunos hemos pedido esta característica, pero no parece una prioridad para suficiente gente: multibackend, Support multiple backends in one instance.

Una posible solución sería tener dos bots replicados e indpendientes y que cada uno responda según se le vaya pidiendo. Sin embargo, dándole vueltas pensé en la posibilidad de establecer un mecanismo de coordinación: añadimos una función forward (fw para escribir menos) y si estoy en el canal del bot que no sabe ejecutar mi instrucción, le pido que la redirija a otro que pueda ser capaz. Por ejemplo, para saber el estado del otro bot, que es una instrucción estándar de Errbot (de momento estoy trabajando con dos, uno reconoce instrucciones que empiezan con ‘!’, y el otro con ‘,’) escribiríamos:

!fw ,status

Una vez planteada la funcionalidad, la decisión era como establecer la comunicación entre los bots. Una posibilidad sería comunicarlos directamente intercambiando mensajes entre ellos, pero entonces puede ocurrir que uno esté desconectado o inactivo y eso sería un problema.

¿Por qué no utilizar un mecanismo similar a los de mando y control (command and control) a través de un canal acordado donde los bots pueden escribir y leer?

Podemos definir una sintaxis (un lenguaje de comunicación) y hacemos que la instrucción fw escriba en el canal. Establecemos también un mecanismo de lectura del canal y cuando el bot encuentre un mensaje para él lo interpreta, lo ejecuta, y publica en el canal el resultado. Si el bot encuentra un mensaje de respuesta para él, envía dicha repuesta por su mecanismo de comunicación al usuario que pidió su ejecución.

Como prueba de concepto podemos echar un vistazo a err-forward (enlace a la versión actual porque es un proyecto vivo y podría evolucionar en el futuro) y también ver un vídeo de dos bots transmitiéndose instrucciones.

Para su desarrollo se han utilizado:

  • el mecanismo de creación de plugins de Errbot
  • el mecanismo de programación de actividades (Scheduling).
  • un canal común donde escribir y leer las instrucciones.

Todos conocemos sistemas de mando y control basados en IRC, correo electrónico, Twitter, … En nuestro caso había que elegir uno para nuestros bots. No soy un gran fan de Slack pero quería darle una oportunidad de uso y pensé que una buena forma sería creando allí el canal de intercambio de mensajes. Slack tiene un API y módulos en Python para interactuar con los canales (slackclient), así que parecía una buena opción para intentarlo.

De momento hemos definido tres tipos de mensajes:

  • Msg para mensajes textuales (saludos y despedidas de los bots y otros).
  • Cmd para instrucciones
  • Rep para respuestas

La creación de un bot en estas circunstancias se basa, entonces, en las siguientes funciones:

  • Inicialización: el bot empieza a funcionar, se conecta al canal y escribe un mensaje de ‘saludo’.
  • Escritura: el bot puede escribir un mensaje de cualquiera de los tres tipos anteriores en el canal.
  • Lectura: el bot lee el canal y es capaz de identificar los mensajes que puede interpretar, realizando las acciones oportunas y escribiendo en el mismo canal las respuestas, si procede.

No entraremos en detalles aquí pero para que un bot pueda leer y escribir en un canal de Slack es necesario tener un token que permita inteactuar con, por ejemplo, la Slack Web API.

Siguiendo desarrollos anteriores, almacenamos el token en un fichero denominado ~/.rssSlack con el formato:

[Slack]
api-key:......

La leemos utilizando el módulo configparser, creamos el cliente y publicamos el primer mensaje. El canal donde se comunicarán los bots es un parámetro de configuración del módulo, al que se accede a través de

    self._check_config('channel') 

Además el bot almacena el usuario del sistema oporativo y el nombre de la máquina, que se usará para enviar las respuestas cuando proceda. El mensaje de saludo incluye la dirección IP:

self['sc'] = SlackClient(slack_token)
self['chan'] = str(self._check_config('channel'))
self['userName'] = pwd.getpwuid(os.getuid())[0]
self['userHost'] = os.uname()[1]

self.publishSlack(typ = 'Msg', args = 'Hello! from %s' % self.getMyIP())

Aquí se ha utilizado el método publishSlack que sirve para escribir en el canal (lo comentaremos luego).

Después se inicializa el poller que lee periódicamente el canal para ver si hay algo que el bot pueda hacer:

    self.start_poller(60, self.readSlack)

Aquí se utiliza el método readSlack que sirve para leer en el canal (lo comentaremos luego) y, en esta configuración se ejecuta una lectura cada 60 segundos.

El método de publicación (publishSlack) es muy sencillo, simplemente prepara el mensaje y lo escribe en el canal. De momento, un mensaje tiene el formato:

    msg = {'userName': usr, 'userHost': host,
            'frm': str(frm), 'typ': typ, 'cmd': cmd, 'args': args }

Incluye el nombre de usuario y de la máquina del usuario, un campo frm que viene de la comunicación del bot, un tipo (typ) tal y como se explicó arriba, y los campos cmd y args que también provienen de la forma de funcionar de Errbot (instrucción y argumentos). El mensaje se codifica para que no se interprete como html, se transforma en json para que sea más fácil leerlo luego y se publica en el canal:

    chan = self['chan']
    self['sc'].api_call( "chat.postMessage", channel = chan, text = msgJ)

El método de lectura (readSlack) es algo más complicado: tiene que leer en el canal la lista de mensajes, decidir si alguno de ellos es para el bot en cuestión, interpretarlo, …

La lectura del canal es sencilla:

    chan = self.normalizedChan(self._check_config('channel'))
    history = self['sc'].api_call("channels.history", channel=chan)

Luego hay que recorrer la lista de mensajes y actuar según proceda:

for msg in history['messages']:
     msgJ = self.extractArgs(msg)
     if ('typ' in msgJ):
         if msgJ['typ'] == 'Cmd':
             # It's a command 
             self.manageCommand(chan, msgJ, msg)
         elif msgJ['typ'] == 'Rep':
             # It's a reply 
             self.manageReply(chan, msgJ, msg)

Como puede verse, se utilizan algunas funciones auxiliares.

El método extractArgs extrae los campos del json que lee del canal y, si no es un mensaje (los mensajes simplemente se ignoran), hace la conversión de los argumentos (están codificados para que no se interpreten como html porque algunas instrucciones utilizan este lenguaje):

if msgJ['args'] and (msgJ['typ'] != 'Msg'):
    # Unquoting the args
    self.log.debug("Reply args before: %s " % msgJ['args'])
    tmpJ = urllib.parse.unquote(msgJ['args'])
    msgJ['args'] = tmpJ

El método manageCommand determina si el mensaje es para el bot y, en su caso, trata de realizar lo que corresponda:

listCommands = self._bot.all_commands
if msgJ['cmd'].startswith(self._bot.bot_config.BOT_PREFIX):
    cmd = msgJ['cmd'][len(self._bot.bot_config.BOT_PREFIX):]

    self.log.debug("Cmd: %s"% cmd)
    if cmd in listCommands:

Esto es, obtiene una lista de instrucciones, comprueba que la instrucción comienza con el caracter adecuado, y luego verifica si es una instrucción conocida para el bot. Posteriormente, la ejecuta. Para ello, identifica el método asociado:

    method = listCommands[cmd]

Y la ejecuta:

    replies = method("", msgJ['args'])

Con un tratamiento ligeramente diferente si se trata de un generador (puede haber varias respuestas) o no.

En ambos casos guarda como texto la respuesta para devolverla convenientemente.

   self.publishSlack(typ = 'Rep', usr= msgJ['userName'],
       host=msgJ['userHost'], frm = msgJ['frm'], args = txtR)

En algunos casos las instrucciones utilizan plantillas (templating) y, por ello, el intérprete necesita tener en cuenta esto:

    txtR = txtR + tenv().get_template(method._err_command_template+'.md').render(reply)

Después de interpretar la instrucción, ejecutarla y escribir la respuesta, el bot borra el mensaje del canal (la referencia a mensajes concretos se realiza basada en un identificador basado en el momento de publicación del mensaje):

    self.deleteSlack(chan, msg['ts'])

Finalmente, el mensaje podría ser una respuesta. Para ello se utiliza el méotodo manageReply. Este método tiene que identificar si la respuesta es para el bot:

if ((msgJ['userName'] == self['userName'])
        and (msgJ['userHost'] == self['userHost'])):
    # It's for me
    self.log.info("Yes. It's for me")
    replies = msgJ['args']

Y enviarla al usuario que lanzó la instrucción:

    self.send(msgTo, replies)

Para después borrarla:

    self.deleteSlack(chan, msg['ts'])

Todavía no hemos hablado del método para redirigir mensajes, que se llama forwardCmd y que funciona como sigue: Si la instrucción tiene parámetros, los separa con

if args.find(' ') >= 0:
     cmd, argsS = args.split()

Y luego publica el mensaje en el canal:

self.publishSlack(mess=mess,
        usr=self['userName'], host= self['userHost'],
        typ = 'Cmd' , cmd = cmd, args = argsS)

Tiene un par de alias, fw y forward.

Para utilizar este plugin podemos cargarlo en cada bot (podríamos hacerlo directamente desde GitHub):

!repos install https://github.com/fernand0/err-forward

Definiremos un canal en Slack y configuramos los bots con:

!plugin config ErrForward {'channel': *el nombre*}

Algunas consideraciones finales:

  • Hemos utilizado Slack pero podría utilizarse cualquier canal, con las adaptaciones oportunas. Probablemente haya mecanismos mejores.
  • Sería interesante disponer de diferentes canales de comunicación, mejorando el plugin para que se pudiera elegir uno, por ejemplo, en la configuración. No se si sería ‘abusar’ montar otra infraestructura de plugins para esto. En todo caso, me encantaría ver si alguien sigue estas ideas y hace otros ‘redirectores’.
  • La redirección se hace escribiendo la instrucción para el bot completa, utilizando el caracter especial de inicio de instrucción (‘!’, ‘,’ en nuestro caso). Esto podría evitarse, y que el bot simplemente intentase interpretar cualquier instrucción.
  • Si hay varios bots que son capaces de ejecutar la misma instrucción podemos terminar ejecutándola más de una vez, no se ha previsto un bloqueo para evitarlo. Esto podría causar problemas al intentar borrar el mensaje por segunda vez.
  • Se ha conseguido el objetivo de tener varios bots (dos) que son capaces de ejecutar distintas instrucciones y comunicarse entre ellos.
  • Hemos aprendido algunas de las interioridades de Errbot que permiten interpretar las instrucciones y ejecutarlas, aplicar plantillas, etc.

Llevo probando este mecanismo durante unas semanas con un par de bots (como decía arriba, uno está escuchando en Telegram y el otro en un canal de IRC) y funciona de manera bastante robusta para las instrucciones que yo suelo utilizar: se pueden ver en mi GitHub (GitHub de fernand0), todos mis módulos empiezan con err-.