25 de novembre de 2014 | Antivirus para Windows
  • Compartir:

Autoprotección para software antivirus

Una suite de seguridad de Internet protege un sistema por completo empleando todas las técnicas de seguridad disponibles. Pero, ¿qué hay de la autoprotección de los protectores del sistema? ¿Utilizan para sí mismos técnicas de seguridad como DEP o ASLR? AV-TEST ha examinado al respecto 32 programas.

Software antivirus para consumidores

algunos fabricantes podrían ampliar aún más el uso de DEP y ASLR en el futuro (versión 10/14).

zoom

En las películas de ciencia ficción, la nave espacial no es simplemente atacada disparando a su escudo de protección, sino que el primer objetivo es siempre el generador del escudo. Si lo equiparamos con el software antivirus, el generador del escudo sería el núcleo de la suite de seguridad, el programa antivirus en sí. Si el generador del escudo falla, entonces el barco, o en nuestro caso el sistema Windows, quedaría desprotegido y sería fácil de abordar.

Los fabricantes de paquetes de seguridad son conscientes, por supuesto, de este problema desde hace tiempo. Por ello han desarrollado e implementado algunas medidas de autoprotección. Lo que muchos usuarios no saben es que el sector TI hace años que desarrolló mecanismos de protección que los programadores pueden utilizar gratuitamente en sus códigos de programación. Se llaman ASLR y DEP.

Los expertos de AV-TEST examinaron 24 suites de seguridad y 8 soluciones de seguridad para empresas en octubre de 2004 para comprobar si ya utilizaban ASLR y DEP. Para la comprobación se separaron los archivos para 32 y de 64 bits.

Tras los opacos términos ASLR y DEP se esconde lo siguiente:

ASLR o Address Space Layout Randomization consiste en una aleatorización de direcciones de espacio que dificulta que se aprovechen agujeros de seguridad en los sistemas informáticos. Mediante ASLR se asignan a los programas direcciones de memoria en base a un proceso aleatorio. De este modo se pretenden impedir o al menos dificultar los ataques si se desborda el búfer.

DEP o Data Execution Prevention, también denominado NX-Bit (No eXecute). La protección tiene su base en el propio hardware. Los fabricantes de procesadores AMD e Intel implementaron esta técnica en todos sus procesadores hace ya 10 años bajo el nombre de EVP o XD-Bit, respectivamente. Con esto se pretende evitar que los programas ejecuten cualquier dato como si fuera un programa e inicien de este modo el código dañino.

Soluciones de seguridad para endpoints

en las versiones para empresas se apuesta más por la protección adicional DEP y ASLR (versión 10/14).

zoom ico
DEP y ASLR en versiones para consumidores

Su uso en los archivos para 64 bits es casi siempre superior que para 32 bits; pero sin que esto constituya una norma (AV-TEST, versión 10/14).

zoom ico
DEP y ASLR en versiones para empresas

casi todos los fabricantes recurren más al uso de DEP y ASLR como protección adicional en las versiones empresariales (AV-TEST, versión 10/14).

zoom ico

1

Soluciones de seguridad para endpoints

2

DEP y ASLR en versiones para consumidores

3

DEP y ASLR en versiones para empresas

Viejo conocido, pero bueno

Las técnicas ASLR y DEP tienen ya más de 10 de antigüedad, pero son más actuales que nunca. Su verdadero sentido es el siguiente:

El código de un programa extenso casi nunca está libre de fallos. Según la página alemana de Wikipedia los mejores programas contienen solo un fallo en cada 2000 líneas de código. Pero, por ejemplo, Photoshop CS6 consta de unos 9 millones de líneas de código, Windows XP de unos 40 millones. Puede encontrar una buena vista general del número de líneas de código de los programas en el infográfico del diseñador londinense David McCandless.

Los inevitables fallos pueden convertirse más tarde en puntos débiles por los que puede introducirse el código malicioso de un atacante. Una suite de seguridad conoce estos puntos débiles e intenta rellenar los agujeros. No obstante, la suite de seguridad también es un programa compuesto de numerosos archivos y un montón de líneas de código. La propia suite podría ser un punto débil del que podría aprovecharse un atacante. Evidentemente, las consecuencias serían fatales.

Si durante la programación se incluye la compatibilidad con las técnicas ASLR y DEP, el riesgo de que pueda aprovecharse de hecho uno de los posibles puntos débiles existentes disminuye. Sin embargo, no se puede decir de forma general que un software que no utiliza ASLR y DEP sea inseguro, puesto que si la programación no contiene ni un solo fallo, la seguridad no se puede aumentar. ASLR y DEP son, por tanto, una protección adicional por si acaso de la que no se debería prescindir, dado que su uso es de lo más sencillo. Se trata de funciones existentes en el compilador que simplemente se activan adicionalmente. La extensión del código o el tiempo de ejecución del programa no se ven afectados por ello.

32 productos examinados

AV-TEST quería averiguar hasta qué punto utilizan los fabricantes esta protección adicional en sus productos. Para ello se instaló cada uno de los productos y se hizo un protocolo de todos los archivos nuevos. Después, para la evaluación se utilizaron los archivos PE (Portable Executable) User Mode para 32 y 64 bits. Todos los demás archivos, inclusive los llamados archivos PE nativos 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

Entre un 5 y un 45 por ciento de los archivos instalados de una solución de seguridad son archivos PE, sobre los cuales se comprobó si su código cuenta con la protección adicional DEP y ASLR.

En las tablas se recoge de manera porcentual cuántos archivos PE de un programa (separados en 32 y 64 bits) cuentan con la protección adicional. El resultado es un tanto sorprendente puesto que algunos fabricantes utilizan ASLR y DEP en parte o por completo, mientras que, por otro lado, algunos prescinden de ella por completo.

Productos para el consumidor: la protección adicional no sirve para todos

El laboratorio ha clasificado los resultados por productos para usuario privados y productos para empresas. En el caso de las suites de seguridad de Internet para usuarios privados se examinaron en total 24 productos, separados entre 32 y 64 bits. Los únicos productos que utilizan ASLR y DEP al 100 por cien son los de ESET (Consumer) y Symantec (Business). Avira, G Data, McAfee y AVG (ambos productos) solo utilizan la protección adicional al 100 por cien en los archivos de 64 bits de sus productos. En los de 32 bits, el valor oscila entre el 90 y 100 por ciento.

En resumen, la mitad de todos los paquetes de protección utilizan ASLR y DEP en más de un 90 por ciento. A partir de ahí, el uso desciende de producto a producto en pasos de un 10 por ciento aproximadamente hasta el valor más bajo de aproximadamente un 5 por ciento. En el caso único de Kingsoft, incluso al 0 por ciento por lo que respecta a 64 bits.

En el caso de muchos archivos para 64 bits, el uso de la técnica de protección, ya sea ASLR o DEP, es superior que en el de los archivos para 32 bits. Sin embargo, no puede establecerse ninguna norma.

Productos para empresas: una cuota elevada

En las soluciones para empresas, los fabricantes recurren mucho más a la autoprotección adicional con ASLR y DEP. Únicamente Symantec utiliza la protección al 100 por cien sin excepciones. Sophos solo en los archivos para 64 bits. Si se añaden los valores de 32 y 64 bits de cada producto, 6 de 8 productos utilizan la protección entre un 81,5 y hasta más de un 97 por ciento. Trend Micro es el único que no apuesta por esta técnica y solo usa ASLR y DEP en un caso 19 por ciento de sus archivos PE.

En general es evidente que la autoprotección se utiliza con más frecuencia en archivos para 64 bits que para 32 bits. No obstante, esto es una tendencia y no una regla.

Resumiendo: Más protección adicional nunca está de más

El uso de las técnicas ASLR y DEP disponibles gratuitamente es recomendable para todos los fabricantes. Al fin y al cabo es una protección adicional que no puede perjudicar. Hay que reconocer que es posible sortear ASLR con técnicas de spraying, como puede leerse en este artículo en Internet escrito en alemán "Die Rückkehr der Pufferüberläufe" (El retorno de sobrecarga de búfer). No obstante, esto exige un mayor esfuerzo por parte de quien escribe el código malicioso. Un esfuerzo que normalmente prefieren evitarse.

Tampoco es DEP (o NX-Bit) una protección infalible para los archivos, pero hace que los programadores de exploits tengan que sortear obstáculos adicionales, lo cual también supone un mayor esfuerzo.

Como casi siempre, es la suma de las cosas lo que marca la diferencia. El esfuerzo que supone salvar dos, tres o más muros de protección le cuesta al atacante tiempo, recursos y pasos adicionales que un software de seguridad posiblemente podría reconocer más fácilmente como ataque.

Esto es lo que dicen los fabricantes al respecto

AV-TEST ha enviado los resultados del examen a los fabricantes y, al mismo tiempo, les ha preguntado por qué en algunos casos no utilizan DEP y ASLR. Este es el resumen de las respuestas:

  • Algunas de las bibliotecas adquiridas no utilizan DEP y ASLR. Pero, en el futuro, tienen la intención de comprar solo libraries que usen estas técnicas.
  • Algunos archivos funcionan con una técnica de protección de desarrollo propio que no sería compatible con DEP y ASLR.
  • Algunos archivos han sido creados con un compilador no conforme con Microsoft para protegerlos de manera especial, pero esto que no sean compatibles con DEP y ASLR.
  • Determinados archivos ya no se utilizan activamente en el programa y por eso no es necesario tenerlos en cuenta.Se utilizan técnicas de protección de desarrollo propio como CFI (Control Flow Integrity ) y la técnica de sandboxing.

Información técnica sobre ASLR y DEP

Director del Malware  Research: Ulf Lösche
Director del Malware Research: Ulf Lösche

Cuanto más código tiene un programa escrito mayor es la probabilidad de que un fallo constituya un potencial punto débil. Mediante las técnicas ASLR y DEP, si bien no es posible cerrar directamente estos puntos débiles, sí se pueden ocultar mejor y protegerlos contra un acceso. En principio, un programador solo debería renunciar a ASLR y DEP si el programa no contiene absolutamente ningún fallo.

Uno de los mayores partidarios de estas técnicas es desde hace tiempo Microsoft. En Windows Vista se utiliza ASLR sin excepción. DEP se incluye desde la versión XP SP 2. Windows se ha ganado de manera injusta la fama de ser un sistema con muchos puntos débiles. Pero lo cierto es que casi siempre es software ajeno instalado el que abre los agujeros en el sistema Windows. Conocidos representantes de este género son Adobe Reader, Flash o Java. En su informe de inteligencia de seguridad Security Intelligence Report, Microsoft informa continuamente sobre la evolución actual en este ámbito. Los informes están disponibles de forma gratuita.

Actualmente también hay un buen estudio de Joxean Koret, COSEINC. En su presentación (PDF) publicada en inglés demuestra de forma gráfica que los puntos débiles existentes en el software antivirus implican un gran riesgo: Breaking Antivirus Software.

AV-TEST ya informó en 2005 acerca de los puntos débiles en el software de seguridad y mostró qué consecuencias pueden tener. Puede leer el PDF sobre el tema aquí: Insecurity in Security Software.

Social Media

¡Nos gustaría mantenernos en contacto con usted! Reciba de manera sencilla y periódica las noticias actuales y las publicaciones sobre pruebas.