METODOLOGÍA PARA LA RECOLECCIÓN DE DATOS · PDF fileAtizapán de...

Metodología para la Recolección deDatos Volátiles Aplicados a un Procesode Investigación Forense-Edición Única

Title Metodología para la Recolección de Datos Volátiles Aplicados aun Proceso de Investigación Forense-Edición Única

Issue Date 2006-04-01

Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey

Item Type Tesis de maestría

Downloaded 19/05/2018 07:17:26

Link to Item http://hdl.handle.net/11285/567549

http://hdl.handle.net/11285/567549

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

CAMPUS ESTADO DE MÉXICO

METODOLOGÍA PARA LA RECOLECCIÓN DE DATOS VOLÁTILES APLICADOS A UN PROCESO DE

INVESTIGACIÓN FORENSE

TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES

PRESENTA

ROSA ALICIA TORRES GARCÍA

Asesor: Dr. ROBERTO GÓMEZ CÁRDENAS

Comité de tesis: Dr. JOSÉ DE JESÚS VÁZQUEZ GÓMEZ Dr. EDUARDO GARCÍA GARCÍA

Dr. ROBERTO GÓMEZ CÁRDENAS

Jurado: Dr. JOSÉ DE JESÚS VÁZQUEZ GÓMEZ Presidente Dr. EDUARDO GARCÍA GARCÍA Secretario

Dr. ROBERTO GÓMEZ CÁRDENAS Vocal

Atizapán de Zaragoza, Edo. Méx., Abril de 2006.

2

CONTENIDO

RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

LISTA DE FIGURAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

LISTA DE TABLAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1. LA INVESTIGACIÓN FORENSE EN CÓMPUTO. . . . . . . . . . . . . . . . . . . . . . 9

1.1 Respuesta a Incidentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.1 Procedimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.1.1 Respuesta inicial del administrador del sistema. . . . . . . . . . . . . . . . 12

1.1.1.2 Protegiendo la integridad de la evidencia. . . . . . . . . . . . . . . . . . . . . 12

1.1.1.3 Procedimientos de shut-down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.1.4 Cadena de custodia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Metodología en una Respuesta a Incidentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Investigación Forense en cómputo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3.1 Pasos del proceso forense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.3.1.1 Paso 1: Identificar y recolectar evidencia . . . . . . . . . . . . . . . . . . . . . 19

1.3.1.2 Paso 2: Preservar la evidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.3.1.3 Paso 3: Analizar la evidencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.3.1.4 Paso 4: Presentar la evidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4 Estándares internacionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.5 México y los delitos informáticos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2. RECOLECCIÓN DE EVIDENCIA Y VOLATILIDAD DE LOS DATOS. . . . 24

2.1 Recolección de evidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.1 Donde y como archivar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1.2 Herramientas útiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3

2.2 Volatilidad de los datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Problemática de la recolección de datos en una investigación forense. . . . . . . . 31

2.4 Propuestas de solución. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3. HERRAMIENTAS PARA LA RECOLECCIÓN DE INFORMACIÓN DE

DATOS VOLÁTILES Y MEMORIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1. SO WindowsNT y 2000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.1. Herramientas (toolkit) de captura con utilerías del SO para Windows. . 36

3.1.1.1. MS-DOS y comandos del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.1.2. Windows Resource Kit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.1.3. Herramientas para Windows no propietarias: PsTools. . . . . . . . . . . 39

3.1.1.4. Herramientas varias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1.5. Volcado de memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.2. Herramientas forenses para Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.2.1. Software comercial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.2.2. Hardware forense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2. SO Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.2.1. Herramientas de captura con utilerías del SO Linux. . . . . . . . . . . . . . . . 48

3.2.1.1. Comandos del Sistema Operativo Linux. . . . . . . . . . . . . . . . . . . . . 49

3.2.1.2. Volcado de memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.2. Herramientas forenses para Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2.2.1. TCT Coroner´s Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2.2.2. Memdump. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.2.2.3. Sleuth Kit y Autopsy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.2.4. Live CD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.2.2.5. Herramientas varias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.3. Análisis comparativo de herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4. METODOLOGÍA PARA LA RECOLECCIÓN DE INFORMACIÓN

Y CASOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1 Estableciendo una metodología “general” para aplicar en cada caso. . . . . . . . . . 77

4.2 Aplicando el procedimiento de recolección: CASO 1 Windows local . . . . . . . . 81

4.3 Aplicando el procedimiento de recolección: CASO 2 Windows por red. . . . . . . 96

4.4 Aplicando el procedimiento de recolección: CASO 3 Linux local. . . . . . . . . . . 114

4.5 Aplicando el procedimiento de recolección: CASO 4 Linux por red. . . . . . . . . . 126

4

4.6 Aplicando el procedimiento de recolección: CASO 5 Grave Robber Linux. . . . 137

5. RECUPERACIÓN DE INFORMACIÓN EN MEMORIA RAM A

TRAVÉS DE PROCEDIMIENTOS FÍSICOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.1 Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5.2 Defectos físicos en los dispositivos de memoria. . . . . . . . . . . . . . . . . . . . . . . . . 144

5.3 Recuperación de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

5.4 Ejemplos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5.4.1 Ejemplo 1: Retención de datos en base a la temperatura . . . . . . . . . . . . . 148

5.4.2 Ejemplo 2: Recuperación de datos en base al stress generado en los

transistores de una celda SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

5.4.3 Ejemplo 3: Recuperación de datos en base al stress del óxido dieléctrico

del capacitor en una celda DRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.4.4 Ejemplo 4: Recuperación de datos utilizando técnicas “Burn in” e “Iddq”

en SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.4.5 Ejemplo 5: Recuperación de datos en base a la alteración del estado

preferente de encendido en una celda DRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.4.6 Ejemplo 6: Recuperación de datos en Smart Cards en base a análisis

de parámetros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.4.7 Ejemplo 7: Recuperación de datos en smartcards utilizando un método

invasivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

5.4.8 Ejemplo 8: Lectura óptica de una SRAM CMOS. . . . . . . . . . . . . . . . . . . 155

5.4.9 Ejemplo 9: Prueba electromagnética en smartcards. . . . . . . . . . . . . . . . . . 156

CONCLUSIONES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

REFERENCIAS BIBLIOGRÁFICAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

ANEXO A. ARTICULO 211 bis CODIGO PENAL FEDERAL. . . . . . . . . . . . . . . . 166

ANEXO B. MICROPRUEBAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

ANEXO C. GLOSARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5

RESUMEN En un incidente de seguridad, donde se ha realizado una intrusión no permitida a un equipo de

cómputo y se requiere buscar la causa y/o al culpable para que se haga justicia sobre los daños

que fueron hechos, se utilizan los conocimientos y experiencia de los investigadores forenses en

cómputo.

Uno de los primeros pasos que realiza el forense en una investigación, es congelar la escena del

crimen con el fin de adquirir la información que pueda llevarlo a encontrar las claves necesarias

para identificar las causas del incidente. En los crímenes digitales la captura de información se

convierte en un paso importante durante la investigación, ya que si no se siguen los pasos

adecuados es fácil perder la información volátil del sistema.

Cuando un investigador llega a la escena del crimen puede encontrar el sistema “vivo” (corriendo

sus procesos en forma “normal”) o el sistema “muerto” (apagado). En el caso de un sistema vivo,

es difícil congelar la escena del crimen, ya que la evidencia es sensitiva al tiempo y además de

frágil, puede ser fácilmente alterada, dañada o destruida, además al realizar la captura de

información volátil y de memoria es fácil cometer errores que traigan consecuencias graves ya

que si se desconecta el equipo antes de capturarla, se puede destruir la poca evidencia existente.

En el caso de encontrar el sistema muerto, podemos decir que la información volátil se ha

perdido. Es por eso que la captura de información volátil de un equipo de cómputo se vuelve un

problema en el proceso de recolección de información en una investigación forense. Otro

problema que se presenta a la hora de recolectar información es el conjunto de herramientas que

se utilizará para obtener la información. El investigador forense tiene que saber el uso de las

6

herramientas que están a su alcance, ya que el orden en que se pueden o deben usar depende de

los efectos que tienen.

Para afrontar este problema en este trabajo de investigación se propone una metodología de

recolección de datos volátiles y de memoria con el fin de asistir al investigador en el proceso de

captura, la metodología consiste en siete pasos que se realizarán en base a la volatilidad de la

información de un sistema de cómputo. Para comprobar su utilidad la metodología se aplicará a

cinco casos con dos sistemas operativos diferentes, donde se accederá en forma local y remota y

se utilizará un conjunto de herramientas en base al análisis de las utilerías existentes para las

versiones de los sistemas operativos planteados en esta investigación.

Dentro del alcance de este trabajo no se plantea una metodología para la recuperación de

información sobre un sistema muerto, ya que lleva un proceso y herramientas muy diferentes a un

sistema vivo, para este caso se exponen varios ejemplos realizados por Universidades dedicadas a

semiconductores y seguridad que muestran que todavía es posible obtener algo de información de

la memoria RAM aunque el equipo esté desconectado de energía.

El presente trabajo se encuentra organizado de la siguiente forma: en el primer capítulo se

introduce al lector a la investigación forense, sus pasos y la respuesta a incidentes; en el segundo

capítulo se plantea la problemática de recolección de información con respecto a la volatilidad de

los datos; en el tercer capítulo se muestran las herramientas útiles para crear el conjunto de

herramientas que permitirán al investigador realizar la recolección de datos volátiles; en el cuarto

capítulo se plantea la metodología a seguir para la recolección de información volátil,

aplicándose a cinco casos con diferentes sistemas operativos; finalmente en el quinto capítulo se

muestran ejemplos de recuperación de información utilizando métodos físicos. Al final del

documento se exponen las conclusiones del trabajo de investigación

7

LISTA DE FIGURAS FIGURA 3.1 Autopsy inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

FIGURA 3.2 Autopsy nuevo caso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

FIGURA 4.1 Casos a considerar para la presente investigación. . . . . . . . . . . . . . . . . . 76

FIGURA 4.2 Caso 1: Aplicación de la metodología con Windows en forma local. . . . 81

FIGURA 4.3 cmd.exe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

FIGURA 4.4 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

FIGURA 4.5 Caso 2: Aplicación de la metodología con Windows en forma remota. . . 96

FIGURA 4.6 Diagrama de conexión: Caso 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

FIGURA 4.7 Caso 3: Aplicación de metodología en Linux con acceso local. . . . . . . . 114

FIGURA 4.8 Caso 4: Aplicación de la metodología a través de la red con Linux. . . . . 126

FIGURA 4.9 Diagrama de conexión: Caso 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

FIGURA 4.10 Pantallas de “Ethereal”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

FIGURA 4.11 Caso 5: Herramienta forense “Grave robber”. . . . . . . . . . . . . . . . . . . . . 137

FIGURA 5.1 Recuperación de datos en un sistema “muerto”. . . . . . . . . . . . . . . . . . . . . 142

FIGURA 5.2 Transistor MOSFET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

FIGURA 5.3 Celda SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

FIGURA 5.4 Mapa construido usando la corriente de eddy. . . . . . . . . . . . . . . . . . . . . . 157

8

LISTA DE TABLAS

TABLA 1.1 Metodología de un Respuesta a Incidentes . . . . . . . . . . . . . . . . . . . . . . . 15

TABLA 2.1 Fuentes del sistemas de datos su volatilidad y utilidad. . . . . . . . . . . . . . 29

TABLA 3.1 Comandos de sistema operativo Windows. . . . . . . . . . . . . . . . . . . . . . . . 36

TABLA 3.2 Herramientas de “Windows Resource Kit” libres. . . . . . . . . . . . . . . . . . 37

TABLA 3.3 Herramientas de “Windows Resource Kit” con costo. . . . . . . . . . . . . . . 38

TABLA 3.4 Suite “PsTools”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

TABLA 3.5 Herramientas varias Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

TABLA 3.6 Software comercial para Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

TABLA 3.7 Hardware forense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

TABLA 3.8 Comandos del sistema operativo Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . 49

TABLA 3.9 Archivos y programas del sistema operativo Linux. . . . . . . . . . . . . . . . . 51

TABLA 3.10 Archivos y directorios de “Grave Robber”. . . . . . . . . . . . . . . . . . . . . . . . 59

TABLA 3.11 Herramientas de seguridad y Forensia para Linux. . . . . . . . . . . . . . . . . . 69

TABLA 3.12 Herramientas varias Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

TABLA 4.1 Pasos y acciones realizadas: Caso 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

TABLA 4.2 Documentando: Caso 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94




TABLA 4.6 Documentando: Caso 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

9

CAPITULO 1

LA INVESTIGACIÓN FORENSE EN CÓMPUTO

10

1. LA INVESTIGACIÓN FORENSE EN CÓMPUTO.

Las computadoras se han convertido en una parte esencial en nuestro trabajo, esto genera el

riesgo de tener violaciones no autorizadas a nuestro sistema (incidentes de seguridad) por el mal

manejo que podamos tener sobre éste. Los delitos informáticos se han vuelto cada día más

importantes debido a la utilización de los servicios que ofrece la red Internet, algunos crímenes

convencionales, especialmente los concernientes a comercio y finanzas, se hacen más

sofisticados tecnológicamente.

Para protegerse contra las amenazas constantes de hackers, crackers y código malicioso, las

organizaciones hacen uso de firewalls, software antivirus y sistemas de detección de intrusos.

Pero a pesar de estas medidas de defensa, computadoras y redes conectadas a Internet, aún siguen

siendo sujetas a ataques frecuentes.

Como resultado de estos hechos desafortunados, organizaciones y gobiernos alrededor del mundo

deben estar preparados para responder ante un incidente de seguridad [1].

11

1.1 RESPUESTA A INCIDENTES

En un incidente donde una brecha de seguridad se ha abierto o un acto criminal involucra a una

computadora, la respuesta inicial es muy importante, las primeras acciones tomadas durante la

atención al incidente puede hacer que se puedan encontrar las pruebas necesarias para detectar la

falla y/o al culpable del acto criminal.

En una respuesta a incidentes el equipo de emergencia hace la verificación del incidente,

recolecta evidencia, analiza la situación, reacciona ante un desastre y reporta acciones, el

investigador forense va un poco mas allá, recolecta y preserva evidencia de la intrusión, busca

pistas, analiza la situación, reporta hallazgos y determina propósitos y motivos.

En un incidente de seguridad es esencial que los pasos que se tomen aseguren la protección de los

datos en el medio de almacenamiento ya que estos datos son invaluables para determinar el nivel

de la brecha de seguridad y la localización de evidencia potencial acerca del acto criminal. El

éxito de la recuperación de datos y el enjuiciamiento dependerá de las acciones del individuo que

inicialmente descubrió el incidente computacional. En la mayoría de las situaciones, el equipo de

emergencia es solo el administrador del sistema. La mayoría de los administradores empiezan a

tomar acciones cuando ocurre un incidente sin darse cuenta del costo que éstas pueden implicar

sobre la evidencia. Es por esto que el proceso de Respuesta a Incidentes tendrá un impacto

significante en el análisis forense posterior.

Las organizaciones necesitan desarrollar un equipo especializado que tenga la capacidad de

responder a incidentes de seguridad, esto incluye personal con habilidades técnicas necesarias

que conozcan los procedimientos y políticas de seguridad.

Mientras la respuesta a incidentes varía dependiendo de las circunstancias, los objetivos

principales en todos los casos según Douglas Schweitzer [21] son:

• Recuperarse rápida y eficientemente del incidente de seguridad.

• Minimizar el impacto causado por la pérdida de datos o robo de información.

• Responder sistemáticamente siguiendo los procedimientos para evitar la recurrencia.

12

Las organizaciones deben desarrollar e implementar un plan de seguridad, llevarlo a cabo y

retroalimentarlo. Deben estar preparadas para actuar rápida y eficientemente para minimizar el

impacto de estos incidentes y establecer los procedimientos que se llevarán a cabo en una

respuesta a incidentes en forma clara y precisa [7].

1.1.1 PROCEDIMIENTOS

No existe un manual que indique paso a paso lo que debemos hacer ante cada uno de los

escenarios en incidentes de seguridad, por lo que podemos ayudarnos con los procedimientos que

algunas dependencias ya han establecido para tomar las medidas precautorias ante un incidente

como la guía de respuesta inicial del Laboratorio de Cómputo Forense del Departamento de

Energía de los E.U. [5] que expone los siguientes cuatro puntos:

1.1.1.1 Respuesta inicial del administrador del sistema

El rol del administrador del sistema es vital para asegurar todos los aspectos de la red, seguridad

y mantenimiento. Desde el punto de vista del forense la situación ideal es aislar el equipo de

cómputo, pero existen casos donde el equipo es un servidor en producción donde la pérdida de

evidencia es inminente.

1.1.1.2 Protegiendo la integridad de la evidencia

Es de gran importancia tener cuidado en preservar la evidencia en su estado original, el simple

hecho de abrir un archivo puede alterar la evidencia, esto en sentido legal puede ser inadmisible

como evidencia. La evidencia incluye también medios de almacenamiento, notas y bitácoras

escritas a mano y documentos del área donde la computadora ha sido involucrada.

1.1.1.3 Procedimientos shut-down

Una de las primeras acciones que se realizan puede estar entre: respaldar evidencia, encontrar

pistas, apagar o dejar arriba el sistema. Cualquier cosa que se haga o no se haga cambiará el

estado del sistema.

13

Cuando se da de baja limpiamente el sistema, se modifica la información del disco y la memoria,

esta es la opción menos viable cuando se desea obtener evidencia. Al apagar el sistema se pierde

información de todos los procesos en ejecución y memoria.

Otra opción es aislar el equipo bajo análisis de la red de trabajo, es decir desconectar de la red y

conectar el otro extremo a un concentrador que no esta conectado a ninguna otra parte, haciendo

suponer a la máquina que sigue conectada a la red y limitando la cantidad de cambios en el

sistema, esto porque la mayoría de los sistemas escriben mensajes de error en los archivos de

bitácora si no se encuentra la red.

Una de las decisiones más difíciles al tratar con un sistema sospechoso es la forma de apagar el

equipo sin corromper la integridad de los archivos. En muchos casos el tipo de sistema operativo

será la clave para tomar la decisión. En algunos sistemas jalar del cordón de poder es un método

para apagar el sistema, pero en otros casos esto puede causar la pérdida de archivos importantes,

o procesos e información en memoria o que el disco duro se dañe. En el caso de los equipos con

Windows se recomienda desconectar el equipo, en el caso de los equipos con Unix se puede

utilizar el comando halt, en sistemas MAC se puede realizar un shutdown especial o quitar el

cordón de corriente.

1.1.1.4 Cadena de custodia

El investigador debe asegurar y administrar eficientemente la evidencia. Una vez que la evidencia

ha sido obtenida se debe tener cuidado de mantener una custodia sobre ésta, en caso de no tenerla

se puede causar un daño grave en la investigación. Por lo que es importante realizar notas de

quién, qué y cuándo se hizo la transferencia de evidencia y mantenerla en un lugar seguro. El

análisis se debe realizar sobre copias en vez de la evidencia original y utilizar firmas digitales

para proveer integridad al contenido original [3].

14

1.2 METODOLOGÍA EN UNA RESPUESTA A INCIDENTES

Los criminales emplean la tecnología como depósito para ocultar evidencia incriminatoria o

materiales de contrabando. Los oficiales de policía deben tener conocimiento y equipo

actualizado para investigar eficientemente la actividad criminal de hoy en día. El reto de la

comunidad policíaca es identificar, investigar e iniciar el procedimiento penal contra las personas

físicas y las organizaciones que usan éstas y otras tecnologías emergentes como medio para sus

operaciones ilícitas. Esto es lo que sucede durante un caso normal:

1.- La víctima notifica que un crimen ha ocurrido.

2.- La policía obtiene evidencia y detecta sospechosos.

3.- Entrevistas y/o interrogaciones pueden ser conducidas.

4.- Al sospechoso son aplicados los cargos.

5.- El caso es llevado a juicio para presentación ante el jurado.

Con el crecimiento del crimen electrónico, una serie de prácticas, procedimientos, procesos de

decisión, referencias, etc. han sido preparados por grupos de trabajo técnico y expertos en

crímenes electrónicos para asistir a las agencias policíacas. La serie de guías direccionarán el

proceso desde la respuesta inicial en la escena del crimen, el laboratorio y ante la corte.

Los departamentos deben contar con herramientas para procesar la escena del crimen. Los

siguientes dispositivos pueden ser útiles en la escena del crimen:

Herramientas de documentación:

Etiquetas de cables

Marcadores indelebles

Herramientas de desensamble y retiro

Desarmadores

Pinzas

Tijeras

Empaquetar y transportar

Bolsas antiestáticas

15

Cables de amarre

Evitar los materiales que puedan producir electricidad estática

Otros dispositivos

Guantes

Lentes de aumento

Maleta de mano

Lámpara

Los siguientes pasos son realizados en una respuesta a un incidente de seguridad:

Tabla 1.1 Pasos de un Respuesta a Incidentes

Preparación Detección del incidente Respuesta inicial Identificar y recolectar evidencia Proceso forense Preservar la evidencia Analizar la evidencia Presentar la evidencia Recuperación Implementación de mecanismo de seguridad Documentación

La preparación cubre todo lo que se necesita hacer antes de que el incidente tome lugar, como

preparar las herramientas de respuesta y forenses, aprender los ambientes, configurar los sistemas

para una respuesta óptima y monitoreo, asignar responsabilidades, formar equipos de trabajo

establecer procedimientos de escalación, etc.

Después de que se ha reportado e identificado el incidente, la respuesta inicial debe tomar los

pasos para asegurar la escena del crimen protegiéndo la integridad de la evidencia, tanto

tradicional como electrónica de todo el personal con acceso a la escena del crimen.

16

Después de asegurar la escena del crimen, la repuesta inicial debe identificar la evidencia

potencial, tanto la electrónica como la convencional. La respuesta inicial debe evaluar la escena

del crimen y formular el siguiente plan. Como actividades se deberá restringir inmediatamente el

acceso a la(s) computadora(s), obtener posibles huellas dactilares, identificar líneas telefónicas

atadas a dispositivos como modems e identificadores de llamadas, documentar, desconectar y

etiquetar cada línea telefónica, etc.

Para determinar el papel de las computadoras dentro del crimen, se pueden contestar las

siguientes preguntas:

• ¿La computadora es contrabando o fruto de un crimen?

o Por ejemplo, ¿el hardware o software de la computadora es robado?

• ¿El sistema computacional es una herramienta para el delito?

o Por ejemplo, ¿se utilizó el sistema en forma activa por el acusado para cometer el delito?

¿se prepararon identificaciones falsas u otros documentos falsificados usando la

computadora, un escáner y una impresora a color?

• ¿El sistema computacional es sólo incidental al delito?, es decir ¿se utilizó para almacenar

evidencia del delito?

o Por ejemplo, ¿el traficante de drogas mantiene sus registros de tráfico en su computadora?

• ¿El sistema computacional es tanto instrumental del delito como un dispositivo de

almacenamiento de la evidencia?

o Por ejemplo, ¿el “pirata” computacional utilizó su computadora para atacar otros sistemas

y también la usó para almacenar información robada de tarjetas de crédito?

Una vez que se conoce el papel de la computadora y que han sido satisfechos los requisitos

legales, se pueden seguir las siguientes recomendaciones:

• No encender la computadora si está apagada

• Si la computadora está encendida

o Consulte al especialista en computadoras

• Si el especialista no está disponible

17

o Tome fotografías del monitor. Desconecte todas las fuentes de energía; desconecte de

la pared y de la parte trasera de la computadora.

o Coloque cinta para proteger evidencia sobre cada entrada a las unidades de disco.

o Tome fotografías/haga un diagrama y coloque etiquetas en la parte de atrás de los

componentes de la computadora y las conexiones existentes.

o Coloque etiquetas a todos los conectores/terminales de cable para permitir el

reensamble, de ser necesario.

o Si se requiere transportación, empaque los componentes y transporte/almacene los

componentes como carga frágil.

o Manténgase alejado de los imanes, transmisores de radio y otros ambientes hostiles.

• Jalar el enchufe podría:

o Dañar en forma importante el sistema

o Interrumpir negocios legítimos

o Originar una responsabilidad para el oficial y el departamento

La evidencia computacional, como toda la evidencia, debe ser manejada cuidadosamente y de

manera que preserve su valor, esto se relaciona no solo con la integridad física, también con los

datos electrónicos que contiene. Las computadoras son instrumentos electrónicos frágiles que son

sensitivos a la temperatura, humedad, golpes físicos, electricidad estática y fuentes magnéticas,

por lo que precauciones especiales se deberán de tomar para empacar y transportar la evidencia

electrónica y mantener la cadena de custodia. Entre los procedimientos de empaque se debe:

• Asegurar que toda la evidencia esta etiquetada e inventariada.

• Utilizar empaques antiestáticos (bolsas de papel o de plástico antiestáticos)

• Evitar almacenar la evidencia electrónica en vehículos por periodos de tiempo

prolongados.

• Proteger de fuentes magnéticas, polvo y partículas contaminantes.

Una vez que se ha obtenido y analizado la evidencia necesaria, se reestablecerá el sistema,

configurando y tomando acciones que prevengan la recurrencia y regrese el sistema a su uso

regular. Documentar el caso resume la lección aprendida y sirve de conocimiento para incidentes

futuros similares. [2,36,44,45]

18

1.3 INVESTIGACIÓN FORENSE EN CÓMPUTO.

El análisis forense digital se está convirtiendo rápidamente en parte integral de una respuesta a

incidentes, incrementándose el número de investigadores forenses y herramientas (toolkits)

disponibles.

En el libro “Techniques of Crime Scene Investigation” escrito por Barry A.J. Fisher [3] se dice

que Forencia es “ciencia y tecnología aplicada a la solución de actos criminales que permite

asistir investigaciones policíacas” y que el Cómputo forense es la “ciencia de adquirir, recuperar,

preservar y presentar datos que han sido procesados electrónicamente y almacenados en un medio

computacional”.

El cómputo forense asegura la preservación y autenticación de los datos computacionales, que

son frágiles por naturaleza y pueden ser fácilmente alterados o borrados si no son manejados

apropiadamente. Adicionalmente, el cómputo forense facilita la recuperación y análisis de

archivos borrados o que no son normalmente visibles al usuario. El análisis forense en cómputo

requiere de la interpretación de expertos más que producir conclusiones, como sucede en el

análisis forense tradicional.

El trabajo de un investigador forense es obtener la mayor información de las fuentes de evidencia

(discos, controladores, archivos de bitácoras, cajas de medios removibles, etc.) tomando en

cuenta dos puntos principales [3]:

• Estar seguro de preservar los datos en su forma original.

• Reconstruir el evento que ocurrió durante un acto criminal.

Cuando se empieza la investigación de un incidente, primero es necesario determinar si en

realidad ha ocurrido un incidente de seguridad, a simple vista quizá no veríamos nada

(especialmente si un “rootkit” está instalado) o podríamos encontrar una saturación de red

originada por un simple “host” (rastreando su dirección ethernet o cuentas de paquetes en un

puerto de un switch) o un programa que se está consumiendo el 100% del CPU sin que el sistema

de archivos muestre algo relacionado con ese programa, cuando esto sucede se verifica que

19

realmente exista un problema de seguridad, muchas veces se trata sólo de un problema de

administración que no necesariamente pone en duda el sistema. Los pasos tomados en cada uno

de estos ejemplos puede ser completamente diferentes entre cada uno, un investigador utilizará la

experiencia e intuición acerca de que y como buscar, cuidando de recordar los pasos realizados

para preservar y recolectar evidencia en forma metódica. Las piezas de datos (evidencia) en el

sistema, exponen la historia de cómo ocurrió el suceso [21,7,3].

La investigación forense sigue métodos científicos, estas acciones metódicas ayudan a obtener y

analizar la evidencia. Grant Gottfried [1] define evidencia digital como “la información

almacenada o transmitida en forma binaria que pueda se útil en una corte de justicia”.

1.3.1 PASOS DEL PROCESO FORENSE

No hay duda de que una metodología o proceso es llevada a cabo en un fraude computacional,

por lo que tampoco hay duda de que en una investigación forense debemos contar también con un

proceso, además un proceso formal permite al investigador enfocar e investigar un crimen

racional y rápidamente. También es importante establecer un protocolo por el cual la evidencia

electrónica es obtenida y manejada, para reducir el riego de ser corrompida. Sin una metodología

o proceso bien definido será más difícil investigar exitosamente y por lo tanto controlar un abuso

o fraude computacional. Es requisito que en un proceso de investigación forense se exhiban las

características de una metodología científica. Por ejemplo un proceso válido debe consistir en

pasos bien definidos que puedan ser repetidos en toda la investigación, cada paso debe ser

consistente [8].

A continuación se exponen los cuatro pasos del proceso forense[4]:

1.3.1.1 PASO 1 Identificar y recolectar evidencia

Identificar la información que se encuentre disponible y determinar la mejor manera de

recolectarla. Este punto se profundizará en el siguiente capítulo.

20

1.3.1.2 PASO 2 Preservar evidencia

Una vez que se ha identificado y recolectado la evidencia es muy importante preservarla con la

menor cantidad de cambios, pero en el caso de realizar cambios se debe demostrar la

responsabilidad que se tenga sobre la evidencia.

La evidencia debe ser estrictamente asegurada y la cadena de custodia necesita ser claramente

documentada, la evidencia debe ser capaz de describir claramente como fue encontrada, como fue

manejada y todo lo que le ha sucedido (cadena de custodia).

Lo que debe ser documentado:

• Dónde, cuándo y por quién fue descubierta y obtenida la evidencia.

• Dónde, cuándo y por quién fue manejada y examinada la evidencia.

• Quién ha custodiado la evidencia, durante qué periodo y cómo fue almacenada.

• Cuándo la evidencia cambia de custodia, y cómo se hace la transferencia.

El acceso a la evidencia debe ser restrictivo y documentado para que se pueda detectar un acceso

no autorizado. Una vez capturada la información debe ser almacenada en medios de solo lectura

y marcar registros que conserven la integridad de la información para que no pueda ser alterada.

1.3.1.3 PASO 3 Analizar la evidencia

Para interpretar la evidencia se requiere de conocimiento profundo para entender como embonan

las piezas. Podemos comenzar por identificar qué cambió en el sistema cómo y cuándo, si es

posible obtener los comandos usados y cuando se usaron, rootkits instalados e información

oculta.

Se deben analizar solo copias (imágenes) de la evidencia, manteniendo la integridad original y

una cadena de custodia estricta. La integridad del sistema se debe verificar antes y después del

análisis.

21

1.3.1.4 PASO 4 Presentar la evidencia

Este paso se enfoca en la forma de presentar la evidencia ante una corte. La credibilidad de los

procesos usados para preservar y analizar la evidencia.

La evidencia computacional necesita ser:

Admisible: Debe conformar ciertas reglas legales antes de que pueda ponerse ante una corte

Auténtica: Debe ser posible atar material evidencial al incidente

Completa: Debe decir toda la historia y no solo una perspectiva particular.

Confiable: No debe haber duda sobre la autenticidad y veracidad de la evidencia ni de cómo

se recolectó.

Creíble: Debe haber credibilidad en la investigación y ser entendible para la corte.

1.4 ESTÁNDARES INTERNACIONALES

El grupo G8 de naciones más industrializadas ha propuesto 6 principios relacionados con

evidencia digital para asegurar una buena aplicación de los métodos y prácticas entre las naciones

y garantizar la habilidad de usar evidencia digital recolectada por un estado en la corte de otro

estado [9]:

1. Cuando se trata con evidencia digital, todos los principios forenses generales y

procedimientos deben ser aplicados.

2. Una vez obtenida la evidencia digital, las acciones que se tomen no deben cambiar la

evidencia.

3. Cuando sea necesario que una persona acceda a la evidencia digital, será necesario que

esté entrenada para ese propósito

4. Todas las actividades del embargo, acceso, almacenamiento o transferencia de evidencia

digital deben ser completamente documentadas, preservadas y disponibles para revisión.

5. Las personas que custodian la evidencia son responsables por todas las acciones tomadas

con respecto a la evidencia digital mientras ésta esté en su poder.

6. La agencia que sea responsable por el embargo, acceso, almacenamiento o transferencia

de la evidencia digital es responsable de cumplir estos principios.

22

Todas las políticas y procedimientos de cómputo forense deben ser desarrollados bajo estos

principios. No limitándose a sólo computadoras en el sentido tradicional, el campo abarca todo,

PDAs, ruteadores, etc. cubriendo crímenes que alcancen desde crear, poseer y diseminar

pornografía infantil hasta intrusiones de red.

Estos principios son un inicio para tratar de estandarizar pero mucho depende de las leyes locales

del estado o país.

1.5 MÉXICO Y LOS DELITOS INFORMÁTICOS

Existen varios estándares y procedimientos que se han creado en combate a los delitos

informáticos. A nivel internacional en países a la vanguardia sobre el tema, se han clasificado los

delitos en diferentes tipos tales como: el espionaje electrónico, la estafa electrónica, el sabotaje

electrónico, la falsificación informática, el plagio de dominios, el plagio de nombres comerciales

o marcas de Internet, el mercadeo de souvenirs que aludan fines xenofóbicos, la apología del

delito, la responsabilidad penal en que pueden incurrir los representantes legales de las empresas

que se dedican a ofrecer hospedaje virtual de anunciantes cuando la información sea considerada

como contraria a la ley o incite a la comisión de un delito, entre otros.

En México, el 17 de mayo del 2000 se publicaron varias reformas en el Diario Oficial de la

federación para la creación de los artículos 211 bis 1 al 7 de l código Penal Federal que se

muestran en el anexo A.

A pesar de los esfuerzos que se han realizado para proponer nuevas normas enfocadas a los

delitos informáticos, que puedan motivar la labor de los cuerpos especializados de investigación

criminal, como la Unidad de Policía Cibernética dependiente de la Policía Federal Preventiva, la

falta de normas legales limita su labor, ya que no cuentan con las disposiciones penales que

sirvan de apoyo para sancionar los delitos informáticos y por tanto, estos permanezcan impunes.

Sánchez Franco [42] expone que deben existir las herramientas legales adecuadas para que la parte

ofendida denuncie y acredite con pruebas los delitos ante la autoridad competente, ya que en caso

23

de no existir como hasta ahora, se favorece la labor de los abogados defensores y se favorece la

impunidad.

Es insuficiente la reforma penal de mayo del 2000, es necesario retomar conciencia sobre el tema

y apoyarse en los modelos avanzados que ya están estableciendo, regulando y sancionando este

tipo de ilícitos.

24

CAPITULO 2

RECOLECCIÓN DE EVIDENCIA Y VOLATILIDAD DE LOS DATOS

25

2. RECOLECCIÓN DE EVIDENCIA

El cómputo forense envuelve la preservación, identificación, extracción, documentación e

interpretación de datos computacionales. Según Stephen Barish en su artículo “Un Caso de

Estudio”[22] “El cómputo forense es más un arte que una ciencia”, pero como es una disciplina

obliga a los especialista forenses a seguir en forma clara y bien definida metodologías y

procedimientos pero al mismo tiempo permite ser flexible al encontrar algo inusual.

Investigar la violación de un equipo de cómputo es como investigar la escena de un crimen, los

detectives recolectan evidencia, buscan claves que puedan ser útiles y toman un inventario de los

daños y pérdidas.

2.1 RECOLECCIÓN DE EVIDENCIA

El primer paso que debe seguir un investigador en un incidente de seguridad es la recolección de

evidencia. Según Timothy E. Write [8] el proceso de búsqueda de evidencia pasa por varios

estados:

1º. Se deberá formular un plan donde el investigador determinará la evidencia que será

buscada y decidirá el procedimiento de búsqueda

2º. El investigador llegará a la escena del crimen y asegurará la evidencia de personas no

autorizadas.

26

3º. El investigador tomará notas cuidadosamente de todos los dispositivos relevantes y la

evidencia encontrada.

4º. El investigador seleccionará, empaquetará y moverá evidencia

5º. Analizará la evidencia en un laboratorio cuidando de no modificarla.

Como se especifica en el RFC 3227, si la recolección de evidencia es hecha en forma correcta,

existe mayor oportunidad de que esta información sea útil en un juicio, facilitando el arresto de

un atacante.

Las principales recomendaciones especificadas en el RFC indican que:

• Los procedimientos de recolección deberán ser incluidos en las políticas de seguridad del

área de cómputo e involucrar al personal de incidentes de seguridad.

• Obtener como sea posible una fotografía exacta del sistema.

• Realizar notas detalladas.

• Anotar la diferencia entre el reloj del sistema y la UTC.

• Estar preparado para testificar todas las acciones que se realizaron y la hora.

• Minimizar cambios en los datos como se van recolectando.

• Cuando se enfrente con una elección entre recolección y análisis, se debe recolectar antes

de analizar.

• Ser metódico.

• La velocidad debe ser crítica, por lo que para un número de dispositivos que se requiere

examinar, será apropiado repartir el trabajo entre más personas para recolectar en forma

paralela.

• Proceder desde lo volátil a lo menos volátil.

• Hacer una copia a nivel de bit del sistema.

Dentro de las cosas que se deben evitar para no destruir evidencia el RFC recomienda:

• No dar de baja el sistema hasta que se ha completado la recolección. La evidencia puede

ser perdida y el atacante puede haber alterado el proceso de shutdown o los archivos

scripts de servicios para destruir esa información.

27

• No confiar en los programas del sistema. Correr los programas de recolección de

información en medios seguros y protegidos.

• No correr programas que modifiquen el tiempo de acceso de todos los archivos en el

sistema.

• Cuando se remueven dispositivos externos notar que la simple desconexión o filtro de la

red puede activar programas que detectan cuando se ha desconectado la red y borran

evidencia.

Los procedimientos de recolección deben ser detallados en lo posible, no deben ser ambiguos y

deben minimizar la cantidad de decisiones necesitadas durante el proceso de recolección. Los

métodos utilizados en la recolección de evidencia digital deben ser transparentes y reproducibles,

no olvidando documentar cada paso. Se debe estar preparado para reproducir precisamente el

método usado, además estos métodos deben ser probados por expertos independientes.

• La cadena de custodia necesita ser claramente documentada, debe describir como se

encontró la evidencia, como fue manejada y todo lo que sucedió.

• Debe documentarse dónde, cuándo y por quién fue descubierta y obtenida, aumentada y

examinada la evidencia.

• Quién la ha custodiado, durante qué periodo y cómo fue almacenada.

• Cuándo la evidencia cambia de custodia y cómo se hace la transferencia.

Los métodos usados para la recolección de evidencia deben ser transparentes y reproducibles [6].

2.1.1 DONDE Y COMO ARCHIVAR

En la medida de lo posible usar medios de almacenamiento de evidencia estándares. El acceso a

la evidencia debe ser restrictivo y documentado claramente, para detectar accesos no autorizados.

Una consideración importante a la hora de hacer las copias es esterilizar los dispositivos en los

que se guardará la copia. Para lo cual se puede esterilizar un dispositivo sobrescribiendo el medio

con ceros.

28

2.1.2 HERRAMIENTAS ÚTILES

Se debe contar con programas de recolección de evidencia en medios de solo lectura (ejemplo:

CD). Contar con un conjunto de herramientas por cada sistema operativo, que contenga

programas para examinar procesos, para hacer copias bit a bit, para generar marcas de tiempo

(checksums) y firmas, etc.

Los programas en el conjunto de herramientas deben ser ligados estáticamente y no deben

requerir el uso de librerías. Se debe estar preparado para testificar la autenticidad y confiabilidad

de las herramientas que se utilicen.

Uno de los problemas a los que se enfrenta el investigador es que los administradores algunas

veces rechazan la idea de dar de baja un sistema, especialmente cuando éste estará abajo por una

indeterminada cantidad de tiempo. Pero solo se puede bajar el nivel de rigor después de que se ha

determinado que el caso no será enjuiciado

2.2 VOLATILIDAD DE LOS DATOS

La evidencia puede ser encontrada en muchos dispositivos electrónicos, como teléfonos,

celulares, asistentes personales digitales (PDAs), cámaras digitales, componentes de red, pagers,

etc. En el caso de las computadoras se puede obtener información a través de los dispositivos de

almacenamiento de datos con los que cuenta, como los son el procesador, memoria, disco duro,

medios removibles (floppy disks, cintas, discos compactos, discos versátiles digitales (DVD)),

impresoras, etc.

El tiempo de vida de los datos digitales depende de donde se encuentren almacenados. Dan

Farmer y Wietse Venema establecieron el siguiente orden de volatilidad:

1 Procesador

2 Sistemas de almacenamiento

3 Tablas del kernel

4 Medios fijos

29

5 Medios removibles

6 Impresiones

Mientras mayor volatilidad de los datos es mayor la dificultad de capturarlos, y menor el tiempo

que tenemos para realizar un análisis. Por ejemplo en el caso del procesador es improbable que se

pueda utilizar el contenido de los registros, el simple acto de buscar en ellos puede modificarlos,

así es que, buscando sobre el contenido de la memoria del sistema y el estado de la red podemos

obtener claves valiosas, el tipo y la fuente de un ataque de entrada, etc. Examinar esta tipo de

estructuras requiere de cierta experiencia para analizar y capturar los datos en forma segura.

A continuación se muestra la tabla 2.1 que publica las diferentes fuentes de sistemas de datos su

volatilidad y su utilidad en la investigación [2].

Tabla 2.1 Fuentes de sistemas de datos su volatilidad y utilidad Máximo tiempo de vida

Categoría Tipo de almacenamiento de datos

Significado para el investigador forense

Registros Captura irrealizable y mínima utilidad

Procesador

Caches Captura irrealizable como una entidad discreta pero puede obtenerse información a través de una imagen de memoria del sistema.

Tan corto como un ciclo de reloj

Video RAM La pantalla actual puede ser capturada y provee información útil si se sospecha que el intruso entró al sistema mediante la consola o en una terminal X Windows

Sistemas de almacenamiento

RAM Incluye información sobre todos los procesos corriendo y el estado del kernel. Fácil de capturar, pero el acto de capturarlos puede cambiarlos. Requiere conocimiento especializado para reconstruirlo completamente, pero no requiere habilidades especiales para buscar estos datos por palabras clave.

Estado de red Puede ayudar a determinar si una puerta trasera “backdoor” ha sido instalada y si está activa. Debe ser analizado para determinar la actividad de red.

Hasta que el host es dado de baja

Tablas de Kernel

Procesos corriendo

Algunos procesos pueden mostrar actividad no autorizada. Todos los procesos deberán ser verificados contra binarios seguros, verificando que

30

Máximo tiempo de vida

Categoría Tipo de Significado para el investigador forense almacenamiento de datos

no sean caballos de Troya.

Espacio swap Cuando las demandas del sistema exceden la capacidad de la RAM, algunos datos del kernel son copiados al disco duro. Estos datos complementan los de la memoria RAM para el análisis de tiempos.

Directorios Queue

Incluye información sobre procesos corriendo y actividades incompletas. Se puede observar correo saliente y trabajos de impresión que no existen en otro lugar en el sistema

Directorios Temp.

Son archivos de trabajo de todo el sistema. Se espera que sea borrado periódicamente, por lo que es un lugar apropiado para dejar datos que no serán necesitados en el futuro. Se pueden encontrar datos que fueron deliberadamente borrados sobre otras partes del sistema

Directorios Log

Esto es crucial para la reconstrucción de eventos. La dificultad es que crecen demasiado, los logs son mantenidos, viejos datos son eventualmente borrados o sobre-escritos.

Medios fijos (Discos duros)

Directorios de configuración, usuario, binarios y librerías.

Cada parte del sistema de archivos que no es considerada temporal, como bitácoras que incluyen archivos que pueden permanecer indefinidamente. Sin embargo, cualquier usuario con acceso de escritura podrá borrar o cambiar los datos.

Discos floppy Uso menos frecuente en ambientes de red, pero puede contener archivos útiles. Discos de alta capacidad que pueden ser usado para respaldos

Cintas Son una fuente confiable de información acerca del contenido histórico del sistema. En caso de existir cintas antes del incidente, pueden ser usadas para determinar el periodo de tiempo durante el cual un incidente ocurrió.

Hasta que sean sobre-escritos o borrados

CD-ROM Read/write

El estándar para CDs es ahora multisesion. Debemos estar seguros de que examinar un CD sospechoso puede mostrar todas las sesiones. Los datos no pueden ser sobrescritos, pero cada sesión crea una nueva tabla de directorio.

Medios removibles

CD-ROM Write/only

Medio de escritura de una sola vez, es un lugar excelente para almacenar archivos log porque ellos no pueden ser alterados.

Hasta que sean físicamente destruidos Salidas Impresiones en

papel Es difícil hacer búsquedas en impresiones muy largas, pero su periodo de destrucción es corto. Es probablemente el mecanismo de almacenamiento de mayor vida

Es imposible completar la captura de todo el estado de una computadora en un incidente. El

simple acto de examinar los datos volátiles provoca que el estado del sistema se modifique.

31

2.3 PROBLEMÁTICA DE RECOLECCIÓN DE DATOS EN UNA

INVESTIGACIÓN FORENSE

De acuerdo a lo que se ha expresado en las secciones anteriores podemos encontrar diversos

problemas a los que se puede enfrentar un investigador forense en la recolección de información.

Ante una respuesta a un incidente, el personal que atiende el incidente debe decidir si el equipo se

queda encendido o apagado. En caso de apagarlo también debe decidir si debe desconectarlo de

la energía o realizar un apagado (shutdown) normal.

Sea lo que decida el personal de respuesta a incidentes el investigador forense realizará la

recolección tal como encontró el equipo y deberá recolectar la información posible que le pueda

llevar a encontrar claves para resolver el caso al que se enfrente.

Por lo que podemos generalizar son dos situaciones a las que se enfrentará el investigador forense

para la recolección de información, cuando el equipo esta encendido y cuando el equipo está

apagado.

Se sabe que en algunas situaciones, especialmente en intrusiones de Internet, la evidencia puede

ser encontrada solamente en la memoria, pero debido a su alta volatilidad si se desconecta el

equipo antes de capturarla, se puede destruir la poca evidencia existente. Por lo que para

recolectar información volátil de un sistema utilizando las herramientas tradicionales de software

necesitamos tener el equipo encendido y corriendo sus procesos en forma normal.

Pero con el sistema corriendo es fácil cometer errores que traigan consecuencias graves, además

se viola uno de los principales principios de investigación forense que es no modificar la

evidencia, como por ejemplo en Linux, cada herramienta en el espacio de usuario o kernel

utilizada para capturar datos, por naturaleza cambia el estado del sistema. Correr herramientas en

un sistema vivo, hace que éstas se carguen en memoria y creen por lo menos un proceso que

puede sobrescribir evidencia. Creando un nuevo proceso, los sistemas de administración de

memoria del sistema operativo colocan datos en memoria principal y puede sobrescribir datos no

32

colocados en la memoria principal o en la memoria swap, que también es totalmente válido en los

ambientes Windows.

Otro problema se presenta cuando queremos tomar acciones legales y necesitamos cumplir con

las leyes locales. Las señales de intrusión encontradas en imágenes de memoria principal pueden

ser no confiables, porque son creadas con herramientas que adquirimos. Por lo que al tomar una

acción debemos decidir si o no, vamos a obtener datos volátiles de un sistema comprometido.

Pero algunas veces el procedimiento vivo describe la única forma de adquirir datos del incidente,

porque cierto código malicioso como algunos “rootkits” son cargados en memoria y no modifican

archivos o directorios.

2.4 PROPUESTAS DE SOLUCIÓN

Como ya hemos mencionado en la mayoría de los casos de atención de incidentes, se encuentra al

sistema en dos estados, se puede encontrar un sistema vivo (donde todavía se puede obtener

evidencia volátil) o se puede encontrar el sistema muerto (el investigador lo encuentra apagado).

El estado del sistema determinará cuales son las primeras acciones que se tomarán. En un sistema

vivo se tiene la opción de monitorear la red, se puede optar por dejar el sistema corriendo después

de recolectar la evidencia y/o instalar algún sniffer en el sistema (si es que lo permiten las

políticas).

En el caso de que el investigador se encuentre con un equipo encendido o “vivo”, lo importante

es actuar lo más rápido posible para capturar información, pero teniendo en cuenta que cada

acción que se tome durante la investigación, debe ser hecha de manera que pueda explicarse

fácilmente, ya que cada error en el sistema vivo puede traer consecuencias.

En el caso de que el investigador encuentre el equipo apagado o “muerto”, podemos pensar que

ya no es posible recuperar la información volátil del sistema, pero de acuerdo a la investigación

realizada en este proyecto, sí se puede recuperar algo de información de la memoria RAM

utilizando métodos físicos. Esto abre la posibilidad de que todavía podamos obtener claves para

una investigación forense aún si encontramos el equipo apagado.

33

No hay duda de que una metodología es llevada a cabo en un fraude computacional, por lo que

tampoco hay duda de que una investigación forense debe contar con una metodología también,

además una metodología formal permite al investigador enfocar e investigar un crimen en forma

racional y rápidamente. También es importante establecer un protocolo por el cual la evidencia

electrónica es obtenida y manejada para reducir el riego de ser corrompida. Sin una metodología

será más difícil investigar exitosamente y por lo tanto controlar un abuso o fraude computacional.

Es requisito que en un proceso de investigación forense se exhiban las características de una

metodología científica. Por ejemplo un proceso válido debe consistir en pasos bien definidos que

puedan ser repetidos en toda la investigación, cada paso debe ser consistente. Sin una

metodología formal comprobada la evidencia recopilada no será tomada seriamente en una corte.

En este trabajo se ha establecido una metodología general aplicada al estado “vivo” del sistema,

para que a partir de ésta se pueda llevar a cabo una recolección de información volátil útil en una

investigación forense, esta metodología será aplicada en cincos casos diferentes con el equipo

encendido y con sus procesos corriendo en forma “normal”, bajo los sistemas operativos más

comunes Linux con Red Hat Entreprise 3 y Windows 2000.

Como parte de la investigación también se mostrarán las herramientas útiles para llevar a cabo

cada procedimiento, dentro de las dos plataformas descritas, esto con el fin de que una vez que

conozcamos lo que existe en el mercado y lo que podemos utilizar del sistema operativo

tengamos la oportunidad de crear un conjunto de herramientas que nos va a ayudar a realizar la

recolección de información. Este paso de crear el conjunto de herramientas es tan importante

como el de la investigación misma, por lo que el siguiente capítulo mostrará estas herramientas,

así el investigador podrá decidir cuales son la que utilizará en su investigación.

Considerando también el problema al que se enfrenta el investigador forense en una situación

donde el estado del sistema esta “muerto”, en el último capítulo se expondrá una serie de

ejemplos experimentales llevados a cabo por Universidades con especialidades en

semiconductores y seguridad, que se basan en los defectos de los dispositivos semiconductores

para recuperación de información en las memorias, y así obtener información clave para una

investigación forense.

34

CAPITULO 3

HERRAMIENTAS PARA LA RECOLECCIÓN DE INFORMACIÓN DE DATOS VOLÁTILES Y MEMORIA

35

3. HERRAMIENTAS PARA LA RECOLECCIÓN DE

INFORMACIÓN DE DATOS VOLÁTILES Y MEMORIA.

Como hemos mencionado el conjunto de herramientas que utilizará el investigador forense o el

equipo de respuesta a incidentes para la captura de información volátil es tan importante como los

pasos del proceso forense.

Es importante conocer las herramientas que existen en el mercado y las que el sistema trae ya

integrado. La memoria RAM como dispositivo de alta volatilidad involucra que muchas veces el

investigador tenga que recolectar información con lo que tenga a primera mano, este es el caso

del sistema operativo. Con experiencia y el conocimiento propio, el sistema operativo puede ser

una excelente plataforma para realizar la recolección de evidencia.

Durante este capítulo se presentarán las principales herramientas de sistema para la recolección

de información volátil, programas para realizar imágenes de memoria, así como software forense

especializado que nos puede ser útil para conformar nuestro conjunto de herramientas de

recolección.

36

3.1 SO WINDOWS NT Y 2000

3.1.1 HERRAMIENTAS DE CAPTURA CON UTILERÍAS DEL SO PARA WINDOWS

Los comandos y utilerías para tareas administrativas del sistema pueden ser de gran utilidad ante

una respuesta inmediata. Esta es la razón por la que a continuación se exponen herramientas del

sistema operativo que no tiene el propósito específico de capturar información para un proceso de

investigación forense, pero se pueden utilizar para ese fin.

3.1.1.1 MS-DOS y comandos del sistema

La tabla 3.1 muestra los comandos útiles y su función en la recolección de datos. Todos estos

comandos van incorporados dentro del sistema operativo, por lo que no será necesario bajarlos de

Internet o comprarlos, a menos que no contemos con el sistema operativo. Tabla 3.1 Comandos del sistema operativo Windows Utilería

Función

debug y dump Visualiza la memoria, carga porciones del disco en memoria y vuelve a grabarlas, pero del subsistema de MSDOS únicamente.

mem Muestra qué y cuánta memoria se está utilizando, pero del subsistema de MSDOS únicamente.

at.exe

El comando AT programa la ejecución de comandos y programas en un equipo a una hora y fecha especificadas. El servicio de programación debe estar en ejecución para utilizar el comando AT.

cmd.exe

Inicia una nueva instancia del intérprete de comandos de Windows XP

dir.exe Muestra la lista de subdirectorios y archivos de un directorio.

ipconfig.exe

Muestra la dirección IP, máscara, subred, puerta de enlace. Puede liberar o renovar las concesiones de dirección IP.

nbtstat.exe

Muestra las estadísticas del protocolo y las conexiones actuales de TCP/IP usando NBT (NetBIOS sobre TCP/IP).

net.exe

Muestra información de cuentas, computadoras, estadísticas de red.

netstat.exe

Muestra estadísticas del protocolo y conexiones TCP/IP actuales

nslookup.exe

Muestra información acerca del nombre de host o de dominio

route.exe

Manipula tablas de enrutamiento

tracert.exe Muestra la ruta para llegar a un host determinado, los saltos y el tiempo

37

Utilería Función de espera hostname

Comando de sistema que despliega el nombre de la máquina

arp

Despliega y modifica la tabla de direcciones IP a direcciones físicas, utilizando el protocolo ARP

doskey

Almacena el historial de comandos aplicados en la línea de comandos.

archivo .dmp Archivo donde se descarga la memoria RAM.

dumpchk.exe Comando que se utiliza para verificar que un archivo dump ha sido creado correctamente, es localizado en el CD-ROM de Windows. Se instala ejecutando setup.exe desde el directorio Support\Tools del CD [25].

reg regedit

Estas herramientas permiten hacer una copia del registry. Reg permite agregar, cambiar, buscar, respaldar, restaurar y realizar operaciones sobre el registry en una línea de comandos, puede ser usada en computadoras locales y remotas.

3.1.1.2 Windows Resource Kits

El Resource Kit de Windows es un conjunto de herramientas, artículos y referencias que ayudan

al profesionista en Tecnologías de Información a dar soporte al sistema operativo. Contiene un

conjunto de herramientas que ayuda al administrador con tareas comunes y soporte a fallas en la

operación del sistema. Principalmente para la administración del “Active Directory”1,

configuración de red, características de seguridad y desarrollo de aplicaciones [23].

El Resource Kit de Windows 2000 incluye muchas herramientas, pero solo algunas de ellas están

libres en Internet. Estos archivos son ejecutables autoextraibles que instalan la herramienta y su

documentación en la computadora, de entre ellas podemos utilizar y adquirir las publicadas en la

tabla 3.2. Tabla 3.2 Herramientas de Windows Resource Kit libres Utilería Función

dh.exe

Es un comando en línea que despliega información acerca del uso de procesos en modo usuario y modo kernel. Acepta switches para identificar el proceso desplegar y enviar a un archivo de texto. Es muy útil para listar la basura de memoria y llamadas de asignación de memoria. Despliega “memory hogs” (programas que utilizan mucha memoria. Envía la información a un archivo de descarga (dmp). Nota: Se tienen que

1 El Directorio activo de Windows es un componente central de dicho sistema operativo que proporciona los medios para gestionar las identidades y relaciones que organizan su entorno de red.

38

Utilería Función configurar algunas variables globales en el sistema (gflags) y en el registry

drivers.exe

Esta herramienta lista los drivers cargados en la máquina. Nota: Se aplica solo localmente

pfmon.exe

Este comando en línea permite al desarrollador o administrador de sistema monitorear fallas de páginas (page faults) que se presentan cuando una aplicación está corriendo.

pstat.exe

Es una herramienta que lista todos los hilos (threads) que están corriendo y despliega su estado. Esta herramienta es similar a Qslice.exe, pero utiliza una línea de comandos en vez de la interfaz gráfica. Esta versión de pstat toma una fotografía (snapshot) del sistema.

pulist.exe

Esta herramienta despliega procesos corriendo en maquinas locales o remotas. Despliega el nombre del proceso, su ID e intenta obtener el user name asociado. Esto es importante cuando múltiples procesos se están ejecutando en el sistema en diferentes contextos de seguridad.

qslice.exe

Muestra el porcentaje del total de CPU en uso por cada proceso en el sistema. Es similar a pstat.exe pero presenta la información en forma gráfica.

showperf.exe

Es una herramienta gráfica que permite a los desarrolladores descargar y desplegar raw performance data del registry y desplegarla.

apimon.exe

Monitorea aplicaciones corriendo de todas las llamadas API (Application Programming Interface) de un proceso.

sclist Es un comando en línea que muestra los servicios actualmente corriendo, los servicios parados o todos los servicios en una computadora local o remota. http://www.petri.co.il/download_free_reskit_tools.htmNota: En forma remota solo si se encuentra dentro del dominio

svrinfo Es un comando que despliega los servicios, información acerca del espacio en disco y tipo de particiones en un servidor remoto. http://www.petri.co.il/download_free_reskit_tools.htmNota: Despliega la información local y la información de servidores donde se este conectado o WinXP.

showmembers Es un comando que muestra los miembros de un grupo dentro de un dominio o los grupos en forma local. http://www.petri.co.il/download_free_reskit_tools.htmNota: Para mostrar los miembros del dominio se necesita estar dentro de éste.

dumpel.exe Es un comando en línea que descarga la bitácora de eventos de un sistema local o remoto a un archivo de texto (tab-separated) http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/dumpel-o.asp

now.exe Despliega la fecha y tiempo del sistema en la salida estándar

Los comandos publicados en la tabla 3.3 no se encuentran libres, por lo que hay que comprarlos: Tabla 3.3 Herramientas de Windows Resource Kit con costo Utilería Función

cconect.exe Concurrent Connection Limiter. Provee un método para rastrear conexiones

http://www.petri.co.il/download_free_reskit_tools.htm



http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/dumpel-o.asp

39

Utilería Función

concurrentes y monitorear que usuarios están conectados al sistema. showacls.exe

Enumera los derechos de acceso para archivos, fólderes y árboles.

sleep.exe Batch Files Wait. Causa que la computadora espere por una cantidad de tiempo especificada.

top.exe

Time-Ordered Processes. Lista los procesos que está usando el tiempo del procesador.

totlproc.exe

Total Processors. Mide el uso de memoria de todos los procesos instalados.

usrstat.exe User Statistics. Lista los nombres completos de usuarios y su última conexión.

3.1.1.3 Herramientas para Windows no propietarias

Existen herramientas libres en Internet para Windows. Una de las más importantes es

md5sum.exe que determina cuando la información ha sido modificada. Una buena práctica es

correr las herramientas de captura, enviar la salida a algún medio e inmediatamente generar un

md5sum o registro de tiempo de los datos.

Otras herramientas útiles son el fport.exe, ethereal, winhex y las utilerías de PsTools [10]. Una

búsqueda en Internet obtendrá estas y otras herramientas, que se podrán utilizar durante una

examinación forense.

PsTools

Los kits de recursos de Windows NT y Windows 2000 vienen con un número de herramientas de

comandos en línea que ayudan a administrar el sistema. PsTools es un conjunto de herramientas

no propietario de Microsoft que incluye comandos similares a los kit de recursos de Windows [27].

Todas estas utilerías trabajan en Windows NT, Windows 2000 y Windows XP y no necesitan ser

instaladas como las herramientas del Resource Kit. La suite PsTools incluye las utilerías

mostradas en la tabla 3.4.

40

Tabla 3.4 Suite PsTools

Utilería Función

psexec

Ejecuta procesos remotamente. Nota: Se necesita cuenta y password de la máquina remota para ejecutar el comando deseado.

psfile

Muestra los archivos de la máquina que han sido abiertos remotamente

psgetsid

Despliega el SID de una computadora o usuario

pskill

Elimina procesos por nombre o ID

psinfo

Lista información detallada acerca de los procesos, el tipo de SO, versión, etc.

psloggedon

Muestra quien esta en una sesión localmente y quienes están conectados a recursos compartidos y desde que hora iniciaron la sesión. Si el servidor esta dentro de un dominio conectado con otros servidores puede dar algunas otras conexiones de usuarios con otros servidores diferente a el.

psloglist

Descarga la bitácora de eventos. Nota: Solo para WinXP.

pspasswd

Cambia los passwords de cuentas

psservice

Muestra y controla servicios

psshutdown

Da de baja o reinicializa la computadora

pssuspend

Suspende procesos de la máquina remota o local

psuptime

Muestra cuanto tiempo el sistema ha estado arriba. Se ha incorporado a psinfo.

pslist

PsList es una utilería que muestra una combinación de información de los dos comandos del Resource Kit (ps y list), incorporando la habilidad de poder ver procesos y estadísticas de hilos en una computadora remota. Con los parámetros de default PsList muestra información orientada a CPU de todos los procesos que están corriendo en el sistema local. La información listada por cada proceso incluye el tiempo de procesador en que se ha ejecutado y cantidad de memoria física asignada. Nota: Para obtener los datos remotamente se necesita que el equipo remoto tenga habilitado el puerto RPC o tener corriendo los servicios remotos del registry.

SYSINTERNALS listdlls

Lista los DLLs abiertos por cada proceso, etiqueta los DLLs cargados con diferentes números de versiones que pueden corresponder a archivos en disco y pueden decir cual DLL esta relocalizado porque no está cargado en su dirección base. Nota: Corre en la máquina localmente

process explorer Muestra la información acerca de un proceso determinado y sus DLLs cargadas o abiertas. Consiste en dos ventanas. Una ventana muestra una lista de los procesos activos, incluyendo el nombre de sus propietarios, si el proceso es un DLL se observará la memoria mapeada. Nota: Corren en la máquina localmente

tcpcon /tcpiew Enumera los “endpoints” de TCP y UDP

41

Utilería Función http://www.sysinternals.com/utilities/tcpview.html Nota: Funciona localmente

3.1.1.4 Herramientas varias

Un posible ataque lo podemos detectar al encontrar un volumen de tráfico inesperado en lugares

inusuales. Para detectar el tráfico anómalo debemos entender muy bien el flujo de tráfico de red.

Para lo cual podemos utilizar algunas herramientas libres disponibles e instalarlas en cualquier

linux para formar un buen conjunto de herramientas, aunque el objeto de análisis sea Windows

[22].

Mientras no contemos con una solución integrada, podemos construir un conjunto simple y

rápidamente con las herramientas mostradas en la tabla 3.5.

Tabla 3.5 Herramientas varias Windows

Utilería Función

ethereal Permite capturar y graficar tráfico de red, corre bajo Windows y bajo Linux.

La habilidad de Ethereal para capturar el tráfico de red 802.11 en Windows es limitado debido al bajo soporte ofrecido por los drivers 802.11 de los adaptadores. En Windows, no se puede administrar la captura o controlar los frames, tampoco se puede capturar en modo promiscuo, por lo que solo se podrá capturar el tráfico para y desde la máquina que está corriendo Ethereal. Esto se debe considerar al correr este software en Windows.

etherape Construye “talkers map” para un segmento de red dado, es una gran herramienta para caracterizar trafico “normal”.

tcpreplay Permite repetir tráfico capturado y controlar la velocidad en la cual fluye a través de otro programa.

fport.exe

Fport es soportado por Windows NT, 2000 y XP. Este comando reporta todos los puertos TCP/IP y UDP abiertos. Es la misma información que se despliega usando el comando “netstat -an”, pero muestra estos procesos con el PID corriendo, nombre y ruta. Puede ser utilizado para identificar rápidamente puertos desconocidos abiertos y sus aplicaciones asociadas. http://www.foundstone.com

winhex

Es un editor hexadecimal que es utilizado en recuperación de datos y procesamiento de datos a bajo nivel. Inspecciona y edita toda clase de archivos, recupera archivos borrados o datos perdidos del disco duro en sistemas de archivos corruptos y también en tarjetas de cámaras digitales. Se puede descargar de la siguiente dirección: http://www.winhex.com/winhex/index-e.html

l0pthcrack L0pthCrack o LC es una aplicación para recuperar y auditar passwords. Se puede obtener una versión de evaluación por 15 días en Internet. http://www.atstake.com/products/lc/

pwdump2 Descarga los password hashes (trozos de password encriptados en formato ASCII) del

http://www.sysinternals.com/utilities/tcpview.html

http://www.winhex.com/winhex/index-e.html

42

Utilería Función Active DIrectory. Es una herramienta libre en Internet. http://www.bindview.com/Services/razor/Utilities/Windows/pwdump2_readme.cfm

quickwiper Es una utilería para limpiar discos y archivos, se puede obtener una versión de evaluación en Internet. http://www.soft32.com/download_4586.html

e-timestamp Obtiene un sello de tiempo de los archivos, se puede obtener una versión de evaluación en Internet. http://www.e-timestamp.com/

md5sum.exe

Con la verificación md5 se compara la huella digital (fingerprint) de los archivos que se bajaron con la huella digital de los archivos publicados en el servidor, esto con el fin de verificar que los archivos no estén corruptos. Esta herramienta se encuentra libre en Internet. http://www.etree.org/md5com.html

nmap.exe Programa de escaneo de puertos, versión libre para Linux y para Windows. http://www.insecure.org/nmap/nmap_download.htmlNecesita tener instalado winpcap ( http://www.winpcap.org/ ) que es una serie de librerías Open Source Windows, que son usadas por capas de red de bajo nivel y es la máquina (engine) de varias herramientas de red comerciales y de código abierto (open source). Como nmap, snort, windump, ntop, etc. Nota: Necesita tener instalado winpcap en la máquina donde será corrido.

ntlast

Analizador de bitácoras de seguridad. Identifica quien ha ganado acceso al sistema. http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/freetools.htm Nota: En el equipo bajo análisis deben estar habilitadas las políticas de auditoría

showin Muestra información acerca de Windows. Revela passwords http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/freetools.htm

bintext Encuentra strings en un archivo. http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/freetools.htm

filemon

Monitorea y despliega la actividad del sistema de archivos en tiempo real. Explora la forma en que trabaja Windows, buscando cómo las aplicaciones utilizan los archivos y DLLs. La característica de sello de tiempo (timestamp) de Filemon muestra cuando la abertura, lectura, escritura o borrado se llevó a cabo y el resultado. http://www.sysinternals.com/Utilities/Filemon.html

netcat (cryptcat)

Utilería usada para crear un canal de comunicación entre dos sistemas diferentes. Cryptcat es usada para crear canales de comunicación encriptado. Netcat provee la forma de transferir información entre sistemas en red.

3.1.1.5 Volcado de memoria

El volcado de memoria es un procedimiento de descarga de información de memoria a un un

archivo creado en el sistema con extensión “*.dmp”. Las acciones que realiza Windows cuando

se produce este error son: escribir un suceso en el registro del sistema, alertar a los

administradores, vaciar la memoria del sistema en un archivo que se puede depurar y reinicia

automáticamente el sistema [24].

http://www.insecure.org/nmap/nmap_download.html

http://www.winpcap.org/

http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/freetools.htm

http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/freetools.htm

http://www.sysinternals.com/Utilities/Filemon.html

43

Los registros del archivo de volcado de memoria son un conjunto de información que puede

ayudar a identificar porque la computadora ha parado inesperadamente. Esta opción requiere un

archivo de pagineo (paging file) de por lo menos 2 MB (megabytes) en el volumen de booteo. En

computadoras corriendo Windows 2000 o sistemas recientes, Windows crea un archivo nuevo

cada vez que la computadora para inesperadamente.

Userdump.exe

Esta herramienta se puede utilizar para generar un volcado de usuario de un proceso que se cierra

con una excepción o cuando un proceso deja de responder (bloqueos) [25].

Como leer los archivos dump

Para leer los archivos dump utilizamos la herramienta WinDbg que permite ver el contenido de

los archivos generados por un volcado de memoria producidas por violaciones de acceso por

fallas de página inválidas o fallas de protección [26].

3.1.3 HERRAMIENTAS FORENSES PARA WINDOWS

La mayoría del software forense que se puede correr en Windows es comercial y se necesita

pagar una licencia para poder utilizarlo, en algunos sitios se puede bajar un demo para presentar

el producto. A continuación se muestran algunos productos, pero no se hace uso de ellos en esta

investigación.

3.1.3.1 Software comercial

El software comercial, tiene un costo para poder utilizarlo, algunos de estos productos tienen una

copia de evaluación o demostración, que el investigador podrá bajar y si es útil y se puede

adaptar fácil a sus necesidades, comprarlo. Algunos de los productos comerciales para Windows

son mostrados en la tabla 3.6.

Tabla 3.6 Software comercial para Windows

44

Producto Características

detective y byteback

Ambas herramientas son comercializadas por la compañía Tech Assist Inc. Byte Back es una herramienta de recuperación. Dentro de sus características se encuentra la clonación o creación de imágenes, la recuperación de archivos en particiones FAT y NTFS. Detective es una herramienta de búsqueda y reporte sobre windows, diseñada para investigar PCs en red y stand-alone. Se puede obtener una copia de evaluación en la siguiente dirección en Internet previo registro http://www.toolsthatwork.com.

encase forensic edition

EnCase es un software para Win95/98 y NT, se utiliza para la recuperación de archivos. Utiliza un lenguaje de programación EnScript que permiten al investigador diseñar sus propias rutinas. Los sistemas de archivos interpretados por este software son: FAT, NTFS, HFS, Sun Solaris UFS, EXT, BSD, Palm entre otros. Se puede obtener un CD de evaluación en Internet previo registro en la dirección http://www.guidancesoftware.com/

forensic utility suite

Se puede obtener un software de demostración en Internet previo registro en la dirección http://www.lc-tech.com para el kit con Filerecovery, Photorecovery y RescuePro.

forensic toolkit password toolkit

Access Data es una empresa que ofrece capacitación y servicios en forensia, dentro de sus productos se encuentran:

Forensic Toolkit. Existe una versión de demostración en su página de Internet en la siguiente dirección : http://www.accessdata.com

Password Toolkit. Se puede obtener de la siguiente dirección http://www.accessdata.com

ghost partition magic

Norton Ghost 2002. Software de Symantec que puede clonar y restaurar particiones individuales o discos completos, y puede enviar y recibir imágenes de disco a través de LAN, USB, y conexiones de puertos paralelos. El editor de imágenes de Ghost Explorer permite usar drag-and-drop para mover archivos y directorios dentro o fuera de la imagen clonada. Partition Magic. Software que permite realizar particiones en diversas plataformas. Ambos productos se pueden obtener de la siguiente dirección en Internet : http://www.symantec.com

safeback

Software que es utilizado para crear imágenes de disco duro. Las imágenes de SafeBack no pueden ser modificadas o alteradas. Se puede obtener en la siguiente dirección:http://www.forensics-intl.com/

forensic replicator forensic sorter pda seizure

Paraben Corporation es una empresa que se dedica a ofrecer servicios forenses, capacitación, equipo y software, a través de su página en Internet http://www.paraben.com, podemos encontrar los siguientes productos:

Forensic replicator. Se utiliza para crear réplicas exactas de controladores (drives) y medios. Es basado en windows. Forensic sorter. Ordena los datos en una forma efectiva para hacer búsquedas exactas. PDA Seizure. Herramienta diseñada para capturar y reportar datos de un PDA, reportando sobre un ambiente windows.

ilook

Es distribuido gratuitamente para agencias calificadas como: Inteligencia, Militar y Gobierno. Se puede encontrar en la siguiente dirección: http://www.ilook-forensics.org.

http://www.lc-tech.com/

http://www.paraben.com/

45

3.1.3.2 Hardware forense

Ya hemos hablado del software necesario para la recolección y análisis forense, pero es necesario

contar con un equipo donde se corra este software que nos va a ser de utilidad para recolectar

datos, monitorear la red y hacer imágenes de disco. Este equipo puede construirse o adquirirse.

Como desconocemos el tipo de SO, equipo de cómputo o dispositivo de comunicación con el que

nos vamos a enfrentar, lo mejor es contar con la mayor cantidad de controladores (drivers) de

dispositivos y Sistemas Operativos. Aún así se puede utilizar cualquier computadora, pero en el

caso de un investigador profesional es mejor estar preparado. Algunos productos de hardware

forense son mostrados en la tabla 3.7.

Tabla 3.7 Hardware Forense

Empresa Producto y descripción

FRED (Forensic Recovery of Evidence Device). Es un equipo que puede ser usado tanto para la adquisición como para el análisis de evidencia. Es modular y se puede usar como una PC estándar.

Tiene preconfigurado multi-boot de Sistemas Operativos (DOS 6.22, Windows 98, XP Prof), contiene el software DriveSpy que es un shell de DOS que puede procesar particiones FAT ocultas de DOS, archivos borrados, espacio asignado o no y RedHat con Norton SystemWorks. Otras de las utilerías con las que cuenta es Image (genera imágenes de discos floppy), PDWipe (limpia el disco duro), PDBlock (previene escrituras inesperadas a un dirve físico), Part (provee información acerca de las particiones del disco duro) y hash MD5.

Existen varias versiones de este tipo de equipo más equipadas o más portátiles.

Intelligence, Inc Compañía que ofrece soluciones de hardware y software para el cómputo forense. Sus productos se pueden obtener en la siguiente dirección: http://www.digitalintel.com/

UltraBlock Es un dispositivo que protege a controladores (drives) de escrituras inesperadas, se puede conectar a través de FireWIre y USB. UltraBlockIDE utiliza manejadores (drives) IDE, ATA, SCSI,etc

46

Empresa Producto y descripción

The Shadow Es un dispositivo que es instalado entre el controlador IDE sospechoso y el disco duro sospechoso. Permite a un sistema bootear en el ambiente sospechoso, manteniendo la integridad del ambiente bajo análisis. Para lo cual almacena y administra todas las operaciones de escritura y modificación del sistema. Asegurando que todas las actualizaciones y escrituras son obtenidas y almacenadas internamente redireccionándolas a una cache interna. Como opera a nivel físico, es compatible con todos los sistemas operativos.

Intelligent Computer Solutions Es una empresa que se dedica al diseño y manufactura de duplicación de equipos a alta velocidad, software de clonación, diagnóstico de sistemas y productos forenses. Sus productos se pueden encontrar en la siguiente dirección: http://www.ics-iq.com/products_cat_fr.cfm

Forensic Link MASSter Es un equipo portátil conteniendo un software de adquisición de datos. Realiza transferencia entre el disco duro sospechoso y un puerto FireWire o USB. Soporta MD5, SHA1 y CRC32 durante la adquisición. Captura cualquier Sistema Operativo, realizando copias a nivel de bit de drive sospechoso incluyendo todos los datos almacenados, archivos borrados, espacio libre y archivos slack. Los métodos de captura de datos se realizan con las herramientas Forensic Tool Kit, Encase y dd de Unix.

47

Empresa Producto y descripción Image MASSter Es un software de duplicación de dispositivos hecho para capturar datos de disco.

Forensic Workhorse IV

Equipo portable que contiene manejadores para CD-ROM, DVD, SCSI, IDE. El equipo es compatible con todo el software de forensia comercial, Encase, Forensic Tool Kit, Safe Back, Mares, etc. Este producto se puede encontrar en la siguiente dirección: www.forensics-computer.com

Adicional al conjunto de herramientas principal, hay muchos otros elementos de los que debemos

disponer cuando se realiza una investigación. Estos elementos incluyen elementos que ayudaran a

documentar actividades en el área. Los dispositivos de registro como cámaras fotográficas, los

medios de almacenamiento seguro y una buena libreta de apuntes.

Es necesario contar con un equipo de red pequeño, como un concentrador (hub) de 4 puertos y

cable de red. Un CD o floppy de respuesta a incidentes para ayudar a buscar y recoger evidencia

en forma segura, sin afectar al sistema victima.

Toma mucho tiempo crear un buen conjunto de herramientas, la mejor forma es probar y

anticipar los sistemas que pueden sufrir intrusiones. Poco a poco se hará mas completo hasta

crear un buen conjunto de herramientas para cada SO, tipo de kernel, etc.

La respuesta a un incidente dependerá de las herramientas que se tengan disponibles.

http://www.forensics-computer.com/

http://www.forensics-computer.com/

48

3.2 SO LINUX

La respuesta inicial en Unix y Linux es similar a la respuesta inicial en Windows, el objetivo es

obtener datos volátiles de los sistemas antes de proceder a la duplicación forense y poder

expandir el alcance de la respuesta inicial para obtener archivos de bitácoras, archivos de

configuración, sistemas de archivos y archivos relevantes (como herramientas hacker o

programas sospechosos) para confirmar rápidamente si ha ocurrido un incidente o no.

Lo bueno de utilizar Linux para Forensia es que la mayoría de las herramientas son libres y el

ambiente es flexible. Las limitaciones son que como la mayoría de las herramientas son libres, no

se tiene soporte técnico.

Según Kevin Mandia y Chris Prosise [36] una de las diferencias de trabajar en Unix y Linux con

respecto a Windows es la dificultad de recuperar archivos borrados en algunas variantes de Unix

y Linux. Cuando se ejecuta un proceso en Windows NT/2000, no se puede borrar el archivo

correspondiente al proceso. Sin embargo Unix y Linux permite borrar un programa después de

que ha sido ejecutado, el proceso puede seguir corriendo, aun cuando el archivo ha sido borrado

del disco duro.

3.2.1 HERRAMIENTAS DE CAPTURA PARA EL SO LINUX

Linux provee muchas utilerías para realizar recolección y restauración de información del

sistema, cuenta con software de captura de imágenes de memoria como dd y dio. Preparar el

conjunto de herramientas (toolkit) no es tan fácil y toma tiempo, porque cada variante del sistema

operativo puede llegar a requerir un conjunto de herramientas único.

49

3.2.1.1 Comandos del Sistema Operativo Linux

Para evitar una dependencia de las bibliotecas en el sistema víctima, se deben compilar las

herramientas estáticamente. Con la opción “static” para crear un programa ejecutable que no

requiera el uso de bibliotecas compartidas. En caso de ser necesario se puede utilizar el comando

“ldd” para determinar si el programa incluye librerías dinámicas e incluir éstas en el conjunto de

herramientas.

La tabla 3.8 expone comandos del sistema operativo Linux y su utilidad para la recolección de

información.

Tabla 3.8 Comandos del Sistema Operativo Linux para recolección Utilería Función

ps Recopila información de los procesos

-aux lsof Lista los archivos abiertos

top Despliega los proceso del CPU

netstat Imprime conexiones de red, tablas de ruteo, etc.

-nr nmap Herramientas de exploración de red y escaneo de seguridad.

$ nmap –O IPaddr Intenta adivinar el tipo de SO de la IPaddr

nslookup Permite interactuar con un DNS

whois Cliente para el servicio de directorios Whois

host Utilería para la búsqueda en el DNS

nc Netcat, permite conexiones de TCP y UDP

uptime Dice cuanto tiempo el sistema ha estado corriendo

w, who Muestra quien está logeado y que está haciendo.

fuser Identifica procesos usando archivos o sockets

strace Rastrea llamadas a sistema y señales

50

Utilería Función

ltrace Rastrea llamadas a librerías dinámicas que son llamadas por el proceso ejecutado.

strings Imprime los caracteres reconocibles de un archivo. Es útil para determinar el contenido de archivos que no son de texto.

Md5sum Crea y verifica la autenticidad del archivo (checksum)

dd Convierte y copia un archivo Lee dispositivo de discos bloque por bloque, incluyendo bloques de datos marcados como borrados. Copia datos que no copian las herramientas para respaldos regulares como tar o dump.

cat Concatena archivos e imprime en la salida estándar.

lsmod Lista los módulos cargados. Esta información también se encuentra en /proc/modules: $ cat /proc/modules

sfdisk Manipula la tabla de particiones de Linux

df Reporta el espacio utilizado por el sistema de archivos del disco

dmesg Imprime los mensajes de inicio en el booteo

Last Muestra la lista de los usuarios loggeados

date Despliega la fecha y hora del sistema

Ifconfig -a Despliega la información acerca de la tarjeta de red.

ls Información de timestamp, último acceso, modificación y creación para cada archivo. Las opciones son: -c para la última modificación del i-nodo, -a para el último acceso, -ls para la última modificación del estado del archivo. La modificación del i-nodo puede ser: cambiar los permisos (Mode changed), cambiar el nombre del archivo, copiarlo a otro equipo o crear el archivo (File created). El acceso puede ser: verlo o copiarlo con ftp. El estado del archivo puede ser realizar un cambio interno.

find Busca archivos. Ejemplos pueden ser: Buscar archivos por permisos: $ find / -perm 540 –ls Buscar archivos donde el propietario es root: $ find / -user root –ls Buscar archivos modificados en los ultimos 5 días: $find / -mtime -5 Mostrar archivos modificados la semana anterior: $ find / -mtime +2 –a +mtime -7

printenv Imprime todo o parte de un ambiente

file Determina el tipo de archivo. Clasifica los archivos en varios tipos, prueba el sistema de archivos, el número mágico y el lenguaje.

ptrace Llamada a sistema que provee una interfaz por la cual un proceso padre puede observar y controlar la ejecución de otro proceso, examinar y cambiar su imagen core y registros. Es usada principalmente para implementar “breakpoints debugging”

script Hace un typescript de todo lo que se ha impreso en la Terminal. Para iniciar la captura solo se ejecuta el comando “script” para finalizar la captura se puede usar CTRL-d.

more Filtro para páginas a través de texto en una pantalla a la vez

51

Utilería Función

gzip Comprime o expande archivos

bash Shell Bourne. Abre un shell, o espacio de trabajo.

DES Algoritmo criptográfico.

modinfo Despliega información acerca del módulo de kernel

vi Editor de texto. Nota: se puede evitar que los comandos se guarden en el historial con !: “ : ! cat /etc/passwd “

pkginfo Despliega los paquetes de software instalados, para versiones de UNIX , AIX y Solaris.

rpm Red Hat Package Manager. Utilería que permite desplegar los paquetes de software instalados e información referente a estos con la opción: rpm –qa, rpm –qai paquete

rm Remueve archivos y directorios

cp Copia archivos y directorios

mmap Mapea o desmapea archivos o dispositivos en memoria. Es una función para programar

/usr/sbin/tcpd Tcpd anota todos los intentos de conexión que le llegan en /var/log/secure para que tenga la posibilidad de saber quien intenta conectarse a su máquina y si lo consigue

openssl Es una herramienta de criptografía que puede ser utilizada para la creación de llaves RSA, DH, DSA, creación de certificados, el cálculo de los “message digest”, cifrar o descifrar, pruebas de servidores con SSL y TLS, y manejo de correo encriptado.

pkg-config Obtiene metainformación acerca de las librerías instaladas. El directorio donde está instalada, etc. #pkg-config - -cflags glib #pkg-config - - modversion glib

iptables Herramienta de administración para el filtrado de paquetes $iptable –L Lista

debugfs Depurador del sistema de archivos ext2 Para listar los inodos borrados: $ debug /imagenes/floopy.img debug: lsdel

ldd Imprime dependencias de librerías compartidas

mount Comando que permite montar Sistemas de Archivos: CDROM, floppy,etc. swapon swapoff

Habilita o deshabilita dispositivos y archivos para pagineo y swapeo

pstree Despliega el árbol de procesos

Los archivos y programas mostrados en la tabla 3.9 también ayudan a proveer más información sobre el sistema: Tabla 3.9 Archivos y programas del sistema operativo Linux

52

Archivo Utilidad

/proc Es un pseudo-filesystem que funciona como interfaz para las estructuras de datos del kernel

/proc/meminfo Permite determinar la cantidad de memoria física. Podemos observar su contenido con cat.

/etc/inetd.conf o /etc/xinetd.conf Configuración de los servicios de Internet

Perl Lenguaje de programación, incluido en el SO (Red Hat)

/dev/mem Archivo de dispositivo tipo caracter que corresponde a la memoria física del sistema. Es un archivo especial que refleja la memoria principal – byte offsets en el archivo de dispositivo son interpretados como direcciones de memoria por el kernel

/dev/kmem Archivo de la memoria virtual del kernel, representa el espacio de direcciones virtual del kernel y una vista mas uniforme de la memoria en cuestión.

/var/log/wtmp Permite ver quien está logeado $ last –f ./wtmp | more

/etc/passwd Información de usuarios

/var/log/messages Información de las bitácoras

/etc/issue Archivo que contiene la información del SO y su versión.

/var/log/boot.log Archivo que contiene registros de inicialización del sistema.

/etc/fstab Mapa de particiones.

PATH La variable de ambiente PATH, direcciona la ejecución de los programas a la trayectoria definida por esta variable.

3.2.1.2 Volcado de memoria (Memory dump)

La facilidad de crear volcados de memoria (memory dump) provee un análisis de primera falla.

La caída de un sistema (crash) se presenta con una falla (bug) de hardware o software (Oops,

BUG() o panic). En Linux la información del volcado de memoria contiene el estado del

procesador, un rastreo de la pila y un conjunto limitado de instrucciones.

Existen parches disponibles para Linux e implementaciones de algunas versiones de Unix, que

reinicializan el sistema sin limpiar la memoria, vaciando una imagen de memoria a disco duro en

una partición swap. Este procedimiento no es estandarizado y generalmente no es disponible ya

que no todos tienen la facilidad del firmware PCBIOS para hacerlo, aún entre cambios de

53

versiones del mismo firmware, por lo que no es una solución razonable para sistemas operativos

de propósito general [15].

Existen máquinas Intel que no limpian la memoria en la reinicialización. Para saber si el equipo

con el que trabajamos es de ese tipo, en el kernel se coloca el parámetro “reboot=w”. Esto

advierte un “warm reboot” instruyendo al BIOS para saltar el chequeo de memoria. Algunas

veces funciona, aunque la mayoría no [13].

En la distribución de Linux Red Hat existen varias herramientas que podemos utilizar para

obtener información realizando un volcado de memoria: Netdump y GDB

Netdump (Network Console and Crash Dump Facility)

Los dispositivos de red son simples, permiten de una forma fácil habilitar un modo de

interrupciones no manejadas, esta característica le permite al sistema seguir trabajando, aun

cuando ocurra una caída del sistema (crash).

Netdump incluido en la versión de Red Hat Advanced Server 2.1 aprovecha esta ventaja y provee

la facilidad de realizar crash-dump y enviar la información a través de red. Netdump es una

arquitectura cliente-servidor, se debe instalar el paquete netdump-server y configurarlo, los

clientes configuran la dirección del servidor donde enviarán los mensajes del kernel y podrán

vaciar imágenes de memoria al servidor centralizado vía la red.

El servidor centralizado registra los mensajes del kernel, incluyendo crash signature messages,

etc. Los dumps son preservados para análisis comparativos, algo que no es fácil con crash dumps

sobre discos [15].

El crash dump se realiza antes de reinicializar el equipo, esto permite reservar solo la memoria

necesitada por el código de crash dump (algunas páginas de memoria), y extender la información

provista por el dump, incluyendo el estado del hardware.

GDB (GNU Project Debbuger)

54

GDB (Proyecto debugger GNU) desarrollado por Richard Stallman, es el depurador de GNU,

permite ver qué está pasando dentro de un programa cuando se está ejecutando o que otro

programa se está ejecutando en el momento de un crash. Viene incorporado en varios sistemas

como RedHat Enterprise.

Una vez iniciado, gdb lee los comandos desde la terminal. Dentro de GDB los comandos

“dump”, “append” y “restore” en GDB pueden copiar datos entre memoria y archivos. Los

comandos dump y append escriben datos a un archivo, y el comando restore lee los datos del

archivo para regresarlos a memoria. Los archivos pueden estar en formato binario[14].

El siguiente ejemplo vacía el contenido de la memoria desde la dirección de memoria start_addr

(0x00000) hasta la dirección end_addr(0xFFFFF): (gdb) dump memory descarga 0x00000 0xFFFFF

En el siguiente ejemplo el comando append agrega el contenido de la memoria desde la dirección

de memoria start_addr hasta la dirección end_addr al archivo filename en forma binaria.

(gdb)append [binary] memory filename start_addr end_addr

El comando restore, restaura el contenido del archivo en memoria. El parámetro “bias” es

agregado a la dirección contenida en el archivo. Los archivos binarios siempre empiezan en cero,

por lo que estos deberán ser restaurados en la dirección “bias”.

(gdb)restore filename [binary] bias start end

Proyecto LKCD

Existen varios módulos ya creados para Linux que nos permiten obtener información de la

memoria. Uno de éstos fue creado por el proyecto Linux Kernel Crash Dump (LKCD). Este fue

diseñado para que los administradores de sistemas tuvieran un método confiable para guardar

información y poder examinar una caída de su sistema (system crash).

El proyecto usa código a nivel de usuario y de kernel con los siguientes objetivos:

55

1) Salvar una imagen de memoria del kernel debido a una falla de software.

2) Recuperar una imagen de memoria del kernel cuando el sistema ha sido reinicializado (reboot).

3) Analizar la imagen de memoria para determinar que sucedió cuando la falla ocurrió.

La imagen de memoria es almacenada en una partición definida del sistema que es conocida

como dispositivo “dump”. Una vez que el sistema se normaliza después de la reinicialización del

sistema, pero antes de que la partición swap sea montada, el archivo dump es recuperado

utilizando la herramienta “lcrash” (Linux Crash).

LKCD permite realizar volcados no destructivos. Esto significa que el sistema continúa corriendo

después del proceso de volcado, pero en operaciones destructivas como “panic” el sistema se

reinicializará. La instalación de LKCD requiere que se reconstruya el kernel[11, 24].

3.2.2 HERRAMIENTAS FORENSES PARA LINUX.

El software que vimos en las secciones anteriores tiene como objetivo apoyar al administrador

del sistema, pero las herramientas forenses están diseñadas para apoyar al investigador forense.

Al igual que el software de capítulos anteriores, el conjunto de herramientas debe contener de

preferencia binarios estáticos que no utilicen bibliotecas o recursos dinámicos compartidos en el

sistema.

También puede ser útil no ejecutar los programas con nombre obvios de programas forenses o de

respuesta a incidentes como “graverobber”, “lazarus” o “mactime”. Por lo que se puede

renombrar las herramientas con nombre menos evidentes.

3.2.2.1 TCT Coroner´s Toolkit

TCT Coroner´s Toolkit es un paquete de utilerías escritas por Dan Farmer y Wietse Venema [35]

para la realización de un análisis forense en un sistema UNIX. Este software fue presentado por

primera vez en agosto de 1999. Fue diseñado para los sistemas Unix, pero puede recolectar y

analizar datos en discos o medios que no son de Unix. El sistema corre en FreeBSD, OpenBSD,

SunOS y Linux.

56

Los programas principales de TCT son:

• Grave-robber

Herramienta de captura de datos.

• Las herramientas C (ils, icat, pcat, file, etc.).

Estas son utilizadas por grave-robber, pero pueden ser utilizadas individualmente.

• Unrm & lazarus

Herramientas para recuperar archivos borrados y datos ocultos o perdidos. Unrm hace una copia

de todo el espacio en disco accesible y no asignado, lazarus analiza esta copia y trata de

determinar cada bloque de datos y su tipo.

• mactime

Herramientas que despliegan los patrones de acceso de los archivos.

De estas herramientas la más utilizada es grave-robber y mactime. Unrm y lazarus se utilizan si

se tiene tiempo y espacio suficiente para un análisis post-mortem por lo que no explicaremos

estas dos últimas herramientas ya que nuestro objetivo es la recolección de información volátil.

El tiempo necesario para obtener datos con TCT depende del sistema, su procesador y el espacio

requerido. Utilizar esta herramienta puede tomar tiempo considerable y crear un gran volumen de

datos. El análisis de esta información puede tomar horas.

Pasos de instalación: #cd /home/hforenses/ #tar zxvf tct-1.15.tar.gz #cd tct-1.15 #make

Se requieren varios megabytes para la salida del TCT. La herramienta unrm puede consumir más

del espacio localizado en el disco duro. TCT usa nombres de path completos.

Almacenar TCT en un floppy

57

Para preparar una copia de TCT y poder almacenarla en un floppy podemos realizar los

siguientes pasos: # mkdir /home/hforenses/tct # cp –R /home/hforenses/tct-1.15/* /home/hforenses/tct # rm –rf /home/hforenses/tct/data # rm –rf /home/hforenses/tct/src # rm /home/hforenses/tct/*.log

Después de este paso copiamos los archivos del directorio tct en un floppy: # cp –R /home/hforenses/tct/* /floppy/tct/

Debido a que la copia todavía tiene referencias a los directorios donde se realizó la instalación,

todas estas referencias deben ser cambiadas, para este propósito los autores de TCT proveen el

script de configuración que hace esta tarea muy simple: # cd /floppy/tct # perl reconfig

Terminado el script obtenemos la copia que necesitamos.

GRAVE-ROBBER

Es la herramienta de captura de datos de TCT, intenta obtener y salvar información del sistema

necesaria para el análisis. Esta herramienta puede ser usada en una máquina “viva” o en una

imagen de disco del sistema de archivos de la victima. En el modo “vivo” grave-robber obtiene la

información según el siguiente orden de volatilidad:

1) Toma los atributos de todos los comandos y archivos. Esta información es recolectada

primero para preservar los atributos de tiempo MAC

2) Toma información del estado de los procesos y opcionalmente la memoria de todos los

procesos corriendo

3) Los archivos borrados que aún están activos.

4) Los archivos ejecutables de todos los procesos.

5) Los atributos de los archivos borrados

6) La información del estado de la red

58

7) La información del estado del host, vía comandos dependientes del sistema que proveen

información de configuración.

8) Los atributos de archivos existentes.

9) Opcionalmente, la información sensitiva como archivos que garantizan acceso remoto a

cuentas de usuarios y trabajos “cron” para comandos de ejecución desatendida.

10) Copia archivos de configuración y archivos críticos.

Toda esta información es almacenada en un directorio protegido que tiene el nombre del host y la

hora de inicio de la recolección de datos. Para cada archivo que es almacenado, grave-robber

aplica md5 hash.

Por default grave-robber corre para el sistema completo, se recomienda que corra como root para

que capture archivos y procesos de información que no son disponibles para usuarios normales.

Esta captura puede tomar varias horas.

Grave-robber es útil sobre sistemas “vivos”, pero también puede usarse sobre la imagen de un

disco. Las opciones que maneja son:

-c Esta opción se utiliza para especificar la ruta donde se encuentra la imagen.

-o Indica el tipo de SO de la imagen.

-E Recolecta todo lo que puede, incluyendo operaciones como pcat.

-f Captura rápida. Trata de evitar rutinas “caras” de recolección.

-F Captura archivos de sistema de archivos.

-i Recolecta datos de i-nodos de áreas no asignadas.

-I Captura archivos ejecutables de procesos corriendo. Primero trata de copiarlo

utilizando /proc, después usa icat con información del inodo que fue obtenida de

lsof

-p Copia procesos de memoria a archivos con el comando pcat.

-P Corre los comandos –pcat, lsof, icat- para obtener datos de los procesos corriendo

y hacer copias de lo archivos ejecutables.

-s Ejecuta comandos de shell para obtener información de host y de la red -netstat,

df, etc-

59

-t Recolecta información de servicios (etc, hosts.equiv, xhosts, .rhosts)

-v verbose

-M Realiza un md5sum de todos los archivos

-V Obtiene el número mayor y menor de /dev

-d Especifíca el directorio donde se almacenará la información recolectada (data)

La información recolectada es almacenada en el subdirectorio “data/hostname”. Dentro de este

subdirectorio existirán los archivos y subdirectorios mostrados en la tabla 3.10.

Tabla 3.10 Archivos y directorios de Grave Robber

Archivo y directorio Función

body Este es un archivo donde se concentra la base de datos de “mactime” de todos

los archivos examinados como su información de inodo, checksum md5 y tiempo de acceso

body.s Este archivo contiene la misma estructura de “body” pero contiene información acerca de los archivos SegUID solamente.

coroner.log Archivo que contiene la lista la ejecución de los programas que fueron iniciados con argumentos y registros de tiempo.

error.log Archivo que contiene mensajes de error ocurridos durante la recolección de datos.

MD5_all Archivo que contiene la lista de todos los registros MD5 de todas las salidas generadas por grave-robber

MD5_all.md5 Archivo que contiene el registro MD5 del archivo MD5_all. pcat Este directorio contiene las imágenes de los procesos corriendo que pcat

puede recuperar. Obtiene el history de los shells. Puede preservar o saltar huecos en memoria, además de imprimir un mapa de memoria de procesos. Opera sobre id de procesos.

proc Este directorio contiene imágenes de los procesos corriendo pero en base al sistema de archivos /proc.

Removed_but_running Este directorio contiene todos los archivos borrados que estaban abiertos o corriendo a la hora de obtener la información.

user_vault Copia de archivos sensitivos de los usuarios encontrados mientras se realiza el análisis del sistema (como SSH key, archivos history, etc.)

deleted_files Este directorio contiene los archivos borrados que estaban abiertos o corriendo cuando grave-robber arrancó.

command_out El directorio de la salida de la mayoría de los comandos que ejecuta grave.robber

conf_vault Todos los archivos que son de interés para grave-robber son copiados en este directorio. Este incluye archivos de configuración, archivos críticos, directorios, etc.

trust Se almacenan los archivos respecto a relaciones de confianza entre equipos (.rhosts, etc.)

60

También podemos utilizar las herramientas “C” en forma independiente como se muestra a

continuación:

PCAT

Pcat es útil en un sistema vivo para examinar procesos, porque copia el contenido de la memoria

del proceso a una salida estándar, pero no copia procesos de sistema. Un ejemplo se muestra en

el siguiente comando que envía a pantalla la información legible (con “strings”) del proceso

id_proceso. # /tct/bin/./pcat id_proceso | strings | less

También se puede enviar esta información a un archivo para almacenarlo, ejemplo: # /tct/bin/./pcat id_proceso > archivo.txt

ILS

Ils lista la información de i-nodos, en un análisis post mortem es muy útil para recolectar i-nodos

de archivos borrados. Ils es útil en sistemas vivos para determinar datos que posiblemente estén

ocultos (archivos abiertos pero “desligados” (unlinked)). # /tct/bin/./ils –of ext2fs /dev/hda6 > archivo.txt

e = lista todo los inodos del sistema de archivos

r = lista solo los inodos de archivos borrados

o = lista solo los inodos de archivos borrados que aun están abriendo o ejecutando

f = especifica el tipo de Sistema de Archivos

Archivos no usados: # /tct/bin/./ils –zf ext2fs /dev/hda6

z = lista los inodos con estado cero en “change time”. Por lo tanto son inodos que nunca han sido

usados (archivo no usados)

61

Este comando nos pueden indicar cuantos archivos están instalados en el sistema y que nunca

hemos utilizado.

ICAT

La herramienta icat copia archivos por el número de i-nodo de un dispositivo dado a la salida

estándar, es útil para recuperar archivos borrados. La podemos usar directamente sobre el disco

para recuperar archivos borrados, como se muestra a continuación:

# /tct/bin/./ils –rf ext2fs /dev/hda2

O aplicarla a una imagen de disco, recuperando los archivos junto con ils, como se muestra a

continuación:

# /tct/bin/./ils –rf ext2fs /imagenes/dev_hda2.img class|host|start_time body|pegaso|1129578295 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|st_nlink 28|a|0|0|1125313915|1125313915|1125313915|0|0|… …st_size|st_block0|st_block1 …0|0|0

Donde st_ino es el número de inodo.

Con el resultado de ils utilizamos icat para recuperar el archivo :

# /tct/bin/./icat –hf tipo_FS devide_name num_inodo # /tct/bin/./icat –hf ext2fs/imagenes/dev_hda2.img 28

h = salta hoyos en archivos, por lo que la información de la dirección absoluta es perdida

H = preserva la dirección absoluta porque copia los hoyos como bloques nulos

f = especifica el tipo de sistema de archivos que estamos utilizando.

FILE

File hace una clasificación por tipos de archivos, haciendo pruebas de sistema de archivos,

número mágico o de lenguaje:

62

# /tct/bin/./file Nombre_de_archivo # /tct/bin/./file /tmp/borrados/* /tmp/borrados/1207: empty /tmp/borrados/16110: ASCII text /tmp/borrados/2039: ELF 32-bit LSB executable, Intel 80386, version 1 /tmp/borrados/2047: perl commands text

MAC times

Mactime es un programa que intenta determinar que archivos fueron accedidos o modificados

con una ventana de tiempo dada. El programa mactime ordena el resultado y produce una lista,

mostrando las tres características de tiempo de los archivos, modificación, acceso y cambio, que

nos permitirá inferir alguna actividad del intruso en cuanto a tiempos.

El siguiente es un ejemplo de utilización de mactime, para crear un reporte de registro de tiempo

de todo el sistema de archivos (se asume que todos los archivos fueron creados después de Enero

2 de 1970):

# /tct/bin/./mactime –y –R –d / 1/2/1970

-R recursivamente a través de los subdirectorios

-d especifica el directorio de escaneo en vez de utilizar la base de datos del archivo body.

-y despliega la fecha como “YY MM DD” en vez de “MM DD YY”

También se puede especificar un periodo de tiempo: # /tct/bin/./mactime –y –R –d bin 1/1/2005-1/14/2005

Todos los archivos son listados en orden por fecha y tiempo (primera columna). La segunda

columna lista el tamaño del archivo, la siguiente columna contiene la acción en el archivo: “m”

para modificación, “a” para acceso y “c” para creación.

Usando la opción –m con grave.robber, también llamamos a mactime para recolectar los registros

de tiempo. # /tct/bin/./grave-robber –m /mnt/hack/root

63

Este resultado es almacenado en la base de datos de recolección de información de TCT en

“data”.

3.2.2.2 MEMDUMP

Memdump es un programa que fue escrito para evitar los problemas que se pueden tener con

“dd” o “cat”. Fue diseñado para alterar la memoria lo menos posible [18]. Después de instalarlo se

crea un archivo ejecutable y se puede obtener una imagen de la memoria sin reinicializar el

sistema y puede ser transferido por la red con netcat o ssl

Esta herramienta provista por los mismos autores de TCT, permite obtener una descarga (dump)

de la memoria física.

En una descarga de sistema de memoria “system memory dump”, se espera encontrar

información del sistema operativo, de procesos corriendo y de cada archivo y directorio que ha

sido accedido recientemente. Dependiendo del sistema operativo, se puede encontrar información

de archivos borrados, sin embargo esta información tiende a ser de corta vida.[18]

Este programa descarga la memoria del sistema a la salida estándar, saltando los hoyos en los

mapas de memoria. Por default, el programa descarga el contenido de /dev/mem. La salida esta

en formato crudo. Sus opciones son:

-k = Intenta descargar la memoria del kernel /dev/kmem

-b = Número de bytes por operación leída en memoria

-d = Número de bytes de memoria a descargar

-m = Escribe el mapa de memoria a un archivo

-p = Especifica el tamaño de la página de memoria

-v = Modo verbose

A continuación se muestra el uso de memdump a través de la red:

memdump | nc hosts port

64

memdump | openssl s_client –connect host:port

Para un mejor resultado enviamos la salida sobre la red usando “netcat” u “openssl.

3.2.2.3 Sleuth Kit y Autopsy

Sleuth Kit (TSK) es una colección de herramientas basadas en TCT y Autopsy, es una interfaz

gráfica para TSK. Estas dos herramientas son de código abierto, corren en sistemas como Linux,

OS X FreeBSD, OpenBSD y Solaris, y analizan sistemas de archivos NTFS, FAT, UFS, EXT2FS

y EXT3FS [16].

Sleuth Kit (TSK) previamente conocida como @stake Sleuth Kit (TASK), es una colección de

herramientas de comandos en línea basada en TCT. Permite examinar el sistema de archivos de

una computadora sospechosa en una forma no intrusiva, porque estas herramientas no se

relacionan con el SO. Soporta particiones DOS, BSD y Mac.

TSK permite analizar la imagen de un sistema de archivos creado con dd o un software similar.

Autopsy proporciona una interfaz gráfica para utilizar las herramientas de TSK. Estas dos

herramientas, en conjunto con TCT hacen un poderoso paquete de herramientas forenses para

Unix, Linux y Windows.

TSK

Algunas de las herramientas que utiliza son:

fsstat Muestra los detalles y estadísticas del sistema de archivos.

dcat Despliega el contenido de un “pedazo” de disco de una imagen forense. La imagen

debe ser creada con dd.

dls Recupera datos de disco. Lista los detalles acerca de unidades de datos y puede

extraer espacio no asignado (unallocated) del sistema de archivos. Es llamado

“unrm” en TCT

dstat Despliega las estadísticas acerca de una unidad de datos dada.

dcalc Calcula donde existen datos en una imagen (dd), en una imagen “slack” (dls –s) o

una imagen “unallocated” (dls).

65

icat Copia archivos por número de inodo. Extrae las unidades de datos de un archivo

ifind Encuentra la estructura del metadato que tiene asignada una unidad de disco dada.

ils Lista la información de los inodos o estructura de metadatos

istat Despliega las estadísticas y detalles acerca de una estructura de metadatos dada.

ffind Encuentra el nombre de un archivo o directorio en base a un inodo dado. Asigna y

libera el nombre de archivos que apuntan a una estructura de datos dada.

fls Lista los nombre de archivos y directorios de una imagen.

hffind Utiliza un algoritmo de ordenamiento binario, que busca hashes.

mactime Toma las salidas de archivos fls e ils para crear una línea de tiempo de la

actividad de los archivos

sorter Ordena los archivos basados en su tipo y extensión

mmls Despliega la distribución del disco, incluyendo el espacio no asignado.

Estas herramientas del sistema de archivos permiten examinar archivos de sistema de una

computadora sospechosa de una manera no-intrusiva. Debido a que las herramientas no dependen

del sistema operativo para procesar archivos de sistema.

Autopsy

Autopsy Forensic Browser, es una interfaz gráfica para la herramienta de análisis forense TSK.

Hace posible el análisis de una imagen obtenida de la máquina víctima a nivel de archivo bloques

e inodo. Autopsy y TSK juntas proveen muchas de las características de herramientas

comerciales de análisis forense para sistemas de archivos Windows y Unix. Autopsy es basado en

HTML, cuenta con un administrador de archivos que muestra los detalles de archivos borrados.

Para la instalación de Autpsy es necesario haber hecho antes la instalación de TSK pues lo que

hace es proporcionar una interfaz gráfica para utilizar las herramientas de TSK. También es

necesario indicarle el directorio donde se concentrará la información de los casos que se manejen.

Una vez instalado se aplica el siguiente comando: #./autopsy

66

Este comando correrá un proceso y deberá permanecer abierto mientras se abre un navegador

HTML con el puerto 9999 del host local. Autopsy puede escuchar solicitudes de cualquier puerto,

por lo que el usuario puede conectarse desde cualquier otro sistema (Windows o Linux) para

operar con Autopsy utilizando un navegador.

La siguiente pantalla muestra el menú inicial, donde podemos ir documentando y analizando cada

caso:

Fig. 3.1 Autposy inicio

A continuación se le indica a Autpsy la creación de un nuevo caso:

Fig. 3.2 Autopsy nuevo caso

67

3.2.2.4 LIVE CD

BIATCHUX BOOTEABLE CD FORENSIC TOOLKIT

Es un CDROM booteable con una distribución portable que provee un ambiente inmediato para

realizar análisis forense, respuesta a incidentes, recuperación de datos, escaneo de virus.

Provee las herramientas necesarias para un análisis forense en vivo, solo montando el CD ROM,

es posible utilizarlos en SO win32, sparc Solaris y x86 linux, los binarios estáticos están

disponibles en /statbins [37].

Las últimas versiones cambiaron al nombre de FIRE

FIRE (Forensic and Incident Response Environment)

Es un CD-ROM booteable que contiene una distribución de Linux con herramientas de

seguridad útiles y un menú de sistema fácil de usar. Es creado y mantenido por William Salusky

[38]. Permite recolectar datos de un host comprometido para iniciar un análisis forense, provee las

herramientas necesarias para responder a un incidente de seguridad utilizando binarios estáticos

confiables de diferentes sistemas operativos como Linux, Solaris y Win32, puede recuperar datos

de particiones perdidas, realizar una verificación de virus y de discos duros en un ambiente

limpio y realizar pruebas de penetración y vulnerabilidades.

FIRE puede ser inicializado en un ambiente de ventanas (X-Windows) o con modo consola.

Requiere un procesador Intel x86 con por lo menos 48MB de RAM. Algunas de las herramientas

que son incluidas son nessus, nmap, hping2, ethereal, snort, tcpdump, ettercap, dsniff, airsnort,

chkrootkit, F-Prot, tct, tctutils, autopsy, testdisk, fdisk,, SSH (client and Server), VNC (client and

server) y perl.

68

Menú de utilidades:

Después de bootear con el CD, se despliega un menú de utilidades, mostrando las siguientes

opciones:

• Start-Here Configuración básica, red, DHCP, Nombre del servidor, etc.

• Virus Scan Realiza un escaneo de virus, puede actualizar firmas de red o desde un

floppy

• Forensics MounDrvsRO/UnMountDrvs que monta y desmonta las particiones

GetWin32Reg que busca los registros Win32 de la máquina local

GetUnixAuth que busca archivos de autenticación de la máquina local

Graphicimgs que busca imágenes

Mac-robber corre en los sistemas de archivos montados

ObtainDrvImg crea imágenes para almacenar

AutopsySetup inicia Autopsy

Si necesitamos utilizar un shell de comandos, podemos utilizar las teclas ALT-F1, ALT-F2, etc.

Con el menú de utilidades podemos montar todas las particiones, pero es importante también

desmontarlas una vez que se haya terminado de utilizarlas. El password de root es firefire.

El CD contiene varios binarios ligados estáticamente que pueden ser utilizados para recolección

de información y análisis forense en un sistema vivo.

KNOPPIX

Es un DVD o CD de inicialización (booteo) con una colección de software GNU/Linux,

detección de hardware automática y soporte para varias tarjetas gráficas y de sonido, SCSI y

USB. Es utilizado como un Linux de escritorio, CD educacional, sistema de respuesta o utilizado

como una plataforma de demostración para software comercial. Debido a la descompresión “on-

the-fly” el CD puede llegar a tener arriba de 2GB de software instalado en el.

69

El software instalado es: Linux-Kernel 2.6.x, KDE V3.x, K Office y Konqueror, X Multimedia

System, programas de manipulación de imágenes GNU, herramientas de seguridad y análisis para

administradores de red, OpenOffice [39].

PENGUIN SLEUTH

CD de booteo para Forensia basado en Knoppix [40]. Las herramientas de seguridad y Forensia

que tiene instaladas se muestran en la tabla 3.11.

Tabla 3.11 Herramientas de seguridad y Forensia para Linux

Herramienta Descripción

Sleuth Kit

Herramienta de Forensia

Autopsy

Parte de Sleuth Kit

Foremost

Herramienta para recuperar archivos utilizando sus cabeceras (headers) o parte final del archivo (footers) – foremost.sourceforge.net

Glimpse

Herramienta para realizar búsquedas rápidas a través de sistemas de archivos completos –www.webglimpse.net

Wipe Utilería en línea de comandos para borrado seguro – wipe.sourceforge.net

Dcfldd Convierte y copia archivos, es una herramienta similar a dd.

Etherape Monitor de red gráfico – etherape.sourceforge.net

Fenris Herramienta de análisis de trayectorias. “Tracer “ multipropósito razor.bindview.xom/tools/fenris/

Honeyd Demonio honeypot. Crea hosts virtuales una red especificada. www.citi.umich.edu/u/provos/honeyd

Snort Sistema de detección de intrusos – www.snort.org

Dsniff Sniffer de passwords – www.monkey.org/~dugsong/dsniff/

John The Ripper

Herramienta de crackeo de password. Para llamarla ejecutamos “john” www.openwall.com/john/

Nikto Herramienta para encontrar archivos web de default y examinar servidores Web y CGI. Ejecutar sobre la línea de comandos. – www.cirt.net/code/nikto.shtml

Nbtscan Herramienta en línea de comandos que escanea por información NETBIOS – www.unixwiz.net/tools/nbtscan.html

Ngrep Función grep en línea de comandos por red – www.packetfactory.net/projects/ngrep

http://www.citi.umich.edu/u/provos/honeyd

http://www.snort.org/

http://www.monkey.org/%7Edugsong/dsniff/

http://www.openwall.com/john/

http://www.cirt.net/code/nikto.shtml

http://www.unixwiz.net/tools/nbtscan.html

http://www.packetfactory.net/projects/ngrep

70

Herramienta Descripción

Nemesis Inyector de paquetes de red en línea de comandos. Sus ejecutables se encuentran en el directorio /KNOPPIX/usr/sbin/ nemesis-arp, nemesis-icmp, nemesis-rip, etc. - www.packetfactory.net/Projects/nemesis

Fragroute

Herramienta de pruebas de intrusión de red. Intercepta, modifica y reescribe tráfico de salida – monkey.org/~dugsong/fragroute/

Fping Utilería en línea de comandos para múltiples “pings” – www.fping.com

TCPtraceroute

Traza la ruta “traceroute” de paquetes TCP - michael.toren.net/code/tcptraceroute/

Tcpreplay Utilería en línea de comandos que reenvía paquetes de archivos capturados – tcpreplay.sourceforge.net

Nessus Cliente del escaner de seguridad de red, el servidor está a cargo del atacante – www.nesus.org

Ethereal

Analizador de red gráfico –www.ethereal.com

Netcat Herramienta en línea de comandos para leer y escribir sobre red – www.atstake.com/research/tools/network_utilities/

Tcpdump

Herramienta en línea de comandos que descarga tráfico de red –www.tcpdump.org/

Hping2 Envío de paquetes TCP/IP arbitrarios sobre hosts en red – www.hping.org

Ettercap

Sniffer multipropósito para LANs switcheadas – ettercap.sourceforge.net

Openssh

Utilería de conexión segura remota – www.openssh.com

Kismet Sniffer de redes inalámbricas – www.kismetwireless.net

Airsnort Herramienta de intrusión de red inalámbrica – airsnort.shmoo.com

Gpg Utilerías de cifrado y firmas – www.gnupg.org

Openssl Utilería de conexión segura remota – www.openssl.org

Lsof Utilería en línea de comandos que lista los archivos abiertos

Hunt Herramienta de auditoría de seguridad lin.fsid.cvut.cz/~kra/index.html

Stunnel Paquete de conexión con SSL – stunnel.mirt.net

Arpwatch Monitor ethernet en línea de comandos

Dig Herramienta en línea de comandos para hacer peticiones a servidores de nombres Chkrootkit Busca por rootkits – www.chrootkit.org

Estos se encuentran en el menú de inicio en las secciones de “Internet” y “System”

http://www.packetfactory.net/Projects/nemesis

http://monkey.org/%7Edugsong/fragroute/

http://www.fping.com/

http://michael.toren.net/code/tcptraceroute/

http://www.nesus.org/

http://www.atstake.com/research/tools/network_utilities/

http://www.hping.org/

http://www.openssh.com/

http://www.kismetwireless.net/

http://www.gnupg.org/

http://www.openssl.org/

http://lin.fsid.cvut.cz/%7Ekra/index.html

http://stunnel.mirt.net/

http://www.chrootkit.org/

71

Por default el usuario con el que se bootea es knoppix, se puede utilizar un shell y convertirse en

root para realizar ciertas tareas, pero en caso de necesitar root en todo el ambiente, se necesita

indicar en el prompt de boot : knoppix 2 y después startx.

SMART

Es un CD con distribución de Linux diseñado para Respuesta a Incidentes investigación

Forenses, creado por la empresa ASR Data [41].

3.2.2.5 Herramientas varias

La tabla 3.12 muestra más herramientas de utilidad para el proceso de recolección de datos que

son disponibles en Internet:

Tabla 3.12 Herramientas varias Linux

Utilería Función

md5deep Md5s recursivo, se puede obtener de la siguiente dirección:

md5deep.sourceforge.net

fatback Archivo de recuperación de sistemas de archivos FAT Sourceforge.net/projects/biatchux

stegdetect Detecta clases de esteganografía en imágenes www.outguess.org

galleta IE cookie parser www.foundstone.com/

pasco IE Activity Parser www.openforensics,org

libpst Convierte archivos de Outlook y Outlook Express a un formato mbox de Linux Sourceforge.net/projects/ol2mbox

flag (forensic and long analysis gui)

www.dsd.goc.au/software/flag

sleauthkit/autopsy Casos de estudio: www.sleuthkit.org/case/index.php chkrootkit Contiene una base de datos de los rootkits mas populares para saber si nuestro

equipo está infectado: #chkrootkit –r /devicename

http://www.outguess.org/

http://www.openforensics,org/

72

Utilería Función www.chkrootkit.org

carbonite www.foundstone.com

smart CD con distribución de linux diseñado para Forensia y Respuesta a incidentes www.asrdata2.com

ethereal

Analizador de protocolos de red. Corre en plataformas Unix, Linux y Windows. Ethereal es una herramienta utilizada para obtener información de la red, esta herramienta nos ayuda a procesar y desplegar paquetes completos capturados por tcpdump. http://www.ethereal.com/

dio (mission critical linux)

La utilería dio desarrollada por Mission Critical Linux como open source puede generar lecturas y/o escrituras a un dispositivo crudo (raw device), a un archivo o a memoria. Soporta archivos grandes y tamaños de bloque variable http://public.planetmirror.com/pub/mclx/oss/ . Es un comando similar a dd .

pdd.

Es una herramienta basada en windows, que realiza imágenes de memoria y adquisición de datos. Fue escrita por Joes Grand, esta disponible la versión 1.10 de marzo 2002.

pdzap

Es una pequeña aplicación que cuando es colocada en un teléfono celular P800 de SonyEricsson, permite obtener imágenes de los dispositivos flash a un stick de memoria.

maresware El software comercial para cómputo forense tiene un precio de $325 dólares. La empresa ofrece capacitación.

<http://www.maresware.com/>

kstat Detectar módulos de rootkit http://www.s0ftpj.org/en/site.html

tripwire Es una herramienta que verifica la integridad de los sistemas. Puede funcionar como detector de intrusos. http://sourceforge.net/projects/tripwire/

tcp-wrapper Servicio que verifica el origen de las conexiones con su base de datos /etc/hosts.allow y /etc/hosts.deny. Provee un control de acceso basado en la fuente y destino de la conexión y el registro de las conexiones exitosas o no. El programa de implementación de tcp-wrapper es tcpd ubicado en /usr/sbin http://www.iec.csic.es/criptonomicon/linux/tcpwrapper.html

3.3 ANÁLISIS COMPARATIVO DE LAS HERRAMIENTAS

Hay que hacer notar que las herramientas descritas no son las únicas, existen muchas más, pero

es cuestión de cada investigador el encontrar la herramienta con la que mejor se adapte.

Una vez conocidas las herramientas con las que podemos disponer, podemos hacer un análisis del

uso de las herramientas para investigación forense. Para nuestro análisis dividiremos las

herramientas en dos grupos:

• Herramientas comerciales y libres

http://www.chkrootkit.org/

http://www.foundstone.com/

http://www.asrdata2.com/

http://www.ethereal.com/

http://public.planetmirror.com/pub/mclx/oss/

http://www.maresware.com/

http://www.s0ftpj.org/en/site.html

http://sourceforge.net/projects/tripwire/

http://www.iec.csic.es/criptonomicon/linux/tcpwrapper.html

73

• Herramientas administrativas y forenses

Herramientas comerciales y libres

Las herramientas comerciales independientemente del sistema operativo que manejen se obtiene

al pagar los derechos por utilizar el software, las herramientas libres se obtienen sin pago alguno

a través de Internet, estas por lo regular corren en SO Linux.

Las herramientas administrativas y forenses

Las herramientas administrativas son las que el SO trae consigo y no se tienen que descargar de

ningún sitio, las herramientas forenses son herramientas especializadas que puede ser comerciales

o libres, en nuestro caso solo utilizamos las herramientas libres.

Comparación de herramientas comerciales con respecto a las herramientas libres

Lo bueno de utilizar Linux para Forensia es que la mayoría de las herramientas son libres, el

ambiente es flexible y cuando las herramientas son usadas apropiadamente, la evidencia puede

ser relevante para levantar cargos al culpable.

La limitación es que como la mayoría de las herramientas son libres, no se tiene soporte técnico y

no se puede llamar al autor a una corte si es necesario, lo cual permite a la defensa recorrer el

código en busca de errores “bugs” y poder descartar la información obtenida por la herramienta

en cuestión. Otra limitación es que no tienen todas las características como los paquetes

comerciales y son más complicadas de usar que las herramientas comerciales.

Por otra parte, las herramientas comerciales tienen todo el respaldo de la empresa o autor que lo

patrocina, pero debemos pagar el precio que marca y las posibles actualizaciones para contar con

la garantía de dicho producto.

Comparación de herramientas forenses con respecto a las herramientas administrativas

Las herramientas administrativas son de gran utilidad para el administrador del sistema nos dan

información fácil y rápidamente, pero no están diseñadas para la recolección y análisis forense

74

En el caso de utilizar las herramientas forenses con respecto a las herramientas administrativas, la

razón por lo que es preferible usar las herramientas forenses es que la mayoría de los sistemas no

pueden ser simplemente desmantelados, los datos crudos (raw data) son demasiado voluminosos

y no es fácil manejarlos. Las herramientas forenses como TCT contienen programas de captura y

de análisis que permiten al investigador entender como operan los sistemas y como defenderse en

incidentes de seguridad futuros.

Para trabajar con las herramientas forenses se necesita mucha práctica para entender cómo

funciona el software y saber interpretar bien los resultados. La recopilación y análisis de

información los crea en paquete sin tener una amplia flexibilidad de lo que queremos y no

queremos respaldar. Las herramientas TSK y Autopsy hacen el análisis sobre imágenes de disco

del sistema bajo análisis y no propiamente sobre la información volátil que es donde nos estamos

enfocando en este trabajo.

Las herramientas de volcado de memoria

Las herramientas de volcado de memoria son software desarrollado para obtener información

después de una falla de sistema que cause su caída, debe ser instalado y configurado previamente

en el sistema, por lo que para este tipo de software se necesita que el usuario esté familiarizado

con el equipo ya que se configura y reconstruye el kernel.

Beneficios de contar un CD LIVE

Utilizar los CD LIVE o CD con sistema operativo y herramientas de seguridad integrados son de

gran utilidad ya que contienen lo necesario para una respuesta rápida, pueden contener un sistema

de menús que hace más fácil su uso, ofrecen una gran cantidad de aplicaciones y detección de

hardware, con las herramientas relevantes para expertos en seguridad, pero es conveniente que el

investigador forense cree su propio conjunto de herramientas que va ir complementando en cada

caso que resuelva.

75

CAPITULO 4

METODOLOGÍA PARA LA RECOLECCIÓN DE INFORMACIÓN

Y CASOS

76

4. METODOLOGÍA PARA LA RECOLECCIÓN DE INFORMACIÓN Y CASOS. En este capítulo se presentará una metodología general de recolección de información volátil y

memoria en un sistema vivo en base a la volatilidad de los datos, esta metodología se aplicará a

cinco casos que se dividirán en el tipo de acceso al sistema sospechoso, es decir si está conectado

en red o se trabajará en forma local y sobre las plataformas más comunes Windows y Linux.

Dentro de cada caso se explicará a detalle la obtención de datos utilizando diversas herramientas

y comandos del sistema operativo y forense, con el fin de capturar datos volátiles y de la

memoria RAM antes de quitar la energía del equipo bajo análisis.

En la figura 4.1 se muestra cada uno de los casos con el estado del sistema “vivo”, así como el

estado del sistema cuando no tiene energía de alimentación o “muerto”, pero esta última parte se

verá con detalle en el siguiente capítulo.

Estado del

sistema

MUERTO VIVO

CASO 2: Windows

CASO 1: Windows

Local Por red Tipo de acceso al sistema

CASO 3: Linux

CASO 4: Linux

CASO 5: Grave_robber Linux

Recuperación de datos con métodos físicos

(ejemplos)

Fig. 4.1 Casos a considerar para la presente investigación

77

4.1 ESTABLECIENDO UN PROCEDIMIENTO “GENERAL” PARA

APLICAR EN CADA CASO.

Dentro de los pasos forenses debemos obtener, guardar y seguir la pista de información acerca de

una posible actividad criminal, esto significa que se debe tener mucha precaución para recolectar

en forma exacta y confiable los datos para hacerlos seguros.

En general la mejor práctica para recolectar evidencia es usar herramientas confiables, salvar

datos en medios removibles y asegurar la autenticidad de los datos. Considerando que nada

acerca del sistema puede ser confiable, debemos tratar cada equipo como si estuviera

comprometido, tuviera “rootkits” instalados o pudiera estar monitoreado por atacantes.

De acuerdo a Kevin Mandia y Chris Prosise en su libro “Incident Response” [36], para la

recolección de datos volátiles es más importante la respuesta inicial que el análisis técnico

posterior. Al dar de baja el sistema bajo investigación se puede llegar a destruir evidencia crítica,

esto debido a que los atacantes han aprendido a tomar ventajas de los medios de almacenamiento

volátil.

Una de las reglas básicas del cómputo forense es que no debemos trabajar con los datos

originales, pero para capturar la información volátil quizá sea la única forma de poder obtenerla.

Por lo que si vamos a trabajar con un sistema vivo debemos recordar que para cada decisión y

paso a tomar, el investigador deberá tener razones sólidas de cada acción realizada y ser

debidamente documentada.

Si sabemos que el examinar datos volátiles los altera, consideraremos que el sistema se

modificará por lo que deberemos saber específicamente qué y porqué se modificó, para lo cual

deberemos conocer muy bien las herramientas que utilizaremos y saber que archivos se

modifican al utilizarlas, también deberemos tomar un registro de tiempo de todos los archivos del

sistema antes y después de proceder a la captura. Con esto sabremos qué estaremos modificando

en el momento de la recolección.

78

Independientemente del sistema operativo con el que cuente el equipo bajo análisis y de acuerdo

a lo explicado en el capítulo 2, los siguientes datos son perdidos una vez que el sistema es dado

de baja:

• Los registros del procesador y el contenido del cache.

• El contenido de la memoria.

• El estado de las conexiones de red.

• El estado de los procesos que están corriendo en ese momento.

El contenido en los registros del procesador y su cache es casi imposible obtenerlos debido a que

el simple intento de capturarlos los alteraría, por lo que no intentaremos capturar esta

información.

En la memoria también existen áreas principales que pueden ser alteradas, algunas páginas en el

área de memoria serán modificadas al correr los comandos de nuestro conjunto de herramientas y

cuando hagamos una clonación o descarga de ésta.

Obtener el estado de las conexiones de red y procesos corriendo tiene un impacto menor en el

sistema. La información es generalmente almacenada en tablas residentes en la memoria del

kernel y la simple lectura de los datos no los modificará.

Todo esto nos lleva a la conclusión de que antes de revisar un sistema “vivo” debemos contar

con una metodología de captura.

A continuación se propone una metodología “general” que contiene los pasos para obtener los

datos volátiles más críticos:

(1) Establecer una línea de comandos segura (shell)

En este paso se realizará una conexión donde los comandos y programas que aplicaremos sean

confiables.

79

(2) Realizar un registro de tiempo del sistema (time stamp)

En este paso iniciamos la obtención de datos utilizando herramientas que nos permitan obtener el

tiempo y fecha del sistema y obtener un registro de tiempo de todos los archivos y directorios

(timestamp).

(3) Obtener los datos y el estado del sistema

En este paso empezaremos a recolectar la información, realizando las siguientes acciones que a

continuación se describen:

a.- Obtener los datos del sistema (nombre, dirección IP, etc.)

b.- Determinar los puertos abiertos

c.- Listar los procesos corriendo (sockets, servicios, etc.)

d.- Respuesta inicial profunda (bitácoras), en el caso de contar con el tiempo necesario.

(4) Determinar quien está dentro del sistema y quienes se han conectado recientemente

En este paso tratamos de determinar las conexiones actuales y recientes al sistema bajo análisis

además de la información de red contenida en el sistema.

(5) Realizar un segundo registro de tiempo

En este paso realizaremos nuevamente un registro de tiempo en los archivos y directorios para

que podamos compararlo con el primer registro y sepamos los cambios que hicimos durante

nuestra recolección de información.

(6) Hacer una copia de la memoria RAM

Finalmente haremos una imagen del sistema de memoria RAM, para después analizarlo con

mayor tiempo y no durante la respuesta inicial.

80

(7) Documentar y transferir a un medio seguro

Una vez obtenida la información deberemos trasferirla y almacenarla en un lugar seguro.

Podremos realizar estos pasos rápidamente si los concentramos en un script. Finalmente todos

estos pasos los tenemos que documentar

Los pasos establecidos en la metodología pueden cambiar de orden, dependiendo de las

circunstancias de la investigación, del sistema operativo, versiones, y también del objetivo de la

investigación ya que puede ser buscar al culpable más que recuperar la información.

Equipo de herramientas

Ya con la metodología establecida, el primer paso es contar con un buen conjunto de

herramientas, que ya hemos conformado con los comandos y software explicados en el capítulo

anterior, que en general deberá incluir:

• Un programa para examinar procesos.

• Programas para examinar el estado del sistema

• Un programa para realizar copias bit a bit

• Programas para generar checksum y firmas

• Programas para generar imágenes core

• Scripts para automatizar la recolección de evidencia.

Contar con el password de acceso

Otra situación a la que se enfrenta el investigador forense es contar con un password de acceso al

sistema, debido a que para recuperar el password de acceso a un sistema muchas veces es

necesario reiniciarlo, o que para tratar de adivinarlo, el proceso lleva tiempo, hemos tomado la

decisión de que en caso de no contar con el password de acceso procederemos a apagar el equipo

sin recolectar la información volátil, debido a que al tratar de obtener el password de acceso

perderemos casi toda la información volátil que estamos buscando, por lo que en los casos

propuestos se considera que se tiene un password de acceso al sistema.

81

4.2 APLICANDO EL PROCEDIMIENTO DE RECOLECCIÓN: CASO 1

WINDOWS CON ACCESO LOCAL

Después de haber establecido la metodología general donde el objetivo es recolectar información

volátil aplicaremos esos pasos al primer caso.

Las condiciones bajo las cuales se encuentra el equipo bajo sospecha son; el estado del sistema

será “vivo”, es decir el equipo sospechoso estará conectado a la energía y corriendo sus procesos

en forma “normal”, el sistema operativo al que se enfrentará el investigador será Windows 2000

y se contará con el password de acceso.

Estado del

sistema

MUERTO VIVO

CASO 2: Windows

CASO 1: Windows


CASO 3: Linux

CASO 4: Linux



(ejemplos)

Fig. 4.2 Caso 1: Aplicación de metodología con Windows en forma local

Tal como consta la figura 4.2 el procedimiento se aplicará a un sistema vivo donde el

investigador forense se conectará directamente en la consola del equipo sospechoso estableciendo

una conexión segura en forma local, una vez establecida esta comunicación el investigador

aplicará los comandos de su conjunto de herramientas a través de esta conexión.

Los programas que utilizará en esta captura no serán instalados en el sistema bajo análisis,

correrán desde una fuente de archivos “confiables” que puede ser un floppy o un drive USB, estas

herramientas correrán sobre el sistema operativo en cuestión y finalmente los resultados

obtenidos se almacenará en un medio confiable (floppy o drive USB).

82

PASO 1: ESTABLECER UNA LÍNEA DE COMANDOS SEGURA (shell)

En este primer paso vamos a hacer disponible el conjunto de herramientas montando el medio en

el sistema, después procedemos a establecer una línea de comandos segura ejecutando la

herramienta “cmd.exe” confiable. Se debe tener cuidado de que el atacante haya puesto algunas

trampas para hacer fracasar la captura de datos, por ejemplo se puede presentar la situación en

que al ejecutar el comando cmd.exe en la máquina victima se active un proceso aplicando el

comando del *.* en el directorio \winnt\System32, haciendo el sistema virtualmente inoperable.

Por lo que ejecutaremos el comando “cmd.exe” de manera confiable, direccionándolo al drive

donde se almacenan nuestras herramientas, en este caso será la letra “a:”, como se muestra en la

siguiente ventana:

Fig. 4.3 cmd.exe PASO 2: REALIZAR UN REGISTRO DE TIEMPO DEL SISTEMA (TIMESTAMP)

Después de crear un “shell” seguro, se captura la hora (time) y fecha (date) del sistema con las

herramientas almacenadas en nuestro medio seguro (drive a:), la opción –t de los comandos

obliga a que el comando no quede en espera. a:\toolkit>date /t The current date is: Thu 08/18/2005 a:\toolkit>time /T The current time is: 16:58:09.14 También podemos utilizar el comando “now” del resource kit, que despliega “date” y “time” en

un solo comando:

A:\toolkit\now

Fri Apr 07 17:53:09 2006

Después de obtener el tiempo y fecha del sistema hacemos un registro de tiempo de todos los

archivos del sistema, utilizando el comando “dir” para obtener un listado de todos los archivos en

el sistema bajo análisis, tiempos de acceso, modificación y creación.

83

Utilizando el comando “dir”, se puede hacer un despliegue por propietario (/Q) y tiempo de

último acceso al archivo (/TA) de todos los archivos del sistema (/S), esto con el fin de marcar un

sello de tiempo (time stamp): a:\toolkit>dir c:\ /Q /S /TA Volume in drive C has no label. Volume Serial Number is ECD3-2160 Directory of c:\ 08/16/2005 05:43p 36,112 BUILTIN\Administrators Auditpol.exe 08/16/2005 05:43p 24,848 BUILTIN\Administrators dh.exe 08/16/2005 05:43p 9,488 BUILTIN\Administrators dhcmp.exe 08/18/2005 05:51p <DIR> BUILTIN\Administrators Documents and Settings 08/16/2005 05:43p 6,928 BUILTIN\Administrators drivers.exe 08/17/2005 12:34p 114,688 BUILTIN\Administrators Fport.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Inetpub 08/16/2005 05:43p 53,248 BUILTIN\Administrators listdlls.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators nmap 08/16/2005 05:43p 208,948 BUILTIN\Administrators NTLast.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Program Files 08/18/2005 04:29p <DIR> BUILTIN\Administrators programas 08/17/2005 05:26p 25,252,224 LUNA\alicia_user resp.reg 08/18/2005 04:29p <DIR> BUILTIN\Administrators temp 08/18/2005 04:29p <DIR> BUILTIN\Administrators toolkit 08/18/2005 04:29p <DIR> BUILTIN\Administrators WINNT 8 File(s) 25,706,484 bytes Directory of c:\Documents and Settings 08/18/2005 05:51p <DIR> BUILTIN\Administrators . 08/18/2005 05:51p <DIR> BUILTIN\Administrators .. 08/18/2005 05:51p <DIR> BUILTIN\Administrators Administrator 08/17/2005 04:42p <DIR> BUILTIN\Administrators alicia_user 08/18/2005 01:58p <DIR> BUILTIN\Administrators All Users 0 File(s) 0 bytes Directory of c:\Documents and Settings\Administrator . . .

El siguiente comando provee un listado recursivo de los tiempos de acceso al drive C a:

\toolkit>dir /t:a /a /s /o:d c

El siguiente comando provee un listado recursivo de los tiempos de modificación del drive D a:\toolkit>dir /t:w /a /s /o:d d El siguiente comando provee un listado recursivo de los tiempos de creación del drive E a:\toolkit>dir /t:c /a /s /o:d e Para obtener los listados recursivos de los tiempos de acceso, modificación y creación también podemos utilizar el comando “ls.exe” incluido en el CD-live de FIRE. a:\toolkit>ls –alRu para tiempos de acceso a:\toolkit>ls –alRc para tiempos de modificación a:\toolkit>ls –alR para tiempos de creación

84

PASO 3: DETERMINAR LOS DATOS Y EL ESTADO DEL SISTEMA

Para determinar el estado del sistema realizaremos las siguientes acciones:

1. Obtener los datos del sistema

2. Determinar los puertos abiertos

3. Listar todos los procesos corriendo

4. Respuesta inicial mas profunda

o Obtener la bitácora de eventos durante una respuesta viva

o Revisar el “registry” durante la respuesta viva

Acción 1: Obtener los datos del sistema

Para obtener los datos del sistema verificamos el nombre del equipo con el comando “hostname”:

a:\toolkit>hostname comprometido

A continuación obtenemos la identificación de red del equipo con el comando “ipconfig” como

se muestra a continuación: a:\toolkit>ipconfig /all Windows 2000 IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 172.29.69.83 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.29.69.254

Acción 2: Determinar los puertos abiertos

Para enumerar los puertos por los cuales los procesos están escuchando, utilizamos la

herramienta “fport”, esta herramienta nos muestra los puertos que están actualmente escuchando,

pero no nos dice que puertos están sirviendo a usuarios remotos en el momento. Para esto

utilizamos el comando de Windows “netstat” que enumera los puertos escuchando y además las

conexiones a esos puertos:

a:\toolkit>fport FPort v2.0 - TCP/IP Process to Port Mapper

85

Copyright 2000 by Foundstone, Inc. http://www.foundstone.com Pid Process Port Proto Path 1052 inetinfo -> 25 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 1052 inetinfo -> 80 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 436 svchost -> 135 TCP C:\WINNT\system32\svchost.exe 8 System -> 139 TCP 1052 inetinfo -> 443 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 8 System -> 445 TCP 492 msdtc -> 1025 TCP C:\WINNT\System32\msdtc.exe 880 MSTask -> 1026 TCP C:\WINNT\system32\MSTask.exe 1052 inetinfo -> 1028 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 8 System -> 1030 TCP 1000 svchost -> 1050 TCP C:\WINNT\system32\svchost.exe 8 System -> 1099 TCP 8 System -> 1723 TCP 1052 inetinfo -> 2087 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 492 msdtc -> 3372 TCP C:\WINNT\System32\msdtc.exe 436 svchost -> 135 UDP C:\WINNT\system32\svchost.exe 8 System -> 137 UDP 8 System -> 138 UDP 8 System -> 445 UDP 228 lsass -> 500 UDP C:\WINNT\system32\lsass.exe 1052 inetinfo -> 1029 UDP C:\WINNT\System32\inetsrv\inetinfo.exe 600 svchost -> 1031 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1032 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1033 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1645 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1646 UDP C:\WINNT\System32\svchost.exe 8 System -> 1701 UDP 600 svchost -> 1812 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1813 UDP C:\WINNT\System32\svchost.exe 1052 inetinfo -> 3456 UDP C:\WINNT\System32\inetsrv\inetinfo.exe A continuación se muestra la aplicación de la herramienta ”netstat” que es útil para grabar datos

volátiles como conexiones actuales y las que han terminado. a:\toolkit>netstat -an Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:25 0.0.0.0:0 LISTENING TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:443 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING TCP 0.0.0.0:1050 0.0.0.0:0 LISTENING TCP 0.0.0.0:1723 0.0.0.0:0 LISTENING TCP 0.0.0.0:2087 0.0.0.0:0 LISTENING TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING TCP 172.29.69.83:139 0.0.0.0:0 LISTENING TCP 172.29.69.83:139 172.29.69.69:3415 ESTABLISHED UDP 0.0.0.0:135 *:* UDP 0.0.0.0:445 *:* UDP 0.0.0.0:1029 *:* UDP 0.0.0.0:1033 *:* UDP 0.0.0.0:1645 *:* UDP 0.0.0.0:1646 *:* UDP 0.0.0.0:1701 *:* UDP 0.0.0.0:1812 *:* UDP 0.0.0.0:1813 *:* UDP 0.0.0.0:3456 *:* UDP 127.0.0.1:1031 *:* UDP 127.0.0.1:1032 *:* UDP 172.29.69.83:137 *:*

86

UDP 172.29.69.83:138 *:* UDP 172.29.69.83:500 *:* En este caso son de particular interés las conexiones externas (172.29.69.69) más que las locales

(127.0.0.1 o 172.29.69.83). Con “fport” se obtienen los procesos sospechosos esperando una

conexión y con “netstat” se obtiene las conexiones actuales a ese proceso. El comando “tcpvcon”

es similar a la utilería “netstat” de Windows, por lo que se puede utilizar en vez de netstat. a:\toolkit>tcpvcon -a

La opción –a muestra todas las conexiones TCP y UDP establecidas

Acción 3: Listando todos los procesos corriendo

Antes de apagar el equipo bajo análisis es importante grabar todos los procesos que están

corriendo. Esta información no puede ser obtenida si se desconecta el cordón de energía. Cuando

un proceso se está ejecutando en Windows se crea un objeto kernel y un espacio de direcciones

conteniendo el código ejecutable. El objeto kernel creado es usado por el sistema operativo para

manejar el proceso y contener información estadística acerca del proceso.

Para obtener la lista de procesos que está corriendo en el sistema podemos utilizar la herramienta

“pslist”, como se muestra a continuación: a:\toolkit>pslist PsList 1.26 - Process Information Lister Copyright (C) 1999-2004 Mark Russinovich Sysinternals - www.sysinternals.com Process information for LUNA: Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time Idle 0 0 1 0 0 7:56:24.963 7:59:01.778 System 8 8 44 208 24 0:00:10.304 7:59:01.778 SMSS 144 11 6 33 1096 0:00:00.560 7:59:01.778 CSRSS 168 13 10 469 1580 0:00:05.778 7:58:50.672 WINLOGON 188 13 18 434 6888 0:00:03.024 7:58:49.330 SERVICES 216 9 37 550 3192 0:00:04.045 7:58:47.267 LSASS 228 9 21 297 2916 0:00:07.160 7:58:47.237 svchost 436 8 8 243 1572 0:00:00.560 7:58:42.100 spoolsv 464 8 11 134 2716 0:00:00.380 7:58:41.088 msdtc 492 8 21 198 1968 0:00:00.360 7:58:40.978 svchost 600 8 29 1085 9612 0:00:04.606 7:58:38.715 LLSSRV 628 9 10 79 796 0:00:00.070 7:58:37.744 FrameworkServic 660 8 10 194 2952 0:00:01.131 7:58:37.423 Mcshield 732 13 20 204 18308 0:00:55.369 7:58:35.801 VsTskMgr 748 8 11 132 5112 0:00:00.230 7:58:35.480 naPrdMgr 792 8 4 108 4560 0:00:00.140 7:58:34.068 regsvc 848 8 2 30 288 0:00:00.050 7:58:27.779 mstask 880 8 6 114 1136 0:00:00.250 7:58:25.656 userdump 924 8 4 47 332 0:00:00.030 7:58:19.608 WinMgmt 952 8 4 115 1276 0:00:10.324 7:58:17.865 svchost 1000 8 6 208 5924 0:00:03.745 7:58:12.187 dfssvc 1032 8 2 36 484 0:00:00.060 7:58:10.755

87

inetinfo 1052 8 27 590 6512 0:00:01.251 7:58:08.782 svchost 1360 8 11 168 1580 0:00:00.250 7:57:13.753 explorer 708 8 15 351 8108 0:00:35.931 5:25:09.453 shstat 1600 8 6 63 4604 0:00:00.240 5:24:45.608 UpdaterUI 1540 8 4 96 1008 0:00:00.240 5:24:41.132 internat 1468 8 1 27 372 0:00:00.080 5:24:40.611 wuauclt 1040 8 5 101 1572 0:00:00.200 5:23:43.930 CMD 1644 8 1 21 340 0:00:00.110 3:15:59.980 cmd 1008 8 1 23 360 0:00:00.430 1:32:41.026 cmd 980 8 1 21 1432 0:00:00.030 1:21:04.975 CMD 776 8 1 21 312 0:00:00.180 0:51:57.903 pslist 712 13 2 88 736 0:00:00.120 0:00:01.692 nc 512 8 2 74 1064 0:00:00.170 0:00:01.532 Es importante poder identificar la diferencia entre los procesos críticos, normales y procesos no

permitidos. Por ejemplo si “pslist” revela que el proceso EVENTVWR está corriendo, esto

sugiere que alguien está observando las bitácoras. Si se observa el USRMGR, se puede sospechar

que alguien trata de cambiar las políticas de auditoría, borrar o agregar una cuenta de usuario o

cambiar los datos de una cuenta de usuario o password.

Acción 4: Respuesta inicial más profunda

Si es que se cuenta con mayor tiempo se pueden ejecutar los siguientes comandos con el fin de

obtener un poco más de información sobre el sistema vivo, en caso de no contar con mayor

tiempo continuaremos con el siguiente paso de la metodología planteada.

Para obtener una bitácora de los accesos que ha habido al sistema podemos utilizar la herramienta

“Ntlast” que nos permite monitorear las entradas (“logons”) exitosas y fallidas al sistema y si la

auditoría de entradas/salidas (“logon/logoff”) fue activada o desactivada en el sistema. “Ntlast”

con la opción –r lista todas las entradas exitosas de un sistema remoto y la opción –f lista los

intentos fallidos. a:\toolkit>ntlast Administrator LUNA LUNA Thu Aug 18 12:37:52pm 2005 Administrator LUNA LUNA Wed Aug 17 06:26:26pm 2005 alicia_user LUNA LUNA Wed Aug 17 02:09:24pm 2005 Administrator LUNA LUNA Wed Aug 17 12:14:31pm 2005 - End Of File - Nota: Este comando da información solo si las políticas de auditoría están habilitadas en el

equipo bajo análisis.

88

Obteniendo la bitácora de eventos durante una respuesta viva

Según Kevin Mandia [36] existen dos fuentes importantes de información en Win2000 y NT: la

bitácora de eventos y el Registry.

El comando “dumpel” se puede utilizar para obtener las bitácoras y copiarlas a un archivo de

texto, a continuación se muestra la captura de los eventos de seguridad, aplicación y sistema: dumpel –l security –t descarga las bitácoras de seguridad dumpel –l application –t descarga las bitácoras de aplicación. dumpel –l system –t descarga las bitácoras de sistema. Ejemplo de aplicación del comando: a:\toolkit>dumpel –l security –t 8/17/2005 12:14:24 PM 16 2 529 Security NT AUTHORITY\SYSTEM LUNA atorres LUNA 2 User32 Negotiate LUNA 8/17/2005 12:14:31 PM 8 9 680 Security NT AUTHORITY\SYSTEM LUNA MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 administrator LUNA 8/17/2005 12:14:31 PM 8 2 528 Security LUNA\Administrator LUNA Administrator LUNA (0x0,0x27C7C) 2 User32 Negotiate LUNA 8/17/2005 12:16:18 PM 16 9 681 Security NT AUTHORITY\SYSTEM LUNA MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 atorres ATORRES 3221225572 8/17/2005 12:34:08 PM 8 2 538 Security NT AUTHORITY\ANONYMOUS LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0x377B2) 3 8/17/2005 12:44:35 PM 8 2 538 Security NT AUTHORITY\ANONYMOUS LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0x37D3A) 3 8/17/2005 1:05:44 PM 8 2 538 Security NT AUTHORITY\ANONYMOUS LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0x38345) 3 8/17/2005 1:53:22 PM 8 2 538 Security NT AUTHORITY\ANONYMOUS LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0xDBA2) 3 8/18/2005 10:10:27 AM 8 2 538 Security NT AUTHORITY\ANONYMOUS LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0xDD2B) 3 . . . . . . . . . . . . . . Capturando el registry durante la respuesta viva

El Registry NT/2000 almacena datos útiles durante la respuesta inicial. Para obtener estos datos

podemos utilizar las herramientas “regedit” o “reg”. Regedit genera un archivo grande y reg

obtiene solo valores específicos que sean de nuestro interés (keys). a:\toolkit\regedit –e respaldo_registry.reg a:\toolkit\reg export HKLM respaldo_registry.reg The operation completed succesfully : Para obtener información de los usuarios podemos aplicar la siguiente sintaxis: reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\REgisteresOwner” reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon” Para obtener información del sistema podemos aplicar la siguiente sintaxis:

89

reg query “HKLM\SYSTEM\ControlSet001\Control\ComputerName\Computername” reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion”

El siguiente es un ejemplo de aplicación del comando “reg”, con la llave para obtener

información de usuarios: a:>toolkit>reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon” ! REG.EXE VERSION 3.0 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon AutoRestartShell REG_DWORD 0x1 DefaultDomainName REG_SZ LUNA DefaultUserName REG_SZ administrator LegalNoticeCaption REG_SZ LegalNoticeText REG_SZ PowerdownAfterShutdown REG_SZ 0 ReportBootOk REG_SZ 1 Shell REG_SZ Explorer.exe ShutdownWithoutLogon REG_SZ 0 System REG_SZ Userinit REG_SZ C:\WINNT\system32\userinit.exe, VmApplet REG_SZ rundll32 shell32,Control_RunDLL "sysdm.cpl" SfcQuota REG_DWORD 0xffffffff allocatecdroms REG_SZ 0 allocatedasd REG_SZ 0 allocatefloppies REG_SZ 0 cachedlogonscount REG_SZ 10 passwordexpirywarning REG_DWORD 0xe scremoveoption REG_SZ 0 DontDisplayLastUserName REG_SZ 0 AppSetup REG_SZ DebugServerCommand REG_SZ no SFCDisable REG_DWORD 0x0 ShowLogonOptions REG_DWORD 0x1 AltDefaultUserName REG_SZ administrator AltDefaultDomainName REG_SZ LUNA HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon\GPExtensions HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon\Notify PASO 4: DETERMINANDO QUIEN ESTÁ EN EL SISTEMA

El siguiente paso es determinar que cuentas de usuarios tiene conexiones activas al sistema. Para

esto nos ayudaremos con la utilería de PStools “psloggedon”: a:\toolkit>psloggedon PsLoggedOn v1.31 - Logon Session Displayer Copyright (C) 1999-2003 Mark Russinovich Sysinternals - www.sysinternals.com Users logged on locally: 8/18/2005 12:38:01 PM LUNA\Administrator Users logged on via resource shares: 8/18/2005 5:02:49 PM (null)\ALICIA_USER Para determinar quien está conectado al sistema utilizamos “net session”, “arp” y “nbtstat”.

La herramienta “nbtstat” es usada para acceder al cache NetBIOS, permitiéndonos listar las

conexiones recientes, con la opción –c se muestra la información en cache de Netbios

90

a:\toolkit>nbtstat –c Local Area Connection: Node IpAddress: [172.29.69.83] Scope Id: [] No names in cache La herramienta “nbtstat” con la opción –n muestra los nombres de Netbios locales a:\toolkit>nbtstat –n Local Area Connection: Node IpAddress: [172.29.69.83] Scope Id: [] NetBIOS Local Name Table Name Type Status --------------------------------------------- COMPROMETIDO <00> UNIQUE Registered FORE <00> GROUP Registered COMPROMETIDO <20> UNIQUE Registered COMPROMETIDO <03> UNIQUE Registered FORE <1E> GROUP Registered FORE <1D> UNIQUE Registered ..__MSBROWSE__.<01> GROUP Registered INet~Services <1C> GROUP Registered IS~COMPROMETIDO....<00> UNIQUE Registered

La herramienta “nbtstat” con la opción –r lista los nombres resueltos por broadcast vía WINS a:\toolkit>nbtstat –r NetBIOS Names Resolution and Registration Statistics ---------------------------------------------------- Resolved By Broadcast = 0 Resolved By Name Server = 2 Registered By Broadcast = 0 Registered By Name Server = 9

La herramienta “nbtstat” con la opción –s lista la tabla de sesiones a:\toolkit>nbtstat –s Local Area Connection: Node IpAddress: [172.29.69.83] Scope Id: [] NetBIOS Connection Table Local Name State In/Out Remote Host Input Output ---------------------------------------------------------------------------- COMPROMETIDO <03> Listening El comando “net” con la opción “session”, obtiene una lista de sesiones establecidas en el

sistema, como se muestra a continuación. a:\toolkit>net session Computer User name Client Type Open Idle time --------------------------------------------------------------------------------- \\172.29.69.69 ATORRES Windows 2002 Serv 1 02:21:03

El comando “arp” es utilizado para mapear direcciones IP a direcciones físicas MAC con las

cuales el sistema se ha comunicado. Con la opción “–a” se muestra y modifica la tabla de

conversión de direcciones IP a direcciones físicas.

91

a:\toolkit>arp –a Interface: 172.29.69.83 on Interface 0x1000003 Internet Address Physical Address Type 172.29.69.254 00-20-9c-12-db-b4 dynamic

PASO 5: REALIZAR EL SEGUNDO REGISTRO DE TIEMPO DEL SISTEMA (TIME

STAMP)

Este paso tiene el fin de obtener un segundo registro para que al compararlo con el primero

podamos identificar bien los cambios que hemos hecho en el sistema a la hora de la recolección

de información, para lo cual nos podemos ayudar nuevamente de la herramienta “dir” o “ls”

como en el paso 1: a:\toolkit>dir c:\ /Q /S /TA Volume in drive C has no label. Volume Serial Number is ECD3-2160 Directory of c:\ 08/16/2005 05:43p 36,112 BUILTIN\Administrators Auditpol.exe 08/16/2005 05:43p 24,848 BUILTIN\Administrators dh.exe 08/16/2005 05:43p 9,488 BUILTIN\Administrators dhcmp.exe 08/18/2005 05:51p <DIR> BUILTIN\Administrators Documents and Settings 08/16/2005 05:43p 6,928 BUILTIN\Administrators drivers.exe 08/17/2005 12:34p 114,688 BUILTIN\Administrators Fport.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Inetpub 08/16/2005 05:43p 53,248 BUILTIN\Administrators listdlls.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators nmap 08/16/2005 05:43p 208,948 BUILTIN\Administrators NTLast.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Program Files 08/18/2005 04:29p <DIR> BUILTIN\Administrators programas 08/17/2005 05:26p 25,252,224 LUNA\alicia_user resp.reg 08/18/2005 04:29p <DIR> BUILTIN\Administrators temp 08/18/2005 04:29p <DIR> BUILTIN\Administrators toolkit 08/18/2005 04:29p <DIR> BUILTIN\Administrators WINNT 8 File(s) 25,706,484 bytes . . . . . . . . . PASO 6: REALIZAR UNA COPIA DE LA MEMORIA

Este paso se deberá realizar una vez concluidos los anteriores porque se producirá un volcado de

memoria que modificará el registry y reiniciará el sistema.

Por lo que para forzar al sistema para que cree un archivo “.dmp” cambiamos la configuración

del “registry” con el siguiente comando que utiliza la herramienta “reg.exe”: a:\>reg ADD HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters /v CrashOnCtrlScroll /t REG_DWORD /d 0x1

92

Después de haber realizado esta configuración en el “registry” y para poder crear el archivo

dump, será necesario provocar el fallo en la computadora oprimiendo la tecla derecha CTRL y al

mismo tiempo oprimir dos veces la tecla Bloq/despl (ScrollLock). Se pondrá la pantalla azul y se

reiniciará el sistema.

Después de que reinicie la computadora se habrá creado el archivo de descarga o volcado de la

memoria en el directorio del sistema. Por ejemplo c:\WINNT>MEMORY.DMP

PASO 7: DOCUMENTANDO LOS COMANDOS USADOS DURANTE LA RESPUESTA

INICIAL, TRANSFERIR Y ALMACENAR LOS DATOS

Todos los pasos con sus respectivas acciones y herramientas aplicadas son resumidos en la tabla

4.1.

Tabla 4.1 Pasos y acciones realizadas: Caso 1

Pasos Acciones Windows

NT/2000 1 Línea de comandos seguros Hacer disponible el conjunto de herramientas

Establecer un nuevo shell cmd.exe

2 Registro de tiempo Obtener el tiempo y fecha del sistema Time stamp, tiempo de creación de los archivos

date, time, now dir, ls

3 Estado del sistema Nombre del equipo Información Obtener los puertos abiertos Listar los procesos que corren actualmente Listar los procesos que abren sockets Lista las conexiones exitosas y fallidas Obtiene las bitácoras y hace la transferencia Obtiene valores de interés del registry Descarga todo el registry a un archivo

hostname ipconfig fport pslist netstat ntlast dumpel reg regedit

4 Quien esta en el sistema Conexiones activas Conexiones recientes Sesiones establecidas Tabla de direcciones

psloggedon nbtstat net session arp

5 2o. Registro de tiempo Listar archivos y directorios dir, ls 6 Copia de la memoria Volcado de memoria reg y archivos

.dmp 7 Documentación Transferir y almacenar los datos en un lugar

seguro Identificar y documentar los pasos

script md5

93

Todos estos comandos pueden ser incorporados en un programa batch como script y hacer la

captura con mayor velocidad. Para realizarlo creamos un archivo de texto con los comandos

requeridos y le ponemos la extensión bat.

En este caso elaboramos 5 scripts, en el primero se concentran los comandos aplicados y para la

respuesta inicial profunda donde se almacenan las bitácoras y el resultado del “registry”,

elaboramos los 4 script restantes.

La figura 4.4 muestra los scripts elaborados.

Fig. 4.4 Scripts Después de ejecutarlos aplicamos el comando “md5sum” al archivo generado por el script para

asignarle una identificación de integridad de los datos.

94

Se ejecuta el script “comandos” y se genera el archivo “datos.txt”, al cual se le aplica el comando

“md5sum” generando el archivo “datos.sum” que contiene el identificador de integridad. a:>toolkit>commandos >> datos.txt a:>toolkit>md5sum datos.txt >> datos.sum a:>toolkit>type datos.sum 7122f802e1a087a0b31848f70862c0d1 *datos.txt Este ejemplo ejecuta el script “copy_reg” que hace una copia del registry, al cual se le realiza el

mismo procedimiento anterior. a:>toolkit>copy_reg >> copy_reg.txt a:>toolkit>md5sum copy_reg.txt >> copy_reg.sum a:>toolkit>type copy_reg.sum 116798d3a85f14acdd5870ee16c4608d *copy_reg.txt Por último se ejecuta el script “sys_log” que obtiene la bitácora de sistema y al cual se le realiza

el mismo procedimiento anterior. a:>toolkit>sys_log >> sys_log.txt a:>toolkit>md5sum sys_log.txt >> sys_log.sum a:>toolkit>type sys_log.sum 301657924f0263c89caa702e08cc48e7 *sys_log.txt Ya que es necesario llevar nota de todos los pasos realizados, nos ayudaremos de la tabla 4.1

para registrar los datos importantes como la hora de inicio de la captura, el comando aplicado, si

es confiable o no, la salida del md5sum al archivo de datos y posibles comentarios, como se

muestra en la tabla 4.2. Tabla 4.2 Documentando: Caso 1

Confiable

Tiempo de inicio

Programa BAT

Archivo generado

Comando aplicado

SI NO

Salida del md5sum

Notas

9:19:20 montaje X 116798d3a85f14acdd5870ee16c4608d

9:22:23 cmd.exe cmd.exe X 301657924f0263c89caa702e08cc48e7

9:27:22 comandos.bat datos.txt date /t time /t dir c:\ /Q /S /TA hostname ipconfig fport netstat -an pslist ntlast

X 7122f802e1a087a0b31848f70862c0d1

El archivo generado es guardado en el medio confiable

95

Confiable

psloggedon nbtstat -c nbtstat -n nbtstat -r nbtstat -s net session arp –a dir c:\ /Q /S /TA

9:32:20 copy_reg.bat copy_reg.txt

regedit -e respaldo_registry.reg

X 116798d3a85f14acdd5870ee16c4608d

9:35:23 sys_log.bat sys_log.txt

dumpel -l system –t X 301657924f0263c89caa702e08cc48e7

9:38:18 reg_add.bat memory.dmp

reg ADD HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters /v CrashOnCtrlScroll /t REG_DWORD /d 0x1

X El archivo generado es guardado en el directorio de sistema del equipo bajo análisis

La información obtenida, será copiada a un lugar de almacenamiento seguro, a un medio

conectado a la estación de trabajo bajo análisis como una memoria USB o un floppy. También se

puede transferir por red a una estación de trabajo segura con el comando “netcat”. Otra

herramienta útil es contar con una cámara fotográfica para tomar fotografías de todas las

pantallas posibles.

96


WINDOWS CON ACCESO REMOTO

En el segundo caso las condiciones bajo las cuales se encuentra el equipo bajo sospecha son

similares al primer caso, el sistema se encontrará “vivo” conectado a energía eléctrica y con sus

procesos en estado “normal”, solamente que en este caso no se tiene acceso local al sistema, por

lo que se tendrá que obtener la información a través de la red. El sistema operativo con el que se

enfrentará el investigador será Windows 2000 y se cuenta con el password de acceso. La

siguiente figura muestra el tipo de caso a tratar:

Estado del

sistema

MUERTO VIVO

CASO 2: Windows CASO 1:

Windows


CASO 3: Linux

CASO 4: Linux



(ejemplos)

Fig. 4.5 Caso 2: Aplicación de metodología con Windows en forma remota

El equipo bajo sospecha puede ser un servidor o estación de trabajo conectado en red, por lo que

en este caso observamos que se puede obtener información de dos formas; la primera a través de

lo que el mismo equipo bajo sospecha emana a través de la red y por lo tanto a todos los equipos

conectados a ésta, sin establecer ningún tipo de conexión al sistema sospechoso, y la segunda

forma estableciendo una conexión segura específica al sistema sospechoso para obtener toda la

información volátil posible con comandos locales aplicados remotamente.

Por lo que la metodología la vamos a aplicar dos veces:

97

• Procedimiento1: Aplicación de la metodología obteniendo información a través de los

servicios activos de red disponibles del equipo comprometido, sin que se tenga que

establecer una conexión segura a través de la red y directa al equipo.

• Procedimiento 2: Aplicación de la metodología estableciendo una línea de comunicación

segura específica al equipo sospechoso a través de la red.

La información recolectada por ambos procedimientos podrá complementarse para obtener

mayor información del sistema bajo sospecha.

Para tener una mejor idea de la situación, la figura 4.6 muestra el diagrama de conexión de los

equipos en la red y los procedimientos que se llevarán a cabo para realizar la recolección:

Equipo comprometido

Investigador forense

Win2000

Procedimiento 2: shell seguro

Procedimiento 1: Servicios activos en red

Fig. 4.6 Diagrama de conexión: Caso 2

La estación forense tendrá cargado el conjunto de herramientas que se utilizará y ésta misma

almacenará los datos recolectados.

98

PROCEDIMIENTO 1: Información obtenida a través de los servicios de red disponibles de

la máquina comprometida

Dentro de este procedimiento aplicaremos los pasos de la metodología propuesta.

PASO 1: ESTABLECER UNA LINEA DE COMANDOS SEGURO

Para este caso en una primera etapa trataremos de obtener todos los datos posibles a través de

servicios disponibles en red de la máquina bajo análisis, por lo que nos saltaremos este paso y

comenzaremos con el segundo.

PASO 2: REALIZAR UN REGISTRO DE TIEMPO

En este paso de la metodología vamos a obtener información en forma remota. Los comandos

que aplicaremos nos permiten obtener información a través de la red, sin necesidad de tener algún

tipo de acceso al equipo.

Primero obtenemos el tiempo y fecha del sistema con el comando “net time”, como se muestra a

continuación: net time \\machinename (forense)C:\pruebas>net time \\comprometido La hora actual en \\luna es 8/16/2005 4:42 PM Se ha completado el comando correctamente. PASO 3: OBTENER EL ESTADO DEL SISTEMA

A continuación podemos obtener información del sistema con el comando “srvinfo” que es una

utilería del resource kit. (forense)C:\pruebas>srvinfo \\comprometido Server Name: comprometido Security: Users NT Type: NT Member Server - Enterprise Version: 5.0 Build: 2195, Service Pack 4 Current Type: Uniprocessor Free Product Name: Microsoft Windows 2000 Registered Owner: alicia

99

Registered Organization: cna ProductID: 51879-270-5770243-05434 Original Install Date: Tue Jul 05 10:36:02 2005 Domain: Error 2 PDC: Error 1717 IP Address: 172.29.69.83 CPU[0]: x86 Family 6 Model 7 Stepping 3: 498 MHz Hotfixes: [ServicePackUninstall]: [Q147222]: [KB842526]: [KB841873]: [KB841872]: [KB840315]: [KB839645]: [KB839643]: [KB837001]: [KB824146]: [KB824141]: [KB824105]: Drive: [FileSys] [ Size ] [ Free ] [ Used ] C$ NTFS 3050 994 2056 Services: [Running] Alerter [Stopped] Application Management [Stopped] Background Intelligent Transfer Service [Running] Computer Browser [Stopped] Indexing Service [Stopped] ClipBook [Running] Distributed File System [Running] DHCP Client [Stopped] Logical Disk Manager Administrative Service [Running] Logical Disk Manager [Running] DNS Client [Running] Event Log [Running] COM+ Event System [Stopped] Fax Service [Running] IIS Admin Service [Stopped] Intersite Messaging [Stopped] Kerberos Key Distribution Center [Running] Server [Running] Workstation [Running] License Logging Service [Running] TCP/IP NetBIOS Helper Service [Running] McAfee Framework Service [Running] Network Associates McShield [Running] Network Associates Task Manager [Running] Messenger [Stopped] NetMeeting Remote Desktop Sharing [Running] Distributed Transaction Coordinator [Stopped] Windows Installer [Stopped] Network DDE [Stopped] Network DDE DSDM [Stopped] Net Logon [Running] Network Connections [Stopped] File Replication [Stopped] NT LM Security Support Provider [Running] Removable Storage [Running] Plug and Play [Running] IPSEC Policy Agent [Running] Protected Storage [Stopped] Remote Access Auto Connection Manager [Running] Remote Access Connection Manager [Running] Routing and Remote Access [Running] Remote Registry Service [Stopped] Remote Procedure Call (RPC) Locator [Running] Remote Procedure Call (RPC) [Stopped] QoS RSVP [Running] Security Accounts Manager [Stopped] Smart Card Helper [Stopped] Smart Card [Running] Task Scheduler [Running] RunAs Service [Running] System Event Notification

100

[Stopped] Internet Connection Sharing [Running] Simple Mail Transport Protocol (SMTP) [Running] Print Spooler [Stopped] Performance Logs and Alerts [Running] Telephony [Stopped] Terminal Services [Stopped] Telnet [Stopped] Distributed Link Tracking Server [Running] Distributed Link Tracking Client [Running] User Mode Process Dump [Stopped] Uninterruptible Power Supply [Stopped] Utility Manager [Stopped] Windows Time [Running] World Wide Web Publishing Service [Running] Windows Management Instrumentation [Running] Windows Management Instrumentation Driver Extensions [Running] Automatic Updates [Stopped] Wireless Configuration Network Card [0]: System Up Time: 0 Days, 3 Hr, 13 Min, 47 Sec Aplicamos el comando “pslist” para obtener los procesos que están corriendo en el sistema

utilizando la siguiente sintaxis: pslist \\machinename (forense)C:\toolkit>pslist \\comprometido PsList 1.26 - Process Information Lister Copyright (C) 1999-2004 Mark Russinovich Sysinternals - www.sysinternals.com Process information for comprometido: Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time Idle 0 0 1 0 0 2:04:11.534 2:05:42.836 System 8 8 47 210 24 0:00:09.253 2:05:42.836 SMSS 144 11 6 33 1096 0:00:00.530 2:05:42.836 CSRSS 168 13 10 437 1288 0:00:02.463 2:05:31.820 WINLOGON 164 13 18 429 6788 0:00:02.663 2:05:30.538 SERVICES 216 9 38 531 3144 0:00:03.695 2:05:28.565 LSASS 228 9 20 291 2896 0:00:01.632 2:05:28.535 svchost 436 8 9 276 1704 0:00:00.851 2:05:23.037 spoolsv 464 8 11 136 2700 0:00:00.540 2:05:22.446 msdtc 492 8 21 207 1992 0:00:00.330 2:05:22.336 svchost 600 8 28 1246 9768 0:00:04.947 2:05:20.233 LLSSRV 628 9 9 75 776 0:00:00.120 2:05:19.492 FrameworkServic 672 8 10 193 2944 0:00:01.041 2:05:18.400 Mcshield 732 13 20 203 18320 0:00:32.556 2:05:17.018 VsTskMgr 748 8 11 131 5112 0:00:00.250 2:05:16.568 naPrdMgr 792 8 4 108 4560 0:00:00.220 2:05:14.625 regsvc 868 8 4 91 744 0:00:00.250 2:05:09.978 mstask 880 8 6 114 1140 0:00:00.270 2:05:08.446 userdump 936 8 4 47 332 0:00:00.020 2:04:58.071 WinMgmt 1000 8 5 117 1332 0:00:10.414 2:04:55.297 svchost 1032 8 6 213 5904 0:00:03.885 2:04:53.965 dfssvc 1056 8 2 36 484 0:00:00.070 2:04:53.495 inetinfo 1084 8 36 776 7424 0:00:02.032 2:04:50.911 svchost 1368 8 11 168 1580 0:00:00.220 2:03:58.786 explorer 1336 8 12 248 4888 0:00:07.821 2:02:37.549 shstat 724 8 6 61 4600 0:00:00.210 2:02:03.160 UpdaterUI 636 8 4 96 1004 0:00:00.260 2:02:00.937 internat 1288 8 1 27 372 0:00:00.070 2:02:00.396 wuauclt 1700 8 5 101 1572 0:00:00.150 2:01:03.163 CMD 1716 8 1 21 316 0:00:00.060 2:00:55.562 DLLHOST 720 8 8 143 1724 0:00:01.001 1:52:07.874 mdm 1620 8 3 88 828 0:00:00.140 1:24:16.150 Aplicamos el comando “nmap” para realizar un escaneo de puertos, utilizando la siguiente

sintaxis, donde la opción “sT” significa conexiones TCP : nmap –sT <dirección IP>

101

(forense)C:\toolkit\nmap\nmap-3.81>nmap -sT 172.29.69.83 Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-08-16 11:27 Hora est . de AmÚrica Central Warning: OS detection will be MUCH less reliable because we did not find at lea st 1 open and 1 closed TCP port Interesting ports on 172.29.69.83: (The 1654 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 25/tcp open smtp 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 443/tcp open https 445/tcp open microsoft-ds 1025/tcp open NFS-or-IIS 1723/tcp open pptp 3372/tcp open msdtc MAC Address: 00:50:DA:B7:D5:BD (3com) Device type: general purpose Running: Microsoft Windows 95/98/ME|NT/2K/XP OS details: Microsoft Windows Millennium Edition (Me), Windows 2000 Pro or Advan ced Server, or Windows XP Nmap finished: 1 IP address (1 host up) scanned in 118.749 seconds Los rootkits y otros programas de acceso remoto son ejecutados desde un servicio, por lo que

listamos los servicios utilizando “sclist”: (forense)C:\toolkit>sclist \\comprometido -------------------------------------------- - Service list for \\comprometido -------------------------------------------- running Alerter Alerter stopped AppMgmt Application Management stopped BITS Background Intelligent Transfe running Browser Computer Browser stopped cisvc Indexing Service stopped ClipSrv ClipBook running Dfs Distributed File System running Dhcp DHCP Client stopped dmadmin Logical Disk Manager Administr running dmserver Logical Disk Manager running Dnscache DNS Client running Eventlog Event Log running EventSystem COM+ Event System stopped Fax Fax Service running IISADMIN IIS Admin Service stopped IsmServ Intersite Messaging stopped kdc Kerberos Key Distribution Cent running lanmanserver Server running lanmanworkstation Workstation running LicenseService License Logging Service running LmHosts TCP/IP NetBIOS Helper Service running McAfeeFramework McAfee Framework Service running McShield Network Associates McShield running McTaskManager Network Associates Task Manage running Messenger Messenger stopped mnmsrvc NetMeeting Remote Desktop Shar running MSDTC Distributed Transaction Coordi stopped MSIServer Windows Installer stopped NetDDE Network DDE stopped NetDDEdsdm Network DDE DSDM stopped Netlogon Net Logon running Netman Network Connections stopped NtFrs File Replication stopped NtLmSsp NT LM Security Support Provide running NtmsSvc Removable Storage running PlugPlay Plug and Play

102

running PolicyAgent IPSEC Policy Agent running ProtectedStorage Protected Storage running PSEXESVC PsExec stopped RasAuto Remote Access Auto Connection running RasMan Remote Access Connection Manag running RemoteAccess Routing and Remote Access running RemoteRegistry Remote Registry Service stopped RpcLocator Remote Procedure Call (RPC) Lo running RpcSs Remote Procedure Call (RPC) stopped RSVP QoS RSVP running SamSs Security Accounts Manager stopped SCardDrv Smart Card Helper stopped SCardSvr Smart Card running Schedule Task Scheduler running seclogon RunAs Service running SENS System Event Notification stopped SharedAccess Internet Connection Sharing running SMTPSVC Simple Mail Transport Protocol running Spooler Print Spooler stopped SysmonLog Performance Logs and Alerts running TapiSrv Telephony stopped TermService Terminal Services stopped TlntSvr Telnet stopped TrkSvr Distributed Link Tracking Serv running TrkWks Distributed Link Tracking Clie running udmpsvc User Mode Process Dump stopped UPS Uninterruptible Power Supply stopped UtilMan Utility Manager stopped W32Time Windows Time running W3SVC World Wide Web Publishing Serv running WinMgmt Windows Management Instrumenta running Wmi Windows Management Instrumenta running wuauserv Automatic Updates stopped WZCSVC Wireless Configuration Otra de las herramientas que podemos aplicar para listar los archivos compartidos y quien los ha

accedido es “srvcheck”, pero debe ser aplicado con una cuenta privilegiada, que en el siguiente

ejemplo muestra al usuario alicia_user y al usuario alicia_admin con privilegios totales sobre la

carpeta_compartida_de_comprometido. (forense)C:\toolkit\srvcheck \\comprometido

\\comprometido\carpeta_compartida_de_comprometido COMPROMETIDO\alicia_user Full Control COMPROMETIDO\alicia_admin Full Control

PASO 4: DETERMINAR LAS CONEXIONES AL SISTEMA

En este paso de la metodología obtenemos las estadísticas del protocolo y las conexiones actuales

de TCPIP con el comando “nbtstat” y la siguiente sintaxis: nbtstat –a \\machinename La opción “-a” hace una lista de los equipos remotos

Ejemplo de aplicación del comando (forense)C:\toolkit>nbtstat -a comprometido

103

Conexión de área local: Dirección IP: [172.29.69.69] Id. de ámbito : [] NetBIOS Remote Machine Name Table Nombre Tipo Estado --------------------------------------------- LUNA <00> Único Registrado FORE <00> Grupo Registrado LUNA <20> Único Registrado LUNA <03> Único Registrado FORE <1E> Grupo Registrado FORE <1D> Único Registrado ..__MSBROWSE__.<01> Grupo Registrado INet~Services <1C> Grupo Registrado IS~LUNA........<00> Único Registrado Dirección MAC = 00-50-DA-B7-D5-BD PROCEDIMIENTO 2: Con línea de comunicación segura

En este procedimiento primero estableceremos una línea de comunicación segura a través de la

red para aplicar las herramientas y una vez hecha, capturamos la información.

PASO 1: ESTABLECER UNA LÍNEA DE COMANDOS SEGURA

Aplicaremos el primer paso de la metodología estableciendo una conexión segura, ya que el

investigador forense no se encuentra físicamente en el lugar donde se ubica el quipo bajo análisis.

Los comandos se copiarán remotamente y se ejecutarán en forma local.

Para realizar una conexión administrativa a la máquina remota utilizamos el comando “net use”

desde la estación forense con la siguiente sintaxis: Net use \\machine\ipc$ /user:machine\administrator password

Ejemplo de aplicación: (forense)C:\>net use \\comprometido\ipc$ /user:administrator password Se ha completado el comando correctamente. Una vez establecida la conexión copiamos los comandos confiables de nuestro conjunto de

herramientas (toolkit) con el comando xcopy: (forense) C:\>xcopy /SVI toolkit \\comprometido\c$\toolkit toolkit\Auditpol.exe toolkit\dh.exe toolkit\dhcmp.exe toolkit\drivers.exe toolkit\Fport.exe

104

toolkit\listdlls.exe toolkit\NTLast.exe toolkit\perms.exe toolkit\procexp.chm toolkit\procexp.exe toolkit\psexec.exe toolkit\psfile.exe toolkit\psgetsid.exe toolkit\Psinfo.exe toolkit\pskill.exe toolkit\pslist.exe toolkit\psloggedon.exe toolkit\psloglist.exe toolkit\pspasswd.exe toolkit\psservice.exe toolkit\psshutdown.exe toolkit\pssuspend.exe toolkit\Rasusers.exe toolkit\README.TXT toolkit\Regrest.exe toolkit\Sclist.exe toolkit\Showmbrs.exe toolkit\Srvcheck.exe toolkit\Srvinfo.exe toolkit\tcpvcon.exe toolkit\nmap\nmap-os-fingerprints toolkit\nmap\nmap-services toolkit\nmap\nmap.exe 33 archivos copiados Una vez copiados los archivos, establecemos una línea de comandos segura (cmd.exe) aplicando

la herramienta “psexec” con la siguiente sintaxis: psexec \\machine cmd

Ejemplo de aplicación (forense)C:\>cd toolkit (forense)C:\toolkit>psexec \\comprometido cmd PsExec v1.55 - Execute processes remotely Copyright (C) 2001-2004 Mark Russinovich Sysinternals - www.sysinternals.com Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. (comprometido)C:\WINNT\system32>cd \toolkit PASO 2: REALIZAR UN REGISTRO DE TIEMPO DEL SISTEMA (TIME STAMP)

Como en el caso 1 utilizamos el comando “dir” o “ls” para obtener un listado de todos los

archivos en el sistema bajo análisis, tiempos de acceso, modificación y creación. a:\toolkit>dir c:\ /Q /S /TA Volume in drive C has no label. Volume Serial Number is ECD3-2160 Directory of c:\ 08/16/2005 05:43p 36,112 BUILTIN\Administrators Auditpol.exe

105

08/16/2005 05:43p 24,848 BUILTIN\Administrators dh.exe 08/16/2005 05:43p 9,488 BUILTIN\Administrators dhcmp.exe 08/18/2005 05:51p <DIR> BUILTIN\Administrators Documents and Settings 08/16/2005 05:43p 6,928 BUILTIN\Administrators drivers.exe 08/17/2005 12:34p 114,688 BUILTIN\Administrators Fport.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Inetpub 08/16/2005 05:43p 53,248 BUILTIN\Administrators listdlls.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators nmap 08/16/2005 05:43p 208,948 BUILTIN\Administrators NTLast.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Program Files 08/18/2005 04:29p <DIR> BUILTIN\Administrators programas 08/17/2005 05:26p 25,252,224 LUNA\alicia_user resp.reg 08/18/2005 04:29p <DIR> BUILTIN\Administrators temp 08/18/2005 04:29p <DIR> BUILTIN\Administrators toolkit 08/18/2005 04:29p <DIR> BUILTIN\Administrators WINNT 8 File(s) 25,706,484 bytes . . . . . . . . . PASO 3: OBTENER EL ESTADO DEL SISTEMA

Una vez hecho el registro de tiempo en el equipo comprometido, procedemos a obtener el estado

del sistema con los comandos de nuestro conjunto de herramientas que ya se encuentra en el

sistema bajo análisis:

Acción 1: Obtener los datos del sistema

Como en el caso anterior obtenemos la identificación de red del equipo con el comando

“ipconfig”, como se muestra a continuación: (forense) C:\toolkit>ipconfig /all Windows 2000 IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 172.29.69.83 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.29.69.254 Acción 2: Determinar los puertos abiertos Para enumerar los puertos por los cuales los procesos están escuchando, utilizamos la herramienta “fport”: (comprometido)C:\toolkit\fport.exe (comprometido)C:\toolkit>fport FPort v2.0 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone, Inc. http://www.foundstone.com Pid Process Port Proto Path 1056 inetinfo -> 25 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 1056 inetinfo -> 80 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 436 svchost -> 135 TCP C:\WINNT\system32\svchost.exe 8 System -> 139 TCP

106

1056 inetinfo -> 443 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 8 System -> 445 TCP 492 msdtc -> 1025 TCP C:\WINNT\System32\msdtc.exe 880 MSTask -> 1026 TCP C:\WINNT\system32\MSTask.exe 1056 inetinfo -> 1028 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 8 System -> 1030 TCP 1004 svchost -> 1056 TCP C:\WINNT\system32\svchost.exe 8 System -> 1059 TCP 8 System -> 1723 TCP 1056 inetinfo -> 2087 TCP C:\WINNT\System32\inetsrv\inetinfo.exe 492 msdtc -> 3372 TCP C:\WINNT\System32\msdtc.exe 436 svchost -> 135 UDP C:\WINNT\system32\svchost.exe 8 System -> 137 UDP 8 System -> 138 UDP 8 System -> 445 UDP 228 lsass -> 500 UDP C:\WINNT\system32\lsass.exe 1056 inetinfo -> 1029 UDP C:\WINNT\System32\inetsrv\inetinfo.exe 600 svchost -> 1031 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1032 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1033 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1645 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1646 UDP C:\WINNT\System32\svchost.exe 8 System -> 1701 UDP 600 svchost -> 1812 UDP C:\WINNT\System32\svchost.exe 600 svchost -> 1813 UDP C:\WINNT\System32\svchost.exe 1056 inetinfo -> 3456 UDP C:\WINNT\System32\inetsrv\inetinfo.exe Acción 3: Listando los procesos corriendo

Para obtener la lista de procesos que está corriendo en el sistema utilizamos la herramienta

“pslist”, esta información ya la obtuvimos en forma remota, pero a menos que no se haya podido

obtener, procederemos a su captura mediante la conexión segura al equipo.


Este paso se realiza si se cuenta con tiempo suficiente para obtener las bitácoras del sistema.

Primero podemos descargar la información del “registry” a un archivo, con el comando “reg” y

“regedit”, como se muestra a continuación: (comprometido)c:\toolkit\regedit –e respaldo_registry.reg (comprometido)c:\toolkit\reg export HKLM respaldo_registry.reg The operation completed successfully Para obtener las bitácoras nos podemos auxiliar del comando dumpel.exe del resource kit. En el

siguiente ejemplo se muestra la obtención de las bitácoras de seguridad, sistema y aplicaciones: (comprometido)c:\toolkit\dumpel –f security.bck –l security The operation completed successfully (comprometido)c:\toolkit\dumpel –f system.bck –l system The operation completed successfully (comprometido)c:\toolkit\dumpel –f application.bck –l application The operation completed succesfully

107

PASO 4: DETERMINAR LAS CONEXIONES AL SISTEMA

El siguiente paso es saber quien esta en el sistema para lo cual utilizaremos las herramientas “net

session” y “tcpvcon” (comprometido)C:\toolkit>net session Computer User name Client Type Opens Idle time ------------------------------------------------------------------------------- \\ATORRES ADMINISTRATOR Windows 2002 Serv 4 00:00:00 The command completed successfully. (comprometido)C:\toolkit>tcpvcon TCPView v2.34 - TCP/UDP endpoint lister Copyright (C) 1998-2003 Mark Russinovich Sysinternals - www.sysinternals.com [TCP] System PID: 8 State: ESTABLISHED Local: comprometido:netbios-ssn Remote: atorres:4082 También listamos los miembros del grupo administrador usando la herramienta “showmbrs” para

verificar algo inusual (comprometido)C:\toolkit>showmbrs administrators Members of local group [\administrators]: COMPROMETIDO\Administrator COMPROMETIDO\alicia_admin Utilizamos la herramienta “psloggedon” para mostrar los usuarios que están en el sistema (logged

on) actualmente. (comprometido)C:\toolkit>psloggedon PsLoggedOn v1.31 - Logon Session Displayer Copyright (C) 1999-2003 Mark Russinovich Sysinternals - www.sysinternals.com Users logged on locally: 8/16/2005 5:37:00 PM COMPROMETIDO\Administrator Users logged on via resource shares: 8/16/2005 6:04:31 PM (null)\ADMINISTRATOR

Con la herramienta “arp” mostramos las conexiones en la tabla de direcciones. (comprometido)C:\toolkit>arp -a Interface: 172.29.69.83 on Interface 0x1000003 Internet Address Physical Address Type 172.29.69.69 00-09-6b-14-84-c9 dynamic 172.29.69.254 00-20-9c-12-db-b4 dynamic

108

Con la herramienta “netstat” mostramos las conexiones activas. (comprometido)C:\toolkit>netstat -a Active Connections Proto Local Address Foreign Address State TCP comprometido:smtp comprometido:0 LISTENING TCP comprometido:http comprometido:0 LISTENING TCP comprometido:epmap comprometido:0 LISTENING TCP comprometido:https comprometido:0 LISTENING TCP comprometido:microsoft-ds comprometido:0 LISTENING TCP comprometido:1025 comprometido:0 LISTENING TCP comprometido:1026 comprometido:0 LISTENING TCP comprometido:1028 comprometido:0 LISTENING TCP comprometido:1030 comprometido:0 LISTENING TCP comprometido:1031 comprometido:0 LISTENING TCP comprometido:pptp comprometido:0 LISTENING TCP comprometido:2087 comprometido:0 LISTENING TCP comprometido:3372 comprometido:0 LISTENING TCP comprometido:netbios-ssn comprometido:0 LISTENING TCP comprometido:netbios-ssn ATORRES:4082 ESTABLISHED TCP comprometido:1041 ATORRES:netbios-ssn TIME_WAIT UDP comprometido:epmap *:* UDP comprometido:microsoft-ds *:* UDP comprometido:1029 *:* UDP comprometido:1034 *:* UDP comprometido:1645 *:* UDP comprometido:1646 *:* UDP comprometido:l2tp *:* UDP comprometido:radius *:* UDP comprometido:radacct *:* UDP comprometido:3456 *:* UDP comprometido:1032 *:* UDP comprometido:1033 *:* UDP comprometido:netbios-ns *:* UDP comprometido:netbios-dgm *:* UDP comprometido:isakmp *:* Para encontrar un historial de entrada al sistema (login history) utilizamos la herramienta

“ntlast.exe“, como se muestra a continuación: (comprometido)C:\toolkit>ntlast alicia_user COMPROMETIDO COMPROMETIDO Wed Aug 17 02:09:24pm 2005 Administrator COMPROMETIDO COMPROMETIDO Wed Aug 17 12:14:31pm 2005 - End Of File -

PASO 5: REALIZAR EL 2º. REGISTRO DE TIEMPO

Como en el paso 1 nuevamente utilizamos el comando “dir” para obtener un listado de todos los

archivos en el sistema bajo análisis, tiempos de acceso, modificación y creación. (forense) C:\toolkit>dir c:\ /Q /S /TA Volume in drive C has no label. Volume Serial Number is ECD3-2160 Directory of c:\ 08/16/2005 05:43p 36,112 BUILTIN\Administrators Auditpol.exe 08/16/2005 05:43p 24,848 BUILTIN\Administrators dh.exe 08/16/2005 05:43p 9,488 BUILTIN\Administrators dhcmp.exe

109

08/18/2005 05:51p <DIR> BUILTIN\Administrators Documents and Settings 08/16/2005 05:43p 6,928 BUILTIN\Administrators drivers.exe 08/17/2005 12:34p 114,688 BUILTIN\Administrators Fport.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Inetpub 08/16/2005 05:43p 53,248 BUILTIN\Administrators listdlls.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators nmap 08/16/2005 05:43p 208,948 BUILTIN\Administrators NTLast.exe 08/18/2005 04:29p <DIR> BUILTIN\Administrators Program Files 08/18/2005 04:29p <DIR> BUILTIN\Administrators programas 08/17/2005 05:26p 25,252,224 LUNA\alicia_user resp.reg 08/18/2005 04:29p <DIR> BUILTIN\Administrators temp 08/18/2005 04:29p <DIR> BUILTIN\Administrators toolkit 08/18/2005 04:29p <DIR> BUILTIN\Administrators WINNT 8 File(s) 25,706,484 bytes . . . . . . . . . PASO 6: HACER UNA COPIA DE LA MEMORIA

Para obtener una copia de la memoria, en este caso podemos utilizar la utilería “pslist” en forma

remota con sus opciones “x” que muestra los detalles de la memoria y proceso hijos (threds) y “t”

que muestra el árbol de procesos. El siguiente comando envía la salida de esta herramienta a un

archivo pslistx.txt.

Ejemplo de aplicación con la opción “x”: (forense)c:\toolkit>pslist –x \\comprometido –u administrator –p password >> pslistx.txt PsList 1.26 - Process Information Lister Copyright (C) 1999-2004 Mark Russinovich Sysinternals - www.sysinternals.com Process and thread information for comprometido: Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time Idle 0 0 1 0 0 0:47:56.105 0:47:58.269 VM WS Priv Priv Pk Faults NonP Page 0 16 0 0 1 0 0 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 0 0 178577 Running 0:00:00.000 0:47:56.125 0:00:00.000 Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time System 8 8 48 187 28 0:00:13.088 0:47:58.269 VM WS Priv Priv Pk Faults NonP Page 1672 36 28 176 2292 0 0 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 4 0 2028 Ready 0:00:00.000 0:00:11.576 0:00:00.000 12 13 6 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.302 16 13 25459 Wait:Queue 0:00:00.000 0:00:00.080 0:48:21.302 20 13 2536 Wait:Queue 0:00:00.000 0:00:00.060 0:48:21.302 24 13 32722 Wait:Queue 0:00:00.000 0:00:00.060 0:48:21.302 28 13 1635 Wait:Queue 0:00:00.000 0:00:00.100 0:48:21.302 32 13 3581 Wait:Queue 0:00:00.000 0:00:00.270 0:48:21.302 36 13 14 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.302 40 12 965 Wait:Queue 0:00:00.000 0:00:00.210 0:48:21.302 44 13 1838 Wait:Queue 0:00:00.000 0:00:00.260 0:48:21.302 48 15 253 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.302 52 15 2944 Wait:Executive 0:00:00.000 0:00:00.000 0:48:21.302 56 18 681 Wait:VirtualMem 0:00:00.000 0:00:00.040 0:48:21.282 60 17 1951 Wait:FreePage 0:00:00.000 0:00:00.150 0:48:21.282 64 16 47802 Wait:Executive 0:00:00.000 0:00:00.010 0:48:21.282 68 23 78867 Wait:Executive 0:00:00.000 0:00:00.010 0:48:21.282 72 16 3 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.122

110

76 17 19 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.122 80 8 345 Wait:Executive 0:00:00.000 0:00:00.020 0:48:20.792 84 17 93 Wait:VirtualMem 0:00:00.000 0:00:00.000 0:48:20.771 88 8 1 Wait:Executive 0:00:00.000 0:00:00.000 0:48:20.411 92 8 15 Wait:Queue 0:00:00.000 0:00:00.000 0:48:14.242 104 8 6 Wait:Executive 0:00:00.000 0:00:00.000 0:47:59.791 108 8 1 Wait:Executive 0:00:00.000 0:00:00.000 0:47:59.791 112 8 1 Wait:Executive 0:00:00.000 0:00:00.000 0:47:58.790 120 8 1 Wait:Queue 0:00:00.000 0:00:00.000 0:47:58.479 Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time mstask 760 8 6 111 1144 0:00:00.140 0:47:28.226 VM WS Priv Priv Pk Faults NonP Page 26924 460 1144 1160 1343 14 23 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 684 9 121 Wait:Executive 0:00:00.020 0:00:00.010 0:47:28.216 780 8 272 Wait:UserReq 0:00:00.040 0:00:00.030 0:47:23.459 800 9 7 Wait:LpcReceive 0:00:00.000 0:00:00.010 0:47:21.366 836 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.684 864 9 19 Wait:Queue 0:00:00.000 0:00:00.000 0:47:12.684 896 10 469 Wait:UserReq 0:00:00.000 0:00:00.020 0:47:11.912 Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time userdump 820 8 4 47 336 0:00:00.020 0:47:18.212 VM WS Priv Priv Pk Faults NonP Page 17056 72 336 336 299 1 14 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 816 14 47 Wait:Executive 0:00:00.010 0:00:00.000 0:47:18.212 876 8 7 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.433 880 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.433 884 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.403 Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time WinMgmt 908 8 4 112 1156 0:00:10.404 0:47:11.702 VM WS Priv Priv Pk Faults NonP Page 23452 108 1156 2168 8965 11 15 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 904 9 101 Wait:Executive 0:00:00.050 0:00:00.020 0:47:11.702 796 9 683 Wait:UserReq 0:00:00.040 0:00:00.110 0:47:09.940 1084 10 524 Wait:LpcReceive 0:00:00.080 0:00:00.080 0:46:53.406 344 9 30 Wait:Queue 0:00:00.000 0:00:00.000 0:45:55.823

Ejemplo de aplicación de “pslist” con la opción “t”: c:\toolkit>pslist –t \\comprometido –u administrator –p password >> pslistt.txt PsList 1.26 - Process Information Lister Copyright (C) 1999-2004 Mark Russinovich Sysinternals - www.sysinternals.com Process information for comprometido: Name Pid Pri Thd Hnd VM WS Priv Idle 0 0 1 0 0 16 0 System 8 8 48 190 1672 36 28 SMSS 144 11 6 33 7304 60 1104 CSRSS 168 13 9 419 19388 396 1092 WINLOGON 188 13 17 421 41260 1180 7140 SERVICES 216 9 42 542 38684 3300 4260 svchost 416 8 8 288 23544 2364 1632 naPrdMgr 656 8 4 106 35684 264 3392 DLLHOST 988 8 13 149 24988 5596 1796 spoolsv 444 8 11 135 30936 1068 2716 svchost 476 8 33 1269 148640 3920 9944 LLSSRV 500 9 10 77 19496 644 792 FrameworkServic 540 8 10 194 33788 1056 2976 Mcshield 600 13 20 199 77152 5912 18644 VsTskMgr 620 8 11 131 45004 300 3960 regsvc 732 8 4 95 14904 1376 748 mstask 760 8 6 111 26924 460 1144 userdump 820 8 4 47 17056 72 336 WinMgmt 908 8 4 112 23452 108 1156

111

svchost 920 8 5 171 29020 1508 3720 dfssvc 952 8 2 36 11776 116 492 inetinfo 968 8 34 703 64024 5052 7204 svchost 972 8 4 187 26132 476 2596 msdtc 984 8 21 195 33660 464 1976 svchost 1344 8 10 161 23556 276 1576 LSASS 228 9 15 277 33444 2296 2756 explorer 1500 8 13 225 37800 2628 3716 internat 272 8 1 27 17388 100 380 UpdaterUI 1288 8 4 96 28572 348 1008 shstat 1296 8 6 60 38004 600 3448 PASO 7: TRANSFERIR A UN MEDIO SEGURO Y DOCUMENTAR

La tabla 4.3 resume los pasos realizados, las acciones tomadas y las herramientas utilizadas que

nos ayudarán a realizar la documentación apropiada de la captura de datos.


Pasos Acciones Windows

NT/2000 Procedimiento 1: Información obtenida vía la red

2 Registro de tiempo Tiempo y fecha del sistema net time 3 Estado y datos del sistema Información del equipo

Listar los procesos que abren sockets Obtener los puertos abiertos Listar los servicios Directorios compartidos y quien los ha accedido

srvinfo pslist nmap sclist srvchk

4 Conexiones al sistema Conexiones actuales establecidas nbtstat Procedimiento 2: Información obtenida localmente

1 Conectarse remotamente Establecer una conexión administrativa Copias remotas Ejecución de comandos remotos

net use xcopy psexec

2 Registro de tiempo Time stamp, tiempo de creación de los archivos dir 3 Estado del sistema Obtener los puertos abiertos

Respuesta inicial profunda Descarga todo el registry a un archivo Obteniendo las bitácoras

fport regedit, reg dumpel

4 Conexiones al sistema Listar la conexiones abiertas Listar los miembros del grupo administrador Determinar quien está dentro del sistema Listar conexiones recientes Desplegar direcciones IP y físicas Lista las conexiones exitosas y fallidas Historial de entradas al sistema

net session, tcpvcon showmbrs netstat psloggedon arp netstat nlast

5 2º. Registro de tiempo Time stamp, tiempo de creación de los archivos dir 6 Información de la memoria Obtener detalles de la memoria y procesos pslist –t

pslist –x 7 Transferir y documentar Transferir y almacenar los datos en un lugar script

112

Pasos Acciones Windows NT/2000

seguro Documentar los pasos

netcat md5sum

Una vez seleccionados los programas y pasos, realizamos un programa script que corra todos

estos comandos al mismo tiempo o también se puede correr cada comando en forma individual y

transferirlos a un sitio seguro con ayuda de la herramienta “netcat”, que envía información a

través de la red.

Para utilizar “netcat” el primer paso es levantar el servicio en nuestra estación de trabajo

(dirección IP 172.29.69.69), para escuchar (l) o recibir los datos remotos por el puerto (p) que en

este caso será el número 2222: (forense)c:\WSForense>nc –l –p 2222 > datos En el equipo bajo análisis se dirige la salida del script generado hacia la dirección IP de la

estación de trabajo forense: (comprometido)c:\toolkit>script | nc 172.29.69.69 2222 En caso de la aplicación de cada comando en forma individual, en la estación forense se abrirá un

archivo para recibir los datos del comando aplicado (forense)c:\WSForense>nc –l –p 2222 > timestamp1.txt

En el equipo comprometido se ejecutará el comando y la salida de dicho comando saldrá por la

red al archivo que hemos abierto en la estación forense: (comprometido)c:\toolkit>dir c:\ /Q /S /TA >> | nc 172.29.69.69 2222 Y así sucesivamente para cada comando.

Para cerrar la conexión se puede teclear CTRL-C.

Una vez concentrada la información en la estación de trabajo forense, se coloca una

identificación de integridad a la información obtenida con la herramienta “md5sum.exe”, como

se muestra a continuación:

113

(forense)c:\WSForense>md5sum datos > datos.sum

Para el caso donde se ejecuta cada comando en forma individual, también se aplica esa misma

herramienta, de la siguiente manera: (forense)c:\WSForense>md5sum timestamp1.txt > timestamp1.sum

114


LINUX CON ACCESO LOCAL

Ahora aplicaremos la metodología sobre la plataforma Linux. La respuesta inicial en un sistema

Linux es similar a la respuesta inicial en Windows, el objetivo es obtener datos volátiles del

sistema antes de proceder a obtener la información estática2 . Las condiciones bajo las cuales se

encuentra el equipo bajo sospecha son que el estado del sistema será “vivo”, estará trabajando

sobre Linux Red Hat Enterprise y el investigador contará con el password de acceso, tal como se

consta en la figura 4.7.

Estado del

sistema

MUERTO VIVO

CASO 2: Windows

CASO 1: Windows


CASO 3: Linux CASO 4:

Linux CASO 5: Grave_robber Linux


(ejemplos)

Fig. 4.7 Caso 3: Aplicación de metodología en Linux con acceso local

El procedimiento se aplicará directamente a la consola del equipo sospechoso estableciendo una

conexión segura en forma local, esto elimina la posibilidad de que el atacante esté monitoreando

la respuesta y asegura que se corran comandos confiables.

Los programas que serán utilizados en esta captura trabajan sobre Linux y no serán instalados en

el sistema bajo análisis, estos correrán desde un CDROM y la información capturada será enviada

a un floppy o USB. 2 La información estática es la información que permanece en el sistema hasta que sea sobrescrita, borrada o destruída como pueden ser archivos de bitácoras, archivos de configuración, sistemas de archivos y que no se pierde al apagar el equipo.

115

PASO 1: LINEA DE COMANDOS SEGURA

Acceder localmente en la consola de la víctima puede evitar la generación de tráfico de red. En

este punto se monta el toolkit confiable y el medio donde se almacenará la información que se

recolecte: # mount /dev/hdc /mnt/fcdrom Para montar un cdrom El primer paso en toda respuesta es estar seguro de que se están ejecutando comandos seguros en

el shell. Los shells de Linux pueden ser alterados (trojaned) por un atacante, que provocan que

los comandos ejecutados realicen operaciones erróneas en los comandos del investigador. Por lo

que será necesario ejecutar un shell seguro también (bash). Una vez ejecutado se direccionarán

todos los comandos a ese shell, colocando la variable de ambiente PATH igual a punto (.),

evitando ejecutar accidentalmente un comando no confiable. Un tip es cambiar el nombre de

nuestros ejecutables confiables para no cometer ese error, por ejemplo en vez de teclear netstat,

tecleamos tnetstat. # /mnt/floppy/bash # /mnt/floppy/PATH=.

# /mnt/cdrom/mount /dev/fd0 /mnt/floppy Para montar el floppy o USB donde almacenar la información. # /mnt/cdrom/mount /dev/sda1 /mnt/memstick

# /mnt/cdrom/mount /dev/sda1 –n vfat /mnt/memstick Especificando en tipo de sistema Los binarios no deben utilizar bibliotecas dinámicas, pero en caso necesario se deberán ligar a

bibliotecas en el CD. Los CD con distribución portable ya contienen herramientas en forma

estática (FIRE, knoppix o Trinux).

PASO 2: REGISTRO DE TIEMPO

Obtener el tiempo y fecha del sistema

Una vez montadas las herramientas obtenemos un registro de tiempo del sistema con el comando

“date”: # /mnt/cdrom/date > /mnt/floppy/date_start.txt Obtener el MAC (Modification, Creation, Access Time) de todos los archivos

116

Una vez que se decide realizar la respuesta inicial, se deben obtener todos los “time/date stamp”

en el sistema de archivos, para eso utilizaremos el comando “ls” con los siguientes argumentos: # /mnt/cdrom/ls –alRu > /mnt/floppy/access_start.txt # /mnt/cdrom/ls –alRc > /mnt/floppy/modification_start.txt # /mnt/cdrom/ls –alR > /mnt/floppy/creation_start.txt PASO 3: ESTADO DEL SISTEMA Para determinar el estado del sistema realizaremos las siguientes acciones:

1. Obtener los procesos corriendo

2. Capturar información del sistema /proc

3. Listar los puertos abiertos y aplicaciones en escucha

4. Respuesta inicial mas profunda

o Detectando y capturando un proceso sospechoso

Acción 1: Listar los procesos corriendo Para obtener todos los procesos corriendo utilizaremos los comandos estándar “ps” o “pstree”. # /mnt/cdrom/pstree –pla > /mnt/floppy/pstree.txt

l= líneas largas, a= argumentos Ejemplo de salida del comando aplicado : init,1 ├─apmd,1624 -p 10 -w 5 -W -P /etc/sysconfig/apm-scripts/apmscript ├─atd,1812 ├─(bdflush,7)* ├─bonobo-activati,1974 --ac-activate --ior-output-fd=16 ├─cardmgr,1600 ├─crond,1773 ├─cupsd,1665 ├─eggcups,1999 --sm-client-id default6 ├─gconfd-2,1971 5 ├─gdm-binary,1832 -nodaemon │ └─gdm-binary,1885 -nodaemon │ ├─X,1886 :0 -auth /var/gdm/:0.Xauth vt7 │ └─gnome-session,1895 │ └─ssh-agent,1961 /etc/X11/xinit/Xclients ├─gnome-panel,1992 --sm-client-id default2 ……… ………

# /mnt/cdrom/ps –Al > /mnt/floppy/procesos.txt La opción Al indica todos los procesos en un formato largo

Ejemplo de salida del comando: UID PID PPID C STIME TTY TIME CMD root 1 0 0 08:01 ? 00:00:04 init root 2 1 0 08:01 ? 00:00:00 [keventd] root 3 1 0 08:01 ? 00:00:00 [kapmd]

117

root 4 1 0 08:01 ? 00:00:00 [ksoftirqd/0] root 7 1 0 08:01 ? 00:00:00 [bdflush] root 5 1 0 08:01 ? 00:00:00 [kswapd] root 6 1 0 08:01 ? 00:00:00 [kscand] root 8 1 0 08:01 ? 00:00:00 [kupdated] root 9 1 0 08:01 ? 00:00:00 [mdrecoveryd] root 13 1 0 08:01 ? 00:00:01 [kjournald] root 68 1 0 08:01 ? 00:00:00 [khubd] root 1495 1 0 08:02 ? 00:00:00 syslogd -m 0 root 1499 1 0 08:02 ? 00:00:00 klogd -x rpc 1525 1 0 08:02 ? 00:00:00 portmap rpcuser 1544 1 0 08:02 ? 00:00:00 rpc.statd root 1600 1 0 08:02 ? 00:00:00 /sbin/cardmgr root 1624 1 0 08:02 ? 00:00:00 /usr/sbin/apmd -p 10 -w 5 -W -P root 1665 1 0 08:02 ? 00:00:01 cupsd root 1705 1 0 08:02 ? 00:00:00 /usr/sbin/sshd root 1719 1 0 08:02 ? 00:00:00 xinetd -stayalive -pidfile /var/ root 1745 1 0 08:02 ? 00:00:00 sendmail: accepting connections smmsp 1754 1 0 08:02 ? 00:00:00 sendmail: Queue runner@01:00:00 root 1764 1 0 08:02 ? 00:00:00 gpm -t ps/2 -m /dev/mouse ... … …

Acción 2: Listar los puertos abiertos y aplicaciones en escucha

En Linux, el comando “netstat” tiene la opción “-p” que mapea el nombre de la aplicación del

proceso, su ID, el puerto, la dirección y si están en escucha: # /mnt/cdrom/netstat –anp > /mnt/floppy/netstat.txt

Ejemplo de salida del comando: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 1544/rpc.statd tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 1719/xinetd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1525/portmap tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 1886/X tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1705/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1665/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1745/sendmail: acce tcp 0 0 127.0.0.1:631 127.0.0.1:32771 ESTABLISHED 1665/cupsd tcp 0 0 127.0.0.1:32771 127.0.0.1:631 ESTABLISHED 1999/eggcups udp 0 0 0.0.0.0:32768 0.0.0.0:* 1544/rpc.statd udp 0 0 0.0.0.0:872 0.0.0.0:* 1544/rpc.statd udp 0 0 0.0.0.0:111 0.0.0.0:* 1525/portmap udp 0 0 0.0.0.0:631 0.0.0.0:* 1665/cupsd Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 2855 1988/metacity /tmp/orbit-root/linc-7c4-0-315ee1028f6b unix 2 [ ACC ] STREAM LISTENING 3067 2009/notification-a /tmp/orbit-root/linc-7d9-0-50b626573cc46 unix 2 [ ACC ] STREAM LISTENING 3095 2003/python /tmp/orbit-root/linc-7d3-0-43893ea45b517 unix 2 [ ACC ] STREAM LISTENING 2885 1992/gnome-panel /tmp/orbit-root/linc-7c8-0-7c0eafdf5ddba unix 2 [ ACC ] STREAM LISTENING 2906 1996/magicdev /tmp/orbit-root/linc-7cc-0-7c0eafdf867db unix 2 [ ACC ] STREAM LISTENING 2924 1994/nautilus /tmp/orbit-root/linc-7ca-0-6e5ddaca9702b unix 2 [ ACC ] STREAM LISTENING 2943 1999/eggcups /tmp/orbit-root/linc-7cf-0-6e5ddacae056c unix 2 [ ACC ] STREAM LISTENING 2627 1886/X /tmp/.X11-unix/X0 unix 2 [ ACC ] STREAM LISTENING 2617 1832/gdm-binary /tmp/.gdm_socket

118

Acción 3: Listar los archivos abiertos Se ejecuta “lsof” para localizar procesos sospechosos, lsof lista todos los procesos corriendo y los

descriptores de archivos que abren los procesos. # /mnt/cdrom/lsof > /mnt/floppy/lsof.txt

Ejemplo de salida del comando: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME portmap 1522 rpc 3u IPv4 1631 UDP *:sunrpc portmap 1522 rpc 4u IPv4 1634 TCP *:sunrpc (LISTEN) rpc.statd 1541 rpcuser 4u IPv4 1668 UDP *:32768 rpc.statd 1541 rpcuser 5u IPv4 1658 UDP *:869 rpc.statd 1541 rpcuser 6u IPv4 1671 TCP *:32768 (LISTEN) cupsd 1662 root 2u IPv4 2235 UDP *:ipp cupsd 1662 root 3u IPv4 3039 TCP pegaso:ipp->pegaso:32771 (ESTABLISHED) sshd 1702 root 3u IPv4 2256 TCP *:ssh (LISTEN) xinetd 1716 root 5u IPv4 2297 TCP pegaso:32769 (LISTEN) sendmail 1742 root 4u IPv4 2406 TCP pegaso:smtp (LISTEN) X 1883 root 1u IPv4 2604 TCP *:x11 (LISTEN) fam 1978 root 0u IPv4 2297 TCP pegaso:32769 (LISTEN) fam 1978 root 1u IPv4 2297 TCP pegaso:32769 (LISTEN) ggcups 1996 root 14u IPv4 3038 TCP pegaso:32771->pegaso:ipp (ESTABLISHED) Como “lsof “ muestra los archivos abiertos , también se puede utilizar para identificar programas

sniffer ilícitos utilizando cuentas y passwords válidos robados. El atacante no querrá sobrescribir

los datos que ha capturado, por lo que los archivos serán fáciles de obtener[36].

Capturando información del sistema de archivos /PROC

El sistema de archivos /proc es un pseudo sistema que es usado como una interfaz a la estructura

de datos del kernel. Cambiándose al directorio /proc realmente se está accediendo a las

estructuras de datos del kernel, no a un directorio verdadero. Cada proceso tiene un subdirectorio

en /proc que corresponde a su ID. Por lo que cada proceso corriendo tendrá un subdirectorio

numérico. El sistema de archivos /proc es prácticamente la representación de todo nuestro

sistema en texto, los archivos y directorios bajo /proc contienen datos sobre cantidad de memoria,

procesos que están corriendo en el sistema y sockets. # /mnt/cdrom/ls /proc > /mnt/floppy/proc.txt

Ejemplo de salida del comando: 1 13 1492 1496 1522 1541 1597 1621 1662 1702 1716 1742 1751 1761 1770 1800 1809 1823 1824 1825 1826 1827 1828 1829 1882 1883 1892 1958 1968 1971 1973 1978 1985 1989 1991 1993 1996 1998 2 2000 2001 2006 2008 2009 2010 2054 3 4 5 6 68 7 8 9 apm bus cmdline cpuinfocrypto devices dma driver exec domains fb filesystems fs ide interrupts iomem ioports irq kcore kmsg ksyms loadavg locks mdstat meminfo misc modules mounts mtrr net partitions pci self slabinfo stat swaps sys sysrq-trigger sysvipc tty uptime version

119


Detectando y capturando un proceso sospechoso

En el caso de contar con tiempo para capturar información en vivo, podemos obtener información

de un proceso identificado como sospechoso, en el siguiente orden:

1) Identificar el proceso sospechoso

2) Listar el ID en el FS /proc/<pid>

3) Copiar el archivo binario

4) Identificar la línea de comandos del proceso

Ejemplo:

1.- Identificamos el proceso sospechoso con el comando “ps” #ps –aux UID PID PPID C STIME TTY TIME CMD root 1 0 0 08:01 ? 00:00:04 init root 2 1 0 08:01 ? 00:00:00 [keventd] root 3 1 0 08:01 ? 00:00:00 [kapmd] root 970 1 0 08:02 ? 00:00:00 proc_sosp rpc 1525 1 0 08:02 ? 00:00:00 portmap rpcuser 1544 1 0 08:02 ? 00:00:00 rpc.statd root 1600 1 0 08:02 ? 00:00:00 /sbin/cardmgr root 1624 1 0 08:02 ? 00:00:00 /usr/sbin/apmd -p 10 -w 5 -W -P

2.- Nos cambiamos al directorio /proc del ID del proceso #cd /proc/970 #ls -al total 0 dr-xr-xr-x 3 root root 0 Oct 10 10:33 . dr-xr-xr-x 68 root root 0 Oct 10 03:01 .. -r--r--r-- 1 root root 0 Oct 10 10:41 cmdline lrwxrwxrwx 1 root root 0 Oct 10 10:41 cwd -> / -r-------- 1 root root 0 Oct 10 10:41 environ lrwxrwxrwx 1 root root 0 Oct 10 10:41 exe dr-x------ 2 root root 0 Oct 10 10:41 fd -r--r----- 1 root root 0 Oct 10 10:41 maps -rw------- 1 root root 0 Oct 10 10:41 mem -r--r--r-- 1 root root 0 Oct 10 10:41 mounts lrwxrwxrwx 1 root root 0 Oct 10 10:41 root -> / -r--r--r-- 1 root root 0 Oct 10 10:41 stat -r--r--r-- 1 root root 0 Oct 10 10:41 statm -r--r--r-- 1 root root 0 Oct 10 10:41 status 3.- Copiamos el archivo binario. La información más significativa se puede encontrar en el

directorio “fd”, la liga “exe” y el archivo “cmdline”.

120

La liga exe permite al investigador recuperar los archivos borrados que aún siguen corriendo. Por

ejemplo, si se ejecutó el siguiente comando: # rm /root/ir/proc_sosp rm: remove ‘/root/ir/proc_sosp?y Aunque se haya removido el programa sospechoso, éste está ligado al sistema de archivos. El

comando “ls” no mostrará el archivo en el FS, sin embargo, en el contenido del directorio

/proc/970, se verá la siguiente salida: 970# ls –al lrwx------- 1 root root 0 Apr 5 20:13 exe -> /root/ir/proc_sosp (deleted). Se puede usar el comando “cp” para crear una copia del ejecutable corriendo en el sistema de

archivos.

En el subdirectorio “fd” (file descriptor), se pueden identificar todos los procesos que un archivo

ha abierto. Cuando el kernel de Linux, abre, lee, escribe o crea un archivo o socket de red, este

regresa un “file descriptor” (un entero positivo) que es usado para referenciar el archivo o socket

de red. Se pueden ignorar los fd 0, 1 y 2 que son “file descriptors” predefinidos para la salida o

entrada estándar. fd# ls –la lrwx------- 1 root root 64 Apr 5 20:12 1 -> /dev/pts/4 lrwx------- 1 root root 64 Apr 5 20:12 4 -> socket: [1359] El archivo “cmdline” muestra los argumentos exactos de la línea de comandos usados para correr

dicha aplicación. Normalmente, este es desplegado cuando un usuario ejecuta un comando “ps”.

Para desplegar su contenido tecleamos: # cat cmdline nautilus --no-default-window --sm-client-id default3

PASO 4: QUIEN ESTÁ EN EL SISTEMA

Determinar quien está en el sistema es un poco más simple. Solo ejecutamos el comando “w”

(what), y desplegará los IDs de usuarios conectados, de que sistemas están entrando y que están

ejecutando. También provee la hora y fecha del sistema: # /mnt/cdrom/w > /mnt/floppy/w.txt Ejemplo de salida del comando

121

11:01:55 up 3:00, 3 users, load average: 0.08, 0.04, 0.04 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root :0 - 8:02am ? 0.00s 0.94s /usr/bin/gnome- root pts/0 :0.0 8:04am 0.00s 2.98s 0.04s w root pts/1 :0.0 10:11am 48:33 0.23s 0.23s bash La línea de cabecera indica la hora actual del sistema, cuánto tiempo el sistema ha estado arriba y

cuántos usuarios están actualmente conectados

El comando para determinar si la interfaz está en modo promiscuo es “ifconfig”: # /mnt/cdrom/ifconfig –a > /mnt/floppy/ifconfig.txt Ejemplo de salida del comando: eth0 Link encap:Ethernet HWaddr 00:00:39:77:E3:C6 inet addr:172.29.69.111 Bcast:172.29.69.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3088 errors:0 dropped:0 overruns:0 frame:0 TX packets:174 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:338230 (330.3 Kb) TX bytes:67384 (65.8 Kb) Interrupt:11 Base address:0xef40 Memory:f7efe000-f7efe038 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3503 errors:0 dropped:0 overruns:0 frame:0 TX packets:3503 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:364926 (356.3 Kb) TX bytes:364926 (356.3 Kb)

Si la tarjeta se descubre en modo promiscuo, se puede suponer que existe un sniffer en el sistema

bajo análisis que eleva la severidad del ataque. Esto sugiere que el sistema comprometido no es

únicamente ese, también significa que el atacante tiene acceso a nivel de root [36].

Para obtener el nombre del sistema y el tiempo que ha estado levantado tecleamos los siguientes

comandos: # /mnt/cdrom/hostname > /mnt/floppy/hostname.txt # /mnt/cdrom/uptime > /mnt/floppy/uptime.txt

PASO 5: DESCARGA DE MEMORIA

En el caso de Linux a diferencia de Windows no es necesario reiniciar el equipo para obtener una

copia de la memoria RAM, por lo que en este caso intercambiamos el paso 5 por el paso 6.

122

No existen muchas formas de descargar la memoria RAM en máquinas Linux. Normalmente se

transfiere el archivo /proc/mem o /proc/kcore del sistema bajo análisis. Este archivo contiene el

sistema RAM en un arreglo no continuo.

El comando dd es parte de el paquete fileutils de Red Hat, lo podemos utilizar para crear una

imagen o copia exacta de un archivo. Para copiar directamente el dispositivo de memoria

utilizamos la siguiente sintaxis: # mnt/cdrom/dd if=/dev/mem of=/dev/fd0/image_memory

129024+0 records in 129024+0 records out

# ls –l image_memory -rw-r--r-- 1 root 66060288 Sep 25 18:27 image_memory El tipo de archivo obtenido no se puede leer con un “cat” normal, pero se puede utilizar el

comando “string” para obtener los caracteres entendibles y mandarlos a un archivo que después

podamos analizar con tiempo. # string image_memory > resultado Utilizando GDB para capturar memoria

GDB puede estar ejecutándose en la misma máquina o remotamente, en algún dispositivo externo

de solo lectura.

Para invocar gdb: [root@luna gdb-6.0]# gdb GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". (gdb) Dentro de GDB los comandos dump, append y restore copian datos entre memoria y archivos.

Los comandos dump y append escriben datos a un archivo, y el comando restore lee los datos del

archivo para regresarlos a memoria. Los archivos pueden estar en formato binario. (gdb) dump memory descarga 0x00000 0xFFFFF

123

El comando anterior vacía el contenido de la memoria desde start_addr (0x00000) hasta

end_addr(0xFFFFF).

PASO 6: REGISTRO DE TIEMPO

Nuevamente como en el paso 2 volvemos a tomar el registro de tiempo del sistema y de los

archivos, para saber que archivos pudimos haber modificado durante la recolección de

información: # /mnt/cdrom/date > /mnt/floppy/date_end.txt # /mnt/cdrom/ls –alRu > /mnt/floppy/access_end.txt # /mnt/cdrom/ls –alRc > /mnt/floppy/modification_end.txt # /mnt/cdrom/ls –alR > /mnt/floppy/creation_end.txt PASO 7: DOCUMENTACION

La tabla 4.4 muestra los pasos que se siguieron y los programas que se utilizaron para llevar a

cabo cada paso. Esto nos ayudará a documentar todos los pasos realizados:


Pasos Acciones Comandos

Linux 1 Línea de comandos seguros Montar el CD con las herramientas

Establecer un nuevo shell Definir rutas de binarios y librerías seguros

mount bash PATH

2 Registro de Tiempo Obtener el tiempo y fecha del sistema Obtener el MAC de todos los archivos

date ls

Listar los procesos que corren actualmente Listar los procesos que corren actualmente Obtener los puertos abiertos Listar los archivos abiertos Capturando información en el FS proc

pstree ps netstat lsof /proc

Para un solo proceso sospechoso

3 Estado del sistema

Listar los procesos Identificar el ID en el FS /proc Copiar el archivo binario Identificar las líneas de comandos del proceso

ps –aux /proc/ID /proc/ID/exe /proc/ID/cmdline

4 Quien esta en el sistema Determinar quien está dentro del sistema Información de la tarjeta de red Nombre del equipo Tiempo que el sistema ha estado levantado

w ifconfig hostname uptime

5 Copia de la memoria Captura de la memoria física dd, /dev/mem dd, /dev/kmem

6 Registro de tiempo Obtener el tiempo y fecha del sistema Time stamp, tiempo de creación de los archivos

date ls

124

Pasos Acciones Comandos Linux

7 Documentación Identificar y documentar los pasos Registro de integridad Automatizar la recolección

md5 bash script

Registro de integridad

A cada uno de los comandos aplicados se le debe generar un registro de integridad de la

evidencia original para validarla. Para lo cual podemos utilizar “md5sum”: # /mnt/cdrom/md5sum image_mem 166e20b346bff5b030cbf07b3f4963718 image_mem

Automatizar la recolección

En este caso también se puede realizar un script que automatice todos los pasos realizados y la

recolección de información sea más rápida. Lo importante es estar seguro de que cualquier

archivo creado o copiado por un script esté en un medio seguro.

Para realizar un script en Linux creamos el siguiente archivo: # !/bin/bash # SCRIPT DE RECOLECCIÓN DE INFORMACIÓN # PASO 2: REGISTRO DE TIEMPO /mnt/cdrom/date > /mnt/floppy/date_start.txt /mnt/cdrom/md5sum date_start.txt > date_start.md5 /mnt/cdrom/ls –alRu > /mnt/floppy/access_start.txt /mnt/cdrom/md5sum access_start.txt > access_start.md5 /mnt/cdrom/ls –alRc > /mnt/floppy/modification_start.txt /mnt/cdrom/md5sum modification_start.txt > modification_start.md5 /mnt/cdrom/ls –alR > /mnt/floppy/creation_start.txt /mnt/cdrom/md5sum creation_start.txt > creation_start.md5 # PASO 3: ESTADO DEL SISTEMA /mnt/cdrom/pstree –pla > /mnt/floppy/pstree.txt /mnt/cdrom/md5sum pstree.txt > pstree.md5 /mnt/cdrom/ps –Auxw > /mnt/floppy/procesos.txt /mnt/cdrom/md5sum procesos.txt > procesos.md5 /mnt/cdrom/netstat –anp > /mnt/floppy/netstat.txt /mnt/cdrom/md5sum netstat.txt > netstat.md5 /mnt/cdrom/lsof > /mnt/floppy/lsof.txt /mnt/cdrom/md5sum lsof.txt > lsof.md5 /mnt/cdrom/ls /proc > /mnt/floppy/proc.txt /mnt/cdrom/md5sum proc.txt > proc.md5 # PASO 4: QUIEN ESTA EN EL SISTEMA /mnt/cdrom/w > /mnt/floppy/w.txt /mnt/cdrom/md5sum w.txt > w.md5 /mnt/cdrom/ifconfig –a > /mnt/floppy/ifconfig.txt /mnt/cdrom/md5sum ifconfig.txt > ifconfig.md5 /mnt/cdrom/hostname > /mnt/floppy/hostname.txt

125

/mnt/cdrom/md5sum hostname.txt > /mnt/floppy/hostname.md5 /mnt/cdrom/uptime > /mnt/floppy/uptime.txt /mnt/cdrom/md5sum uptime.txt > /mnt/floppy/uptime.md5 # PASO 5: COPIA DE MEMORIA /mnt/cdrom/dd if=/dev/mem of=/dev/fd0/image_memory.txt /mnt/cdrom/md5sum image_memory.txt > image_memory.md5 # PASO 6: REGISTRO DE TIEMPO /mnt/cdrom/date > /mnt/floppy/date_end.txt /mnt/cdrom/md5sum date_end.txt > date_end.md5 /mnt/cdrom/ls –alRu > /mnt/floppy/access_end.txt /mnt/cdrom/md5sum access_end.txt > access_end.md5 /mnt/cdrom/ls –alRc > /mnt/floppy/modification_end.txt /mnt/cdrom/md5sum modification_end.txt > modification_end.md5 /mnt/cdrom/ls –alR > /mnt/floppy/creation_end.txt /mnt/cdrom/md5sum creation_end.txt > creation_end.md5 El script contiene todos y cada uno de los pasos ejecutados, esto también puede ser una referencia

de documentación del proceso.

126


LINUX A TRAVÉS DE RED

Las condiciones bajo las cuales se aplicará la metodología en este caso serán sobre un sistema

vivo, el tipo de acceso que se tendrá al sistema será local y la información se recolectará a través

de la red, el sistema operativo con el que se enfrentará el investigador será Linux Red Hat

Enterprise y se contará con el password de acceso. La siguiente figura muestra el tipo de caso a

tratar.

Estado del

sistema

MUERTO VIVO

CASO 2: Windows

Captura de paquetes

Analizador

CASO 1: Windows


CASO 3: Linux

CASO 4: Linux



(ejemplos)

Fig. 4.8 Caso 4: Aplicación de la metodología a través de la red con Linux

El equipo bajo sospecha puede ser un servidor o estación de trabajo conectado a red, por lo que la

información recolectada puede ser enviada a través de la red misma a una estación segura,

complementando la información con un equipo analizador de paquetes conectado a la misma red,

como se observa en la figura 4.9. Equipo comprometido

Linux

Conexión segura

Fig. 4.9 Diagrama de conexión: Caso 4

Monitor de red

o o o o o o o o

Linux

Estación forense

Investigador forense

127

Por lo que en este caso se conectarán dos equipos seguros la estación forense para recopilar

información y el equipo de monitoreo que en forma paralela estará capturando los paquetes que

circulen por la red.

MONITOREO DE RED

Para obtener datos de un sistema vivo, podemos correr un analizador de paquetes de red (network

sniffer) y observar el flujo de información para y desde el equipo comprometido, así, podemos

detectar algún tipo de actividad maliciosa, grabando y analizando en tiempo real su

comunicación.

Para capturar el tráfico del equipo sospechoso configuramos el switch donde esta conectado el

equipo para que envíe una copia del tráfico de ese puerto al puerto donde tenemos colocado

nuestro analizador de red. Para que esto se pueda realizar el switch debe tener disponible en los

puertos la técnica “Port Mirror” para que se pueda realizar esta acción.

El analizador de red que podemos utilizar es Ethereal que viene instalado en la versión de Red

Hat con la que estamos trabajando, a continuación presentamos las ventanas para correr una

captura de paquetes. Toda esta información puede ser guardada a un archivo que puede analizarse

posteriormente:

Fig. 4.10 Pantallas Ethereal

128

Fig. 4.10 Pantallas Ethereal

Una vez mostrada la forma de obtener los datos a través de un equipo de monitoreo podemos

empezar a aplicar los pasos de la metodología planteada:

PASO 1: ESTABLECIENDO UNA CONEXIÓN SEGURA

En este paso primero haremos disponible el conjunto de herramientas confiable, éste se montará

en el sistema comprometido. Por lo que vamos a usar el comando “mount” no confiable de ese

sistema para realizar esta tarea, esperando que sea el único comando no confiable que habremos

de correr.

Para verificar el impacto que el comando “mount” tendrá en el sistema podemos utilizar el

comando “strace” del sistema operativo que nos ayuda a identificar los archivos y directorios que

son modificados al aplicar el comando “mount”: #strace /bin/mount /mnt/cdrom execve("/bin/mount", ["/bin/mount", "/mnt/cdrom"], [/* 32 vars */]) = 0 uname({sys="Linux", node="pegaso", ...}) = 0 brk(0) = 0x8059cc0 open("/etc/ld.so.preloadopen("/etc/ld.so.cache", O_RDONLY) = 3

", O_RDONLY) = -1 ENOENT (No such file or directory)

fstat64(3, {st_mode=S_IFREG|0644, st_size=65998, ...}) = 0 old_mmap(NULL, 65998, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75da000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 ..

129

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 .. lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=156, ...}) = 0 .. open("/etc/fstab", O_RDONLY|O_LARGEFILE) = 3 .. mount("/dev/cdrom", "/mnt/cdrom", "udf", MS_RDONLY|MS_NOSUID|MS_NODEV|0xc0ed0000, 0x805bb20) = -1 ENODEV (No such device)

Concluimos que los archivos que se modifican son: /etc/ld.so.cache /lib/tls/libc.so.6 /usr/lib/locale-archive /etc/fstab /etc/mtab /dev/cdrom /bin/mount Es evidente que este procedimiento debe haberse realizado antes de aplicar la metodología en una

investigación.

Como ya sabemos los archivos que se modificarán al utilizar el comando “mount” no confiable,

procedemos a montar el CDROM con el toolkit creado: (comprometido)# mount –n /mnt/cdrom La opción –n monta sin escribir en el archivo /etc/mtab.

Una vez montado el CD con las herramientas establecemos un shell seguro: (host comprometido) # /mnt/cdrom/./bash (host comprometido) # /mnt/cdrom/PATH=.

PASO 2: REGISTRO DEL TIEMPO

Enviamos información de la fecha y hora del sistema comprometido a la estación forense que

almacenará los datos (en este caso 192.29.69.69) a través de “netcat” por el puerto 2222 como

sigue: (forense) # nc –l –p 2222 > datos_recolectados En el host comprometido aplicamos los comandos, direccionándo la salida a la estación forense: (comprometido)# /mnt/cdrom/statbins/./date | /mnt/cdrom/./nc 192.29.69.69 2222 Para mantener la integridad de la evidencia digital, calculamos el valor “hash” del archivo

recolectado.

130

(forense)# md5sum datos_recolectados > datos_recolectados.md5 Para tomar la hora del sistema utilizamos el mismo comando “date” con la opción “-u”, el

resultado es presentado en el formato UTC (Coordinated Universal Time) (forense) # nc –l –p 2222 > start_time (comprometido)# /mnt/cdrom/statbins/./date –u | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum start_time > start_time.md5 A continuación tomamos una referencia de tiempo de todos los archivos en el sistema (time

stamp) con el comando “mactime” para tener un control de lo que habremos de modificar en la

recolección de información: (forense) # nc –l –p 2222 > mactime.txt (comprometido)# /mnt/cdrom/statbins/./mactime –y –R –d / /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum mactime.txt > mactime_txt.md5 También lo podemos hacer con el comando “ls” con sus opciones “c” que muestra modificación

del inodo, “u” del último acceso y sin parámetro la fecha de modificación del estado del archivo

o de creación del archivo. (forense)# nc -l -p 2222 > maChange (comprometido)#/mnt/cdrom/statbins/./ls –lRc / | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense)# md5sum maChange > maChange.md5 (forense)# nc -l -p 2222 > mAccesc (comprometido)#/mnt/cdrom/statbins/./ls –lRu / | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense)# md5sum mAccesc > mAccesc.md5 (forense)# nc -l -p 2222 > Modifyac (comprometido)#/mnt/cdrom/statbins/./ls –lR / | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense)# md5sum Modifyac > Modifyac.md5

PASO 3: ESTADO DEL SISTEMA

Acción 1: La lista de los procesos activos

La información acerca de los procesos, puertos y archivos abiertos puede ser recolectada por la

herramienta “lsof”. (forense)# nc -l -p 2222 > lsof (comprometido)#/mnt/cdrom/statbins/./lsof -n -P -l | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense)# md5sum lsof > lsof.md5

Acción 2: Listar los módulos cargados en la memoria del kernel de un SO

131

Listar el directorio “modules” dentro de /proc nos puede servir para observar qué módulos están

cargados en memoria y poder detectar si tenemos un rootkit instalado. Algunas veces los rootkits

débiles pueden exportar sus símbolos, que se encuentran en el directorio “ksyms” de /proc por lo

que procedemos a obtener todo el sistema /proc de la siguiente manera:

(forense)#nc -l -p 2222 > proc (comprometido)#/mnt/cdrom/statbins/./cat /proc | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense)# md5sum proc > proc.md5

Acción 3: Nombre y tiempo del sistema Para obtener el nombre del sistema utilizamos el comando hostname

(forense) # nc –l –p 2222 > hostname (comprometido)# /mnt/cdrom/statbins/./hostname | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum hostname > hostname.md5

Para obtener el tiempo que ha estado levantado el sistema utilizamos el comando uptime:

(forense) # nc –l –p 2222 > uptime (comprometido)# /mnt/cdrom/statbins/./uptime | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum uptime > uptime.md5


Recolectando un proceso sospechoso

Si algunos de los procesos activos son sospechosos podemos obtener información específica de

ese proceso o tal vez recuperarlo. Copiando un proceso particular podemos separar de mejor

manera los datos maliciosos de la memoria del sistema comprometido

El primer paso es listar los procesos que están corriendo: (comprometido)#/mnt/cdrom/statbins/./ps -aux

Con “lsof” podemos listar las conexiones y archivos abiertos por el proceso:

(comprometido)#/mnt/cdrom/statbins/./lsof -p proc_id

Observar el proceso, registrando las llamadas a sistema y señales del proceso

(comprometido)#/mnt/cdrom/statbins/./strace -p proc_id

Registrar las llamadas a rutinas (librerías) que realiza el proceso

132

(comprometido)#/mnt/cdrom/statbins/./ltrace -p proc_id

Una vez identificado el proceso sospechoso. Utilizamos la herramienta “pcat” para copiar la

memoria del proceso. (comprometido)#/mnt/cdrom/statbins/./pcat proc_id > mem_proces_ID.txt

PASO 4: QUIEN ESTÁ EN EL SISTEMA

Información de Cache

Primero recolectamos información de la tabla cache por el tiempo de vida de estos datos (que es

muy corto). Recolectamos datos de las tablas de ruteo y arp.

Tabla cache de direcciones MAC: (forense) # nc –l –p 2222 > arp (comprometido) # /mnt/cdrom/statbins/./arp –an | mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum arp > arp.md5 Tabla cache del ruteo IP del Kernel: (forense) # nc –l –p 2222 > route (comprometido) # /mnt/cdrom/statbins/./route –Cn | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum route > route.md5 C=Operar en el cache de ruteo del Kernel N=Mostrar las direcciones numéricas

Conexiones actuales, pendientes y puertos TCP/UDP abiertos

Recolectamos las conexiones y puertos abierto con el comando “netstat”: (forense) # nc –l –p 2222 > netstat.txt (comprometido) # /mnt/cdrom/statbins/./netstat –an | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum netstat.txt > netstat_txt.md5

También se puede utilizar el comando “cat” en vez de “netstat” con la información de puertos

abiertos que es almacenada en el sistema de archivos proc (Archivos: /proc/net/tcp y

/proc/net/udp). La información de la conexiones activas se encuentra en el archivo

/proc/net/netstat. Todos los datos en estos archivos se presentan en formato hexadecimal, por

ejemplo la dirección 0100007F:0401 en decimal es 127.0.0.1:1025. Las conexiones activas

también pueden ser detectadas por el analizador de tráfico.

133

Para obtener la dirección de red tecleamos lo siguiente: (forense) # nc –l –p 2222 > ifconfig (comprometido)# /mnt/cdrom/statbins/./ifconfig -a | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum ifconfig > ifconfig.md5

PASO 5: IMAGEN DE MEMORIA

Se puede obtener la memoria física copiando directamente el dispositivo /dev/mem como lo

hicimos en el caso anterior, pero también podemos hacerlo a través del archivo kcore. Este

archivo representa la RAM en un sistema operativo Linux, es encontrado en el directorio /proc,

su tamaño es igual al de la memoria física, la ventaja de utilizar kcore es que este archivo tiene

formato ELF, por lo que puede ser depurado fácilmente con la herramienta “gdb”.

Utilizar una computadora remota como en este caso puede ser la mejor manera de salvar datos

con un mínimo de modificación sobre la memoria. (remoto)# nc -l -p 2222 > kcore (comprometido)# /mnt/cdrom/statbins/./dd < /proc/kcore | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (remoto)# md5sum kcore > kcore.md5

Cuando copiamos todo el sistema de memoria, se copian los datos colocados y los no colocados

(allocated/unallocated) porque el proceso copia la imagen entera de la memoria física.

También se puede utilizar memdump para obtener una imagen de la memoria sin reinicializar el

sistema y puede ser transferido por la red con netcat o ssl: (forense)# nc -l -p 2222 > memdump (comprometido)# /mnt/cdrom/statbins/./memdump | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense)# md5sum memdump > memdump.md5

Sintaxis para ssl: (forense)# memdump | openssl s_client –connect host:port

También podemos copiar la información en la memoria swap. La forma más fácil de copiar este

tipo de memoria es con un “cat” o “dd” al dispositivo de archivos en cuestión. (forense)# /mnt/cdrom/statbins/./swapon –s Filename Type Size Used Priority /dev/hda3 partition 449812 0 -1 (forense)# /mnt/cdrom/statbins/./cat /dev/hda3 >> swap_cap.file

134

PASO 6: 2º. REGISTRO DE TIEMPO

Después de finalizar la recolección de información, nuevamente registramos la hora del sistema. (forense)#nc -l -p 2222 > end_time (comprometido)# /mnt/cdrom/statbins/./date | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 Para tomar un registro de tiempo de todos los archivos utilizamos los comandos “ls” o “mactime”

como lo hicimos en el paso 2. (forense) # nc –l –p 2222 > end_time (comprometido)# /mnt/cdrom/statbins/./date –u | /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum start_time > end_time.md5 (forense) # nc –l –p 2222 > mactime_end (comprometido)# /mnt/cdrom/statbins/./mactime –y –R –d / /mnt/cdrom/statbins/./nc 172.29.69.69 2222 (forense) # md5sum mactime.txt > mactime_end.md5

En este punto podemos desconectar de la energía el equipo comprometido. Recordando que no se

deberá utilizar “shut down” o “init”. Deberemos desconectar el cable directamente de la

alimentación de energía.

PASO 7: DOCUMENTACIÓN

La tabla 4.5 muestra los pasos que se siguieron y los programas que se utilizaron y con esta tabla

podemos a empezar a documentar todas nuestras acciones: Tabla 4.5 Pasos y acciones realizadas: Caso 4 Pasos Acciones Comandos

Linux Información obtenida vía la red

Obtener información de red Detectar tráfico anómalo

ethereal

Información obtenida localmente 1 Estableciendo una conexión

al sistema Montar el conjunto de herramientas Obtener un shell seguro

mount bash

2 Registro de tiempo Obtener el tiempo y fecha del sistema Time stamp de los archivos Time stamp, tiempo de creación de los archivos

date mactime ls

3 Quien esta en el sistema Información de cache Listar las conexiones y puertos abiertos Desplegar direcciones IP y físicas

arp route netstat ifconfig

4 Estado del sistema Listar los procesos activos Listar los módulos cargados

lsof cat /proc/modules

135

Pasos Acciones Comandos Linux

Símbolos exportados por el modulo kernel Nombre del equipo Tiempo que el sistema ha estado levantado

cat /proc/ksyms hostname uptime

Para un solo proceso sospechoso Listar los procesos que corren Lista las conexiones y archivos abiertos Observar el proceso Registrar las llamadas a rutinas (librerías) Copiar el contenido de la memoria del proceso

ps-aux lsof –p PID strace –p PID ltrace –p PID pcat

5 Información de la memoria Obtener una copia de la memoria Obtener una copia de la memoria swap

dd /proc/kcore memdump swapon

6 Registro de tiempo Obtener el tiempo y fecha del sistema Registro de tiempo de todos los archivos

date mactime

7 Documentación Documentar los pasos Nuestro siguiente paso es documentar la información obtenida del sistema comprometido. Esta

información es necesaria para preparar una descripción propia del incidente y realizar una copia

de todo el sistema de archivos. Recordando que todos los resultados tienen que ser enviados a la

estación forense remota. La tabla 4.6 es un resumen de los comandos que conjuntan esa

información:

Tabla 4.6 Documentando: Caso 4

Confiable

Salida del md5sum

Tiempo de inicio

Acción Comando aplicado Archivo generado

SI

NO

9:19:20 Montar el CD

mount –n /mnt/cdrom

X

9:22:23 Abrir un shell

/mnt/cdrom/statbins/./bash X

9:23:24 Tomar la hora del sistema

/mnt/cdrom/statbins/./date -u start_time X 7122f802e1a087a0b31848f70862c0d1

9:24:00 Registros MAC de archivos

/mnt/cdrom/statbins/./mactime –y –R –d /

Mactime X aec67122f802e1a08727bfa628447285

9:24:25 Modificaciones del inodo del archivo

/mnt/cdrom/statbins/./ls –lRc maChange X 89caa702e08cc48301657924f0263cca

9:25:26 Acceso al archivo

/mnt/cdrom/statbins/./ls –lRa mAccesc X cdd5870ee16c460a702e08cc48a70ccc

136

Confiable

Salida del md5sum

Tiempo de inicio

Acción Comando aplicado Archivo generado

SI

NO

9:26:27 Modificaciones del estado del archivo

/mnt/cdrom/statbins/./ls –lRs Modifyac X 301657924f0263c7122f802e1a087ade

9:27:28 Direcciones MAC

/mnt/cdrom/statbins/./arp –an

arp.md5

X 472854960acebf27baec629ba5184cef

9:27:40 Ruteo IP

/mnt/cdrom/statbins/./route –Cn

route.md5

X 85027bfa628492be1743953719ba8146

9:28:00 Conexiones y puertos abiertos

/mnt/cdrom/statbins/./netstat –an

netstat.txt

X 2849174ab4395ca63859b1284629aef9

9:28:17 Dirección de red

/mnt/cdrom/statbins/./ifconfig -a ifconfig X caa702e08cc4802e08cc487122f8 70

9:28:29 Procesos activos

lsof -n -P -l lsof X 702e08cc48a702e08cc487122f870aaf

9:29:18 Módulos cargados

cat /proc/modules

lkms

X 116798d3a85f14acdd5870ee16c4608d

9:30:30 Símbolos del kernel

cat /proc/ksyms ksyms X e08cc48301657924f0263ca702e08cc48

9:31:29 Nombre del equipo

/mnt/cdrom/statbins/./hostname hostname X Cc482e1a087a301657924f0263c22f8e

9:32:22 Tiempo de trabajo del sistema

/mnt/cdrom/statbins/./uptime uptime X Ca89caa702e08cc48a702e022f802e 88

9:33:24 Copia de memoria

/mnt/cdrom/statbins/./dd < /proc/kcore

kcore X C2e1a087a7022f802e2e08cc487122f8

9:33:24 Copia de memoria

/mnt/cdrom/statbins/./memdump memdump X C2e1a087a7022f802e2e08cc487122f8

9:50:33 Registro de hora

/mnt/cdrom/statbins/./date end_time X caa702e08cc48301657924f0222f802e

9:53:00 Registro de tiempo de los archivos

/mnt/cdrom/statbins/./mactime mactime_end

X 08cc41653919ae30581bcf1938284677

137

4.6 RECOLECCIÓN DE INFORMACIÓN CON GRAVE-ROBBER: CASO 5

En este caso vamos a aplicar la herramienta forense “grave-robber” de TCT sobre un sistema

“vivo” a través de un acceso local directo en la consola del equipo sospechoso. La figura 4.11

muestra el tipo de caso a tratar:

Estado del

sistema

MUERTO VIVO

CASO 2: Windows

CASO 1: Windows


CASO 3: Linux

CASO 4: Linux

CASO 5: Grave_robberLinux


(ejemplos)

Fig. 4.11 Caso 5: Herramientas forenses “grave robber”

Se trabajará bajo las siguientes condiciones:

• El procedimiento se aplicará a un sistema vivo antes de quitar la energía eléctrica.

• Se accederá al sistema a través de la consola del sistema y no a través de la red.

• El investigador forense se conectará al equipo sospechoso estableciendo una conexión

segura en forma local.

• El sistema operativo del equipo comprometido es Linux (Red Hat Enterprise 3.0)

• Se cuenta con el password de acceso.

• La herramienta forense de captura será “grave-robber” que corre desde un floppy y los

archivos generados serán copiados a una memoria USB.

Las herramientas forenses ya traen incluida su metodología a seguir y sus scripts de recopilación

de información como se mencionó en el capitulo 3. Por lo que los pasos 2, 3, 4, 5 y 6 de la

metodología se realizarán en este caso en un solo paso.

138

PASO 1: ESTABLECIMIENTO DE UNA CONEXIÓN SEGURA

El primer paso será montar la herramienta: (comprometido)# mount /dev/fd0 /mnt/floppy Una vez montado el medio con las herramientas establecemos un shell seguro: (comprometido) # /mnt/floppy/./bash (comprometido) # /mnt/floppy/PATH=.

Montamos el medio donde se almacenará la información, puede ser el mismo donde tenemos la

herramienta, pero en nuestro caso utilizaremos un stick de memoria: (comprometido)# mount /dev/sda1 –t vfat /mnt/memstick

Se debe tomar en cuenta que puede que no esté creado el directorio memstick en /mnt

PASOS 2,3,4,5,6: RECOLECCIÓN DE INFORMACIÓN VOLÁTIL DEL SISTEMA

Para una recolección rápida con grave-robber podemos usar las siguientes opciones: (comprometido)# /mnt/cdrom/tct/bin/grave-robber –d /mnt/memstick –lPstv /

Para una recolección mayor con grave-robber podemos usar las siguientes opciones, auque esta

recolección puede durar horas: # /tct/bin/grave-robber –d /mnt/memstick –E –v /

A continuación se muestra la información obtenida en el directorio /data cuando aplicamos el

comando de recolección rápida body class|host|start_time body|pegaso|1129578295 md5|file|st_dev|st_ino|st_mode|st_ls|st_nlink|st_uid|st_gid|st_rdev|st_size|st_atime|… 000|/sbin/arp|770|340184|33261|-rwxr-xr-x|1|0|0|5632|38364|1129561396|… 000|/usr/bin/at|770|567699|35309|-rwsr-xr-x|1|0|0|0|36904|1129560411|… …st_mtime|st_ctime|st_blksize|st_blocks …1061824441|1125332924|4096|80 …1063360476|1125333129|4096|80 body.s class|host|start_time body|pegaso|1129578295

139

md5|file|st_dev|st_ino|st_mode|st_ls|st_nlink|st_uid|st_gid|st_rdev|st_size|st_atime… 000|/usr/bin/at|770|567699|35309|-rwsr-xr-x|1|0|0|0|36904|1129560411|… 000|/usr/bin/crontab|770|568049|35309|-rwsr-xr-x|1|0|0|0|110114|1129560234|… …st_mtime|st_ctime|st_blksize|st_blocks …1063360476|1125333129|4096|80 …1045661968|1125333199|4096|224 md5_all Mon Oct 17 14:47:32 CDT 2005 md5_all.md5 d3aacbe1530ee815573d2450c3803144 /home/alicia/foren/tct-1.15/data//pegaso/MD5_all command.out Directorio \command_out 17/10/2005 01:47 p.m. 29 arp 17/10/2005 01:47 p.m. 90 arp.md5 17/10/2005 01:47 p.m. 219 df 17/10/2005 01:47 p.m. 89 df.md5 17/10/2005 01:47 p.m. 7,130 dmesg 17/10/2005 01:47 p.m. 92 dmesg.md5 17/10/2005 01:47 p.m. 348 finger 17/10/2005 01:47 p.m. 93 finger.md5 17/10/2005 01:47 p.m. 29 ifconfig 17/10/2005 01:47 p.m. 95 ifconfig.md5 17/10/2005 01:47 p.m. 1,130 ipcs 17/10/2005 01:47 p.m. 91 ipcs.md5 17/10/2005 01:47 p.m. 24,404 ksyms 17/10/2005 01:47 p.m. 92 ksyms.md5 17/10/2005 01:47 p.m. 9,846 last 17/10/2005 01:47 p.m. 91 last.md5 17/10/2005 01:47 p.m. 29 lastcomm 17/10/2005 01:47 p.m. 95 lastcomm.md5 18/10/2005 10:28 a.m. 0 lista.txt 17/10/2005 01:47 p.m. 982 lsmod 17/10/2005 01:47 p.m. 92 lsmod.md5 17/10/2005 01:46 p.m. 161,701 lsof 17/10/2005 01:46 p.m. 91 lsof.md5 17/10/2005 01:46 p.m. 117,631 lsof0 17/10/2005 01:46 p.m. 92 lsof0.md5 17/10/2005 01:46 p.m. 449,467 major_minor 17/10/2005 01:46 p.m. 1,216 netstat-a 17/10/2005 01:46 p.m. 96 netstat-a.md5 17/10/2005 01:46 p.m. 136 netstat-in 17/10/2005 01:46 p.m. 97 netstat-in.md5 17/10/2005 01:47 p.m. 1,216 netstat-na 17/10/2005 01:47 p.m. 97 netstat-na.md5 17/10/2005 01:46 p.m. 520 netstat-rn 17/10/2005 01:46 p.m. 97 netstat-rn.md5 17/10/2005 01:47 p.m. 29 nfsstat 17/10/2005 01:47 p.m. 94 nfsstat.md5 17/10/2005 01:46 p.m. 2,079 ps 17/10/2005 01:46 p.m. 89 ps.md5 17/10/2005 01:47 p.m. 252 rpcinfo 17/10/2005 01:47 p.m. 94 rpcinfo.md5 17/10/2005 01:47 p.m. 29 rpm 17/10/2005 01:47 p.m. 90 rpm.md5 17/10/2005 01:47 p.m. 29 showmount-a 17/10/2005 01:47 p.m. 98 showmount-a.md5 17/10/2005 01:47 p.m. 29 showmount-e 17/10/2005 01:47 p.m. 98 showmount-e.md5 17/10/2005 01:47 p.m. 5,134 top 17/10/2005 01:47 p.m. 90 top.md5 17/10/2005 01:47 p.m. 110 uname 17/10/2005 01:47 p.m. 92 uname.md5 17/10/2005 01:47 p.m. 92 uptime 17/10/2005 01:47 p.m. 93 uptime.md5 17/10/2005 01:47 p.m. 402 w 17/10/2005 01:47 p.m. 88 w.md5

140

17/10/2005 01:47 p.m. 161 who 17/10/2005 01:47 p.m. 90 who.md5

En cada archivo se encuentra el resultado de la ejecución del comando. Por ejemplo en la

aplicación del comando “df” el contenido del archivo es el siguiente: Mon Oct 17 14:47:08 CDT 2005 Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 7131448 4660160 2109024 69% / none 119384 0 119384 0% /dev/shm trust Directorio \trust 17/10/2005 01:47 p.m. 29 time 17/10/2005 01:47 p.m. 85 time.md5 17/10/2005 01:47 p.m. 415 trust.time 17/10/2005 01:47 p.m. 98 window_systems 17/10/2005 01:47 p.m. 95 window_systems.md5 user_vault Directorio \user_vault 17/10/2005 01:47 p.m. 87 alicia__home_alicia_.bash_history 17/10/2005 01:47 p.m. 119 alicia__home_alicia_.bash_history.md5 17/10/2005 01:47 p.m. 11,404 operator__root_.bash_history 17/10/2005 01:47 p.m. 114 operator__root_.bash_history.md5 17/10/2005 01:47 p.m. 11,404 root__root_.bash_history 17/10/2005 01:47 p.m. 110 root__root_.bash_history.md5 conf.vault Directorio \conf_vault 17/10/2005 01:47 p.m. 156 index.html

Paso 7: Documentar

Por lo regular las herramientas forenses traen un sistema de introducción de datos que ordena la

información para cada caso en particular, en el caso de “Autopsy” para iniciar la documentación

de un caso se pide la imagen recopilada del disco. Pero en nuestro caso sólo utilizamos la

herramienta “grave-robber” de “TCT” que obtiene sólo la información volátil en forma de

archivos y no de imágenes. Por lo que utilizaremos para el análisis los archivos generados

directamente por la herramienta.

141

CAPITULO 5

RECUPERACIÓN DE INFORMACIÓN EN MEMORIA RAM A TRAVÉS DE PROCEDIMIENTOS

FÍSICOS

142

5. RECUPERACIÓN DE INFORMACIÓN EN MEMORIA

RAM A TRAVÉS DE PROCEDIMIENTOS FÍSICOS.

Se ha mencionado que una de las decisiones a las que se enfrenta el equipo de respuesta a

incidentes es dar de baja o no el sistema para realizar la captura de datos, en el capítulo anterior

se expusieron procedimientos en base a una metodología general para obtener datos de memoria

cuando el sistema permanecía encendido y corriendo sus procesos en forma “normal”.

En este capítulo hablaremos del caso donde el investigador forense encuentra el equipo apagado

o “muerto” y veremos que todavía es posible recuperar algo de la información de la memoria

RAM, por lo que ahora en lugar de utilizar el concepto de captura de datos utilizaremos el

concepto de recuperación de datos.

Estado del

sistema

MUERTO


(ejemplos)

VIVO

CASO 2: Windows

CASO 1: Windows


CASO 3: Linux

CASO 4: Linux


Fig. 5.1 Recuperación de datos en un sistema “muerto”

143

Para mostrar esto, daremos una introducción a los problemas en semiconductores que pueden

generar que se guarde algo de información en las memorias y mostraremos nueve ejemplos de

recuperación de datos de la memoria RAM utilizando métodos físicos:

1. Retención de datos en base a la temperatura

2. Recuperación de datos en base al estrés generado en los transistores de una celda SRAM

3. Recuperación de datos en base al estrés del óxido en el capacitor dieléctrico

4. Recuperación de datos utilizando pruebas de estrés: “Burn in” e “Iddq”

5. Recuperación de datos en base a la alteración del estado preferente de encendido de una

celda SRAM

6. Recuperación de datos en smart cards en base al análisis de parámetros

7. Recuperación de datos en smart cards utilizando métodos invasivos

8. Lectura óptica de una SRAM CMOS

9. Prueba electromagnética en smartcards

Es importante mencionar que estos ejemplos han sido realizados en microcontroladores y tarjetas

“smartcards” por Universidades y centros de investigación especializados en semiconductores y

seguridad.

Durante esta investigación no se plantea una metodología para recuperar información volátil en

un sistema que ha sido apagado, pero estos ejemplos muestran la posibilidad de que aún se puede

obtener información de memoria en equipos donde se ha eliminado la energía eléctrica y que

pueden ser aplicados en alguna computadora o estación de trabajo que esté bajo una investigación

forense.

5.1 INTRODUCCIÓN

“Contrario a lo que se sabe, la memoria semiconductora “volátil” no pierde completamente su

contenido cuando la energía es removida”. Esto es debido a la remanencia en el dispositivo.

“Ambas memorias SRAM y DRAM retienen algo de información de los datos almacenados

cuando la energía era aplicada”, esto es lo que expresa el doctor e investigador del departamento

144

de Ciencias Computacionales de la Universidad de Auckland Peter Gutman en su artículo

“Secure Deletion of Data from Magnetic and Solid-Sate Memory” [19].

La remanencia es la representación física residual del dato que ha sido borrado de alguna forma.

Después de que un medio de almacenamiento es borrado existen algunas características físicas

que permiten al dato ser reconstruido [28].

Algunas veces durante el ciclo de vida de un sistema de información, su unidad de

almacenamiento primario o secundario puede ser reutilizada, destruida o liberada. Es importante

que los oficiales de seguridad, operadores de computadoras u otros usuarios de estos recursos

estén informados de los riesgos que corren. Se deben utilizar procedimientos para prevenir la

revelación de información “sensitiva” que se haya almacenado en el medio.

El problema de la remanencia fue reconocido desde el año 1960. Se encontró que sin la

aplicación de procedimientos seguros de borrado de datos, la información sensitiva podía ser

revelada en un ambiente controlado. La remanencia de datos puede ocurrir en todos los

dispositivos semiconductores, es difícil de contrarrestar porque depende grandemente de las

características y defectos de los semiconductores.

El concepto de la remanencia se ha estudiado como un problema. Pero para nuestro caso, donde

lo que buscamos es una pista de información remanente en los dispositivos semiconductores esto

se vuelve más que un problema una solución.

5.2 DEFECTOS FÍSICOS EN LOS DISPOSITIVOS DE MEMORIA

Desde mediados de los 90’s la demanda de confiabilidad y tolerancia a fallas en memorias

semiconductoras ha crecido. Con la constante miniaturización de los transistores MOSFET o

MOS, las memorias se han vuelto vulnerables a variaciones resultado del bajo rendimiento de

manufacturación y confiabilidad. Asociados a estas variaciones se encuentran varia fallas

paramétricas como lo son fugas de corriente en el óxido de la compuerta (gate oxide) y cambios

en los umbrales de voltaje, ataques de iones, de partículas alfa, de neutrones o radiación cósmica

145

que pueden causar un trastorno en el almacenamiento de los datos. Otros efectos simples como la

ruptura de una compuerta pueden destruir el dispositivo.

Algunos de los problemas que acompañan las nuevas generaciones de memoria debido a la

miniaturización de los dispositivos son [35]:

1) Problemas de energía (supply voltaje and power constraints)

Para realizar un escalamiento confiable es necesario mantener el campo eléctrico constante en los

dispositivos mientras las dimensiones disminuyen. Sin embargo, reducir la alimentación de

voltaje asocia problemas de retraso y estandarización en el chip. Por lo que la alimentación de

voltaje se ha reducido tradicionalmente en un factor mas pequeño que el espesor del óxido de la

compuerta, produciendo una gran fuerza en el campo del óxido de la compuerta (gate oxide).

3) Confiabilidad del oxido de la compuerta

La confiabilidad del óxido de la compuerta (gate oxide) es afectada por defectos físicos durante la

fabricación, como el espesor del óxido que puede incrementar las fuerzas del campo eléctrico.

Este espesor del óxido abajo de los 4nm3 produce una corriente en el óxido que pueden aumentar

los campos eléctricos, la temperatura y causar rupturas.

4) Degradación Hot Carrier

Se sabe que los efectos por inyección de portadoras aceleradas (hot carrier) pueden causar

sobrecarga de portadoras en el substrato, degradación del tiempo de refresco de la DRAM y en

algunos casos ruptura de los transistores MOSFET. Existe un decremento exponencial de los hot

carriers con respecto a la alimentación de voltaje. Por lo que la degradación por hot carrier no

afecta en gran medida a las DRAMs en el rango de los gigabits que tratan la alimentación de

voltaje de menos de 1V. Sin embargo, voltajes por arriba de éste pueden incrementar la

probabilidad de la degradación.

3 nm= nanómetro, unidad de longitud que equivale a una milmillonésmina parte de un metro, 1nm=1x10-9 m

146

Tipo n

Substrato tipo p

Tipo n

Fuente/source/Emisor Drenado/drain/colector

Barrera de Aislamiento o Tamperproof coating o Capa de pasivación

Compuerta/ Gate/Base

Compuerta- Gate

Substrato tipo p

Fuente Drenador

Esquema simbólicoDiagrama físico

Contacto ohmico

Fig. 5.2 Transistor MOSFET

5) Descargas electrostáticas y sobrestrés eléctrico

Las descargas electrostáticas y el sobrestrés eléctrico puede originar electricidad estática por el

cuerpo humano o por el ambiente en equipos mal aterrizados, esto puede generar rupturas en la

capa delgada de la compuerta (gate oxide). La fuerza del campo eléctrico requerido para romper

el SiO2 es cerca de 10 MV/cm. En años recientes los MOSFET se han hecho más sensibles a las

descargas. En chips con protección a estas descargas se coloca una circuitería de protección en

los pines I/O para proteger el dispositivo de picos de voltaje.

6) Confiabilidad de la metalización

En el proceso de escalación, la corriente de saturación del drenador del MOSFET se incrementa

moderadamente debido a la reducción significante del voltaje efectivo de la compuerta (gate), por

el bajo voltaje de alimentación. En primera instancia se podría esperar que un pequeño

incremento en la corriente del drenador no representa un problema serio de electromigración en

líneas de metal llevando esta corriente, sin embargo, la presencia de granos limitantes en todo el

ancho de la línea puede causar regiones localizadas de densidad de corriente incrementada y

vulnerabilidades de electromigración. La migración de estrés representa un problema de

confiabilidad en la metalización para tecnologías de escalación. La migración de estrés es estrés

mecánico que causa la difusión de iones de metal y crea vacíos. No es independiente de la

electromigración, la migración de estrés es causada por el desajuste entre el coeficiente térmico

de expansión de la línea de metal y del aislador.

147

La electromigración, la migración de estrés (stress migration) y la contaminación en el metal con

elementos radiactivos como uranio y torio, compromete la confiabilidad de la metalización.

5.3 RECUPERACIÓN DE DATOS

En la construcción de los circuitos integrados (CI) los problemas derivados de la miniaturización

producen defectos físicos que pueden ocurrir durante varios estados de fabricación desde la

formación del cristal de Si, la oxidación, la difusión, litografía óptica, metalización y

empaquetación. Aunque se han desarrollado técnicas, materiales y procesos para reducir estos

problemas, estos defectos pueden ser aprovechados por atacantes que buscan modificar, recuperar

o dañar ciertas partes del circuito objetivo.

Existe una variedad de formas en las cuales los datos almacenados pueden dejar trazos de su

existencia.

Estas formas se llevan a cabo a nivel físico del dispositivo semiconductor, desde la composición

del transistor, el arreglo de éstos y los capacitores que conforman la celda de memoria, hasta los

elementos complementarios como los amplificadores de sensibilidad que constituyen el sistema

de memoria.

Los efectos del estrés eléctrico en dispositivos semiconductores, producidos por contaminantes

iónicos, hot carrier y electromigración, pueden ser utilizados para determinar, después de un

período de tiempo indefinido, que tipo de señal fue llevada por una parte específica del circuito.

Por la amplia variación de métodos experimentales y la gran variedad de dispositivos no es

posible proveer información definitiva de cómo llevar a cabo un proceso de recuperación de

datos.

Otras investigaciones demuestran que a bajas temperaturas se puede incrementar el tiempo de

retención de un SRAM a muchos segundos e incluso minutos. Otra posible forma es “congelar”

el estado de la celda de memoria aplicando temperatura baja al dispositivo. En este caso la

148

SRAM puede retener información por varios minutos y aún horas dependiendo de la temperatura

(-20ºC).

Los ejemplos a continuación son llevados a cabo bajo situaciones experimentales en

microcontroladores y smartcards, que contienen diferentes tipos de memoria SRAM y DRAM.

No está descartado que estas técnicas pueden ser aplicadas a los dispositivos de memoria de una

estación de trabajo [20,28,31,35] .

5.4 EJEMPLOS

Como se mencionó, los ejemplos a continuación fueron desarrollados por Universidades y

Centros de Investigación:

5.4.1 EJEMPLO 1: RETENCIÓN DE DATOS EN BASE A LA TEMPERATURA

Es común asumir que una vez removida la energía de la SRAM, el contenido de la memoria es

destruido inmediatamente. Este no es el caso, los datos puede mantenerse por varios segundos, en

que el dispositivo revertirá a su estado anterior si la energía regresa de nuevo. Si el CI es

congelado, el periodo de remanencia puede incrementarse en minutos u horas. La remanencia

varía entre los diferentes componentes.

Los ingenieros de seguridad están interesados en el periodo de tiempo en el cual una SRAM

retiene los datos una vez que se ha removido la energía. En los 80s una serie de experimentos

demostró que a bajas temperaturas la retención de datos de una SRAM se incrementaba de

segundos a minutos. Con los dispositivos de esa época se encontró que la retención de datos

comenzaba a -20ºC.

Algunos dispositivos son diseñados con sensores de temperatura, cuando detectan una baja de

temperatura después de los -20ºC, se trata como un intento de intromisión y la memoria es puesta

en ceros inmediatamente.

149

Sergei Skorobogatov de la Universidad de Cambridge en 2002 [31] realizó una serie de

experimentos donde demostraba la retención de datos en CIs SRAM en función de la

temperatura. Concluyendo que la temperatura en la cual el 80% de los datos es retenido por un

minuto varía ampliamente entre dispositivos, algunos requieren enfriamiento de por lo menos

-50ºC, mientras otros retienen los datos por este periodo a temperatura ambiente. En ese trabajo

se propuso una solución para atenuar este problema colocando una tierra del voltaje de

alimentación en lugar de dejarlo sin conexión.

También concluyó que los tiempos de retención de la memoria varían no solo de un dispositivo a

otro, también entre dispositivos del mismo fabricante. Esto es porque los fabricantes no incluyen

en su proceso de fabricación el control de la retención de datos. Versiones de baja potencia del

mismo chip tuvieron más tiempo de retención de datos [28,31].

5.4.2 EJEMPLO 2 : RECUPERACIÓN DE DATOS EN BASE AL ESTRÉS GENERADO

EN LOS TRANSISTORES DE UNA CELDA SRAM

Peter Gutman de la Universidad de Auckland expuso [20] que en una serie de pruebas aplicadas a

un dispositivo SRAM, el dispositivo cambia el voltaje de umbral, transconductancia y corriente

drenador-fuente después de los 100-500 segundos de estrés, correspondiendo con un cambio en el

tiempo de acceso a la SRAM y la operación de voltaje.

Esto hace posible determinar donde fue almacenado un 0 o 1 detectando que transistor fue más

estresado. Como se observa en la celda SRAM, al leer o escribir un 0 o 1 se utiliza un transistor

de acceso diferente.

Select

Dispositivos de carga

Data Data

+V

Select

Read/Write (R/W)

A B

Fig. 5.3 Celda SRAM

150

Los puntos grises en los transistores de la figura 5.2 muestran donde es localizado el principal

estrés. Los cambios en el comportamiento de la celda pueden ser determinados obteniendo el

tiempo de acceso de la celda a través de una microprueba de voltaje en las celdas de transistores o

utilizando técnicas similares.

Pruebas similares han sido realizadas en DRAMs sin embargo en este caso el énfasis de los

efectos de estrés fue en los circuitos compartidos como son los buffers de direcciones y los

amplificadores de sensibilidad (sense amplifiers) [20].

5.4.3 EJEMPLO 3 : RECUPERACIÓN DE DATOS EN BASE AL ESTRÉS DEL ÓXIDO

EN EL CAPACITOR DIELÉCTRICO DE UNA CELDA DRAM

La DRAM también puede “recordar” el último estado almacenado, pero de manera diferente.

Esto no es en base a la carga que es retenida en la celda (voltaje en los capacitores), sino al óxido

delgado que forma el dieléctrico del capacitor que es estresado altamente cuando se aplica un

campo y se relaja cuando no es aplicado (se estresa de acuerdo al estado del dato), este efecto

puede presentarse en forma inversa, es la conclusión a la que llega Peter Gutman en Julio 1996

[19].

Aún un óxido perfecto es susceptible a cambiar cuando se aplica un campo magnético. En la

presencia de un campo eléctrico los átomos con una carga positiva migran hacia el polo negativo

con una velocidad que depende de la temperatura, la calidad del óxido y los contaminantes

(sodio). Si el campo eléctrico es cero o no existe por suficiente tiempo, el estrés tiende a disiparse

eventualmente.

El estrés en la celda tiene un efecto acumulativo, como la carga de un circuito RC. Si el dato es

aplicado por solo unos milisegundos se efectuará un pequeño aprendizaje en las celdas. Por lo

que las propiedades del óxido cambian ligeramente dependiendo del dato.

Los efectos del estrés pueden ser medidos utilizando pruebas de memoria ”built-in-self” en las

celdas. En estas pruebas se induce un voltaje débil a la celda de almacenamiento para medir su

151

margen. Las celdas mostrarán diferentes márgenes dependiendo de cuanto óxido estresado esté

presente.

Un método simple pero destructivo para eliminar los datos almacenados en memorias

semiconductoras es elevar la temperatura. Tanto la DRAM como la SRAM perderán el contenido

mientras se llegue mas rápido a la temperatura Tjunction=140ºC. Varias horas sin energía

aplicada a esta temperatura, serán suficientes para hacer más difícil la recuperación de datos.

Contrario a esto, extender la vida de los bits almacenados cuando la energía es removida puede

llevarse a cabo debajo de los -60ºC, por días e incluso semanas[19].

5.4.4 EJEMPLO 4: RECUPERACIÓN DE DATOS UTILIZANDO PRUEBAS DE

ESTRÉS: “BURN IN” E “IDDQ”

Burn in

En el trabajo de Peter Gutman también se afirma que es posible recuperar datos directamente del

dispositivo sin preocuparse por restaurarlo. En dispositivos de los 80’s fue común leer los datos

almacenados en largos periodos en una SRAM con técnicas “Burn in”. Burn-in es una prueba

eléctrica de estrés que emplea voltaje y temperatura para acelerar las fallas eléctricas del

dispositivo.

Burn-in es realizado a 125ºC, con excitación eléctrica aplicada a muestras. Las memorias son

cargadas en tarjetas de prueba y son insertadas en hornos burn-in, los cuales proporcionan los

voltajes necesarios para las muestras a la temperatura de la prueba. Los sistemas dinámicos burn-

in aplican voltajes a temperaturas extremas mientras ejercitan las entradas del dispositivo bajo

prueba. Este procedimiento involucra altos costos por el manejo individual de los dispositivos [35].

Iddq

En los dispositivos SRAM más recientes se requiere de métodos mas sofisticados para hacer la

lectura de datos. Algunas técnicas se enfocan al uso de pruebas de dispositivos como lo es la

prueba Iddq (Corriente en reposo de la fuente de poder (quiescent current)) en cada vector

funcional de prueba, utilizando monitores de corriente de alta velocidad para mediciones rápidas.

Esta metodología de prueba envuelve la ejecución de un conjunto de vectores hasta una

152

localización alcanzada (conocida como medida paramétrica de paro o PM) en este punto el

dispositivo es interrumpido y la corriente es medida.

Variando los parámetros como el voltaje aplicado y la temperatura de operación es posible

identificar dispositivos que han sido sujetos a efectos de estrés de “hot carrier” que alteran sus

parámetros operacionales. El diseño de la compuerta (floating-gate) puede tener características de

Iddq dependiendo del tiempo, en la cual la compuerta causa que los MOSFET n y p esté

parcialmente en “on” y conduzcan un flujo de corriente que cesa lentamente conforme a la carga

de la compuerta para un estado lógico en especial. La carga inicial (o carencia de ésta) en la

compuerta y el cambio en la carga puede ser observado en la lectura por Iddq [19].

5.4.5 EJEMPLO 5: RECUPERACIÓN DE DATOS EN BASE A LA ALTERACIÓN DEL

ESTADO PREFERENTE DE ENCENDIDO DE UNA CELDA SRAM

Otra de las conclusiones a las que llega Peter Gutman en su investigación es que la SRAM es

susceptible a la remanencia debido a que el almacenamiento del mismo dato sobre un largo

periodo de tiempo tiene el efecto de alterar el estado preferente de encendido (power up). CIs

antiguos pueden “recordar” el estado previo al apagar el equipo por varios días. De hecho, es

posible fabricar SRAMs que tengan cierto estado de encendido, pero que no se sobrescriban

como una “ROM escribible”.

Una llave contenida en una memoria RAM estática por un largo periodo de tiempo puede ser

revelada en el siguiente “power on” debido a la remanencia [19,28].

5.4.6 EJEMPLO 6: RECUPERACIÓN DE DATOS EN SMART CARDS EN BASE AL

ANÁLISIS DE PARÁMETROS

Análisis de energía (Power analysis)

En el análisis de energía se miden las fluctuaciones en la corriente consumida por el dispositivo.

Las diferentes instrucciones causan diferentes niveles de actividad en el decodificador de

instrucciones y unidad aritmética, que pueden ser claramente distinguidas y parte de los

algoritmos puede ser reconstruida.

153

El desarrollo del análisis de energía y energía diferencial ha habilitado ataques severos en todos

los procesadores actuales en las smart cards. Cada cambio de bit en el bus del chip de la tarjeta

causa una corriente extra, una cantidad medible que es dibujada en la alimentación. Si los detalles

de implementación del software de la tarjeta son conocidos, se puede establecer un ataque

habilitando los valores de las llaves [33,30].

Análisis de corriente

Utilizando resistencias de 10 y 15 ohms en la fuente de poder, podemos medir con un convertidor

analógico-digital las fluctuaciones en la corriente consumida por la tarjeta. Preferentemente, las

mediciones deberán hacerse a por lo menos 12 bits de resolución y el muestreo de frecuencia

debería ser un entero múltiple de la frecuencia del reloj de la tarjeta.

El manejo de los buses de datos y direcciones consiste de más de una docena de inversores

paralelos por bit, cada uno maneja una gran carga capacitiva. Estos pueden causar un corto

circuito durante alguna transición. Los cambios en un bus de un 0 a 1 o inversamente contribuyen

de entre 0.5 y 1 mA del total de la corriente en el tiempo de un salto de reloj, así 12 bits son

suficientes para estimar el número de bits en el bus que cambian a la vez. SRAM escribe

operaciones generadas por fuertes señales. Promediando las mediciones de corriente de

transacciones idénticas repetidas, se pueden identificar señales pequeñas que no son transmitidas

por el bus. Estas señales llevan los estados de los bits. Señales como el estado del bit de acarreo

(carry bit state) son de interés especial, porque muchos algoritmos criptográficos utilizan el

cambio en la operación para elegir un bit de la llave individual en la bandera carry [30].

Análisis de frecuencia

Las diferentes instrucciones causan niveles de actividad diferentes en el decodificador de

instrucciones y unidad aritmética, que pueden ser claramente distinguidas y pueden ayudar a

reconstruir un algoritmo. Los diferentes procesadores tienen sus switcheos en tiempos diferentes

que son relativos al reloj y pueden ser identificados en mediciones de alta frecuencia [30].

154

5.4.7 EJEMPLO 7: RECUPERACION DE DATOS EN SMART CARDS UTILIZANDO

MÉTODO INVASIVO

Los ataques invasivos empiezan desempaquetando el chip. Una vez que el chip es abierto se

realizan las pruebas o ataques. Se debe remover por lo menos la capa de pasivación (passivation

layer) antes de que las pruebas puedan establecer contacto. Esto se puede realizar grabando

(etching), taladrando (drilling) o cortando con láser.

Para realizar estos ataques, el invasor debe estar familiarizado con las técnicas de diseño de los

CMOS VLSI (Very Large Scale Integration) y arquitectura de microcontroladores. Capas

profundas pueden ser accedidas utilizando equipo y herramienta especializados. También

utilizando estas técnicas se puede modificar la estructura del chip creando nuevas líneas de

conexiones y aún nuevos transistores.

Todos los ataques invasivos son complicados. Requieren de horas o semanas en un laboratorio

especializado y en el proceso destruyen el paquete. En suma los ataques invasivos requieren de

especialistas altamente calificados y un presupuesto propio.

Una vez que el chip es abierto, es posible realizar pruebas o ataques. La herramienta mas

importante para un ataque invasivo es una estación de trabajo para micropruebas (microprobing

Workstation). Su mayor componente es un microscopio óptico especial con distancia de trabajo

de por lo menos 8mm entre la superficie del chip y los lentes.

No es muy práctico leer información almacenada en un procesador de seguridad directamente de

cada celda de memoria, excepto para ROM. Los datos almacenados tienen que ser accedidos vía

un bus de memoria donde todos los datos estén disponibles para una localización simple. Las

micropruebas son usadas para observar el bus entero y grabar los valores de memoria que son

accedidos.

Es difícil observar todos lo buses de datos y direcciones al mismo tiempo (mas de 20). Pero

varias técnicas se pueden realizar, por ejemplo podemos repetir la misma transacción muchas

veces y utilizar dos o cuatro probadores para observar varios conjuntos de buses. Tan pronto

como el procesador realice la misma secuencia de acceso a memoria.

155

Para leer las celdas de memoria sin ayuda de software de tarjeta, se necesita utilizar algunos de

los componentes del CPU como un contador de direcciones para acceder a todas las celdas de

memoria. El contador de programa se incrementa automáticamente durante cada ciclo de

instrucción y la utiliza para leer la siguiente dirección, la cual nos sirve como generador de

secuencia de instrucciones. Solo se necesita prevenir que el procesador ejecute un salto, retorno o

llamada al procesador, que pueda afectar el contador de programa en su secuencia normal de

lectura. Pequeñas modificaciones al decodificador de instrucciones o al circuito contador del

programa tienen el efecto deseado con abrir las interconexiones correctas con el láser [29].

5.4.8: EJEMPLO 8: LECTURA ÓPTICA DE UNA SRAM CMOS

Una forma tradicional de lectura de datos en memorias de smartcards es realizada con un ataque

invasivo utilizando pruebas mecánicas en el bus del procesador. Estos ataques involucran

desempaque físico del chip y lectura de sus estados internos haciendo conexiones eléctricas a

componentes internos utilizando micropruebas. Siendo una tarea difícil el acceso a los circuitos

debido a la miniaturización de los elementos, estos ataques pueden ser realizados con diversas

herramientas como luz UV, rayos X y otras fuentes de radiación iónica, láser y campos

electromagnéticos.

El equipo de investigadores de la Universidad Católica de Louvain (Samyde y Quisquater) junto

con los investigadores de la Universidad de Cambridge (Skorobogatov y Anderson) desarrollaron

ataques donde las técnicas semi-invasivas podían ser usadas para leer el estado de la celda de

memoria de una forma no destructiva. Ejemplos de estos ataques son las pruebas ópticas y las

pruebas Electromagnéticas.

En las pruebas ópticas un láser es usado para inducir una falla transitoria en una o más

compuertas de forma que cause una fuga de información [32,34].

La base teórica de los experimentos se basa en los fotones que produce un haz de láser rojo

(659nm de longitud de onda) que al chocar con un dispositivo semiconductor produce mas

energía que la banda gap del Si (silicon band gap), haciendo que las áreas del CI apuntadas con el

láser se ionizen. Si los fotones alcanzan el área cercana a las uniones (junctions) p-n de un

156

transistor, se decrementará la resistencia del canal por la inyección de portadoras libres y se

producirá una fotocorriente debido al efecto fotovoltáico.

La habilitación de lectura a los estados de la celda de memoria se realiza a través del decremento

en la resistencia de los canales (n y p). En los experimento que llevaron a cabo los investigadores

se apuntó el rayo del láser en un transistor de un CI, pudiéndose distinguir los dos posibles

estados de memoria. Esta técnica es similar a la usada para cambiar el estado de memoria de los

bits usando rayos láser de baja potencia.

5.4.9 EJEMPLO 9: PRUEBA ELECTROMAGNÉTICA EN SMARTCARDS

Similar a las pruebas ópticas se pueden utilizar técnicas con pruebas electromagnéticas para

obtener datos de la memoria de un CI. Investigadores de la Universidad Católica de Louvain en

Bélgica en 2002 trabajaron con un análisis electromagnético, utilizando inducción

electromagnética para escanear un semiconductor. En esta técnica se utiliza un pequeño probador

en la superficie baja del CI y se mide la corriente inducida en él por un campo magnético en su

superficie. En algunas circunstancias esto da información similar a la obtenida en mediciones de

consumo de energía por el CI (power analysis). Este análisis mostró más información de la

requerida ya que el campo magnético obtenía otros campos magnéticos generados por señales

locales que no eran presentadas fuera del CI.

En los experimentos que llevó a cabo el equipo de investigadores se construyó un inductor

miniatura, colocando cientos de vueltas de alambre alrededor de la punta de la aguja en un equipo

de microprueba. Al inductor se le inyectó una corriente en el espiral que generó un campo

magnético donde las líneas del campo se dibujaron sobre la aguja.

La punta de prueba se colocó algunos micrómetros (microns) sobre la superficie del procesador

de prueba y se conectó el espiral al bulbo del flash de una cámara donde la corriente de remolino

creada por el campo magnético se sensó permitiendo construir un mapa del CI, como se muestra

en la figura 5.3.

157

Fig. 5.4 Mapa construído usando la corriente de eddy en una fotografía de la misma área.

Se observó que esta técnica de inducción, también podía ser usada para leer datos en forma no

destructiva. Con el mismo sensor se escaneó un chip creando una pequeña perturbación en la

celda de memoria. La idea fue mover por un corto tiempo el punto de polarización del transistor.

Cuando el punto de polarización es movido de su estado original, la velocidad o el tiempo que

tarda en regresar a ese estado original refleja el dato guardado en el transistor pudiendo ser un “0”

o un “1”. Con el equipo utilizado fue difícil crear la suficiente corriente en el chip sin alterar el

contenido de las celdas de memoria, pero mejorando los equipos, técnicas de laboratorio y con un

procesamiento de señal más sofisticado se puede poner en práctica el uso de técnicas

electromagnéticas para leer memorias con mayor eficacia [33].

158

CONCLUSIONES

Uno de los problemas a los que se enfrenta un investigador forense a la hora de capturar

información, es obtener información volátil y de memoria que puede ser borrada o sobrescrita al

querer obtenerla.

La memoria guarda información importante que puede ser la única fuente de información que el

atacante haya dejado en una violación a un sistema y puede convertirse en evidencia crucial para

detectar las causas del incidente.

Pero el análisis vivo no es ideal para un proceso de investigación forense porque se trabaja

directamente sobre el sistema sospechoso, esto puede alterar la información recolectada y si esta

información es llevada a un juicio ante una corte, puede que no sea aprobado como evidencia

porque no es una copia fiel de la escena del crimen, por lo que considerando esta situación el

investigador deberá conocer muy bien las herramientas de captura que utilice, por si llega a

modificar algo, sepa exactamente que cambia en el sistema una vez ejecutado cada comando.

No cabe duda que una metodología es aplicada por un atacante para llevar a cabo una intrusión,

por lo que tener una metodología para realizar la investigación forense también es necesaria y

sobre todo en el primer paso de recolección de información volátil. Con los pasos bien definidos

a seguir durante la recolección podremos capturar mayor y de mejor manera información volátil

que pueda complementar la información estática y así obtener mayor evidencia para asistir al

investigador en determinar las causas del incidente, hasta llegar al culpable.

159

La respuesta a incidentes en investigaciones, se centra en el primer intento del investigador por

verificar el incidente, quien atiende un incidente puede verse forzado a elegir una acción que

podría modificar la evidencia. En el proceso de investigación forense se aplican técnicas

científicas y analíticas a infraestructura de cómputo, para identificar, preservar, analizar y

presentar evidencia de manera que sea aceptable en un procedimiento legal para reconstruir los

hechos pasados con base en la evidencia que se recolecta.

Es en la respuesta inicial donde será incluido el procedimiento propuesto, ya que se debe obtener

la información volátil que nos pueda ayudar a obtener datos importantes de la verificación de un

incidente y así mismo la evidencia necesaria para llegar a ese objetivo.

La aplicación de una metodología para el sólo paso de la recolección de información es de

extrema utilidad ya que puede servir como una guía para que el investigador pueda recolectar la

información volátil con la menor alteración posible, esta metodología se realizó en base al orden

de volatilidad considerando que independientemente del sistema operativo con el que cuente el

equipo bajo análisis los registros del procesador, el contenido de la memoria y el estado de las

conexiones y los procesos es perdido cuando el sistema es apagado. Por lo que se puede aplicar

en diferentes sistemas operativos.

En la metodología planteada expone siete pasos de recolección de información volátil sobre

equipos de cómputo; el primer paso establece una línea de conexión segura al sistema donde

podamos aplicar las herramientas de nuestro conjunto en forma confiable, una vez establecida

esta comunicación se realiza un registro de tiempo de todo el sistema y se procede a obtener los

datos del sistema (en base a la volatilidad), una vez finalizadas estas tareas se realiza un nuevo

registro de tiempo y una copia de la memoria que muchas veces causa la reinicialización de la

máquina. El paso final se refiere a la documentación de la información, que es tan importante

como cada uno de los pasos anteriores.

Esta metodología se aplicó sobre los sistemas operativos Windows y Linux ya que son los de uso

más común, y se consideraron dos tipos de accesos, en forma local y a través de la red,

pudiéndose observar la utilidad de las herramientas existentes en cada una de las versiones de los

160

sistemas operativos elegidos ya que éstos son una excelente plataforma que permite flexibilidad

para ejecutar comandos de recolección de información volátil.

Varias herramientas y procedimientos puede que no trabajen como se describe en la

investigación, debido a que Windows y Linux parchan sus sistemas continuamente

protegiéndolos contra ataques y por lo tanto contra la recolección forense. Cada situación

requerirá quizá de una herramienta nueva que se tendrá que adecuar al caso, por lo que el

investigador forense tiene que saber muy bien el uso de cada herramienta, ya que el orden en que

se pueden o deben usar depende de los efectos que tienen.

En el caso del uso de las herramientas forenses como grave-robber se observó que este tipo de

software aplica una metodología planteada por el desarrollador, la cual se ejecuta con comandos

internos de los cuales solo observamos el resultado, sin tener la flexibilidad de profundizar sobre

un punto, modificarlo o quizá saltarnos algunas acciones. Por lo que la creación del propio

conjunto de herramientas es importante para la recolección.

Las herramientas utilizadas para la recolección de información volátil en los primeros casos no

fueron especializadas o forenses, se utilizaron herramientas del administrador del sistema, esto

porque la recolección de información volátil muchas veces requiere que el investigador utilice lo

que tienen a primera mano, además de que el sistema operativo tiene los comandos necesarios

para aplicarlos donde el investigador exactamente lo requiere, más que aplicar un solo comando

para realizar toda la captura como lo ejecutan las herramientas forense.

Finalmente la elección del conjunto de herramientas dependerá completamente del investigador,

en este trabajo solo se exponen las ventajas y desventajas que se pudieran tener en caso de

decidirse por una u otra herramienta.

El objetivo del análisis forense es una actividad orientada a respuesta, es decir, determinar qué

sucedió, quién fue el culpable y cuál es el impacto de los eventos. Las herramientas descritas y la

metodologías es útil, pero la habilidad del investigador es la que determina si el caso será resuelto

o no.

161

Dentro del alcance de este trabajo no se plantea una metodología para la recuperación de

información sobre un sistema muerto, ya que lleva un proceso y herramientas muy diferentes a un

sistema vivo, pero se expusieron varios ejemplos realizados por Universidades dedicadas a

semiconductores y seguridad que muestran que todavía es posible obtener algo de información de

la memoria RAM aunque el equipo esté desconectado de energía.

El concepto en que se basa esta serie de experimentos es la retención de datos en dispositivos de

memoria (remanencia), causado principalmente por los problemas que se generan en el proceso

de miniaturización de los dispositivos de memoria. Estos problemas pueden no estar

contemplados en la construcción y generar defectos que pueden aprovecharse para la

recuperación de información en estos dispositivos.

Aunque para los desarrolladores de software y los constructores de circuitos integrados los

defectos en los sistemas representan problemas, para el investigador forense estos defectos son

una forma que pueden emplear para recuperar u obtener evidencia. Pero la utilización de equipo

especializado y pruebas experimentales hace difícil que los dueños de los equipos puedan

acceder a estas acciones en el caso de una investigación judicial. Tal vez no se pueda incluir

como evidencia en una corte, pero es una buena noticia saber que existe una forma de obtener

información de memoria aunque el sistema esté completamente muerto.

Los pasos de la metodología general propuesta puede que no sean apropiados en todas las

jurisdicciones, por lo que se debe realizar un procedimiento de recolección de información volátil

para cada sitio en específico, y la metodología propuesta puede ser de gran utilidad.

Hemos hablado de llevar la información recolectada a una corte, pero en México son pocas las

leyes establecidas para delitos informáticos, por lo que esta metodología general se adecuará a

cada sitio en específico, es por eso que una metodología puede ayudar a hacer el proceso más

formal y obtener un punto más a favor en la lucha contra los crímenes digitales.

162

REFERENCIAS BIBLIOGRÁFICAS [1] Gottfried, Grant. ”Emerging Technology: Taking a Byte Out Of Crime”. Itarchitect

Network Magazine [en línea]. Mayo 2001. [ref. Marzo 2003]. Disponible en WWW : <http://www.networkmagazine.com/article/NMG20010125S0001>

[2] Kruse, Warren G., y Heiser, Jay G. “Computer Forensics (Incident Response Essentials)”.

Editorial Addison Wesley, Septiembre 2001. [3] Dittrich, Dave. “Basic Steps in Forensic Analysis of Unix Systems”. Computer Forensics

[en línea]. [ref. Marzo 2003]. Disponible en WWW: <http://staff.washington.edu/dittrich/>

[4] Grego, Adolfo. “Presentación Computación Forense”

ALAPSI/ITESM 2001 [5] Department of Energy, Computer Forensics Laboratory.”First Responder´s Manual”. [en

línea] . [ref. Marzo 2003]. Disponible en pdf en Internet: <http://www.linuxsecurity.com/resource_files/documentation/firstres.pdf>

[6] Brezinski, D. y Killalea, T. “Guidelines for Evidence Collection and Archiving”. Request

for Comments[en línea]. RFC 3227, categoría: Best Current Practice. Febrero 2002. [ref. Abril 2003]. Disponible en Internet: <http://www.rfc-archive.org/getrfc.php?rfc=3227>

[7] Aquino Luna, Rubén. “Análisis forenses en sistemas Windows/Unix.” Cómputo Académico UNAM. Marzo 2003. [8] Write, Timothy E. “The Field Guide for Investigating Computer Crime: Overview of a

Methodology for the”. Security Focus [en linea]. Mayo 26 2002 [ref. Jul 2003]. Disponible en WWW: <http://www.securityfocus.com/infocus/1245>

[9] International Organization on Computer Evidence. “G8 proposed principles for forensic

evidence”. International Organization on Computer Evidence IOCE [en línea]. 2002. [ref. Ago 2003]. Disponible en pdf en Internet. <http://www.ioce.org/ >

http://www.networkmagazine.com/article/NMG20010125S0001

http://staff.washington.edu/dittrich/

http://www.securityfocus.com/infocus/1245

http://www.ioce.org/G8_proposed_principles_for_forensic_evidence.html

163

[10] Russinovich, Mark. “Ps Tools”. Sysinternals [en línea]. 2005. [ref. Octubre 2005]. Conjunto de herramientas disponible en Internet:<http://www.sysinternals.com/Utilities/PsTools.html>

[11] Robinson, Matt D. y Morano, Tom. “Linux Kernel Crash Dump”. Sourceforge [en línea].

2000. [ref. Sep 2004]. Disponible en WWW: <http://lkcd.sourceforge.net/> [12] Linux Education. “LKCD Installation and Configuration”. IBM Global Services [en

línea]. 2000.[ref. Sep 2004]. Disponible en pdf en Internet: <http://lkcd.sourceforge.net/doc/lkcd_tutorial.pdf> [13] Winchell, Dave, Moyer, Jeff y Huber, Josh. “Mission Critical Linux”. Mission Critical

Linux [en línea]. Inc. 2000. [ref. Oct 2004]. Disponible en WWW: <http://oss.missioncriticallinux.com/projects/mcore/>

[14] The GNU Project Debugger. “GDB”. The GNU Project Debugger [en línea]. Enero 2002.

[ref Sep 2004]. Disponible en Internet: <http://sources.redhat.com/gdb/> [15] Johnson, Michael K. “Netdump Rationale”. Red Hat, Inc.'s Network Console and Crash

Dump Facility [en línea]. 2002. [ref. Ago 2003]. Disponible en WWW: <http://www.redhat.com/support/wpapers/redhat/netdump/>

[16] Carrier, Brian. “ Sleuth Kit” y “Autopsy Browser”. Sleuthkit.org [en línea]. [ref. Mayo

2005]. Disponible en WWW: <http://www.sleuthkit.org/> [17] Venema, Wietse. “The Coronoer´s Toolkit (TCT). Porcupine.org [en línea]. [ref. Mayo

2005].Disponible en WWW:< http://www.porcupine.org/forensics/tct.html> [18] Venema, Wietse. “Memdump”. Porcupine.org [en línea]. [ref. Mayo 2005].Disponible en

WWW:<http://www.porcupine.org/forensics/memdump-1.0.README> [19] Gutman, Peter. “ Secure Deletion of Data from Magnetic and Solid-State Memory”.

Department of Computer Science, University of Auckland [en linea]. 6o. Simposio de Seguridad USENIX, Julio 1996. [ref. Enero 2005]. Disponible en formato pdf en Internet:

<http://www.cs.auckland.ac.nz/~pgut001/> [20] Gutman, Peter. “ Data Remanence in Semiconductor Devices.”. IBM T.J. Watson

Research Center [en línea].10 Simposio de Seguridad USENIX, Agosto 2001. [ref. Enero 2005]. Disponible en Internet: <http://www.cs.auckland.ac.nz/~pgut001/>

[21] Schweitzer, Douglas. “Incident Response: Computer Forensics Toolkit”. HNS [en línea].

Octubre 2003. Capitulo 1. [ref. Dic 2004]. Disponible en formato pdf en Internet: <http://www.net-security.org/dl/reviews/0764526367.pdf>

[22] Barish, Stephen. “Windows Forensics: A Case Study”. SecurityFocus [en línea].

Diciembre 2002 [ref. Mayo 2005]. Disponible en WWW: <http://www.securityfocus.com/infocus/1653>

http://www.sysinternals.com/Utilities/PsTools.html

http://lkcd.sourceforge.net/

http://oss.missioncriticallinux.com/projects/mcore/

http://sources.redhat.com/gdb/

http://www.redhat.com/support/wpapers/redhat/netdump/

http://www.sleuthkit.org/

http://www.porcupine.org/forensics/tct.html

http://www.net-security.org/dl/reviews/0764526367.pdf

mailto:[email protected]

164

[23] Microsoft. “Windows 2000 Resource Kits”. Microsoft Corporation [en línea]. 2004. [ref. Mayo 2005]. Disponible en WWW: <http://www.microsoft.com/windows2000/techinfo/reskit/default.asp>

[24] Microsoft. “How to configure system failure and recovery options in Windows”.

Microsoft Corporation [en línea]. 2003. [ref. Agosto 2005]. Disponible en WWW: <http://support.microsoft.com/kb/307973>

[25] Microsoft Support. “How to Use Dumpchk.exe to Check a Memory Dump File”.

Microsoft Corporation [en línea]. 2003. [ref. Agosto 2005]. Versión en español Id. del artículo 241215 Disponible en WWW: <http://support.microsoft.com/kb/315271/EN-US/> inglés

<http://support.microsoft.com/default.aspx?scid=kb;es;241215 > español [26] Microsoft. “Debugging Tools for Windows”. Microsoft Corporation [en línea]. 2003.

[ref. Agosto 2005]. Disponible en WWW: <http://www.microsoft.com/whdc/devtools/debugging/default.mspx>

[27] Russinovich, Mark. “PsTools”. Sysinternals [en línea]. 2004. [ref. Mayo 2005].

Disponible en WWW: <http://www.sysinternals.com/ntw2k/freeware/pstools.shtml> [28] Nacional Computer Security Center. “A Guide to Understanding Data Remanence in

Automated Information Systems”. Department of Defense Trusted Computer System Evaluation Criteria [en línea]. Rainbow Series. Library No. 5-236,082, version 2, Septiembre 1991. [ref. Febrero 2005]. Disponible en WWW: <http://www.fas.org/irp/nsa/rainbow/tg025-2.htm>

[29] Skorobogatov, Sergei P. “Semi-Invasive Attacks (definition). University of Cambridge

[en línea]. Octubre 2001. [ref. Febrero 2005]. Disponible en WWW: <http://www.cl.cam.ac.uk/~sps32/semi-inv_def.html>

[30] Skorobogatov, Sergei P. “Copy Protection in Modern Microcontrollers”. University of

Cambridge [en línea]. Noviembre 2001. [ref. Febrero 2005]. Disponible en WWW: <http://www.cl.cam.ac.uk/~sps32/mcu_lock.html>

[31] Skorobogatov, Sergei. “Low Temperature Data Remanence in Static RAM”. University of Cambridge Computer Laboratory. Junio 2002. [ref. Febrero 2005]. Disponible en pdf en Internet: < http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-536.html>

[32] Skorobogatov, Sergei y Anderson Ross. “Optical Fault Induction Attacks” University of

Cambridge [en línea]. Mayo 2002. [ref. Marzo 2005]. Disponible en WWW: <http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/faultpap3.pdf>

[33] Moore, Simon. 3rd Generation Smart Card Project [en línea]. G3Card IST-1999-13515.

Enero 2003. [ref. Marzo 2005]. Disponible en WWW: <http://www.g3card.com/> [34] Skorobogatov, Sergei y Anderson Ross. “On a New Way to Read Data from Memory”.

University of Cambridge [en línea]. Diciembre 2002. [ref. Marzo 2005]. Disponible en formato pdf en Internet: <http://www.cl.cam.ac.uk/~sps32/>

http://support.microsoft.com/kb/307973

http://support.microsoft.com/kb/315271/EN-US/

http://support.microsoft.com/default.aspx?scid=kb;es;241215

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

http://www.fas.org/irp/nsa/rainbow/tg025-2.htm

http://www.cl.cam.ac.uk/%7Esps32/semi-inv_def.html

http://www.cl.cam.ac.uk/%7Esps32/mcu_lock.html

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-536.html

http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/faultpap3.pdf

http://www.g3card.com/

http://www.cl.cam.ac.uk/%7Esps32/

165

[35] Chakraborty, Kanad y Mazumder, Pinaki. “Reliability and Fault Tolerance of RAMs”.

Pearson Education, Informit [en línea]. Ejemplo de Capítulo cortesía de Prentice Hall. Octubre 2002. [ref. Abril 2005]. Disponible en WWW: <http://www.informit.com/articles/article.asp?p=29732>

[36] Mandia, Kevin y Prosise, Chris. “Incident Response: Investigating Computer Crime”. Editorial: Osborne/McGraw Hill. 2001.

[37] Wreski, Dave. “Biatchux Booteable CD Forensics Toolkit”. Linux Security.com [en línea] Febrero 2002. [ref. Agosto 2005]. Disponible en Internet: <http://www.linuxsecurity.com/content/view/111308/65/>

[38] Salusky, William. “Forensic and Incident Response Environment”. Source Forge [en

línea] 2004.[ref. Septiembre 2005]. Disponible la herramienta y documentación en Internet: <http://fire.dmzs.com/>

[39] Knopper, Klaus. “Knoppix”. Knopper.net [en línea]. [ref. Septiembre 2005]. Disponible la

herramienta y documentación en Internet: < http://www.knoppix.org/> [40] Baca Ernest. Penguin Sleuth Booteable CD”. Linux-Forensics.com [en línea] 2003. [ref.

Septiembre 2005]. Disponible herramienta y documentación en Internet: < http://www.linux-forensics.com/downloads.html>

[41] ASR Data. “Smart Linux”. ASR Data [en línea] 2005. [ref. Septiembre 2005]. Disponible

la herramienta y documentación en Internet: <http://www.asrdata2.com/> [42] Sánchez Franco, Alfredo. “Delitos Informáticos y su prueba - Algunas Consideraciones

sobre la Ley Penal Mexicana, con base en la Legislación Penal Internacional”. Delitos Informáticos [en línea]. Enero 2004. [ref Octubre 2005]. Disponible en WWW: <http://www.delitosinformaticos.com/delitos/ensayomexico.shtml>

[43] Semiconfareast.com. “Microprobing”. Semiconfareast.com [en línea]. [ref. Octubre 2005]. Disponible en Internet: http://www.semiconfareast.com/microprobing.htm

[44] Gómez, Roberto. “Mejores Prácticas para confiscar evidencia electrónica”. [ref. Mayo

2006].Apuntes de la MCC ITESM Campus Estado de México. [45] Peikaru, Cyrus y Chuvakin, Antón. “Security Warrior”. Editorial: O´Reilly&Associates.

2004

http://www.informit.com/articles/article.asp?p=29732

http://www.linuxsecurity.com/content/view/111308/65/

http://fire.dmzs.com/

http://www.knoppix.org/

http://www.linux-forensics.com/downloads.html

http://www.asrdata2.com/

http://www.delitosinformaticos.com/delitos/ensayomexico.shtml

http://www.semiconfareast.com/microprobing.htm

166

ANEXO A

ARTICULO 211 bis CODIGO PENAL FEDERAL

ARTICULO 211 bis 1.- Al que sin autorización modifique, destruya o provoque pérdida de

información contenida en sistemas o equipos de informática protegidos por algún mecanismo de

seguridad, se le impondrán de seis meses a dos años de prisión y de cien a trescientos días multa.

Al que sin autorización conozca o copie información contenida en sistemas o equipos de

informática protegidos por algún mecanismo de seguridad, se le impondrán de tres meses a un

año de prisión y de cincuenta a ciento cincuenta días de multa.


información contenida en sistemas o equipos de informática del Estado, protegidos por algún

mecanismo de seguridad, se le impondrán de uno a cuatro años de prisión y de doscientos a

seiscientos días multa. Al que sin autorización conozca o copie información contenida en

sistemas o equipos de informática del Estado, protegidos por algún mecanismo de seguridad, se

le impondrán de seis meses a dos años de prisión y de cien a trescientos días de multa.

ARTICULO 211 bis 3.- Al que estando autorizado para acceder a sistemas y equipos de

informática del Estado, indebidamente modifique, destruya o provoque pérdida de información

que contengan, se le impondrán de dos a ocho años de prisión y de trescientos a novecientos días

de multa.

Al que estando autorizado para acceder a sistemas y equipos de informática del Estado,

indebidamente copie información que contengan, se le impondrán de uno a cuatro años de prisión

y de ciento cincuenta a cuatrocientos cincuenta días de multa.


información contenida en sistemas o equipos de informática de las instituciones que integran el

167

sistema financiero, protegidos por algún mecanismo de seguridad, se le impondrán de seis meses

a cuatro años de prisión y de cien a seiscientos días de multa.

Al que sin autorización conozca o copie información contenida en sistemas o equipos de

informática de las instituciones que integran el sistema financiero, protegidos por algún

mecanismo de seguridad, se le impondrán de tres meses a dos años de prisión y de cincuenta a

trescientos días de multa.

ARTICULO 211 bis 5.- Al que estando autorizado para acceder a sistemas y equipos de

informática de las instituciones que integran el sistema financiero, indebidamente modifique,

destruya o provoque pérdida de información que contengan, se le impondrán de seis meses a

cuatro años de prisión y de cien a seiscientos días multa.

Al que estando autorizado para acceder a sistemas y equipos de informática de las instituciones

que integran el sistema financiero, indebidamente copie información que contengan, se le

impondrán de tres meses a dos años de prisión y de cincuenta a trescientos días multa. Las penas

previstas en este artículo se incrementarán en una mitad cuando las conductas sean cometidas por

funcionarios o empleados de las instituciones que integran el sistema financiero.

ARTICULO 211 bis 6.- Para los efectos de los artículos 211 bis 4 y 211 bis 5 anteriores, se

entiende por instituciones que integran el sistema financiero, las señaladas en el artículo 400 bis

de este Código.

ARTICULO 211 bis 7.- Las penas previstas en este capítulo se aumentarán hasta en una mitad

cuando la información obtenida se utilice en provecho propio o ajeno [42].

168

ANEXO B

MICROPRUEBAS

Micropruebas (microprobing) o simplemente probing, es una técnica de análisis de fallas

utilizada para realizar contactos eléctricos o acceso a un punto en un circuito activo o muerto.

Emplea una pieza especial de equipo conocido como estación de microprueba, algunos ejemplos

se muestran en la siguiente figura:

Durante al análisis de circuitos en una micropruena, el analista emplea el mismo proceso de

análisis que en una falla de un circuito de gran tamaño. La microprueba es solo una herramienta

para que el analista acceda a nodos críticos o circuitos microscópicos mientras analiza el

comportamiento de varias partes del circuito.

169

Las mediciones de corriente y voltaje son realizadas por instrumentos de medición eléctricos

implementadas en el probador y manejadas a través de micromanipuladores, como los mostrados

abajo:

Instrumentos comunes son voltímetros, osciloscopios, fuentes de voltaje, generadores de onda. La

glassivation (deposición al final de la capa de pasivación, que protege de daños mecánicos y

corrosión) en la cubierta de un CI es removida por un grabado de iones reactivos (reactive ion

etching) antes de la prueba.

Las micropruebas también requieren de un diagrama esquemático del dispositivo para ser

efectivo y eficiente. El análisis necesita estos diagramas par apuntar inmediatamente a nodos

críticos para la prueba y aislamiento de la falla. Pero aún que el analista no esté familiarizado

con el funcionamiento del circuito y no tenga los diagramas, se puede llevar a cabo el análisis

correlacionando lo que es conocido y comparando voltajes y señales. La coordinación de ojos y

manos, así como la experiencia se necesitan para localizar un área de interés, elegir un punto de

prueba y ejercer la presión correcta par un buen contacto eléctrico [43].

170

ANEXO C

GLOSARIO Archivo de símbolos (Symbol File) Un archivo de símbolos contiene información de depuración similar a la que provee un archivo ejecutable, sin embargo, esta información es almacenada en un archivo debug (.dbg) o una base de datos de programas (program database - .pdb), mas que un ejecutable. Apología Discurso en el que se alaba o defiende a una persona o a una causa. BIOS (Basic Input/Output System) Es una memoria flash colocada en la mayoría de las computadoras donde se almacena los programas de entradas y salidas del sistema (BIOS). El BIOS asegura que todos los otros chips, discos duros, puertos y CPU funcionen juntos. Built in Self Test y algoritmos de prueba Es una técnica de diseño de hardware y software en circuitos integrados, que permiten la realización de auto pruebas. Checksum Es una forma simple de medición que protege la integridad de los datos detectando errores. Trabaja añadiendo un componente al mensaje y almacenando el valor resultante en el mensaje. Cluster de disco Es un grupo de sectores de disco. CMOS (Complimentary Metal Oxide Semiconductor) Tipo de material usado en la construcción de un chip. CRC (Cyclic Redundance check) Es un tipo de función hash usado para producir un checksum.

171

CYGWIN Es una colección de herramientas de software libre, que permite a varias versiones de Microsoft Windows actuar como un sistema UNIX. Deep Submicron Fabrication Technologies Esta tecnología habilita la creación de circuitos con decenas de millones de transistores. Las tecnologías de fabricación deep-submicron permiten a los ingenieros de diseño poner un número impresionante de componentes como microprocesadores, memorias e interfaces en un simple microchip. Depurar (debugging) Es un proceso metódico para encontrar y reducir el número de “bugs” o defectos de un programa o hardware electrónico. DFT (Design for Test) DFT (también referida como “structured test”) agrega transistores adicionales a la circuitería de un chip para hacer más fácil las pruebas sobre éstos. Utilizar una metodología DFT agrega trabajo y tiempo adicional al proceso del diseño, pero también puede eliminar tiempo significante en el programa de pruebas. Dieléctrico Sustancia aislante en la cual puede existir un campo eléctrico en estado estacionario. Esta sustancia tiene como principales características eléctricas su permitividad y su poder de aislamiento Dopante Elemento introducido en un semiconductor para establecer conductividad tipo p o n; comúnmente los dopantes de Si son para el tipo p Boro (B) y para tipo n Fósforo (P), Arsénico (As) y Antimonio (Sb). Eddy Current Non-Destructive Testing (Prueba NDT) La corriente de remolino (eddy) es creada a través de un proceso llamado inducción electromagnética. Cuando corriente alterna es aplicada a un conductor (alambre de cobre) un campo magnético es desarrollado alrededor del conductor, este campo magnético se expande cuando la corriente aumenta, si otro conductor eléctrico es acercado al campo se inducirá una corriente por el segundo conductor. La corriente de remolino es corriente eléctrica inducida que fluye en una trayectoria circular o de remolino. ELF (Executable and Linking Format) ELF (Executable and Linking Format) define el formato binario de default en los SO para Linux, Solaris y SVR. EOS- Electrical Overstress (Sobre-estrés electrica) Se refiere a la destrucción de circuitos debido a voltaje, corriente o potencia excesiva. ESD- Electrostatic Discharge (Descargas electrostáticas) Es un caso especial de EOS. Es una transferencia de carga electrostática entre dos objetos.

172

Excepciones Una excepción es una herramienta de programación útil para el manejo de errores. Cuando se encuentra un error (un caso excepcional), simplemente se manda una excepción. Las excepciones proveen una forma conveniente de manejar condiciones anormales. File descriptor Es un entero no asignado usado por un proceso para identificar un archivo abierto. Dos mil descriptores de archivos son disponibles por cada proceso. Las subrutinas “open, pipe, create y fcntl” generan descriptores de archivos. Los descriptores de archivos son generalmente únicos por cada proceso, pero pueden ser compartidos por sus procesos hijos creados con una subrutina “fork” .Los descriptores de archivos son indexados a una tabla de descriptores de archivos en un área mantenida por el kernel para cada proceso. Firmware Software (programas o datos) que han sido escritos para memorias de solo lectura (ROM). El firmware es una combinación de software y hardware. ROMs, PROMs y EPROMs que tienen datos o programas grabados son firmware. FireWIre (IEEE 1394) Estándar de bus externo que soporta velocidades de transmisión arriba de 400Mbps (1394a) y 800Mbps (1394b) Floating gate (en la memoria FLASH) Área central de almacenamiento de una celda de memoria FLASH, que es de 80 por 160 nanómetros. GDB (GNU Debugger) Es el depurador estándar de GNU. GNU (“GNU´s Not Unix”) Proyecto que involucra el desarrollo de software libre, permitiendo a los usuarios copiar modificar o redistribuir código. Hash (Función hash) Es una función (subrutina o secuencia de código que realiza tareas específicas) que convierte una entrada de gran rango en una salida de pequeño rango (valor hash). IDE/ATA (Integrated Drive Electronics/AT Attachment) IDE es una interfaz usada para controlar los discos duros, también es conocida con otra variedad de nombres como ATA, ATA/ATAPI, EIDE,ATA-2, Fast ATA, ATA-3, Ultra ATA, Ultra DMA, etc. Ionización La ionización es un mecanismo mediante el cual un electrón puede absorber suficiente energía para desprenderse de la estructura atómica y unirse a portadores libres en la banda de conducción. Interferómetro láser Aparato de medición de precisión sobre superficies planas hechas de cristal, metal y cerámica.

173

Kernel El módulo central del sistema operativo Latch Registro de instrucciones o registro de direcciones. Latch up es definido como la creación de una trayectoria de baja impedancia entre la energía de alimentación y la circuitería de salida. Es un caso especial de sobre-estrés eléctrico. Lógica Transistor-Transistor (TTL) El circuito básico de la compuerta TTL consiste de un transistor multiemisor de entrada y un transistor de salida. LKM (Loadable Kernel Module) El LKM permite al administrador del sistema agregar o remover funcionalidad a un sistema corriendo. Esta habilidad ayuda a los desarrolladores a crear nuevas partes del kernel sin tener que rebotear la máquina constantemente para probar los cambios. Malware (Malicious Software) Software diseñado para dañar o destruir un sistema, este puede ser un virus o un caballo de Troya. MD5 (Message Digest Algorithm 5) Es una función hash criptográfica que utiliza un valor hash de 128. MD5 ha sido utilizado en una amplia variedad de aplicaciones de seguridad y es referido al estándar de Internet RFC1321. Memory Stick Es un medio diseñado para grabar, compartir e intercambiar información digital, como fotografías, datos de computadora, música, imágenes, etc. Memoria RAM tipos La memoria RAM (Random Access Memory) es una forma de almacenamiento electrónico con la característica de ser rápida y temporal. Se clasifica en memorias RAM estáticas (SRAM, Static Random Access Memory) y memorias RAM dinámicas (Dynamic Random Access Memory) Memoria ROM Read Only Memory. Memoria de solo lectura MOSFET Tipo de transistor que compone una celda DRAM en serie con un capacitor, también es referido como transistor array-acces o dispositivo de transferencia. Object File u Object Code Es una representación intermedia de código generada por el compilador después de que procesa su código fuente. Un formato de archivo objeto es un formato usado para almacenar el código objeto y sus datos relacionados típicamente producidos por el compilador o ensamblador.

174

PDA (Personal Digital Assistant) Dispositivo móvil que combina organización y tecnologías de conectividad en un pequeño paquete. Se puede enviar correo, faxes o hacer llamadas telefónicas, contiene un software organizador para contactos y agenda. Portable Executable El formato PE es un formato de archivo ejecutable utilizado en versiones de Windows32 y 64. El termino “portable” se refiere a la portabilidad del formato a través de 32 bits. PE es una versión modificada del formato de archivos de Unix COFF. Port Mirroring También conocido como “Roving Analysis Port”, es un método para monitorear tráfico de red que envía una copia de cada entrada o salida de paquetes de un puerto de un switch a otro puerto, donde el paquete puede ser estudiado. Es una herramienta de diagnóstico. Pruebas funcionales Es el proceso que aplica vectores de un patrón a un dispositivo y verifica la salida para determinar si el dispositivo está operando acorde a su tabla de verdad (Pruebas paramétricas). También puedes ser el proceso de probar un dispositivo para identificar su habilidad en la realización de sus funciones (ejemplos: lectura/escritura de pruebas de memoria, pruebas de conversión analógico digital, etc.) Prueba paramétrica Es el proceso de probar un dispositivo con respecto a sus especificaciones para medidas con características eléctricas como lo es voltaje o corriente. Rootkit Herramientas normalmente en software que se utilizan para comprometer un sistema de cómputo “sin detectarse”. Un programa para “hackear” root. SCSI (Small Computer System Interface) Es un bus de alta velocidad (arriba de 160 Mbps) para conectar componentes en estaciones de trabajo y equipos de cómputo, entre los componentes se encuentras: discos duros, escaner, CD-ROM, impresoras, etc. Señales Las señales son usadas para notificar un proceso o hilo de un evento particular. Las señales se describen como una interrupción de software. Cuando una señal es enviada a un proceso o hilo, un manejador de señal entra en funcionamiento de manera similar al trabajo desarrollado por un manejador de interrupciones en cuestión de hardware. SHA (Secure Hash Algorithm). Es un conjunto de funciones cirptográficas hash. La más común es SHA-1, que es empleada en una gran variedad de aplicaciones de seguridad y protocolos incluyendo IPSec, PGP y SSH. SHA-1 es considerado a ser el sucesor de MD5. Slack space Espacio no usado en un disco o cluster de discos.

175

.sig archivos Es un bloque corto de texto al final de un mensaje identificando el emisor del mensaje y provee información adicional acerca de él. Símbolos en Windows Un símbolo es un nombre que representa un registro o un valor absoluto o una dirección de memoria absoluta o relativa. Los símbolos son generados por el compilador, explican la relación entre el código fuente y objeto. Los módulos y símbolos de Windows proveen información diferente dependiendo del depurador que esté corriendo. Los símbolos obtienen las direcciones hexadecimales del procedimiento. Un símbolo se asigna cuando se crea un objeto de un recurso en la programación de Windows. Sistema de Archivos (File System) Es un método para almacenar y organizar los archivos y datos para acceder a ellos y encontrarlos fácilmente. Tipos de sistemas de archivos pueden ser de disco, red o base de datos. Sistema de Archivos de disco Almacena los archivos y datos por un controlador de disco, que puede estar conectado directa o indirectamente a la computadora. Algunos ejemplos son: FAT (File Allocation Table) Desarrollado por MS-DOS para consumidores de Windows Microsoft. NTFS (New Technology File System) Es un sistemas de archivos estándar para WinNT, 2000 y sus descendientes Ext2 (Second Extended File System) Fué un sistema de archivos estándar utilizado en SO Linux ISO 9660 Define un sistema de archivos para CDROM ODS-5 o Files 11 (On-Disk Structure) Es el sistema de archivos utilizado por Hewlett Packard para el SO OpenVMS. UDF (Universal Disk Format) Es una especificación de formatos para almacenar archivos en medios regrabables. UFS (Unix File System) Es un Sistema de archivos utilizado por Unix. CDFS (Compact Disc Files System) ReiserFS Sistema de archivos de propósito general. Actualmente soportado por Linux. Sistema de Archivos de red También conocido como sistema de archivos distribuidos, es un sistema de archivos donde los archivos son accedidos mediante la red, con la finalidad de estar compartidos por varias computadoras. Ejemplos son: NFS (Network File System) Comparte archivos sobre la red en base a UDP CIFS (Common Internet Files System) Versión de Microsoft del SMB (Server Message Block) que es un protocolo de red para compartir archivos, impresoras y puertos seriales en la red. Lustre Es un sistema de archivos Open Source, generalmente utilizado por clusters. Global File System Sistema de archivos para clusters. Sistema de Archivos de bases de datos Es un nuevo concepto de administración de archivos en base a archivos de bases de datos. En lugar de utilizar una estructura jerárquica, los archivos son identificados por sus características como tipo de archivo, tópico, autor, etc. Ejemplos son: Gnomo Storage y WInFS.

176

State-of-the-art El nivel de desarrollo (de un dispositivo, procedimiento, proceso, técnica o ciencia) alcanzada a una fecha en particular frecuentemente como resultado de métodos modernos. Temperatura Tjunction Temperatura de empalme PN o límite de transición entre materiales tipo P y tipo N en un dispositivo semiconductor. Time stamp Prueba inequívoca de que el contenido de tu trabajo existió en un punto en el tiempo y que el contenido ha tenido cambio desde esa fecha. Transconductancia Es una expresión del rendimiento de un transistor bipolar o un FET (field effect transistor). En general, la transconductancia se mide por la capacidad de ganancia (amplificación) que el dispositivo es capaz de generar, cuando todos los demás factores permanecen constantes. USB (Universal Serial Bus) Bus externo que soporta velocidades de 12 Mbps. Permite conectar diversos periféricos y sustituye el bus serial y paralelo. USB2 soporta velocidades de 480Mbps. VLSI (Very Large Scale Integration) Término que describe circuitos integrados compuestos de cientos de elementos lógicos o celdas de memoria.

METODOLOGÍA PARA LA RECOLECCIÓN DE DATOS · PDF fileAtizapán de...

Documents

Transcript of METODOLOGÍA PARA LA RECOLECCIÓN DE DATOS · PDF fileAtizapán de...