- Acceso a archivo
Para permitir a la base del motor AV ser independiente del sistema operativo, debe haber una capa de abstracción entre el motor AV y el file system, la capa tiene que incluir la compilación condicional para las plataformas particulares. Otra técnica difundida es compilar ciertas partes del motor AV solamente para determinados sistemas operativos y no utilizando la capa del file system para todos. Mientras que esta forma da lugar a resultados programados más rápidos, a largo plazo, resulta difícil de mantener y poco extensible. Una capa de abstracción, comparable a la capa de abstracción del file system, se debe también implementar para la interfase con la memoria y la interfase gráfica con el usuario, de modo que la base del motor explorador siempre llame a las mismas API para asignar memoria, generar mensajes, etc..
- Modularidad requerida.
Generalmente diseñando el motor AV con modularizar en mente, las partes individuales se pueden sustituir más adelante por un módulo más potente manteniendo la misma funcionalidad. Para los clientes corporativos, es especialmente importante ofrecer una interfase flexible de consola para administración. Estas partes obviamente no pertenecen al núcleo del motor AV, sino que se deben tener presentes al diseñar interfaces, los módulos del motor y las matrices de comunicación. Al hablar de modularidad, es también una buena idea dividir las partes del núcleo del motor AV en componentes, se puede considerar como método de alto nivel la separación en un motor de virus binario y un motor de macro/script.
Funciones Pragmáticas
Los siguientes componentes deben ser considerados en el desarrollo de un motor AV "moderno".
- Núcleo del Motor AV
El núcleo del motor AV puede considerarse como un framework que llama a módulos escaners externos. En consecuencia, necesitan ser diseñados con mecanismos de "registro", así los componentes adicionales (tales como el escáner de un nuevo formato de archivo) pueden ser registrados y actualizados. Estos mecanismos necesitan ser protegidos por certificados digitales o mecanismos similares.
- Capa del file system
Según lo mencionado en la sección anterior, es una buena idea implementar una capa del sistema de archivos de modo que todas las partes del motor AV puedan invocar a las mismas APIs en todas las plataformas. Para permitir el fácil acceso a los archivos se deben soportar las siguientes funcionalidades (cercano al estándar ANSI-C):
? open(filename)
? close(filehandle)
? read(file handler, buffer, length, numero de bytes leidos)
? write(file handler, buffer, length, numero de bytes escritos)
? seek(offset, campos opcionales)
? find first(handle)
? find next(handle)
- Escáner de Tipo de Archivo
En el progreso del programa, uno de los primeros pasos es identificar el tipo del archivo. Podemos llamar a este punto, el "punto de entrada". Este puede ser dirigido desde el núcleo del motor AV o desde una función determinada llamada desde cada módulo scanner para un formato/tipo de archivo determinado. Es preferible este último método para permitir cambios sencillos y poder agregar nuevos módulos de escaneo.
Después de que se haya determinado el tipo del archivo, el escáner correspondiente tiene que ser llamado para ejecutar la rutina de escaneo por sí misma. Cada módulo debe tener la capacidad de llamar de nuevo al punto de entrada del motor AV. Esto puede requerirse en el caso de escanear archivos dentro de otros archivos (por ejemplo, un documento word dentro de una presentación PowerPoint). Dependiendo del resultado del explorador, el motor AV debe poder interactuar con la interfase del usuario por medio de una capa de abstracción genérica para mostrar ciertas advertencias, peticiones, etc..
En este punto tiene sentido definir ¿qué funcionalidades deben existir dentro de cada módulo scanner?
? código de detección de tipo de archivo, que comprueba si la entrada dada puede ser manejar por el módulo scanner;
? funcionalidad de escaneo (que debe poder interactuar con las partes del GUI para mostrar peticiones, etc.); y,
? funcionalidad de eliminación (por ejemplo quitar los vínculos del virus en archivos infectados o borrar los archivos completamente).
La idea es mantener la interfase tan pequeña y clara como sea posible. Los módulos de escaneo no deben confiar en ningún almacenamiento intermedio situado en el núcleo del motor AV. Además, el núcleo del módulo de escaneo debería solo ver archivos/punteros-a-memoria y trabajar con estos punteros. Toda operación/capa subyacente debe ser totalmente transparente para el módulo de escaneo.
- Funcionalidad de eliminación
En el caso de la funcionalidad de eliminación, a menudo es necesario eliminar entradas del registro para inhabilitar la activación de cierto código malévolo. Esta funcionalidad, que es obviamente fuertemente dependiente de la plataforma subyacente, se debe programar usando determinadas funciones del sistema operativo, y deben compilarse solamente cuando sea necesario. En este punto de creación no tiene sentido implementar la capa de abstracción.
- Componentes del Escáner de Memoria
Los componentes del escáner de memoria (por ejemplo memory scanner for Windows 95/98 IFS-based malicious codes) se pueden poner dentro de la misma categoría que la funcionalidad de limpieza del registro descripta antes. Debe observarse que los componentes del scanner de memoria no están a menudo dentro del foco principal en el desarrollo del motor AV.
- Descompresión
La funcionalidad de descompresión en los motores AV considerada a menudo como una tarea pequeña, es realmente un programa complejo. Por un lado, archivos, como .zip, .tar, etc., y formatos de intercambio, por ejemplo MIME, uuencode etc., se descomprimen recursivamente y sin la necesidad de programas externos de descompresión. Por otro lado, los archivos ejecutables deben poder ser descomprimidos. Hablando de la descompresión de los archivos y formatos de intercambio, parece ser un buen método para descomprimir todos los archivos dentro de un directorio predefinido y realizar rutinas recursivas de descompresión, en caso de ser necesario. En el pasado de han visto un par de ataques contra los módulos de descompresión, se descomprimían los archivos embebidos en memoria y el sistema funcionaba fuera de memoria. El archivo era puesto en un archivo .zip con un tamaño total de 42 KB. Desempaquetado recursivamente, los archivos guardados dentro de este archivo son más grandes de 100MB, de modo que la descompresión "en memoria" obviamente disminuía drásticamente la performance.
Además debe ser posible guardar otra vez los archivos comprimidos para permitir significativas operaciones de limpieza. La operación de descompresión, por lo tanto, también necesita el acceso a la capa del sistema de archivos genérica de los archivos descomprimidos store/access.
Para los archivos ejecutables comprimidos (por ejemplo: comprimido con UPX), es posible un método similar. El archivo descomprimido puede ser grabado en un directorio predefinido y después pasarlo por un escáner. Otro método típico es descomprimir el archivo entero en memoria y por detrás pasarle a la instancia llamada el puntero y tamaño del archivo. Entonces la capa del sistema de archivos tendrá que poder tratar un rango de memoria también como archivo.
Finalmente, debe ser resaltado que los archivos cifrados siguen siendo el mayor problema de los motores de descompresión y por lo tanto también para los motores AV.
Diseñar la actualización en línea
Generalmente, todas las actualizaciones se deben firmar digitalmente para proteger a los usuarios de instalar actualizaciones malignas. No es crítico implementar esto en las actualizaciones de los archivos de datos. Enviando solamente actualizaciones de versiones previamente instaladas, en vez de archivos completos de actualización, mantendrá el tráfico de la red bajo y, como tal, es una característica atractiva para los usuarios en ambientes corporativos. Poner al día el código ejecutable usando la actualización en línea es generalmente una operación más compleja. Este típico método reemplaza los módulos completos de un explorador AV. Por lo tanto el motor AV necesita tener la funcionalidad de registrarse, quitarse, ponerse al día y agregar los módulos de su propiedad. Esta interfase necesita obviamente ser protegida (por ejemplo, por certificados digitales), si no los códigos malignos pueden comenzar a atacar esta interfase de registro e inhabilitar ciertas funcionalidades importantes.
Los medios informáticos y sistemas de computación, desde hace ya bastante tiempo, han sido víctimas de distintos tipos de amenazas.
Los tipos de amenazas varían tanto como las técnicas utilizadas para replicarse, evitar ser detectadas, o para dañar a sistemas de cómputos. Se han acuñado nombres para cada tipo de amenaza, aunque dichas definiciones distan de ser claras y concisas.
También son distintos los intereses detrás de una amenaza, que pasan desde la simple satisfacción personal de haber logrado vencer la seguridad de un sistema de cómputos, hasta grandes intereses comerciales. También es variada la peligrosidad de una amenaza, considerando algunos factores de la misma tales como la propagación, el daño y la distribución de la misma.
El objetivo de la gran mayoría de las amenazas suelen ser los pequeños sistemas de cómputo, con sistemas operativos Windows. Esto es debido a que la mayoría de los usuarios utilizan sistemas de este tipo. Pero existen otras amenazas independientes del sistema, como por ejemplo algunas que se transmiten a través del correo electrónico. Por lo tanto, la sola existencia de un sistema de cómputos hace necesaria la consideración de su seguridad.
Tanto las amenazas como los sistemas diseñados para eliminarlas, han ido evolucionando a la par. Ni las amenazas, ni los sistemas que las combaten, han logrado imponerse. Es de esperar que los avances en el área continúen, y que encontremos métodos cada vez más sofisticados para dañar a un sistema de cómputos, y como contraparte sistemas cada vez más avanzados para combatirlos.
Fuentes de información:
Qué son? ¿cómo trabajan? Glosario
http://www.symantec.com/avcenter/refa.html
http://www.mcafee.com/anti-virus/virus_glossary.asp?
http://www.symantec.com/avcenter/faq.html
http://www.pandasoftware.com/virus_info/about_virus/keys.htm
Historia de los virus
http://www.virusprot.com/Historia.html
Panda Software Virus Encyclopedia
http://www.pandasecurity.com/virus-encyclopedia.html
Panda Software – Phishing: personal data theft
http://www.pandasoftware.com/virus_info/phishing/
Widespread Virus Myths
http://www.actlab.utexas.edu/~aviva/compsec/virus/myths.html
Clasificación de gravedad
http://www.symantec.com/avcenter/threat.severity.html
Virus polimórfico
http://www.symantec.com/avcenter/reference/striker.pdf
Comportamiento de antivirus en Sistemas Operativos de 32 bits:
http://securityresponse.symantec.com/avcenter/reference/virus.behavior.under.win.32.pdf
http://securityresponse.symantec.com/avcenter/reference/virus.behavior.under.win.nt.pdf
Debilidades del MS Office 2000 ante virus:
http://www.symantec.com/avcenter/reference/o2secwp.pdf
Building an Anti Virus engine
http://online.securityfocus.com/infocus/1552
Attacks on win32
http://securityresponse.symantec.com/avcenter/reference/attack.on.win32.pdf
Hoaxes & Hypes.
http://www.research.ibm.com/antivirus/SciPapers/Gordon/HH.html
Techniques of Adware and Spyware.
http://www.symantec.com/avcenter/reference/techniques.of.adware.and.spyware.pdf
Michelangelo, un ícono de los virus informáticos..
http://www.perantivirus.com/sosvirus/virufamo/michelan.htm
An Environment for Controlled Worm Replication and Analysis.
http://www.research.ibm.com/antivirus/SciPapers/VB2000INW.htm
Introduction to Database and Application Worms
http://www.appsecinc.com/presentations/Database_Application_Worms.pdf
Worms and trojans go mobile
http://www.niser.org.my/resources/worms_and_trojans_go_modile.pdf
Autor:
Sebastián Calvo
Andrés Chadarevián
Nicolas Cestari
Alejandro Goñi
| Página siguiente |