Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
El IronFrame para luchar contra ataques de ClickJacking
En una entrevista concedida antes de DefCon, el hacker Dan Kaminisky ha dejado entrever una idea para luchar contra los ataques de ClickJacking que me ha gustado. Aunque no he visto los detalles de la misma, la poca información que hay sobre el IronFrame, que así se llama la medida de protección, me ha parecido digna de investigar y ha hecho que mi mente juegue un poco con los detalles.
 |
| Figura 1: El IronFrame para luchar contra los ataques de ClickJacking |
Los ataques de ClickJacking se basan en conseguir superponer un iframe transparente sobre la página que está viendo la víctima. En ese iframe transparente se coloca la web con la que se quiere que la víctima interactúe para así conseguir mediante engaños que la víctima configure cosas inseguras en su equipo sin darse cuenta.
Para conseguir que el usuario haga clic en las zonas de la capa transparente, el atacante utiliza trucos de ingeniería social que engañan a la víctima. En este vídeo se puede ver cómo un atacante podría utilizar una ataque de ClickJacking para cargar la página de configuración de Adobe y activar la webcam a la víctima con solo robar unos clics.
Figura 3: Ataque de ClickJacking para activar la webcam de la víctima
Si un atacante consigue inyectar un código en el cliente y poner un iframe, se podrían hacer infinidad de cosas. Una de las que más me gustó - abusando de nuevo de la gran potencia que tiene HTML 5 - fue la de aprovechar las funciones de Speech to Text para grabar lo que una persona diga en frente del navegador. En este artículo os conté cómo se podría hacer que una web te escuche y grabe lo que digas.
Figura 4: Cómo conseguir que una web te oiga inyectando un iframe malicioso
Al final, todos los ataques de ClickJacking se basan en poder superponer una capa sobre lo que está viendo el usuario, para conseguir el robo de los comandos que emite la víctima, que podrán ser clics, acciones de drag&drop, introducciones de teclado y hasta comandos de voz.
Para evitar que esta inyección se produzca, debe fortificarse al máximo la conexión entre el cliente y el servidor, para lo que se toman distintas medidas paliativas de fortificación desde el servidor, y en en los navegadores que puedan ser atacados. Las principales son:
- Evitar la inyección de código en ataques man in the middle: Si alguien es capaz de manipular la página en tránsito, entonces podría inyectar código directamente por la red. El uso de conexiones HTTPs y el forzado de estas conexiones HTTPs con el protocolo HSTS (HTTP Strict Transport Security) ayuda a mitigar estas posibilidades.
- Evitar la inyección de código en el cliente: El gran esfuerzo se pone siempre en evitar que se pueda hacer una inyección de código en el lado del cliente por medio de un ataque de XSS o HTML Injection. Para ello, se toman las siguientes protecciones:- Filtros Anti-XSS: Los navegadores se fortifican con filtros Anti-XSS que los investigadores de seguridad constantemente tratan de saltarse. Debido la complejidad de las tecnologías web, conseguir que un filtro Anti-XSS sea perfecto es casi imposible, por lo que de cuando en cuando van apareciendo bugs para saltarse el filtro Anti-XSS en todos los navegadores. Algunos ejemplos tenéis en estos artículos:- El 0day del filtro Anti-XSS de Google Chrome que duró 24 horas
- Saltarse el filtro Anti-XSS de Google Chrome 11
- Unos trucos para saltarse el filtro Anti-XSS de Google Chrome y Apple Safari- Forzado de filtros Anti-XSS con HTTP Headers: Estos filtros pueden ser anulados desde el cliente. Es decir, el usuario podría configurar su navegador para quitar esta protección, pero aún así pueden ser forzados desde el servidor web por medio de los HTTP headers de servidor X-XSS-Protection. Aunque el cliente lo hubiera deshabilitado, el servidor lo puede volver a habilitar.
 |
| Figura 5: Servidores de Google activando el filtro con X-XSS-Protection: 1 |
- Content-Security Policies: La última de las medidas que un servidor web puede aplicar para evitar la inyección de código en su web es el uso de las CSP. Con la configuración de una CSP, el administrador de un sitio podría anular la ejecución de código JavaScript en toda una parte de la web, lo que evitaría que se ejecutara cualquier código inyectado vía un bug de XSS en esa web.
 |
| Figura 6: Configuración CSP en la web de Facebook |
- Evitar la inclusión de un web en un iframe: La última de las protecciones que se aplican generalmente es la de evitar que una web pueda ser incluida dentro de un iframe. Al final, cuando el atacante quiere hacer un esquema de ClickJacking, inyecta un iframe en una web vulnerable y en ese iframe incluye la web de la que quiere robar los clics a la víctima. Por ello, para evitar que roben los clics de tu web, se introducen protecciones por medio de HTTP Headers X-Frame-Options, además de comprobaciones en JavaScript para ver si una web está en la ventana principal o no del navegador.
Todas estas medidas, cuando se hace una auditoría de seguridad a una web, se revisan una a una. Nosotros en nuestro servicio de pentesting persistente Faast miramos a ver si están todos los HTTP Headers en su sitio y la robustez de la conexión HTTPs, pero aún así, no hay garantía de que no se pueda llegar a encontrar un resquicio para un ataque de ClickJacking
Vaya por delante que de la propuesta de Dan Kaminisky conozco lo que he leído, entre otros sitios en Dark Reading, pero me gusta desde el principio. La idea se basa en que los navegadores tengan un IronFrame que siempre sea la capa más cercana al usuario, es decir, que sobre ese IronFrame no pueda situarse ningún iframe. De esta forma, la aplicación web se aseguraría que ninguna capa pudiera superponerse y engañar la visión que tiene el usuario de la web.
Quedan muchas cosas por definir sobre cómo gestionar ese IronFrame, pero de base es un buen punto de partida. Añadir la política de gestión de ese IronFrame desde las Content-Security Policies, usar HTTP Headers para manejarlo que solo puedan incluirse en conexiones HTTPs para evitar que nadie pueda incluir un IronFrame malicioso vía bugs de XSS o HTML Injection, o mediante ataques de man in the middle, usar HSTS para evitar que alguien, con esquemas similares al de Evil Foca pueda hacer ataques de Bridging HTTPs(IPv4)-HTTP(IPv6) o directamente SSLStrip, son detalles que quedarían por limar y ver cómo se podrían definir en un estándar, pero a mí el concepto me gusta.
 |
| Figura 8: Ningún iFrame podría estar por encima del IronFrame |
Además, se podrían añadir opciones para que desde el lado del servidor se pudiera acceder a imágenes rasterizadas de qué es lo que se está pintando en el IronFrame, lo que daría grandes posibilidades de testing e incluso de detectar ataques man in the browser - que o de mitigarlos, ya que si hay un troyano en cliente estaríamos hablando de otros ataques y no de ClickJacking -. ¿Qué os parece a vosotros la idea de construir este IronFrame en los navegadores?
5 comentarios:
Buenas
aveces me das miedo Chema ¬¬
como se puede saber si una pagina contiene iframe?
creo que se de varias paginas que pueden estar realizando ese tipo de ataques, lo que no recordaba el nombre de la técnica/ataque, así que clickjackin, jooder macho >.< ya te lo avía escuchado mencionar en algunos de tus vídeos/charlas/conferencias, pero como a día de hoy son tantos y e visto casi todos, sabe dios en cual lo nombras, ya estaba medio loko jejeje, pero lo dicho, como puedo hacer un test/scanweb para saberlo a ciencia cierta, por que en el código fuente del sitio a simple vista no se refleja nada, verdad?
Espero tu respuesta, sino por aquí por email plis ñ.ñ
Jonathan Novel
Saludos! ;-)
La idea está bastante bien, aunque hay cosillas que se me escapan. Forzar el renderizado del bg para evitar que el iframe oculte lo que sea esta muy bien, pero si mal no recuerdo tu puedes poner iframe que no sean gráficos y capturen los input del cliente... ¿no?
Amén de que puede que exista un iframe presente desde la parte servidor, váyase usté a saber por qué. xD
Bueno suena bastante guay, habrá que informarse mejor de como va todo este asunto =).
Y digo yo. Si bien estos ataques pueden ser devastadores, ¿Por qué cojones tuvo Adobe que poner sus preferencias accesibles desde la web?¿Por qué pones una parte tan delicada de tu reproductor en una versión web al alcance de cualquier ataque de javascript contra el DOM o una triquiñuela de este tipo?
Con lo fácil que es hacer un panel de preferencias en el panel de control o una aplicación con GUI predeterminada y abrir ese panel cuando cualquier enlace destinado a tu configuración de Flash Player. Ya es bastante difícil asegurar tu integridad con las vulnerabilidades que hay en la web como para que encima los servicios clave de la navegación web estén jodiendo exponiendo a la web algo tan íntimo como es tu propia conexión a internet.
como se puede saber si una pagina contiene iframe?
Instala NoScript ... y sufre con la cantidad de páginas que, dedicadas a la seguridad de usuarios y empresas, tienen clickjacking para que sus visitantes se entretengan :P
Y si instalas el Trafficligth de BitDefender, te encantará ver los intentos de phishing que se ponen en páginas que, por ejemplo, están encargadas de la protección de los datos personales de los ciudadanos, que es lo que me encontré en México :P
Muy bueno el escrito, como es tu gran costumbre, Chema, gracias :)
@Dario
Muchas gracias!
Saludos! ;-)
Publicar un comentario