Hemos advertido en numerosas ocasiones, sobre los riesgos de las extensiones del navegador, no sólo para Chrome, sino para cualquier navegador.
Esto se debe a que las extensiones del navegador no están sujetas a los mismos estrictos controles que el contenido de las páginas web, de lo contrario no serían extensiones, básicamente serían páginas web almacenadas localmente.
Un bloqueador de publicidad o un gestor de contraseñas bloqueado para que funcione exactamente en un sitio web no sería muy útil, un gestor de pestañas que sólo pudiera gestionar una pestaña o un sitio a la vez no sería muy útil, y así sucesivamente.
Se supone que las páginas web no pueden anular los controles impuestos por el propio navegador, por lo que no pueden alterar la barra de direcciones para mostrar un nombre de servidor falso, o saltarse el cuadro de diálogo “¿Estás seguro?” que verifica que realmente quieres descargar ese documento de Word en tu disco duro.
Las extensiones del navegador, por otro lado, se supone que pueden, bueno, ampliar y alterar el comportamiento del propio navegador.
Entre otras cosas, las extensiones del navegador pueden:
- Mirar lo que se va a mostrar en cada pestaña una vez descifrada.
- Modificar lo que finalmente se muestra.
- Ver y modificar todo lo que escribas o subas antes de que se transmita.
- Leer y escribir archivos en tu disco duro local.
- Lanzar o supervisar otros programas.
- Acceder a hardware como cámaras web y micrófonos.
Screencastify es un ejemplo de extensión del navegador que ofrece una función popular que no sería posible sólo a través de un sitio web, a saber, capturar parte o toda la pantalla para poder compartirla con otros usuarios.
La extensión presume de tener más de 10.000.000 usuarios (aparentemente, no hay una categoría superior, independientemente del número de usuarios al que se llegue), y te invita, en su propia descripción, a hacerlo:
El investigador de seguridad Wladimir Palant, también desarrollador de extensiones, decidió investigar Screencastify, dada su popularidad.
A principios de esta semana, publicó lo que encontró.
Entre otras cosas, su informe es un recordatorio bien escrito de lo difícil que puede ser averiguar quién está involucrado en la red de confianza que debes tener cuando decides usar una aplicación o servicio de la empresa X.
Los riesgos de la cadena de suministro
Al igual que los riesgos de la cadena de suministro de código fuente, en la que se instala un software de A, que tiene licencia de B, se actualiza de C, se introducen módulos adicionales de D (posiblemente repetidos recursivamente en muchas etapas interconectadas); los riesgos de los servicios basados en la web pueden provenir de una delegación implícita de confianza en muchos otros vendedores o proveedores que participan en el proceso de prestación de servicios.
Palant comenzó examinando el archivo de manifiesto de Chrome de Screencastify, un archivo de datos JSON que viene con cada extensión para especificar información importante como el nombre, el número de versión, la política de seguridad, la URL de actualización y los permisos necesarios.
Una de las entradas del manifiesto de Chrome es una lista denominada externally_connectable, que indica qué extensiones, aplicaciones y sitios web pueden interactuar con tu extensión.
Normalmente, otras extensiones y aplicaciones ya instaladas en tu sistema pueden hacerlo por defecto, pero por razones obvias de seguridad, los sitios web externos no pueden.
Esto significa que no puedes entrar inocentemente en un sitio web, sólo para echar un vistazo, sólo para encontrar que el servidor que estás visitando está tratando de tomar el control de la extensión.
Pero Screencastify proporciona todo tipo de funcionalidades adicionales basadas en la nube desde su propio sitio web, por lo que es comprensible que se haya incluido en la lista de fuentes externally_connectable.
Cuando Palant miró por primera vez, la lista de confianza de conexión tenía este aspecto:
Dado que el carácter especial * significa “cualquier cosa “, la especificación anterior dice que cualquier URL de cualquier sitio web bajo el dominio screencastify.com está automáticamente autorizada a interactuar de forma remota con tu navegador, a través de la extensión Screencastify que, no lo olvides, tiene acceso a tu cámara web para proporcionar un aspecto popular de su servicio.
Palant descubrió rápidamente que una de las peticiones que estos sitios web con conexión externa podían enviar a tu navegador tenía la etiqueta bg:getSignInToken, y al hacer esta petición devolvía un token de acceso a Google para tus archivos de Google Drive. (En nuestras pruebas, Screencastify no funciona a menos que tengas una cuenta de Google y hayas iniciado sesión en ella).
Curiosamente, según Palant, la razón por la que Screencastify funciona con acceso completo a Google Drive (las extensiones pueden, de hecho, solicitar acceso sólo a un directorio propio) es que, sin acceso completo, una extensión no puede mostrar una lista de sus propios archivos. Por lo tanto, para mantener un conjunto de archivos subidos que luego puedas consultar, parece que una extensión debe solicitar acceso completo, crear un directorio propio y luego mostrar sus propios archivos desde allí.
Además, como era de esperar, dado que Screencastify se centra en la captura de pantalla con la incorporación de la transmisión de la webcam, los sitios web con conexión externa pueden solicitar acceso a la API de captura de escritorio de Chrome (que puede leer el contenido de los píxeles de cualquier parte de la pantalla), a la API de captura de pestañas (que puede extraer contenido del propio navegador) y a la API de WebRTC (abreviatura de comunicación web en tiempo real, incluido el acceso a la cámara web).
Las solicitudes para capturar el escritorio o las pestañas del navegador son menos controvertidas de lo que parece, porque siempre producen un diálogo emergente obvio para solicitar permiso.
Aparentemente, Chrome pregunta cada vez – ni siquiera hay un permiso inferido si activas la captura de pantalla varias veces en una sola sesión.
Sin embargo, los permisos de la webcam sólo deben solicitarse una vez, lo que hace Screencastify al configurarlo, tras lo cual pueden reclamarse sin que aparezcan más ventanas emergentes.
Palant también descubrió que la configuración de grabación de vídeo por defecto de Screencastify, una vez que se habilita algún tipo de captura, incluye la subida del vídeo a tus archivos de Google Drive.
Y, como ya hemos mencionado, cualquier sitio web de la lista externally_connectable puede adquirir un token de acceso a tu Google Drive y descargar los vídeos más tarde, aunque no haya iniciado furtivamente una captura de webcam no deseada.
¿Y qué?
Llegados a este punto, puede que estés pensando: “¿Y qué? Ya he decidido confiar en el código y el sitio web de Screencastify, así que esto no es una sorpresa. Ya espero que Screencastiy capture y almacene el vídeo, así que lo tendrán de todos modos”.
Aquí es donde la configuración https://*.screencastify.com/* (véase más arriba) cobra importancia.
Como descubrió Palant en el momento de su investigación, al menos seis subdominios de Screencastify eran gestionados por terceros:
- Webflow gestionaba el subdominio www.screencastify.com,
- Teachable gestionaba course.screencastify.com,
- Atlassian gestionaba el subdominio status.screencastify.com,
- Netlify gestionaba quote.screencastify.com,
- Marketo gestionaba go.screencastify.com, y
- ZenDesk gestionaba learn.screencastify.com.
En otras palabras, no sólo tenías que confiar en las extensiones de Screencastify y en sus propios servidores con acceso “silencioso” a tu cámara web y a tu Google Drive, sino que también tenías que confiar en al menos todos los demás proveedores mencionados.
Más concretamente, tenías que confiar en que no había fallos como el cross-site scripting (XSS) en ninguno de esos subdominios.
Un fallo XSS significa que se puede engañar a un sitio como example.com para que genere y sirva una página web que incluya contenido no modificado y peligroso de su propia elección, como un resultado de búsqueda que incluya un fragmento sin procesar de código JavaScript en lugar de una simple cadena de texto.
Finalmente, Palant encontró un error XSS en una de las propiedades de Screencastify, del que informó en febrero.
Por suerte, Screencastify reconoció el error el mismo día y lo arregló al día siguiente.
Muchas partes en movimiento
Esta investigación es, sin embargo, un buen recordatorio de que puede haber muchas más partes móviles, y muchas más exposiciones al riesgo, de lo que se piensa al principio cuando se decide por el producto P o el servicio S del proveedor X.
Curiosamente, desde que se publicó el informe de Palant, Screencastify decidió restringir esa lista de confianza excesivamente amplia en su especificación externally_connectable, que ahora se ha reducido a un conjunto explícito de subdominios:
El subdominio www.screencastify.com, operado por un tercero, sigue ahí, pero la lista explícita hace mucho más fácil para los investigadores de SecOps (operaciones de seguridad) cuantificar el riesgo global de esta extensión si así lo desean.
El principio del mínimo privilegio
Esto es un gran recordatorio del valor del principio de necesidad de conocer, o de mínimo privilegio, que dice que no se debes dar a nadie acceso a recursos que no necesita, por mucho que se confíe en ellos, con el argumento de que hay menos posibilidades de equivocarse si se especifica la configuración de seguridad de forma explícita en lugar de implícita.
La necesidad de saber también protege a los usuarios de confianza de cometer errores inocentes que podrían ser peligrosos tanto para ti como para ellos.
Por ejemplo, a veces necesitas iniciar sesión con poderes de root o de administrador, pero no necesitas ser root para leer tu correo electrónico o navegar por la web, por lo que debes configurar tu cuenta para que puedas asumir esos superpoderes sólo cuando los necesites, y renunciar a ellos cuando no los necesites.
En ciberseguridad, menos es más.
Dejar un comentario