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,