Dirección Electrónica Única (DEU), usabilidad, y distribución de módulos criptográficos vulnerables

Hola,

Una nota breve para hablar un poco sobre el proceso de creación de una Dirección Electrónica Única (DEU) a través del servicio telemático que ofrece la Administración General del Estado.

Por cierta deformación profesional, cuando suscribo un servicio, especialmente si es público, promovido y tutelado por el Estado, tiendo a reflexionar sobre cómo se pone a disposición del ciudadano en términos de usabilidad, y especialmente, desde el punto de vista de la seguridad. El otro día hablamos del Tesoro Público, y hoy toca hablar de las DEU.

Sobre el tapete la idea de poder informar de una DEU es brillante. Poder suscribir alertas de Hacienda, Tráfico y de cualquier organismo que las permita es útil y cómodo para el ciudadano. Poder recibir en el móvil o en el correo electrónico un aviso que nos afecta es algo siempre digno de alabar. Veamos ahora la parte práctica.

Examinando …

Lo primero que debemos tener claro cuando vamos a contratar algo es leer bien la letra pequeña. En este caso, lo primero es comprobar qué requisitos debemos cumplir para poder suscribir una DEU. Hoy estoy generoso, y no haré comentarios sobre el certificado de la URL de partida en la que podemos darnos de alta para obtener una DEU (https://notificaciones.administracion.es/) Dejaré esto para los lectores con ganas de hacer alguna que otra verificación, a los cuales también invito a inspeccionar las condiciones básicas de usabilidad.

Como podemos comprobar, mal empezamos, porque si la página es conforme a WAI-A (o eso dice el pie de página), lo primero que queda claro es que no es conforme a WAI en los niveles más excelsos, es decir, doble A y triple A (aspectos que creo que un Gobierno debería tener en cuenta si desea dotar a sus servicios de la máxima usabilidad y accesibilidad). No voy a perder el tiempo en realizar un test de conformidad, algo que os dejo a vosotros a modo de ejercicio práctico.

Volviendo a los requisitos, son los siguientes:

requisitos DEU

Es aquí donde empiezan las bromas, ya que:

  • Se nos invita a usar una versión de Adobe Acrobat del año de la polca (Mayo del 2001), vulnerable y que hace ya años que no se suministra a los usuarios. Ya ni se llama «Acrobat» como dice el anuncio de requisitos. Se llama Acrobat Reader (a no ser que quieran que licenciemos el producto de generación e impresión PDF completo, claro)
  • Nos invitan a poder usar Netscape Navigator, un producto que lleva discontinuado desde el 1 de marzo de 2008, y que hace años que estaba muerto. La versión 6.0 que citan data de 2001. De la versión de Internet Explorer, ni hablemos. De la de Mozilla, tampoco.
  • Se nos pide la instalación de unos misteriosos módulos de seguridad.

Sobre estos módulos, se nos ofrece la siguiente información:

modulos seguridad

Vayamos a la zona de descarga:

descargas

Obviemos hablar de versiones, que me pongo nervioso.

La parte fea de la película

El método de instalación de los módulos de seguridad, si empleas Internet Explorer, ya podéis imaginar cuál es. ¿Pero esto qué broma es? ¿Qué clase de protección criptográfica se basa en instalar componentes ActiveX descargados en remoto en mi equipo? ¿Se ha parado a pensar alguien qué pasaría si un atacante lograse comprometer ese control y lo reemplazase por uno malicioso? ¿Qué broma es esa en la que necesito descargar elementos de alto riesgo en mi máquina para poder firmar una transacción electrónica?

En el caso de Mozilla, la cosa no pinta mucho mejor:

error libreria

Mozilla-JSS. ¿Y esto se supone que lo tiene que comprender el ciudadano de a pie? ¿Qué cara pondrá la gente cuando se meta en esa URL y vea cosas del tipo JSS uses the NSPR and NSS libraries for I/O and crypto. JSS version 3.0 linked statically with NSS, so it only required NSPR. JSS versions 3.1 and later link dynamically with NSS, so they also require the NSS shared libraries?

Haciendo un poco de seguimiento al control ActiveX, resulta fácil localizar la petición en la siguiente URL:

GET http://notificaciones.administracion.es/PortalCiudadano/CABS/PaqueteSin/SNAE_MSA.cab HTTP/1.1

Nos bajamos el paquete, e inspeccionamos. El fichero .inf contiene las instrucciones para desplegar en la máquina. Registra los componentes (que también vienen en el paquete) SNAE_CAPIWRAP.dll, capicom.dll y SNAE_MSA.ocx en el directorio %11%, suerte que los programadores han dejado un comentario para interpretar esto:

;Archivo INF de SNAE_MSA.ocx
;DestDir puede ser 10 para el directorio de Windows, 11 para el directorio Windows\System(32) o se puede dejar en blanco para el directorio Occache.

También se han dejado ahí un signature=»$CHICAGO$», debe ser que algunos se ha criado por esos lares. Si alguien tiene curiosidad por saber sobre CAPICOM, que eche un ojo a la Technet.

Vulnerabilidades …

Lo realmente preocupante es que, a poco que os molestéis en ver el paquete suministrado desde la descarga oficial de notificaciones.administracion.es, veréis que se distribuye el módulo CAPICOM (Cryptographic API Component Object Model) con versión 2.1.0.1

capicom

¿Y por qué incidir en esto?. Sencillo. Es un producto vulnerable. Si repasamos el KB 931906 de Microsoft obtendremos que:

capicom

No sin gran asombro descubro que esta vulnerabilidad en CAPICOM data de mayo de 2007, y fue calificada como altamente crítica. Consiste en errores indeterminados a la hora de manejar ciertas entradas al módulo criptográfico, lo que finalmente se traduce en poner en bandeja que un atacante ejecute código remoto en la máquina del usuario por el mero hecho de visitar un sitio Web malicioso construido a tal efecto.

Ante el riesgo que implica algo tan dramático como que un desconocido ejecute en nuestras máquinas algo tan serio como código arbitrario, surge el natural consejo de no usar el servicio DEU (por lo menos los servicios que tiran de la criptografía, especialmente la firma) hasta que se ponga a disposición de los usuarios una versión no vulnerable de CAPICOM. No estaría de más que los responsables le dieran una vuelta a la necesidad de introducir controles ActiveX en un sistema para procesar transacciones, porque basar las cosas en ActiveX y en cualquier otro componente, como Mozilla JSS, es una bomba de relojería que hace que ante una vulnerabilidad, los usuarios queden expuestos. Hay mejores maneras de afrontar este tipo de necesidades.

Como siempre, me pongo a disposición de los responsables del servicio para cooperar en lo que sea necesario. Por lo pronto les he enviado un correo avisando, espero caiga en buenas manos.

Un saludo,

16 comentarios sobre “Dirección Electrónica Única (DEU), usabilidad, y distribución de módulos criptográficos vulnerables

  1. Sergio,

    Eso de «$CHICAGO$» es el nombre en clave de Windows 95, y si no recuerdo mal es frecuente encontrarlo en los ficheros .INF de productos destinados para Windows 95 o Windows 98, como controladores de dispositivo y otros módulos.

  2. Muy interesante. No obstante hay algo que no me encaja y sólo es una pregunta, sin ánimo de polemizar ni nada similar. Has barajado la opción de esperar una respuesta «oficial» antes de publicar esta entrada? Lo digo más que nada para que los «malos» no juegen con ventaja o alguien con mucho tiempo libre se dedique a trastear lo que no debe. Es simplemente el dilema de siempre…….. es bueno o malo hacer públicas según que vulnerabilidades ?

  3. Edgard,

    El objetivo de mi mensaje es advertir a los usuarios que el uso de esos componentes vulnerables implica riesgos para sus equipos.

    En ningún caso es una llamada a usuarios maliciosos, ni tampoco es un disclosure: la vulnerabilidad que documento existe, y es conocida, lo que hago es simplemente dar a conocer que el uso de ese componente es vulnerable, pero no ofrezco patrones para, por ejemplo, comprometer el servidor desde el cual se sirve, valga la redundancia, el componente. Nada más lejos de la realidad y mis deseos.

    No he recibido respuesta oficial por parte de los responsables del servicio, por cierto.

    Un saludo,

  4. El problema – a mi modo de ver – son las nulas capacidades criptográficas avanzadas disponibles en los navegadores. En el caso de mozilla ‘al menos’ tiene una función muy básica para realizar firmado crypto.signtext, en el caso de Explorer AFAIK, siempre tienes que ‘morir’ a un componente ActiveX, llamalo CAPICOM o llamalo de otra forma (CAPICOM, a día de hoy, esta deprecated por la propia Microsoft) De ahí que cada web se monte su reino de taifas a la hora de implementar. Como curiosidad, yo he usado con bastante satisfacción CryptoApplet http://forja.uji.es/projects/cryptoapplet que permite firmar en múltiples formatos y es multiplataforma.

  5. Creo que te pasas cuando indicas que se nos está invitando a usar software obsoleto. Un profesional de la informática como tú seguro que tiene muy claro la diferencia entre los «requisitos mínimos» y el «software recomendado».

    Saludos.

  6. anónimo,

    Ciertamente mi redacción es mejorable. Lo que creo que es obvio es que la definición de requisitos mínimos se aleja mucho de la realidad, ya que incluye productos descatalogados.

    Lamento el tono de esa aseveración. Me lo anoto para la próxima.

  7. Puntualizar algo:

    a) Dices: «Se nos invita a usar una versión de Adobe Acrobat del año de la polca (Mayo del 2001), vulnerable y que hace ya años que no se suministra a los usuarios. Ya ni se llama «Acrobat» como dice el anuncio de requisitos. Se llama Acrobat Reader». Y respondo: 1º: que yo leo «Acrobat Reader» y no «Acrobat» en la página de los requisitos. 2º: que dice, versión 5.0 O SUPERIOR. Tú seguramente utilizarás las últimas versiones de todos los productos, pero no así el resto de ciudadanos. A mí me parece estupendo que pueda utilizar mi versión 6.2 o 7.1 o 5.5 y no únicamente la última del mercado que posiblemente casi nadie utilizará hasta dentro de unos meses. Y no es que «se nos invite» sino que te dicen que si tienes una versión antigua, como la 5, pues tranquilo que vas a poder utilizarla.

    b) Dices: «Nos invitan a poder usar Netscape Navigator, un producto que lleva discontinuado desde el 1 de marzo de 2008, y que hace años que estaba muerto. La versión 6.0 que citan data de 2001. De la versión de Internet Explorer, ni hablemos. De la de Mozilla, tampoco.». Y yo digo: que lleve «discontinuado» desde 1 de marzo de 2008 no quiere decir que la gente lo haya dejado de utilizar, volvemos a lo mismo que con el Reader… y lo mismo respecto al resto de navegadores… te están diciendo que es compatible con versiones antiguas, no que se requiera una versión antigua…

    Crítica: ¿tú realmente piensas que seria mejor requerir a los usuarios las últimas versiones de los productos?. Tú por ejemplo no estás utilizando la última versión del wordpress, por lo que eres vulnerable a ciertos ataques XSS.
    Lo ideal es requerir los productos que la gente utilice con más normalidad, y la última versión de un producto no es la más utilizada.

  8. anonimo2,

    Creo que en mi anterior comentario dejaba claro que la crítica es a la sensación de «escasa actualidad», es decir, yo cuando leo esos requisitos tengo la impresión de que no es actual, porque habla de versiones y productos descatalogados. Para mí decir que el requisito mínimo es Internet 5.5, o Mozilla 1.5 es una manera poco adecuada de citar los requisitos mínimos, porque como tú mismo dices, lo adecuado creo que sería recomendar lo habitual, y creo que las versiones mínimas recomendadas en esta página no son las habituales.

    Los usuarios creo que tienen que tender a, en la medida de lo posible y huyendo de betas y prototipos, a tener en sus equipos las últimas versiones actualizadas que se consideren estables. Por muy bien que funcione la aplicación en términos de compatibilidad anterior, citar Internet Explorer 5.5 y Navigator 6.0 creo que no es lo normal ni lo recomendable. Para mí sólo causa sensación de no ser información actualizada. Y si te empeñas (no tú, la Administración) en decir que esos son los mínimos, haz una nota en la tabla de compatibilidad dejando claro que aunque funcione, que se tenga en cuenta que son productos vulnerables. Es lo mínimo que se puede pedir a alguien responsable cuando declara estas cosas en un resumen de requisitos.

    Por otro lado, el que yo haga upgrades selectivos de WordPress creo que nada tiene que ver en lo que comentamos. De hecho es normal que entre parche y parche haya una ventana de no actualización (es lo malo de no estar en casa todo el día pegado a la pantalla) :)

    Las DEU es un servicio público, patrocinado por el estado, que está distribuyendo software vulnerable con una antigüedad que hace injustificable la demora (desde 2007). Mi blog es personal, no lo patrocina la Administración, tiene una clara nota explicativa en los términos y condiciones especificando precisamente estos casos, y rara es la ocasión en la que está en producción con una versión vulnerable más allá de lo que tarde en regresar a casa y parchear (el parche es de ayer, y ten por seguro que a lo largo del día estará actualizado). La nueva versión se publicó ayer mientras dormía, dame algo de tiempo a estudiar los parches y cómo y cuándo aplicarlos :)

    Por cierto, ya que sacamos el tema, la lista completa de tickets está en:

    http://codex.wordpress.org/Changelog/2.7.1
    http://core.trac.wordpress.org/query?status=closed&milestone=2.7.1&resolution=fixed&order=priority

    De entre todos los tickets, creo que te refieres al 8767:

    http://core.trac.wordpress.org/ticket/8767

    Parece que es un problema asociado a IE6, lo que podría efectivamente dar pie a ataques de este tipo (empleando UTF-8). Se ha detectado en bbPress hace tiempo, pero se ha estado retrasando debido a una controversia sobre si el parche es efectivo mitigando el riesgo o no, algunos desarrolladores decían que lo adecuado era hacer blanking ante patrones XSS, otros decían que no, en fin. Finalmente está en el paquete actualizado.

    Sobre este asunto hay una lectura interesante en:

    http://applesoup.googlepages.com/bypass_filter.txt

    Tan pronto llegue a casa, actualizaré. Aunque tengo mis dudas, porque este sitio opera en ISO-8859-15 y no en UTF-8, con lo que no tengo claro el nivel de impacto, porque no me queda claro al ver la documentación si el trigger es el charsetting del blog o del navegador cliente que lo visita. El RSS tampoco se sirve en UTF-8.

    El otro ticket de seguridad no me preocupa. No opero en SSL (http://core.trac.wordpress.org/ticket/8641). Hay uno de administración que no aplica, ya que no existen usuarios registrados.

    Un saludo, y gracias por tu aportación :)

  9. Jajaja, muy buena respuesta Sergio :), no quería que mal interpretaras mi comentario, que lo hacía desde el «cariño».

    En cualquier caso yo pensaba que una persona como tú no necesitaría esperar a que salieran parches para, en este caso, tu wordpress, sino que tú mismo corregirías los bugs ;)

    Y sí, era el ticket 8767.

    Un cordial saludo

  10. Tranquilo hombre, yo parezco borde y serio, pero no lo soy :)

    ¿Corregir mis propios bugs? Puf, a veces intento anticiparme, sobre todo cuando hay 0day que se pueden mitigar con toqueteo de PHP (el caso de register_globals es el típico) y si hay problemas con cosas serias, como autenticación y compromiso del servidor, intento poner las medidas que están a mi alcance (no soy root en mi hosting)

    Pero creo que corregir yo sólo los bugs … eso mejor se lo dejamos a los expertos :)

    Un saludo, y en serio, se agradece la crítica constructiva. Sigue haciéndola.

  11. Este artículo que acabo de leer es absurdo de cabo a rabo, sin ánimo de ofender. Efectivamente las versiones mínimas que exigen para el uso de este tipo de servicios son antiguas y obsoletas, pero… ¿qué ocurre con usuarios que tengan equipos con Windows 98, donde Internet Explorer 7 no funciona?

    El objetivo de esos requisitos mínimos (por eso siempre se habla de versión X o superior), es que los servicios puedan llegar a la mayor cantidad posible de ciudadanos. Luego es responsabilidad de cada usuario el decidir si desea instalar programas de última generación o no. Es una especie de «ahi tenéis la plataforma, usadla».

    Haciendo un símil que se entiende bastante bien: el Estado pone a nuestra disposición carreteras. ¿Podemos exigir que todos los coches que circulen por ellas estén dotados de ABS, airbags, limitador de velocidad, avisador acústico del cinturón…? Evidentemente NO. El Estado pone las carreteras, y luego allá cada uno con lo que haga con su coche, su vida y su dinero. Pues esto es exactamente lo mismo.

    Independientemente de lo dicho, estoy de acuerdo en que este es un país de pandereta, y como tal, este tipo de servicios dejan mucho que desear. Pero tampoco es necesario alimentar la paranoia de los usuarios con argumentos tan poco sólidos.

    Un saludo.

  12. Ramón,

    Tu crítica es bienvenida. Puedes llamarlo como quieras, y a mi me puedes calificar como quieras, pero que un servicio público esté mal programado e implementado, provocando no sólo problemas de accesibilidad sino de seguridad, para mí sólo tiene el calificativo de chapuza soberana, y a mi por lo menos me parecen argumentos sólidos.

    Esto es un servicio público que sirve para gestionar aspectos relacionados con tu identidad. Esto no es una página tonta informativa que tiene errores, ni ningún servicio 2.0 de moda que contiene información errónea. En estos escenarios, tolerancia cero. No es de recibo.

    El símil de la carretera no me es válido, ya que el Estado aquí no sólo pone la carretera, sino que además (el módulo de seguridad CAPICOM) es el que te pone un airbag en mal estado en el coche. Son cosas distintas.

    Un saludo,

  13. Sergio,

    Como profesional de la informática, sabras que por definición no hay ningún sistema infranqueable ni 100% seguro. Absolutamente TODO en informática es inseguro. Y cuando digo TODO es TODO.

    De nada me vale tener sistemas de comunicaciones cifradas de última generación para hacer pagos con tarjeta de crédito, si tengo en mi PC un troyano que se dedica a loguear mis pulsaciones de teclado. O tener un PC sin conexión a Internet («para que nadie me entre») con datos médicos si luego me los llevo a la calle con un pendrive. O crear contraseñas seguras de 16 dígitos alfanuméricos, mayúsuclas-minúsculas y con símbolos, si el usuario al que se la dé la apunta en un papel y la deja encima de la mesa.

    Evidentemente todo lo que el Estado está poniendo en nuestras manos, se cae por su propio peso, porque sigo insistiendo en que este es un país de pandereta, y las cosas siempre se hacen tarde y mal.

    A diario trato con gente (clientes) que tienen una auténtica paranoia por hacer cosas por Internet más allá de leer el periódico y mirar vídeos de Youtube. Y artículos como éste lo único que hacen es alimentar esa paranoia. No se dan cuenta de que, sin usar estos servicios de Internet, corren también riesgos reales de suplantación de identidad, robo de los datos de las tarjetas de crédito, acceso a datos personales… Y de que el probablemente el riesgo REAL de que nos «ataquen» sea más bajo en la vida virtual que en la vida real, a pesar de todos estos agujeros de seguridad.

    Ejemplo real de conversación:

    – Ah! No, no, no, yo por Internet no doy mi número de tarjeta ni de coña, con la cantidad de estafas que se oyen todos los días, no me arriesgo a que me roben pasta
    – OK. Normalmente, en los restaurantes, ¿pagas con tarjeta de crédito?
    – Bueno, sí, a veces
    – Ajam… y cuando pagas con tarjeta de crédito, ¿te levantas con el camarero de forma que nunca pierdes de vista la tarjeta?
    – Bueno, no… se la doy y luego viene con la boleta para que le firme…

    A este tipo de cosas me refiero. Este tipo de artículos está muy bien para gente que entendemos de qué va el tema; pero para gente que desconoce de temas técnicos (que es precisamente a quien va dirigido el artículo), lo único que vale es para asustarla. De hecho yo llegué aquí buscando información sobre un error en la instalación del famoso ActiveX…

    Este es mi modo de verlo… Me parece un artículo genial como documento técnico (se usa tal módulo que tiene tal boquete de seguridad), pero tal y como está redactado, solo vale para que la gente se desanime a utilizar este tipo de nuevas tecnologías en su vida cotidiana.

    Un saludo.

  14. Ramón,

    Totalmente de acuerdo, la seguridad 100% no existe, y de existir, es absurda, porque no es rentable. Este concepto no te lo discutiré.

    Para mí sin embargo hay una diferencia sutil entre no colocar medidas de seguridad porque se asume o se mitiga el riesgo de un modo distinto, y tener medidas de seguridad inválidas o que fomenten el uso malicioso del sistema, y eso es lo que quería reseñar con el artículo.

    Lamento que el resultado del texto te resulte desalentador para los usuarios, pero no puedo hablar de otro modo de algo que me parece mal diseñado y que no es seguro. Procuro notar los riesgos para que los usuarios de los servicios sepan a qué se atienen, por ejemplo, instalando el ActiveX de marras. Si el resultado es desconfianza en el montaje, lo siento, pero lo que no puedo es alentar el uso de algo que creo que puede ser explotado para contaminar tu equipo, tu privacidad y tus activos.

    Tomo nota no obstante para futuras reseñas, trataré de ofrecer un mensaje más claro para tratar que los usuarios aprendan a gestionar su seguridad por sí mismos, en vez de desconfiar de las cosas sin más. Todo es mejorable, o eso al menos dicen. No soy una excepción :)

    Un saludo,

Comentarios cerrados.