Protegerse de la falsificación de DNS

Detectar el uso de un certificado válido pero comprometido de alguna manera es difícil:

• Si el sitio de destino tiene sus claves privadas robadas y aún no se dio cuenta, el atacante podría falsificar el sitio a la perfección, es decir, el cliente no notará la diferencia con el sitio original.
• Si el sitio le robaron la clave privada y se dio cuenta de ello, debería revocar el certificado. En teoría, el navegador verificará si el certificado fue revocado y se negará a conectarse en este caso. Pero en la práctica no se puede confiar realmente en esta verificación, excepto en casos especiales (como certificados EV o sitios considerados importantes por el proveedor del navegador), ya que los navegadores no realizan ninguna verificación de revocación con OCSP o ignorarán los errores durante la verificación. los errores pueden ser causados por el atacante.
• Si un atacante logró obtener un certificado de confianza pública para el sitio (por ejemplo, adquiriendo el DNS del sitio el tiempo suficiente para obtener dicho certificado, consulte problema reciente con Fox-IT ) también es difícil para el cliente detectar esto como un problema ya que el uso de un nuevo certificado podría ser realmente válido. Los proyectos como Convergence pueden ayudar en este caso porque permiten detectar si otros usuarios ven un certificado diferente para el mismo sitio. Además, la fijación de certificados (HPKP) utilizada por el sitio en sí puede ayudar.

Dado que la detección del uso del certificado incorrecto es imposible en muchos casos, esto deja solo la detección de la falsificación del DNS:

• El monitoreo de IP como usted sugirió podría ayudar a detectar si el atacante está usando una IP de destino muy diferente de la que usualmente usa el sitio original. Tenga en cuenta que esto no ayuda contra la falsificación de ARP en redes locales o en todo el Internet BGP redirects ya que la IP de destino no se cambia necesariamente en este caso, solo se redirige.
• Si el sitio admite DNSSec, debe usarse para verificar cuál es la IP real. Por supuesto, esto solo ayuda contra la falsificación local y no si el servidor DNS primario para el dominio fue pirateado.
• Si el destino no emplea DNSSec, puede ser útil solicitar un servidor DNS que no esté afectado por la falsificación de DNS (local). Por ejemplo, uno podría usar DNS sobre HTTPS para que el atacante no pueda falsificar estas respuestas DNS también. Por supuesto, un atacante podría intentar que estos sitios no estén disponibles para usted con la esperanza de que recurra al DNS localmente suplantado.

Hay varios proyectos como DNSSEC y DNSCrypt que tienen como objetivo prevenir el envenenamiento del DNS, etc. La adopción de este tipo de tecnologías está aumentando, pero aún no ha llegado a ese punto.

Sin embargo, diferenciemos entre el control de su servidor DNS, el control del nombre de dominio y el control del servidor web.

Si un atacante tiene el control de un servidor DNS, puede enviarlo a su servidor de ataque, pero no puede falsificar un certificado de confianza. Esto es fácil de ver, ya que obtendrá un "este sitio no es confiable".

Sin embargo, si un atacante obtuviera la información de su cuenta para el registrador de su dominio, podría registrar su propia IP con su nombre de dominio, que luego podría canalizar para obtener un certificado de confianza para ese dominio.

Si un atacante tiene el control del servidor web, podría obtener un certificado de confianza para ese dominio; esto es completamente independiente de DNS.

Para los dos ataques posteriores, es muy difícil de detectar. La monitorización de IP no es muy útil en la mayoría de los casos, ya que muchos sitios web utilizan la nube alojada (amazon, azure, google) donde su IP puede cambiar día a día. Podría controlar los certificados, un nuevo certificado tendría una huella digital diferente, que podría detectar del lado del cliente (y probablemente podría automatizarse con un complemento del navegador). Sin embargo, los certificados cambian legítimamente cada pocos años (los certificados expiran después de un período de tiempo establecido por diseño), por lo que esto podría producir muchos falsos positivos.

En resumen, si un atacante puede robar la identidad de un sitio web, ya sea secuestrando el dominio a través del registrador o simplemente accediendo al servidor web existente, es muy difícil que un cliente lo detecte. Depende de los administradores del sitio web asegurarse de que mantienen el control de su identidad.

Hasta el último punto sobre zeroSSL / vamos a cifrar / y ese tipo de proveedores de certificados automatizados. Ha habido una serie de casos de alto perfil en los que estos sistemas automatizados han estado generando certificados que no deberían ser (certificados en los que el control del dominio no se está validando correctamente). En este caso, la falla está completamente en la CA (ZeroSSL / Let's Encrypt / etc.), Y expone el problema inherente al permitir que los algoritmos manejen la validación. Es rápido y barato, pero los algoritmos pueden ser engañados de manera que los humanos saben que son trucos.