Implementing a Signing Forms mechanism in an open XMPP Server to reduce successful network attacks

Abstract

Servers implementing the eXtensible Messaging and Presence Protocol (XMPP) enable the near-real-time exchange of structured yet extensible data between any two or more network entities. In this paper we propose to address network attacks, a security issue, by implementing signing forms over an inband registration mechanism. We validate our proposal implementing this mechanism over OpenFire, which is a free, communitysupported and open source XMPP server. Our experiments showed that the number of successful attacks was reduced to 0 when our proposal is implemented.

-

XMPP es un protocolo abierto para la comunicacion en tiempo real. Existen multiples ejemplos de aplicaciones que utilizan este protocolo, incluyendo mensajer a instantanea, presencia y colaboracion [ 5 ][ 10 ]. Las especi caciones centrales fueron desarrolladas por la Internet Engineering Task Force (IETF) pero es extensible por la XMPP Standards Foundation, quienes estandarizan protocolos publicando XEPs [ 7 ], los cuales extienden la funcionalidad de XMPP.

Ahora bien, las redes de Internet de las cosas (IoT) pueden ser implementadas utilizando diversos protocolos de comunicaciones. Aunque a nivel de usuario, una caracter stica relevante es la facilidad que provee el servidor para adicionar nuevas \cosas" (tipo Plug and Play), tales como sensores, controladores, actuadores o concentradores, tal como se aprecia en la Tabla 1, diversas caracter sticas tecnicas de los protocolos utilizados para IoT deben ser considerados al momento de realizar una eleccion para implementar una red IoT.

HTTP [ 3 ] 3

CoAP [ 11 ] 3

MQTT [ 1 ] 7

XMPP [ 5 ][ 10 ] 3 7

Lamentablemente, a nivel de seguridad, aun existen desaf os importantes. CoAP, por ejemplo, es un protocolo de transferencia RESTful para nodos y redes con restricciones, el cual tiene una pobre capa de seguridad con un Bypass de Firewall limitado [ 11 ]. MQTT tiene serias vulnerabilidades conocidas, tanto as que incluso gobiernos han prohibido su uso [ 6 ]. Tal como se aprecia en la Tabla 1, XMPP es mas robusto en terminos de seguridad. Permite delegar automaticamente y de manera segura permisos a los clientes - cosas - para registrar una identidad en la red XMPP-IoT dado que utiliza OAuth 1.0 [ 4 ] con dos XEPs espec cas. La XEP-0077 (https: //xmpp.org/extensions/xep-0077.html) [ 9 ] que describe el mecanismo para registrarse en banda en un servidor XMPP. La XEP-00348 (https: //xmpp.org/extensions/xep-0348.html)[ 12 ] que lo hace tanto para clientes como para el servidor. Ahora bien, dado que esto le da proteccion a la red IoT contra bots maliciosos mediante resolucion de CAPTCHAS (https://xmpp.org/extensions/ xep-0158.html) [ 9 ][ 8 ], (opcion que puede ser habilitada o no), lamentablemente, las \cosas" no pueden registrarse de forma automatizada en la red IoT. Lamentablemente, si el registro en banda es activado pero sin habilitar la validacion por CAPTCHAS, se abre una brecha en la seguridad de la red XMPP-IoT. Debido a esto, es habitual que se deje la red XMPPIoT con el XEP-0077 activado pero con el XEP-0158 deshabilitado, es decir, que cualquiera que pueda visualizar a nivel de red el servidor puede registrar identidades en el servidor. Esto abre una brecha en la seguridad de la misma red XMPP-IoT. 2

Propuesta

Existe una serie de servidores que implementan XMPP. Existen de uso libre o de pago, de codigo abierto y desarrollado en diversos lenguajes de programacion, documentacion, con una comunidad existente en torno al servidor, que corren sobre diferentes sistemas operativos y con diversas XEPs implementadas. IoT Broker (https://waher.se/Broker.md), servidor XMPP de uso no libre, no es open-source y no hay una comunidad incipiente en torno al proyecto. AstraChat Isode M-Link, su uso es de pago. ejabberd, Tigase y Open re son de uso libre. Los primeros dos poseen una comunidad tambien incipiente en torno al desarrollo de nuevas caracter sticas. Open re, por otro lado es de uso libre, open-source, esta codi cado en Java, funciona bajo los Sistemas Operativos Linux, macOS, Solaris y Windows y tiene una gran comunidad activa. La misma organizacion ofrece SMACK, el cliente.

En este trabajo proponemos desarrollar e implementar el mecanismo descrito en la especi cacion XEP-0348: Signing Forms sobre la XEP-0077: In-band Registration, tanto en el servidor como en el cliente, para que, de este modo, se pueda asignar el permiso de crear identidades en la red XMPP-IoT solo a ciertos clientes. Con esto proponemos reducir a cero la creacion de identidades por usuarios o bot maliciosos. En particular para la validacion realizada mediante experimentos implementaremos nuestra propuesta en el cliente SMACK y en el servidor Open re tal como se aprecia en las Figuras 1 y 2. 3

Validacion

Tal como se ve en la Figura 1 el experimento consta un servidor XMPP Open re modi cado con varios clientes XMPP SMACK modi cados, los cuales son: un Cliente XMPP Thing-Sensor (TS{1) que posee un sensor de humedad y temperatura un Cliente XMPP Thing-Sensor (TS{2) que posee un sensor de gas, un Cliente XMPP Thing-Controlador (TC{1) Ya realizada las modi caciones, el procedimiento es el siguiente: 1. Ingresar a la consola de administracion web de

Open re. 2. Ingresar a la seccion de registro.

Para los clientes ingresamos el ConsumerKey y el ConsumerSecret, para que de este modo, se realice la conexion con el servidor y exista el intercambio de Stanzas con dataforms [ 2 ] siendo exitosa la veri cacion de Signatures, y de este modo, se le delegue al cliente la facultad de crear identidades en el servidor XMPP Open re. As , pudimos realizar consultas de temperatura y humedad al cliente TS{1 y de gas al TS{2. Realizado esto, se creo y ejecuto el Bot malicioso en ambos servidores (el modi cado con nuestra propuesta y el sin modi car). Los resultados se pueden apreciar en las siguientes Tablas: 4

Conclusiones y Trabajos Futuros Este trabajo brinda un aporte a la comunidad de Internet de las Cosas dado que extiende un servidor libre, de codigo abierto y apoyado por una comunidad que lo extiende en el tiempo. Tal como se vio en el experimento, dada nuestra implementacion es posible reducir el numero de ataques de red en el servidor XMPP OpenFire que podr a sufrir dada la implementacion del Inband registration de la XEP-0077 sin la implementacion de signing forms.

Si bien, la brecha de seguridad presente en el XEP0077 es abordada con la implementacion del XEP0348, quedan varios desaf os, uno de ellos es implementar un Plugin en Open re para aprovisionamiento. Ademas, un Registro de Cosas que registre que permisos tiene una \cosa{cosa" y \humano-cosa".

References

[1] Banks , A. & Gupta , R. ( 2014 ). Mqtt version 3.1. 1. OASIS standard , 29 .

[2] Eatmon , R. , Hildebrand , J. , Miller , J. , Muldowney , T. , & Saint-Andre , P. ( 2006 ). Jep- 0004 : Data forms . online] Jan , 5 .

[3] Fielding , R. , Gettys , J. , Mogul , J. , Frystyk , H. , Masinter , L. , Leach , P. , & Berners-Lee , T. ( 1999 ). Hypertext transfer protocol{http/1.1 . Technical report.

[4] Hammer-Lahav , E. ( 2010 ). The oauth 1.0 protocol ( 2010 ). URL https://tools.ietf.org/pdf/rfc5849.pdf.

[5] Internet Engineering Task Force (IETF) , P. S.- A. ( 2011 ). Rfc6120 extensible messaging and presence protocol (xmpp): Core.

[6] Lundgren , L. ( 2016 ). LightWeight Protocol! Serious Equipment! Critical Implications! [Online; accessed 19-July-2018].

[7] P. Saint-Andre D. Cridland ( 2015 ). XEP-0001 : XMPP Extension Protocols. [Online; accessed 20- July-2018].

[8] Paterson , I. & Saint-Andre , P. ( 2008 ). Captcha forms .

[9] Saint-Andre , P. ( 2004 ). Xep-0077: in-band registration . Jabber Software Foundation.

[10] Saint-Andre , P. ( 2011 ). Extensible messaging and presence protocol (xmpp): Core.

[11] Shelby , Z. , Hartke , K. , & Bormann , C. ( 2014 ). The constrained application protocol (coap).

[12] Waher , P. ( 2017 ). Xep- 0348 : Signing forms.