El Internet of Things (IoT) abarca todos y cada uno de los productos que están conectados a Internet o entre ellos. Cualquier producto que requiera conexión a una red doméstica, desde un automóvil o desde una oficina para entregar un conjunto completo de características, cae bajo este amplio término. De hecho, los automóviles en sí son ahora componentes IoT, ya que intercambian datos con el fabricante de  forma continua.

Todo lo relacionado con la I/O, recopila datos durante el uso y, a menudo, comparte esa información con sus fabricantes sin que los usuarios sepan que se está recopilando. En muchos casos, las funciones del producto dependen de la conexión a Internet. Este concepto de hacer que todos los componentes de nuestras vidas se comuniquen entre sí, con nosotros, y con las aplicaciones de software internas y externas, es de lo que define IoT.

IoT como sinónimo de poca seguridad

Los fabricantes de todo tipo de Dispositivos electrónicos o eléctricos se apresuran a agregar funciones que requieren conexión a Internet. En su prisa por comercializar y obtener beneficios, estas compañías, muchas de las cuales no tienen experiencia previa con dispositivos conectados a la red, pasan por alto las complicaciones del diseño y la construcción de seguridad de hardware y software debido a las "prisas" por obtener la función más nueva y más "fresca" al menor coste.

Es casi una regla que los fabricantes de productos que prueban estas nuevas fronteras apliquen las mismas pautas a su selección de hardware, que cuando lo hacen a la hora de obtener ellos mismo cualquier otro producto. Los chips más antiguos, cuyos diseños se pagaron hace mucho tiempo y ahora son muy baratos, son bloques de construcción atractivos para diseños de dispositivos que solo necesitan capacidades limitadas.

Actualmente la prueba del software que se está escribiendo para un electrodoméstico o juguetes para niños, tiene un solo objetivo: confirmar que funciona y que será fácil de configurar (con muchas selecciones predeterminadas, incluso contraseñas). Siendo la seguridad una idea posterior en el mejor de los casos.

El hardware utilizado en la mayoría de los productos nuevos es muy antiguo y, a menudo, tiene múltiples vulnerabilidades conocidas. El software que se incluye con los dispositivos de IoT y que rara vez recibe pruebas de seguridad en profundidad casi siempre tiene su propio conjunto de problemas de seguridad. El resultado es que decenas de miles y pronto cientos de millones de dispositivos, dispositivos y juguetes instalados en las redes domésticas y comerciales estarán listos para ser vulnerados. Y una vez que se descubra una vulnerabilidad en una línea de productos ampliamente distribuida habrá miles o posiblemente cientos de miles de hogares y negocios que estarán abiertos a tener sus dispositivos IoT "secuestrados".

Aplicaciones de IoT

En el mundo doméstico, los dispositivos IoT está en todas partes:

• IoT en casa: En las casas domóticas, los objetos conectados a Internet, como televisores, termostatos, luces, cerraduras e incluso frigoríficos, se están volviendo comunes. Ofrecen a los propietarios el control de los servicios y funciones del hogar sin estar realmente en casa. Los frigoríficos inteligentes pueden controlar la cantidad de leche que queda y hacer un pedido automáticamente desde nuestra tienda preferida. O por ejemplo, las secadoras nos notifican en nuestros teléfono cuando terminan.
• IoT en personas: Los dispositivos portátiles orientados a la salud y la actividad física que ofrecen mediciones biométricas, como la frecuencia cardíaca, los niveles de transpiración e incluso mediciones complejas, como los niveles de oxígeno en el torrente sanguíneo, son algunos de los ejemplos de dispositivos portátiles con IoT conectados. En medicina, los dispositivos implantados quirúrgicamente informan al médico sobre el estado de salud y, en algunos casos, aceptan instrucciones del personal médico para reaccionar autónomamente. Todos estos datos se recopilan en una base de datos central propiedad del fabricante y proporcionan una secuencia de datos potencialmente pirateable.
• IoT en vehículos: Los sistemas de transporte y ahora los automóviles utilizan una gran cantidad de sensores, que a menudo funcionan en combinación con el GPS para obtener el mejor punto A y B de manera segura y eficiente. Más allá de eso, los vehículos son aún más inteligentes. Sistemas de navegación a bordo, sistemas de diagnóstico que nos alertan (y al fabricante) sobre todo, desde luces defectuosas hasta presión de los neumáticos.

Las empresas también ven la importancia de integrar dispositivos conectados IoT para ofrecer nuevas funciones, reducir costos y mejorar la eficiencia.

• Etiquetas RFID antirrobo que ayudan  a monitorizar el inventario.
• Carretillas sin conductor funcionando 24x7, aumentando los niveles de producción, la mayoria de los días ;)
• Los sistemas de infraestructura crítica, como los sistemas de generación y entrega de energía, los sistemas de agua y los sistemas de transporte, están incorporando más dispositivos IoT para mejorar la precisión de los datos y el control.
• Las granjas usan sensores conectados para controlar los cultivos y rebaños a fin de optimizar la distribución de pesticidas, fertilizantes y alimentos.
• Los dispositivos conectados a la IoT alertan a los gerentes de planta sobre equipos defectuosos o que funcionan mal.
• Las cadenas de suministro enteras que abarcan varias compañías e incluso continentes están integrando sus sistemas de producción para permitir una mejor administración de máquinas y personas a través de la monitorización y el control de sus acciones o ubicaciones.

Los dispositivos IoT generan y comparten gran cantidad de datos y, por lo tanto, son susceptibles a ataques maliciosos, lo que justifica las pruebas dinámicas, revisiones de código y la evaluación de vulnerabilidades en la fase de desarrollo del producto.

Vulnerabilidades en IoT

Según Gartner, se espera que la cantidad de dispositivos conectados a Internet alcance los 50 mil millones en 2020. Si bien la IoT mejorará la vida de muchas personas, la cantidad de riesgos de seguridad a los que los consumidores y las empresas se enfrentarán aumentará exponencialmente.

Las partes interesadas en el dominio IoT enfrentan problemas de privacidad, la mayoría de las veces desconocen la situación. Como tal, los dispositivos de IoT han estado en el foco en los últimos meses debido a los controles de seguridad deficientes y a las numerosas vulnerabilidades encontradas.

Algunos de los problemas comunes que han surgido debido a la propagación de IoT son:

• Los usuarios de IoT dan su aprobación para la recopilación y el almacenamiento de datos sin tener la información adecuada o el conocimiento técnico. Los datos recopilados y compartidos con o perdidos por terceros eventualmente producirán una imagen detallada de nuestra vida personal que los usuarios nunca considerarían compartir con ningún extraño que conocieran en la calle.
• El anonimato ha sido un problema constante en el mundo de IoT, donde las plataformas apenas le dan importancia al anonimato de los usuarios en el proceso de compartir datos.
• Es probable que los ciberataques se conviertan en una amenaza cada vez más física (en lugar de simplemente virtual). Muchos dispositivos conectados a Internet, como cámaras, televisores y aparatos de cocina ya están habilitados para espiar a las personas en sus propios hogares. Dichos dispositivos acumulan una gran cantidad de datos personales, que se comparten con otros dispositivos o son retenidos en las bases de datos por las organizaciones, los mismos,  propensos a ser mal utilizados.
• Los dispositivos automotrices controlados por ordenador, como bocinas, frenos, motor, tablero de instrumentos y cerraduras corren el riesgo de que hackers puedan acceder a la red  y manipularlos, por diversión, o por motivos económicos.
• El concepto de seguridad en capas y redundancia para gestionar los riesgos relacionados con la IO todavía está en una etapa incipiente. Por ejemplo, las lecturas de los dispositivos inteligentes de salud para monitorizar la condición de un paciente pueden verse alteradas, lo que de nuevo cuando se conecta a otro dispositivo para prescribir medicamentos después del análisis, se verá comprometido y afectará adversamente el diagnóstico o tratamiento del paciente.
• Existe una alta probabilidad de no obtener acceso a un sitio web o base de datos en particular cuando varios dispositivos basados ​​en IoT intentan conectarse a él, lo que resulta en insatisfacción del cliente y caídas en los ingresos.

Pruebas estáticas y dinámicas en dispositivos IoT

A medida que los dispositivos IoT se convierten en una parte integral de nuestra vida cotidiana, es crucial que estos se sometan a pruebas exhaustivas y establezcan una base mínima de seguridad.

Si se realiza alguna prueba, la prueba estática es el proceso más frecuentemente implementado. Pero las pruebas estáticas no están pensadas o diseñadas para encontrar las vulnerabilidades que existen en los componentes "Plug and Play", como los procesadores y la memoria en los que se instalará la aplicación.

Las pruebas dinámicas, por otro lado, son capaces de exponer tanto las debilidades del código como cualquier defecto o vulnerabilidad subyacente introducidos por el hardware y que pueden no ser visibles en el análisis estático. Además, las pruebas dinámicas a menudo resultan ser una forma más pragmática de probar los dispositivos IoT y juegan un papel fundamental en la búsqueda de vulnerabilidades que se crean cuando se usa código nuevo en procesadores antiguos. Como tal, los fabricantes que compran hardware y software de otros deben realizar pruebas dinámicas para garantizar que los dispositivos sean seguros.

Pruebas de control de calidad para hardware y aplicaciones

Los desarrolladores producen aplicaciones que, en mayor o menor grado, intercambian información al adherirse a un protocolo lo más cerca posible. El departamento de calidad prueba la funcionalidad de la aplicación contra ese protocolo en un mundo perfecto del laboratorio de pruebas. Dadas las numerosas formas en que los programadores pueden cometer errores, buscar vulnerabilidades de seguridad en un software debe ser una parte integral del proceso de desarrollo. Extrañamente, ese no es siempre el caso, ya que probar la seguridad de un producto en particular puede ser una propuesta costosa y los desarrolladores a menudo sopesan el gasto contra el coste de otros factores involucrados en la liberación del producto a los clientes. Debido a esto, incluso el software desarrollado en un entorno estrictamente consciente de los riesgos de seguridad, probablemente se publique sin haber realizado las pruebas de una forma completa.

Naturalmente, cuando se lanza la aplicación, los hackers nos martirizaran con todas las formas corruptas posibles del protocolo usado para crear un error en la aplicación. Al fricionar el protocolo, es posible que encuentren la manera de desconectar la aplicación y crear un buffer overflow, el error de diseño con mayor probabilidad de ocurrencia.

¿Cómo es que los hackers encuentran oportunidades de buffer overflow que se perdieron durante el desarrollo y las pruebas de calidad en el prelanzamiento? La comunidad de hackers ha desarrollado una amplia gama de herramientas para permitir que la base encuentre nuevos exploits. Estas herramientas, fuzzers, funcionan al crear y alimentar una amplia gama de entradas inesperadas o corruptas buscando una combinación que rompa la aplicación. La producción de estas herramientas se ha convertido en una pequeña industria propia. El mundo de QA ha intentado adaptar estas herramientas de hackers rudas y listas en sus procesos de prueba con cierto éxito, pero también con muchos dolores de cabeza. La mayoría de estos fuzzers desarrollados por hackers se centran en un único tipo de debilidad del código o simplemente en un solo protocolo o incluso en una sola aplicación.

En el caso de dispositivos IoT conectados, es importante que las empresas identifiquen patrones de tráfico y diferencien entre los legítimos y los maliciosos. Por ejemplo, un empleado puede descargar una aplicación aparentemente original en un smartphone que le da a su empleador, sin saber que la aplicación tiene algún tipo de malware. En tales casos, la organización debe estar preparada con un conjunto adecuado de procesos para garantizar una amplia seguridad de la forma más temprana posible.

La mayoría de los dispositivos IoT vienen con credenciales predeterminadas cuando se usan por primera vez, lo que significa identidades de administrador y contraseñas conocidas. También algunos dispositivos vienen con un servidor web incorporado. Esto ayuda a los administradores a iniciar sesión y administrar el dispositivo de forma remota. Esta vulnerabilidad masiva puede atraer fácilmente a los hackers a hacer un uso indebido de los datos confidenciales disponibles. Para evitar cualquier fuga de datos, las empresas deben desarrollar un estricto proceso de asignación, donde la configuración inicial del dispositivo pueda probarse y verificar cualquier tipo de vulnerabilidad que pueda existir. Las fallas validadas que pudieron haber sido identificadas deberían corregirse, y se debería emitir una certificación de cumplimiento antes de que el dispositivo salga al mercado.

Incluso después de realizar todas las pruebas de control de calidad, se deben realizar pruebas de buffer overflow, pruebas de incumplimiento de protocolos y pruebas de caja negra para reducir aún más el alcance de agregar vulnerabilidades a los dispositivos.

Buffer overflow: vulnerabilidades generadas en el proceso de desarrollo

La traducción de los requisitos durante el desarrollo de la aplicación es la primera causa de la mayoría de los errores de programación. Por ejemplo, durante el desarrollo de una aplicación para un frigorífico inteligente, un jefe de proyecto o analista traduce los requisitos del extremo deseado al equipo de programación, los programadores traducen a asignaciones de programación individuales. Los programadores luego traducen la tarea en una sintaxis adecuada para el lenguaje de programación escrito por otra persona, que a su vez un intérprete de lenguaje de programación traduce al código de máquina correspondiente. Todas estas traducciones son fuentes de posibles errores de programación durante la etapa de diseño.

Los errores uno a uno, los errores de uso del lenguaje de programación, o los desbordamientos de enteros son ejemplos de errores generados por los programadores al traducir un concepto a su algoritmo apropiado. Por ejemplo, para contener 'n' elementos que tienen cada uno 'm' bytes de longitud, el programador puede decirle al programa que asigne n * m bytes. Si m * n es mayor que el número más grande que se puede representar, se asignará menos memoria de la prevista a la operación. Esto puede conducir a un desbordamiento del buffer. En otra instancia, si un programador asume que una variable contiene solo enteros positivos, pero si el entero en cuestión es realmente un entero con signo, las operaciones aritméticas pueden causar una sobrescritura del bit de la izquierda y hacer que el resultado sea un número negativo, lo que posiblemente lleve a un comportamiento "explotable".

Sin embargo, no todos los errores de programación se crean por igual. Algunos permiten que los atacantes ganen algo u obtengan habilidades que aún no tenían. Pueden negar el acceso a otros usuarios al programa bloqueándolos o acceder a información que no deberían poder acceder. En algunos casos, pueden hacer que el programa ejecute cualquier comando que indiquen. Estos errores son vulnerabilidades. Otros errores, si bien pueden tener las mismas causas, no otorgarán a los atacantes ningún acceso que no tengan. Por ello, la primera tarea para un investigador de vulnerabilidad es determinar si el error de programación es simplemente un error o si puede llevar a la explotación del activo. Si un error puede conducir a la explotación, ya sea por sí mismo o cuando se usa con otro conjunto, de forma que sea una vulnerabilidad.

Los desbordamientos y vulnerabilidades del buffer causados ​​por la aplicación que no verifica la disponibilidad de espacio antes de copiar datos que no son de confianza en el espacio preasignado en la memoria del sistema, terminan sobrescribiendo el contenido de la memoria fuera del buffer. Como resultado, la próxima vez que el programa examine ese espacio de memoria, verá los datos del desbordamiento en lugar de los datos originales. Si el programa intenta usar valores de esa área, lo más probable es que no vea lo que espera, cuyas consecuencias pueden variar desde un bloqueo del programa hasta otras acciones potencialmente más peligrosas como DoS o, peor aún, la ejecución de código malicioso. Un desbordamiento de buffer basado en pila puede permitir a los atacantes ejecutar código en el pc de la víctima, ya que sobrescribe las direcciones de memoria que se usarán más adelante, mientras que un "desbordamiento de pila" generalmente da como resultado un DoS, ya que intenta escribir en la memoria que no está disponible.

Los fuzzers "inteligentes" multi-protocolo y variables de entorno como beSTORM son vitales para encontrar debilidades de desbordamiento de buffer no solo porque automatizan y documentan el proceso de entrega de entradas dañadas, sino también porque vigilan de cerca la respuesta inesperada de la aplicación. Por ejemplo, beSTORM probará paquetes con encabezados mal formados, manipulando el contenido del paquete y proporcionando el tipo de datos que la aplicación puede estar buscando, usando &, , puntos y comas completos dentro de aplicaciones de correo electrónico, o símbolos URL típicos para servidores HTTP, siendo inviable si se hace de forma manual.

Vulnerabilidades en las comunicaciones API

Las API de protocolo de dispositivo permiten que las aplicaciones hablen con un dispositivo a través de los protocolos estándar de la industria. Los desarrolladores necesitan simplemente identificar el dispositivo y luego abrir un canal de comunicación hacia él. Al abrir un canal, se solicita autorización de acceso. Este es un paso crítico para ayudar a evitar que los programas se comuniquen accidental o maliciosamente con uno o más dispositivos sin que el usuario se dé cuenta. Una vez que se concede el acceso, el programa puede comunicarse con un dispositivo, lo que incluye iniciar largas transferencias de datos.

Ser capaz de atacar la implementación real del protocolo generando vectores de ataque que se enfocan en errores básicos de codificación tales como mal manejo de validación de entrada o verificación fronteriza (errores de programación defensiva), defectos de diseño (lógica, especificación de diseño y similares) y la implementación de la protocolo en sí, es cómo los hacker logran mejores resultados. El problema principal con eso es la cantidad de posibles combinaciones de ataque que aumentan en un factor significativo, lo que hace que el tiempo hasta el resultado (bloqueo o similar) sea poco práctico en algunos casos. Este problema se resuelve mediante el uso de algoritmos avanzados en un intento de agilizar los ataques que son más propensos a causar un error primero, y luego proceden a cubrir todo el espacio de combinación.

Aún así, estos algoritmos no son fáciles de desarrollar. En algunas ocasiones, tratar de explotar un gran buffer o enviar datos del tipo de datos incorrecto facilita las capturas, pero cuanto más el fuzzer avanza en su búsqueda, más importante es la eficiencia de los algoritmos utilizados por los fuzzers individuales.

El uso de manipulaciones más avanzadas basadas en los dos tipos básicos (manipulación del valor y manipulación del protocolo) también afecta considerablemente la capacidad de los fuzzers de hoy en día para proporcionar resultados. Por ejemplo, intentar explotar una falla lógica en el programa enviando dos veces una solicitud de inicio de sesión y luego combinarla en el crisol de ataques aumenta la cantidad de combinaciones requeridas y la tasa de éxito. Ser capaz de trabajar con protocolos más avanzados, que requieren que el fuzzer espere una respuesta antes de enviar la siguiente solicitud (básicamente establecer sesiones con el fuzzing basado en la sesión de la aplicación atacada) es otro paso en el fuzzing.

Algunas técnicas de manipulación más avanzadas basadas en los conjuntos básicos aumentan aún más los resultados finales y el éxito del fuzzing. Una de esas técnicas avanzadas es la manipulación lógica. Basado en la manipulación del protocolo, el fuzzer intenta encontrar errores de programación lógica que resultan en una vulnerabilidad potencial. Otra técnica avanzada es la manipulación de sesiones (también basada en la manipulación de protocolos), que manipula la sesión real. Por ejemplo, enviar una solicitud para que se emita una clave, y luego cuando se recibe usando otra o continuar sin ella puede causar otros tipos de posibles errores.

El principal desafío al que se enfrentan los fuzzers de segunda generación cuando emplean estas nuevas técnicas es el tiempo requerido para cubrir el espacio combinado de manera exhaustiva. Algunas vulnerabilidades "exóticas" en un producto pueden ubicarse al final del espacio de combinación. El desarrollo de la tecnología para tratar de encontrar los vectores de ataque más probables para desencadenar posibles vulnerabilidades en el menor tiempo posible es la solución.

Prueba de caja negra: fuzzing basado en protocolo para VA y pruebas de aplicación

Esta es una técnica que funciona alimentando automáticamente un programa con múltiples iteraciones de entrada que están especialmente construidas de tal forma que desencadenan un error interno indicativo de un error y posiblemente lo bloqueen. Comúnmente conocida como técnica "fault injection", las pruebas de blackbox se pueden aplicar a un servicio de red tanto como a una CPU, un smartphone, parámetros de programa, una API, un navegador web o un tipo de archivo.

Los probadores que no conocen el funcionamiento interno de la aplicación que se está probando realizan su trabajo "olfateando" primero el tráfico en los protocolos de destino, generan iteraciones de entrada a partir de lo que observan y luego envían mensajes 'Random' o 'Garbled'  y eventos de teclado en la aplicación hasta que surjan vulnerabilidades. La monitorización de la aplicación puede variar de un Watchdog que ve si el programa todavía se está ejecutando a una verificación remota para ver si el servicio todavía está disponible y responde o técnicas más avanzadas como mirar con un depurador una excepción anticipada. Mediante la manipulación de valores, solo se prueba un conjunto de datos específico para cambios de valores específicos y, a través de la manipulación de protocolos, se puede probar la implementación de toda la estructura del protocolo o ambas dos.

La solución es detectar fallas de la aplicación durante el desarrollo utilizando el mejor fuzzer que podamos obtener, cuando la corrección es relativamente fácil y mucho menos costosa.

Mediante la aplicación de técnicas de fuzzing basadas en protocolos automatizados, cómo poderosas herramientas de auditoría automatizada, debemos probar virtualmente todas las combinaciones de ataques, iniciando inteligentemente los escenarios más probables y detectando anomalías en las aplicaciones, que indican un ataque exitoso. De esta forma, los agujeros de seguridad se pueden encontrar en la aplicación mucho más rápido, sin pruebas de fuerza bruta y casi sin intervención del usuario.