martes, 23 de junio de 2009

La e-Administración dando mal ejemplo: El Padre que no tiene padre

Como en otros post anteriores, hoy vamos a ver un ejemplo de cómo en esto de la seguridad las medias tintas no garantizan el cumplimiento de los objetivos planteados.

El caso de hoy tiene que ver con las garantías que la AEAT nos quiere dar sobre la fiabilidad del software PADRE que podemos descargar de su página Web para la realización de la declaración de la renta. Voy a plantear este ejemplo como si de un análisis de riesgos se tratara, para mostrar como al final, no se logra garantizar el objetivo por el cual se plantea la medida de seguridad.
  • Objetivo de seguridad: Garantizar la integridad del programa Padre o lo que es lo mismo, que todo ciudadano pueda tener la certeza de que la aplicación Padre que está descargada en su PC y que va a instalar para hacer la renta es la aplicación legítima elaborada por la AEAT y no una aplicación maliciosa.

  • Amenaza: Intentar engañar al usuario y colar una aplicación malware que robe datos dentro del PC del ciudadano. Para ello, podría aparecer un sitio Web falso que tratara de engañar a los contribuyentes y que pusiera a su disposición un ejecutable manipulado.

  • Salvaguarda: En este caso, se publica el código MD5 de la aplicación ejecutable en la Web de la AEAT.

  • Beneficio de seguridad: El usuario puede descargar el ejecutable y comprobar en su PC si la aplicación que se ha bajado coincide en su MD5 con la publicada por la AEAT en la Web www.aeat.es. Es una comprobación básica de la integridad del fichero que demuestra la no manipulación.

Ambas capturas corresponden a las garantías de integridad que actualmente proporciona la Web de la AEAT respecto al programa PADRE que podemos descargar de la Web.


Con esta solución parcial e incompleta, no se logra mitigar el riesgo planteado por la amenaza de suplantación. ¿Por qué?

Cualquier atacante que elabore una aplicación maliciosa que vaya a simular ser el programa Padre lo que hará seguramente será distribuirla probablemente desde una Web que suplante también a la Web de la AEAT. Ya en su momento la Agencia Tributaria sufrió un caso de phishing algo más simple donde solicitaban datos bancarios bajo el señuelo de que se devolvía antes la renta. Evidentemente este atacante lo que también haría sería colocar en la Web suplantada el correspondiente código MD5 de la aplicación maliciosa que quería hacer pasar por el programa PADRE y el ciudadano seguramente, aun comprobando la integridad, sería victima del engaño.

Para que esta hipótesis no pudiera ser planteada, la AEAT debería "demostrar" que su página Web se corresponde con el dominio www.aeat.es, utilizando como medio de seguridad la presentación de un certificado digital. Algo que la Banca electrónica ya tiene más que asumido parece que en las Administraciones Públicas no está todavía a la orden del día, y eso que ya admiten trámites electrónicos. Sin embargo, no está disponible el acceso bajo https a la Agencia Tributaria, como muestra esta captura donde el certificado de servidor apunta hacia un dominio akamai que es donde deben estar alojados los servicios Web para satisfacer la demanda de ancho de banda y balanceo de carga.



Alonso Hurtado ya planteo esta problemática en el post "La sede electrónica en el nuevo modelo de e-Administración".

Artículo 10. La sede electrónica.
1. La sede electrónica es aquella dirección electrónica disponible para los ciudadanos a través de redes de telecomunicaciones cuya titularidad, gestión y administración corresponde a una Administración Pública, órgano o entidad administrativa en el ejercicio de sus competencias.

Artículo 17. Identificación de las sedes electrónicas.
Las sedes electrónicas utilizarán, para identificarse y garantizar una comunicación segura con las mismas, sistemas de firma electrónica basados en certificados de dispositivo seguro o medio equivalente.


Por tanto, de nuevo tenemos como hay más de "sensación de seguridad" que de "protección real de la seguridad".

  • Objetivo de seguridad: Garantizar la integridad del programa Padre o lo que es lo mismo, que todo ciudadano pueda tener la certeza de que la aplicación Padre que está descargada en su PC y que va a instalar para hacer la renta es la aplicación legítima elaborada por la AEAT y no una aplicación maliciosa.

  • Objetivo no cumplido dado que la Web donde se coloca el HASH MD5 no realiza la autenticación de servidor. Engañar al ciudadano sería algo tan trivial como suplantar la Web de la AEAT, colocar el malware que se haría pasar por el programa PADRE y publicar el MD5 del troyano en la propia Web falsa.
    Si tenemos integridad sobre la aplicación software que descargamos, pero no tenemos autenticación sobre si el HASH que utilizamos para verificar la integridad es correcto o no, por tanto, el mecanismo pierde toda su eficacia.


Otro caso más donde se demuestra que las medias tintas no logran la protección deseada.

2 comentarios:

Joseba Enjuto dijo...

Una de cal... ¿Cuantas de las personas que se han descargado el programa PADRE han comprobado el hash? Incluso en este sector, me apuesto a que no muchas... De todas formas, el algoritmo seleccionado tampoco es el más seguro, a día de hoy.

Y otra de arena. Porque la mayor parte de la gente que haya descargado el programa PADRE seguramente haya navegado directamente a la web de la AEAT, así que para poder suplantar la web de forma efectiva el atacante también debería haber realizado algún tipo de ataque con éxito sobre la resolución DNS de la víctima. Y en ese caso, si la víctima ya está afectada, poco importa ya si es el falso programa PADRE u otro el que acaba campando a sus anchas en el equipo de la víctima... Vamos, que de nuevo la parte más vulnerable es el usuario que, víctima del phishing, se descarga el programa a partir de esos enlaces. Y esos usuarios no suelen verificar el hash...

Paco dijo...

Y en vez del MD5 de la página, ¿No hubiera sido más cómodo "firmar" el código ya sea con las tecnologías del S.O. o empleando el certificado de la FNMT ?.

 
;