Debilidad TCP/IP con kernel superior al 3.6 y como arreglarla

[h]La nueva implementación TCP/IP propia a Linux para hacer este protocolo más seguro ha creado una debilidad de un tipo nuevo[/h]

En 2010 unos investigadores de Cisco y Huawei pusieron el dedo en una debilidad del protocolo TCP/IP que presentaron con todos detalles:
[list=*]
] RFC 5961 - Improving TCP’s Robustness to Blind In-Window Attacks de A. RAMAIH, R.STEWART y M.DALAL @ IETF/]
[/list]
Demostraron que había que modernizar el protocolo para prevenir la inyección de paquetes TCP “spoofed” (paquetes ilegítimos que parecen venir de una fuente legitima)
Así que los de Linux se pusieron mano a la obra y “mejoraron” el protocolo a partir del kernel 3.6 (salido en 2012)
Fueron los únicos en tomarse en serio (cómo se debía) esta vulnerabilidad; mac y windows se quedaron con su vieja implementación débil.

Desgraciadamente, fortaleciendo el protocolo por un lado, crearon una debilidad por otro…
…Lo importante es que ahora se sabe gracias a este trabajo:
[list=*]
]Off-Path TCP Exploits: Global Rate Limit Considered Dangerous de Yue CAO, Zhiyun QIAN, Zhongjie WANG, Tuan DAO, Srikanth V. KRISHNAMURTHY y Lisa M. MARVEL @ Univerity of California Riverside/]
[/list]

Es posible forzar la de-conexión entre un servidor y el cliente usando los bytes SYN o RST de un paquete TCP “basura” (ilegitimo que inyectamos en una comunicación)
Hablamos de un ataque de tipo DoS nuevo que no toma mucho tiempo de poner de pie y con muy buenos resultados.

Los investigadores hicieron pruebas con TOR y vieron que podían impedir el acceso a un nudo.
Cuando usamos TOR, pasado un tiempo, si un nudo no funciona se pasa por otro.
Podemos imaginar que un “intruso” tenga un nudo bajo su control.
En este caso tendría que des-autenticar su victima hasta que llega a conectarse al servidor que tiene bajo su control.
Podría así hacer que la red ToR no sirve de nada para el “anonimato” de su victima.

Detrás de una DOS llevada acabo con éxito existe la posibilidad de hacer llegar el cliente sobre un pagina falsa que controla el intruso y hacer pishing.
Los investigadores combinaron estas dos técnicas contra un móvil Android conectado al sitio de USA today y lograron hacerlo llegar a un pagina falsa para que entre los credenciales
de su cuenta
¡Ojo!
Hay que relativizar de inmediato esta demostración ya que el sitio de USA today no utiliza https
¡Increíble! :smiley:
Sabemos que es muy fácil engañar a alguien sobre una pagina falsa htpp porque, además de no cifrar las comunicaciones, no permite verificar la autenticidad de un sitio visitado.
Todos los sitios correctamente administrados que manejan información personal llevan https.

En todos casos nunca es bueno que se pueda hacer DOS y hay que mejorar esto.

[h]Solución[/h]

Los investigadores han propuesto a los desarrolladores de Linux una solución muy interesante que consiste en producir ruido para impedir a un intruso de llevar acabo su ataque.
Sino otra opción es deshabilitar el challenge basado en la cuenta de paquetes ACK.
El punto negativo de esta solución es que este challenge tiene virtudes si no nos focalizamos solo en la debilidad que puede ocasionar,
Con lo cuál no sería nada mal adoptar la idea de une contra-medida algo ofensiva que impide el ataque falseando los resultados sin abandonar el concepto de global challenge ACK count
“Deshabilitar” el challenge es muy fácil y lo podemos hacer nosotros mismo con un truco simple:
[list=1]
]Abrimos con un editor de texto y derechos de administrador el fichero de configuración /etc/sysctl.confsudo gedit /etc/sysctl.conf/]
]Añadimos esta linea net.ipv4.tcp_challenge_ack_limit = 999999999/]
]Guardamos los cambios y activamos la nueva configuración con sudo sysctl -p/]
[/list]
No hemos realmente deshabilitado nada pero hemos puesto un limite tan alto al numero de paquetes ACK aceptados que nunca se activara.
Es un parche sucio pero eficaz propuesto aquí:.
[list=]
]Linux TCP flaw lets ‘anyone’ hijack Internet traffic de ** Steven J. VAUGHAN-NICHOLS* @ ZD-NET/
]
[/list]
Podemos también esperar tranquilamente que salga el arreglo en Linux y no hacer nada
Si por mucha mala suerte somos victimas de una DOS montada en base de esta vulnerabilidad, pues, no podremos conectarnos correctamente al sitio.
Lo del ataque DOS + pishing mediante un sitio http es un riesgo que existe sin o con esta debilidad,
Entrar datos sensibles en un sitio http es una cosa peligrosa de por si y nunca se debería hacer.