Nunca instalarías una aplicación que pudiera iniciar sesión en tus documentos de Google, leer las pulsaciones de teclas en tu navegador, interceptar solicitudes en tránsito, ejecutarse de forma continua, actualizarse de forma silenciosa Y que pudiera 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 van más allá de un solo ordenador o incluso de una sola empresa.
Hace unos meses, un empleado de Vercel instaló la extensión para el navegador Context.ai, relativamente nueva y popular, que ofrecía una «suite ofimática con IA». Para conectarse a las aplicaciones, era necesario conceder permisos OAuth, por lo que, cuando la pantalla de permisos le pidió que autorizara el acceso de la herramienta a su cuenta de Google, hizo 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 un programa de descarga de trucos para Roblox que contenía un programa de robo de información. Ese malware, denominado « », localizó el token OAuth de Vercel, que se convirtió en el punto de entrada para un ataque a gran escala contra Vercel. El atacante no tuvo que piratear Vercel, sino que bastó con que pirateara la startup de IA a cuyo software un empleado de Vercel ya le había proporcionado las claves de acceso.
Un programa malicioso robó datos recopilados a través de una extensión de navegador en segundo plano. ¿Te suena este patrón? Parece un ataque a la cadena de suministro, y eso es precisamente lo que es.
Por qué la brecha de seguridad 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 el ámbito de la seguridad empresarial, y la brecha de seguridad de Vercel no es más que el último ejemplo. El ataque siguió un patrón que el sector de la seguridad conoce bien en el caso de las dependencias de código abierto, en las que se confía implícitamente en cierto código de terceros que luego se ve comprometido en una fase anterior. Tenemos un nombre para ese patrón y toda una categoría de herramientas desarrolladas en torno a él, pero el sector en su conjunto aún no las ha aplicado a las extensiones de navegador.
Un ataque a la cadena de suministro tiene varios elementos clave. Se necesita código de terceros que se ejecute con privilegios reales, confianza implícita y víctimas que no tengan una relación directa con el origen de la vulneración inicial. La brecha de Vercel cumple estos tres requisitos. Context.ai era un producto real que realizaba una tarea real, y el acceso OAuth que se le había concedido a Google Workspace era una solicitud razonable para lo que pretendía hacer (aunque podría decirse que se le concedió demasiada confianza y poder). Eso significaba que un token OAuth con amplios privilegios se encontraba en el backend de AWS de Context.ai, a solo un dispositivo de un empleado comprometido de convertirse en propiedad de un atacante.
Cuando ese empleado de Context.ai instaló un programa de robo de información en su propio ordenador, la confianza que un solo empleado había depositado en una extensión que antes era legítima se convirtió en la vía de acceso a sus entornos internos. La filtración original se produjo en otro lugar, pero Vercel fue la que pagó 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 seguridad de Cyberhaven a finales de 2024 fue una versión específica de un escenario similar, en la que los atacantes se centraron específicamente en extensiones dirigidas a desarrolladores. La propia extensión de Chrome de Cyberhaven se vio comprometida a través de un ataque de phishing a una cuenta de desarrollador, y se envió una actualización maliciosa a los usuarios antes de que nadie se diera cuenta. La versión maliciosa estuvo activa durante aproximadamente 24 horas.
El modelo de actualización silenciosa supone un mayor riesgo
El modelo de actualización de las extensiones resulta un poco preocupante si se analiza desde el punto de vista de la seguridad. A diferencia del software del sistema operativo, las extensiones del navegador se actualizan de forma silenciosa y automática. Es posible que el código que se ejecuta hoy en tu navegador no sea el de 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 ningún aviso para solicitar el consentimiento del usuario para la actualización. La única ocasión en la 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 todos los usuarios que la tengan instalada la recibirían automáticamente. Si ya tenía muchos permisos, estás en problemas. Imagina que las dependencias de software se actualizaran automáticamente y de forma silenciosa en tu máquina de desarrollo.
Lo que no ha funcionado
Las empresas suelen intentar crear listas de extensiones permitidas (bloqueando todo lo demás) o, por el contrario, listas de extensiones bloqueadas. Sin embargo, en ambos casos, mantener la lista actualizada y bien gestionada presenta algunas dificultades evidentes. Aproximadamente la mitad de los autores de extensiones son desconocidos, y la mayoría de los editores solo han publicado una extensión, por lo que gestionar las extensiones basándose únicamente en su reputación solo funciona para una pequeña parte de ellas. De todos modos, incluso las grandes empresas publican extensiones que no son del todo impecables. Mantener manualmente una lista interna precisa y actualizada es imposible.
SCA se creó para resolver este problema en el ámbito de los paquetes. Los mecanismos que se aplican a las dependencias de código abierto se basan en lo que hace el paquete (no en su nombre ni en la funcionalidad que declara). Aprobar paquetes de npm basándose únicamente en su nombre, sin análisis de código ni inteligencia de amenazas, no se consideraría una medida de seguridad de la cadena de suministro para las dependencias. Pero si sustituimos «paquete de npm» por «extensión de Chrome», ese es, más o menos, el enfoque que se ha adoptado en materia de seguridad de los navegadores en los últimos años.
Tratemos las extensiones de navegador como cualquier otro vector de la cadena de suministro
Aunque las tiendas de aplicaciones no lo reflejen, confiar en el momento de la instalación no es suficiente. Debemos aplicar aquí la misma filosofía que seguimos en materia de seguridad de los paquetes. Las organizaciones deben saber qué hay instalado en todos los equipos y necesitan monitorización continua que no se les pase por alto una extensión que, aunque parezca limpia, acabe volviéndose maliciosa.
La mayoría de los equipos de seguridad son capaces de definir un modelo de amenazas de la cadena de suministro para las dependencias. Saben que las cuentas de los mantenedores pueden verse comprometidas y que un paquete que estaba limpio el trimestre pasado puede convertirse hoy en un vector de ataque (y ataques a la cadena de suministro hemos visto muchos ataques a la cadena de suministro de gran repercusión ataques a la cadena de suministro ). Sin embargo, como sector, 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. análisis de dependencias de software análisis de dependencias porque la inteligencia de amenazas subyacente inteligencia de amenazas actualizada, comparando los datos con bases de datos que se actualizan a medida que se descubren nuevas amenazas, en lugar de con una lista que alguien recopiló el trimestre pasado. El bloqueo previo a la instalación de las extensiones de navegador debe funcionar de la misma manera. ataques a la cadena de suministro rápidamente, y una lista de permitidos que era precisa el mes pasado no tiene en cuenta que una extensión haya cambiado de manos o haya recibido una actualización maliciosa la semana pasada.
Las organizaciones también necesitan saber qué hay instalado en todos los dispositivos de los desarrolladores. Los gestores de paquetes dejan un rastro documental, como archivos de bloqueo y listas de dependencias que se almacenan en los repositorios, pero las extensiones de navegador no lo hacen. La única forma de saberlo es auditar activamente todos los dispositivos de la organización. No se puede responder a amenazas cuya existencia se desconoce, y muchas empresas no cuentan con las herramientas necesarias para hacerlo.
Por último, todos los miembros de una organización, desde los ingenieros hasta el departamento de RR. HH., deben ser conscientes de los riesgos que entrañan las extensiones de navegador. Las vulnerabilidades de las dependencias han recibido mucha atención mediática, pero no tanto la seguridad de los navegadores. Aunque la gente suele saber que no son muy seguras, a menudo no es tan consciente de vulnerabilidades graves como el robo de credenciales. Debemos informar a nuestros equipos y organizaciones sobre los riesgos y las mejores prácticas (por ejemplo, enviándoles este artículo).
Evita 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 como para que eso cambie por sí solo. Hay que abordar la seguridad de las extensiones de navegador como el problema de la cadena de suministro que ya es, ojalá antes del próximo ataque (y no después).
Aikido Endpoint aplica un modelo de seguridad de la cadena de suministro para proteger los dispositivos de los desarrolladores. Las extensiones maliciosas se bloquean antes de su instalación; las que se sabe que son maliciosas se comparan con la base de datos de Aikido Intel antes de que lleguen al dispositivo. La base de datos de Aikido Intel que lo alimenta identifica hasta 100 000 paquetes maliciosos al día y es pública y de libre acceso en intel.aikido.dev.
Obtén más información sobre Aikido Endpoint o explora el feed de Aikido Intel para ver en tiempo real qué se ha detectado en los ecosistemas de código abierto.
