
API on Wheels: un viaje por carretera lleno de vulnerabilidades riesgosas
¿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.


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.
최고 경영자, 회장 겸 공동 설립자

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
데모 예약하기최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(AISA - 호주 정보 보안 협회)로 선정되었으며, GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA 자격증을 보유하고 있습니다.


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

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

아래 링크를 클릭하고 이 자료의 PDF를 다운로드하세요.
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
보고서 보기데모 예약하기최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(AISA - 호주 정보 보안 협회)로 선정되었으며, GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA 자격증을 보유하고 있습니다.
¿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.




%20(1).avif)
.avif)
