Podcast: Descargar (Duración: 27:47 — 26.3MB)
Karpersky define el pharming de la siguiente manera:
El pharming, una combinación de los términos «phishing» y «farming», es un tipo de cibercrimen muy semejante al phishing, en el que el tráfico de un sitio web es manipulado para permitir el robo de información confidencial.
https://latam.kaspersky.com/resource-center/definitions/pharming
Aunque la definición que ofrece Karpersky es la más extendida, con más o menos modificaciones, si me permitís, voy a sugerir yo la siguiente: «Pharming es una actividad maliciosa que reemplaza la dirección IP de un sitio web, pero manteniendo el nombre para realizar actividades ilícitas con los datos del usuario«.
Cuando hablamos de phishing nos referimos a aquella actividad ilícita que intenta engañar al usuario haciéndole entrar en una web con un nombre parecido, pero en pharming vamos un poco más allá y el usuario va a la web correcta, lo que pasa es que hay «algo por detrás» que desvía el tráfico para que vaya a un servidor diferente al legítimo.
Esto podemos hacerlo en principio de dos formas:
- Modificando el fichero de hosts del equipo. (Afecta sólo a un cliente)
- Haciendo una modificación en el DNS que utiliza el equipo. (Afecta a muchos clientes de una vez)
Máquina comprometida
En el caso de realizar una modificación en el fichero de hosts del equipo esto es producido por una modificación local, es decir, algún software ha modificado ese fichero en concreto. Esto es causado por algún virus, troyano o similar. Es interesante disponer de algún antivirus para este tipo de cosas, o al menos disponer de un mínimo de sentido común a la hora de ejecutar cosas y más de ejecutarlas como root o administrador, dependiendo el sistema operativo.
Y luego está la opción más conocida, compleja y la que más miedo da en general. Estamos hablando del caso en el que nuestro ordenador, teléfono móvil, etc… está perfecto y es el servidor de DNS el que está infectado, o bien, hay un equipo infectado en la propia red del cliente que interfiere las respuestas del DNS. Ahí como usuarios individuales no podemos controlarlo todo, pero como administradores de la red sí podemos y debemos hacer algo.
Spoofing en la respuesta en LAN
La primera opción será que el atacante interfiera nuestra petición de DNS y genere una respuesta que llegue antes que la respuesta del servidor real. Aquí se realiza un spoofing para colar la información maliciosa.
Las condiciones para que la respuesta falsa cuele son los siguientes:
- The source IP address must match the IP address of the DNS server.
- The destination IP address must match the IP address of the user’s machine.
- The source port number (UDP port) must match the port number that the DNS request was sent to(usually port 53).
- The destination port number must match the port number that the DNS request was sent from.
- The UDP checksum must be correctly calculated.
- The transaction ID must match the transaction ID in the DNS request.
- The domain name in the question section of the reply must match the domain name in the question section of the request.
- The domain name in the answer section must match the domain name in the question section of the DNS request.
- The User’s computer must receive the attacker’s DNS reply before itreceives the legitimate DNS response.
Ataque de envenenamiento de caché o DNS Spoofing
Hay una forma mucho más eficiente que modificar todas y cada una de las peticiones de DNS al host es hacer lo mismo pero con el servidor de DNS, de forma que se quede en caché la entrada concreta.
Mi PC pregunta a mi DNS y el proceso se realiza en el DNS y no en el PC origen, es mucho más eficiente.
Esto se podía conserguir incluso con DNSSec al principio aprovechando vulnerabilidades del servidor de DNS y antiguamente era posible aceptar RRset que no coincidieran, recordar si ya lo sabéis que un RRSet no es más que un conjunto de resource records que comparten clase, tipo y nombre y sí o sí tienen que ser los mimos datos, de hecho DNSSec lo tratamos ya en este podcast en otro capítulo, así que podéis usar el buscador en eduardocollado.com.
Ataque remoto a la caché del DNS
Si el atacante no está en la misma LAN que el servidor DNS tenemos que buscar formas más imaginativas para modificar esa caché. Al no estar en la misma LAN no podemos averiguar cual es el ID de la transacción, pero sólo 65536 opciones diferentes, es decir, 2¹⁶, que parecen muchas, pero realmente no lo son.
El método consiste en hacer peticiones de subdominios aleatorios, que lo normal es que no existan. Nuestro servidor de DNS tendrá que hacer una búsqueda recursiva y es ahí donde le enviaremos respuestas con esa entrada y la de www, porque el estándar nos permite devolver varias respuestas en un mismo datagrama si son del mismo dominio.
Si conseguimos adivinar el ID y somos más rápidos que el DNS al que se pregunta ya tenemos insertado en caché la IP mala.
Así de fácil.
Protección
Por supuesto estos ataques se pueden hacer en un Mundo ideal con DNSs antiguos, sin ningún tipo de protección y sin DNSSec.
¿Cómo nos protegemos? pues como usuarios lo que podemos hacer es comprobar el certificado SSL de las webs, si el certificado es erróneo, caducado o no tiene desconfiad. A día de hoy gracias a Let’s Encrypt no tener certificado debería de ser al menos pecado, porque es prácticamente imposible que nos lo pongan más fácil.
Otra cosa que podemos hacer para proteger al menos nuestro dominio es usar DNSSec, por la misma razón que el certificado de la web, es algo que se configura en un momento y que el coste es inexistente.
Si nosotros gestionamos servidores de DNS lo que tenemos que hacer es siempre siempre siempre tenerlos actualizados y no dejarlos en el olvido. Los servidores de DNSs principales que existen hoy en día están muy protegidos contra este tipo de cosas. Obviamente siempre saldrá alguien que descubra vulnerabilidades nuevas, es ley de vida, pero lo que está claro es que si no tenemos nuestros DNSs actualizados nuestras posibilidades de tener problemas serán mucho mayores.
Y para proteger a nuestros usuarios de problemas en la LAN a día de hoy es bastante sencillo independizar el tráfico entre los clientes ya sea en una red cableada o en una red inalámbrica.
Conclusión, tener todo actualizado y activar las opciones de seguridad. Eso nos dará tranquilidad.