SCW Icons
hero bg no divider
Blog

API on Wheels: un viaje por carretera lleno de vulnerabilidades riesgosas

Pieter Danhieux
Published Nov 30, 2021
Last updated on Mar 06, 2026

¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.

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

Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así 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 el tráfico malicioso de API crece 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, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.

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

Los vehículos conectados han sido objeto de escrutinio por la seguridad de su 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 recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.

¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto 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 una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la 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 API que permitían la apropiació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 varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.

Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del 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 las API de automoción 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 para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?

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, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.

Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a 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 espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.

Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello 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 de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los 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 la desesperación de estos portales vulnerables. 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 necesarias para tomar las decisiones correctas en las etapas críticas de la creación.

Ver recurso
Ver recurso

Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento.

¿Interesado en más?

Chief Executive Officer, Chairman, and Co-Founder

learn more

Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.

Reserva una demostración
Comparte en:
linkedin brandsSocialx logo
autor
Pieter Danhieux
Published Nov 30, 2021

Chief Executive Officer, Chairman, and Co-Founder

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Comparte en:
linkedin brandsSocialx logo

¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.

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

Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así 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 el tráfico malicioso de API crece 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, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.

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

Los vehículos conectados han sido objeto de escrutinio por la seguridad de su 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 recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.

¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto 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 una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la 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 API que permitían la apropiació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 varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.

Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del 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 las API de automoción 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 para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?

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, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.

Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a 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 espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.

Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello 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 de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los 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 la desesperación de estos portales vulnerables. 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 necesarias para tomar las decisiones correctas en las etapas críticas de la creación.

Ver recurso
Ver recurso

Rellene el siguiente formulario para descargar el informe

Nos gustaría recibir su permiso para enviarle información sobre nuestros productos o temas relacionados con la codificación segura. Siempre trataremos tus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
scw success icon
scw error icon
Para enviar el formulario, habilite las cookies de «análisis». No dudes en volver a desactivarlas una vez que hayas terminado.

¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.

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

Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así 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 el tráfico malicioso de API crece 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, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.

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

Los vehículos conectados han sido objeto de escrutinio por la seguridad de su 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 recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.

¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto 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 una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la 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 API que permitían la apropiació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 varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.

Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del 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 las API de automoción 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 para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?

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, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.

Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a 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 espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.

Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello 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 de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los 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 la desesperación de estos portales vulnerables. 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 necesarias para tomar las decisiones correctas en las etapas críticas de la creación.

Ver seminario web
Comenzar
learn more

Haga clic en el enlace de abajo y descargue el PDF de este recurso.

Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.

Ver informeReserva una demostración
Ver recurso
Comparte en:
linkedin brandsSocialx logo
¿Interesado en más?

Comparte en:
linkedin brandsSocialx logo
autor
Pieter Danhieux
Published Nov 30, 2021

Chief Executive Officer, Chairman, and Co-Founder

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Comparte en:
linkedin brandsSocialx logo

¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.

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

Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así 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 el tráfico malicioso de API crece 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, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.

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

Los vehículos conectados han sido objeto de escrutinio por la seguridad de su 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 recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.

¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto 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 una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la 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 API que permitían la apropiació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 varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.

Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del 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 las API de automoción 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 para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?

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, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.

Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a 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 espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.

Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello 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 de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los 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 la desesperación de estos portales vulnerables. 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 necesarias para tomar las decisiones correctas en las etapas críticas de la creación.

Tabla de contenido

Descargar PDF
Ver recurso
¿Interesado en más?

Chief Executive Officer, Chairman, and Co-Founder

learn more

Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.

Reserva una demostraciónDescargar
Comparte en:
linkedin brandsSocialx logo
Centro de recursos

Recursos para empezar

Más publicaciones
Centro de recursos

Recursos para empezar

Más publicaciones