Post on 16-Jan-2022
transcript
STRACE COMO HERRAMIENTA DE SEGURIDAD EN LINUX
Boris Alejandro Hurtado Sáenz
Asesora
Sandra Julieta Rueda Rodríguez, Ph.D.
Profesora Asistente
Universidad de Los Andes
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y Computación
Bogotá, 2017
2
Tabla De Contenido
Resumen ................................................................................................................................ 4
1.Introducción ....................................................................................................................... 5
2. Descripción Del Problema................................................................................................ 7
3. Marco Teórico ................................................................................................................... 9
3.1.Linux…………………………………………………………………………………….9
3.1.1. Llamadas Al Sistema ...................................................................................... 9
3.2.Técnicas De Análisis De Software ........................................................................... 10
3.2.1. Análisis Dinámico. ........................................................................................ 10
3.2.2. Análisis Estático ............................................................................................ 11
3.2.3. Análisis Dinámico Vs Análisis Estático ...................................................... 12
3.3.Strace. ....................................................................................................................... 13
4. Propuesta De Solución ............................................................................................................... 15
4.1.Diseño De La Solución .............................................................................................. 15
4.2.Objetivos De La Solución ........................................................................................ 16
4.3implementación ......................................................................................................... 17
4.3.1. Detalles De La Implementación................................................................... 17
4.3.2. Filtros En Strace ........................................................................................... 18
4.3.3. Limitaciones De La Implementación .......................................................... 19
4.4.Ejecución ................................................................................................................... 19
5. Evaluación ………………………………………………………………………………………20
5.1.Separación Entre Scripts Y Programas.................................................................. 20
5.2.Evaluación En Scripts .............................................................................................. 20
5.3.Evaluación En Programas Escritos En Leguaje C ................................................ 21
6. Trabajo Relacionado ...................................................................................................... 30
6.1.Systrace ...................................................................................................................... 30
6.2.Sysdig ……………………………………………………………………………….30
7. Conclusiones Y Trabajo Futuro .................................................................................... 32
7.1.Trabajo Futuro ......................................................................................................... 32
7.2.Conclusiones .............................................................................................................. 32
8. Trabajos Citados............................................................................................................. 34
3
Tabla de figuras
Figura 1 Llamadas al sistema en Linux. ..................................................................................................................................... 10 Figura 2. Análisis dinámico. ............................................................................................................................................................. 12 Figura 3. Strace dentro del contexto de Linux. ........................................................................................................................ 14 Figura 4. Rastreo de un proceso por medio de Strace. ........................................................................................................ 15 Figura 5 Entorno de una máquina virtual. ............................................................................................................................... 16 Figura 6. Chequeo de instalación y versión de Strace .......................................................................................................... 17 Figura 7. Instalación de Strace. ...................................................................................................................................................... 18 Figura 8. Script que imprime una línea en consola. .............................................................................................................. 20 Figura 9. Archivo ejecutable .sh que imprime en consola. .................................................................................................. 21 Figura 10. Código del programa en C .......................................................................................................................................... 21 Figura 11. Información Strace sobre el programa. ............................................................................................................... 22 Figura 12. Información sobre las llamadas al sistema que realiza el programa. .................................................... 22 Figura 13. Programa que trata de hacer bufferoverflow. .................................................................................................. 24 Figura 14. Programa que trata de hacer bufferoverflow: ejecución correcta y con la que lo produce .......... 25 Figura 15. Ejecución del programa con Strace. ...................................................................................................................... 25 Figura 16. Programa monitoreado con Strace cuando no se produce el bufferoverflow ..................................... 26 Figura 17. Programa monitoreado con Strace cuando se produce el bufferoverflow. .......................................... 26 Figura 18. Código del programa que lee un archivo y retorna la primera línea ...................................................... 27 Figura 19. Ejecución del programa. ............................................................................................................................................. 27 Figura 20. Ejecución del programa monitoreado por Strace .......................................................................................... 28 Figura 21. Lista de llamadas al sistema que genera el programa .................................................................................. 28
4
RESUMEN
Los sistemas operativos son software especial que manejan y controlan todas las funciones
de un computador, por esta razón son objetivos de variados ataques informáticos. Con el fin
de mitigar estos ataques existe la seguridad informática.
Una de las tareas de la seguridad informática es intentar garantizar que un software es
benigno. Para esto, hay dos maneras de analizar software; análisis dinámico y análisis
estático. El análisis dinámico evalúa el código de un programa y los distintos escenarios en
los que se puede encontrar el programa. El análisis estático, evalúa el comportamiento del
programa mientras se encuentra en ejecución.
En el caso específico de los sistemas operativos Linux, hay una gran variedad de software
para fortalecer la seguridad informática. Para este proyecto se va a hacer énfasis en una
herramienta proporcionada por Linux llamada Strace. Esto se debe a que Strace permite
monitorear todos los recursos que un software le pide al sistema operativo mientras se está
ejecutando, debido a la información que proporciona Strace un usuario es capaz de conocer
cómo actúa el software y qué recursos usa durante su ejecución.
En este proyecto se usará esta herramienta que realiza análisis dinámico sobre el software
que está siendo ejecutado. Lo anterior con el fin de evaluar el comportamiento de software y
determinar si es benigno o malicioso.
Al realizar la implementación del proyecto se espera poder entender qué tipo de llamadas
realiza un programa o software benigno y qué tipo de llamadas realiza un software malicioso.
Con la información obtenida se realizará una clasificación o perfilamiento de los programas
en las dos categorías anteriormente mencionadas.
Este proyecto permite entender cómo funciona Strace. Asimismo, se logró usar Strace cómo
una herramienta de seguridad informática que tiene como fin evaluar software mientras se
está ejecutando. Gracias a la información que proporciona Strace es posible entonces crear
perfiles de software en los que se distingue entre software benigno y malicioso.
5
1. INTRODUCCIÓN
Los sistemas operativos son software que se encargan de manejar los recursos de hardware
y software de la máquina con el fin de proveer servicios para os usuarios o procesos que
corren en nombre de dichos usuarios. Esto quiere decir que todos los programas o software
necesitan un sistema operativo para funcionar. Otra forma de expresar lo anterior es decir
que el sistema operativo controla lo que pasa en un computador.
Existen varios Sistemas Operativos, entre los que se encuentra Linux, un sistema operativo
de núcleo Unix de código abierto publicado en 1991. Linux fue creado por Linus Torvalds
debido a que trabajaba con Minix, un sistema operativo Unix-like (que se comporta
similarmente a Unix) que no era gratuito. Torvalds empezó a escribir el kernel para publicar
la versión 0.11 bajo una licencia freeware, más adelante publicaría la versión 0.12 bajo la
Licencia Pública General de GNU. Linux fue creado para dar a las personas acceso a un
sistema UNIX-like de modo gratuito. (LivingInternet, s.f.)
Desde su publicación la utilización de Linux ha venido en aumento, “Según estadísticas de
Market Share en su informe mensual sobre el uso de sistemas operativos, Linux por primera
vez en la historia ocupa 1% del ocupando el tercer lugar en el mercado de los sistemas
operativos” (Lainx, 2009). Para cifras más recientes se puede tener en cuenta el artículo
publicado en la página muycomputer, “NetMarketShare le da a Linux un 4,83% de cuota de
mercado en PC, correspondiente a septiembre de 2017” (Poymerol, 2017).
Por lo tanto, el manejo de la seguridad en sistemas Linux es un problema que concierne cada
vez a más usuarios. Por esta razón, se han desarrollado con el paso del tiempo varias
herramientas para manejar la seguridad en estos sistemas operativos. Algunos ejemplos son:
• Nmap, que realiza una detección de los servicios que presta cierta red y los equipos
que se encuentran en dicha red. (Marnigroedu, 2010).
• ClamAv, que es un antivirus gratis para Linux.
• Snort, que cumple con la detección de intrusos en una red, detecta ataques y posible
escaneo de puertos. (Marnigroedu, 2010).
• CHKrootkit que “es un Unix-programa basado en la intención de ayudar a los
administradores de sistemas controlar su sistema de rootkits conocidos. Se trata de
un script de shell utilizando UNIX / Linux herramientas como las cuerdas y los
6
comandos grep para buscar programas del sistema básico de firmas y para la
comparación de un recorrido de los archivos / proc con la salida de la PS (estado de
proceso) para buscar discrepancias” (Marnigroedu, 2010).
El problema es que no todas las herramientas se enfocan en revisar el software que está
instalado en la máquina. Por lo tanto, un usuario puede instalar software en su máquina sin
que alguna herramienta detecte si es benigno o malicioso. Existen herramientas que hacen
esto a través de análisis dinámico y análisis estático. Ambos tipos de análisis tienen sus
respectivas ventajas y desventajas, en el apartado de análisis de software se discutirá este
tema y se explicará por qué se escogió Strace cómo herramienta de trabajo.
Strace es una herramienta de análisis dinámico. De hecho, se han creado herramientas que
realizan una función similar a la de Strace, las herramientas de análisis dinámico permiten al
usuario conocer de qué manera se comporta un software en ejecución y qué servicios solicita
al sistema operativo. Strace cumple los requerimientos que se esperan solucionar; hacer uso
de una herramienta de análisis dinámico para evaluar distintos tipos de software, clasificar el
software entre benigno y malicioso, utilizar los filtros que proporciona Strace para acceder a
información específica sobre el comportamiento del software.
7
2. DESCRIPCIÓN DEL PROBLEMA
La seguridad informática tiene como objetivo proteger los datos de las personas, los datos
que atraviesan distintas redes y las infraestructuras computacionales. En otras palabras, es el
área encargada de minimizar los riesgos para los usuarios y empresas en cuestiones de
tecnologías de la información. Para lograr este objetivo, la seguridad informática debe
disponer de distintas herramientas que permitan evaluar las amenazas que se presentan contra
sus sistemas con el fin de evitar los riesgos que se derivan de dichas amenazas. “Para que las
empresas puedan utilizar las tecnologías de la información y las comunicaciones con
garantías es necesario disponer de guías, métricas y herramientas que les permitan conocer
en cada momento su nivel de seguridad y las vulnerabilidades que aún no han sido cubiertas”
(Olmo Parra, Sanches Crespo, Alvarez, Huerta, & Fernandez Medina, 2016). Entonces, a
manera de resumen, la seguridad de la información debe encargarse de tratar las
vulnerabilidades que se presentan en los sistemas de información.
Una vulnerabilidad es una debilidad que se presenta en un sistema informático específico y
que puede ser utilizada por los atacantes para causar daños al sistema, tomar control del
sistema o acceder a la información (en muchos casos sensible) que se encuentra almacenada
ahí.
No todas las herramientas cumplen las mismas funciones, algunas se encargan de monitorear
el tráfico en la red, otras se encargan de realizar análisis de vulnerabilidades y un grupo de
herramientas se encarga de analizar el software instalado en la máquina. En el aspecto de
analizar el software instalado, se encuentran dos formas de hacerlo, dinámica y estáticamente.
No obstante, cuando se instala software, se están dando permisos para que obtenga recursos
del sistema operativo cuando se ejecuta, si el software es malicioso va a realizar acciones que
puedan perjudicar al usuario o tomar provecho de las vulnerabilidades del sistema.
El problema específico trata del desconocimiento general de los usuarios en el momento de
entender cómo un programa interactúa con el sistema operativo y la máquina en la que se
encuentra instalado. Por esta razón, se han desarrollado herramientas que se encargan de
realizar evaluaciones al software para entender qué recursos necesita, más específicamente,
qué le está pidiendo al sistema operativo.
Con lo anterior en mente, se debe entonces tratar en primer lugar de entender cómo interactúa
el software con el sistema operativo y en segundo lugar analizar si las acciones que realiza el
8
software son las que realmente debería realizar o son acciones maliciosas que atacan las
vulnerabilidades del sistema o recolectan información sensible de la máquina y de su usuario.
Con el fin de superar estos inconvenientes, distintas herramientas han sido creadas para
monitorear las acciones del software, algunas lo realizan mientras el software se ejecuta
(análisis dinámico) otras realizan este análisis sobre el código del software (análisis estático).
No obstante, existen ciertas ventajas y desventajas cuando se realizan estos análisis. Para el
problema específico se escogió el tipo de análisis que hace Strace ya que muestra más
cercanamente la interacción del software con el sistema operativo, específicamente con el
Kernel de Linux.
Con este contexto, los objetivos de este trabajo son:
Objetivo general:
• Hacer uso de Strace cómo una herramienta de seguridad informática que permita
evaluar el comportamiento del software en ejecución.
Objetivos específicos:
• Construir perfiles de comportamiento con base en la información que retorna Strace.
• Evaluar el comportamiento específico de software con ayuda de la herramienta.
• Utilizar los filtros de Strace para agrupar el software en dos categorías; benigno y
malicioso
9
3. MARCO TEÓRICO
3.1. LINUX
Como se estableció anteriormente Linux es un sistema operativo, de código abierto, Unix-
like creado por Linus Torvalds, este se basó en UNIX, sistema operativo comúnmente
llamado sistema Kernel, o simplemente Kernel, es visto como un conjunto de capas, en la
que hay una interacción directa con el hardware que suministra servicios comunes a los
programas, esta es la forma en la que funciona UNIX. Kernel es un sistema que enfatiza en
el aislamiento de los programas de usuarios, esto quiere decir, que los programas son
independientes al hardware subyacente en el que se ejecutan, lo anterior facilita el
movimiento de los programas en el sistema UNIX, siempre y cuando, dichos programas no
requieran un hardware específico para ejecutarse (Bach, 1986). No obstante, la ejecución
exitosa también depende de la manera en la que se haya compilado el programa dado que un
ejecutable compilado no puede moverse entre distintas arquitecturas de hardware. Este
sistema operativo maneja los servicios que provee un computador a través de llamadas al
sistema. Es decir, si un proceso en ejecución solicita un recurso, de cualquier tipo, el sistema
operativo genera una llamada al sistema para proveer dicho recurso y lo hace a través de una
interfaz de llamadas al sistema. En Linux existen distintas herramientas que permiten ver
información acerca de dichas llamadas al sistema como Strace.
3.1.1. LLAMADAS AL SISTEMA
Una llamada al sistema es una solicitud que un proceso le hace al Kernel o sistema operativo
para obtener un servicio. Un proceso es una instancia en ejecución de un programa.
Cuando un programa necesita acceder a un recurso lo hace a través de las llamadas al sistema,
el kernel provee el recurso que el programa solicita. Un sistema operativo Unix-like ejecuta
procesos en uno de dos modos posibles, el modo usuario que es donde se ejecutan los
programas de los usuarios sin privilegios especiales y el modo kernel que es donde se tiene
acceso a instrucciones que requieren privilegios especiales, como instrucciones para acceso
a los recursos compartidos del sistema. Cómo se especifica en Sistemas operativos modernos,
una llamada al sistema nace de un proceso en ejecución.
“Si un proceso está ejecutando un programa de usuario en modo usuario y necesita
un servicio del sistema, como leer datos de un archivo, deberá invocar el servicio
correspondiente. Las instrucciones asociadas, requieren privilegios y al ser invocados desde
10
un proceso que corren en modo usuario generan una trampa (trap en inglés) para transferir el
control al sistema operativo. Después, el sistema operativo averigua qué es lo que quiere el
proceso que hace la invocación, para lo cual inspecciona los parámetros. Luego lleva a cabo
la llamada al sistema y devuelve el control a la instrucción que va después de la llamada al
sistema. En cierto sentido, realizar una llamada al sistema es como realizar un tipo especial
de llamada a un procedimiento, sólo que las llamadas al sistema entran al kernel y las
llamadas a procedimientos no” (Tanebaum, 2009).
Esto significa que las llamadas al sistema son servicios que solicitan los procesos de un
programa en ejecución al sistema operativo. Dependiendo del programa se van a solicitar
distintos servicios, dichos servicios generalmente son de lectura, modificación de archivos o
datos o acceso a una función del sistema. Por ende, cuando un programa está instalado en
una máquina tiene permisos para realizar llamadas al sistema. Estas llamadas al sistema son
las que se quiere monitorear a través de la herramienta Strace, con el fin de analizar si un
programa realmente hace lo que debería hacer.
Como se puede apreciar en la figura uno (1) Linux maneja dos tipos de espacio; usuario y
núcleo. La comunicación entre estos dos espacios se hace a través de la interfaz de llamadas
al sistema que maneja Linux, la cual se encarga de operar todas las llamadas que ejecutan los
procesos o programas y proveer los recursos solicitados por el software.
Figura 1 Llamadas al sistema en Linux. Tomado de: http://sop.upv.es/gii-dso/es/t5-llamadas-al-sistema/gen-t5-llamadas-al-sistema.html
3.2. TÉCNICAS DE ANÁLISIS DE SOFTWARE
3.2.1. ANÁLISIS DINÁMICO.
11
El análisis dinámico se realiza al ejecutar un programa, observar la manera en la que se
ejecuta y qué recursos le pide al sistema operativo. Bajo este tipo de análisis, se puede
observar cómo se ejecuta el programa, que flujos de control son tomados. La ventaja de este
tipo de análisis es que “Hay poca o ninguna incertidumbre sobre los flujos de control que se
tomaron, qué valores fueron computados, qué cantidad de memoria fue consumida, qué tanto
se demoró el programa en ejecutarse” (Ernst, 2003) De igual forma, los análisis dinámicos
pueden ser tan rápidos como la ejecución del programa.
3.2.1.1. DESVENTAJAS DEL ANÁLISIS DINÁMICO.
La desventaja principal es que este análisis es realizado sobre una ejecución específica, esto
significa que se tiene en cuenta únicamente las variables que el programa usó en esa
ejecución. Es decir, a medida que las variables de ejecución cambien, la ejecución del
programa va a tomar otro rumbo. Un ejemplo podría ser los flujos de control que toma el
programa si un campo de texto recibe letras o valores numéricos. Lo anterior muestra que
cuando se realiza un análisis estático, los resultados no se pueden generalizar para todas las
ejecuciones de software.
3.2.1.2. CONSTRUCCIÓN ADECUADA DEL ANÁLISIS DINÁMICO
Dado que el análisis dinámico tiene en cuenta los valores de la ejecución en el momento, “el
reto principal de construir análisis dinámicos es seleccionar una buena función de
abstracción, el reto principal de realizar un buen análisis dinámico es seleccionar un conjunto
representativo de casos (entradas del programa que está siendo analizado” (Ernst, 2003). En
el artículo de Michael Ernst también se menciona que dependiendo de la calidad de las
pruebas se puede obtener información relevante sobre el programa o sobre las pruebas como
tal, por ende, es necesario crear pruebas que de alguna forma traten de generalizar la manera
en la que se va a ejecutar el programa.
3.2.2. ANÁLISIS ESTÁTICO
Este tipo de análisis evalúa el código de un software y trata de determinar todos los posibles
escenarios de ejecución del programa. Generalmente, este tipo de análisis son más seguros
ya que tratan de inferir los posibles caminos que va a tomar el programa al ejecutarse, esto
se logra “construyendo modelos del estado del programa, y determinando los estados posibles
a alcanzar por el programa. No obstante, debido a que existen múltiples posibilidades de
ejecución, se opta por construir un modelo abstracto del programa” (Becerra, 2015). Este
12
análisis entonces crea un modelo de ejecución del programa y ejecuta en ambientes seguros
el programa para ver o determinar su comportamiento. En la figura dos (2) se puede apreciar
cual es el proceso que se debe seguir para realizar un análisis estático exitosamente, de estos
cinco pasos, probablemente el más importante es el de crear un modelo abstracto adecuado
que permita simular los futuros estados en los que se pueda encontrar el software.
Figura 2. Análisis dinámico. Tomado de: http://www.verifysoft.com/en_grammatech_how_static_analysis_works.html
3.2.2.1. DESVENTAJAS DEL ANÁLISIS ESTÁTICO.
Dado que existen varios estados en los que se puede encontrar el programa, el análisis debe
mantener monitoreado todos estos posibles estados. Por lo tanto, la tarea de crear modelos
abstractos que traten de contener todos los posibles escenarios se dificulta, además el tiempo
de ejecución de estos análisis puede llegar a ser muy amplio, razón por la cual el tiempo
también debería ser un motivo de preocupación a la hora de construir estos análisis.
3.2.2.2. CONSTRUCCIÓN ADECUADA DEL ANÁLISIS ESTÁTICO.
En principio, se debería crear un modelo que logre comprender los posibles estados de un
programa sin que sea muy pesado al momento de ejecutarse, para esto, se podría poner
restricciones en los retornos de las funciones o del software analizado.
3.2.3. ANÁLISIS DINÁMICO VS ANÁLISIS ESTÁTICO
Cada tipo de análisis tiene sus fortalezas y desventajas. Por una parte, el análisis estático
prueba el código del software antes de que se ejecute y por la otra, el análisis dinámico prueba
13
el software mientras se está ejecutando. Para el proyecto cómo tal se escogió el análisis
dinámico dado que se quería ver cómo era la interacción de un programa en ejecución con el
Kernel de Linux, qué recursos pedía y que acciones tomaba. Todo lo anterior mientras se
ejecutaba un programa específico.
3.3. STRACE
“Escrito originalmente por Paul Kranenburg para el sistema operativo Sun, fue inspirado por
su funcionalidad de rastreo. Se hizo un puerto para Linux y fue mejorada por Branko
Lankester, quién también escribió el soporte para el kernel de Linux” (Linux.die, s.f.).
Se trata de una herramienta de análisis dinámico que permite monitorear las llamadas al
sistema y las señales que se reciben. Por medio de Strace, es posible ver cómo interactúa un
programa con el kernel de Linux y todas las llamadas al sistema que este realiza.
Generalmente Strace se usa para ver qué problemas presenta un programa desde el momento
que se ejecuta, es decir, puede utilizarse como una herramienta de debugging. La figura 3
muestra cómo funciona Strace en el contexto de Linux, la herramienta se encarga de
monitorear el tráfico que pasa por la interfaz de llamadas al sistema, debido a esto Strace es
capaz de obtener información de las llamadas que realiza un software específico. No obstante,
la función más importante de Strace es monitorear las llamadas al sistema, por esta razón, se
trata también de una herramienta útil que permite entender las interacciones de un programa
con el usuario y el Kernel. Asimismo, permite observar i un programa realiza las acciones
adecuadas o las acciones para las que fue creado. Otra función de Strace es que permite
rastrear procesos, como se puede observar en la figura 4, en la cual se muestra cómo Strace
se adhiere a un proceso con el fin de obtener toda la información relevante que luego podrá
ser observada a través de los reportes que proporciona la herramienta. Strace puede
monitorear procesos específicos de un programa por medio de los filtros, de los cuales se
hablará en el apartado de evaluación. Para que Strace pueda monitorear las llamadas al
sistema debe hacer uso de una llamada al sistema ptrace. Esta llamada al sistema puede ser
usada por los programas para rastrear otras llamadas al sistema, leer y escribir registros y
manipular la entrega de señales a los procesos monitoreados. La llamada al sistema ptrace
puede ir acompañada de distintos “flags” entre ellos se encuentran PTRACE_ATTACH que
se encarga de suministrar el ID del proceso monitoreado. Luego se usa el flag
PTRACE_SYSCALL, que permite inspeccionar los argumentos de las llamadas al sistema y
14
obtener información relevante sobre el proceso y las llamadas al sistema que realiza
(packagecloud, 2016).
Figura 3. Strace dentro del contexto de Linux. En esta figura se puede ver de qué manera Strace es capaz de monitorear las llamadas al sistema, toma la información directamente de la interfaz de llamadas al sistema de Linux. Tomado de:
https://www.slideshare.net/brendangregg/linux-performance-analysis-and-tools/16-analysis_and_Tools_strace_Operating
15
Figura 4. Rastreo de un proceso por medio de Strace. En esta figura se puede apreciar el monitoreo que hace la herramienta a un proceso específico, igual que en la figura 3, Strace realiza esta acción a través de la interfaz de
llamadas al sistema. Tomado de: https://sysdig.com/blog/sysdig-vs-dtrace-vs-strace-a-technical-discussion/
4. PROPUESTA DE SOLUCIÓN
Con todas las definiciones explicadas anteriormente es posible entonces crear una solución
para el problema planteado que trata sobre la seguridad informática y de cómo saber si un
software es benigno o malicioso.
La propuesta para detectar si un programa es malicioso o benigno consiste entonces en hacer
uso de la herramienta Strace para conocer qué llamadas al sistema se hacen. En la sección de
trabajos relacionados se explicará por qué se decidió usar Strace como herramienta del
proyecto. Así, con base en los resultados que provee la Strace se podrá ver si un programa
actúa adecuadamente, es decir, como se supone que debería hacerlo.
A partir de los resultados, se podrá especificar cuál es la diferencia entre los programas que
actúan adecuadamente y los programas que realizan acciones maliciosas, entiéndase acciones
maliciosas cómo accesos a información sensible, modificación de datos sin el permiso del
usuario, etc. Con estás especificaciones se podrá crear perfiles para los programas benignos
y perfiles para los programas maliciosos y de esta manera entender qué tienen en común los
programas maliciosos y de qué forma puede un usuario prevenir instalar este software en su
computador.
4.1. DISEÑO DE LA SOLUCIÓN
Para la solución, se decidió instalar una máquina virtual con sistema operativo versión Linux
16.04.3 que se ejecutase sobre el software VirtualBox y soportara Strace. Las
especificaciones de la máquina virtual son las siguientes:
• Sistema operativo: Linux v. 16.04.3
• Memoria RAM: 4GB
• El procesador de la máquina real: Intel ® Core ™ i7-4500U CPU @ 1.80 GHz 2.40
GHz
Con El sistema operativo instalado, se revisó que efectivamente Strace estuviese instalado
para empezar a realizar las pruebas sobre software real. Para este proyecto se usarán Scripts
escritos por el autor y programas en C escritos también por el autor así como ejemplos de
16
programas en C que actúen de manera inadecuada, un ejemplo claro podría ser un programa
que intente causar un bufferoverflow.
Así, si un programa trata de causar daños, los realizará sobre la máquina virtual y no sobre
la máquina física en la que se ejecuta Virtual Box, ya que cómo se muestra en la figura 5, los
recursos de una máquina virtual no son físicos sino simulados. De hecho, esta sería una
solución en primera medida para detectar si un software es malicioso, ejecutarlo sobre una
máquina virtual y ver de qué manera se comporta.
El diseño se trata entonces de una máquina virtual que cuenta con un sistema operativo Linux,
tiene instalado Strace (versiones anteriores no contaban con esta herramienta) y distintos
scripts y programas en lenguaje C que tratan de acceder a los recursos de la máquina.
Figura 5 Entorno de una máquina virtual. Tomado de: http://moisesgarnica.info/mipalmera/tutoriales/1852-abril-2014-que-es-una-maquina-virtual
4.2. OBJETIVOS DE LA SOLUCIÓN
17
• Se espera que a partir de los resultados que se obtengan de la ejecución de los
programas monitoreada por Strace se puedan construir perfiles de comportamiento de
software.
• Evaluar el comportamiento específico de un programa con la herramienta de software
• Utilizar los filtros de Strace para hacer agrupaciones de la información.
4.3. IMPLEMENTACIÓN
4.3.1. DETALLES DE LA IMPLEMENTACIÓN
Cómo se describió anteriormente, se debe contar con una máquina con sistema operativo que
soporte Strace. Para este caso, la versión que se usó de Linux ya contaba con Strace, de no
ser así simplemente se debe ejecutar el comando sudo apt-get update seguido del comando
sudo apt-get install strace. En el caso de que ya se encuentre instalado se obtendrá una
respuesta como la de la figura 6.
Figura 6. Chequeo de instalación y versión de Strace
En este punto se puede ejecutar el comando strace –V para ver si Strace se encuentra instalado
y cuál es la versión instalada, cómo se puede ver en la figura 7. De aquí en adelante se puede
usar la herramienta Strace para monitorear las llamadas al sistema que realiza un programa.
18
Figura 7. Instalación de Strace.
4.3.2. FILTROS EN STRACE
La herramienta utilizada puede ejecutarse con el comando strace y retornará información del
programa y las llamadas al sistema que este hace. Sin embargo si se agregan los filtros que
proporciona Strace, es posible ver información específica, en algunos casos los filtros pueden
llegar a ser de gran ayuda dado que dan información específica. A continuación se darán a
conocer algunos de los filtros más importantes de strace y su función.
Comando del filtro Función
-c
Tiempo de ejecución del programa,
igualmente muestra la información sobre el
número de llamadas que son realizadas.
-f Rastrea los procesos “hijos” que son
creados a partir de los procesos principales
de un programa
-r Imprime una marca de tiempo cada vez que
un programa recibe una nueva entrada
-T Retorna el tiempo gastado en cada llamada
al sistema
-x Imprime todas la cadenas String que no son
ASCII en formato String hexadecimal
-e trace=set Rastrea únicamente las llamadas al sistema
especificadas en el parámetro set
-e trace=archivo Rastrea únicamente las llamadas al sistema
que toman como parámetro el archivo
archivo
-e trace=network Rastrea únicamente las llamadas al sistema
relacionadas con la red
-o nombre_archivo Escribe la información que retorna Strace en
el archivo con nombre nombre_archivo
19
-p pid
Se une al proceso con identificación pid y lo
monitorea
Tabla 1. Filtros de Strace
4.3.3. LIMITACIONES DE LA IMPLEMENTACIÓN
Las limitaciones que se pueden encontrar dependen de la versión de Linux que el usuario
esté usando, por lo general Strace se puede instalar una vez se hayan realizado las
actualizaciones correspondientes.
4.4. EJECUCIÓN
Para monitorear las llamadas al sistema haciendo uso de Strace se usa el comando strace
seguido del comando para ejecutar el programa. /nombre_del_programa. Así la herramienta
retornará la información solicitada por medio del análisis dinámico. Esto se verá más
profundamente en el apartado de evaluación.
20
5. EVALUACIÓN
En esta parte ya se hace uso de la implementación con el fin de entender cómo funciona la
herramienta, qué información puede retornar y los filtros que proporciona. Aquí es necesario
precisar de qué manera y bajo cuales parámetros se evaluará cada programa. Igualmente, se
especificará antes de evaluar cada programa qué filtros serán usados en la herramienta Strace
con el fin de obtener información específica. El principal problema que se puede encontrar
se deriva de los permisos de los archivos ejecutables o programas, por esta razón, en todos
los casos se accedió desde el modo administrador a los archivos y se dieron permisos de
lectura, modificación y ejecución a cada archivo. Si no se cuenta con los permisos, el sistema
operativo no permite el acceso a los recursos que solicita el programa y por lo tanto termina
la ejecución de este. De modo que para poder monitorear el comportamiento de un programa
se debe contar con los permisos necesarios o usar el modo administrados para obtenerlos de
esta manera.
5.1. SEPARACIÓN ENTRE SCRIPTS Y PROGRAMAS
Para este proyecto se van a usar dos tipos de programas, scripts y programas en C. Los scripts
van a ser sencillos, implemente impresiones en la consola de cadenas de texto y valores
numéricos. Por su parte, los programas en C van a leer archivos, modificarlos, imprimir en
consola y en algún caso tratar de generar un bufferoverflow.
5.2. EVALUACIÓN EN SCRIPTS
La herramienta Strace no reconoce los scripts como archivos ejecutables, en las figuras 8 y
9 se puede ver un ejemplo de Scripts escritos para imprimir o leer un archivo. Por ende se
utilizarán programas escritos en C para evaluar el funcionamiento de la herramienta.
Figura 8. Script que imprime una línea en consola.
21
Figura 9. Archivo ejecutable .sh que imprime en consola.
5.3. EVALUACIÓN EN PROGRAMAS ESCRITOS EN LEGUAJE C
En este punto, se hará uso de tres programas:
• Primero: Escribe en consola la frase “Primer prueba con strace”.
• Segundo: Causa un bufferoverflow.
• Tercero: Modifica el contenido de un archivo de texto.
Cada programa realiza llamadas al sistema de manera distinta, se mostrará el código de cada
programa y lo que retorna Strace en el momento de ejecución del programa.
Figura 10. Código del programa en C
22
Figura 11. Información Strace sobre el programa.
Figura 12. Información sobre las llamadas al sistema que realiza el programa.
En este caso, se puede ver que para la ejecución del programa se realizan dos llamadas para
abrir el archivo, también se realizan llamadas para leer y para escribir, que es cómo se debería
comportar el programa. No hay ningún error en ejecución cómo se puede ver en la tabla de
información. Se hace una llamada munmap que carga el archivo en memoria. También se
puede encontrar una llamada mprotect que realiza una protección de las páginas de memorias
en un rango. El programa se desempeña correctamente.
23
Llamada al sistema Descripción
read Lee el número de bytes que son pasados por
parámetro de un archivo específico cuya
identificación es pasada también por
parámetro.
Write Escribe el número de bytes que son pasados
por parámetro de un archivo específico cuya
identificación es pasada también por
parámetro.
Open Abre el archivo con la ruta específica
suministrada por el parámetro.
Fstat Devuelve información acerca de un archivo
cuyo identificador es pasado por parámetro.
Mmap Crea un nuevo mapeo en el espacio de la
dirección virtual del proceso que realiza la
llamada.
Mprotect Realiza un cambio de las protecciones de
acceso a las páginas de memoria del proceso
en ejecución.
Munmap Borra los mapeos hechos con la llamada al
sistema Mmap.
Brk Cambia la ubicación del “program break”
que es el encargado de definir el fin de un
segmento de datos de un proceso. Lo que
resulta en asignación de mayor memoria
para el proceso.
Access Realiza el chequeo sobre los permisos que
tiene el proceso en ejecución sobre los
archivos a los que desea acceder.
24
Execve Ejecuta el programa con la ruta especificada
por parámetro. Debe ser un archivo
ejecutable.
Arch_prctl Establece procesos específicos de una
arquitectura o el estado de un “thread” a un
proceso en ejecución
Tabla 2. Información tomada de: http://man7.org/linux/man-pages/
Programa que intenta realizar un bufferoverflow
Figura 13. Programa que trata de hacer bufferoverflow.
25
Figura 14. Programa que trata de hacer bufferoverflow con la ejecución correcta y con la que produce el bufferoverflow
Figura 15. Ejecución del programa con Strace.
En las figuras 13, 14 y 15 se puede observar cómo actúa el programa sin hacer el
bufferoverflow, en la figura 16 se muestra la lista de llamadas al sistema cuando el programa
se ejecuta de manera adecuada, es decir sin realizar ningún tipo de desbordamiento y se
contrastará con lo expuesto en la figura 17, cuando si hay bufferoverflow.
26
Figura 16. Programa monitoreado con Strace cuando no se produce el bufferoverflow
Figura 17. Programa monitoreado con Strace cuando se produce el bufferoverflow.
Cómo se puede observar, se realizan más llamadas al sistema cuando se trata de realizar un
bufferoverflow. En el primer caso, las llamadas al sistema son normales, casi iguales a las
del programa que imprime una frase en consola. Por otra parte, las llamadas al sistema en el
segundo caso son más. Debido a que está versión de Linux sabe cuándo se quiere realizar
este tipo de bufferoverflow lo que hace es detener o matar el proceso del programa para que
no se produzcan errores, por esta razón se ven llamadas como tgkill, que envían señales al
proceso para detenerlo o la llamada gettid para conocer la identidad del proceso que está
tratando de realizar la acción indebida. Estas llamadas al sistema son realizadas cuando el
27
sistema operativo encuentra problemas en la ejecución del programa y decide detenerla con
el fin de evitar daños a la máquina. Por una parte, tgkill envía una señal que trata de
inmediatamente detener la ejecución del programa o proceso. Por otra parte, gettid recolecta
información para que el usuario pueda revisar qué pudo haber causado el problema.
Programa que intenta leer un archivo
Figura 18. Código del programa que lee un archivo y retorna la primera línea
Figura 19. Ejecución del programa.
Como se puede observar en la figura 19, se presenta un error “Segmentation fault” esto
sucede cuando se quiere acceder a una parte de la memoria para la cual no se cuenta con
28
permisos. En esta oportunidad, se quiere observar de qué forma Strace monitorea este
programa y qué llamadas al sistema hace.
Figura 20. Ejecución del programa monitoreado por Strace
Figura 21. Lista de llamadas al sistema que genera el programa
29
Para esto, se presenta la figura 21, en donde se muestra de qué manera el sistema operativo
lidia con estos programas que tratan de acceder a zonas de la memoria para las que no tienen
permisos. De la misma manera, Strace es capaz de ver qué llamadas se hacen que no deberían
realizarse.
Cómo se puede observar, se presentan 3 errores en la llamada al sistema access que es la
encargada de chequear si el proceso que está realizando la llamada puede acceder al archivo,
en este caso llamada textoboris.txt.
Gracias a los casos de prueba, es posible ver que Strace sí monitorea todas las llamadas que
se hacen al sistema, devuelve los errores de ejecución (por esta razón es también usada como
herramienta de debugging) y, lo más importante para este proyecto, es capaz de producir
información relevante cuando un programa actúa de forma incorrecta.
30
6. TRABAJO RELACIONADO
6.1. SYSTRACE
En este apartado, se expondrá la herramienta más similar a Strace, llamada Systrace que
“hace cumplir las políticas en las llamadas al sistema utilizadas por las aplicaciones
restringiendo su acceso al sistema. La política se genera interactivamente. Las operaciones
no cubiertas por la política activan una advertencia y permite que un usuario refine la política
actualmente configurada.” (Provos, 2002) En resumen, Systrace notifica al usuario de todas
las llamadas al sistema que hace un programa y, con base en esta información, le permite al
usuario crear políticas para las llamadas al sistema. El problema de Systrace es que no es de
fácil acceso en primer lugar y por otra parte, no funciona para las versiones más recientes de
Linux. Sin embargo, realiza las mismas funciones de Strace y permite al usuario generar
políticas de seguridad para las aplicaciones que se van a ejecutar en su sistema. Estas políticas
de seguridad que se permiten crear al usuario son definidas por Provos como “buenas
políticas” dado que permiten únicamente lo necesario para que el software haga el trabajo
que debe hacer y se le niegue todo lo demás. Así, se puede construir una política que tenga
en cuenta todas las posibles acciones que le permiten al software ejecutarse adecuadamente,
si una acción no es parte de esa lista simplemente se niega. El autor de Systrace creó esta
herramienta con el fin de mejorar la seguridad en sistemas Linux. Sin embargo, actualmente
esta herramienta no tiene soporte en las versiones de Linux. Además, necesita de una librería
llamada libevent para poder instalarse en versiones más antiguas de Linux.
Para el caso de este proyecto, en un principio se intentó usar este programa debido al mayor
número de funcionalidades que tiene, como la generación de las políticas para los programas
que un usuario puede usar en su computador. No obstante, debido a que el programa no ha
tenido mantenimiento en las nuevas versiones de Linux se descartó esta idea.
6.2. SYSDIG
Esta herramienta es de fácil uso debido a que cuenta con una interfaz gráfica que permite al
usuario ver qué está ocurriendo en el sistema operativo, “Sysdig es instalado en el kernel de
Linux… captura llamadas al sistema y otros eventos del sistema operativo. Luego usando la
interfaz de comandos de sysdig, usted puede filtrar y decodificar estos eventos con el fin de
extraer información útil. Sysdig puede ser usada para inspeccionar sistemas en tiempo real o
para generar archivos de monitoreo que pueden ser analizados luego” (Sysdig, s.f.)
31
Sysdig es entonces una herramienta más de análisis dinámico pero está enfocada a monitorear
más que todo el sistema operativo y sus acciones y no tanto los programas. La mayor
diferencia con Strace es que Sysdig cuenta con una interfaz gráfica que en algunos casos
podría facilitar la interacción con el usuario. No obstante, cómo se mencionó anteriormente
su enfoque no es totalmente en los programas sino en las acciones del sistema operativo.
6.3. TAINTDROID
Android hace uso del kernel de Linux con algunas modificaciones para funcionar. Por esta
razón, las vulnerabilidades que puede presentar el kernel de Linux pueden aparecer
igualmente en Android. Para intentar mitigar dichas vulnerabilidades se han creado varias
herramientas, entre las cuales se encuentra TaintDroid.
TaintDroid es una herramienta de análisis dinámico que se encarga de observar cómo una
aplicación maneja los datos del usuario en tiempo real. Es decir, sobre la ejecución del
software (en este caso las aplicaciones). Para esto hace uso de etiquetas que pone sobre los
datos, a las que llama taint.
Cuando una aplicación en Android ejecuta métodos nativos, variables con etiquetas “taint” o
manchas son devueltas. Estas etiquetas se propagan por medio del Binder que es el encargado
de comunicar procesos en Android (cada proceso se ejecuta en un hilo distinto). TaintDroid
usa rastreo de variables de nivel dentro del interprete VM de Android. Por lo tanto, debido a
la acción combinada del Binder al distribuir los datos por Android y de las etiquetas,
TaintDroid es capaz de observar cómo se mueven los datos a través del dispositivo, dónde se
almacenan y quiénes hacen uso de esos datos. Este caso se concentra principalmente en el
manejo de los datos más que en la ejecución de los programas, sin embargo, se trata
igualmente de análisis dinámico y puede dar a entender cómo funciona un programa en
cuanto al manejo de datos. (Enck, Gilbert, & Chun, 2014)
32
7. CONCLUSIONES Y TRABAJO FUTURO
7.1. TRABAJO FUTURO
En este caso se probaron programas que aunque si trataban de causar daños al sistema o
acceder a información sensible, no eran maliciosos o malware como tal. En primer lugar se
quiere encontrar muestras de malware para probar con Strace. En segundo lugar, se quiere
realizar perfiles de gran profundidad tanto para software benigno como malicioso. Gracias a
la información que proporciona Strace será posible hacerlo debido a que las llamadas al
sistema que hace un programa cuando se comporta de manera errónea son distintas a las
llamadas que realiza cuando se comporta adecuadamente, tal y como se pudo observar en el
caso del programa que intentaba realizar bufferoverflow.
De igual manera, se quiere agregar filtros a strace que permitan que la información sea
desplegada de forma más amigable al usuario. Esto se debe a que un usuario que no conozca
las llamadas al sistema o su nombre, no entenderá muy bien en primera instancia qué es lo
que está haciendo el programa y si es lo correcto o no.
Permitir crear políticas de seguridad automáticamente cuando se detecte que un programa
actúa de forma extraña, aunque esto ya está implementado en Systrace, no se encuentra
implementado en strace ya que se trata más que todo de una herramienta de debugging. Por
el contrario, se podría denegar automáticamente el acceso a programas que hayan sido
analizados con Strace y actúen de forma extraña.
7.2. CONCLUSIONES
En este proyecto abordó los temas de seguridad informática y análisis dinámico como una
solución a los problemas o vulnerabilidades que se presentan en la seguridad de la
información en el momento de ejecutar un programa desconocido por parte del usuario. Aun
cuando existen mecanismos avanzados o en algunos casos el propio sistema operativo detecta
los errores, no siempre es el caso, por ende, se hizo uso de la herramienta Strace.
Se logró hacer uso de Strace y los filtros que ofrece no como herramienta de debugging sino
como una herramienta de seguridad informática que revela al usuario qué está realizando un
programa en el momento de su ejecución, qué llamadas al sistema realiza y otros datos
33
importantes cómo el tiempo que toma en ejecución y todos los procesos que se crean al
ejecutar el programa.
Las llamadas que realiza un software benigno son distintas a las que realiza un software
malicioso, el software malicioso puede tratar de acceder a áreas de memoria a las que no
tiene permiso y no debería tratar de acceder, también puede realizar llamadas al sistema que
detiene abruptamente la ejecución de sí mismo o de otros programas que se estén ejecutando
en ese momento. Debido a lo anterior, se puede concluir que con los reportes que puede llegar
a generar strace se puede hacer una lista de llamadas al sistema que realizan más que todos
los programas o software malicioso.
La herramienta que se usó es adecuada para realizar análisis dinámico siempre y cuando se
pueda crear un modelo que cubra la mayoría de escenarios de ejecución. A modo de ejemplo,
en el caso del programa que causaba bufferoverflow, el programa podía tener dos escenarios,
cuando no existía ningún problema y cuando se causaba el bufferoverflow. Es necesario
entonces, para cada software específico, crear modelos que traten de recrear los posibles
estados de ejecución.
Es posible crear perfiles de software, esto se realizará cuando se tenga un conocimiento más
profundo de las llamadas al sistema que realiza un programa malicioso. Con la información
de Strace se puede entonces agrupar el software en dos categorías; malicioso y benigno.
Para finalizar, es posible ver qué, aunque se realizaron pruebas en programas escritos en
lenguaje C únicamente, Strace rastrea las llamadas de cualquier software en ejecución, sus
procesos y el tiempo que toma en ejecutarse. Por lo tanto, si se desea evaluar un software
para posteriormente clasificarlo se podría hacer en un ambiente seguro, como el que se utilizó
para este proyecto y de esta forma obtener los resultados esperados (clasificar el software)
gracias a la información que Strace proporciona de la ejecución del programa.
34
8. TRABAJOS CITADOS
Becerra, L. M. (2015). Análisis de flujo de información en aplicaciones Android. Bogotá,
Colombia.
Enck, W., Gilbert, P., & Chun, B.-G. (2014). TaintDroid: An Information-Flow Tracking
System for Realtime Privacy Monitoring on Smartphones. ACM Transactions on
Computer Systems, 32(2). Obtenido de Appanalysis.
Ernst, M. (2003). Static and dynamic analysis: synergy and duality. International Conference
on Software Engineering, 24-27. Obtenido de
https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-woda2003.pdf
Lainx. (5 de Febrero de 2009). Recuperado el 10 de Octubre de 2017, de Lainx:
http://www.lainx.com/2009/05/por-primera-vez-en-la-historia-el-uso-de-linux-
supera-el-1.html
Linux.die. (s.f.). Recuperado el 29 de Octubre de 2017, de Linux.die:
https://linux.die.net/man/1/strace
LivingInternet. (s.f.). Recuperado el 5 de Diciembre de 2017, de LivingInternet:
https://www.livinginternet.com/i/iw_unix_gnulinux.htm
Marnigroedu. (10 de Agosto de 2010). Marnigroedu. Recuperado el 21 de Octubre de 2017,
de Marnigroedu: https://marnigroedu.wordpress.com/2010/08/10/las-mejores-10-
herramientas-de-seguriadad-linux/
Olmo Parra, A., Sanches Crespo, L., Alvarez, E., Huerta, M., & Fernandez Medina, E. (29
de Agosto de 2016). Olmo Parra, Sanchez Crespo, Alvarez. IEEE Latin America
Transactions, 14(6).
packagecloud. (29 de Febrero de 2016). blog.packagecloud.io. Recuperado el 17 de
Diciembre de 2017, de blog.packagecloud.io:
https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-work/
Poymerol, j. (2 de Octubre de 2017). Muycomputer. Recuperado el 10 de Octubre de 2017,
de Muycomputer: https://www.muycomputer.com/2017/10/02/cuota-mercado-linux-
crece/
Provos, N. (11 de Diciembre de 2002). niels.xtdnet. Recuperado el 5 de Noviembre de 2017,
de niels.xtdnet: http://niels.xtdnet.nl/systrace/es/index.html
Sysdig. (s.f.). Recuperado el 14 de Noviembre de 2017, de Sysdig:
https://www.sysdig.org/wiki/sysdig-overview/
Tanebaum, A. (2009). Sistemas operativos modernos. México: Pearson educación.
Verne, J. (1865). De la Tierra a la Luna. Francia: Hetzel.