API sobre ruedas: un viaje por carretera lleno de vulnerabilidades peligrosas

¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo de dónde te encuentres, puede que sea algo que apenas has retomado recientemente, pero, sinceramente, no hay nada mejor que la carretera abierta y un cambio de aires.

A menos que seas una vulnerabilidad de software, claro.

Hemos hablado largo y tendido sobre los peligros que suponen las medidas de ciberseguridad laxas en la industria automotriz, con empresas como Tesla y Jeep trabajando ya con investigadores de seguridad para encontrar errores explotables que podrían haber provocado graves problemas de seguridad si no se hubieran descubierto y corregido a tiempo. También hemos comentado cómo, en general, la seguridad del software sigue estando en el Lejano 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 API se están volviendo especialmente insidiosas, con un tráfico malicioso de API que ha crecido más de un 300% solo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son, esencialmente, API sobre ruedas. Están conectados, interactúan constantemente con otras aplicaciones y podrían verse atrapados en ataques dirigidos como uno de los muchos puntos finales vulnerables.

Cuando tu cargador de vehículo eléctrico habla demasiado

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

¿A quién le importa un cargador? ¿Qué podría ganar un atacante? Por desgracia, uno de los inconvenientes de tener tecnología potente y avanzada trabajando sin descanso para nosotros es que, por lo general, estos dispositivos sufren de un exceso de información. Los cargadores de vehículos eléctricos se comunican con aplicaciones móviles mediante API en un entorno basado en la nube, y todo eso puede ser vulnerable a ataques si no se programa y configura de forma segura. Las API, por 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 demasiada información o, peor aún, acceder a ella a través de una puerta trasera vulnerable en la aplicación.

Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber permitido secuestrar millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de API que permitían la toma de control de cuentas y el acceso remoto, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de múltiples dispositivos. Estos problemas se solucionaron, pero el hecho de que unas pocas líneas de código fueran lo único que separaba a los atacantes de una interrupción total de la funcionalidad principal y de la infraestructura de servicio es profundamente preocupante.

Y no es que sea cosa de genios. Wallbox, por ejemplo, tenía dos referencias directas a objetos inseguros (IDOR) en su API, lo que habría permitido la toma de control de cuentas si se hubieran explotado. IDOR se clasifica como autenticación rota, que ocupa el segundo lugar en el Top 10 de vulnerabilidades de API de OWASP. Es algo sumamente común, lo que apunta a un fallo en el aprendizaje y la implementación de código de calidad. No podemos seguir conectando dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las API mal configuradas son precisamente eso.

Trabajar de forma segura con API automotrices requiere educación y paciencia

Lo frustrante de la seguridad de las API es que se promociona como una nueva ola de desastres de ciberseguridad que hay que mitigar, cuando en realidad es solo un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. Cross-site scripting, inyección, errores de configuración: ¿te suena?

Los indicadores recientes de organizaciones como el NIST son prometedores y demuestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, todavía estamos lejos de contar con los expertos necesarios para siquiera hacer mella en la cantidad de salvaguardas que deben aplicarse al diluvio de código que se escribe cada día. Es necesario elevar el nivel de conocimientos y responsabilidades de seguridad de los desarrolladores, y no depende de ellos tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en electrodomésticos, o en API que podrían convertir un coche en un juguete teledirigido, debes asegurarte de que tengan lo necesario para dejar de introducir vulnerabilidades comunes.

Las diferencias entre una API segura y una vulnerable debido a XSS son mínimas, por ejemplo, pero hay que mostrar a los desarrolladores los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, los procesos de desarrollo descuidados suelen ser la norma en las configuraciones de API, donde muchas reciben permisos mucho más amplios de los mínimos necesarios para realizar sus tareas, lo que abre una superficie de amenaza mucho mayor y aumenta el riesgo de robo de datos. Estos factores deben tenerse en cuenta durante la creación, pero si no están arraigados en prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.

Evitar el nuevo patio de recreo de los ciberdelincuentes

El aumento drástico de las API como objetivo de los ciberdelincuentes demuestra que la atención se está desplazando hacia lo que perciben como un objetivo fácil... y, en este caso, podría ser una vía hacia un botín importante, además de representar amenazas potenciales para la vida en forma de posible secuestro de vehículos.

Dejar la seguridad de las API al azar es una forma segura de generar problemas a futuro, con consecuencias potencialmente devastadoras en el peor de los casos, y con frustrantes procesos de reajuste y bajo rendimiento en el mejor. Debe ser una consideración crítica dentro del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de cualquier programa de seguridad de primer nivel. La clave es tratar cada API como si fuera una persona y evaluar qué acceso debería tener. ¿Debería Jim de Contabilidad tener acceso a todos los documentos legales confidenciales de toda la empresa? Probablemente no, y, por lo general, el control de acceso se determina correctamente en el caso del personal real. No se puede decir lo mismo de las API, y es importante recordar que son herramientas de comunicación potentes que revelarán todos tus secretos si no se configuran con los mismos métodos de confianza cero que 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 código de calidad que esté libre de estos portales vulnerables hacia el desastre. 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.