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.