Tras ver el
hackeo en el caso de Ebay, se preguntaba
en el artículo si habíamos probado la resistencia de nuestra empresa contra ataques de phishing
que buscaran robar las credenciales de los usuarios internos. Este es
un caso de
ataque típico desde hace muchos años que se puede usar en
ejemplos de
robo de fotos de famosas o que lo pueden usara los
Syrian Electronic Army para hackear a la RSA Conference.
 |
| Figura 1: El viejo y el mar. Viejas técnicas de pesca, mismos resultados. |
Así que, aceptando el reto propuesto, y con el objetivo de medir y
analizar el grado de conocimiento y conciencia sobre la seguridad de la
información en la empresa, se realizó una simulación de
ataque de
phishing a los trabajadores de la
empresa. Estos son los resultados obtenidos, que nos han hecho preocuparnos.
El escenario de auditoría
El ataque que se planteo fue muy sencillo, y consistió en hacer llegar a
los usuarios un correo que llegaba supuestamente desde el banco que
utiliza la
empresa para pagar los sueldos, ofreciendo una promoción
atractiva e indicando que era necesario suscribirse siguiendo un
hipervínculo.
Para hacerlo más creíble, se registró un nombre de dominio relacionado
con el nombre del banco, pero que evidentemente no era el del banco. Se
gestionó para que todo fuera mucho más aparente, además, un
certificado
SSL Clase 1 firmado por una autoridad certificante confiable por cualquier navegador, por lo que se eligió
StartCom.
Cuando el usuario seguía el enlace, era dirigido a un sitio idéntico al de la
Banca Personal del banco que fue copiado con
httrack,
pero que esta vez estaba controlado por el área de Seguridad de la
Información de la empresa. Cada enlace enviado contenía un código
único que hacía posible trazar la actividad individual de cada usuario
dentro del sitio, para facilitar el análisis posterior y para que fuera
más efectivo el
APT y no fuera detectado por ningún
bot o afectara a otros usuarios, el
firewall del servidor solo aceptaba peticiones desde la dirección
IP pública de la empresa.
Por supuesto, el sitio de
phishing solicita las
credenciales, las almacena localmente y redirige a una página de error
del sitio real del banco. Por tratarse de información sensible, sólo
se almacenó una fracción de las credenciales, con el objetivo de poder
verificar si se trata de credenciales que posiblemente eran reales o si
eran valores aleatorios.
El análisis de los resultados
Para que sea fácil entender lo que sucedió, clasificamos los usuarios en
tres tipos. Los que calificaríamos como alertados y precavidos que no
hicieron nada, los curiosos que siguieron el hiper-enlace asumiendo
riesgos pero sin introducir las credenciales y las víctimas, que
ingresaron los datos. La siguiente tabla detalla el comportamiento de
los usuarios luego de recibir el correo:
- Sin Acción: El usuario no siguió el link enviado en el correo.
- Visita: El usuario siguió el link, pero no ingresó sus credenciales.
- Autenticación: El usuario siguió el link e ingresó sus credenciales.
Sorprendentemente, en algunos casos los usuarios visitaron el sitio y/o
ingresaron sus credenciales más de una vez. Sólo se consideraron las
visitas únicas en cada caso.
 |
| Figura 2: Números de cada tipo de acción |
Además, cabe destacar la velocidad y efectividad del ataque, ya que una gran parte de los intentos de autenticación, el
72% de ellos, sucedieron dentro de las primeras
4 primeras horas de vida del
ataque desde que fueron enviados los correos, lo que hace dudar mucho
de la efectividad de los servicios de bloqueos de hoy en día.
 |
| Figura 3: Un 20 % de los usuarios tuvieron comportamiento inseguro |
En nuestro caso, hay que felicitar al administrador de red de la empresa
que recibió el correo y al verificar que se trataba de un sitio
sospechoso, bloqueó el acceso al sitio para toda la empresa a los
86 minutos de ser enviados los correos. Luego, a pedido del
Área de Seguridad, lo volvió a habilitar. En el caso de haber sido una situación real, el bloqueo
hubiera evitado el 63% de los intentos de autenticación por una buena acción del servicio de seguridad de red.
Algunos empleados, más alertados de este tipo de ataques, tomó una
actitud activa demostrando que estaban concienciados con la seguridad y
el área de
Recursos Humanos envió una consulta a la sucursal local del banco, bajo la sospecha de que se trataba de un caso de
phishing. Luego de recibir la confirmación por parte del banco, dio aviso al
Área de Sistemas para que tomara acción al respecto.
Por último y para dar por cerrado el experimento, desde
Sistemas se envió una circular, indicando que se trataba de un correo de
phishing
y que era conveniente no seguir los enlaces ni enviar las credenciales y
luego, se eliminó del servidor toda la información relacionada con el
proyecto y se redirigió el dominio a otro servidor.
Conclusiones
Después de esta prueba, me cruce con uno de los usuarios en el cajero automático
(ATM)
de la empresa, hablando por el teléfono móvil. Estaba furioso porque no
podia cambiar su clave de banca personal. Creo que ese usuario aprendió
que no debe ingresar credenciales en sitios raros. Este usuario era uno
de los que había ingresado
9 veces sus credenciales en el sitio de phishing
El proyecto no sólo sirvió para medir y analizar el estado de
seguridad de los usuarios, sino también para concientizarlos de cómo se
hacen estos ataques y los riesgos que hay, además de detectar actitudes
que ayudan a reducir el riesgo, como la acción activa de verificación
por parte del area de
RRHH y el
Área de Seguridad de Red.
Tal vez, un proceso interno más ágil en el que los usuarios puedan
pedir a seguridad de red que verifique si un correo es phishing hubiera
podido reducir los tiempos.
Los usuarios que ingresaron sus credenciales y luego recibieron
información de que se trataba de phishing, posiblemente hayan tomado
conciencia sobre el riesgo de seguir enlaces de correos no esperados o
ingresar credenciales en sitios no verificados correctamente. Los
usuarios que no ingresaron sus credenciales, posiblemente hayan
reforzado el estado de conciencia que demostraron al no hacerlo en
primera instancia.
Por supuesto, internamente se planifica a futuro, realizar un proyecto
similar, con el fin de realizar un análisis comparativo y tomar algunas
conclusiones. En un caso de un
APT, el atacante solo
necesitaría una credencial, y viendo el número de ellas y la velocidad
que con que se consiguen, hace pensar que la protección de todas las
identidades que se usan en una empresa por solo usuarios y contraseñas
no es nunca una buena idea, y que implantar el uso de
segundos factores de autenticación es cada vez más necesario.
Autor: V.L.
PD:Nosotros ya lo hemos probado, ahora te toca probarlo en tu empresa.
