[lacnog] Problema de seguridad en Junos e IPv6

JORDI PALET MARTINEZ jordi.palet en consulintel.es
Mie Ene 22 13:48:28 GMT+3 2020



El 22/1/20 17:31, "Fernando Gont" <fgont en si6networks.com> escribió:

    On 22/1/20 12:28, JORDI PALET MARTINEZ via LACNOG wrote:
    > Hola Fernando,
    >   
    > 
    > El 22/1/20 14:59, "Fernando Gont" <fgont en si6networks.com> escribió:
    > 
    >      On 22/1/20 09:30, JORDI PALET MARTINEZ via LACNOG wrote:
    >      > Hola Fernando,
    >      >
    >      >
    >      > El 22/1/20 12:34, "Fernando Gont" <fgont en si6networks.com> escribió:
    >      >
    >      > On 22/1/20 07:34, JORDI PALET MARTINEZ via LACNOG wrote:
    >      >> Jaja, no había visto la broma de Tomás ... ni que yo fuera el
    >      >> causante de todos los males de IPv6!
    >      >>
    >      >> Yo no concuerdo con Fernando. Eso depende de cada implementación,
    >      >> de cómo hace el fabricante su trabajo. Esta claro que todo es
    >      >> mejorable, pero también esta claro que IPv4 sigue teniendo muchas
    >      >> vulnerabilidades, que dependen tanto del protocolo como de las
    >      >> implementaciones de determinados fabricantes.
    >      >
    >      > Podes listarlas? Al menos 5? -- porque sino corremos el riesgo de
    >      > entrar en lo que en Maradonia conocemos como "vatir fruta
    >      > indiscriminada e impunemente" :-)
    >      >
    >      > No guardo registro de los emails que me llegan con vulnerabilidades,
    >      > fácil que varias cada mes, lo siento. Pero es fácil hacer una
    >      > búsqueda en google: "ipv4 vulnerabilities 2019".
    >      
    >      No veo una sola que tenga que ver con el protocolo ipv4.
    >      
    > Debe ser que las búsquedas desde diferentes partes del mundo arrojan resultados diferentes. Por citar algunos que a mi me salen (tal cual, y en el orden en que me salen), la primera media docena:
    > 
    > https://nvd.nist.gov/vuln/detail/CVE-2019-12664
    > https://nvd.nist.gov/vuln/detail/CVE-2019-12256?cpeVersion=2.2
    > https://www.cvedetails.com/cve/CVE-2019-15239/
    > https://www.cvedetails.com/cve/CVE-2019-11683/
    > https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10965
    > https://vulmon.com/vulnerabilitydetails?qid=CVE-2019-12256
    > 
    > Si lo he visto bien, son todas del ultimo trimestre de 2019 (las he abierto y visto muy por encima).
    
    Me refiero a que ninguna de ellas son vulnerabilidades del protocolo, 
    sino de implementaciones.

** precisamente, lo que dije desde el principio de este hilo es que las vulnerabilidades a veces dependen del fabricante (de una implementación especifica)
    
    En cuanto a las vulnerabilidedes en si, hay algunas que son de TCP mas 
    que de IPv6.
    
    Despues hay casos como este: 
    https://vulmon.com/vulnerabilitydetails?qid=CVE-2019-12256 , que son 
    verdaderamente pauperrimos, con vulnerabilidades sobre cuestiones de TCP 
    que son conocidas desde hace mas de 10 años.
    
    
    
    >      >> Ningún "software" se libra nunca de eso. Teóricamente a más años
    >      >> que pasen, menos vulnerabilidades pero la práctica a veces nos
    >      >> lleva la contraria.
    >      >
    >      > La superficie de ataque solo se incrementa si con el tiempo se
    >      > agregan mas features de lo que se remueven cosas.
    >      >
    >      > No sólo. A veces hay cosas que pasan desapercibidas, y por
    >      > investigadores, o combinaciones de diversas causas, incluso
    >      > casualidades, salen a flote.
    >      
    >      La posibilidad de que algo pase desapercibido con una tecnologia probada
    >      tanto tiempo en produccion como IPv4 es considerablemente menor que en
    >      el caso de ipv6, cuyo tiempo en produccion, comparativamente, es marginal.
    >      
    > Estadísticamente estamos de acuerdo, pero las cosas no siempre son "estadísticamente correctas"
    
    Bueno, tratandose de un ambito ingenieril uno apuntaria a manejarse en 
    base a estadisticas, no?  ;-)
    
** prefiero la experiencia (sin obviar las estadísticas)    
    
    
    >      > Reconocer problemas no implica dejar de lado. Por otro lado, no se
    >      > cual seria la logica de que lo que no aparece via IPv6 necesariamente
    >      > aparece en CGNs.
    >      >
    >      > Quizás no me explique bien. Quiero decir, que si no usas IPv6, vas a
    >      > tener que usar CGN. Y ello implica que ahí también hay posibilidad de
    >      > que surjan mas vulnerabilidades y problemas en general.
    >      
    >      El dispositivo donde aplica la vulnerabilidad es diferente. Si yo soy un
    >      banco, realmente me importa muy poco las vulnerabilidades que pueda
    >      tener el CGNAT que utiliza tu ISP para que vos puedas acceder a mis
    >      sistemas via IPv4.
    >      
    > Precisamente has puesto un ejemplo perfecto. No puedo hablar del caso, pero hubo un banco que sufrió una vulnerabilidad importante, cuando algunos ISPs del país en cuestión empezaron a usar CGN, y era fácil confundir sesiones de usuarios ... El software estaba mal hecho, si!, pero las vulnerabilidades no son otra cosa que software mal hecho.
    
    No usaba SSL el banco? :-)
    
    Sinceramente, dudo del caso. Y de existir, su problema no es cualquier 
    vulnerabilidad de CGNs, sino todo un conjunto de decisiones pauperrimas. 
    (como se "confundian las sesiones" con SSL?)
    
    
    > Hay que ver todo el contexto. Software es software, y los fallos se pueden producir en muchas partes de la cadena entre el usuario final y el proveedor del servicio.
    
    Una cosa es un fallo de conectividad --> que llegado al caso puede ser 
    una vulnerabilidad de DoS, en el caso de algun ISP especifico, y otra 
    distinta es hacer DoS al banco en si, o inclusive ganar acceso remoto al 
    mismo.
    
    
    
    
    >      > Muchos otros dispositivos (camaras IP, smart TVs, etc), nunca lo
    >      > harán.
    >      >
    >      > Bueno, yo mismo me sorprendo cada día en esto. Estoy haciendo un
    >      > trabajo de IPv6 para Consumer Electronics (CTA, la organización
    >      > responsable de CES, representando un negocio de 398 billones de
    >      > dólares en US) y me he encontrado con la información de un número %
    >      > impresionante de SmartTVs que desde hace 2 años tienen soporte IPv6
    >      > (lo he comprobado personalmente). Igualmente me ha pasado con cámaras
    >      > IP. Sin decir marcas, pero he comprado unas cámaras tipo dome con Pan
    >      > y Tilt y otras con PTZ, por unos 30 Euros cada una, y ambas tenían
    >      > IPv6 - y no eran últimos modelos, de hecho, eran un poco mas baratas
    >      > que las actuales del mismo fabricante (que ahora valen 50-55 euros) y
    >      > por eso eran mas baratas.
    >      
    >      No es el caso ni de Tp-link, ni de Genius, ni de Belkin, ni de....
    > 
    > Depende mucho del tipo de dispositivo, no podemos hablar de forma genérica.
    
    No encontré uno solo con soporte IPv6. Y en cierto sentido, enhorabuena! 
    Porque tienen diseños pauperrimos. -- asi que cuanto mas desconectados 
    estén, mejor :-)
    
    
    
    >      Tampoco lo soportan dispositivos smart-plugs ni de tp-link, ni de dlink,
    >      ni otros.
    >      
    >      Ni hablar de impresoras... q muchisimas de ellas no tendran ipv6 por el
    >      resto de sus vidas.
    > 
    > En cuanto a impresoras discrepo. He visto muchos fabricantes y modelos de impresoras con IPv6 desde hace mas de media docena de años.
    >      
    >      Tan asi es la cosa que el v6ops está proponiendo una optimizacion a
    >      464xlat por este motivo
    >      (https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-00)
    >      -- del cual sos co-autor ;-)
    > 
    > Obvio porque no todos los usuarios cambian su SmartTV ahora o hace 2 años cuando han empezado a salir con IPv6, si lo habían comprado justo hace 3 años. Y si le podemos dar solución es bueno para el despliegue de IPv6.
    
    Ese es el punto: la solucion se justifica si una proporción 
    mayoritaria/significativa de los smart TVs son IPv4-only.
    
    Podés ganar un argumento, o el otro -- pero no ambos ;-)
    
    
    
    
    >      Imagino que si el numero de smart tvs fuera mayoritariamente dual-stack,
    >      no estarian trabajando en eso ;-)
    >      
    > Los SmartTVs, los propios fabricantes se aseguran de que lo cambies con mas frecuencia, porque deja de funcionar hasta YouTube!
    
    Mala tactica: me dejo de funcionar el Youtube, pero le compre un bluray 
    de 50 USD, y uso los "smart" del bluray ("Sony, LTA")
    
    
    
    >      
    >      > De los SmartTVs y otros productos de consumo, no puedo desvelar
    >      > estadísticas de todos los tipos de aparatos que se han analizado. En
    >      > cuanto pueda lo hago. Pero insisto en que me ha sorprendido muy
    >      > gratamente, especialmente el crecimiento del año 2017, 2018 y 2019
    >      > respecto de años anteriores.
    >      
    >      El INDEC de Argentina tenia estadisticas satisfactorias, tambien.
    >      
    > Supongo que es algún organismo público ... como el INE en España. Lo menos fiable del mundo! Pero las estadísticas de una asociación de fabricantes es muy diferente.
    
    Donde está el URL describiendo la estadistica, y documentando el resultado?

Cuando pueda divulgarlo, lo hare, no lo dudes.
    
    Slds,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: fgont en si6networks.com
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    
    
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





Más información sobre la lista de distribución LACNOG