Una noche de repente no puedes dormirte, y decides ir de cacería en busca de vulnerabilidades. Sí, de esas que días anteriores no te terminaban de funcionar y te decides a enviar un reporte a la compañía. ¡Unos días de espera, y… malas noticias! No fueron consideradas como vulnerabilidades en Facebook.
El día de hoy, les traigo un artículo a modo de debate, en el que se muestran dos reportes no fueron considerados como problema de seguridad en Facebook - aunque creo que quedará claro que son "weaknesses" o debilidades -. La duda me viene a la cabeza es si no son realmente fallos de seguridad que haya que arreglar. ¿Tendrán razón?
¿Será parte de asumir los riesgos que podría ocasionarle a unos pocos usuarios que no sean expertos en seguridad? ¿Será fácil para los malos utilizar estas "weaknesses"? ¿Podrá una nueva "Cambridge Analytica" utilizarlos en su provecho en un futuro? Veamos los siguientes vídeos con las PoC (Pruebas de Concepto)
PoC 1: Un Phishing a Facebook con una App nativa de Facebook
Como se puede ver en la PoC, es posible cargar sitios webs en las apps nativas de Facebook sin mostrar la barra de navegación, permitiendo hacer un ataque de Phishing perfecto al propio sitio de Facebook, y solicitar fácilmente la contraseña del login de Facebook.
En este primer vídeo se muestra como es posible bypassear el protocolo de deeplinks de la aplicación, para que cargue una URL externa en una Webview sin mostrar la barra de direcciones, como si se tratase de un enlace propio de Facebook, que en cierta parte lo es pero que luego termina por realizar una redirección, terminando por engañar a la whitelist de dominios propia de la aplicación.
Para replicar esta PoC de ataque basta con realizar una publicación con el enlace y accederla desde la app mobile:
PoC 2: Saltar validaciones de seguridad en redirects
Como se puede ver en el siguiente vídeo, es posible cargar iframes con sitios maliciosos, que permitiría por ejemplo hacer redirecciones sin pasar por el sistema link shim de Facebook. En el vídeo vemos como Facebook permite a terceros embeber iframes dentro de páginas - limitado para páginas con más de 2000 seguidores - para tener contenido personalizado y así ofrecer sus servicios directamente desde Facebook.
El problema con esto, es que muchas aplicaciones hacen uso de parámetros para hacer redirecciones o cargar contenido de manera dinámica a través del iframe, y como es de esperar no poseen las validaciones de seguridad necesarias.
Algunas PoCs de ejemplo que llevarían al El lado del mal sin pasar por link shim:
Desde Facebook me comentaron que ambos casos el problema no sería arreglado. En el primer caso porque detectarían en caso spam re-direcciones maliciosas o de phishing y las bloquearían, y en el segundo caso, porque estos iframes son cargados por terceros, sin importar si afecta al dominio principal Facebook.com
Probablemente tengan motivos para no dedicarle tiempo a arreglar este tipo de inconvenientes, y es verdad que tienen mecanismos de protección extras, puede pasar por asumir el riesgo de que atacantes se aprovechen de esto en casos puntuales y usuarios acaben sufriendo aunque tengan esos controles de seguridad.
Tal vez debieran arreglar las debilidades, como han hecho con las weaknesses en HSTS que mostraron los investigadores de ElevenPaths y luego ellos corrigieron. A usted lector, ¿qué le parece que deberían hacer con estas "weaknesses" los ingenieros de Facebook?
Autor: Ariel La Cono @ignaciolacono, San Luis, Argentina
 |
| Figura 1: Dos "weaknesses" de seguridad contra el Phishing que Facebook NO solucionará |
El día de hoy, les traigo un artículo a modo de debate, en el que se muestran dos reportes no fueron considerados como problema de seguridad en Facebook - aunque creo que quedará claro que son "weaknesses" o debilidades -. La duda me viene a la cabeza es si no son realmente fallos de seguridad que haya que arreglar. ¿Tendrán razón?
¿Será parte de asumir los riesgos que podría ocasionarle a unos pocos usuarios que no sean expertos en seguridad? ¿Será fácil para los malos utilizar estas "weaknesses"? ¿Podrá una nueva "Cambridge Analytica" utilizarlos en su provecho en un futuro? Veamos los siguientes vídeos con las PoC (Pruebas de Concepto)
PoC 1: Un Phishing a Facebook con una App nativa de Facebook
Como se puede ver en la PoC, es posible cargar sitios webs en las apps nativas de Facebook sin mostrar la barra de navegación, permitiendo hacer un ataque de Phishing perfecto al propio sitio de Facebook, y solicitar fácilmente la contraseña del login de Facebook.
Figura 3: Un Phishing a Facebook con una Webview en una app nativa de Facebook
Figura 4: Proteger tu cuenta de Facebook con Latch Cloud TOTP
Para replicar esta PoC de ataque basta con realizar una publicación con el enlace y accederla desde la app mobile:
https://www.facebook.com/logout.php?next=https://bit.ly/2jhoZyM&api_key=534210376601304Por si acaso, para evitar el impacto que pueda tener si caes en este tipo de ataques, pon desde ya que pongas un 2FA con Latch Cloud TOTP en Facebook, que hasta a los más experimentados puede que les engañe.
PoC 2: Saltar validaciones de seguridad en redirects
Como se puede ver en el siguiente vídeo, es posible cargar iframes con sitios maliciosos, que permitiría por ejemplo hacer redirecciones sin pasar por el sistema link shim de Facebook. En el vídeo vemos como Facebook permite a terceros embeber iframes dentro de páginas - limitado para páginas con más de 2000 seguidores - para tener contenido personalizado y así ofrecer sus servicios directamente desde Facebook.
 |
| Figura 5: Link Shim de Facebook |
El problema con esto, es que muchas aplicaciones hacen uso de parámetros para hacer redirecciones o cargar contenido de manera dinámica a través del iframe, y como es de esperar no poseen las validaciones de seguridad necesarias.
Figura 6: PoC 2 Demo de URL redirect sin pasar por Link Shim
Algunas PoCs de ejemplo que llevarían al El lado del mal sin pasar por link shim:
Facebook Won´t Fix them
Desde Facebook me comentaron que ambos casos el problema no sería arreglado. En el primer caso porque detectarían en caso spam re-direcciones maliciosas o de phishing y las bloquearían, y en el segundo caso, porque estos iframes son cargados por terceros, sin importar si afecta al dominio principal Facebook.com
 |
| Figura 7: Facebook won´t fix them |
Probablemente tengan motivos para no dedicarle tiempo a arreglar este tipo de inconvenientes, y es verdad que tienen mecanismos de protección extras, puede pasar por asumir el riesgo de que atacantes se aprovechen de esto en casos puntuales y usuarios acaben sufriendo aunque tengan esos controles de seguridad.
 |
| Figura 8: Nota de Facebook explicando las debilidades de HSTS |
Tal vez debieran arreglar las debilidades, como han hecho con las weaknesses en HSTS que mostraron los investigadores de ElevenPaths y luego ellos corrigieron. A usted lector, ¿qué le parece que deberían hacer con estas "weaknesses" los ingenieros de Facebook?
Autor: Ariel La Cono @ignaciolacono, San Luis, Argentina
Pues ponerse las pilas porque luego esas pequeñas debilidades van aumentando (como una pequeña infección localizada en un punto, puede llegar a ser una infección sistémica)..asique yo creo que no estan pa más sorpresas..pero Mark sabrá!
ResponderEliminar