API sobre ruedas: Un viaje por carretera de arriesgadas vulnerabilidades
¿Cuándo fue la última vez que hizo un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que sólo sea una vuelta reciente a la agenda, pero realmente, nada es mejor que la carretera abierta y cambiar de aires.
A menos que sea una vulnerabilidad de software, por supuesto.
Ya hemos hablado largo y tendido sobre los peligros que suponen las medidas de ciberseguridad poco estrictas en la industria del automóvil, con empresas como Tesla y Jeep que ya están trabajando con investigadores de seguridad, encontrando fallos explotables que podrían haber dado lugar a graves problemas de seguridad si no se descubrían a tiempo y se solucionaban. También hemos hablado de que, en general, la seguridad del software sigue estando en el salvaje oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las APIs se están volviendo especialmente insidiosas, ya que el tráfico de APIs maliciosas ha crecido más de un 300% sólo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente APIs sobre ruedas. Están conectados, conversan mucho con otras aplicaciones y podrían ser objeto de ataques dirigidos como uno de los muchos puntos finales vulnerables.
Cuando su cargador de vehículos eléctricos dice demasiado
Los vehículos conectados han sido objeto de escrutinio por su seguridad de software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de carga de vehículos eléctricos domésticos, así como en una red pública de carga de vehículos eléctricos muy extendida.
¿A quién le importa un cargador? ¿Qué podría ganar un atacante? Por desgracia, una de las desventajas de la tecnología potente y profunda que trabaja horas extras para nosotros es que, por lo general, estos dispositivos tienen un mal caso de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles que los acompañan a través de una API, en un entorno basado en la nube, y todo ello puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones, y si estos puntos finales no se configuran con cuidado, se podría compartir demasiado, o peor aún, acceder a través de una puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de la API que permitían la toma de posesión de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de múltiples dispositivos de vehículos eléctricos. Todos estos problemas fueron corregidos, pero el hecho de que unas pocas líneas de código fueran todo lo que se interpuso entre los atacantes y la interrupción completa de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que se trate de un asunto de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, que habrían permitido la toma de posesión de cuentas si se hubieran explotado. IDOR entra dentro de la autenticación rota, que ocupa el segundo lugar en el Top 10 de vulnerabilidades de API de OWASP. Es tan común como la suciedad, lo que apunta a un fallo en el aprendizaje y la implementación de código de calidad. No podemos persistir en conectar dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las APIs mal configuradas son precisamente eso.
Trabajar de forma segura con las APIs de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las APIs es que se promociona como una nueva ola de desastres de ciberseguridad que hay que intentar mitigar, cuando en realidad no es más que un nuevo escenario para los mismos viejos problemas que hemos visto durante décadas en el desarrollo web. Cross-site scripting, inyección, desconfiguración: ¿te suena?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, seguimos sin contar con los expertos necesarios para hacer siquiera mella en la cantidad de salvaguardas que hay que aplicar a la avalancha de código que se escribe cada día. Los desarrolladores tienen que elevar sus conocimientos y responsabilidades en materia de seguridad, y no les corresponde a ellos tomar la iniciativa. Si tienes un equipo que trabaja en sistemas integrados en electrodomésticos, o en APIs que podrían convertir un coche en el juguete de control remoto de alguien, entonces debes asegurarte de que están equipados con lo que necesitan para dejar de introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido a XSS son mínimas, por ejemplo, pero es necesario mostrar a los desarrolladores los matices que diferencian un patrón de codificación pobre de uno bueno. Además, los procesos de desarrollo perezosos suelen ser habituales en las configuraciones de las API, ya que a muchas se les conceden amplios permisos por encima de los requisitos mínimos para que realicen las tareas establecidas, lo que abre una gran superficie de amenaza adicional y un posible robo de datos. Estos factores deben ser considerados durante la construcción, pero si no están arraigados en las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El dramático aumento de las APIs como objetivo de los actores de amenazas muestra que la atención se está moviendo a una fruta que se percibe como de bajo riesgo... y en este caso, es una que podría ser una tubería a la suciedad significativa, además de las amenazas potenciales a la vida en forma de toma de posesión del vehículo.
Dejar la seguridad de las APIs al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos, y frustrante retrabajo y bajo rendimiento en el mejor. Debería ser una consideración crítica como parte del ecosistema de comunicación del software, y estar en lo alto de la lista de un programa de seguridad de primera clase. La clave para esto es tratar cada API como si fuera un humano, y evaluar qué acceso debe tener. ¿Debe Jim de Contabilidad tener acceso a todos los documentos legales sensibles de toda la empresa? Probablemente no, y generalmente el control de acceso se determina correctamente en el caso del personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son potentes parlanchines que permitirán que todo el mundo conozca sus secretos si no se configuran con los mismos métodos de confianza cero de todo lo demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de estos portales vulnerables a la desesperación. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas para tomar las decisiones correctas en las etapas críticas de la creación.
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/63e39c23d1fa055d9a19b841_613f0d0d79f15e7f01097c5e_dino-reichmuth-A5rCN8626Ck-unsplash.webp)
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/63e39c23d1fa05288119b842_613f0d0d79f15e7f01097c5e_dino-reichmuth-A5rCN8626Ck-unsplash.webp)
Dejar la seguridad de la API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos, y frustrantes reajustes y bajo rendimiento en el mejor.
Director General, Presidente y Cofundador
![](https://cdn.prod.website-files.com/5fec9210c1841a81c9c6ce7d/66d0b4fa43284a440c24b591_learn-more.avif)
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDirector General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/63e39c23d1fa055d9a19b841_613f0d0d79f15e7f01097c5e_dino-reichmuth-A5rCN8626Ck-unsplash.webp)
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/63e39c23d1fa05288119b842_613f0d0d79f15e7f01097c5e_dino-reichmuth-A5rCN8626Ck-unsplash.webp)
¿Cuándo fue la última vez que hizo un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que sólo sea una vuelta reciente a la agenda, pero realmente, nada es mejor que la carretera abierta y cambiar de aires.
A menos que sea una vulnerabilidad de software, por supuesto.
Ya hemos hablado largo y tendido sobre los peligros que suponen las medidas de ciberseguridad poco estrictas en la industria del automóvil, con empresas como Tesla y Jeep que ya están trabajando con investigadores de seguridad, encontrando fallos explotables que podrían haber dado lugar a graves problemas de seguridad si no se descubrían a tiempo y se solucionaban. También hemos hablado de que, en general, la seguridad del software sigue estando en el salvaje oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las APIs se están volviendo especialmente insidiosas, ya que el tráfico de APIs maliciosas ha crecido más de un 300% sólo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente APIs sobre ruedas. Están conectados, conversan mucho con otras aplicaciones y podrían ser objeto de ataques dirigidos como uno de los muchos puntos finales vulnerables.
Cuando su cargador de vehículos eléctricos dice demasiado
Los vehículos conectados han sido objeto de escrutinio por su seguridad de software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de carga de vehículos eléctricos domésticos, así como en una red pública de carga de vehículos eléctricos muy extendida.
¿A quién le importa un cargador? ¿Qué podría ganar un atacante? Por desgracia, una de las desventajas de la tecnología potente y profunda que trabaja horas extras para nosotros es que, por lo general, estos dispositivos tienen un mal caso de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles que los acompañan a través de una API, en un entorno basado en la nube, y todo ello puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones, y si estos puntos finales no se configuran con cuidado, se podría compartir demasiado, o peor aún, acceder a través de una puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de la API que permitían la toma de posesión de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de múltiples dispositivos de vehículos eléctricos. Todos estos problemas fueron corregidos, pero el hecho de que unas pocas líneas de código fueran todo lo que se interpuso entre los atacantes y la interrupción completa de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que se trate de un asunto de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, que habrían permitido la toma de posesión de cuentas si se hubieran explotado. IDOR entra dentro de la autenticación rota, que ocupa el segundo lugar en el Top 10 de vulnerabilidades de API de OWASP. Es tan común como la suciedad, lo que apunta a un fallo en el aprendizaje y la implementación de código de calidad. No podemos persistir en conectar dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las APIs mal configuradas son precisamente eso.
Trabajar de forma segura con las APIs de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las APIs es que se promociona como una nueva ola de desastres de ciberseguridad que hay que intentar mitigar, cuando en realidad no es más que un nuevo escenario para los mismos viejos problemas que hemos visto durante décadas en el desarrollo web. Cross-site scripting, inyección, desconfiguración: ¿te suena?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, seguimos sin contar con los expertos necesarios para hacer siquiera mella en la cantidad de salvaguardas que hay que aplicar a la avalancha de código que se escribe cada día. Los desarrolladores tienen que elevar sus conocimientos y responsabilidades en materia de seguridad, y no les corresponde a ellos tomar la iniciativa. Si tienes un equipo que trabaja en sistemas integrados en electrodomésticos, o en APIs que podrían convertir un coche en el juguete de control remoto de alguien, entonces debes asegurarte de que están equipados con lo que necesitan para dejar de introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido a XSS son mínimas, por ejemplo, pero es necesario mostrar a los desarrolladores los matices que diferencian un patrón de codificación pobre de uno bueno. Además, los procesos de desarrollo perezosos suelen ser habituales en las configuraciones de las API, ya que a muchas se les conceden amplios permisos por encima de los requisitos mínimos para que realicen las tareas establecidas, lo que abre una gran superficie de amenaza adicional y un posible robo de datos. Estos factores deben ser considerados durante la construcción, pero si no están arraigados en las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El dramático aumento de las APIs como objetivo de los actores de amenazas muestra que la atención se está moviendo a una fruta que se percibe como de bajo riesgo... y en este caso, es una que podría ser una tubería a la suciedad significativa, además de las amenazas potenciales a la vida en forma de toma de posesión del vehículo.
Dejar la seguridad de las APIs al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos, y frustrante retrabajo y bajo rendimiento en el mejor. Debería ser una consideración crítica como parte del ecosistema de comunicación del software, y estar en lo alto de la lista de un programa de seguridad de primera clase. La clave para esto es tratar cada API como si fuera un humano, y evaluar qué acceso debe tener. ¿Debe Jim de Contabilidad tener acceso a todos los documentos legales sensibles de toda la empresa? Probablemente no, y generalmente el control de acceso se determina correctamente en el caso del personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son potentes parlanchines que permitirán que todo el mundo conozca sus secretos si no se configuran con los mismos métodos de confianza cero de todo lo demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de estos portales vulnerables a la desesperación. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas para tomar las decisiones correctas en las etapas críticas de la creación.
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/63e39c23d1fa055d9a19b841_613f0d0d79f15e7f01097c5e_dino-reichmuth-A5rCN8626Ck-unsplash.webp)
¿Cuándo fue la última vez que hizo un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que sólo sea una vuelta reciente a la agenda, pero realmente, nada es mejor que la carretera abierta y cambiar de aires.
A menos que sea una vulnerabilidad de software, por supuesto.
Ya hemos hablado largo y tendido sobre los peligros que suponen las medidas de ciberseguridad poco estrictas en la industria del automóvil, con empresas como Tesla y Jeep que ya están trabajando con investigadores de seguridad, encontrando fallos explotables que podrían haber dado lugar a graves problemas de seguridad si no se descubrían a tiempo y se solucionaban. También hemos hablado de que, en general, la seguridad del software sigue estando en el salvaje oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las APIs se están volviendo especialmente insidiosas, ya que el tráfico de APIs maliciosas ha crecido más de un 300% sólo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente APIs sobre ruedas. Están conectados, conversan mucho con otras aplicaciones y podrían ser objeto de ataques dirigidos como uno de los muchos puntos finales vulnerables.
Cuando su cargador de vehículos eléctricos dice demasiado
Los vehículos conectados han sido objeto de escrutinio por su seguridad de software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de carga de vehículos eléctricos domésticos, así como en una red pública de carga de vehículos eléctricos muy extendida.
¿A quién le importa un cargador? ¿Qué podría ganar un atacante? Por desgracia, una de las desventajas de la tecnología potente y profunda que trabaja horas extras para nosotros es que, por lo general, estos dispositivos tienen un mal caso de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles que los acompañan a través de una API, en un entorno basado en la nube, y todo ello puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones, y si estos puntos finales no se configuran con cuidado, se podría compartir demasiado, o peor aún, acceder a través de una puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de la API que permitían la toma de posesión de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de múltiples dispositivos de vehículos eléctricos. Todos estos problemas fueron corregidos, pero el hecho de que unas pocas líneas de código fueran todo lo que se interpuso entre los atacantes y la interrupción completa de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que se trate de un asunto de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, que habrían permitido la toma de posesión de cuentas si se hubieran explotado. IDOR entra dentro de la autenticación rota, que ocupa el segundo lugar en el Top 10 de vulnerabilidades de API de OWASP. Es tan común como la suciedad, lo que apunta a un fallo en el aprendizaje y la implementación de código de calidad. No podemos persistir en conectar dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las APIs mal configuradas son precisamente eso.
Trabajar de forma segura con las APIs de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las APIs es que se promociona como una nueva ola de desastres de ciberseguridad que hay que intentar mitigar, cuando en realidad no es más que un nuevo escenario para los mismos viejos problemas que hemos visto durante décadas en el desarrollo web. Cross-site scripting, inyección, desconfiguración: ¿te suena?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, seguimos sin contar con los expertos necesarios para hacer siquiera mella en la cantidad de salvaguardas que hay que aplicar a la avalancha de código que se escribe cada día. Los desarrolladores tienen que elevar sus conocimientos y responsabilidades en materia de seguridad, y no les corresponde a ellos tomar la iniciativa. Si tienes un equipo que trabaja en sistemas integrados en electrodomésticos, o en APIs que podrían convertir un coche en el juguete de control remoto de alguien, entonces debes asegurarte de que están equipados con lo que necesitan para dejar de introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido a XSS son mínimas, por ejemplo, pero es necesario mostrar a los desarrolladores los matices que diferencian un patrón de codificación pobre de uno bueno. Además, los procesos de desarrollo perezosos suelen ser habituales en las configuraciones de las API, ya que a muchas se les conceden amplios permisos por encima de los requisitos mínimos para que realicen las tareas establecidas, lo que abre una gran superficie de amenaza adicional y un posible robo de datos. Estos factores deben ser considerados durante la construcción, pero si no están arraigados en las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El dramático aumento de las APIs como objetivo de los actores de amenazas muestra que la atención se está moviendo a una fruta que se percibe como de bajo riesgo... y en este caso, es una que podría ser una tubería a la suciedad significativa, además de las amenazas potenciales a la vida en forma de toma de posesión del vehículo.
Dejar la seguridad de las APIs al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos, y frustrante retrabajo y bajo rendimiento en el mejor. Debería ser una consideración crítica como parte del ecosistema de comunicación del software, y estar en lo alto de la lista de un programa de seguridad de primera clase. La clave para esto es tratar cada API como si fuera un humano, y evaluar qué acceso debe tener. ¿Debe Jim de Contabilidad tener acceso a todos los documentos legales sensibles de toda la empresa? Probablemente no, y generalmente el control de acceso se determina correctamente en el caso del personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son potentes parlanchines que permitirán que todo el mundo conozca sus secretos si no se configuran con los mismos métodos de confianza cero de todo lo demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de estos portales vulnerables a la desesperación. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas para tomar las decisiones correctas en las etapas críticas de la creación.
Director General, Presidente y Cofundador
![](https://cdn.prod.website-files.com/5fec9210c1841a81c9c6ce7d/66d0b4fa43284a440c24b591_learn-more.avif)
Haga clic en el siguiente enlace y descargue el PDF de esta página.
DescargarSecure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónDirector General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
¿Cuándo fue la última vez que hizo un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que sólo sea una vuelta reciente a la agenda, pero realmente, nada es mejor que la carretera abierta y cambiar de aires.
A menos que sea una vulnerabilidad de software, por supuesto.
Ya hemos hablado largo y tendido sobre los peligros que suponen las medidas de ciberseguridad poco estrictas en la industria del automóvil, con empresas como Tesla y Jeep que ya están trabajando con investigadores de seguridad, encontrando fallos explotables que podrían haber dado lugar a graves problemas de seguridad si no se descubrían a tiempo y se solucionaban. También hemos hablado de que, en general, la seguridad del software sigue estando en el salvaje oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las APIs se están volviendo especialmente insidiosas, ya que el tráfico de APIs maliciosas ha crecido más de un 300% sólo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente APIs sobre ruedas. Están conectados, conversan mucho con otras aplicaciones y podrían ser objeto de ataques dirigidos como uno de los muchos puntos finales vulnerables.
Cuando su cargador de vehículos eléctricos dice demasiado
Los vehículos conectados han sido objeto de escrutinio por su seguridad de software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de carga de vehículos eléctricos domésticos, así como en una red pública de carga de vehículos eléctricos muy extendida.
¿A quién le importa un cargador? ¿Qué podría ganar un atacante? Por desgracia, una de las desventajas de la tecnología potente y profunda que trabaja horas extras para nosotros es que, por lo general, estos dispositivos tienen un mal caso de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles que los acompañan a través de una API, en un entorno basado en la nube, y todo ello puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones, y si estos puntos finales no se configuran con cuidado, se podría compartir demasiado, o peor aún, acceder a través de una puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de la API que permitían la toma de posesión de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de múltiples dispositivos de vehículos eléctricos. Todos estos problemas fueron corregidos, pero el hecho de que unas pocas líneas de código fueran todo lo que se interpuso entre los atacantes y la interrupción completa de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que se trate de un asunto de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, que habrían permitido la toma de posesión de cuentas si se hubieran explotado. IDOR entra dentro de la autenticación rota, que ocupa el segundo lugar en el Top 10 de vulnerabilidades de API de OWASP. Es tan común como la suciedad, lo que apunta a un fallo en el aprendizaje y la implementación de código de calidad. No podemos persistir en conectar dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las APIs mal configuradas son precisamente eso.
Trabajar de forma segura con las APIs de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las APIs es que se promociona como una nueva ola de desastres de ciberseguridad que hay que intentar mitigar, cuando en realidad no es más que un nuevo escenario para los mismos viejos problemas que hemos visto durante décadas en el desarrollo web. Cross-site scripting, inyección, desconfiguración: ¿te suena?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, seguimos sin contar con los expertos necesarios para hacer siquiera mella en la cantidad de salvaguardas que hay que aplicar a la avalancha de código que se escribe cada día. Los desarrolladores tienen que elevar sus conocimientos y responsabilidades en materia de seguridad, y no les corresponde a ellos tomar la iniciativa. Si tienes un equipo que trabaja en sistemas integrados en electrodomésticos, o en APIs que podrían convertir un coche en el juguete de control remoto de alguien, entonces debes asegurarte de que están equipados con lo que necesitan para dejar de introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido a XSS son mínimas, por ejemplo, pero es necesario mostrar a los desarrolladores los matices que diferencian un patrón de codificación pobre de uno bueno. Además, los procesos de desarrollo perezosos suelen ser habituales en las configuraciones de las API, ya que a muchas se les conceden amplios permisos por encima de los requisitos mínimos para que realicen las tareas establecidas, lo que abre una gran superficie de amenaza adicional y un posible robo de datos. Estos factores deben ser considerados durante la construcción, pero si no están arraigados en las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El dramático aumento de las APIs como objetivo de los actores de amenazas muestra que la atención se está moviendo a una fruta que se percibe como de bajo riesgo... y en este caso, es una que podría ser una tubería a la suciedad significativa, además de las amenazas potenciales a la vida en forma de toma de posesión del vehículo.
Dejar la seguridad de las APIs al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos, y frustrante retrabajo y bajo rendimiento en el mejor. Debería ser una consideración crítica como parte del ecosistema de comunicación del software, y estar en lo alto de la lista de un programa de seguridad de primera clase. La clave para esto es tratar cada API como si fuera un humano, y evaluar qué acceso debe tener. ¿Debe Jim de Contabilidad tener acceso a todos los documentos legales sensibles de toda la empresa? Probablemente no, y generalmente el control de acceso se determina correctamente en el caso del personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son potentes parlanchines que permitirán que todo el mundo conozca sus secretos si no se configuran con los mismos métodos de confianza cero de todo lo demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de estos portales vulnerables a la desesperación. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas para tomar las decisiones correctas en las etapas críticas de la creación.
Índice
Director General, Presidente y Cofundador
![](https://cdn.prod.website-files.com/5fec9210c1841a81c9c6ce7d/66d0b4fa43284a440c24b591_learn-more.avif)
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Impulse la seguridad impulsada por los desarrolladores a escala global Tournaments
Nuestra plataforma le permite fomentar una red de ciberseguridad centrada en la comunidad con atractivos concursos de codificación y tournaments, destacando vulnerabilidades del mundo real y prácticas de codificación seguras.
Trust Agent en acción
SCW Trust Agent le proporciona las herramientas que necesita para entregar código seguro más rápidamente, garantizando que los desarrolladores tengan los conocimientos y las habilidades para implementar las mejores prácticas de seguridad en el lenguaje de programación específico de sus commits de código.
Recursos para empezar
Cómo DigitalOcean redujo la deuda de seguridad del software y amplió los límites de la productividad
Secure Code Warrior ayudó a DigitalOcean a crear y publicar código de calidad desde el principio, impulsando la innovación digital y la modernización con desarrolladores conscientes de la seguridad.
Cómo DigitalOcean redujo la deuda de seguridad del software y amplió los límites de la productividad
Secure Code Warrior ayudó a DigitalOcean a crear y publicar código de calidad desde el principio, impulsando la innovación digital y la modernización con desarrolladores conscientes de la seguridad.
Las mujeres en la seguridad están ganando: Cómo la AWSN está creando una nueva generación de supermujeres de la seguridad
Secure-by-Design es la última iniciativa en boca de todos, y el gobierno australiano, colaborando con CISA en los niveles más altos de la gobernanza mundial, está orientando un estándar más alto de calidad y seguridad del software por parte de los vendedores.
SCW Trust Agent: visibilidad y control para ampliar la seguridad impulsada por los desarrolladores
SCW Trust Agent, presentado por Secure Code Warrior, ofrece a los responsables de seguridad la visibilidad y el control necesarios para ampliar la seguridad impulsada por los desarrolladores dentro de las organizaciones. Al conectarse a los repositorios de código, evalúa los metadatos de commit del código, inspecciona a los desarrolladores, los lenguajes de programación utilizados y las marcas de tiempo de envío para determinar los conocimientos de seguridad de los desarrolladores.