Envenenamiento de caché de DNS como un foil a SSL

No, este ataque no es factible. Créeme, lo he intentado. Ahora, cuando digo que lo intenté, no estaba escribiendo un virus o algo para robar contraseñas, estaba escribiendo un software en el que el usuario era plenamente consciente de que estaba usando un servidor DNS personalizado que mentía intencionalmente (según sus reglas) en conjunción con un proxy HTTP. Esto es exactamente lo que usted describe, "envenenando" el DNS para que básicamente se acueste al software que realiza la búsqueda y lo apunte a donde quiera que realmente quiera que vaya el tráfico. Hay varios problemas que surgen una vez que lanzas SSL en la mezcla.

1) Incluso si tiene un servidor DNS personalizado o una parte del software que supervisa y modifica los paquetes DNS, no hay forma de que este protocolo le indique si está tratando con solicitudes de HTTP / HTTPS, o quién sabe qué. Por lo tanto, no puede decir para qué protocolo es la solicitud. Incluso si inspecciona el paquete y busca el nombre de host, aparecerá como "mail.google.com", no " enlace ", como un ejemplo.

2) Para omitir las advertencias del navegador, necesita algunas cosas. Primero, necesita un certificado raíz de confianza para su proxy o servidor malicioso. No va a pasar. Incluso si logra que el usuario lo acepte e instale (las ventanas básicamente se aseguran de hacer que el usuario sienta que está aceptando un sobre con ántrax si dicen que sí), la mayoría de los navegadores tienen sus propios almacenes de certificados de autoridad raíz confiables que comprueban contra Así que ahora tienes que hacer que el usuario haga un esfuerzo adicional para instalar tu certificado en cualquier tipo de navegador que esté usando también.

3) El segundo paso no es suficiente. Ahora, si ha llegado tan lejos, tiene su certificado malicioso para su servidor malicioso. Ahora necesita emitir certificados dinámicamente para cada host individual en el que se realiza una conexión HTTPS o, de lo contrario, adivinen qué, las alarmas aún suenan. Estas advertencias del navegador no son como los viejos tiempos. Google Chrome ni siquiera le permitirá continuar cuando detecte que esto está sucediendo , sin importar cuánto quiera el usuario ser descuidado con su propia seguridad.

Además, sin hacer ninguno de estos trucos fallidos analizados en 2 y 3, obtienes incluso menos. Todo lo que puede ver en un nivel de socket es el socket abierto desde la aplicación que solicita la búsqueda, usted ve que la resolución del host se realiza sobre DNS, luego se abre un nuevo socket TCP que intenta conectarse al host que solicita una conexión segura. El encabezado de socket no contiene nada excepto esta solicitud básica. Tan pronto como se realiza la conexión con el servidor, se produce un apretón de manos y la conexión HTTP se vuelve segura, momento en el que se pierde la esperanza de fallar con cualquiera de los datos.

El punto es que la probabilidad de que este ataque tenga éxito es básicamente inexistente. El usuario tendría que ignorar las advertencias del estilo del día del juicio final de Windows sobre certificados, aprobar la solicitud de Windows de permisos de administrador elevados (suponiendo que esté utilizando software malintencionado para envenenar directamente el caché de DNS o decirle al sistema que use un servidor de DNS malicioso). Tendría que ignorar la gigantesca pantalla roja del estilo del día del juicio final en su navegador (si su navegador lo permite). Sería excepcionalmente difícil de obtener y tendría un éxito mínimo incluso si pudieras.

Dicho todo esto, realmente espero que estés solicitando esta información por el bien del bien, no de intentar cosas como esta. Jugar y aprender estas cosas puede ser divertido y puede ayudar a proteger a los usuarios. Sí, estaría perfectamente bien configurar tu propia red de prueba y piratearla por diversión y educación, pero hacer y aprender todo esto para explotar a la gente te convierte en un matón y un criminal y una desgracia para el aprendizaje superior. No estoy diciendo que seas esto, estoy diciendo que las personas que hacen eso son. Espero que consideres y peses estas cuestiones morales y filosóficas en tu aventura para obtener conocimiento.

Vea también, para una prueba de la protección del navegador de este problema.

Advertencia de SSL de Chrome : "No puede continuar porque el operador del sitio web ha solicitado una mayor seguridad para este dominio".

La razón principal por la que los servidores SSL utilizan certificados es precisamente para que el tipo de ataque que está describiendo no funcione. Y, más generalmente, SSL no confía en cualquier característica de seguridad, o falta de ella, de su medio de transporte. Esto incluye la conversión de nombres a direcciones IP, es decir, el DNS. Para todos los propósitos prácticos, SSL permanece seguro incluso si el atacante mismo transmite todos los paquetes de datos en ambas direcciones.

Si lo prefiere, incluso con el control total del tráfico de bajo nivel en ambas direcciones, no podrá hacer que los clientes hagan una conexión SSL con su servidor falso; el cliente recibirá una advertencia muy visible acerca de que el certificado del servidor aparente es incorrecto (o no podrán validarlo, o el nombre en el certificado no coincidirá con lo que se espera, o ambos). Si los usuarios humanos "hacen clic" en la advertencia, entonces sí, se conectarían a su servidor falso y quedarían bajo su control; sin embargo, los navegadores modernos hacen cada vez más difícil para el usuario humano típico no prestar atención a estas advertencias relacionadas con los certificados.

Aparte de las otras respuestas, este ataque desde la perspectiva de una llamada a la API utilizando la opción curl con -k (insegura) implicaría que irá a la espera y se conectará al servidor malicioso, considerando que a la mayoría de los desarrolladores les encanta usar -k para ignorar el certificado validación a menudo.