SCW-Symbole
Held-Hintergrund ohne Trennlinie
Blog

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

Pieter Danhieux
Veröffentlicht Nov 30, 2021
Zuletzt aktualisiert am 06. März 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.

Siehe Ressource
Siehe 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.

Interessiert an mehr?

Vorstandsvorsitzender, Chairman und Mitbegründer

mehr erfahren

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Eine Vorführung buchen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Autor
Pieter Danhieux
Veröffentlicht Nov 30, 2021

Vorstandsvorsitzender, Chairman und Mitbegründer

Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Teilen auf:
LinkedIn-MarkenSozialx 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.

Siehe Ressource
Siehe Ressource

Füllen Sie das folgende Formular aus, um den Bericht herunterzuladen.

Wir möchten Ihre Erlaubnis einholen, Ihnen Informationen über unsere Produkte oder Themen im Zusammenhang mit sicherer Verschlüsselung zuzusenden. Wir werden Ihre personenbezogenen Daten stets mit größter Sorgfalt behandeln und niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte die „Analyse“-Cookies. Sie können diese nach Abschluss des Vorgangs wieder deaktivieren.

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

Webinar ansehen
Beginnen
mehr erfahren

Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Bericht anzeigenEine Vorführung buchen
Siehe Ressource
Teilen auf:
LinkedIn-MarkenSozialx Logo
Interessiert an mehr?

Teilen auf:
LinkedIn-MarkenSozialx Logo
Autor
Pieter Danhieux
Veröffentlicht Nov 30, 2021

Vorstandsvorsitzender, Chairman und Mitbegründer

Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Teilen auf:
LinkedIn-MarkenSozialx 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.

Inhaltsverzeichnis

PDF herunterladen
Siehe Ressource
Interessiert an mehr?

Vorstandsvorsitzender, Chairman und Mitbegründer

mehr erfahren

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Eine Vorführung buchenHerunterladen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Ressourcenzentrum

Ressourcen für den Einstieg

Weitere Veröffentlichungen
Ressourcenzentrum

Ressourcen für den Einstieg

Weitere Veröffentlichungen