Autoprotección en aplicaciones Windows: ¿Hasta qué punto son seguros los lectores de PDF, Java y los navegadores?

Casi 20 aplicaciones populares se sometieron a la prueba del laboratorio

Hace poco, AV-TEST seleccionó suites de seguridad actuales y volvió a comprobar su autoprotección y a encontrar muchos puntos débiles. En la segunda gran prueba, el laboratorio ha comprobado si las aplicaciones de Windows utilizan las técnicas de autoprotección. Para ello se revisaron conocidos lectores de PDF, navegadores, programas de Office, programas de compresión, software gráfico y versiones de Java. De existir se comprobó tanto la versión de 32 bits como la de 64 bits de cada aplicación con Windows de 32 y 64 bits:

- Lectores de PDF: Adobe Reader, Foxit Reader, PDF-X-Change Editor
- Navegadores: Chrome, Firefox, Opera
- Paquetes de Office: Free Office, Libre Office, Microsoft Office, Open Office, WPS Office
- Programas para comprimir archivos: 7Zip, WinRAR
- Java: últimas actualizaciones de la versión 5 a 8
- Software gráfico: ACDSee, GIMP, IrfanView, Paint.Net

En la prueba solo se comprobaron los llamados archivos PE (Portable Executable) User Mode para las versiones de 32 y 64 bits. Todos los demás archivos eran irrelevantes para la prueba. Entre los archivos PE están, por ejemplo:

.exe o "Executable", es decir, un programa o módulo ejecutable
.dll o "Dynamic Link Library", una biblioteca de programas
.sys o "System", un software de sistema
.drv o "Driver", un archivo de controlador para un equipo

En esta prueba se comprobó adicionalmente si todas las versiones iban firmados y utilizaban un certificado válido.

Importante: El laboratorio comprobó siempre todos los archivos PE de cada aplicación, sin importar si estas funcionan con 32 o 64 bits, ya que en las versiones de 64 bits también trabajan en paralelo archivos de 32 bits. Y, por supuesto, viceversa.

También es importante mencionar que algunos proveedores de software dotan determinados archivos con una protección especial que es incompatible con DEP y ASRL. Por ello no pueden alcanzar el 100 por cien en la prueba.

La autoprotección podría ser mejor

Entre las aplicaciones más conocidas que acaparan titulares negativos están Adobe Reader y Java. Pero si se mira la tabla de evaluación, estas aplicaciones son casi modélicas en lo relativo al uso de DEP y ASLR. Especialmente en las versiones de Java se apreciar claramente la evolución. Mientras que hasta la antigua versión 6 no se utilizaban estas técnicas en absoluto, a partir de la versión 7 se implementan sin excepción, inclusive la versión 8 update 60 disponible para la prueba.

En el caso de los navegadores más importantes, también se registra un aumento, pero para nada tan amplio, del uso de DEP y ASLR. Firefox consigue una cuota de implementación del 100 por cien con su versión 40.0.3, pero con la versión 41.0.2 desciende al 90 por ciento. El navegador Opera utiliza DEP y ASLR a la perfección en los archivos de 32 bits, sin embargo, el único archivo de 64 bits existente es ignorado. Internet Explorer, por desgracia, no está incluido en la lista. Esto se debe a que está tan profundamente integrado en el sistema operativo Windows, que no se pueden delimitar con exactitud los archivos que utiliza. Por tanto, solo podría hacerse una valoración muy vaga, y por eso el laboratorio lo descartó.

En el caso de los programas de Office, la diferencia en el uso no podría ser mayor. Microsoft Office 2016 apuesta por una protección casi completa, WPS Office usa la protección adicional en casi un 80 por ciento de los casos, Libre Office en parte, pero Free Office en absoluto: 0 por ciento. Open Office protege solo sus archivos de 32 bits. El uso en los archivos de 64 bits es nulo.

En el caso de los populares paquetes de software de fuente abierta 7Zip y GIMP, lamentablemente, no protegen adicionalmente ni un solo archivo. Pero hay otros paquetes de software, como ACDSee Ultimate o IrfanView, que tampoco utilizan DEP y ASLR de forma generalizada.

Los archivos sin firma pueden suponer un riesgo

En la segunda fase de la prueba se comprobó si todos los archivos PE estaban dotados de una firma y un certificado válido. Estos, además de otro valor hash, ayudan a identificar un archivo de forma segura. Si un archivo no está equipado con esta información, una suite de seguridad, por ejemplo, no puede determinar exactamente si el archivo es original o si se trata de un archivo manipulado. El resultado es, con frecuencia, el envío de mensajes de error al usuario o incluso el bloqueo de aplicaciones por motivos de seguridad. Si bien las soluciones de seguridad cuentan con otras herramientas para verificar un archivo, como la Sandbox, suponen un esfuerzo adicional y un desperdicio de rendimiento innecesario.

En el pasado eran precisamente aplicaciones como Adobe Reader las que se utilizaban a menudo como ayuda para acceder al PC. Los cibercriminales buscan y aprovechan cualquier punto débil. Los expertos consideran los archivos no firmados como un potencial punto débil. En este contexto, no se entiende, especialmente en el caso de Adobe Reader, por qué los archivos de 64 bits están todos firmados mientras que la mitad de los archivos de 32 bits no lo están. Los archivos de PDF-Exchange solo están completamente firmados en la versión de 32 bits. En el caso de Foxit Reader, por el contrario, todo está en perfecto estado.

De los navegadores, solo Chrome y Opera tenían todos sus archivos firmados. Firefox solo había dejado algunos archivos puntuales sin firmar. Internet Explorer también fue excluido de esta fase de la prueba por los motivos mencionados respecto a DEP y ASLR.

Microsoft Office con certificado caducado

En el apartado de programas de Office, Free Office no firma ningún archivo y Open Office prácticamente ninguno. WPS Office y Libre Office contienen entre un 5 y 10 por ciento de archivos sin firmar. En Microsoft Office 2016 no había ningún archivo sin firmar, pero sí un archivo con un certificado no válido. Esto es aún peor teniendo en cuenta que la tecnología para firmar códigos Authenticode proviene, al fin y al cabo, de Microsoft y el fabricante debería dar ejemplo con todos sus productos. Preguntado al respecto, Microsoft aún no había respondido en el momento de publicación de este artículo.

En cuanto a los programas para comprimir archivos, el panorama es casi idéntico en cuestión de firmas que el del uso de DEP y ASLR. Ni un solo archivo de 7Zip está firmado y solo unos pocos de WinRAR.

Java también está a menudo en el punto de mira de los atacantes, ya que muchos equipos lo utilizan. Solo en la versión 7 estaban firmados todos los archivos. En las versiones 6 y 8 sigue habiendo algún que otro archivo de 32 y de 64 bits sin firmar.

El software open source llama la atención

El frecuentemente recomendado programa de edición gráfica GIMP es software de fuente abierta. Utiliza en todas sus versiones entre un 50 y un 70 por ciento de archivos sin firmar. Pero hay otros programas gráficos que tampoco brillan por su fiabilidad, si bien el número de archivos sin firmar es notablemente inferior. Es decir, que en todos los demás programas comprobados, como IrfanView, Paint.Net o ACDSee, se encontraron archivos sin firmar. En el caso de la versión de 64 bits de ACDSee hay hasta 2 archivos con certificados caducados.

Conclusión: mejor de lo esperado

Este tipo de exámenes no ha sido ejecutado con esta exhaustividad por ningún otro laboratorio hasta la fecha. Si se compara el resultado con la prueba actual de autoprotección de software antivirus y dejando a un lado el software open source, se obtiene la siguiente impresión general: En la mayoría de aplicaciones para Windows se implementan relativamente bien las técnicas DEP y ASLR. ¡De media incluso mejor que en el software de seguridad actual! Pero algunos fabricantes podrían implementar mejor la protección y también sencillamente firmar sus archivos. El laboratorio repetirá la prueba transcurrido un cierto tiempo. Entonces se verá si los fabricantes hacen caso de la exigencia de una mayor seguridad.

Llama la atención que en el caso del software de fuente abierta, como 7Zip, GIMP u Open Office, los archivos finales con frecuencia no estén dotados de DEP y ASLR, así como de una firma. Puede que esto se deba a que los programadores constituyen un grupo abierto y que, por ello, los archivos sean modificados con frecuencia. Los directores de estos proyectos tienen que pensar con urgencia en algo para que su software, por lo demás bueno, cobre mala fama. Implementar DEP y ASLR debería ser algo fácil y adquirir firmas de un proveedor de certificados tampoco cuesta una fortuna.