Desde hace varios años es público en internet que existen modems instalados en los usuarios de CNT que utilizan una clave por defecto, podemos ver ejemplos de esta información aquí y aquí.
Con el tiempo éstas contraseñas por defecto, que representan un riesgo para la seguridad del usuario común, se han hecho tán fáciles de encontrar que solo basta con una simple búsqueda en Google.
El día de ayer 17 de Noviembre, Ernesto Pérez del CSIRT-CEDIA encontró un modem de CNT el cual tenía cambiado un servidor de DNS apuntando a un equipo en Rusia. Cuando se consultaba a este DNS por la página web www.pichincha.com daba como respuesta una dirección localizada en el Reino Unido.
Se sugiere se revise la configuración de todos los modems de este proveedor dado que posiblemente el atacante no se centró únicamente en un usuario, sino que posiblemente utilizó un script para modificar los DNS de un grupo de modems.
Este cambio solamente puede producirse si un atacante logra acceder al modem instalado donde el cliente y modificar los DNS que se utilizan para la red del usuario.
Este ataque no es novedoso, ya con anterioridad se ha presentado: http://www.pcworld.com/article/2602040/attack-hijacks-dns-settings-on-home-routers-in-brazil.html
¿Cómo funciona el ataque?
El ataque en sí no es sofisticado ya que cualquier persona con algunos conocimientos sobre cómo funciona el sistema DNS podría llevarle.
El ataque se produce por la falta de seguridad en la implementación de contraseñas, es decir, la mayoría de los routers de CNT vienen con la misma credencial por defecto. Desde el punto de vista de un usuario común puede que no signifique mucho debido a la falta de conocimiento con respecto a las contraseñas por defecto pero si éste mismo escenario se lo observa desde el punto de vista de un atacante las cosas cambian.
Imágen 1.1
Configuración de DNS de router CNT.
Observervamos como el atacante ha sustituido la IP del DNS primario por uno controlado posiblemente por él con la finalidad de redirigir al usuario donde ellos deseen dando la impresión al usuario que está visitando un sitio totalmente válido pues el usuario escribe el nombre de un sitio (www.pichincha.com en este caso) y obtiene un sitio idéntico al del banco pichincha.
Imágen 1.2
Sitio falso del Banco Pichincha.
Aprovechando ésta vulnerabilidad los atacantes decidieron enfocarse en los usuario del Banco Pichincha procediendo a redirigir a los usuarios a un servidor previamente configurado junto con una vista aparentemente legítima de la página del Banco Pichincha.
Imagen 1.3
Certificados e información de DNS.
Al intentar acceder al Banco Pichincha por parte de los usuarios que hagan uso de routers con el DNS modificado por este intruso, estos encontrarán un mensaje por parte de la página diciendo que el certificado de seguridad emitido por la entidad no puede ser verificado, por otra parte, se puede ver que la dirección IP que se muestra en la Imagen 1.3 es 83.170.68.72, una IP del Reino Unido que no es donde el banco del pichincha acostumbra a tener sus servidores.
Efectivamente, un usuario con conocimientos informáticos, al ver que se indica que el certificado no puede ser validado, puede optar por negarse a entrar a esta página. Sin embargo un usuario quizá con conocimientos menos avanzados puede aceptar entrar al sitio aún cuando el navegador le indica que el certificado no puede ser validado.
Imágen 1.4
Dirección IP real del Banco Pichincha.
Cuando se intenta de averiguar la dirección IP desde un servicio DNS no afectado por la vulnerabilidad se comprueba que no es la misma IP a la que se redirige a los usuarios del ruteador atacado.
Imágen 1.5
Comparación de certificados.
Como último punto queda mencionar que al aceptar el certificado no válido emitido por los atacantes se estará completando la última etapa ortorgándole al atacante el poder de saber qué enviamos a través de conexiones seguras, por lo tanto, resultando en pérdida de nuestra información.
Recomendaciones
- EcuCERT debe trabajar con CNT para apoyarles y que, de forma urgente, bloqueen el acceso al puerto 80 y/o cambiar la clave por defecto de los modems.
- El Banco Pichincha debe emitir un aviso en el que sugiera cambios de clave frecuentes. O proponer a la entrada el cambio de clave a usuarios.
- Aunque la autenticación en dos etapas puede no ser completamente segura, el Banco debe analizar implementar autenticación en dos etapas a todos los intentos de entrada por la web.
