Investigadores de la Universidad de California y del US Army Research Laboratory, han descubierto un fallo crítico en la implementación del Transmission Control Protocol (TCP) en sistemas Linux.
TCP sirve para empaquetar e intercambiar datos entre diferentes ordenadores a través de internet, asegurando que la integridad de los mismos permanezca intacta. No solo navegadores web (HTTP/HTTPS) sino también clientes FTP y otros servicios (SSH, Telnet, Bittorrent, IRC, XMPP, etc.) son los que utilizan este protocolo.
La vulnerabilidad (CVE-2016-5696) que se da en kernels con versión 3.6 o superior (a partir de 2012 aprox.), permite inyectar código malicioso o terminar una conexión entre dos partes de forma remota, lo que puede tener graves consecuencias para la seguridad en internet.
Los investigadores detectaron que un ataque de tipo lateral era capaz de predecir los números de secuencia TCP utilizados para la identificación entre partes, aprovechando el límite de caracteres ACK (100) que introdujo Linux 3.6.
Algo que podéis comprobar con este comando:
cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
Fue una medida para mejorar la mejorar la seguridad de TCP contra determinados ataques, pero dejo la puerta abierta a que un atacante pueda establecer conexiones simplemente conociendo la IP del cliente y del servidor.
Como consecuencia de eso, se podría debilitar la capacidad de anonimato de redes como Tor facilitando el rastreo de sus usuarios.
También permitir el secuestro de conexiones web inyectando material falso en una página. Algo que se puede hacer en menos de un minuto, tal como podemos observar en este vídeo:
Las posibilidades de éxito del ataque –que no precisa ningún MITM con servidores por medio– oscilan entre el 88-97 % dependiendo de las condiciones del mismo y es especialmente preocupante debido a que la mayoría de servidores en internet ejecutan Linux.
Los usuarios de Android también se verían afectados, al igual que multitud de aparatos inteligentes (smartTVs por ej), así como los que usamos cualquier distribución GNU/Linux más o menos reciente.
Versiones del kernel a partir de 4.7 (que establece un límite ACK superior, de 1000) no se ven afectadas por esta vulnerabilidad
La gente del núcleo ya está trabajando en una solución a este error en versiones previas. Se han propuesto varias medidas temporales para evitar cualquier posible ataque, como aumentar el ratio ack en el archivo de configuración de sysctl. En todo caso lo más recomendable, es esperar unas horas a que lleguen los parches a nuestra respectiva distro
Señalar que este fallo no afecta a otros sistemas operativos como OS X o Windows.
Tenéis más información sobre el tema en el paper donde se da a conocer la vulnerabilidad.
Vía | Ars Technica
por suerte ahora que esta descubierto, no tardara en estar parcheado. ventajas del FOSS 😀
En pocas horas comienzan a aparecer articulos sobre lo peligroso e inseguro que es GNU/Linux…….. pero antes de ello ya tendremos la solucion. Claro que esa segunda parte no aparecera en los medios.
Exácto.
Y no estaría mal que aparezcan. Nada es seguro.
Mis saludos, y respetos amigo colega. el articulo te quedo de lujo. Bien detallado y acorde a todos los niveles de lectores. Como siempre un gusto pasar por tu blog a leer.
Gracias amigo @Anger
Como siempre tann….a la vanguardia.
Felicitaciones colega!
Bah, casualidad, pasaba por allí XD
Gracias a ti por pasarte y comentar!
Vamos a morir todooooooooooooooooooos, CORRED INSENSATOOOOOS!!!!!!!!!!!!!!
Estas movidas siempre se dan en estas fechas…¿casualidad? yo no lo creo!
Y aún faltan los típicos troyanos de verano, que ni son troyanos ni son nada (hoy ya vi uno que apuntaba a servidores Redis, aunque a mi me parece más una feature que un malware XD)
Desde que el kernel 3.6 comenzó a navegar por el mundo Linux ha pasado mucha agua por el Ebro y ¿Se dan cuenta ahora?. Pues menos mal que algunas cosas están encerradas bajo 7 llaves y no es tan fácil sacarlas a la luz. Desde donde yo estoy editando ahora mismo está pìrulando el kernel Linux 4.6.4-1-ARCH #.
Andamos iguales, en seguida comprobé en Antergos y tengo la misma versión
Acabo de leer en Linux Adictos que el kernel Linux le dará soporte a Surface de Microsot. Je, je, os imagináis lo que podría llegar a liarse.
«Versiones del kernel a partir de 4.7 (que establece un límite ACK superior, de 1000) no se ven afectadas»
sapeee,,,..
Te felicito por la información que das de primera mano. Espero que resuelvan pronto con un parche. ¡¡enhorabuena!!
Gracias @Antonio.
Están cocinando el parche, pero todavía el backport todavía no ha llegado a las principales distros (quitando rolling tipo arch, que ya han metido kernel 4.7.1)
Por ejemplo Debian, a la hora de escribir esto todos los kernel son vulnerables
https://security-tracker.debian.org/tracker/CVE-2016-5696
Solo un comentario, mi versión del kernel de linux es 3.2 y al realizar la comprobación (cat /proc/sys/net/ipv4/tcp_challenge_ack_limit) el límite del ACK también se encuentra en 100.
Al comprobar directamente en la página del nist del CVE indica claramente: que afecta a versiones anteriores al kernel 4.7:
«net/ipv4/tcp_input.c in the Linux kernel before 4.7 does not properly determine the rate of challenge ACK segments, which makes it easier for man-in-the-middle attackers to hijack TCP sessions via a blind in-window attack.»
No veo dónde aparece ese kernel 3.6 que se comenta en la noticia. Así pues, al menos en Debian, el límite del ACK a 100 es como mínimo a partir de la versión del kernel 3.2.
@Adrian El cambio en ACK fue introducido en Linux 3.6, lo que pasa es que Debian lo heredó a posteriori en una actualización de la rama 3.2.x , con lo cual como tu bien dices también está afectada.
Manjaro Linux a actualizado la rama 4.4 (4.4.17-1-Manjaro), pero no veo cambios en tcp_input.c …
cat /proc/sys/net/ipv4/tcp_challenge_ack_limit, sigue devolviendo el valor 100.
Alguien sabe en que consiste el patch …
Aún no hay un parche para los kernels con ese fallo, así que una de dos, o cambias el valor directamente en el sysctl.conf que es lo que he hecho yo en mi servidor con Debian 8.5 y ya está, o aprovechando que estás usando manjaro, cambias al kernel 4.7 (se puede con una interfaz gráfica) que no tiene el bug.
Una posible solución de momento en que se arregla el problema seria:
Aumentar el Challenge ACK Limit a un valor más grande.
Esto funciona en Debian y derivados.
#echo «net.ipv4.tcp_challenge_ack_limit=999999999» >> /etc/sysctl.conf
#sysctl -p #Aplicando cambios sin nececidad de reiniciar el equipo.
Saludos!! 😀