Esta semana en seguridad: cargadores inseguros, solicitudes falsas y seguridad básica

La gente de Pen Test Partners decidió echar un vistazo a los cargadores de vehículos eléctricos. Muchos de estos cargadores están conectados a WiFi y le permiten verificar el estado de carga de su vehículo a través de la nube. ¿Qué tan bien están asegurados? Como era de esperar, no tan bien como podrían estarlo.

El peor de los dispositivos probados, Project EV, en realidad no tenía autenticación de usuario en la API del servidor. Saber el número de serie fue suficiente para acceder a la cuenta y controlar el dispositivo. Los números de serie son predecibles, por lo que hacerse cargo de cada cargador de Project EV conectado a Internet sería trivial. Además de eso, el firmware arbitrario podría cargarse de forma remota en el hardware, lo que representa un problema potencial real.

La plataforma EVBox tenía otro problema en el que un usuario autenticado podía simplemente especificar un rol de seguridad. El rol de administrador fue especialmente interesante aquí, trabajando como supervisor que podía ver y administrar múltiples cuentas. Este defecto se reparó en unas impresionantes 24 horas. El cargador EVBox, así como varios otros dispositivos que revisaron, tenían debilidades de seguridad fundamentales debido al uso de hardware Raspberry Pi en el producto.

Espera, ¿qué pasa con la Raspberry Pi?

Al parecer, la opinión de que Raspberry Pi no pertenecía al hardware de IoT atrapó un poco a Pen Test Partners, ya que unos días después publicaron una publicación posterior que explicaba su justificación. En pocas palabras, el Pi no puede asegurar una puesta en marcha y no puede hacer almacenamiento encriptado. Varios de los defectos que encontraron en los cargadores mencionados anteriormente se descubrieron porque los sistemas de archivos del dispositivo estaban abiertos para su inspección. Un procesador que puede manejar el cifrado de hardware, idealmente mejor que la combinación de TPM y Windows Bitlocker que discutimos la semana pasada, brinda cierta seguridad real contra tal ataque.

Ahora Linux en la Pi ciertamente puede hacer un sistema de archivos cifrado, pero el problema real es el almacenamiento de la clave de cifrado. Sin un enclave seguro en el SoC, es muy difícil tener una clave de cifrado que un atacante con acceso físico no lea trivialmente. En una computadora portátil, no es un problema porque el usuario puede dar una contraseña que se utiliza como parte de la clave de cifrado, pero ¿quién quiere escribir una contraseña en cada dispositivo de IoT cada vez que los enciende?

Carga lateral de Snapcraft

[Amy Burnett] Encontré algo en un sistema Ubuntu que no tenía sentido: un comando de Docker que arrojaba un error de segmentación. Lo que fue aún más extraño, solo sucedió cuando el comando se lanzó en un directorio separado, donde un libc.so.6 El archivo también se guardó. Su sentido de seguridad tintineó. Por alguna razón, ese archivo de biblioteca probablemente se cargó cuando se ejecutó el comando docker. Rápido strace confirmó la teoría, pero ¿por qué sucedió eso? La respuesta es la vulnerabilidad de seguridad en el nuevo administrador de paquetes de Ubuntu. Ubuntu ha comenzado a proporcionar algunos programas como instantáneas en lugar de paquetes tradicionales.

El culpable es la lógica de Snapcraft utilizada para construir el LD_LIBRARY_PATH variable local. Si una de las variables utilizadas para construir esa variable está vacía, terminará con dos puntos dobles como parte de la cadena. Linux interpreta esto como el directorio actual y, por lo tanto, el lanzamiento de un paquete instalado con Snapcraft puede cargar bibliotecas dinámicas involuntariamente. Un ataque propuesto es distribuir un archivo de video en un archivo e incluso en una biblioteca maliciosa. Cualquier usuario que simplemente extraiga los archivos y reproduzca el video en un reproductor Snapcraft instalado cargará automáticamente la biblioteca maliciosa. El problema se rastreó como CVE-2020-27348 y se solucionó a fines de 2020.

Pedir falsificaciones

Esta semana apareció un trío de historias sobre la falsificación de mascotas, la primera de las cuales fue una falsificación de mascotas en línea (CSRF) en OkCupid. Para empezar, un ataque CSRF es cuando una visita a un sitio puede desencadenar una acción en otro sitio. Se supone que el uso compartido de recursos cruzados es la solución a este problema, pero hay advertencias que debe conocer. Lo importante aquí es que un formulario HTML puede enviar POST a otro dominio, incluso si el encabezado CORS no está configurado. La forma común de protegerse contra este ataque es un token CSRF que confirma que la solicitud realmente proviene de un sitio web aprobado. OkCupid no usó estos caracteres y, como tal, fue posible construir una página web que desencadena una acción en nombre del usuario.

Uno de los otros patrones comunes de solicitud falsa es la Solicitud falsa del lado del servidor (SSRF). Este es un poco diferente: aquí estamos engañando a un servidor al generar una solicitud no intencional. Por lo general, esto ocurre en el contexto de un servidor de aplicaciones para el usuario que envía tráfico a servicios de servicios de fondo no públicos. Aquí está la opción de incluir una URL interna como parámetro para nombrar la API de Facebook. Parece que el punto final de la API acepta ingenuamente cualquier URL como una imagen válida, incluso si ese sitio no es de acceso público. En este caso, esta acción filtró el contenido del endpoint interno, lo que permitió al explorador capturar un signo canario y ganar un par de premios de $ 30,000.

La historia final estalló a fines de la semana, y se trata de HTTP / 2. Este protocolo relativamente nuevo es un posible reemplazo de HTTP, y se trata de acelerar y hacer que el sitio sea más flexible. Adivina qué viene con un nuevo protocolo. Sí, nuevas formas creativas de romperlo. [James Kettle] de PortSwigger cubre una gran cantidad de posibles vulnerabilidades relacionadas con la solicitud de contrabando, en su mayoría relacionadas con la traducción de HTTP / 2 a HTTP 1.1 a través de un servidor anterior. Estos ataques son cosas como incluir dos puntos o nuevas líneas en los campos HTTPS / 2, donde esos símbolos se interpretan de manera diferente una vez traducidos a HTTP 1.1.

La vulnerabilidad anunciada más importante es probablemente CVE-2021-33193, una falla en Apache. mod_proxy. Existe un problema donde el espacio en blanco en un encabezado entrante es entendido de manera diferente por el servidor de front-end HTTP / 2 que en la parte posterior. Esto permite que un atacante solicite un punto final privilegiado, por ejemplo /wp-admin, pero disfrazar esa solicitud como algo poco interesante. Esta maniobra puede eludir las reglas de acceso y permitir el acceso a estas ubicaciones. La falla se corrigió en Apache Master y será parte de una versión 2.4.49, pero aquí estamos hablando de la vulnerabilidad y la 2.4.49 aún no ha terminado. Si está ejecutando un servidor vulnerable, puede que sea el momento de desactivar HTTP / 2.

Decodificación TLS alucinante

SySS lanzó recientemente Hallucinate como un proyecto de código abierto. Este proyecto trata de descifrar el tráfico SSL, no por cable, sino conectándose al sistema operativo o programa que realiza el cifrado. Los posibles usos son bastante amplios. ¿Tratando de averiguar qué datos envía una fuente binaria cerrada a la nube? ¿Resolver un problema difícil de manejar en datos cifrados? Una alucinación podría ayudar. Puede escupir un archivo PCAP cifrado o incluso ejecutar scripts de Python para manipular datos cifrados en tiempo real. Definitivamente un truco útil para agregar a tu biblioteca.

Seguridad básica de Google

[Kees Cook] del equipo de seguridad de código abierto de Google publicó una publicación esta semana, hablando sobre el estado de la seguridad en y alrededor del kernel de Linux. Señala que, si bien el núcleo funciona muy bien, cuando las cosas funcionan bien, cuando se rompe, puede descomponerse de manera insegura. En otras palabras, le gustaría que se hiciera más trabajo para hacer que el núcleo sea resistente al compromiso incluso en el caso de defectos. Aunque los cambios necesarios para hacer esto no se explican en la publicación, solo puedo pensar en esfuerzos como agregar Rust al núcleo y hacer una aleatorización de direcciones adicional.

La mayoría de la publicación no está dirigida al núcleo ascendente, sino a los integradores ascendentes. El consejo aquí es simple. Realice un seguimiento de la última versión o del núcleo estable. No utilice un núcleo de 10 años. ¿Es eso un desafío porque tiene mucho código central desajustado? Aguas abajo de sus cambios. Hace que todos estén más seguros. En lugar de gastar tanto esfuerzo de ingeniería en respaldar las correcciones a su antiguo núcleo, dedique ese esfuerzo a asegurar aún más el núcleo ascendente. Es interesante que concluya el artículo con la opinión de que el kernel y el kit de herramientas de Linux necesitan alrededor de 100 ingenieros inteligentes adicionales para ser mantenidos de manera efectiva.

Gloria Vega
Gloria Vega

Deja una respuesta

Tu dirección de correo electrónico no será publicada.