qBittorrent corrige discretamente un agujero de seguridad de hace 14 años

qBittorrent, una popular aplicación de intercambio de archivos peer-to-peer que existe desde 2006, ha estado aceptando casi cualquier certificado SSL en dominios y direcciones puestos en el componente DownloadManager de la aplicación durante más de 14 añosy ahora ha parcheado esa vulnerabilidad. El commit que creó el potencial agujero de seguridad se introdujo en abril de 2010, y era bastante simple; todo lo que hacía era cambiar el estado por defecto de la verificación SSL de activado a desactivado. Esto eliminó los molestos errores de seguridad, algo que potencialmente podría molestar a los usuarios y evitar que pudieran descargar contenidos de fuentes no verificadas. A partir del 28 de octubre de 2024 y de la versión 5.0.1, el estado por defecto vuelve a ser activado. Vale la pena señalar que qBittorrent no ofreció ninguna explicación para el cambio, y no notificó a los usuarios de ninguna manera especial, aparte de las habituales notas de parche que acompañan a las nuevas versiones.

Los certificados SSL son tokens de seguridad que hacen dos cosas: verifican que una fuente de tráfico web procede del sitio web del que dice proceder, y permiten que el contenido que llega a través de esa conexión esté encriptado. Dado que BitTorrent, como protocolo, se basa en la transferencia de archivos de igual a igual, es lógico que uno pueda estar recibiendo archivos perfectamente seguros desde el servidor doméstico de alguien, o incluso desde su PC, lo que significa que puede no estar debidamente equipado para ser el autor de un certificado SSL. Dejar esta comprobación desactivada permitiría a los usuarios comunicarse con tales fuentes y descargar desde ellas sin problemas.

La otra cara de la cuestión es que la falta de un certificado SSL, o la aceptación de uno ilegítimo, abre la posibilidad de que casi cualquier fuente de tráfico web de cualquier servidor se haga pasar por aquella a la que el usuario está intentando acceder. Esto, a su vez, permitiría a malos actores secuestrar el tráfico, posiblemente robando información de los sistemas anfitriones o de los sistemas de los usuarios, y posiblemente inyectando casi cualquier código que deseen. En muchos sentidos, este tipo de ataque man-in-the-middle elude muchas medidas de seguridad convencionales, como los cortafuegos, que de otro modo protegerían a los usuarios de los malos actores.

La configuración que rige si la aplicación aceptará una conexión sin realizar una verificación del certificado SSL sigue siendo accesible para los usuarios, por lo que aquellos que estén dispuestos a correr el riesgo pueden simplemente desactivarla. Por lo general, no se espera que el usuario medio de plug-and-play se sumerja en la configuración de la aplicación antes de utilizarla, o que sepa cómo funcionan los certificados SSL y qué riesgos se crean al dejar desactivado el ajuste, lo que hace que esta medida sea netamente positiva para la seguridad de las aplicaciones.