Se ha lanzado la versión del navegador especializado Tor Browser 11.0.2, centrado en garantizar la anonimidad, la seguridad y la privacidad. Al utilizar Tor Browser, todo el tráfico se redirige únicamente a través de la red Tor, y no es posible conectarse directamente a través de la conexión de red estándar del sistema actual, lo que impide rastrear la dirección IP real del usuario (en caso de que el navegador sea hackeado, los atacantes pueden acceder a la configuración de la red del sistema, por lo que para bloquear completamente posibles filtraciones se deben utilizar productos como Whonix). Las compilaciones de Tor Browser están preparadas para Linux, Windows y macOS.
Para garantizar una protección adicional, Tor Browser incluye la extensión HTTPS Everywhere, que permite utilizar la encriptación del tráfico en todos los sitios donde sea posible. Para reducir la amenaza de ataques que utilizan JavaScript y bloquear por defecto los plugins, se incluye la extensión NoScript. Para combatir el bloqueo e inspección del tráfico, se utilizan transportes alternativos. Para protegerse de la identificación de características específicas del visitante, se han desactivado o restringido las API WebGL, WebGL2, WebAudio, Social, SpeechSynthesis, Touch, AudioContext, HTMLMediaElement, Mediastream, Canvas, SharedWorker, WebAudio, Permissions, MediaDevices.enumerateDevices y screen.orientation, así como se han desactivado las herramientas de envío de telemetría, Pocket, Reader View, HTTP Alternative-Services, MozTCPSocket, «link rel=preconnect», y se modificó libmdns.
En la nueva versión se ha sincronizado con la base de código de la versión Firefox 91.4.0, en la cual se han corregido 15 vulnerabilidades, de las cuales 10 están marcadas como peligrosas. 7 vulnerabilidades son causadas por problemas de manejo de memoria, como desbordamientos de búfer y accesos a áreas de memoria ya liberadas, y potencialmente pueden llevar a la ejecución de código malicioso al abrir páginas especialmente diseñadas. De la compilación para la plataforma Linux se han excluido algunas fuentes ttf, cuya utilización provocaba la interrupción de la renderización del texto en elementos de la interfaz en Fedora Linux. Se ha desactivado la configuración «network.proxy.allow_bypass», que controla la actividad de protección contra el uso indebido de la API Proxy en extensiones. Para el transporte obfs4 se ha activado por defecto una nueva puerta de enlace «deusexmachina».
Mientras tanto, continúa la historia de bloqueo de Tor en Rusia. Roskomnadzor ha cambiado en el registro de sitios prohibidos la máscara de los bloqueados. dominios De «www.torproject.org» a «*.torproject.org» y se amplió la lista de direcciones IP que deben ser bloqueadas. Debido a este cambio, la mayoría de los subdominios del proyecto Tor quedaron bloqueados, incluyendo blog.torproject.org, gettor.torproject.org y support.torproject.org. Permanece accesible forum.torproject.net, que se aloja en la infraestructura de Discourse. Gitlab.torproject.org y lists.torproject.org están parcialmente disponibles, a los cuales inicialmente se les perdió el acceso, pero luego se recuperó, probablemente después de un cambio de direcciones IP (gitlab ahora está dirigido al host gitlab-02.torproject.org).
Al mismo tiempo, dejaron de registrarse bloqueos de puertas de enlace y nodos de la red Tor, así como del host ajax.aspnetcdn.com (CDN de Microsoft), utilizado en el transporte meek-asure. Al parecer, los experimentos de bloqueo de nodos de la red Tor cesaron después del bloqueo del sitio Tor. La situación es complicada con el espejo tor.eff.org, que sigue funcionando. La cuestión es que el espejo tor.eff.org está vinculado al mismo IP, que se utiliza para el dominio eff.org de la organización EFF (Electronic Frontier Foundation), por lo que bloquear tor.eff.org conducirá a un bloqueo parcial del sitio de esta conocida organización de derechos humanos.
Adicionalmente, se puede mencionar la publicación de un nuevo informe sobre posibles intentos de llevar a cabo ataques de de-anonimización de usuarios de Tor, vinculados al grupo KAX17, identificado por un correo electrónico de contacto ficticio específico en los parámetros de los nodos. Durante septiembre y octubre, el proyecto Tor bloqueó 570 nodos potencialmente maliciosos. En su punto máximo, el grupo KAX17 logró llevar el número de nodos controlados en la red Tor a 900, distribuidos entre 50 proveedores diferentes, lo que representa aproximadamente el 14% del total de relés (para comparar, en 2014 los atacantes lograron obtener el control de casi la mitad de los relés de Tor, y en 2020 del 23.95% de los nodos de salida).
La colocación de un gran número de nodos controlados por un solo operador permite la deanonimización de los usuarios a través de un ataque de clase Sybil, que puede llevarse a cabo si los atacantes controlan el primer y último nodo en la cadena de anonimización. El primer nodo en la cadena Tor conoce la dirección IP del usuario, y el último conoce la dirección IP del recurso solicitado, lo que permite deanonimizar la solicitud al agregar en el lado del nodo de entrada una cierta etiqueta oculta en los encabezados de los paquetes, que permanece inalterada a lo largo de toda la cadena de anonimización, y al analizar esta etiqueta en el lado del nodo de salida. Con nodos de salida controlados, los atacantes también pueden modificar el tráfico no cifrado, por ejemplo, eliminando redirecciones a las versiones HTTPS de los sitios y interceptando contenido no cifrado.
Según representantes de la red Tor, la mayoría de los nodos eliminados en otoño se utilizaban solo como nodos intermedios, no empleados para procesar solicitudes de entrada y salida. Investigadores individuales señalan que los nodos pertenecían a todas las categorías y la probabilidad de que un usuario se conectara a un nodo de entrada controlado por el grupo KAX17 era del 16%, y a un nodo de salida — del 5%. Pero incluso si esto es así, la probabilidad total de que un usuario se conecte simultáneamente a nodos de entrada y salida del grupo de 900 nodos controlados de KAX17 se estima en un 0,8%. No hay pruebas directas del uso de nodos KAX17 para llevar a cabo ataques, pero ataques similares no se pueden descartar potencialmente.
Fuente: opennet.ru
