Sistema anti-phising Garante

Acabo de leer acerca de una propuesta de sistema anti-phising denominada Garante. Lo curioso de esta propuesta es no sólo que es Española, sino que difiere bastante de otras de las propuestas realizadas en la actualidad. También me sorprende que, según la documentación que he leído, el autor parece estar regañado con las tildes (me he permitido el lujo de realizar las correciones ortográficas pertinentes cuando hago referencias literales a la documentación).

A continuación paso a comentar algunos párrafos del documento técnico de Garante:

En vez de intentar recopilar lo mas rápidamente posible firmas para identificar servidores web falsos, lo que hace es tener una base de datos de firmas capaces de identificar unívocamente un sitio web de forma 100 % confiable tanto en su contenido como en su direccionamiento IP. Para esto emplea técnicas criptográficas.

Garante funciona de la siguiente manera:

  • Descarga una base de datos con los “hash” SHA2 del contenido HTML del servidor web y de su dirección IP. Esta base de datos está firmada digitalmente.
  • Verifica la firma digital de la base de datos con la clave pública que dispone.
  • Se conecta al servidor web y descarga el código HTML de la página.
  • Realiza un hash criptografico del HTML que ha obtenido.
  • Compara el resultado que ha obtenido con el que aparece en la base de datos.
  • Realiza la resolución nombre-dns –> dirección IP.
  • Genera un hash criptografico de la dirección IP que obtiene de la resolución.
  • Compara el Hash con el de la base de datos.
  • Si todas las comprobaciones han sido satisfactorias y las operaciones criptograficas demuestran que el sitio al que se va a acceder no ha sido alterado o modificado, se lanza el navegador para acceder.

No entiendo por qué resume de forma separada el contenido de la página Web y la dirección IP, en lugar de hacer el resumen conjunto de ambas. Tampoco entiendo, cuando habla de SHA-2, a qué versión de la familia SHA-2 se refiere, al igual que la implementación utilizada de dicho algoritmo (compatible FIPS, OpenSSL, etc.).

De este modo, si el servidor desde el que se descargan las bases de datos fuera comprometido y las bases de datos alteradas, en este punto “Garante” detectaría la inconsistencia e informaría de la incidencia.

Entiendo que para conseguir que el servidor desde el que se descargan las bases de datos sea suficientemente seguro para aguantar una intrusión es que el proceso de firma de las bases de datos se realice de forma separada, en una máquina aislada, y preferiblemente sin conexión a la red. Si el proceso de firma se realiza en la misma máquina que almacena la base de datos, un intruso podría alterar la base de datos y firmarla.

Los sistemas anti-phising actuales se basan en la premisa de una actualización constante por parte del usuario y en optimizar los tiempos de respuesta a la hora de detectar e incluir en sus bases de datos los sitios que albergan contenido malicioso.

Realmente no veo mucha diferencia entre los sistemas actuales y Garante: ambos deben actualizarse periódicamente: Los bancos pueden cambiar ligeramente su página de acceso, pueden cambiar de dirección IP, etc. Lo que sí me parece significativo es el hecho de que Garante utiliza la política “todo aquello que no está explícitamente permitido está prohibido” lo cual me parece un aspecto muy positivo.

“Garante” emplea tecnología PKI pero tan solo necesita un par de claves publica (distribuida con el cliente) y privada (en manos de la organización) para verificar el origen de los datos.

Destacar que PKI no es una tecnología, sino una infraestructura formada por múltiples tecnologías y estándares. Aprovecharse de una PKI no hace que un producto sea automáticamente seguro. ¿Qué ocurre con las claves de firma que se utilizan para autentificar la base de datos? ¿Dónde se almacenan? ¿Existen copias? ¿Qué longitud de clave tienen? ¿Qué ocurrirá cuando el certificado asociado a la clave pública utilizada para comprobar la firma caduque? ¿Cómo se renueva? ¿Instalando una versión nueva del software? ¿Actualizándolo?

El origen de los datos no es lo único que debe interesar al usuario, sino su integridad. Puede que los datos procedan del repositorio central de eGarante pero, ¿qué garantiza que dichos datos son correctos y están al día? ¿Qué ocurre si un banco cambia de dirección IP? ¿O si el banco tiene una página de acceso para clientes que cambia periódicamente? Tendrá que existir un acuerdo tácito entre eGarante y el banco. ¿Qué ocurre si el número de bancos aumenta considerablemente? ¿Es escalable el sistema?

Así mismo, eGarante no puede proteger el usuario contra otros tipos de ataques, como capturadores de teclado (keyloggers), parásitos o troyanos.

Evitar confusiones: Al ser un elemento independiente del navegador se evita caer en confusiones y que, por ejemplo, una pagina web maliciosa trate de simular la interface o mecanismos de respuesta del programa dejando al usuario en una situación de indefension.

La independencia con respecto al navegador me parece un aspecto muy positivo, precisamente porque la mayoría de los usuarios sólo esperan ver un candado cuando intentan acceder de forma segura a la página de su banco, pero no saben con certeza en qué lugar de la pantalla debe aparecer dicho candado. En algunos navegadores el candado aparece en la barra de estado, mientras que en otros aparece en la barra de título (como Safari). Pero ninguno lo hace dentro de la zona visual del navegador. Separando el proceso de validación del navegador ayuda a evitar confusiones o malos entendidos por parte del usuario.

Un problema que encuentro es que se trata de una solución cerrada. Al no disponer del código fuente, me resulta imposible saber cómo funciona realmente este sistema. Así mismo, al ser una solución cerrada estoy dejando, en cierta medida, en manos de un tercero la capacidad de decidir si un sitio es auténtico o no. ¿Quién me garantiza que ese software funciona correctamente? Por añadido, es una aplicación autónoma para sistemas Windows. ¿Qué ocurre con el resto de usuarios, como los usuarios de GNU/Linux, FreeBSD, NetBSD, OpenBSD, Solaris o Mac OS X?

Parece que la distribución de la base de datos queda en manos de una sola entidad: el fabricante. ¿Qué ocurre si el fabricante sufre una intrusión? Su base de datos queda automáticamente comprometida. Quizá sería interesante implementar un modelo algo más descentralizado, de manera que la descarga de la base de datos pueda hacerse a través de varios sitios, que firman con claves diferentes, a fin de obtener ciertas garantías de la integridad de la base de datos. Otra solución es separar físicamente el proceso de firma del proceso de generación y distribución de la base de datos. Incluso me parecería interesante descentralizar el proceso de firma, por ejemplo en N entidades (separadas físicamente), de manera que la base de datos deba ser firmada simultáneamente por todas ellas. De esta forma, para poder comprometer la base de datos sería necesario comprometer N procesos de firma digital.

Otro punteo que quiero resaltar es que Garante no deja de ser un programa autónono, y por ello, comprometible. No creo que fuera demasiado difícil desarrollar un gusano o virus que se instale en el sistema, desactive, reemplace o comprometa el software de Garante. Podría ser interesante desarrollar un sistema de desafío, por el cual el cliente desafíe al sitio Web a que realice algún tipo de operación, cálculo o proceso, que sólo éste sabe o puede hacer, pero cuyo resultado pueda ser comprobado por el usuario.

Como conclusión, decir que me parece una propuesta interesante, aunque hay ciertos aspectos que no veo demasiado claros, como la apertura de código, independencia tecnológica del sistema operativo y la descentralización del sistema para repartir los puntos de ataque.

Advertisements

5 thoughts on “Sistema anti-phising Garante

  1. Hola, primero de todo presentarme, soy el autor de Garante. Agradezco tu profuso y extenso análisis del producto. Voy a intentar aclarar los aspectos que no te han quedado claros de la forma mas sucinta posible.

    1- Resumen por separado: Bien aquí la mutilación a parte de tener un orden, es poder distinguir la parte que no corresponde HTML / DNS de forma que resulte mas comprensible, por ejemplo, saber si el fallo esta en que tu DNS ha sido comprometido o simplemente que estas ante una pagina web cuyo contenido no corresponde con el correcto. Desde mi punto de vista el hacer esta parte de forma modular la hace mas comprensible.
    (Cuando empecé a leer esta parte pensé que ibas a preguntar porque no usar la misma clave privada DSA para igual que se firma la base de datos, firmar el contenido HTML / DNS, y pensaba responderte que todo obedece a un motivo de eficiencia, computacional-mente hablando es mas rápido un Hash que la firma.)

    Estoy utilizando SHA2-256 que cumple con el estándar NIST (los autores).

    2-Proceso de firmado: Efectivamente el host http://www.egarante.com NO se utiliza para el firmado, es obvio que si nos estamos tomando tantas molestias para asegurar la información, no íbamos a cometer un error de tal calibre. El proceso de firmado se realiza desde un host independiente, que para mas información es un sistema OpenBSD con acceso único mediante consola que tiene en ejecución dos procesos: uno que periódicamente verifica la concordancia de las bases de datos y otro que procede a firmar.

    3-Diferencias entre el modelo tradicional y garante: Sinceramente que plantees esto me lleva a preguntarme si he sido capaz de expresar correctamente el concepto puesto que, a mi juicio, la diferencia es obvia: Un sistema tradicional basado en firmas maliciosas, depende de la rapidez con la que se reporten sistemas que albergan contenido Phising, potencialmente puede haber ventanas de … ¿semanas? hasta que un ataque de phising se lanza y es detectado / archivado. Y convendras conmigo en que resulta *imposible* tener listados todos los sistemas que pueden estar siendo usados para hacer phising. Por contra, garante monitoriza un numero N de paginas web, esa monitorización cuando el sistema sea estable, sera cada minuto de forma que, la ventana de reacción por nuestra parte sera ínfima.
    Virtualmente puedes asegurar que *siempre* las bases de datos estarán disponibles y serán fiables, por contra nunca podrás hacer esta afirmacion sobre otra solución tradicional anti-phising, ya que seria temerario decir “Yo tengo listados todos los sitios maliciosos”, es imposible controlar cada una de las millones de conexiones que hay en el mundo.
    Por si nuevamente he fallado en mi expliación, te pondré un ejemplo: Imagina un edificio gubernamental donde el acceso se hiciera en función de si tu foto NO se encuentra en un archivo de potenciales terroristas, Obviamente si bien te puedes asegurar que Bin Laden no va a poner una bomba, estarás de acuerdo conmigo en que el sistema es todo menos fiable. Por contra, el tipo de acceso que repreguntaría Garante seria el contrario, para acceder al edificio necesitas que tu huella dactilar se encuentre dentro de una base de datos y antes de entrar, has de poner tu dedo en un lector.

    4- Caducidad de la clave: En este punto creo que cometes un error de concepto, si te fijas en la documentacion hablo de un par de claves DSA, no de certificados digitales con fecha de caducidad por lo que la parte de la renovacion, no tiene sentido. Respecto a la parte de revocacion, obviamente si la clave privada fuera comprometida supondría un problema de enormes proporciones por lo que las medidas de seguridad para su protección son extremas. En el caso de su compromiso, habría que liberar una nueva versión de Garante con la nueva clave publica. Naturalmente la posibilidad de que se comprometa dicha clave es remota puesto que no es algo que se descuide. Recientemente pude asistir a la ceremonia de la CA raiz del DNI digital Español, y te diré que, por ejemplo, la seguridad de toda la infraestructura y los (futuros) 40.000.000 de certificados digitales descansa en una única clave privada de la CA raíz dentro de un HSM. Para bien o para mal así funcionan los sistemas de PKI.

    Para el firmado, estoy usando una clave DSA de 1024.

    Respecto al tema de los keyloggers / troyanos, nada que objetar, garante no ofrece esa protección, que por otra parte, creo debería estar en manos de otros elementos de seguridad.

    Respecto a los mecanismos de desafío / respuesta, me parece muy interesante el planteamiento, pero al final, siempre acabaría teniendo que “Hardcodear” algo dentro del código fuente (alguna clave) que en manos de alguien muy laborioso, seguramente consiguiera des-ensamblar. Estuve planteándome que el cliente enviara un HASH SHA2 del ejecutable, pero cuando pensé mas detenidamente en ello caí en la cuenta de que en el momento que alguien pudiera cargar una DLL al .exe el ejecutable seguiría siendo el mismo y por contra, su comportamiento no.

    5-Liberación de código, múltiples plataformas: Efectivamente me planteo en un momento dado liberar todo el código fuente, piensa que el proyecto no lleva mas de 1 semana en marcha y aun quedan muchas decisiones por tomar, entre ellas esa. Respecto al tema de introducir mas plataformas, te diré que yo soy usuario habitual de Linux y que Garante ha sido desarrollado en varios sistemas Windows ejecutados bajo VMware en una Fedora, así que en el momento en el que solucione otras prioridades, cuenta con una versión para Linux.

    6- Múltiples firmas / Escalabilidad: Respecto a lo que tu propones de montar sistemas sobre-descentralizados es algo en lo que ya había pensado, de primeras, para que hubiera múltiples repositorios de las bases de datos (alta disponibilidad) y como te decía en el punto anterior, Garante es un sistema Beta y la infraestructura actual, también. Según vayamos creciendo incidiremos en ese aspecto.

    Respecto a la escalabilidad, sinceramente otra vez me vuelvo a preguntar si acaso no me exprese con suficiente claridad en la documentacion, piensa que, es mucho mas escalable / mantenible tener … ¿10? bases de datos de 10 Bancos a tener 10.000 bases de datos con sitios maliciosos.

    Por otra parte si bien tu análisis técnico ha sido riguroso y excelente, obvias la parte que, para mi, es mas importante: el impacto social. Me explico, una de las cosas en las que mas hago hincapié en la documentacion es que actualmente a la gente no se le ha explicado cual es la forma correcta de llegar a su banco, la gente sabe que http://www.banco.com es el banco pero nada mas. Lo que yo pretendo con Garante es ofrecer un sistema extremadamente sencillo y fácil de utilizar por cualquiera, de forma que resulte fácil “educar” a la gente y que aumente su conciencia sobre la seguridad informática. Obviamente un usuario que comprenda el hecho de que acceder al banco usando Garante es la forma de no tener sustos, es un usuario que se lo pensara dos veces antes de hacer “click” en un enlace que le haya llegado por correo electrónico. Y este es el fin ultimo de la herramienta, ofrecer seguridad robusta de una forma fácil y sencilla al alcance de todos los perfiles.

    Espero haber aclarado tus dudas al respecto y si tienes alguna otra inquietud no dudes en comunicar-mela, de hecho, pienso que hubiera sido interesante antes de publicar en tu weblog todo esto, que me lo hubieras enviado y haber podido incluir mis respuestas.

    Un saludo y un fuerte abrazo

  2. Ante todo, quiero pedir mis disculpas por no haberme puesto en contacto con E-garante antes de haber hecho públicos mis comentarios. Problemas de ser novato en esto.

    Procedo a comentar los puntos que resaltas en tu comentario anterior:

    Ahora sí entiendo por qué separas la firma de los datos de DNS de la firma del código HTML, y me parece razonable, aunque no le veo mucha utilidad. Para mí, como usuario que soy, no creo que sea importante saber dónde está el problema (si me han comprometido el DNS o alguien ha comprometido el sitio Web), sino saber que existe un problema con el sitio Web.

    Me alegra saber que utilizas SHA2-256, pero, ¿quién ha implementado dicho algoritmo? SHA2-256 es un estándar NIST, pero la implementación de dicho algoritmo debería cumplir además FIPS-140. No basta con utilizar un algoritmo aprobado por el NIST, sino implementarlo adecuadamente. Actualmente, sé que OpenSSL cumple FIPS-140, tal y como se anuncia en http://linuxdevices.com/news/NS4742716157.html.

    También me gustaría hacerte una sugerencia, y es que utilizases diferentes algoritmos de resumen digital simultáneamente, en lugar de utilizar uno sólo. Esto es lo mismo que hace la comunidad de FreeBSD en sus ports: resumen separadamente utilizando MD5, SHA-1 y RIPE MD-160, y luego firman los tres resúmenes. De esta forma, resulta mucho más complejo montar un ataque de colisión. Personalmente, me inclinaría por resumir la información utilizando MD5, SHA2-512 y RIPE-MD160, y DSA-2048 para firmar los tres resúmenes digitales.

    Me alegra muchísimo ver que estáis usando OpenBSD, y que el proceso de firma se hace de forma separada un una máquina independiente.

    Espero también que algún día Garante implemente firmas múltiples sobre la base de datos. Por ejemplo, si la base de datos se va a distribuir a N servidores, previamente haya sido firmada por M principales. De esta manera, para poder comprometer la información contenida en la base de datos sería necesario comprometer los M principales para falsear las múltiples firmas de la base de datos.

    Me quedó clara la diferencia entre el sistema tradicional y el sistema propuesto por Garante y me parece francamente interesante.

    Lo que quería expresar en mi comentario es que tanto los sistemas tradicionales como Garante necesitan actualizarse constantemente. En el caso de los sistemas tradicionales, monitorizando los posibles sitios responsables de Phising, en el caso de Garante, monitorizando las páginas Web de las entidades financieras. Queda claro, sin embargo, que resulta más controlable y sencillo monitorizar unas pocas páginas Web de entidades financieras.

    Nada que objetar en este aspecto, precisamente porque me parece un enfoque radicalmente distinto de las soluciones actuales que ya han demostrado su ineficacia.

    También veo que la renovación y revocación de las que hablaba en mi comentario pueden sustituirse mediante la liberación de nuevas versiones de Garante, lo cual es totalmente plausible. Lo que sí creo sería necesario es ofrecer algún mecanismo que permita firmar digitalmente los ejecutables de Garante.

    Otro comentario que me no quiero dejarme en el tintero es acerca de la forma en que Garante se comunica con el usuario. Como no he desarrollado nunca para Windows, me gustaría preguntar acerca de la posibilidad de sustituir las cajas de diálogo estándar por cuadros emergentes (bocadillos) ligados al tray o área de notificaciones de Windows. Lo comento principalmente porque al utilizar cajas de diálogo estándar de Windows, es posible engañar al usuario de tal forma que un sitio Web, mediante JavaScript, pudiera desplegar cajas de diálogo similares a las de Garante. ¿Qué opinas?

    En conclusión, no quiero que entiendas mis comentarios de forma negativa. Todo lo contrario. Me parece que Garante es una iniciativa muy interesante y te animo a que sigas con ella, mejorándola. Por mi parte, estoy deseando probar una versión para Linux y Mac OS X.

  3. Hola, ante todo gracias por publicar mi comentario, creo que finalmente de todo esto ha quedado un debate francamente interesante.

    Respecto a los algoritmos de firmado, me decante por SHA2 debido a que había leído noticias que daban por inseguros (incluso he llegado a ver pruebas de concepto) MD5 y SHA1 así que directamente me cure en salud usando SHA2, estoy utilizando la implementación SHA2 de “Aaron Gifford” que hasta donde yo se, es bastante robusta.

    Respecto a separar las comprobaciones HTML / DNS supongo que eso me viene de que como usuario de sistemas Linux, censuro la filosofía Windows de “Se ha producido un error” sin aportar mas información, a todos nos ha pasado estar usando un programa windows y de repente somos informados de un error sin mas detalles lo que impide determinar donde se ha producido, así que me pareció interesante ir informando paso a paso y decir donde se ha producido el error.

    Respecto a implementar múltiples firmas, me parece una opción extremadamente segura y fiable pero quizás, el gasto computacional que habría que invertir haria bastante mas lento al programa. Yo creo que las medidas de seguridad hay que parametrizarlas en función de cada proyecto y así como por ejemplo si estuviéramos hablando de datos sanitarios o datos personales entendería duplicar o triplicar las medidas de seguridad, para el caso concreto de Garante, me parece que el hecho de que las bases de datos estén firmadas por una única firma cumple con el objetivo del sistema (asegurar la integridad de las bases de datos) de una forma que sería muy muy compleja de romper. Por lo que estarás de acuerdo conmigo que si bien el sistema podría ser mas robusto, lo que hay implementado hasta ahora es, objetivamente, un buen sistema de seguridad.

    Respecto a lo de firmar digitalmente los ejecutables, te refieres a publicar en la pagina web sus, por ejemplo, sumas SHA2 ?

    Tienes toda la razón en el asunto de los dialogos MsgBox como formula para interactuar con el usuario, el lunes (espero) ya estará en el servidor una versión que implementa sus propios cuadros de dialogo con el logo de la aplicación etc etc.

    Un saludo y muchas gracias por tus sugerencias, están siendo francamente constructivas.

  4. No hace falta que me agradezcas el haber publicado tu comentario: era lo menos que podía hacer 🙂

    Separar las comprobaciones DNS de HTML me parece una buena idea, aunque insisto en que creo que a la mayoría de los usuarios (erróneamente) no les suele preocupar la causa de los problemas, sino el hecho de que existe un problema en sí mismo. En cualquier caso, me parece bien la decisión de separar las comprobaciones.

    Con respecto al tema de las múltiples firmas, tampoco estaba pensando en hacer 10 firmas. Por ejemplo, para empezar, podría bastar con una única firma digital, como haces ahora. Sin embargo, podría ser interesante, en un futuro, permitir que la base de datos estuviera firmada dos veces, mediante dos claves DSA distintas, llevadas a cabo en dos máquinas físicamente diferentes y separadas.

    Cuando hablaba de la firma digital del ejecutable, me refería al hecho de utilizar alguna tecnología, como Authenticode, que permita firmar digitalmente el ejecutable, para luego poder comprobar su integridad. Utilizar un resumen SHA-2 no me parece una idea aconsejable, ya que la mayoría de los usuarios no saben ni lo que es, ni cómo hacerlo. Estaba pensando en tecnologías como Authenticode en plataformas Windows, o paquetes RPM firmados con PGP en plataformas Linux, que permiten, de forma automática, validar la integridad y procedencia del instalable.

    De momento, eso es todo. Ánimo, y al toro.

  5. rather radical. Even so, I am sorry, because I can not subscribe to your whole plan, all be it refreshing none the less. It would seem to everyone that your commentary are not completely validated and in actuality you are generally yourself not totally certain of the point. In any case I did appreciate examining it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s