Mi experiencia de años en este tema me ha demostrado que la mayoría de las empresas y entidades que reciben ataques de phishing, no reaccionan con la celeridad suficiente cuando sufren estos ataques. Además la mayoría solo toma medidas reactivas, pocas medidas preventivas y prácticamente ninguna medida de detección temprana.
Sí, ya sé que algunos estarán pensando que un ataque de phishing no se puede anticipar, pero eso en el 85% de los casos es falso, aunque dejaré para otra oportunidad ese tema. Lo que voy a explicar en este artículo son las medidas reactivas a tomar ante un ataque de phishing en curso por parte de la administración de la aplicación afectada. La prevención y la detección temprana aunque son la mejor práctica no forman parte de este artículo.
Es impresionante ver en las empresas y entidades la poca preparación ante estos temas. En ocasiones me he visto rodeado de personal de seguridad, vicepresidentes, programadores y hasta policía al rededor de sendas mesas de reunión (más de 12 personas en una ocasión), solo para enterarme que mis servicios fueron solicitados pasadas más de 72 horas desde que se detectó el ataque, sin que ni siquiera se hubiera denunciado aún el sitio ofensivo mediante un procedimiento extremadamente básico que cualquier usuario pude hacer en menos de tres pasos desde su navegador.
Como primer punto, hay que entender que el atacante no necesariamente es un programador experimentado. Fíjense que ni siquiera le llamo con el término "hacker" ya que desarrollar un phishing es más un trabajo de "script-kiddies" o "lammers" (términos despectivos con los que los hackers llaman a los que atacan aplicaciones copiando código o exploits sin tener gran noción del proceso).
Otro detalle importante a tomar en cuenta, es que un ataque de phishing se realiza en casi la totalidad de los casos desde la plataforma de un servidor que ha sido vulnerado, para colocar las páginas falsas allí. El atacante tratará de que sus scripts y páginas falsas no sean detectadas, por lo cual dejará la menor huella posible (footprint), razón por la que sus páginas falsas llaman directamente las imágenes desde el servidor de la aplicación real, así como posiblemente a otros recursos.
Un tercer punto a tomar en cuenta es que las primeras horas de un ataque de phishing son las más peligrosas y en las que el ataque es más efectivo. En las primeras 24 horas el 60% del daño ya ha sido hecho. Por tanto las medidas a que expondré no deben aplicarse de forma secuencial sino dentro de lo posible de forma simultánea por varias personas ya que algunas necesitan seguimiento.
Pasos a seguir ante un ataque de phishing:
Antes de tomar cualquier paso obtenga las direcciones de los servidores en los que se encuentran alojadas las pseudo-fachadas o páginas falsas. Aclaro este punto porque el ataque pudiera bien ser distribuido entre varios servidores tratando de aumentar el tiempo de vida y dándole más trabajo para denunciar más sitios, esperandoasí que se pasen algunos por alto. ¿Cómo hacerlo? Simple, usted debe tener al menos una dirección reportada, si no aún no sabría del ataque. Pues bien, fíjese qué imágenes de la páginas falsas son llamadas directamente desde su sitio y diríjase a archivo de registros de su servidor web para consultar por dichas imágenes. Una vez allí obtenga las direcciones de las que son solicitadas o "referers". Recuerde hacer seguimiento permanente de este punto ya que pudieran aparecer nuevos sitios falsos a medida que usted bloquea otros. El ataque podría ser distribuido o por etapas, para darle atacante la capacidad de ir "quemando" los sitios a medida que usted los descubre y denuncia.
Simultáneamente usted deberá renombrar todas las imágenes utilizadas por los sitios falsos, para que estos ya no logren mostrarlas y el usuario vea como resultado al hacer clic en los enlaces forjados un sitio falso sin imágenes o al menos sin algunas de ellas (el logotipo y las imágenes que identifican la página son las más importantes).
Denuncie las direcciones falsas usandon las funciones de los navegadores Internet Explorer, Google Chrome y Opera . Si usa Firefox será igual que usar Chrome ya que acceden ambos a la misma base de datos de sitios ofensivos. Cada sitio debe ser denunciado en los tres navegadores ya que cada uno de ellos usa bases de datos diferentes. Si no tiene instalado Opera, puede hacer la denuncia directamente en https://www.phishtank.com/. Si tiene suficiente personal no olvide denunciar también las páginas en el APWG (Anti-Phishing Working Group) http://www.antiphishing.org/ .
Obtenga la información necesaria de los proveedores de hosting en los cuales se encuentran los sitios falsos mediante Reverse DNS Lookup de las direcciones asociadas al ataque, y ubique la cuenta de correo destinada a denuncias de abuso. Casi siempre tiene el formato "abuse@proveeedor.com". Denuncie el abuso con pruebas y direcciones a cada una de estas cuentas. Si logra ubicar números de teléfono con los cuales contactar a los proveedores no dude en usarlos. Este tipo de detalles se podrá obtener también mediante consultas WHOIS o nsLookup. Recuerde que este tipo de ataque es penado seriamente por la ley en muchos paises y el hecho de que un proveedor de hosting o ISP se niegue a ayudarlo puede ser causa de una denuncia por complicidad. También pueden ofrecerle direcciones en las que se hayan formularios para denuncias. Llénelos a la brevedad posible.
Llene el receptáculo de datos del atacante con información falsa. Hágalo llenando los datos solicitados como si fuera un usuario incauto, manualmente desde varios equipos mientras prepara un script para hacerlo de forma automatizada. Trate que la información que introduce en los formularios sea creíble. Esta técnica podrá ocultar a los usuarios incautos entre montones de datos falsos por un tiempo prudencial. Además con ella usted está comprando tiempo para que sus usuarios puedan cambiar de password si sospechan que han sido engañados. Por otro lado si ejecuta el script gran cantidad de veces pudiera lograr que alguno de los servicios del sitio falso dejen de funcionar. Algo parecido a una negación de servicio defensiva.
Todas estas técnicas deben ser implantadas por un tiempo prudencial de 24 horas sin parar, hasta que las denuncias en las listas de phishing se hagan efectivas y ya los navegadores protejan al usuario con la típica pantalla roja de seguridad.
Sin embargo si el ataque es distribuido, con un número muy alto de sitios falsos usted necesitará aplicar técnicas de defensa mucho más potentes y quizás no tan éticas. Generar un DoS mediante Loic o Hping puede ser una solución rápida, pero deberá estar muy seguro de a quien ataca y preferiblemente hacerlo desde una red externa a la entidad esperando un contraataque.
Recuerde que la idea es proteger a sus usuarios antes que nada, el resto son asuntos que puede dejar para otros departamentos cuando sus usuarios estén seguros.
Lógicamente, habrá podido apreciar que usted deberá en más de un caso tomar decisiones y saltar protocolos como control de calidad y otros. Su empresa debe tener un protocolo de seguridad para estos casos para que usted no se encuentre con las manos atadas por los procedimientos convencionales a seguir. Si todas las medidas anteriores suman más de 48 horas no habrán servido de mucho.
Por último, recuerde que antes de pasar por todo esto, usted puede evitar de forma casi definitiva los ataques de phishing mediante técnicas de prevención anti-phishing, sistemas de acceso seguros comprobados, factores de autenticación externos y sistemas de alerta temprana que pueden detectar a un atacante mientras aún se está instalando el phishing en el servidor vulnerado. En fin, toda una serie de técnicas de prevención y alerta que le ahorrarán muchas molestias a usted y a sus usuarios y mucho dinero a su entidad.
Hasta la próxima...
Este blog está dirigido a todos los programadores y desarrolladores en general, en él encontrarán consejos útiles en las respectivas áreas del desarrollo de aplicaciones, especialmente de Aplicaciones y Soluciones Web sobre diferentes entornos y plataformas móviles como Windows Phone y Android.
Suscribirse a:
Comentarios de la entrada (Atom)
Entradas populares
-
Es importante cuando se habla de amenazas en aplicaciones web y otras, establecer un sistema de cálculo estándar que permita a los interesad...
-
Volvemos a mencionar en este artículo la importancia del OWASP (Open Web Application Security Project) y en especial esta vez mencionaremos...
-
Un "error" muy común de los programadores web en cuanto a la seguridad de sus aplicaciones, es acceder directamente a las variable...
-
Las amenazas constantes a las aplicaciones web, el crecimiento de cada vez más veloz de las plataformas desarrolladas en línea y una crecien...
-
Es una indudable ventaja el hecho de poder obtener el número IMEI de un dispositivo móvil desde una aplicación para cualquiera de las plataf...
-
Uno de los problemas que presentamos los desarrolladores es el control de los Cookies usados en transacciones seguras. El primer inconveni...
-
El Phishing ya se ha convertido en un parásito dañino de nuestras aplicaciones y sistemas en Internet. Uno de los ejemplos más claros y mas ...
-
Nuevamente OWASP nos hace llegar la lista de las más importantes vulnerabilidades en lo referente a desarrollo web en su lista del 2017 Top ...
-
Si el video de OWASP del anterior post sobre HSTS (HTTP Strict Transport Security) los dejó con algo de espectativas acerca de la implementa...
-
El ya conocido tipo de estafa que se basa en la simulación de un sitio en Internet para robar los datos de acceso a los usuarios con propó...
No hay comentarios.:
Publicar un comentario