Me gustaría compartir con vosotros unas reflexiones sobre el uso de ataques a cliente hoy en día en las pruebas de “Ethical Hacking”. Lo primero de todo es aclarar que cuando hablo de ataque a cliente me refiero a pruebas diseñas explícitamente para atacar al usuario final de una organización, donde estas pruebas o ataques pueden buscar cualquier usuario de la organización o buscar determinados perfiles (ataques dirigidos), como administradores de sistemas, directivos, responsables del departamento de compras, etcétera. Además, estas pruebas o ataques combinan ingeniería social y técnicas de explotación de software cliente para conseguir objetivo.
Una vez introducido el concepto de “ataque a cliente”, desde mi punto de vista no incluir este tipo de pruebas dentro de la batería de pruebas de un “Ethical Hacking” significa que no estamos poniendo a prueba nuestra organización frente a la vía principal de infección y ataque en la actualidad. Normalmente se contemplan pruebas sobre nuestras aplicaciones Web, sobre nuestro sistemas situados en el perímetro y sobre nuestra red interna; estas pruebas son totalmente necesarias, pero me pregunto ¿son suficientes? ¿nos hemos puesto a prueba realmente? Podemos estar aplicando muchas medidas de seguridad a diferentes niveles pero, ¿son efectivas ante un ataque a cliente?
Un escenario sencillo de ataque a cliente sería el siguiente: un atacante envía un correo muy sugerente a un alto cargo de la organización para que acceda a una página Web con código javascript malicioso (el atacante podría utilizar la herramienta beEF para crear el ataque). El alto cargo accede, con lo que el equipo queda controlado por el atacante al ejecutarse el código javascript, pudiendo llegar a comprometer el equipo de manera persistente en el caso de poseer alguna vulnerabilidad (un ejemplo de este escenario sería este vídeo). Con este simple ejemplo hemos saltado las barreras perimetrales habituales y ese equipo está controlado por el atacante, poniendo a prueba la seguridad en nuestra red interna, la del propio sistema cliente y nuestros sistemas de monitorización internos.
A partir de ese momento uno se debe preguntar: ¿está mi organización preparada para prevenir, detectar y reaccionar en el caso de que esto pase? Si partimos del hecho de que alguien en la organización por alguna circunstancia ha sido infectado, ¿seríamos capaces de detectarlo? ¿Podríamos enterarnos si el espécimen que ha infectado el equipo está sacando información confidencial hacia fuera? ¿Sería capaz de parar todos los ataques destinados a usuarios de mi organización, mis medidas lo paran?.
Vamos a mostrar dos ejemplos de posibles pruebas que un equipo de “Ethical Hacking” podría diseñar de una manera sencilla y que aportaría a la organización una serie de indicadores:
1. En primer lugar el equipo de “Ethical Hacking” desarrolla un correo electrónico muy sugerente donde se regala un dispositivo electrónico de moda, aprovechando las fechas de la navidad. Este correo es enviado a la gente de la organización desde una cuenta amigable (direccion@miempresa.es). En el correo se coloca un enlace a una página Web donde cada visita será registrada. El equipo de “Ethical Hacking” dispondrá al final de un periodo establecido de una serie de datos, de los cuales se extraerán dos indicadores útiles para la organización:
- Cuantos usuarios avisan al equipo de seguridad de un correo fraudulento.
- Cuantos usuarios siguen el enlace.
El objetivo de esta “práctica” sería por tanto crear un phising controlado.
2. Otro escenario sería dejar uno o varios dispositivos USB de almacenamiento cerca de la organización en puntos estratégicos, como si se hubieran perdido. Dentro habrán documentos bastante sugerentes. Al ejecutarse lo único que se haría es mandar un paquete hacia al equipo de “Ethical Hacking” indicando que se ha visto el documento.
De este escenario tan simple se extraerán indicadores útiles para la organización como:
- Cantidad de usuarios que usan el pendrive.
- Cantidad de usuarios que ejecutan el fichero.
- Cantidad de usuarios que ejecutan el fichero como administrador, etcétera.
Este escenario pondrá a prueba el nivel de concienciación del usuario final, las políticas del sistema del cliente, etcétera.
Los escenarios posibles son muchos, como muchas son las vías que los atacantes están utilizando para infectar los equipos cliente y con ello vulnerando la seguridad de nuestra organización. Los escenarios propuestos son muy simples y podrían ampliarse, obteniendo más indicadores de interés para comprobar que todo está funcionando como esperamos. Con esta entrada lo que me gustaría es que se reflexione sobre la utilidad de este tipo de pruebas y se piense si estamos testando nuestra organización ante este tipo de ataques. Estas pruebas van dirigidas al personal de la organización, por lo que deben estar muy bien diseñadas y acordadas con el cliente para no afectar a los usuarios y a la vez obtener resultados concluyentes.
¿Qué piensan nuestros lectores sobre este tipo de pruebas? ¿se están utilizando ampliamente en las pruebas de ethical hacking? ¿son demasiado arriesgadas?.
Para terminar me gustaría dejar una presentación de Carnal0wnage, donde se tratan los ataques a la capa 8, es decir los ataques al cliente en un PENTEST, una presentación muy recomendable.
Aunque estoy de acuerdo con todo lo que expones en el artículo y creo que este tipo de pruebas son necesarias, su ejecución tiene connotaciones legales y morales a tener en cuenta. Sin extenderme demasiado, por un lado, puede considerarse algo similar a “incitación al delito”, y por otro hay que valorar las implicaciones y medidas a adoptar hacia aquellas personas que, existiendo normativas y políticas de seguridad implantadas en la organización, las ignoran poniendo en riesgo la seguridad de la organización. ¿Qué se hace en esos casos? Despido procedente (¿?), proceso disciplinario, etc. Se podría valorar una gestión anónima y meramente estadística, pero es difícil que el cliente acceda a prescindir de los datos de aquellos que podrían poner en riesgo el negocio.
Como digo, es necesario pero su ejecución puede ser mucho más complicada que una auditoría lógica.
La verdad es que en una análisis agresivo de la seguridad de una organización poner el enfásis en el eslabón debil (la persona) me parece adecuado (más bien necesario), particularmente porque nos puede permitir evaluar las distintas alternativas tecnológicas que nos ayuden a contrarrestar su ‘debilidad humana’, pero como dice Manuel las connotaciones son demasiado amplias. Y su repercusión un peligro en algunos casos.
No obstante me parece muy adecuado el artículo, y muy sugerente.
Un saludo.
Excelente entrada y ciertamente la presentación a la que se referencia es muy ilustrativa y comprensiva de los ataques más extendidos. Lectura obligada para casi todos.
Saludos.
Estoy de acuerdo en que hay que considerar los aspectos legales y morales, ni dudarlo, y me parecen unos comentarios muy apropiados para tenerlos en cuenta a la hora de plantearse esto. Por otro lado añadir, que un Ethical Hacking abarca plantearse este tipo de cuestiones que planteáis, y sobretodo, como indica su propio nombre es “ethical” :-). Lo que nunca deben de ser (estos aspectos), bajo mi punto de vista, es una barrera insalvable para poder ejecutar pruebas que realmente pongan a prueba nuestra organización, como YA lo están haciendo los malos; fórmulas existen para poderlo hacer y pruebas a realizar muchas.
Gracias por los comentarios! :-)