Indagar sobre los Requisitos de Seguridad del Código de Ejecución Remota para Dispositivos IoT

El Internet de las Cosas (IoT) es un concepto en evolución y es descrito de varias maneras, uno de los más comunes siendo “una infraestructura de objetos, gente, sistemas y recursos de información interconectados”¹. Es obvio para los practicantes, sin embargo, que IoT no es un concepto nuevo. Es un nuevo paradigma que es creado y realizado a través del uso de conceptos viejos, métodos, y herramientas que han estado presente por muchos años en el mundo de TI y computación. Algunos de estos conceptos incluyen la función remota de llamado y ejecución de código remoto.

Desde un punto de vista de seguridad, sin embargo, IoT exhibe nuevas funciones y características, como ser la necesidad de compartir tipos adicionales de datos y operaciones. En contraste con sistemas más viejos, dispositivos IoT reciben varios tipos de input desde otros dispositivos en la forma de datos y comandos remotos^{2, 3}. Dispositivos IoT (por ejemplo: Candados inteligentes o impresoras) son requeridos para ejecutar un grupo de comandos que le son enviados por entidades remotas, cómo son los teléfonos, en la misma red o ir a buscar bibliotecas públicas que se colocan en servidores dispersos (por ejemplo: Librerías Javascript). Es común que dispositivos IoT reciban un grupo de instrucciones de máquina o comandos para actualizaciones del software que controla el dispositivo físico (por ejemplo: Firmware) o instrucciones que le digan al equipo exactamente que se necesita hacer. En términos técnicos, los dispositivos pueden utilizar métodos bien conocidos de la llamada de procedimiento remoto, método de invocación remota, carga dinámica de clases, y descarga de librerías compartidas y objetos.

Este artículo se enfoca en los requisitos de seguridad alrededor de la ejecución de código remoto, lo que significa recibir y ejecutar código/comandos desde otro sistema en la misma red. En el caso de IoT, esto se refiere a un dispositivo (la fuente de instrucciones) capaz de controlar “una cosa” conectada desde cualquier parte del mundo. Utilizada maliciosamente la ejecución de código remoto es una amenaza seria. Es buscada por los hackers: el poder controlar una máquina para hacer cualquier cosa. Piense, por ejemplo, de una persona maliciosa que pueda controlar en forma remota carros conectados, dispositivos médicos o sistemas de control de plantas de energía.

El artículo investiga requisitos de seguridad de técnicas tradicionales de ejecución de código remoto en vista de los resultados del modelado de amenazas y expone en las secciones de las regulaciones de cumplimiento de seguridad que establecen los requisitos.

Tipos y Escenarios de Ejecución de Código Remoto

Ejecución de Código Remoto es un término utilizado para diversos tipos de código compartido en el que una entidad solicita y recibe algo de código y ejecuta el código en su propio entorno. Estos son los escenarios comunes en el cual la ejecución de código remoto ocurre:

1. El uso de librerías de utilidades comunes colocados en un servidor remoto (por ejemplo: Librerías JavaScript). Las funciones son extraídas desde el servidor, pero ejecutadas en el cliente (por ejemplo: El navegador)⁴.
2. Carga Dinámica de (compiladas) clases. Un ejemplo es la carga de clase dinámica de Java, lo cual incluye la carga de la forma binaria de una clase (desde un archivo o ubicación de la red) que ha sido previamente compilado del código fuente⁵.
3. Socialización del Objeto⁶. También conocido como clasificación, serialización de objeto incluye convertir el objeto (estructura, funciones y atributos) en un nuevo formato (por ejemplo: Un flujo de bytes) que fácilmente puede ser transmitido y almacenado. Serializacion y des-serializacion (algunas veces llamado no serializacion) es implementado en muchos lenguajes como Java⁷ y C#⁸. JavaScript Object Notation (JSON) es construido en el mismo concepto; sin embargo, la meta de JSON es primeramente transferir datos en vez de ejecutar código remoto. Nótese que, en este escenario, hay una instancia de la clase (un objeto con un grupo de propiedades) siendo transmitida. Es diferente de la carga dinámica de clase en el cual la clase (la binaria) es cargada (usualmente solo la estructura, código y constantes, y no instancia particular).
4. Llamadas a procedimientos remoto (RPC) o método de invocación remoto (RMI). Hay un sin número de protocolos RPC de métodos más viejos basados en Common Object Request Broker Architecture (CORBA)⁹ y Open Software Foundation (OSF) RPC a modelos más nuevos de interfaces de programación de aplicaciones Java (API) para Extensible Markup Language (XML)-basado RPC (JAX-RPC) y JAX-WS (Java API para XML-para servicios Web)¹⁰. Llamando a los servicios Web como Protocolos de Acceso de Objetos Simple (SOAP) y Transferencia de Estado Representacional (REST) servicios Web¹¹ podrían también ser considerados un caso especial de RPC. Sin embargo, vea que si el código se ejecuta en el host (por ejemplo: Servidor) y solo el resultado es pasado al dispositivo solicitante, el proceso no calificaría como RPC.
5. Comandos Operacionales de dispositivos específicos. Esto incluye comandos enviados a un dispositivo o un sistema embebido para llevar a cabo una secuencia de tareas. Un ejemplo son comandos en la forma de Idiomas de Trabajo de Impresoras HP (PJL)¹². Es previsible que este tipo de protocolos propietarios y estándar surgirán y extenderse para numerosos dispositivos y aplicaciones mientras IoT madure.
6. Comandos de control específicos del dispositivo (incluyendo actualización de comandos firmware). Comandos de actualización del firmware y del sistema básico de entrada/salida son muy comunes para los dispositivos IoT, y el código puede ser recibido en el mismo canal del comando especifico del dispositivo (mencionado en el escenario 5). También existen otros estándares y comandos de control propietarios que pueden enviarse a dispositivos de acuerdo a los protocolos IoT^{13, 14}.
7. Código ejecutable embebido en archivos. Ejemplos incluyen código en la forma de Postscript, ActiveX y Macros embebidos en archivos como es Microsoft Word, Microsoft Excel, PDF y Adobe Flash. El código es transmitido como parte del archivo y es ejecutado en el destino. Este concepto es explicado bajo el título “código móvil” en el Instituto Nacional Americano de Estándares (ANSI)/Sociedad Internacional de Automatización (ISA) 62443¹⁵ y NIST 800-53¹⁶ regulaciones de cumplimiento.

Modelado de Amenazas de Ejecución de Código Remoto

La figura 1 muestra un simple diagrama de flujo de datos recomendado por el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP) método de modelo de amenazas de aplicaciones¹⁷. El diagrama muestra los elementos comunes de los escenarios descritos. La fuente del código remoto es de una ubicación compartida (por ejemplo: lugares con permisos de escritura en los dispositivos Android cuando se utiliza la carga dinámica de clases). Un proceso o dispositivo (por ejemplo: Un dispositivo IoT embebido) eventualmente será el anfitrión y ejecutará el código remoto. Para determinar el lugar del código remoto y recuperar los datos, se utiliza un servicio de resolución de ubicación. Por ejemplo, en caso de archivos en ubicaciones compartidas, el sistema operativo puede manejar las solicitudes y enviarlos al recurso correcto. Para el acceso a la internet, los servidores de nombres de dominio traducen la dirección de los recursos a una dirección de protocolo de Internet (IP).

Una idea importante desplegada en figura 1 es que hay dos direcciones de flujo concebibles. En algunos casos, el anfitrión/dispositivo inicia la solicitud para el código remoto. En otros, el dispositivo recibe los comandos, aunque no necesariamente haya iniciado la solicitud. Por ejemplo, una impresora puede tener un canal para recibir comandos remotos para ejecutar varios trabajos.

El uso de suplantación de identidad, la manipulación de los datos, el repudio, la divulgación de información, denegación de servicio (DoS), y la elevación de la técnica de modelado de amenazas privilegio (STRIDE), las amenazas a la seguridad de la ejecución remota de código se pueden clasificar y resumir como sigue¹⁸:

• Suplantación de Identidad—Suplantación Sistema de Nombre de Dominios (DNS) puede causar solicitudes para un recurso y ser enviada a otro¹⁹. Otros tipos de ataques de hombre–en-el-medio también pueden facilitar una mala representación de código suplantado como si fuese código original. Estas amenazas son relevantes a todos los siete tipos y escenarios de ejecución de código remoto descrito en la sección previa.
• Manipulación de datos—Cualquier forma de manipulación de datos en tránsito o en reposo (por ejemplo: Manipulación de datos a través de ataques de hombre-en-el-medio) pueden caer bajo esta categoría. Una forma específica de esta vulnerabilidad ocurre cuando el código es cargado desde una ubicación compartida o accesible al mundo (por ejemplo: Universal serial bus [USB] almacenamiento conectado a una PC u ubicación con permisos de escritura en una tarjeta SD Android). Datos suplantados, si son manejados por librerías de ejecución de código remoto típicas (tales como las bibliotecas de deserialización esbozadas en el escenario 3 descritas antes) sin medidas de protección adicionales, pueden conducir a la ejecución de código malicioso similar a los reportados para librerías comunes Apache.²⁰
• Divulgación de Información—Cualquier dato confidencial que son transmitidos como parte de un objeto (por ejemplo: Propiedades de un objeto serializado C# que constituye un registro de la salud de una persona) son vulnerables a divulgación no autorizada (especialmente para escenarios 3 y 4). Algunos de los pasos de serialización/deserialización o RPC se delegan a las bibliotecas que no utilice los canales encriptados. Desarrolladores puede que desconozcan los mecanismos subyacentes utilizados por esas librerías (por ejemplo: Si una librería en particular utiliza un canal encriptado para procedimientos de llamado remoto).
• Negación de Servicio—La disponibilidad de un sistema que ejecuta código remoto puede ser amenazado por código malicioso. Una forma de ataque simple puede involucrar la creación de una carga enorme y enviándolas al sistema como código. Esto puede ocurrir en todos los siete escenarios. Aunque el sistema efectué verificación de integridad, un volumen grande de datos puede afectar la operativa normal del sistema y eventualmente ocasionar una negación de servicio. Amenazas adicionales a la disponibilidad son dependientes excesivamente en un recurso remoto y carente de procedimientos a prueba de fallas cuando ese recurso no está disponible. Otra gran vulnerabilidad emerge del uso de librerías de terceros que no cuentan con protección contra DoS.
• Elevación de Privilegios—Hay un sin número de situaciones en la cual la ejecución remota de código inseguro puede conducir a la elevación de los privilegios. Por ejemplo, aplicaciones Android pueden cargar dinámicamente clases Java (escenario 2). La aplicación que cargue las clases le pasa todos los permios a la clase que los está ejecutando. La clase cargada recibe los permisos y privilegios de la aplicación ya que el código está ejecutando en un nuevo ambiente. Otro ejemplo es si un dispositivo no discrimina entre varios canales del cual recibe comandos (por ejemplo: No separa la actualización de su canal firmware del canal dedicado a su trabajo normal), hay un riesgo de usar permisos de un canal para efectuar actividades no autorizadas (escenarios 5 y 6)²¹. Librerías de terceros también pueden ser una vulnerabilidad.
• Repudio—Cualquier otra vulnerabilidad puede crear una oportunidad para repudio.

La figura 2 muestra amenazas bajo varias categorías y también muestra sus relaciones con la triada de seguridad de confidencialidad, integridad y disponibilidad. Basado en todas las amenazas identificadas y vulnerabilidades, este articulo provee ocho reglas de ejecución de código remoto que mitigan estas áreas de riesgo de seguridad.

Un Enfoque Prescriptivo para Asegurar la Ejecución Remota de Código

Esta sección delinea un grupo de requisitos de seguridad que mitigan el riesgo y amenaza relacionado con dispositivos IoT de baja complejidad.

1. Encriptar campos, ofuscar clases y utilizar canales encriptados. Este requisito se deriva del objetivo de la confidencialidad y la posibilidad de divulgación de información. Hay varias maneras para mantener la confidencialidad de los datos transmitidos como parte de objetos o procedimientos por:
   • Encriptando campos individuales (por ejemplo: Propiedades de los objetos). Gestión de llaves seguras y distribución, especialmente para dispositivos autónomos, es una importante acción en este caso.
   • Oscurecer y ofuscar código y objetos. Los binarios de clases compiladas son fáciles de realizar ingeniería inversa. Utilizando decompiladores, hackers pueden obtener el código original y cualesquier constantes en el código. Ofuscar no es una panacea, pero le agrega un nivel de defensa, por ejemplo: No debiese tratarse como una medida única de seguridad. Más información sobre esto puede encontrarse en documentos relacionados con el proyecto OWASP en ingeniería inversa de código²².
   • Comunicarse a través de una canal encriptado (por ejemplo: Secure Sockets Layer [SSL]/Transport layer Security [TLS] channels). Es importante mantener un ojo en los estudios sobre vulnerabilidades SSL/TLS y aplicar el resultado de esos estudios. Hay varias guías en el tipo de canales encriptados a utilizar y que evitar²³. Por ejemplo. SSL v2.0 y 3.0 no son seguros, y librerías SSL necesita constantes actualizaciones debido a varias vulnerabilidades que son regularmente descubiertas (por ejemplo: Heartblled, Explotar contra Navegador SSL/TLS [BEAST], Factoring RSA export Keys [FREAK] y Compression Ratio Info-leak Made Easy [CRIME] vector de ataque). Un dispositivo IoT sin capacidad de actualización se tornará inseguro en un tiempo corto. Implementar SSL/TLS en dispositivo de baja complejidad es un reto que puede causar dependencia en soluciones a o b mencionadas anteriormente en vez de encriptar todo el flujo de datos, que es requerido por SSL/TLS.
2. Revise el tamaño de la carga. Antes de cualquier cosa—aun antes de verificar la firma del código—verifique el tamaño de la carga y evite lidiar con grandes trozos de datos que son enviado como parte de un ataque DoS.
3. Firme el código o utilice métodos de autentificación específicos del protocolo.Firmar el código y evitar ejecutar cualquier código no firmado es la medida más importante de seguridad. Al utilizar canales no encriptados (por ejemplo: TLS), valide el certificado y cadena de confianza. Código firmado no es obviamente código seguro, pero una firma, como mínimo, manifiesta la integridad del código²⁴.
4. No ejecute cualquier parte del código antes de verificar su tamaño y firma. Ningún método constructor o de sobrescritos deben ser ejecutados por el código, o cualquier librería de terceros antes de que se llevan a cabo todos los controles de seguridad. Por ejemplo, una librería contiene un conjunto de clases que maneja objetos serializados. El conjunto de clase no debiese recibir los inputs externos antes de verificar tamaño/firma. Tampoco debiese ejecutar cualquier parte de las clases (por ejemplo: Constructores o reemplazo de métodos de lectura Objetos) antes que el objeto es validado.
5. Sandbox el proceso de ejecución remota de código y la memoria. No permita que el código se ejecute en una memoria compartida o espacio de almacenaje al cual otros procesos tienen acceso y viceversa (especialmente los comandos de actualización). Sandboxing (acceso directo al almacenaje y memoria de otras aplicaciones) no protege contra cualquiera de las vulnerabilidades mencionadas hasta ahora. Sin embargo, ya que la falta de sandboxing puede anular otras medidas de seguridad (como ser la verificación de firmas), sanboxing contribuye para reforzar otros mecanismos de defensa. En el caso de una actualización del BIOS, por ejemplo, investigadores han demostrado que un desbordamiento de buffer puede permitir la ejecución una porción no firmada del paquete de actualización²⁵.
6. Separe los canales de transferencia de código.Asegúrese que los datos en canales ordinarios de transferencia de datos (por ejemplo: Comandos operacionales de una impresora) no puedan ser utilizados para la ejecución de código remoto malicioso. Restricciones de comandos de actualización (por ejemplo: Requisitos de firmas) debiesen ser diferentes del de los comandos comunes.
7. Verificar que las librerías de Terceros cumplan con los requisitos previos. No alimentar datos de los usuarios a las librerías a menos que todas las verificaciones se han llevado a cabo. Por ejemplo, si la librería es utilizada antes de verificar el tamaño, una organización puede hacerse vulnerable a ataques DoS.
8. Evitar el exceso de dependencia de los recursos remotos y tener un plan a prueba de fallas. Desarrolle un plan alterno para las situaciones en que los recursos remotos no estén disponibles. Si continuar con el proceso se hace casi imposible debido a la no disponibilidad de esos recursos, diseñe un plan a prueba de fallas.

La figura 3 despliega una mejor práctica para la serialización de objetos, en el cual el objeto transmitido es sellado (encriptado), luego firmado y transferido. En el lado del receptor, el objeto primeramente es verificado por su tamaño, luego su firma es verificada y finalmente des-encriptado.

Relación con las Principales Normas de Cumplimiento de Seguridad

ANSI/ISA 62443, bajo los requisitos de seguridad (SR) 2.4 (código móvil), instruye a sistemas de control a reforzar restricciones de uso en tecnologías de código móvil que incluyen: prevención de ejecución de código móvil, requiriendo autentificación/autorización propia para el origen del código, restringir la transferencia de código móvil y monitoreo del uso de código móvil²⁶.

NIST 800-53r4 en la sección de protección del sistema y comunicaciones (SC-18, código móvil), recomienda la ejecución de código remoto en un ambiente confinado.²⁷ En la sección de integridad del sistema e información, SI-7 (15), el estándar estipula la firma y verificación del código.

Las vulnerabilidades descritas en este artículo están entre las principales 25 vulnerabilidades listadas en el Common Weakness Enumeration (CWE)/SANS: descargar código sin una verificación de integridad (CWE-494) e inclusión de funcionabilidad de una esfera de control no confiable (CWE-829)²⁸.

La guía final de la Autoridad de la Banca Europea relacionada a la seguridad en pagos a través de la internet, afirma que software entregado a través de la internet necesita ser digitalmente firmado por el proveedor del servicio de pago²⁹. En la Declaración de Divulgación para la seguridad de los dispositivos Médicos (MDS2), los fabricantes requieren declarar si el dispositivo protege la integridad de transmisión (TXIG) y si hay mecanismos para asegurar que el código instalado o actualización está autorizado por el fabricante (15-2)³⁰.

Conclusión

Enviar código remoto en varias formas a “cosas” y preguntándole por instrucciones por esas cosas, especialmente para actualizaciones de dispositivos y firmware, es común y se tornara una práctica más común en el eco sistema de IoT. Debido a que dispositivos IoT tienen interacción con el mundo físico y en muchos casos, esas interacciones son remotamente controlables (ya sea en un termostato o en el sistema de prevención de colisión de un vehículo conectado), las consecuencias de evitar los controles de seguridad son inmensos. La ejecución no segura de código remoto puede evitar los controles de seguridad y pueden causar daños físicos a consumidores de productos IoT. Por lo tanto, todas las medidas de seguridad y secciones relevantes del cumplimiento de regulaciones deben considerarse antes de tratar de diseñar la seguridad para soluciones IoT.

Notas Finales

¹ ISO/IEC, SWG 5 agreed on this definition of IoT in 2014: “An infrastructure of interconnected objects, people, systems and information resources together with intelligent services to allow them to process information of the physical and the virtual world and react.” ISO/IEC JTC 1, “Internet of Things (IoT) Preliminary Report,” 2014
² Athreya, A. P.; B. DeBruhl; P. Tague; “Designing for Self-configuration and Self-adaptation in the Internet of Things,” 9^th IEEE International Conference on Collaborative Computing: Networking, Applications and Worksharing, CollaborateCom, 2013
³ Klauck, R.; M. Kirsche; “Chatty Things—Making the Internet of Things Readily Usable for the Masses With XMPP,” 8^th IEEE International Conference on Collaborative Computing: Networking, Applications and Worksharing, CollaborateCom, 2012
⁴ Flanagan, D.; JavaScript: The Definitive Guide: Activate Your Web Pages, O’Reilly Media Inc., USA, 2011
⁵ Gosling, J.; et al.; “The Java Language Specification–Java SE 8 Edition,” Oracle America, 2014
⁶ Deitel, P.; H. M. Deitel; Java for Programmers, Second Edition, Prentice Hall Professional, USA, 2011
⁷ Ibid.
⁸ Hericko, M.; et al.; “Object Serialization Analysis and Comparison in Java and .NET,” ACM Sigplan Notices, vol. 38, iss. 8, August 2003, p. 44-54
⁹ Ben-Natan, R.; Corba: A Guide to Common Object Request Broker Architecture, McGraw-Hill Inc., USA, 1995
¹⁰ Fisher, M.; et al.; Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices, Prentice Hall Professional, USA, 2006
¹¹ Richardson, L.; S. Ruby; RESTful Web Services, O’Reilly Media Inc., USA, 2007
¹² Hewlett-Packard, Printer Job Language Technical Reference Manual, 2003, www.hp.com
¹³ Op cit, Athreya
¹⁴ Op cit, Klauck
¹⁵ ANSI/ISA, Security for Industrial Automation and Control Systems Part 3-3: System Security Requirements and Security Levels, USA, 2013
¹⁶ National Institute of Standards and Technology, Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication 800-53r4, USA, 2013
¹⁷ Open Web Application Security Project (OWASP), “Application Threat Modeling,” https://www.owasp.org/index.php/Application_Threat_Modeling
¹⁸ Shostack, A.; Threat Modeling: Designing for Security, John Wiley & Sons, USA, 2014
¹⁹ Shinder, D. L.; M. Cross; Scene of the Cybercrime, Syngress, USA, 2008
²⁰ The Apache Software Foundation Blog, “Apache Commons Statement to Widespread Java Object De-serialisation Vulnerability,” 10 November 2015, https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
²¹ Cui, A.; M. Costello; S. Stolfo; “When Firmware Modifications Attack: A Case Study of Embedded Exploitation,” Presented at the NDSS symposium, 2013
²² See OWASP’s Reverse Engineering and Code Modification Prevention Project, https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project.
²³ Ristic, I.; “SSL/TLS Deployment Best Practices,” 2013
²⁴ Op cit, Cui
²⁵ Wojtczuk, R.; A. Tereshkin; “Attacking Intel BIOS,” BlackHat, Las Vegas, Nevada, USA, 30 July 2009
²⁶ Op cit, ANSI/ISA
²⁷ Op cit, NIST
²⁸ Common Weakness Enumeration, “2011 CWE/SANS Top 25 Most Dangerous Software Errors,” 2011, http://cwe.mitre.org/top25/
²⁹ European Banking Authority, Final guidelines on the security of internet payments, 19 December 2014, https://www.eba.europa.eu/documents/10180/934179/EBA-GL-2014-12+(Guidelines+on+the+security+of+internet+payments)_Rev1
³⁰ HIMSS/NEMA, Manufacturer Disclosure Statement for Medical Device Security, 2013, www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medical-Device-Security.aspx