OWASP Guía de seguridad estilo Top 10 para implementación en dispositivos de hardware

1. Cuentas de prueba de puerta trasera.

Los ingenieros a menudo incluyen mecanismos de puerta trasera y cuentas de prueba en hardware para fines de depuración, con medidas de seguridad triviales o sin ningún tipo de protección para protegerlos. Desafortunadamente, una gran cantidad de dispositivos llegan al mercado sin tener estos mecanismos y cuentas desactivados, lo que permite a los atacantes obtener acceso ilegítimo al dispositivo.

2. Protocolos de gestión de red no seguros.

Muchos dispositivos implementan SNMP o UPnP para la administración remota, pero no implementan incluso niveles básicos de seguridad a su alrededor. El equipo de oficina, el hardware de red, los sistemas de control industrial, etc. a menudo filtran datos sensibles (como la tabla de enrutamiento) a través de SNMP, y pueden proporcionar varias funciones de control a través de UPnP. Muchos dispositivos habilitados para UPnP implementan las funciones estándar de administración de la interfaz de red, que permiten a un atacante deshabilitar una interfaz de red. Otras funciones pueden permitir que un atacante dañe permanentemente el dispositivo, o causar problemas graves con la funcionalidad.

3. Desbordamientos de búfer.

Las implementaciones de hardware son notoriamente malas por no verificar los tamaños del búfer de destino y pueden permitir la corrupción completa del estado de la memoria. Esto puede resultar en la ejecución del código, pero más comúnmente simplemente se traduce en una condición de denegación de servicio, donde el dispositivo debe reiniciarse por hardware antes de que se pueda usar nuevamente.

4. Desbordamientos / subflujos de enteros.

Se producen cuando una entrada de entero sin signo se trata como firmada, o un tipo de entero más grande se convierte directamente en un tipo de entero más pequeño. Ambos de estos problemas pueden dar lugar a casos en los que un valor está fuera del rango esperado, lo que puede hacer que las comprobaciones de rango de matriz y las comprobaciones de longitud del búfer pasen a pesar de que el búfer de entrada sea demasiado grande. Esto también puede dar lugar a condiciones de lectura en cualquier lugar, donde un índice de matriz negativo conduce a operaciones de memoria que acceden a regiones de memoria anteriores.

5. Insuficientes controles de cordura.

Por lo general, se considera que los valores de entrada en las implementaciones de hardware tienen una integridad sólida, por lo que a menudo no se realizan controles de integridad. Esto podría permitir a un usuario malintencionado proporcionar un valor inesperado y cambiar el comportamiento del dispositivo. Un ejemplo común de esto es cuando se utiliza un conjunto de indicadores de bits y se establecen bits en conflicto.

6. Secretos compartidos y codificados en el disco duro incrustados en la memoria no volátil.

Los diseñadores de hardware a veces están bajo la ilusión de que debido a que algo se almacena en un chip EEPROM en una placa, los datos que contiene no pueden ser leídos por alguien que desea interferir con el dispositivo. Es común encontrar claves criptográficas codificadas y otras credenciales almacenadas en el firmware de un dispositivo. Estos pueden usarse para comprometer el dispositivo o sus comunicaciones, y suelen ser los mismos en todos los dispositivos del mismo modelo.

7. Crypto de mala calidad, autodiseñado o faltante.

A menudo, es complicado implementar algoritmos criptográficos adecuados en sistemas integrados, especialmente cuando se trabaja con microcontroladores y microprocesadores de velocidad más amplia. Las implementaciones de referencia a menudo asumen arquitecturas de tipo x86 o de tipo ARM, lo que aumenta el factor de trabajo. Los ingenieros también suelen carecer del conocimiento y la experiencia para implementar correctamente la criptografía. Como tal, los algoritmos criptográficos que se encuentran en los sistemas integrados tienden a estar mal implementados, o son diseños caseros con fallas de seguridad graves. Muchos sistemas carecen completamente de cualquier forma de hashing en las contraseñas y otras credenciales. Este tipo de datos generalmente se puede extraer de la memoria no volátil usando herramientas disponibles.

8. Falta de una sólida integridad y comprobación de autenticidad en las actualizaciones de firmware.

La integridad del firmware del dispositivo a menudo se verifica a través de un hash CRC32 o MD5, pero rara vez se autentica a través de un medio fuerte. Muchos fabricantes confían en la oscuridad como medida de seguridad. Si bien el costo de la ingeniería inversa puede ser considerable, el firmware de un dispositivo lo está reduciendo con la llegada de las arquitecturas de microprocesadores comunes (por ejemplo, ARM) en sistemas integrados. Una vez que un atacante obtiene la capacidad de cargar una imagen de firmware, puede subvertir completamente el sistema.

9. Varias fallas de aplicaciones web en los paneles de control.

Muchas de las fallas de las principales aplicaciones web de OWASP son inquietantemente comunes en los paneles de control web para dispositivos integrados. CSRF, XSS y el robo de sesión se encuentran altamente en la lista de vulnerabilidades comunes, aunque SQLi es menos común debido a la cantidad relativamente baja de sistemas que implementan una base de datos relacional completa.

10. Servicios de red enlazados incorrectamente.

Muchos servicios de red en dispositivos integrados están configurados para vincularse a 0.0.0.0, en lugar de hacerlo directamente a una dirección IP de LAN. Esto puede permitir que un atacante se comunique con el dispositivo desde fuera de la LAN. La segregación adecuada y la configuración del firewall pueden ayudar a mitigar esto, pero sigue siendo una preocupación.

La seguridad de la información es una disciplina del sistema porque requiere el conocimiento experto de un sistema de información completo (incluidas las personas) para tener éxito. El hardware y el software nunca pueden ser más que piezas en un sistema más grande. Realizar un análisis de seguridad en un sistema integrado requiere comprender cómo lo utilizarán las personas en el sistema. Un buen análisis del sistema siempre será mejor que una lista de verificación.

1. Fácil acceso físico a partes o componentes críticos de seguridad.

Algunas partes de un dispositivo integrado serán críticas para que funcione de manera segura y otras partes no lo serán. Los dispositivos bien diseñados dificultarán el acceso a esos componentes mediante una variedad de técnicas. Las técnicas simples incluyen la exclusión de tornillos y el uso de placas sólidas para cubrir el exterior del dispositivo. Las pruebas requieren un experto en desmontaje.

2. Confiar demasiado en un componente único del diseño.

Desde los conectores personalizados que 'nadie más puede obtener' hasta frecuencias únicas que 'nadie más usa', estas características de diseño generalmente afectan a los usuarios autorizados más que a los usuarios no autorizados. Efectivamente haciendo que el dispositivo sea más caro de usar. No hay manera de probar directamente la concentración de confianza, pero el análisis de los modos de falla y los estados del sistema puede ayudar a identificar puntos únicos de falla.

3. No proteger los manuales de planos, esquemas y mantenimiento.

Estos documentos e información ayudan al atacante a encontrar los puntos débiles físicos, así como a identificar los componentes críticos de seguridad del dispositivo. La mitigación implica la contabilidad de documentos y equipos y la auditoría periódica

4. Clave todos los dispositivos del mismo diseño con la misma clave.

De esta manera, cuando un dispositivo se ve comprometido, todos se comprometen. Dependiendo de la cantidad total de dispositivos y amenazas, las claves del entorno podrían cambiarse por dispositivo o por lote. La cantidad de dispositivos en un lote será un compromiso entre la eficiencia del uso de las teclas y el daño causado cuando se comprometa la llave de un lote.

5. No está diseñando un sistema de cambio de clave.

Casi cualquier dispositivo seguro requerirá una o más claves criptográficas. Con el tiempo, como los dispositivos están expuestos a un entorno de amenaza, una o más claves se verán comprometidas. Cuando eso sucede, es bueno poder volver a teclear un dispositivo en lugar de rasparlo por partes. Es especialmente importante probar los modos de falla de la funcionalidad de cambio de clave.

6. No construir en la detección de manipulación

Sin la detección de manipulación, no se puede construir ningún mecanismo activo contra la manipulación. Los mecanismos incluyen la eliminación de datos confidenciales, la destrucción de claves o la "bricking" del dispositivo.

7. Apantallamiento de RF inadecuado.

Esto puede exponer señales fuera de banda al entorno, que puede usarse para inferir información importante sobre el funcionamiento seguro del dispositivo. Un ejemplo simple es determinar el éxito o el fracaso de una solicitud segura. Muchos sistemas tardarán más tiempo cuando una solicitud es parcialmente exitosa y luego ninguna parte de la solicitud es exitosa. Esto se describe a menudo como un ataque de canal lateral.

Puede consultar los Perfiles de protección de criterios comunes , por supuesto, una lista no exhaustiva, pero de hecho una lista. de requerimientos para diferentes sistemas. Algunos podrían cubrir lo que estás desarrollando.

Cada perfil de protección (PP) sigue un formato que introduce el objetivo de la evaluación (TOE) y los objetivos para asegurar el TOE. Por lo tanto, un PP es una fórmula de requisitos formales para la evaluación de criterios comunes.

Un ejemplo de PP es el PP del gobierno de los EE. UU. para sistemas operativos de redes de propósito general . Un requisito específico, aquí para la auditoría, se presenta a continuación:

  

El TSF [las funciones de seguridad de confianza del SO] proporcionará a los administradores autorizados la capacidad de leer toda la información de auditoría de los registros de auditoría

Además, las amenazas al sistema se presentan y formalizan:

  

[Amenaza T.CRYPTO_COMPROMISE:] Un usuario o proceso malintencionado puede provocar que se acceda (vea, modifique o elimine) clave, datos o código ejecutable asociado con la funcionalidad criptográfica, lo que compromete los mecanismos criptográficos y la información protegida. por esos mecanismos.

En conclusión, las amenazas son consideradas:

  

Cada una de las amenazas a la seguridad identificadas se aborda mediante uno o más objetivos de seguridad. [Se proporciona una] asignación de los objetivos de seguridad a las amenazas, así como una justificación que discute cómo se aborda la amenaza. Las definiciones se proporcionan (en cursiva) debajo de cada objetivo de amenaza y seguridad para que el lector de PP pueda consultarlas sin tener que volver a las secciones 3 y 4 [ que son secciones que analizan el entorno y los objetivos de seguridad].