Una página puede cargar código controlado por un atacante durante una visita normal. Si el navegador u otro componente tiene una vulnerabilidad, ese código puede intentar aprovecharlo sin pedirte que ejecutes un archivo. Es una posible vía de ataque, no el resultado de visitar cualquier página sospechosa: que funcione depende del fallo concreto y de las protecciones del navegador.
«Drive-by download» se utiliza a menudo en sentido amplio, pero entregar contenido y comprometer un dispositivo son pasos distintos. Una web puede intentar aprovechar un fallo del navegador sin avisar, o inducirte a aceptar una descarga, notificación o instalación. En la descripción de MITRE de los ataques drive-by, algunas variantes requieren que el usuario haga algo más. Este artículo se centra en los intentos que puede activar una visita si se llega a una función vulnerable.
Por qué no siempre hace falta hacer clic
Al navegar, una página puede cargar scripts, imágenes, tipografías y archivos multimedia. Según los ajustes del navegador y la propia página, los scripts pueden utilizar API gráficas, multimedia y WebAssembly. Procesar ese contenido podría alcanzar un fallo, aunque no hayas pulsado un archivo adjunto ni concedido otro permiso.
Un ataque necesita un fallo concreto y una acción que lo active. Entre los posibles objetivos están el motor de JavaScript, el código que dibuja las páginas y el procesamiento multimedia. Cargar una página no da privilegios de sistema a su script. Un fallo explotado con éxito puede permitir ejecutar código dentro del proceso afectado, sujeto a su aislamiento y a otras protecciones.
Los navegadores modernos separan las webs y restringen los procesos que muestran las páginas, como explica la documentación de Chrome sobre el aislamiento entre sitios. Comprometer uno de esos procesos no equivale a obtener control total del dispositivo. El atacante puede necesitar otro fallo para salir del entorno aislado o conseguir más privilegios. El análisis de Google de una campaña de 2024 documenta un fallo en el proceso de Chrome combinado con otro que permitía escapar del aislamiento. La cadena iba dirigida a ciertas versiones de Android sin parchear, no a todos los visitantes.
Qué componentes pueden tener fallos
Motores de JavaScript. V8 y SpiderMonkey incluyen compiladores y sistemas complejos de gestión de memoria. Un fallo puede provocar un comportamiento imprevisto dentro de un proceso del navegador. Normalmente ese proceso está limitado por el aislamiento del navegador: el código del motor no se ejecuta sin más con permisos ilimitados del sistema.
Gráficos. WebGL y WebGPU ofrecen funciones gráficas mediante API controladas por el navegador. Sus implementaciones y los controladores pueden contener errores, pero los shaders no llegan al hardware sin controles. Un fallo gráfico tampoco demuestra por sí solo que se pueda escapar del aislamiento.
Procesamiento de imágenes y multimedia.Los navegadores descodifican archivos complejos de páginas que no son de confianza. Un fallo en un descodificador podría ser explotable, pero el impacto depende del error y del proceso que trate el archivo. El aislamiento del navegador y del sistema operativo puede limitarlo. Un incidente en una aplicación de mensajería no demuestra la existencia de un exploit de navegador.
WebAssembly y workers. Permiten ejecutar código o realizar tareas en contextos separados, siempre dentro de las reglas del navegador. Utilizarlos no es, por sí mismo, un ataque. Sin embargo, un fallo de implementación o de un componente relacionado podría abrir otra vía a un atacante.
Cómo llega la página a tu pantalla
El contenido controlado por un atacante tiene que llegar al navegador. MITRE enumera entre las posibles vías los anuncios maliciosos, las webs comprometidas, los recursos de terceros modificados y los scripts o marcos insertados. Su frecuencia varía según la campaña; no hay una única vía dominante en todos los ataques drive-by.
Un anuncio malicioso puede introducir contenido no deseado en un espacio publicitario. En un ataque de tipo watering hole se compromete una web que visita un grupo elegido. Ninguno de los dos implica que todos los visitantes sean comprometidos: primero podrían comprobarse detalles del dispositivo o el navegador, y quizá haga falta otra acción. Para el caso de la publicidad, consulta nuestra guía sobre anuncios maliciosos.
En un caso documentado de 2024, varias webs gubernamentales de Mongolia comprometidas cargaban un iframe oculto controlado por los atacantes. El informe del Threat Analysis Group de Google describe cadenas de exploits diferentes para visitantes seleccionados con versiones afectadas de iOS o Android. Los fallos ya tenían parches: se explotaban en dispositivos que no los habían recibido o aplicado. El caso demuestra que una web de confianza puede servir de vía de entrada, no que cada visita a una web comprometida termine en una infección.
El plazo entre el parche y su instalación
Un parche publicado no protege a un navegador que sigue ejecutando una versión afectada. Los plazos dependen del proveedor, la plataforma, la compatibilidad del dispositivo y la política de actualizaciones; dar cifras fijas de horas o semanas sería engañoso. El caso de Google de 2024 muestra que fallos ya parcheados seguían siendo útiles contra determinados dispositivos sin actualizar.
Los atacantes pueden aprovechar un fallo conocido después de que exista un parche, lo que a veces se llama «n-day». También pueden usar un fallo antes de que haya parche: un «zero-day». El tiempo necesario para preparar un ataque funcional y el tiempo que los usuarios siguen expuestos varían mucho. Por eso conviene mantener al día el navegador y el sistema operativo y comprobar si hay actualizaciones pendientes de aplicar.
Las descargas automáticas ayudan, pero una actualización instalada puede necesitar un reinicio. La guía de actualización de Chrome explica cómo comprobar si queda pendiente volver a abrir el navegador. Los dispositivos administrados pueden seguir la política de despliegue de su organización. Comprueba la versión que se está ejecutando, sin dar por hecho que una descarga ya está activa.
Reducir la exposición y contener el daño
Los hábitos de navegación prudentes reducen la exposición, pero una web conocida también puede cargar contenido comprometido. Mantén actualizado el navegador, utiliza sus protecciones integradas y considera bloquear scripts o anuncios no deseados cuando tenga sentido. Un antivirus u otra protección del dispositivo puede detectar código dañino o un comportamiento sospechoso, pero no hay garantía. El aislamiento entre sitios y la sandbox del navegador añaden barreras si algo falla.
Con un navegador remoto como Browser.lol, el código de la página se ejecuta en un contenedor alejado de tu navegador local. Eso cambia el primer entorno que encuentra un posible exploit, y puedes terminar la sesión cuando ya no la necesites. No demuestra que tu dispositivo o tus cuentas estén a salvo: los archivos descargados, las credenciales que introduzcas, el portapapeles, las transferencias de archivos y la infraestructura del servicio abren otras vías. Mantén al día los navegadores locales y remotos y trata los archivos con cuidado. Para distinguir los fallos corregidos de los que aún no tienen parche, consulta nuestra guía sobre vulnerabilidades zero-day.
¿Necesitas una sesión aislada para tu próxima tarea?
Abre un navegador aislado desde el que ya usas y ponte manos a la obra.
Iniciar una sesiónSin instalar otro navegador • Las funciones dependen del plan
