¿Cuándo fue la última vez que hizo un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que sólo sea una vuelta reciente a la agenda, pero realmente, nada es mejor que la carretera abierta y cambiar de aires. 

A menos que sea una vulnerabilidad de software, por supuesto.

Ya hemos hablado largo y tendido sobre los peligros que suponen las medidas de ciberseguridad poco estrictas en la industria del automóvil, con empresas como Tesla y Jeep que ya están trabajando con investigadores de seguridad, encontrando fallos explotables que podrían haber dado lugar a graves problemas de seguridad si no se descubrían a tiempo y se solucionaban. También hemos hablado de que, en general, la seguridad del software sigue estando en el salvaje oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.

Las vulnerabilidades de las APIs se están volviendo especialmente insidiosas, ya que el tráfico de APIs maliciosas ha crecido más de un 300% sólo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente APIs sobre ruedas. Están conectados, conversan mucho con otras aplicaciones y podrían ser objeto de ataques dirigidos como uno de los muchos puntos finales vulnerables. 

Cuando su cargador de vehículos eléctricos dice demasiado

Los vehículos conectados han sido objeto de escrutinio por su seguridad de software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de carga de vehículos eléctricos domésticos, así como en una red pública de carga de vehículos eléctricos muy extendida.

¿A quién le importa un cargador? ¿Qué podría ganar un atacante? Por desgracia, una de las desventajas de la tecnología potente y profunda que trabaja horas extras para nosotros es que, por lo general, estos dispositivos tienen un mal caso de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles que los acompañan a través de una API, en un entorno basado en la nube, y todo ello puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones, y si estos puntos finales no se configuran con cuidado, se podría compartir demasiado, o peor aún, acceder a través de una puerta trasera de una aplicación vulnerable.

Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de la API que permitían la toma de posesión de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de múltiples dispositivos de vehículos eléctricos. Todos estos problemas fueron corregidos, pero el hecho de que unas pocas líneas de código fueran todo lo que se interpuso entre los atacantes y la interrupción completa de la funcionalidad básica y la infraestructura de servicios es muy preocupante. 

Tampoco es que se trate de un asunto de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, que habrían permitido la toma de posesión de cuentas si se hubieran explotado. IDOR entra dentro de la autenticación rota, que ocupa el segundo lugar en el Top 10 de vulnerabilidades de API de OWASP. Es tan común como la suciedad, lo que apunta a un fallo en el aprendizaje y la implementación de código de calidad. No podemos persistir en conectar dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las APIs mal configuradas son precisamente eso. 

Trabajar de forma segura con las APIs de automoción requiere educación y paciencia

Lo frustrante de la seguridad de las APIs es que se promociona como una nueva ola de desastres de ciberseguridad que hay que intentar mitigar, cuando en realidad no es más que un nuevo escenario para los mismos viejos problemas que hemos visto durante décadas en el desarrollo web. Cross-site scripting, inyección, desconfiguración: ¿te suena?

Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, seguimos sin contar con los expertos necesarios para hacer siquiera mella en la cantidad de salvaguardas que hay que aplicar a la avalancha de código que se escribe cada día. Los desarrolladores tienen que elevar sus conocimientos y responsabilidades en materia de seguridad, y no les corresponde a ellos tomar la iniciativa. Si tienes un equipo que trabaja en sistemas integrados en electrodomésticos, o en APIs que podrían convertir un coche en el juguete de control remoto de alguien, entonces debes asegurarte de que están equipados con lo que necesitan para dejar de introducir vulnerabilidades comunes. 

Las diferencias entre una API segura y una vulnerable debido a XSS son mínimas, por ejemplo, pero es necesario mostrar a los desarrolladores los matices que diferencian un patrón de codificación pobre de uno bueno. Además, los procesos de desarrollo perezosos suelen ser habituales en las configuraciones de las API, ya que a muchas se les conceden amplios permisos por encima de los requisitos mínimos para que realicen las tareas establecidas, lo que abre una gran superficie de amenaza adicional y un posible robo de datos. Estos factores deben ser considerados durante la construcción, pero si no están arraigados en las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.

Evitar el nuevo campo de juego de los actores de amenazas

El dramático aumento de las APIs como objetivo de los actores de amenazas muestra que la atención se está moviendo a una fruta que se percibe como de bajo riesgo... y en este caso, es una que podría ser una tubería a la suciedad significativa, además de las amenazas potenciales a la vida en forma de toma de posesión del vehículo. 

Dejar la seguridad de las APIs al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos, y frustrante retrabajo y bajo rendimiento en el mejor. Debería ser una consideración crítica como parte del ecosistema de comunicación del software, y estar en lo alto de la lista de un programa de seguridad de primera clase. La clave para esto es tratar cada API como si fuera un humano, y evaluar qué acceso debe tener. ¿Debe Jim de Contabilidad tener acceso a todos los documentos legales sensibles de toda la empresa? Probablemente no, y generalmente el control de acceso se determina correctamente en el caso del personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son potentes parlanchines que permitirán que todo el mundo conozca sus secretos si no se configuran con los mismos métodos de confianza cero de todo lo demás.

La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de estos portales vulnerables a la desesperación. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas para tomar las decisiones correctas en las etapas críticas de la creación.