[lacnog] Utilización de DoH como canal encubierto para controlar Malware
Fernando Gont
fgont en si6networks.com
Lun Sep 7 16:48:07 GMT+3 2020
Hola, Raul,
Esas consideraciones, y otras, estan mencionadas en la pregunta 9
(pagina 7) de
https://www.internetsociety.org/wp-content/uploads/2019/03/deploy360-dns-privacy-faq-v1.1.pdf
Como menciona el documento, hay otras cosas a tener en cuenta, como ser
la jurisdiccion legal de la empresa que brinda el servicio de resolucion
de DNS.
También hay cuestiones de caracter operacional. Ejemplo: Supongamos que
un ISP tiene conexion a un IXP en el cual hay un cache de un proveedor
de contenidos. En la normalidad de los casos, el trafico de dicho
proveedor de contenidos se serviria desde el cache local. Sin embargo,
si la resolucion de DNS se hiciera mendiante un servidor externo
(incluyendo 8.8.8.8, por mas que no se use DoH), eso podria resultar en
que no se termine utilizando el cache, generando trafico internacional
para el operador -- con lo que esto significa. Por lo cual no me
sorprenderia que en consecuencia, el operador intentara filtrar DoH (no
por querer "espiar", sino por querer servir los contenidos de forma
local, en vez de usar un enlace internacional para ello).
En lo personal, desde el punto de vista del usuario, creo que la mejora
en materia de privacidad es, en el mejor de los casos, marginal.
En aquellos casos en los cuales a uno le preocupa la privacidad, no se
puede prescindir de una VPN -- en cuyo punto, la resolucion de DNS es
simplemente una funcionalidad mas provista por la VPN.
Mas alla de eso, creo que algunas de estas cosas, mas alla de las buenas
intenciones, a veces sufren de desconocer la realidad de aquellos que
suponen ser los beneficiarios de estas tecnologías. Por ejemplo, en
aquellos lugares donde existen problemas de censura o libertad de
expresión, el uso en sí de tecnologías de "privacidad" desata sospechas
en quienes ejercen la censura/control. -- algo así como una señal
deliberada de "Hola! Les estoy ocultando cosas!". En cuyos casos, este
tipo de estrategia no es la mas interesante.
Saludos,
Fernando
On 7/9/20 10:59, Raúl Echeberría wrote:
>
> Prefiero no opinar sobre el componente ético. Claramente la preocupación
> sobre Privacidad y el uso de DNS como una herramienta para el filtrado y
> la censura, fueron motivaciones válidas para estos desarrollos.
>
> Esto demuestra como, a veces, motivado por razones loables, se puede
> llegar a conclusiones erróneas. Son las famosas “consecuencias no
> deseadas”.
>
> El objetivo es bueno y compatible. El resultado no lo es tanto y abre
> más flancos que los temas que soluciona.
>
> A los puntos ya mencionados como preocupaciones yo le agregaría dos:
>
> - El efecto en la concentración de mercado (aún más) en la resolución de
> DNS. Le quita al DNS una de sus propiedades más ricas, que es la
> arquitectura distribuida. Aumenta la posibilidad de impactos mayores de
> las fallas (acuérdense del impacto del ataque a Dyn en 2016) y además si
> 2 o 3 empresas nuclean el 90% de las resoluciones de DNS, esto
> potencialmente genera el riesgo de oligopolios y la debilitación de los
> mecanismos multistakeholder de desarrollo de políticas para el DNS.
>
> - El riesgo de una respuesta de sobre-regulación por parte de algunos
> gobiernos, incluso los que no tenían intenciones de regular el uso del
> DNS para control de contenidos. Cuando los gobiernos terminen de
> entender que DoH les quita totalmente la posibilidad de controlar el DNS
> (aunque no pensaran utilizarlo para esos fines) puede generar un efecto
> opuesto al buscado.
>
>
>
> Saludos,
>
>
> Raúl
>
>
>
>> El 6 set. 2020, a las 18:29, Jorge Villa <villa en reduniv.edu.cu
>> <mailto:villa en reduniv.edu.cu>> escribió:
>>
>> Hola a tod en s, buenas tardes.
>> Espero esten muy bien, asi como sus familias y amistades.
>> Nico, gracias por traer DoH de vuelta al ruedo, esta vez con algo mas
>> de analisis en ese paper que nos compartes, y que luego Carlos estuvo
>> desglosando un poco, y Fernando agrego tambien.
>> La cuestion en si, es que cada vez es mas fina e indiscernible, la
>> linea entre privacidad y seguridad. Por tanto, es bastante facil
>> cometer “abusos” en uno y otro terreno, tratando de garantizar
>> seguridad o privacidad, según interese.
>> Sin embargo, lo que veo en este caso en particular de Mozilla, es que
>> la solución que dieron, crea problemas mas grandes que los que intentó
>> resolver. No puedes pretender garantizar la privacidad del trafico de
>> DNS de los usuarios, enviandolo de forma automatica y anonima hacia un
>> sitio de terceros (seleccionados unilateralmente); que aunque
>> supongamos sean los mas buenos y transparentes del planeta, nunca
>> firmaron (ni firmaran) un acuerdo de confidencialidad con los usuarios
>> cuya privacidad se trata de ayudar a proteger con esto.
>> De igual forma, al implementar esto, terminan alterandose diseños
>> operativos en las organizaciones que legitimamente tienen contrato con
>> los usuarios, y que ademas pueden tener repercusiones tanto en el
>> acceso a contenidos (cuando se trabaja con vistas, balanceadores, etc)
>> como en problemas relacionados con las normativas de seguridad que
>> existan en el pais donde se encuentre dicho usuario.
>> Si por demas, abre opciones geniales para los atacantes como ya nos
>> queda ilustrado (y que posiblemente muchas organizaciones ya esten
>> sufriendo)… pues creo que habria que pensar bien el alcance y el
>> empleo de estas tecnologias, antes de implementarlas, y si se hace,
>> creo que tiene que ser de manera consciente. La idea del post era
>> emplear DoH para ayudar a controlar el Malware; pero si quien recibe
>> el DoH no me muestra esa informacion (ni mis herramientas de seguridad
>> la pueden usar), simplemente lo que esta logrando esto es favorecer a
>> los atacantes.
>> Coincido contigo Nico, en que para el sector corporativo esto es muy
>> poco recomendable, y en el sector residencial, el 95% de los usuarios
>> (para ser conservador) no esta ni siquiera pendiente de si le mandan
>> las consultas de DNS a Google o a su ISP o a cualquier otra
>> organizacion. Simplemente les importa poder acceder a los servicios
>> que les gusta y punto.
>> Por tanto, me parece que este procedimiento de Mozilla no es nada
>> etico, y ciertamente no va a soluconar mayores problemas de privacidad
>> (según enienden los usuarios); pero abre una puerta bastante oscura a
>> la recoleccion de datos “de forma forzada” de usuarios de todo el
>> mundo, que pueden tener muchos usos; en los que la privacidad de los
>> usuarios va a terminar siendo violentada de formas insospechadas.
>> Como opcion tecnologica para quienes la quiera usar de forma
>> consciente, me parece bien (como tantas opciones que existen en todas
>> las aplicaciones y servicios que rara vez se usan); pero forzar su
>> uso, sin siquiera alertar a los usuarios, fatal. En teoria la
>> habilitacion de DoH en Mozilla iba a ser automatico solo en USA. En
>> Europa imagino se cuiden por cuenta de GDPR; pero que creen que pase
>> en nuestra región?
>> Saludos,
>> Jorge
>> *De: *LACNOG <lacnog-bounces en lacnic.net
>> <mailto:lacnog-bounces en lacnic.net>> en nombre de "Carlos M. Martinez"
>> <carlosm3011 en gmail.com <mailto:carlosm3011 en gmail.com>>
>> *Responder a: *Latin America and Caribbean Region Network Operators
>> Group <lacnog en lacnic.net <mailto:lacnog en lacnic.net>>
>> *Fecha: *viernes, 4 de septiembre de 2020, 5:55 p. m.
>> *Para: *Latin America and Caribbean Region Network Operators Group
>> <lacnog en lacnic.net <mailto:lacnog en lacnic.net>>
>> *CC: *Latin America and Caribbean Region Network Operators Group
>> <lacnog en lacnog.org <mailto:lacnog en lacnog.org>>
>> *Asunto: *Re: [lacnog] Utilización de DoH como canal encubierto para
>> controlar Malware
>> Hola a todos,
>> Si yo entiendo bien este escenario, en realidad lo que hizo Mozilla de
>> cambiar el default de hacia dónde van las consultas DNS (con lo que
>> discrepó totalmente) es solamente una capa mas en una ataque ya de por
>> si complejo.
>> El registro dns que se ve en el articulo sigue pudiendo ser consultado
>> incluso por “ye olde" plain text DNS
>> |$ dig txt dmarc.jqueryupdatejs.com <http://dmarc.jqueryupdatejs.com>|
>> ||
>> |; <<>> DiG 9.10.6 <<>> txt dmarc.jqueryupdatejs.com
>> <http://dmarc.jqueryupdatejs.com>|
>> |;; global options: +cmd|
>> |;; Got answer:|
>> |;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19013|
>> |;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1|
>> ||
>> |;; OPT PSEUDOSECTION:|
>> |; EDNS: version: 0, flags:; udp: 4096|
>> |;; QUESTION SECTION:|
>> |;dmarc.jqueryupdatejs.com <http://dmarc.jqueryupdatejs.com>. IN TXT|
>> ||
>> |;; ANSWER SECTION:|
>> |dmarc.jqueryupdatejs.com <http://dmarc.jqueryupdatejs.com>. 38400
>> IN TXT "v=DKIM1; k=rsa;
>> p=/NkBspI4LG64/nlEJ5sKjBiKA2L0Oi0B/TVRRNE5ESXpPRFk0T0E9PQ/mvYI54xdsqEmW/TVRRNE5ESXpPRFk0Tnc9PQ/TWpNNE9ETTN/TWpNNE9ETTNNVGszTkE9PQ/mvYI54xdsqEmW/TWpNNE9ETTNNakUwTXc9PQ/+ENwGoMUg9feAaD9qyw7KUEysv23BHGBHxInOA2FOhTOZrNWg7DQIDAQAB"|
>> ||
>> |;; Query time: 684 msec|
>> |;; SERVER: 200.7.84.14#53(200.7.84.14)|
>> |;; WHEN: Fri Sep 04 10:07:36 -03 2020|
>> |;; MSG SIZE rcvd: 307|
>> ||
>> Aca hay casi tantas capas como en una cebolla:
>>
>> * el uso de un nombre de dominio que se ve inocente, como
>> “jqueryupdatejs.com <http://jqueryupdatejs.com>” , cualquiera
>> diría que es el update de jQuery
>> * el uso de DNS como covert channel. Incluso si se usa DNS plano, a
>> menos que alguien esté minando datos de consultas DNS esto puede
>> demorar meses y meses en ser detectado
>> * el payload del DMARC record ya es, o al menos puede pasar como,
>> algo cifrado normal
>>
>> El DNS over HTTPS aca es una mas de esas capas, pero no es ni cerca el
>> unico ni el mas importante de los elementos aca.
>> Entiendo que lo que hizo Mozilla no esta bueno, esa es otra discusión
>> que me encantaría tuviéramos.
>> Abrazo y buen finde para todos.
>> /Carlos
>> On 4 Sep 2020, at 5:46, Roque Gagliano wrote:
>>> Nico,
>>> No hubo ni hay "discusión", Mozilla cambió el default y punto.
>>> Roque.
>>> On Thu, Sep 3, 2020 at 5:33 PM Nicolas Antoniello
>>> <nantoniello en gmail.com <mailto:nantoniello en gmail.com>> wrote:
>>>> Estimados,
>>>> Para que lo tengan en cuenta. En este caso, los sistemas de
>>>> detección de amenazas que puedan estar operando en las
>>>> organizaciones no serían capaces de detectar este tipo de ataques.
>>>> La forma de detectarlo sería (en principio) únicamente desde el
>>>> cliente con algún mecanismo de detección de Malware o similar.
>>>> Este trata de la utilización de respuestas DNS conteniendo código
>>>> para comandar y controlar un malware previamente instalado en el
>>>> cliente.
>>>> Lo interesante es que al valerse de DoX se vuelve mucho más
>>>> difícil su detección y por lo tanto es aprovechable por los
>>>> atacantes como mecanismo para intentar evitar sistemas de detección
>>>> que puedan utilizar las organizaciones.
>>>> En el artículo se menciona el hecho de que este tipo de ataques no
>>>> es nuevo; así como el hecho de que esto no es un problema propio de
>>>> DoX; sino que los atacantes se valen de la privacidad que provee DoX
>>>> para encubrir su tráfico.
>>>> https://www.bleepingcomputer.com/news/security/attackers-abuse-google-dns-over-https-to-download-malware/
>>>> Personalmente creo que agrega una consideración interesante en la
>>>> conversación sobre privacidad vs. seguridad a la hora de cada uno
>>>> decidir en qué ámbitos aplicaremos cada mecanismo; así como qué
>>>> medidas adicionales de seguridad (y privacidad) podemos tomar a
>>>> nivel operativo para buscar protegernos mejor de este tipo de amenazas.
>>>> Saludos,
>>>> Nico
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>>
>>> --
>>>
>>>
>>> At least I did something
>>> Don Draper - Mad Men
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>> _______________________________________________ LACNOG mailing list
>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion:
>> https://mail.lacnic.net/mailman/options/lacnog
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
--
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Más información sobre la lista de distribución LACNOG