Icônes SCW
héros bg sans séparateur
Blog

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

Pieter Danhieux
Publié le 30 novembre 2021
Dernière mise à jour le 6 mars 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.

Veuillez consulter la ressource
Veuillez consulter la ressource

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.

Souhaitez-vous en savoir davantage ?

Directeur général, président et cofondateur

En savoir plus

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.
Partager sur :
marques LinkedInSocialLogo x
auteur
Pieter Danhieux
Publié le 30 novembre 2021

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :
marques LinkedInSocialLogo x

¿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.

Veuillez consulter la ressource
Veuillez consulter la ressource

Veuillez remplir le formulaire suivant pour télécharger le rapport.

Nous souhaiterions obtenir votre autorisation pour vous envoyer des informations sur nos produits ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Envoyer
icône de réussite scw
icône d'erreur scw
Pour envoyer le formulaire, veuillez activer les cookies « d'analyse ». N'hésitez pas à les désactiver à nouveau une fois que vous avez terminé.

¿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.

Veuillez consulter le webinaire
Commencer
En savoir plus

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez consulter le rapportVeuillez réserver une démonstration.
Télécharger le PDF
Veuillez consulter la ressource
Partager sur :
marques LinkedInSocialLogo x
Souhaitez-vous en savoir davantage ?

Partager sur :
marques LinkedInSocialLogo x
auteur
Pieter Danhieux
Publié le 30 novembre 2021

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :
marques LinkedInSocialLogo x

¿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.

Table des matières

Télécharger le PDF
Veuillez consulter la ressource
Souhaitez-vous en savoir davantage ?

Directeur général, président et cofondateur

En savoir plus

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.Télécharger
Partager sur :
marques LinkedInSocialLogo x
Centre de ressources

Ressources pour débuter

Plus de publications
Centre de ressources

Ressources pour débuter

Plus de publications