Phishing con punycode. 

Phishing con punycode. 

 El Phishing… un arte que nunca muere? Porque ya son demasiados años en que ésta práctica se utiliza para el robo de credenciales a los usuarios, porque parece que poco le hace a su efectividad las capacitaciones que se brindan al respecto y porque a pesar del tiempo ni siquiera se ha sofisticado demasiado la técnica de ataque. Siempre es lo mismo, una cabecera de origen de un correo falsificada, un mensaje bonito y un link a un sitio que se apropiará de tus datos si allí los ingresas.

Parece tan tonto, tan obvio de darse cuenta lo que va a pasar… pero no! Lamentablemente miles de usuarios caen a diario en estas trampas y sus credenciales y/o datos confidenciales son robados.

¿Por qué estoy escribiendo una nota de Phishing?

Lei un comentario en el post de ayer que me gusto y quería rescatar ese comenatrio así que tal como mencioné, la técnica no se ha sofisticado demasiado en el tiempo, el común denominador siempre es explotar el factor humano y eso no cambiará, sin embargo, hay algunos conceptos y herramientas de las que me gustaría escribir.

El Phishing comenzó como lo que mencionamos en el primer párrafo, un correo de origen falsificado con un mensaje que pretende engañar al usuario para que entre a determinada página y escriba sus credenciales. Cuando se capacitaba a la gente para prevenirla de caer en esta trampa, a menudo se hacía énfasis en dos cosas: “Revisar si el sitio al que dirige el link del correo falso es HTTPS o no”, “Mirar bien el link, suele ser similar a la URL del sitio que se está falsificando, mas no es exactamente igual”.

¿Por qué estos consejos? Es cierto que la mayoría de los ataques de Phishing se montan sobre sitios web HTTP mientras que los sitios originales siempre los vemos sobre HTTPS. Pero decirle a un usuario que con ver que el sitio al que ingresa es HTTPS ya es suficiente para confiar, es un grave error. Un atacante puede obtener un certificado SSL/TLS para su sitio falso, y convertirlo en HTTPS fácilmente, de hecho, ni siquiera es necesario que invierta dinero, existen páginas como “Let’s Encrypt” que emiten certificados totalmente válidos y gratuitos por varios meses. (DE NADA)

Respecto del segundo consejo habitualmente mencionado, revisar bien la URL, es porque para el sitio falso se suele adquirir un dominio muy similar al del sitio real. La técnica se la suele llamar typosquatting y se trata básicamente de engañar al ojo humano, para que lea por ejemplo “linkedin.com” cuando en realidad dice “likendin.com”. Una alternativa similar, es utilizar el mismo nombre de dominio pero con un TLD diferente, por ejemplo linkedin.tk en lugar de linkedin.com pero el poder hacerlo depende de que dicho dominio esté disponible. Debido a esto, existen numerosas herramientas para hacer un chequeo rápido de los TLD disponibles para un determinado nombre de dominio.

Una herramienta nueva, que me ha gustado mucho es CATPHISH, pueden descargarla de aquí: https://github.com/ring0lab/catphish/.

Como se puede ver en la imagen, nos arroja un listado de dominios muy similares, en este caso al dominio de Twitter, que están disponibles para ser registrados por cualquier persona. Imposible de negar que a “twiiter.com” hasta podríamos entrar por error de tipeo, es bastante riesgoso que dicho dominio “ande libre por ahí”.

Hace realmente muchos años, al menos unos 10… cuando empecé a estudiar estos temas, leí la teoría sobre ataques homógrafos, la cual se basa en registrar un dominio que utiliza caracteres que a la vista son extremadamente similares o prácticamente idénticos a los que se quieren falsificar. Así es como cierta persona registró ɢoogle.com en lugar de google.com (sutil cambio en la letra “g” ¿no?).  Hasta hace algún tiempo atrás, no se escuchaba que esta técnica fuera aprovechada, pero parece que eso está cambiando…

Hace poquito Xudong Zheng registró el dominio xn--80ak6aa92e.com que si hacemos click, notaremos que el navegador lo muestra como apple.com. Es una hermosa demostración del potencial de este tipo de ataque si se lo utiliza con fines delictivos. La realidad, es que no es más que jugar con los caracteres y aprovecharse del sistema “punycode”, utilizado por los servidores DNS para poder gestionar dominios que son registrados en otros caracteres que no son romanos.
La herramienta que mostré anteriormente, se ganó mi cariño por encima de las demás, ya que tiene un parámetro que analiza las posibles URLs que podrían registrarse utilizando caracteres que a la vista del usuario se verán muy similar al dominio original.

Por ejemplo en la imagen podemos ver que el dominio xn--ppl-rgzsf.com está disponible para ser registrado y a simple vista luce muy parecido al dominio real de Apple.
Tal como comencé escribiendo, los ataques homógrafos llevan muchos años documentados, sin embargo ahora, desde mi punto de vista, estoy observando más casos que lo aprovechan así como también nuevas herramientas que facilitan el llegar a registrar este tipo de dominios.

Bueno, esta nota no tenía otro objetivo más que comentar algunas cosas del tema y compartirles la herramienta catphish que fue de mis preferidas esta semana.

HAPPY HACKING
Vamos a jugar con las redirecciones

Vamos a jugar con las redirecciones

Más allá del clásico uso para phising, las webs que permiten redireccionar hacia donde nosotros deseamos pueden ser aprovechadas en otros escenarios para nuestro beneficio.

Cuando se protegen áreas de una web que requieren cierto privilegio para su visualización (áreas de miembros, zonas de administración, estadísticas, etc.) se suele utilizar una redirección a través de un código 3xx para evitar que un usuario sin dichos privilegios pueda acceder. Realizar esto con PHP, por ejemplo, es algo trivial. ¿Pero qué ocurre si no se implementa de la forma correcta? Veamos el siguiente ejemplo:

<?php


if ($_SESSION[‘log’] !== TRUE) {
header(“Location: http://foo.es/login.php);
}
….
…..
?>
<h1>Texto que no deberías de poder ver porque no estás logueado</h1>

En el ejemplo vemos como símplemente se utiliza la función header() para realizar la redirección pero no se corta el flujo de lo que se muestra después, por lo que si hacemos que se ignore la petición de redirección podremos ver esa web restringida.

El bypass de esta medida se puede realizar fácilmente colocando un proxy en medio para que bloquee el response con el 302, o elimine el header “location”. Otra opción mucho más rápida de implementar es utilizar algún add-on que bloquee las redirecciones cuando se navega, como “NoRedirect” de Firefox. Activando el add-on podremos acceder a las zonas restringidas sin estar logueado.

Otra situación donde podemos abusar de una redirección es cuando ésta es realizada a través de JavaScript (usando document.location.href por ejemplo) y la dirección es pasada a través de una variable a la cual se le realiza un filtrado con htmlentities o funciones similares. De este tipo suelen ser aquellas webs que muestran un mensaje de “Serás redireccionado en X segundos” o te muestran una alerta de que estás abandonando el dominio.

En estas situaciones estamos ante un XSS no-persistente, ya que podemos usar el viejo truco de “data:text/html;base64,AquiJavaScriptenBase64” para ejecutar javascript.  Como ejemplo:

<script language=”JavaScript” type=”text/javascript”>
document.location.href = ‘<?php echo htmlentities($_GET[‘url’]); ?>’;
</script>