ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.
Si has estado alguna vez en un aeropuerto, hospital, universidad... o realmente en casi cualquier edificio de oficinas, casi seguro que has visto un dispositivo de control de acceso con tarjeta de la marca HID.
Este tipo de dispositivos controlan el acceso a las áreas restringidas, y forman parte de la política de seguridad y auditoría de accesos de muchas empresas y organismos, siendo HID probablemente la empresa fabricante más grande del mundo.
Cada uno de estos dispositivos de lectura de tarjetas seguras está conectada a un controlador de apertura de puerta, que maneja todas las funciones de apertura y cierre, horarios, alarmas, etc... Como casi todo en nuestra época, en los últimos años los han conectado a una red para poder configurarlos y gestionarlos en remoto así como meterles actualizaciones. Y como todo lo que está conectado a una red, tarde o temprano viene un cracker y lo revienta ;-)
Lo malo de reventar un dispositivo que está asociado a un elemento físico es que las consecuencias suelen ser mayores que cuando se asalta un software en un servidor. O al menos, más tangibles.
En las películas los "hackers" de pacotilla que siempre aparecen rompen la seguridad de estos dispositivos con una facilidad pasmosa, dando acceso al agente secreto de turno a cualquier instalación con cuatro comandos en su sistema operativo. La realidad suele ser más complicada.
Sin embargo el investigador de seguridad Ricky Lawshae del laboratorio DVLabs de HP, ha descubierto una vulnerabilidad que afecta a los controladores VertX y Edge (los más importantes de la empresa, presentes en miles de instalaciones en todo el mundo) que permite abrir remotamente cualquier puerta controlada por estos dispositivos.
Un sistema de gestión remota de estos controladores puede enviar una sonda mediante un paquete UDP al puerto 4070 de estos, y todos los controladores que estén en la red responderán automáticamente con información detallada sobre su dirección MAC, tipo de dispositivo, nombre "legible" (por ejemplo, "Puerta Farmacia"), e incluso la versión exacta del firmware del aparato. Hasta aquí todo más o menos normal. El problema viene porque el sistema también puede enviar una pequeña orden a los aparatos para que cambien el patrón de parpadeo de sus indicadores LED (seguramente para identificarlos visualmente). Y esta función ¡no comprueba los parámetros que se le pasan!.
Resultado: inyección de comandos al canto. El sistema operativo subyacente (basado en Linux) ejecuta los comandos que se le pasan en la inyección de datos, y el sistema está bajo nuestro control ya que, encima, se ejecuta con permisos de "root" (o sea, súper-administrador).
Es decir, que el programador que hizo el software del controlador cometió los dos errores más graves que cualquier programador puede cometer en seguridad:
- No verificar los datos que reciben las funciones
- No ejecutar el código con los mínimos privilegios necesarios
Del ABC de la escritura de código seguro, la A y la B :-P
Desde entonces la empresa ha actualizado el software de todos los dispositivos, que ya vuelven a ser seguros.
Pero este episodio debería servir para, una vez más, ser conscientes de la importancia que tiene la escritura de código seguro, y que la seguridad de una aplicación no depende solo de la "gente de sistemas", sino que primordialmente es nuestra responsabilidad como programadores.
La seguridad de una aplicación no depende solo de la "gente de sistemas", sino que primordialmente es nuestra responsabilidad como programadores.
Fecha de publicación: