Nunca instalarías una aplicación que pueda iniciar sesión en tus documentos de Google, leer tus pulsaciones de teclado en tu navegador, interceptar solicitudes en tránsito, ejecutarse continuamente, actualizarse silenciosamente Y que podría ser lo suficientemente potente como para robar tus contraseñas, ¿verdad? Pues bien, esto es más o menos lo que pueden hacer las extensiones de navegador, y crean vulnerabilidades que se extienden más allá de un solo ordenador o incluso de una sola empresa.
Hace unos meses, un empleado de Vercel instaló la extensión de navegador Context.ai, relativamente nueva y popular, que ofrecía una “Suite de Oficina con IA.” Requería permiso OAuth para conectarse a las aplicaciones, así que cuando la pantalla de permisos les pidió que concedieran a la herramienta acceso a su cuenta de Google, hicieron clic en permitir. No era una extensión que Vercel hubiera aprobado internamente, pero tampoco estaba bloqueada.
A finales de febrero, un empleado de Context.ai instaló posteriormente una descarga de trucos de Roblox que contenía un infostealer. Ese malware encontró el token OAuth de Vercel, que se convirtió en el punto de entrada para un ataque a gran escala contra Vercel. El atacante no necesitó hackear Vercel, sino la startup de IA a cuyo software un empleado de Vercel ya había dado las claves.
Un malware robó datos recopilados de una extensión de navegador en la sombra. ¿Te suena familiar el patrón? Parece un ataque a la cadena de suministro, y eso es precisamente lo que es.
Cómo la brecha de Vercel fue un ataque a la cadena de suministro
Las extensiones de navegador se han convertido en uno de los vectores de ataque más subestimados en la seguridad empresarial, y la brecha de Vercel es solo el último ejemplo. El ataque siguió un patrón que la industria de la seguridad conoce bien por las dependencias de código abierto, donde parte del código de terceros se confía implícitamente y luego se ve comprometido en la cadena de suministro. Tenemos un nombre para ese patrón y toda una categoría de herramientas construidas en torno a él, pero la industria en su conjunto no los ha aplicado a las extensiones de navegador.
Un ataque a la cadena de suministro tiene algunos ingredientes principales. Se necesita código de terceros ejecutándose con privilegios reales, confianza implícita y víctimas sin una relación directa con la fuente del compromiso inicial. La brecha de Vercel cumple con los tres. Context.ai era un producto real que realizaba un trabajo real, y el acceso OAuth que se le había concedido a Google Workspace era una solicitud razonable para lo que intentaba hacer (aunque, discutiblemente, con demasiada confianza y poder). Eso significaba que un token OAuth altamente privilegiado estaba en el backend de AWS de Context.ai, a solo un dispositivo de empleado comprometido de convertirse en propiedad de un atacante.
Cuando ese empleado de Context.ai instaló un infostealer en su propia máquina, la confianza que un solo empleado había depositado en una extensión previamente legítima se convirtió en la vía de acceso a sus entornos internos. La brecha original ocurrió en otro lugar, pero Vercel sufrió las consecuencias. Y eso es lo que llamamos un ataque a la cadena de suministro.
El caso de Vercel no es el primer ataque de malware que utiliza extensiones de navegador como parte de un ataque a la cadena de suministro. Por ejemplo, la brecha de Cyberhaven a finales de 2024 fue una versión dirigida de un escenario similar, con extensiones centradas en desarrolladores específicamente en el punto de mira de los atacantes. La propia extensión de Chrome de Cyberhaven fue comprometida a través de un ataque de phishing en una cuenta de desarrollador, y se envió una actualización maliciosa a los usuarios antes de que nadie la detectara. La versión maliciosa estuvo activa durante aproximadamente 24 horas.
El modelo de actualización silenciosa crea más peligro
El modelo de actualización para las extensiones es un tanto descontrolado si se mira desde una perspectiva de seguridad. A diferencia del software de sistema operativo, las extensiones de navegador se actualizan de forma silenciosa y automática. El código que se ejecuta en tu navegador hoy puede no ser la aplicación que aceptaste al instalarla. A diferencia de otras actualizaciones de software que te piden que actualices (durante meses mientras sigues haciendo clic en “Actualizar más tarde”), no hay ninguna solicitud para obtener el consentimiento del usuario para actualizar. La única vez que recibirías una notificación es cuando la extensión solicita permisos adicionales. Una extensión que estaba limpia el mes pasado podría recibir una actualización maliciosa esta noche, y cada usuario que la tuviera instalada la obtendría automáticamente. Si ya tenía muchos permisos, estás en problemas. Imagina si las dependencias de software se autactualizaran silenciosamente en tu máquina de desarrollo.
Lo que no ha estado funcionando
Las empresas a menudo han intentado crear listas de extensiones permitidas (bloqueando todo lo demás) o, a la inversa, de extensiones bloqueadas. Pero en ambos casos, mantener la lista curada y actualizada presenta algunas barreras obvias. Aproximadamente la mitad de los autores de extensiones son desconocidos, y la mayoría de los editores han publicado solo una extensión, por lo que la gestión de extensiones basada en la reputación solo funciona para una pequeña parte de ellas. Incluso grandes empresas publican extensiones que no son del todo limpias, de todos modos. Mantener manualmente una lista interna precisa y actualizada es imposible.
El escaneo SCA se inventó para resolver esto para los paquetes. Los mecanismos que funcionan para las dependencias de código abierto operan en función de lo que hace el paquete (no del nombre o la funcionalidad declarada). Aprobar paquetes npm solo por su nombre, sin escaneo de código y sin inteligencia de amenazas, no se consideraría seguridad de la cadena de suministro para las dependencias. Pero si se cambia "paquete npm" por "extensión de Chrome", esa es más o menos la aproximación a la seguridad del navegador en los últimos años.
Tratemos las extensiones de navegador como otros vectores de la cadena de suministro
Aunque los marketplaces no lo reflejen, la confianza en el momento de la instalación no es suficiente. Debemos aplicar la misma filosofía aquí que en la seguridad de paquetes. Las organizaciones necesitan saber qué está instalado en todas las máquinas y requieren monitorización continua para que una extensión aparentemente limpia que se vuelve maliciosa no pase desapercibida.
La mayoría de los equipos de seguridad pueden articular un modelo de amenazas de la cadena de suministro para las dependencias. Saben que las cuentas de los mantenedores se ven comprometidas y que un paquete que estaba limpio el trimestre pasado puede ser un vector hoy (y hemos visto muchos ataques a la cadena de suministro de alto perfil últimamente). Sin embargo, como industria, no hemos aplicado ese conocimiento a las extensiones de navegador en la misma medida.
Lo que funciona para las dependencias también puede funcionar para las extensiones de navegador. El análisis de dependencias de software funciona porque la inteligencia de amenazas subyacente se mantiene actualizada, cotejando con bases de datos que se actualizan a medida que se descubren nuevas amenazas, en lugar de una lista compilada el trimestre pasado. El bloqueo previo a la instalación para las extensiones de navegador debe funcionar de la misma manera. Los ataques a la cadena de suministro se mueven rápido, y una lista de permitidos que era precisa el mes pasado no sabe que una extensión cambió de manos o recibió una actualización maliciosa la semana pasada.
Las organizaciones también necesitan visibilidad sobre lo que está instalado en cada dispositivo de desarrollador. Los gestores de paquetes dejan un rastro documental, como archivos de bloqueo y listas de dependencias que residen en los repositorios, pero las extensiones de navegador no disponen de ello. La única forma de saberlo es auditar activamente todos los dispositivos de la organización. No se pueden responder a amenazas cuya existencia se desconoce, y muchas empresas no cuentan con las herramientas necesarias para ello.
Finalmente, todos en una organización, desde ingenieros hasta RRHH, deben ser conscientes de los riesgos de las extensiones de navegador. Las vulnerabilidades de dependencias han recibido mucha atención mediática, pero la seguridad del navegador no tanto. Aunque la gente puede saber en general que no son ideales, a menudo no son tan conscientes de vulnerabilidades importantes como el robo de credenciales. Debemos educar a nuestros equipos y organizaciones sobre los riesgos y las mejores prácticas (por ejemplo, enviándoles este artículo).
Prevenir el próximo ataque a la cadena de suministro al estilo Vercel
La brecha de seguridad de Vercel no será el último incidente en el que una extensión de navegador forme parte de la cadena de ataque. La superficie de ataque es demasiado valiosa y los controles en los que confían la mayoría de las organizaciones son demasiado limitados para que esto cambie por sí solo. Trate la seguridad de las extensiones de navegador como el problema de la cadena de suministro que ya es, ojalá antes del próximo ataque (no después).
Aikido Endpoint aplica un modelo de seguridad de la cadena de suministro para proteger los dispositivos de desarrollador. Las extensiones maliciosas se bloquean antes de su instalación; las conocidas como maliciosas se cotejan con Aikido Intel antes de que lleguen al dispositivo. El feed de Aikido Intel que lo impulsa identifica hasta 100.000 paquetes maliciosos al día y es público y gratuito para explorar en intel.aikido.dev.
Obtenga más información sobre Aikido Endpoint o explore el feed de Aikido Intel para ver qué se ha detectado en los ecosistemas de código abierto en tiempo real.
