"Hackeando" a mis colegas

Hace meses leí una columna en Harvard Business Review donde Tom Cochran, Director de Tecnología de Atlantic Publishing, relataba un experimento de "hacking ético" donde hizo un ataque de phishing a su propia compañía para mostrar con datos certeros la importancia de la seguridad informática y lo fácil que resulta capturar contraseñas por medios muy simples.

El asunto me quedó sonando y empecé a pensar en los riesgos del manejo de información confidencial y las contraseñas en el colegio donde soy responsable por el uso de tecnología. Estoy convencido de que un número importante de los riesgos de seguridad informática se pueden solucionar con capacitación a los usuarios, pues el 99% de los virus y ataques utilizan estrategias de ingeniería social y se pueden evitar con un poco de conocimiento técnico y un mínimo de pensamiento crítico, junto con políticas de seguridad más estrictas (y más demandantes y aburridas, sin duda).

Sin embargo, también estoy de acuerdo con Cochran cuando dice:

"Would it start with educating the employees at my company? The problem with this solution is that people are inherently fallible. They will make mistakes, regardless of awareness training. Unfortunately, for most people, the cost of modifying comfortable behavior is too high. To the average employee, fixing bad digital habits yields intangible benefits and often creates annoying inconveniences."

De manera que es importante tomar acciones en ambos sentidos: capacitar a los usuarios en seguridad informática (y sentido común), además de mejorar las políticas, incluyendo soluciones como autenticación de dos factores y mejores contraseñas.

En esta línea de ideas, ayer lancé un sencillo ataque de phishing contra 281 usuarios de nuestro dominio, incluyendo 140 empleados y 141 estudiantes mayores de 16 años. El vector de ataque fue así:

  1. Creé un formulario copiando el diseño que usa Google y lo publiqué en un servidor público que usa un dominio provisto por un servicio gratuito: http://webmaster-glm.dyndns-web.com/pass/index.html. Dicho formulario guardaba la información que daba la víctima. Esta mañana modifiqué la página de confirmación para dar mayor información a las víctimas, así: http://webmaster-glm.dyndns-web.com/pass/form.php
  2. Creé una cuenta en Yahoo!, llamada gimnasiolamontana@yahoo.com y desde ella envié un mensaje a un grupo de usuarios pidiendo que cambiaran su clave, siguiendo un enlace al formulario que había publicado.

Los resultados se resumen en este gráfico:

http://www.fernandodiazdelcastillo.com/sites/all/files/images/

Ahora viene lo interesante, la discusión y la búsqueda de mejores estrategias de seguridad, en lo cual nos embarcaremos en diversas instancias del colegio, empezando por los directivos.

Espero que todos hayamos aprendido del ejercicio de "hacking ético".

Para los usuario que fueron víctimas, aquí les dejo algo de información:

¡Usted le entregó sus datos a un hacker!

Si hubiese sido una persona mal intencionada, usted podría haber perdido el acceso a su cuenta y le habría dado cualquier información confidencial y privada de sus estudiantes, colegas, familiares y amigos que tenga en su correo, Drive, sites, etc. a esta persona.

Los datos capturados por atacante fueron:

  • Su nombre de usuario
  • Su contraseña actual
  • Otra contraseña (¿que tal vez usa en otras cuentas?)

¿Y esto qué importa? En principio, podría haber ingresado a su cuenta institucional y toda la información que tiene ahí. Información confidencial, personal, privada. Información de otros que usted debe proteger. Esa información podría dar pie a un nuevo ataque, a usted o a otros.

Antes de escribir su datos en una página que se veía como Google, debería haber notado lo siguiente:

  1. El mensaje que le pedía cambiar la contraseña fue enviado desde una cuenta de Yahoo! o una cuenta de Gmail. Ni Google, ni el GLM le pedirán que cambie su clave desde un enlace que viene en un correo que usted no solicitó explícitamente. Nunca. Tampoco lo hará su banco, ni Facebook, ni Instagram, ni Twitter, ni nadie.
  2. La URL de la página en la cual escribió sus datos estaba alojada en http://webmaster-glm.dyndns-web.com. Cuando le pidan su contraseña, mire la barra de direcciones y piense si el dominio tiene sentido. Por ejemplo, una contraseña de Google debe cambiarse en el dominio google.com. En http://accounts.google.com/.
  3. La página en la cual escribió sus datos no estaba encriptada (no estaba el candado al lado de la barra de direcciones de su navegador): Chrome, Firefox.

[Edit: Imagen del pesador tomada de Wikemedia Commons].

Add new comment