<-!-> FAQ - Biblioteca - Recopilatorio de Shellcodes - ¡Leer!

Iniciado por Rojodos, 8 Enero 2004, 23:13 PM

0 Miembros y 2 Visitantes están viendo este tema.

Rojodos

Para una introducción a lo que se trata en este subforo ve a: Taller de Introduccion a Bugs y Exploits

Para una introducción a las vulnerabilidades de stack overflow ve a: Taller de Stack Overflows en Windows

Para una introducción al análisis de vulnerabilidades binarias usando GDB ve a: Uso de GDB para analizar programas sencillos, complejos y vulnerabilidades






FAQ - EXPLOITS

-- BUGS --

Los bugs son fallos en el diseño / implementacion de software (fallos en la programacion normalmente) o hardware (fallos de diseño o de montaje). Estos fallos pueden comprometer al soft/hard, permitiendo que un atacante consiga algun privilegio, alguna informacion, o realize alguna accion para lo que el sistema no estaba programado / implementado.

Por ejemplo, el bug UNICODE de los windows (mas bien en los IIS...), permitia a los que visitaban una web pudieran acceder al directorio principal del disco duro donde estaba alojada la web, y ejecutar una shell con sus respectivos comandos.

Normalmente, los bugs en si no dan nada a los hackers, sino que estos programan "exploits" con los que atacar estos bugs (explicado en EXPLOITS en esta FAQ). Nuevamente, como ejemplo, las contraseñas de los Windows usando LM (LanManager) tienen varios bugs de diseño y algoritmizacion, que hacen que la contraseña no sea tan dificil de romper como deberia. Muchos crackeadores se basan en estos bugs para crackear dichas contraseñas rapidamente. El bug en si no permite nada, pero un exploit basado en ese bug si que lo permite.

Obviamente el caso del UNICODE por ejemplo no necesita exploit (aunq los hay) porque los chicos de Windows se lo curran mucho en la seguridad xDDDD

Hay bugs en los que el hacker no puede conseguir nada (informacion, privilegios) pero puede atacar a la makina, provocando un mal funcionamiento o incluso su caida o reinicio. Esto es llamado DoS (Denial of Service, Denegacion de Servicio).

La palabra "bug" es "bicho" en ingles, y viene de que una polilla (otros hablan de cucarachas) se instalo en la valvula de vacio de un ordenador antiguo (esos que ocupaban una habitacion entera) debido al acogedor calor que emitia. De ahi tambien viene Debugear o Debug, que es buscar el jodido bicho xD. En makinas, se refiere a la depuracion en ejecucion de un programa para encontrar los fallos del mismo.

-- EXPLOITS --
Que Son y ejemplos:
http://www.elhacker.net/exploits/

Como se usan:
http://foro.elhacker.net/index.php?board=32;action=display;threadid=11830

-- SHELLCODES --

http://foro.elhacker.net/index.php?board=32;action=display;threadid=16513

http://www.elhacker.net/exploits

RECOPILACION DE POST INTERESANTES:

BoF en inet network afecta a BIND por Anon
http://foro.elhacker.net/bugs_y_exploits/bof_en_inetnetwork_afecta_a_servidor_dns_bind-t196923.0.html

Analisis de un Bug: 'imlib2' Library 'load()' CVE-2008-5187 por Anon
http://foro.elhacker.net/bugs_y_exploits/analisis_de_un_bug_imlib2_library_load_cve20085187-t237384.0.html

- Mi primera shellcode para un exploit -
http://foro.elhacker.net/index.php/topic,12032.0.html

- Explotando el bug de buffer overflow remoto (NSIISlog.DLL)
http://foro.elhacker.net/index.php?board=32;action=display;threadid=15919

- Aprendiendo Buffers Overflow
http://foro.elhacker.net/index.php?board=32;action=display;threadid=21086

- Como se Usan los Exploits?????
http://foro.elhacker.net/index.php?board=32;action=display;threadid=11830

- Mini manual del concepto exploit
http://foro.elhacker.net/index.php?board=32;action=display;threadid=18915

- Offsets en overflows
http://foro.elhacker.net/index.php?board=32;action=display;threadid=17319

- que es una shellcode?
http://foro.elhacker.net/index.php?board=32;action=display;threadid=16513

- buffer overflow // Desbordamiento de Buffer

http://foro.elhacker.net/index.php?board=32;action=display;threadid=6838

http://foro.elhacker.net/index.php?board=32;action=display;threadid=6151

- Mi primera Shellcode para un exploit!!!
http://foro.elhacker.net/index.php?board=32;action=display;threadid=12032

- Exploit para el overflow del RPC de windows (DCOM)
http://foro.elhacker.net/index.php?board=32;action=display;threadid=15974

- RECOPILATORIO DE EXPLOITS
http://foro.elhacker.net/index.php/topic,32810.0

- Textos sobre Exploits y demas - BIBLIOTECA -
http://foro.elhacker.net/index.php/topic,38455.0

- PEDAZO DE HERRAMIENTA! BUSCA OFFSETS EN DLLS! FINDJMP.EXE!
http://foro.elhacker.net/index.php/topic,22708.0

- LOS FAMOSOS OFFSETS
http://foro.elhacker.net/index.php/topic,37817.0

- Microsoft Windows XP Task Scheduler (.job) Universal Exploit (MS04-022)
http://foro.elhacker.net/index.php/topic,37176.0

- Aprendiendo a Hackear... utilizando exploit dcom
http://foro.elhacker.net/index.php/topic,36222.0

- Exploit Win 2k/XP (MS03-049) (shell remota)
http://foro.elhacker.net/index.php/topic,22504.0

- Win32Create Admin User Account
http://foro.elhacker.net/index.php/topic,35867.0

- Usar Buffers libres en un Stack Overflow...¿?
http://foro.elhacker.net/index.php/topic,35602.0

- Reverse Shell

http://foro.elhacker.net/index.php/topic,26483.0

- [MOD] ¿Manual de C/C++ orientado a Exploits?
http://foro.elhacker.net/index.php/topic,33996.0

- Aprender hacer shellcode
http://foro.elhacker.net/index.php/topic,23212.0

- Exploits Getadmins en Windows.
http://foro.elhacker.net/index.php?board=32;action=display;threadid=10995

- Format String Vulnerability - De que trata esto...(texto)
http://foro.elhacker.net/index.php/topic,79262.0.html

Tutorial de MetaSploit FrameWork
http://foro.elhacker.net/index.php/topic,93294.0.html

Buffer overflow como si estuviera en primero
http://www.milw0rm.com/papers/278





NIVEL WEB

http://foro.elhacker.net/index.php/topic,49215.0.html
http://www.net-security.org/dl/articles/WASC-TC-v1_0.pdf

- SQL Injection para principiantes, ejemplos en aplicaciones reales.
http://foro.elhacker.net/index.php/topic,142203.0.html

Gospel

#1
Wola

Ya que estamos en horas bajas y ultimamente no aparecen públicos nuevos exploits, aquí os dejo un buen material para saber más sobre cómo explotar algunas de las vulnerabilidades conocidas en servicios de Microsoft Windows con los exploits mencionados en el RECOPILATORIO DE EXPLOIT @ http://foro.elhacker.net/index.php/topic,32810.0

Los siguientes trabajos han sido presentados por aspirantes a la Certificación GIAC.
GIAC (Global Information Assurance Certification) es un estandar para la certificación profesional en conocimientos de seguridad informática fundado por el Instituo SANS (www.sans.org), una de las más importantes organizaciones dedicadas a la búsqueda de nuevas vulnerabilidades y mejora de la seguridad en la red.


La presentación de todos los trabajos sigue las mismas pautas:

1) Descripción de la vulnerabilidad
2) Descripción del exploit
     - Variantes del exploit
3) Cómo funciona el exploit
4) Escenario imaginario donde aplicar el exploit
     - Scaneando a la víctima
     - Explotando la vulnerabilidad con el exploit
     - Asegurando futuros accesos
     - Cubriendo el rastro
5) Firma de ataque del exploit
     - Captura del tráfico generado durante la utilización del exploit
6) Cómo protegerse del exploit
7) Fuentes y Links

Aunque he encontrado muchísimos trabajos, todos referidos a temas de seguridad, aquí os dejo sólo aquellos cuyo contenido está relacionado con el análisis de exploits.
Por desgracia, decir que todos los textos están en inglés...


Citar[!] MS03-026: Windows RPC DCOM Interface Buffer Overrun

RPC-DCOM Vulnerability & Exploit by Brian Porter
www.giac.org/practical/GCIH/Brian_Porter_GCIH.pdf

Microsoft RPC-DCOM Buffer Overflow Attack using Dcom.c by Dean Farrington
www.giac.org/practical/GCIH/Dean_Farrington_GCIH.pdf


Citar[!] MS03-043: Windows Messenger Service Buffer Overflow

Exploiting Heap Overflow in Microsoft Messenger Service with msgr07.exe by Patti Lawrence
www.giac.org/practical/GCIH/Patti_Lawrence_GCIH.pdf

An Analysis of the Windows Messenger Service Buffer Overflow Vulnerability by Peter Hewitt
www.giac.org/practical/GCIH/Peter_Hewitt_GCIH.pdf


Citar[!] MS03-049: Windows Workstation Service WKSSVC.DLL Buffer Overflow

A Study of the o_wks.c Exploit for MS03-049 by Eric Arnoth
www.giac.org/practical/GCIH/Eric_Arnoth_GCIH.pdf

Out of Bounds! Windows Workstation Service by Michael Harbison
www.giac.org/practical/GCIH/Michael_Harbison_GCIH.pdf


Bien, cómo véis me aburro mucho durante examenes, así q espero que a alguien le resulte interesante la lectura de estos textos (aunq leer un pdf en inlgés puede hacerse bastante duro).

Hmmm....sobre los textos referentes a la explotación de MS03-043, ambos hacen uso del exploit de Adik. La verdad es que he llegado a tener pesadillas con este exploit. No me creo que haya dos textos que demuestren que funciona para Windows 2000 SP3 y Windows XP SP1 y a mi no me haya funcionado para Windows 2000 SP4 ni Windows XP SP0, y eso que he buscado correctamente los offsets válidos  ???


Salu2

Rojodos

#2
Bueno, aqui dejo una recopilacion de textos interesantes sobre explotacion y demas. Asi reducimos el numero de post con chincheta en el foro.

Stack Overflows en Linux (por Hakin9)

http://foro.elhacker.net/index.php/topic,37482.0

Win32 Shellcodes by Kekabron -Undercon 2002-

http://foro.elhacker.net/index.php/topic,37252.0

Analizando una shellcode fake (falsa)

http://foro.elhacker.net/index.php/topic,23846.0

Rompiendo la proteccion anti-overflows de los windows 2k3 (ingles)

http://foro.elhacker.net/index.php/topic,36551.0

Interesantes textos sobre ANÁLISIS DE EXPLOITS [GIAC Certification]

http://foro.elhacker.net/index.php/topic,33735

Introduction to Shellcoding - How to Exploit Buffer Overflows

http://tigerteam.se/dl/papers/intro_to_shellcoding.pdf

Explotando buffer overflows en Fedora Core 2

http://foro.elhacker.net/index.php/topic,54212.0.html

Usando SEH para tomar el control - muy basico
http://foro.elhacker.net/index.php/topic,55974.0.html  (Nuevo!)

Explotacion de los archivos PIE en Red Hat (la continuacion del texto como explotar buffer overflows en Fedora)
http://foro.elhacker.net/index.php/topic,57138.0.html  (Nuevo!)

Recopilacion de textos (español)

Varios textos sobre overflows y shellcoding en español =) (Lo enconter en la sección de cracking de elhacker.net xDDD)

Recopilacion de Textos (ingles)
La mejor recopilacion de texots (la mayoria en ingles) la encontre en la web de HEAP (thx) y pesa algo de 14mb =)

Que los disfruteis :D

Salu2

Griph

He quedado de acuerdo con Gospel para ir reuniendo el material de los distintos post de este foro en forma de un sólo texto para cada post.

Si alguien quiere colaborar, simplemente que envíe el texto por IM o por correo eletrónico; y luego se posteará en este tema.

Esta información la puedes encontrar a continuación:

¿Qué es una ShellCode?

Offsets en OverFlows:

¿Cómo se usan los Exploits?

El Desbordamiento del Buffer: Buffer OverFlow (Desbordamiento de la Memoria)

TODA LOS TEXTOS QUE DEJO AQUÍ ESTÁN EN CASTELLANO

Bueno para darle un poco más de tecnisismo a este foro aquí dejo suficiente material como para que despejes muchas dudas:


* Textos Sobre Programación de Exploits y ShellCodes

_ Exploits, por mitrein
_ Ejemplos de códigos de Bugs y Exploits, por NetSearch
_ Ejemplos de códigos de Bugs y Exploits, por DDiego
_ Automatizacion de Xploits Locales Bajo Linux, por RaiSe

_ Desbordamiento de la Pila, por RaiSe
_ Explotar Stack Overflow en UNIX x86, por dex
_ Stack OverFlow en Linux (IPgh0st)
_ Stack Overflow con Stack No Ejecutable, por Ripe

_ ASM y Buffer Overflows
_ Aprovechamiento de Buffer Overflow en Alpha Linux, (honoriak)
_ Buffer Overflows para 'kiddies' (Plataformas x86), (honoriak)
_ Buffer Overflows - Rasman & Winhlp32, por FCA00000
_ Buffer Overflows (b0f's), por kekabron
_ Buffer Overflow Exploits en Perl (1), (Taseh)
_ Buffer Overflows en Perl (2), (Taseh)
_ Desbordando el Buffer, por Doing y Ripe
_ Desbordamiento_de_Buffer_en_win32, por dark spyrit AKA Barnaby Jack (honoriak)
_ Escribiendo Exploits Basados en Buffer OverFlows (honoriak)
_ 'Exploiting' Avanzado de Buffer Overflows, (honoriak)

_ Guia de Shells
_ Shellcodes en Linux-i386 (1), por RaiSe
_ Shellcodes en Linux-i386 (2), por RaiSe
_ ShellCodes en win32 y OverFlows, por RaiSe y Eid0

_ Bugs de Formato (1-2), por RaiSe
_ Format Bugs Que son, De donde vienen, por lamagra (honoriak)
_ Explotando Format Bugs, por 0x90

_ Heaps Overflows (1-2), por cafo
_ Introduccion a los heap-bss overflow, por Pluf
_ Integer Overflow, por Runlevel
_ Overflows Alfanumericos, por RaiSe
_ Denial Of Service, por Swoish

_ Curso de Lenguaje C, por El_Max_5 (41 Kb)
_ Instrucciones de Ensamblador Basicas
_ Curso de Ensamblador, por AESOFT (91 Kb)


Bueno lo que pasó en cuanto a qué el tamaño del archivo con los textos aumentara es que cuando habían dos ficheros con los textos, habían algunos escritos repetidos. Entonces, los uní y saque los textos que repetidos (que eran pocos, en realidad).

Saludos y Suerte,

Griph
"...la Base está en Aprender a Programar..."

Griph

#4
Una Shell code es una serie de ordenes en ensamblador que hace algo a lo cual sacamos provecho; ejecutar /bin/sh para obtener una shell, por ejemplo copiar una shell y setearla con suid root, etc. Tiene características de programación un tanto especiales.

Se usa para conseguir ejecutar un código después de haber sobreescrito la dirección de retorno de un programa/función mediante un overflow, o mediante cualquier otro método válido. Es decir, el valor de la dirección de retorno que se sobre-escribirá será la de nuestra shellcode. Cuando se programa una ShellCode simplemente cabe decir que cuando se produzca el desbordamiento y el salto se ejecutará nuestra ShellCode.

Nota: Lo de ejecutar bin/bash, setuid(0), etc. es en GNU/Linux o UNIX. Las ShellCodes para Windows (se construyen, obviamente, de distinta forma) hacen "otras cosas" como ejecutar cmd.exe (la shell del MSDOS), descargar y ejecutar algo silenciosamente (como un troyano), añadir un usuario definido como administrador del sistema, etc.

Cuando se programa una ShellCode a veces es necesario harcodearla, lo cual significa que hay que meter en el código en assembler (ASM) la dirección exacta del RET, de los strings, de las llamadas a funciones, etc. El problema es que la dirección del RET así como las llamadas a las funciones en una shellcode, varían según se ejecute en un Sistema Operativo (SO) o en otro (es decir que varía si se ejecuta en un sistema Windows, GNU/Linux, UNIX, Solaris,
BSD, etc. Esto pasa sobre todo con el software de Micro$oft, por eso los exploits para productos de esta empresa traen un mini menú para elegir el SO (win NT, win 2k, win XP, wink3...) así como los SPs (Service Packs) instalados.

Por tanto, es posible que los testeos que hagas en tu servidor no funcionen en otros que tengan un sistema operativo diferente (o incluso iguales).

Algunas aclaraciones:

* ASM: Assambler Programming Languaje, es decir Lenguaje de Programación Ensamblador. Es el lenguaje de nivel más bajo y por consiguiente el que interactúa de forma más directa con el hardware del ordenador.

* RET: Return Address, es decir Dirección de Retorno. Ésta contiene la dirección de memoria que ejecutará cuando termine la función, o hacia dónde tiene que regresar y ejecutar. Cabe decir que el RET se almacena en la Pila.

* String: Es una cadena de Texto. Ejemplos:
_ "Hola"
_ "\xcd\x80"
_ {'h','o','l','a','\0'}
Son todos Strings.


Más información:

www.shellcode.com.ar
www.google.com
"...la Base está en Aprender a Programar..."

Griph

Nota: las direcciones offset de las cuales se habla en este texto son fictisias, simplemente se dan esos números para
proceder a la ejemplificación. No deben ser tomados en cuenta.

Un offset es un desplazamiento respecto de a una dirección de memoria. Por ejemplo, kernel32.dll se carga en memoria
a partir de la dirección (la siguiente es una fictisia) 0x76890000. Es decir, la dirección 0x76890000 empieza la
"DLL" (la cual recibe el nombre de dirección base). Bien, ahora, si por ejemplo usted quiere usar la función
LoadLibraryA (la cual se haya contenida en la DLL kernel32.dll), tendrá que informarse del offset de esa
función, le cual es: 0x7C. Lo cual quiere decir que la función la encuentra aquí:

Dir. Base + Offset = Dirección de la Función
0x76890000 + 0x7C = 0x7689007C

Entonces cuando quiere llamar a LoadLibraryA en ASM, tienes que mandar sus arguementos a la pila
(push eax/ebx/ecx o datos a mano..., teniendo en esos registros los argumentos, mandándolos en orden inverso).
Lo cual es de la siguiente forma:

push eax;  // Argumento 2º
push ebx;  // Argumento 1º
call 0x7689007C;  // Llamada a LoadLibraryA

Ese código ejecutará:

LoadLibraryA (argumento1, argumento2);

En el caso de los sistemas operativos de la empresa micro$oft las direcciones base de las DLL y los offset
de las diversas funciones cambian según la versión del sistema, los service packs instalados, parches y demás cuestiones.


Es decir:


Win 98 --> Dir Base kernel32.dll = 0x78960000

Win 2k --> Dir Base kernel32.dll = 0x79990000

Win 2k SP1 --> Dir Base kernel32.dll = 0x80000000

Win 2k SP4 --> Dir Base kernel32.dll = 0x79880000

Win XP --> Dir Base kernel32.dll = 0x80600000

Win XP SP1 --> Dir Base kernel32.dll = 0x80500000


Como puede ver, si durante la ShellCode deseamos llamar a LoadLibraryA simplemente tenemos que cambiar la dirección
de memoria del kernel32.dll y luego la de su offset, lo cual recibe el nombre de harcodear direcciones de memoria
o direcciones offsets). Por consiguiente nos damos cuenta que para cada shellcode que programemos tendremos que
desarrollar una para cada sistema operativo diferente. Aunque en realidad cabe decir que hay formas de lograr
una shellcode que se ocupe de buscar la dirección base y el offset de la función a utilizar de forma automática
(para que no la tengamos que cambiar y a la vez se pueda emplear en diferentes sistemas operativos).

Con la Pila (Stack) ocurre la misma situación: varía según el sistema operativo, service packs (SPs)
instalados, etc. Por eso puede que la dirección de memoria RET funcione en nuestro ordenador y no en otro.
De todos modos hay algoritmos que aplican la técnica de fuerza bruta (brute force) a la RET Address, hasta
que logran encontrar la dirección correcta a la que apunta la shellcode.

La Shellcode generalmente va como argumento del programa. Este arguemento se copia a un buffer mal construido, el
cual (dicho en palabras simples) peta. Luego se puede llamar a la shellcode a ese buffer que ha petado o en
donde estaba antiguamente, es decir en los argumentos (en ARGV, exactamente).
"...la Base está en Aprender a Programar..."

Griph

#6
¿Cómo se Usan los Exploits?

Los exploits son formas de explotar los bugs/vulnerabilidades que presenta un software  determinado, lo cual se puede llevar a cabo mediante una aplicación que fue programada especialmente para explotar una vulnerabilidad específica (un bug). En el transcurso de diseñar el exploit se lo puede programar para que explote la vulnerabilidad de forma remota o local.
Forma Local (exploit local): es el caso en el que tienes un entorno interactivo (una shell,  por ejemplo). Para ejecutar un exploit de forma local hay que tenerlo en la máquina y luego subirlo.

Forma Remota (exploit remoto): se ejecuta de la máquina en la cual se esta probando el  bug/vulnerabilidad que existe en otra máquina remota, aprovechando algún servicio que tenga conexión a la red y por consiguiente que tenga la vulnerabilidad que se está estudiando (pueden ser muchas, así como también una sola). De esta forma generalmente lo que se intenta es tener acceso a una shell. Tanto mediante un puerto privilegiado (los que son menores a 1024, los cuales están reservados para el sistema operativo y para el usuario root) o a un puerto no privilegiado (los que son mayores a 1024 en adelante). Respecto de los puertos privilegiados puede ser que con el "nc" puedes mandar una rootshell bin/bash (por ejemplo) y luego telnetear y tener la shell ahí lista para tipear comandos. Esto se puede ver en aquellos  exploit que envían la shell al puerto 80, por ejemplo (y cabe decir que el objetivo es el de saltarse los firewalls). De una u otra forma esto se consigue si el exploit logra tomar el privilegio de usuario root o ejecutarse en el espacio GDT del  kernel (de esta forma se puede abrir un puerto privilegiado). Referente a los puertos no privilegiados son puertos más "grandes" y por consiguiente tienen  una probabilidad de colapsar menor que un puerto privilegiado. Además es una forma de que el admin (sysop) no se de cuenta  de que hay un intruso en el sistema. Por otro lado cabe decir que un exploit puede programarse en cualquier lenguaje (siempre y  cuando tenga la suficiente capacidad para llevar a cabo un desarrollo de este tipo, generalmente en se encuentran  escritos en C; dado que se ha convertido en un estándar en la red.
Este es un ejemplo de código en Java que puede producir un exploit (esto es simplemente un  trozo de de código hecho en Java, y es precisamente un método o función):

Code:

public void processX(int i) {
int a = 10;
int result;
result = i / a;     // esta es la línea que puede causar un exploit
}

Este es el código de un método normal que espera una reducida cantidad de datos enteros (int) y lo procesa de acorde a algún valor definido dentro del mismo programa o su base de datos.
Podria no ser un valor cero, y esto haría un crash al sistema, el problema mayor de los  códigos es que no rechequean o válidan ninguna entrada de sus procesos, entonces un exploits puede hacer lo que desee, desde una tonteria hasta un serio programa de seguridad en flaws. En fin... los exploit son provocados por algún mínimo error que pueda tener un determinado software.



* Proceso de Compilación:

¿Qué es Compilar un Código Fuente?

Es un proceso realizado por un programa compilador, que consiste en la traducción del código  fuente escrito por el programador en alguno de los lenguajes de programación existentes (BASIC, C,C++,Java, Cobol, Pascal, Phyton, Perl, Delphi, Ada, Ensamblador, etc.) en código ejecutable (un programa) en un determinado sistema informático (UNIX, GNu/Linux, Windows,
Solaris, etc.).

Más información en: http://www.hispabyte.com/glosario/index.php?letra=c

  • Compilar un exploit escrito en lenguaje C desde GNU/Linux sería:

    *_* Compilación:

    #gcc exploit.c -o exploit

    *_* Ejecución:

    #./exploit <parametros><parametros2> etc.

    En caso de no tener acceso a un sistema GNU/Linux, se puede compilar desde windows. Mediante compiladores como: LCCWIN32, Dev C++, etc. Aunque cabe decir que muy pocos (esto se ve reflejado en el tema de los sockets, es decir en rigor de verdad por las librerías las cuales son distintas para cada sistema operativo y el exploit tendría que estar escrito especialmente para windows). De una u otra forma se puede leer el código fuente: cat  exploit.c , more exploit.c, etc. para ver el código fuente y leer las especificaciones que podría traer; tanto para la correcta compilación como para su posterior uso.

    Puede ocurrir que en la compilación de las fuentes con DevCpp (comúnmente conocido como Dev- C++) surgan errores referentes a los archivos de encabezado (headers), los cuales se deben a que se quiere  utilizar un fichero ***.h que no es estándar (porque son creados por otros programadores, para otros compiladores o bien para  otros sistemas operativos). Es
    decir este compilador trabaja con dos tipos de ficheros headers: Los ANSI (que son estandar) y los que trae de forma predeterminada windows (que también son ANSI pero sólo sirven para este sistema operativo, un ejemplo de estos ficheros es por ejemplo winsock.h que sirve para trabajar con wsockets en windows). Para evitar estos  problemas un compilador como
    CYGWIN con el paquete GCC instalado.


  • Un exploit en Perl (estos funcionan tanto para GNU/Linux como para MS-DOS, aunque para  este último hay que llevar a cabo algunos pasos anteriores antes de comenzar a compilar códigos):

    perl exploit.pl <parametros> <parametros>

    Luego se ejecuta el fichero exploit.pl. El intérprete de Perl lo va compilando línea por  línea (al exploit) y luego lo ejecuta secuencialmente. Para ejecutar estos exploit en windows se puede bajar el ACTIVE PERL, y luego se pueden  ejecutar los exploits escritos en
    Perl desde una consola MS-DOS: C:\perl exploit.pl <parametros>


  • Compilar un exploit en shellscript (éstos sólo funcionan en GNU/Linux):

    ./sh exploit.sh parametros

    En fin así como se puede compilar o programar un exploit con estos lenguajes, se puede hacer  también con cualquier lenguaje del cual se tenga un buen dominio (que se lo sepa usar bien).



    Para más información:

    * www.securityfocus.com
    * www.packetstorm.com
    * www.securiteam.com
    * Las e-zines de NetSearch.
    * www.decowar.com
    * www.cyruxnet.org (tiene muy buenos textos)
    * www.zine-store.com.ar
    * www.hackemate.com.ar (se las han ingeniado muy bien para recopilar tantos e-zines, son verdaderamente muchos)
    * www.cyervonet.com.ar
    * www.prehackers.com
    * www.hackxcrack.com (hay información muy útil sobre seguridad avanzada en general, viene muy bien darle una mirada)
    * http://www.cygwin.com/ (compilar y ejecutar exploits en windows, es una emulador de la shell para windows)
    * http://cygwin.com/faq/
    * http://cygwin.com/cgi-bin2/package-cat.cgi?file=gcc/gcc-3.2-3&grep=gcc (el compilador gcc)
    * http://gcc.gnu.org/
    * http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gcc (paquetes para gcc)
    * En caso de que falte la DLL CYGWIN.dll (hay que ubicarla en el directorio system32 o system):
    http://www.cs.washington.edu/homes/kautz/blackbox/cygwin1.dll
    * http://cyruxnet.org/rpcxploit.htm (Cómo usar un xploit)
    * http://www.hackxcrack.com/phpBB2/viewtopic.php?t=14605 (son servidores para hacer poner en prueba los testeos de seguridad, cabe decir que es para prácticar cómo podría alguien atacar nuestro servidor u ordenador personal).
"...la Base está en Aprender a Programar..."

Griph

El Desbordamiento del Buffer: Buffer OverFlow (desbordamiento de la memoria).

Los desbordamientos de buffer se basan en introducir el código en el espacio reservado para las variables locales (los argumentos de un método/función) y después modificar la dirección de retorno/regreso (RET), en donde regresa la información, para que apunte a un offset en donde hemos introducido nuestro código fuente. Este código puede ser - por ejemplo - una ShellCode, es decir, instrucciones para llevar a cabo la ejecución de un intéprete de comandos como puede ser: bash, sh, entre otros.

Una forma de aprovechar los desbordamientos del buffer (en el caso del Lenguaje de Programación C) es la función strcpy(), con la cual se sobreescribe una posición en la memoria (es decir, se sobreescribe un offset) "parecido a las funciones de las shell codes". El string origen (la cadena de caracteres) de la función "strcpy" contiene nuestro código al principio y después la nueva dirección de retorno (RET) repetida tantas veces como sea necesario para llegar a sobreescribir la antigua.

El desbordamiento del buffer se produce cuando un usuario o un proceso intenta introducir en el buffer una cantidad de datos superior para lo cual estaba preparado el buffer. Algunas funciones útiles para llevar a cabo el desbordamiento del buffer son, las siguientes:


* strcpy();
* strcat();
* sprintf();

Entre otras (nada es perfecto y por consiguiente es más que probable que hayan otras funciones que ayuden a la hora de desbordar un buffer).

Lo que provoca el desbordamiento de un buffer es una violación de la segmentación de memoria. El objetivo de esto es saltar a otra dirección offset, y por consiguiente caer en la librería que tiene el intérprete de comandos. Es decir la Shell para ejecutar los comandos, que para esto estaremos dentro del sistema del cual se está testeando.

De una forma un poco más detallada se puede explicar qué causa el fallos de la siguiente manera:

En realidad el fallo en sí no se provoca al desbordar el buffer o sobrepasar el valor para el cual está preparada la variable local, sino que al escribir más de lo que se había reservado se puede llegar a escribir la RET (la dirección de retorno). Luego el sistema operativo llevará a cabo la función a la cual se le ha desbordado buffer y se dirige a la pila. Después buscará el offset en el cual se encuentra la RET y encontrará en ésta una violación de segmento.

Existen dos tipos de desbordamientos: "Locales" y "Remotos".

Un buffer de longitud fija de 128 bytes, define la cantidad de datos que pueden almacenarse como entrada al mandato SendMail que puede servir para identificar usuarios (es decir que a tal fin está preparada para recibir 128 bytes, de lo contrario desbordará).

Entonces si envíaramos un bloque de 1000 caracteres (lo cual equivale a 1000 bytes) en lugar de un bloque de 128 caracteres (128 bytes) lo que sucede es que el buffer de SendMail se desborda; y por consiguiente se puede producir una denegación de servicio (es decir los ataques conocidos comúnmente como DoS, Denial of Service) y podría ejecutarse el comando /bin/sh. Lo grave es que si esto sucede un intruso puede tener privilegios de root (administrador):

Echo ?sendmail 'perl -e 'print ?a? x 1000' ' ? |nc www.victima.com 25

Por suerte no todos los programas responden de igual manera que SendMail. El código que se usó es EGG Assembly (Assembly, sinónimo de ensamblador).

De todos modos el código fuente en ensamblador depende del Sistema Operativo, uno para GNU/Linux es el siguiente:


char shellcode [] =
? \xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b?
? \x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd?
? \x80\xe8\xdc\xff\xff\xff\bin\sh ? ;
"...la Base está en Aprender a Programar..."

Griph

Estaba leyendo un texto sobre ensamblador y vi una parte interesante que habla sobre la Pila (Stack) del Procesador. Dado que es un concepto que hay que tener claro a la hora de diseñar una shellcode para un exploit, etc. aquí les dejo el texto:

Citar
     - La pila del procesador:
     -------------------------
     La pila es una característica interna del 8086. Es una estructura de
     datos situada en la RAM. Proporciona a los programas un lugar donde
     almacenar datos de forma segura, pudiendo compartirlos con otros
     procedimientos o programas de forma cómoda y práctica.

     La función más importante de la pila es la de mantener las direcciones
     de retorno en las llamadas a procedimientos e interrupciones, así como
     guardar los parámetros pasados a estos procedimientos.
     La pila también se utiliza para almacenamiento temporal de datos dentro
     de un programa, y para muchas cosas más que se aprenden con la práctica.

     La pila tiene su nombre por analogía con los montones de platos apilados
     (pilas de platos). Cuando un dato nuevo es introducido en la pila, se dice
     que es apilado (push) debido a que se sitúa por encima de los demás, es
     decir se sitúa en la CIMA de la pila.

     Una pila opera en el orden  último-en-entrar - primero-en-salir:
     LIFO (LAST IN FIRST OUT) o lo que es lo mismo, el último en entrar es
     el primero en salir.

     Esto significa que cuando la pila se utiliza para seguir la pista de los
     retornos de las subrutinas, la primera llamada a subrutina que se hizo,
     es la última que se devuelve. De esta manera, la pila mantiene ordenado el
     funcionamiento del programa, las subrutinas y rutinas de tratamiento de
     interrupción, sin importar la complejidad de la operación.

     La pila crece en orden inverso. Es decir, a medida que se añaden nuevos
     datos, la cima de la pila se acerca más a posiciones más bajas de memoria.

     Existen 3 registros destinados a gestionar la pila.
     Registro de segmento de pila (SS): que indica la dirección base del
     segmento de pila
     Puntero de pila (SP): que apunta a la cima de la pila.
     Puntero base de pila (BP): que se usa para moverse a través de la pila
     sin cambiar la cima. Se suele utilizar para acceder a los distintos
     parámetros al llamar a una función.

     Los elementos que se almacenan en la pila son del tipo palabra (2 bytes).
     Esto quiere decir, entre otras cosas, que el puntero de pila (SP), así como
     el puntero base de pila (BP), incrementan/decrementan en 2 su valor para
     apuntar a un nuevo elemento dentro de la pila, fruto de apilar o desapilar
     un elemento.

     También conlleva el que si queremos almacenar un byte en la pila, primero
     lo debemos convertir en palabra (2 bytes), y luego almacenar esa palabra.
     Esto es muy sencillo, sólo hay que meter ese byte o registro de 8 bits
     en un registro de 16 bits y almacenar este registro.

     Las instrucciones para manejar la pila son:
     PUSH ---> Guarda un dato en la pila. Decrementando SP en 2 unidades, para
               que apunte al nuevo elemento a introducir.
               Ejemplo: PUSH AX --> Apila el contenido de AX en la cima de la
                        pila.

     POP ----> Obtiene un dato de la pila. Incrementando SP en 2 unidades, para
               que apunte al nuevo elemento a introducir.
               Ejemplo: POP AX --> Desapila el contenido de la cima de la pila
                        en el registro AX. Es decir, AX contendrá el valor
                        que hubiera en la cima de la pila, y el puntero de pila
                        se actualiza incrementándolo en 2.

     PUSHF --> Guarda el contenido del registro de estado (FLAGS) en la pila.
               Decrementando SP en 2 unidades, para que apunte al nuevo elemento
               a introducir.
               No es necesario indicar sobre qué actúa esta instrucción, lo
               lleva implícito en su nombre PUSHF (PUSH FLAGS).

     POPF ---> Introduce en el registro FLAGS el contenido de la cima de la
               pila. Incrementando SP en 2 unidades, para que apunte al nuevo
               elemento a introducir.
               Al igual que con la instrucción anterior, no es necesario indicar
               sobre qué actúa esta instrucción POPF (POP FLAGS).



     Conviene recordar el hecho de que la pila crece en orden inverso al
     normal, es decir de direcciones de memoria altas a direcciones bajas.
     Por lo tanto es necesario tener en cuenta el uso que se va a hacer de
     la pila en el programa, debido a que si reservamos espacio en nuestro
     programa para una pila pequeña, en caso de sobrepasarla haciendo muchos
     push seguidos, machacaría nuestro programa.

     Hay que tener en cuenta que no sólo es nuestro programa el que utiliza
     la pila mediante la instrucción PUSH y mediante llamadas a procedimientos,
     interrupciones, etc. Sino que mientras nuestro programa corre se están
     sucediendo numerosas interrupciones que conllevan muchos PUSH.
     Por ejemplo, 18'2 veces por segundo se produce la interrupción de reloj,
     con lo cual, todas estas veces se está apilando y posteriormente
     quitando información de la pila.

     Por regla general, basta con tener una pila de unos 2 KS, es decir, espacio
     para almacenar 1024 elementos. Es muy difícil que se sobrepase este tamaño.

Que les sirva.

Griph
"...la Base está en Aprender a Programar..."