COMO SALTARSE EL FIREWALL DE MANERA SIGILOSA.....

Tabla de contenidos:
-Introducción
-Cómo funcionan los cortafuegos
-Infección de procesos sin .dll externa
-Problemas de implementación
-cómo implementarlo
-Limitaciones de esta implementación
-Workaround: otro método de infección
-Conclusión
-Últimas palabras

-Referencias/bibliografía

-Inyector de código fuente
-Código para la evasión del Tiny
-Binarios (base64)

:_Introducción_________________________________________________________________________________________________________

Este documento se refiere a una característica de los cortafuegos de software disponible en
los sistemas operativos Windows, que se llama "outbound detection". Esta característica no
tiene nada que ver con la idea original de un cortafuegos, bloquear paquetes entrantes
provenientes de la red: el mecanismo "outbound detection" tiene como misión proteger al usuario
de programas malignos que se ejecutan en su máquina - programas tratando de comunicarse con un
host remoto y por tanto dejando al descubierto información sensible, la detección de salida
(nota del traductor: no se cómo traducir ese término "outbound detection", así que lo llamaremos así
a partir de ahora) controla la comunicación de las aplicaciones con Internet.

En un mundo donde no para de crecer el número de troyanos, gusanos y virus expandiéndose por la red,
es una característica muy buena. Sin embargo, desde que conozco la existencia de los cortafuegos,
me he estado preguntando si realmente proveen un cierto nivel de seguridad. Al fin y al cabo,
sólo es software que se supone que te protege de otro software, y eso suena como una mala idea.

Acortando: esta detección de salida puede ser evitada, y eso es lo que se discutirá en este texto.
Además creo que si se puede saltar esta seguridad, también se pueden saltar otras restricciones.
Los cortafuegos personales son software tratando de controlar otro software, y en cierto caso,
será posible darlo un giro de 180º a esto, y crear un software que controlase el cortafuegos.

Cómo conseguir esto será parte de la discusión que continúa. No hablaré sólo de teoría, sino que ilustraré el tema
con código fuente de ejemplo para saltarse un cortafuegos inyectando código a un proceso de prueba.
Puede parecerte interesante que el método de infección de que se presenta no necesite una dll externa
- el "bug" se puede practicar desde un ejecutable único y diminuto.

Además, este tema va sobre coding (programacion), especialmente win32 coding. Para entender el código fuente deberías estar
familiarizado con windows, la API de windows y ensamblador básico. También sería conveniente conocer
algo de la estructura PE (Portable Ejecutable) y cosas relacionadas, pero no será del todo necesario.
Intentaré explicar todo lo que pueda lo más precisamente posible.

Nota: Si encuentras números encerrados entre paréntesis en el texto, estos números son referencias a futuros documentos.

:_Cómo funcionan los cortafuegos____________________________________________________________________________________

Por supuesto, sólo puedo hablar de los cortafuegos que he visto y probado hasta ahora, pero estoy seguro de que estas
aplicaciones están entre las más utlizadas. Como todos los cortafuegos funcionan de una manera muy parecida,
asumiremos que el concepto es el concepto de los cortafuegos en general.

Casi todo el software moderno tienen características que simulan el comportamiento de los cortafuegos de hardware permitiendo
al usuario bloquear puertos. No he echado un vistazo en profundidad a estas características y una vez más quiero enfatizar que
romper estas protecciones se encuentra fuera de lugar en este documento.

Otra característica importante de la mayoría de los cortafuegos personales es el concepto de dar privilegios y diferentes niveles
de confianza a los diferentes procesos que se ejecutan en la máquina para proporcionar una medida de "outbound detection". Una vez
que un determinado ejecutable crea un proceso intentando acceder a la red, al archivo ejecutable se le hace un cheksum por el
cortafuegos, y al usuario le aparece una ventana donde se le da a elegir si permitirá la comunicación con el exterior de dicho proceso o no.

Para acelerar esta tarea, el cortafuegos probablemente habrá instalado unos drivers en el kernel y hooks
(Nota del traductor: hook significa "gancho", se puede interpretar como un dispositivo parecido a un sniffer, que sólo se dedica a
leer los datos y a dejarlos pasar. Además, hay que recordar que los hooks al teclado se utilizan en los keyloggers.)
para monitorizar e interceptar llamadas a rutinas de un nivel bajo de la red (Nota del traductor: recordad el modelo OSI del taller TCP/IP)
que son provistas por el núcleo del S.O. Así, un usuario puede permitir a un proceso conectar "connect()" a otro host de la red, escuchar "listen()",
o realizar otras tareas de la red. El punto principal de esto es:TAN PRONTO COMO EL USUARIO DA PERMISO A UN EJECUTABLE; TAMBIÉN DA PERMISO
A CUALQUIER OTRO PROCESO CREADO POR ÉSTE. Sin embargo, una vez que cambiemos el ejecutable, éste ya no concordará con el checksum qe tenía antes,
y el cortafuegos dará una alerta.

Como resumen, el cortafuegos dará permiso a un proceso mientas el ejecutable que lo ha creado permanezca igual. También sabemos que en muchos casos,
un usuario dará permiso a su navegador web y a su cliente de correo....jejejejeje

:_Infección de procesos sin .dll externa_____________________________________________________________________________________

El cortafuegos sólo calculará y analizará el checksum para un ejecutable que acabe de crear un proceso. Después de que lo haya creado,
se supone que permanecerá igual hasta que la conexión termine.

Y desde que llevo hablando de la infección de procesos en tiempo real, creo que habrás adivinado lo que vamos a hacer.
Si no podemos alterar el ejecutable, iremos directamente al proceso e inyectaremos nuestro código en su memoria, ejecutarlo desde allí
y saltarnos la protección del cortafuegos.

A lo mejor he ido un poco rápido, no problem. Un proceso se carga en la memoria RAM por el S.O., en cuanto un archivo binario, ejecutable se ejecuta
(valga la redundancia). De manera más simple: un proceso es una cadena de datos binarios que ha sido situada en una dirección de memoria determinada.
De hecho, es mucho más que una cadena que el S.O. sitúa en una dirección de memoria, pero por el momento, nada de eso importa.

Para todos aquellos que estéis familiarizados con lo que significa la infección de un ejecutable - realmente no me gusta la inyección de dll's para este propósito,
simplemente porque no hay ninguna otra opción que pueda ser considerada menos elegante.

En la práctica, la inyección de dll's significa que el ejecutable que se salta la protección de alguna manera transporta la dll adicional.
Esto no significa sólo que se produzca un aumento significativo del tamaño del programa, sino que esta dll también tiene que ser escrita en el
disco duro del sistema afectado, y para ser honestos: si de verdad vas a escribir un programa que se salte la protección del cortafuegos, querrás evitar este tipo de problemas.
Por lo tanto, el método aquí presentado funcionará sin necesidad de una dll externa, estará escrito en ensamblador (x86) y lo mejor de todo es que ocupara poco espacio.

En resumen, todo lo importante para nosotros por ahora será la habiliadad de tener acceso a la zona de memoria del proceso, copiar nuestro código en ella
y ejecutarlo remotamente en el contexto de ese proceso.

¿Suena complicado? No del todo. Si tienes un buen conocimiento de la API Win32, también sabrás que Windows proporciona todo lo necesario al programador
para realizar dicha tarea. La llamada más importante a la API que se viene a la cabeza probablemente sea: CreateRemoteThread().
Citando MSDN (1):
La función CreateRemoteThread crea un hilo que se ejecuta en el espacio de memoria de otro ejecutable.

Código:

HANDLE CreateRemoteThread(
HANDLE hProcess,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
DWORD dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);



Perfecto, ahroa podemos ejecutar código en una dirección de memoria determinada dentro de otro proceso
e incluso podemos pasarle una variable DWORD como parámetro. Para eso, además necesitaremos las dos siguientes llamadas a la API:
Código:

VirtualAllocExec()
WriteProcessMemory()



Estas funciones nos darán la capacidad de inyectar nuestro propio código arbitrario en la dirección de memoria de otro proceso, y
una vez que esté allí, crearemos un hilo remotamente para ejecutar lo que esté allí.

En resumen: crearemos un ejecutable binario que contendrá el código de inyección así como el código que se ejecutará y se saltará la protección del cortafuegos.
O, hablando en lenguaje de programación de alto nivel: crearemos un archivo ejecutable que contiene dos funciones, una para inyectar el código en un determinado proceso,
y la otra será la función que será inyectada.

:_Problemas de implementación_____________________________________________________________________________________________________________

Hasta ahora todo suena muy bonito, pero no lo es. Por ejemplo: difícilmente serás capaz de escribir una aplicación en C que de manera eficiente
inyecte otra función C (static). De hecho, puedo casi garantizarte que el proceso remoto se bloqueará. Aunque puedes llamar a las principales funciones
de la API desde C, hay muchos problemas en los lenguajes de alto nivel para este propósito.
La esencia de los problemas de los lenguajes de alto nivel se puede resumir de la siguiente manera: los compiladores producen código en ensamblador que utilizan offsets
ya predefinidos (Nota del traductor: en inglés, hardcoded offsets, aunque en un principio no supe a lo que se refería, está bien explicado en las líneas siguientes).
Un ejemplo: cuando usas una cadena constante en C, esta cadena seá almacenada en una determinada posición del ejecutable resultante de la compilación.
Esto quiere decir que cuando tu proceso necesite pasar esta constante a una función, la dirección ya estará predefinida en el ejecutable.

Considera lo siguiente:

Código:

void main() {
printf("Hello world" ;
return 0;
}



Suponiendo que la cadena "Hello world" se encuentra almacenada en el offset 0x28048 dentro de tu ejecutable, y que el ejecutable se cargue en
la dirección 0x00400000, el código binario de tu ejecutable compilado y enlzado se referirá a la dirección 0x00428048 en algún lugar.

El desensamblado de dicha aplicación, compilado con VisualC++ 6, sería así:

Código:

00401597 ...
00401598 push 0x00428048 ; la cadena "hello world"
0040159D call 0x004051e0 ; dirección de la función printf
0040159E ...



¿Cuál es el problema con este tipo de direcciones? Si permaneces dentro de tu propia dirección, no hay problema. Sin embargo, cuando mueves
ese código a otra dirección de memoria, todas esas direcciones internas del ejecutable apuntarán a otras direcciones de la memoria.
La cadena hello world en mi ejemplo esta 0x2000 = 131072 bytes más alejada del código del programa. Así que si inyectas código en el espacio
de otro proceso, tienes que asegurarte de que en 0x00428048 hay una cadena C válida...incluso si había algo parecido a una cadena C, probablemente
no será "Hello world". Espero que pilléis este punto.

Esto no es nada más que un simple ejemplo y no abarca todos los problemas que pueden ocurrir, sin embargo, las direcciones de todas las funciones
también están definidas, como la dirección de "printf" en nuestro ejemplo.En el espacio de otro proceso, estas funciones pueden estar en cualquier
otro lugar o incluso podrían no aparecer, y esto conduce a los errores más absurdos que puedas imaginar. La única manera de asegurarse de que todas
las direcciones son correctas, y de que cada instrucción de la Cpu cabe, es escribir el código en ensamblador.

Nota: Hay varios métodos de saltarse la proteccion de los cortafuegos por medio de la inyección de librerías dinámicas.
Esto consiste en lo siguiente: el ejecutable fuerza a un proceso a cargar la dll, y una vez que la dll ha sido cargada en
el espacio de memoria del otro proceso, ella misma ejecuta el código arbitrario para la tarea que queramos realizar en la red.
Este procedimiento para saltarse la protección del cortafuegos funciona muy bien y puede ser implementada con lenguajes de alto nivel de una manera fácil,
pero no me gusta la dependencia de una dll externa,como ya expliqué antes así que decidí escribir el código de una solución, en la que la inyección la hace
el propio ejecutable.

Además, LSDUMP usa exactamente la misma medida para grabar los secretos LSA desde el LSASS.EXE, y está escrito en C.

:_Cómo implementarlo_________________________________________________________________________________________________________________________

Hasta ahora, todo es teoría, pero en la práctica encontrarás multitud de problemas cuando escribas un código como este.
Incluso tendrñas que tratar con detalles que tienen poco que ver con el problema en si. Vamos a dejar la parte abstracta detrás y vamos a pensar
cómo escribir semejante código.

Primero, queremos evitar al máximo las direcciones definidas. Y lo primero que necesitamos es saber la ruta del navegador del usuario. EN vez de buscar el archivo,
consultaremos la clave del registro: "HCKR\htmlfile\shell\open\command".

Lo siguiente que hay que hacer es llamar a la función de la API, CreateProcess(). El valor wShowWindow de la estructura STARTUP_INFO pasada a la función debería ser
SW_HIDE, con el objeto de mantener la ventana del navegador escondida.

Nota: Si quieres asegurarte completamente de que no se mostrará ninguna ventana en la pantalla, podrías, por ejemplo, crear un hook para mantener todas las ventanas
que son creadas por el proceso escondidas. Sólo he probado mi ejemplo con Internet Exlorer, y el truco SW_HIDE funciona correctamente,
de hecho, debería funcionar en cualquier aplicación con una interfaz gráfica más o menos normal.

Para asegurarnos de que el proceso ha cargado ya todas las librerías necesarias, y que ha alcanzado un nivel estable, utilizaremos la función WaitForInputIdle(), para darle tiempo
a la aplicación a estabilizarse.

Ahora procedemos a llamar a la función VirtualAllocExec(), para colocar memoria en los procesos creados
y WriteProcessMemory() para copiar nuestro código que trabajará en la red (aquel que hará como puerta trasera/troyano)
Finalmente usaremos CreateRemoteThread() para ejecutar el código, y entonces, sólo tenemos que esperar a que termine el hilo.
Al fin y al cabo, la inyección en sí no es tan complicada.

La función que será inyectada sólo puede recibir un argumento, una palabra doble. En el ejemplo que se presentará, el procedimiento infectado
se conectará a www.phrack.org por el puerto 80 y enviará HTTP GET para recibir la cabecera. Tras recibir la cabecera, la mostrará un mensaje. unque es un ejemplo muy básico, el procedimiento no necesita más información.

De todas maneras, todavía tenemos que usar el parámetro para pasar el valor de 32 bits (una palabra doble) a nuestro procedimiento inyectado:
su dirección base. Con eso, el código inyectado sabe en que dirección de memoria ha sido situado, en el contexto del otro proceso.
Esto es muy importante porque no pordemos leer directamente del registro EIP, y porque nuestro código inyectado tendrá que acceder a direcciones de memoria de estructuras
de datos dentro del código inyectado.

Una vez inyectado y situado dentro del procedimiento remoto, el código inyectado practicamente no sabe nada. La primera tarea que realizará será buscar
la dirección base de la librería kernel32.dll en el espacio de memoria del procedimiento remoto, y desde allí, la dirección de la función GetProcAdress() para cargar
cualquier otra cosa que necesitemos.. No explicaré en detalle cómo se consiguen estos valores, todo no se puede cubrir en este documento.
Si estás interesado en detalles, te remito al documento sobre los componentes de win32 en el ensamblador, del grupo Last Stage of Delirium. He utilizado grandes partes de su documento para la escritur del código que
se describirá en los párrafos siguientes.

En términos simples, conseguimos la dirección base de kernel32.dll de la estructura Process Environmente Block (PEB), la cual se puede encontrar dentro de la estructura
Thread Environment Block (TEB). La dirección del offset del TEB siempre se almacena dentro del registro FS, así que es sencillo conseguirla.
Y desde que sabemos que el kernel32.dll se ha cargado, sólo tenemos que encontar la dirección de GetProcAdress(). Si no estás familiarizado con el formato PE, no te preocupes.

Una librería de enlace dinámico contiene una "sección de exportación". En esta seción, a los offsets de todas las funciones exportadas se les asigna nombres legibles para los humanos,
es decir, cadenas. De hecho, hay dos arrays (matrices o estructuras) que nos interesan. Hay más de dos arrays dentro de esta sección, pero a nosotros sólo nos interesan dos de ellas.
Durante el resto del documento, trataré los términos lista y array igualmente, puesto que a este nivel de programación no hay diferencia.
El primer array es una lista de cadenas estándar de C, que contienen los nombres de las funciones. El otro array contiene los puntos de entrada de las funciones,
es decir, los offsets.

Haremos algo muy parecido a lo que GetProcAdress() hace: buscaremos "GetProcAdress" en el primer array y encontraremos su offset en la segunda lista.

Desafortunadamente, a Microsoft se le ocurrió una idea para la exportación de sus DLL's, y esto se torna mucho más complicado. Esta idea consiste en los punteros
(Nota del traductor: se refiere a "forwarders", lo he traducido a "punteros" porque creo que está relacionado con los punteros de ciertos lenguajes de programación y porque era lo más "parecido"
al castellano. Originalmente "forward" quiere decir "adelante" , y básicamente quiere decir que una dll puede traspasar la función a otra dll.
En vez de apuntar al offset del código de una función dentro de una dll, el offset del segundo array apunta a una cadena. Por ejemplo:
la función HeapAlloc() de la librería Kernel32.dll apunta a la función RtlAllocoteHeap() de la librería ntdll.dll.
Esto siginifica que el citado offset de HeapAlloc() en kernel32.dll no serña el offset de una función que ha sido implementada en kernel32.dll, sino que será el offset de una cadena que ha sido situada dentro de kernel32.dll.
Esta cadena es: "NTDLL.RtlAllocateHeap".


Después de un rato, me di cuenta de que este puntero/cadena está situado inmediatamente después del nombre del función en el primer array.
Dentro de kernel32.dll se encontraría algo así:

Cita:

48 65 61 70 41 6C 6C 6F HeapAllo
63 00 4E 54 44 4C 4C 2E c.NTDLL.
52 74 6C 41 6C 6C 6F 63 RtlAlloc
61 74 65 48 65 61 70 00 ateHeap.

= "HeapAlloc\0NTDLL.RtlAllocateHeap\0"



Esto es por supuesto un poco confuso porque hay más cadenas en el primer array que offsets en el segundo - cada puntero parece el nombre de una función.

Para identificar la cadena "GetProcAdress", hago uso de una función hash para cadenas cortas del grupo LSD. La función hash es así en C:

Código:

unsigned long hash(const char* strData) {
unsigned long hash = 0;
char* tChar = (char*) strData;
while (*tChar) hash = ((hash<<5)|(hash>>27))+*tChar++;
return hash;
}



El hash calculado para "GetProcAdress" es 0x099c95590, y nosotros buscaremos una cadena en la sección de exportación (Nota del traductor: la de los dos arrays)
de kernel32.dll que coincida con el hash. Una vez que tenemos la dirección del GetProcAddress() y la dirección base de kernel32 podemos cargar
fácilmente todas las llamadas a la API que necesitemos. A partir de aquí, todo lo que tenemos que hacer es cargar la librería ws2_32.dll para utilizar los sockets.

Nota: Recomendaría leer [0x0B] ahora.

:_Límites de la implementación_____________________________________________________________________________________________________________

El código de ejemplo presentado dará un ejecutable que se ejecuta en el ring 3 (Nota del traductor: En la revista 18 hay un artículo sobre Virus,
en cuyo apartado 2.1.5 se habla de los privilegios o "rings" . Estoy seguro de que la mayoría de los cortafuegos contienen drivers en modo kernel
con la capacidad de ejecutar tareas más poderosas que este ejecutable inyector, por tanto, la capacidad de este ejecutable de saltarse la protección es limitada.
Lo he probado en los siguiente cortafuegos con los siguientes resultados:


Zone Alarm 4 vulnerable
Zone Alarm Pro 4 vulnerable
Sygate Pro 5.5 vulnerable
BlackIce 3.6 vulnerable
Tiny 5.0 immune


Tiny alerta al usuario de que el ejecutable inyector se "acopla" al proceso del navegador, intentado acceder a la red de esta manera. Parece que Tiny
actúa como todos los demas cortafuegos, pero simplemente es un poco más cuidadoso. Tiny, además, le hace un hook a la función CreateProcess() y CreateRemoteThread(),
por lo tanto, puede proteger a los usuarios de este tipo de ataques.

De todas maneras, por el resultado de las pruebas, confirmé que los cortafuegos actúan como módulos del kernel.

Así que no he presentado un ataque 100% efectivo, es sólo un ejemplo.

:_Otro método de infección____________________________________________________________________________________________________________________

El equipo de Phrack sugirió presentar un análisis sobre el problema de la infección con Tiny, pero supe que este no es el único problema
con el que hay que tener cuidado, ya que Tiny le hace un hook a la función CreateRemoteThread(). Desafortunadamente, estaba en lo correcto, y el simple hecho de
infectar un proceso que ya está ejecutandose hace saltar la alarma del cortafuegos tiny.

De todas maneras, aún hay más maneras de forzar la ejecución de nuestro propio código inyectado, y explicaré brevemente en que consiste este
método para aquellos que estén interesados. Lo que estoy intentando demostrar es que se pueden superar las restricciones de los cortafuegos mediante un esfuerzo a la hora
de escribir el código.

Las API's principales que utilzaremos serán GetThreadContext() y SetThreadContext(). Estas dos funciones poco documentadas te permiten modificar el contexto de un proceso.
¿Qué es el contexto de un proceso? El contexto es una estructura que contiene el valor actual de cada uno de los registros de un determinado proceso. Por lo tanto, con estas dos funciones
puedes obtener el valor de los registros, y, lo que es más importante, aplicar nuevos valores a cada uno de los registros de la CPU del proceso remoto.
De gran interés para nosotros es la posibilidad de modificar el registro EIP, el puntero de instrucciones de un hilo. (Nota del traductor: En el número 23 de la revista
hay un artículo interesante sobre Buffers Overflows en el que se explican detalladamente los registros, punteros, direcciones de memoria...Lectura recomendad )

Bueno, lo primero, fácilmente encontraremos un proceso al que se le permita la comunicación con la red.
Entonces, como siempre, inyectaremos nuestro código en su memoria con los métodos explicados anteriormente. Esta vez, sin embargo, no crearemos un nuevo hilo,
sino que secuestraremos el hilo primario del proceso de confianza para el cortafuegos y modificaremos el EIP para que apunte a nuestro propio código.

Esa es toda la teoría que hay detrás de este segundo método. En la práctica, procederemos de manera lo más cuidadosa posible para que el código sea lo más robusto posible.
No sólo escribiremos la función de inyección, sino varios códigos en ensamblador, con el fin de devolver al proceso inyectado a su estado
inicial después de que el nuestro haya terminado su trabajo. Cómo puedes ver, vamos a insertar una cadena de shellcode [0x0c] al proceso, que es así en un debugger:

Cita:

<base + 0x00> PUSHAD ; guarda todos los registros
<base + 0x01> PUSHFD ; guarda todas las flags (banderas)
<base + 0x02> PUSH <base + 0x13> ; primer argumento: dirección propia
<base + 0x07> CALL <base + 0x13> ; llama al código inyectado
<base + 0x0C> POPFD ; recupera las banderas
<base + 0x0D> POPAD ; recupera los registros
<base + 0x0E> JMP <orignal EIP> ; recupera el estado inicial (contexto)
<base + 0x13> ... ; el código de la función inyectada empieza aquí



Recuerda, este código será inyectado en una dirección de memoria (offset) muy alejada del contexto inicial del proceso.
Por eso vamos a necesitar un número de 4 bytes para la dirección relativa que necesitamos en el JMP.

Esta es una solución simple para evitar que nuestro proceso de confianza del cortafuegos se bloquee tras haber
ejecutado el código inyectado. Es más, decidí usar un evento que salta cuando el proceso inyectado ha recibido la cabecera HTTP.
De esta manera, el ejecutable inyector es informado una vez que la rutina que hemos inyectado ha terminado su trabajo.
Podemos desalojar ese espacio de memoria remoto y de esta manera realizar una "limpieza". EL sigilo lo es todo.

Debería decir que este método es un poco más frágil y menos fiable que el método mostrado anteriormente.
Este último método explicado funcionará con todos los cortafuegos que he probado y muy probablemente con
todos los demás. Pero de todas maneras debes tener en cuenta que para que estos ataques funcionen, hemos dado por hecho
que el Internet Explorer tiene acceso a internet, sino...búscate la vida con otro programa.

He probado este ataque junto con el Internet Explorer, pero otras aplicaciones podrían no reqerir que secuestraras el hilo primario
El hilo primario normalmente es una apuesta fiable porque asumimos que no se bloqueara en el momento de la infección, aunque
teóricamente podría ocurrir que la interfaz del programa se bloquease de repente porque el código inyectado se ejecuta más que el
código que trata de ejecutar el programa. Con este ejemplo tan simple e Internet Explorer, no me topé con dichos programas.
También funciona con "Outlook.exe", así que creo que se puede considerar un método bueno y estable.

:_Conclusión_______________________________________________________________________________________________________________________________
Creo que puedo estar contento con los resultados que he obtenido. Aunque el ejecutable inyector es inferior a cualquier cortafuegos con
módulos en el kernel, creo que funcionará con el 80% de los firewalls.

Mi segundo método incluso funciona contra todos ellos. Ambos ejemplos simnplemente mandan una petición de la cabecera HTTP, pero
sería relativamente fácil que hiciesen cualquier otra tarea en la red. Por ejemplo, mandar un e-mail con información crítica
se podría hacer casi de la misma manera. El código sólo tendría que ser un poco más sosfisticado y grande que el provisto aquí.

Teniendo en cuenta que he conseguido esto con una aplicación 5k (Nota del traductor: 5k ¿? (5k user-mode application))
estoy seguro de que será más fácil con un programa ejecutándose en el Ring 0, haciendo hooks a las llamadas de bajo nivel.
Quien sabe, quizás alguien que hizo el mismo tipo de investigación esté utilizando ya esta técnica. La conclusión general es que los
cortafuegos son inseguros. Y estoy muy de acuerdo con esta generalización: el problema de los cortafuegos es
el concepto, no la implementación.

El software no te puede proteger de otro software sin estar en constante riesgo de ser "esquivado" por otro software.

¿Porqué es esto un riesgo? Este es de hecho un gran riesgo porque los cortafuegos de hardware se están utilizando en estaciones windows
de manera generalizada. Dentro de una red, es común encontrar ambos cortafuegos, hardware y software. Además los cortafuegos de software
en dichas redes sirven al propósito de defender la red de troyanos y puertas traseras. Y, después de lo que hemos visto,
esta protección es muy débil.

Aparte del peligro de los ordenadores privados, que se ha demostrado que están insuficientemente protegidos contra troyanos y gusanos,
la explotación de un sistema remoto usando un cortafiegos puede abarcar los métodos descritos en este documento. El código en
ensamblador de cualquiera de los métodos se puede convertir en una shellcode para cualquier exploit remoto.
Una vez que hemos descubierto una vulnerabilidad en un sistema remoto, sería posible también saltarse la protección del cortafuegos así.

Las aplicaciones de ejemlo se conectan a www.phrack.org por el puerto 80, pero podrías hacer incluso que se conectasen a tu IP.