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.

Fuente: Security Art Works