¿Merece la pena el esfuerzo de crear extensiones maliciosas? Por supuesto. El navegador es la aplicación estrella del sistema. Disponer de la capacidad para leer el código fuente de una página, manipular su comportamiento y usar la capacidad de cómputo y comunicaciones… es un caramelo demasiado dulce como para dejarlo pasar. Así, tenemos la experiencia de extensiones maliciosas que inyectan publicidad, manipulan resultados de búsqueda, roban credenciales de los formularios, rastrean el comportamiento de los usuarios, inyectan más publicidad o, por supuesto, minan criptomonedas.
Extensiones con malos propósitos podemos encontrarlas en todos los navegadores, pero sin duda es el navegador Google Chrome en el que se enfoca buena parte de esta forma de encarnación del malware. Una de las razones, como ocurre en su Google Play, es evitar la fricción con el desarrollador: no se le exige demasiado para publicar, y tampoco se revisa demasiado lo publicado para agilizar todo el proceso. El precio a pagar es plataformas oficiales donde prolifera el malware. Pero hay que reconocer que se van dando pasos de cara al endurecimiento de reglas o aplicación de restricciones para evitar encontrar una extensión dañina en el Store, o el potencial daño que puedan causar una vez instaladas.
El pasado abril, el equipo de Chrome vetó el uso de scripts de minado en las extensiones. La fiebre del oro virtual estaba en auge y raudos y veloces, los desarrolladores con menos pudor se apresuraron a flirtear con los ciclos de la CPU de sus usuarios, ajenos al favor que le hacían a otros. Google se cargó de un plumazo toda extensión que ejecutara minería. No en vano, según ellos, el 90 % de las extensiones con este propósito no informaba deliberadamente a los usuarios. Un golpe necesario para detener los crecientes abusos.
En mayo, llegaría una nueva medida: el aislamiento de iframes lanzados por la extensión. Y es que una extensión podía llegar a convertirse en maliciosa sin realmente serlo. Siempre existe la opción de que la extensión pueda lanzar y cargar un iframe con contenido externo, y esto podría ser aprovechado para manipular el espacio de la extensión con scripts cargados del exterior. Con el aislamiento de los iframes cargados por la extensión, se intenta aislar estos subprocesos de la misma forma que la relación entre las páginas y extensiones. Recordemos que desde la versión 56, Chrome ya aísla a su vez el proceso que carga una web del proceso de la extensión. Se diferencian así los ámbitos de trabajo y no se permite el abuso en ninguna de las direcciones.
Otra vuelta de tuerca fue dada en junio, cuando se prohibió la instalación de extensiones fuera del mercado de aplicaciones para Chrome. Se intentaba así cerrar el paso al malware que entraba con el alojamiento de extensiones en sitios de terceros. A partir de ese mismo mes, una extensión agregada por un dominio externo a la Chrome Web Store debía ser instalada a través del canal oficial. Ya sabemos que la web está llena de sitios que desean instalar «codecs» ,»visores de archivos», o incluso «¡drivers!» que no son otra cosa que extensiones de Chrome maliciosas disfrazadas de plugins «muy necesarios» para poder continuar la navegación o descargar un contenido. Algo que los navegantes con experiencia pueden rememorar con aquellas instalaciones torticeras de barras del navegador con supuestas «funcionalidades» imperdibles.
 |
| Claro ejemplo de extensión falsa para Chrome. Fuente: Fossbytes |
Siguiendo la estela de mejoras de seguridad respecto de las extensiones, el equipo de Chrome prepara un paquete de nuevas medidas para complicarle algo más la vida a las extensiones maliciosas. Por fin, se adopta una granularidad muy necesaria en los permisos por sitio a los que deseamos que una extensión pueda tener acceso. Hasta ahora, cuando dábamos permiso a una extensión para “leer y escribir” en el contenido web, este permiso era universal; un asterisco que arrojaba un preocupante exceso de confianza.
Desde la versión venidera de Chrome 70, se podrá seleccionar de forma más específica qué dominios puede actuar con la extensión e incluso, más allá, podremos autorizar a la extensión de forma expresa solo cuando pulsemos en su icono. Un filtro muy necesario, tanto por la contención de daños como por la siempre necesaria privacidad.
También cambia el proceso de revisión de aquellas extensiones que requieran permisos importantes o amplios. A partir de ahora, es una promesa (que ya se verá si se cumple), este tipo de extensiones pasarán un filtro de revisión más profundo. Suponemos que además del automatizado, se las verá ante el juicio de un revisor humano. Lo podremos deducir por los tiempos de espera en cuanto a las aprobaciones para salir en el Store.
Otra nueva medida, (curiosa e interesante), es la prohibición de ofuscar el código que porten (o descarguen) las extensiones. Obligatorio para nuevas extensiones y periodo de gracia de 90 días para las ya publicadas, que serán volatilizadas del market si no incluyen el código fuente sin ofuscar.
Según el equipo de Chrome, el 70 % de las extensiones maliciosas tienen el código ofuscado. Así que ellos consideran que si el código está ofuscado es probablemente porque el creador no desea que la verdadera intención del código pueda ser derivada de su estudio. Además, alegan que el código ofuscado interfiere con los nuevos procesos de revisión; reforzando así nuestra premisa de revisor humano en ciertas extensiones.
Si el lector ha estado atento habrá comprobado que se ha mencionado «porten o descarguen». ¿Se refiere a que Chrome enviará a análisis el código descargado por las extensiones cada vez que difiera del almacenado en caché? Esta opción es interesante, puesto que una extensión puede contener un mínimo de funcionalidad en el market, pasar los filtros, y delegar la carga en scripts externos que sí posean comportamiento indeseable. De este modo, se estaría vigilando la modificación de ese comportamiento dinámico de la extensión.
Es importante en este punto hacer una distinción entre ofuscamiento del código (dificultar su entendimiento, análisis, etc) de su «minificación» (manipular el código para optimizar su ejecución y peso). El primero se prohíbe, el segundo se promociona y desea.
Además de todo esto, los desarrolladores deberán adoptar la autenticación con segundo factor. Será un requisito obligatorio para 2019. Ningún desarrollador podrá loguearse con solo el tándem usuario y contraseña. Un clarísimo movimiento ejecutado para dificultar el hackeo de cuentas de desarrolladores que permita a un atacante insertar código malicioso en extensiones ya publicadas, algo que ha pasado en forma de phishing masivo en al menos dos ocasiones en el último año.
¿Son suficientes estas medidas? La experiencia nos dice que la creatividad se hace fuerte cuantas más restricciones le sean impuestas. El gato ha dado un paso hacia delante, le toca mover al ratón. Estaremos atentos para ver qué contramedida se tercia. Por cierto, si en lo que análisis de extensiones se refiere aun no la has usado, nuestra herramienta NETO es una auténtica navaja suiza para ayudarte en tus análisis. Pruébala.
