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.
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
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.
¿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.
¿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.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
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.
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
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
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
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.
Recursos para empezar
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Inmersión profunda: Navegando por la vulnerabilidad crítica CUPS en sistemas GNU-Linux
Descubra los últimos retos de seguridad a los que se enfrentan los usuarios de Linux mientras exploramos las recientes vulnerabilidades de alta gravedad en el Sistema de Impresión UNIX Común (CUPS). Aprenda cómo estos problemas pueden conducir a una potencial ejecución remota de código (RCE) y lo que puede hacer para proteger sus sistemas.