Archive

Archive for October, 2010

Redirecionando portas e janelas no Cisco ASA :P

A situação e a seguinte conforme desenho abaixo.

Preciso redirecionar 2 porta externas distintas para a mesma porta interna, ou seja, redirecionar tudo que chega na porta 80 e 8080 no ip outside 200.200.200.200 para o endereço ip interno 192.168.10.10 na mesma porta 80. A principio isso e fácil criamos 2 nat estaticos conforme abaixo

static(inside, outside) tcp 200.200.200.200 80 192.168.10.10 80 netmask 255.255.255.255
static(inside, outside) tcp 200.200.200.200 8080 192.168.10.10 80 netmask 255.255.255.255

Mas esta solução não ira funcionar, a primeira regra irá funcionar sem problemas, mas quando inserir a segunda regra ele irá reclamar dizendo que já existe uma regra de nat estatico para a porta 80 e o que fazer então?

Vamos trabalhar com access-list. Criaremos 2 access-list’s

access-list policy1 permit tcp host 192.168.10.10 eq 80 any
access-list policy2 permit tcp host 192.168.10.10 eq 80 any

static (inside,outside) tcp 200.200.200.200 80 access-list policy1
static (inside,outside) tcp 200.200.200.200 8080 access-list policy2

Simples né.

Att.

Categories: Uncategorized

Mini análise forense

Após um longo tempo sem postar achei um tempo entre trabalho e correria para montar um post um mini analises de binarios no Linux com comando file, nm, strings, strace, ltrace, etc.

Introdução

Em ocasiões frequentemente depois de um ataque, podemos encontrar em nossos servidores binarios ou executaveis misteriosos. Programas que podem ter sido usado por um hacker para comprometer sua rede ou servidor.
Pode-se utilizar técnicas e métodos juntamente com ferramentas para fornece pistas do que o programa suspeito faz.

Como saber o tipo de arquivo?

Para obter informação do tipo do arquivo e muito simples e fácil utilizamos um software para isso o comando “file”. veja um exemplo de uso do mesmo:

root@capsula:~# file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
root@capsula:~# file mkdosfs
/sbin/mkdosfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, statically linked, not stripped
root@capsula:~#

Um item interessante à analisar nos 2 binarios é que o comando “ls” esta construindo com links dinamicos enquanto o comando “mkdosfs” esta construido estaticamente. Por padrão o compilador gcc constroi o aplicativo dinamicamente. Este comportamento pode ser alterado através do flag -static. Com isso deixando o binario sem a dependência de libs externas porém deixando o arquivo maior.

Fiz um “hello world” em C para demostrar isso. Segue abaixo o exemplo.

root@capsula:~/dev# gcc teste.c -o dinamic
root@capsula:~/dev# gcc -static teste.c -o static
root@capsula:~/dev# ls -lh
total 744K
-rwxr-xr-x 1 root root 8.3K 2010-10-07 21:46 dinamic
-rwxr-xr-x 1 root root 725K 2010-10-07 21:46 static
-rw-r–r– 1 root root 71 2010-10-07 21:46 teste.c
root@capsula:~/dev#

Vejam a diferença entre os tamanhos do binario compilado statico e dinamico. Outro item a se averiguar e a string “stripped” e “not stripped”, afinal o que quer dizer isso?
Um binario “stripped” significa que o mesmo não possue os símbolos do arquivo objeto. Simbolos que são gerados pelo compilador e ajudam na busca de informaçoes sobre o binário analisado.

Um hacker pode eliminar os simbolos do binário através do comando “strip”.

root@capsula:~/dev# ls -lh static
-rwxr-xr-x 1 root root 725K 2010-10-07 21:46 static
root@capsula:~/dev# strip static
root@capsula:~/dev# ls -lh static
-rwxr-xr-x 1 root root 650K 2010-10-07 21:51 static
root@capsula:~/dev#

Repare no exemplo acima que o tamanho do binario diminui, legal neh 😀

Bom digamos que o hacker esqueceu de sumir com os símbolos do binario, podemos analisá-los entao. Existe um comando que nos auxilia nessa tarefa o comando “nm”, ele lista os simbolos do binario.

root@capsula:~/dev# nm static
nm: static: no symbols
root@capsula:~/dev#

Mas se analisarmos o binário compilado “dinamic” será que ele possue simbolos?

root@capsula:~/dev# nm dinamic
0000000000600e40 d _DYNAMIC
0000000000600fe8 d _GLOBAL_OFFSET_TABLE_
0000000000400638 R _IO_stdin_used
w _Jv_RegisterClasses
0000000000600e20 d __CTOR_END__
0000000000600e18 d __CTOR_LIST__
0000000000600e30 D __DTOR_END__
0000000000600e28 d __DTOR_LIST__
00000000004006e8 r __FRAME_END__
0000000000600e38 d __JCR_END__
0000000000600e38 d __JCR_LIST__
0000000000601020 A __bss_start
0000000000601010 D __data_start
00000000004005f0 t __do_global_ctors_aux
0000000000400490 t __do_global_dtors_aux
0000000000601018 D __dso_handle
w __gmon_start__
0000000000600e14 d __init_array_end
0000000000600e14 d __init_array_start
0000000000400550 T __libc_csu_fini
0000000000400560 T __libc_csu_init
U __libc_start_main@@GLIBC_2.2.5
0000000000601020 A _edata
0000000000601030 A _end
0000000000400628 T _fini
00000000004003f0 T _init
0000000000400440 T _start
000000000040046c t call_gmon_start
0000000000601020 b completed.7382
0000000000601010 W data_start
0000000000601028 b dtor_idx.7384
0000000000400500 t frame_dummy
0000000000400524 T main
U printf@@GLIBC_2.2.5
root@capsula:~/dev#

Sim e bastante 🙂

Note que nosso binário não faz nada demais apenas usa a função “printf”, mas olhe bem no final do comando “nm”. Vemos um “printf”, como funcionou para visualizar o acesso a função “printf”, funciona para outras chamadas de sistemas como “socket”, “connect”, “ioctl”, etc. 😀

Olhando dentro do executável 😛

Existe um comando que nos permite olhar em até certa parte dentro de um executável. O comando ‘strings’ ele permite obter os textos de caracteres armazenado no executável. Vejamos um exemplo:

root@capsula:~/dev# strings dinamic
/lib64/ld-linux-x86-64.so.2
__gmon_start__
libc.so.6
printf
__libc_start_main
GLIBC_2.2.5
fff.
=/
fffff.
l$ L
t$(L
|$0H
Hello World
root@capsula:~/dev#

Veja bem no final o conteudo do nosso printf “hello world”. Se estiver analisando um binário misterioso com esse comando você obter detalhes da função “printf” ou qualquer outra cadeia de caracteres que o binário misterioso faz uso.

Análise dinâmica.

Apos analisarmos o binario e verificar que não oferece perigo podemos executá-lo e analisar quais chamadas de sistemas e bibliotecas que ele chama ou executa.
Possuimos 2 comandos para isso, são eles:

    strace – Permite visualizar as chamadas de sistemas que são executadas pelo binário.
    ltrace – Permite visualizar as bibliotecas executadas pelo binário.

strace

root@capsula:~/dev# strace ./dinamic
execve(“./dinamic”, [“./dinamic”], [/* 20 vars */]) = 0
brk(0) = 0x1128000
access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c153000
access(“/etc/ld.so.preload”, R_OK) = -1 ENOENT (No such file or directory)
open(“/etc/ld.so.cache”, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=17219, …}) = 0
mmap(NULL, 17219, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbe5c14e000
close(3) = 0
access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
open(“/lib/libc.so.6”, O_RDONLY) = 3
read(3, “\177ELF\2\1\1\3>\1`\355\1″…, 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1572232, …}) = 0
mmap(NULL, 3680296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbe5bbb2000
mprotect(0x7fbe5bd2c000, 2093056, PROT_NONE) = 0
mmap(0x7fbe5bf2b000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x179000) = 0x7fbe5bf2b000
mmap(0x7fbe5bf30000, 18472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbe5bf30000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c14d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c14c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c14b000
arch_prctl(ARCH_SET_FS, 0x7fbe5c14c700) = 0
mprotect(0x7fbe5bf2b000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ) = 0
mprotect(0x7fbe5c155000, 4096, PROT_READ) = 0
munmap(0x7fbe5c14e000, 17219) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), …}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c152000
write(1, “Hello World”, 11Hello World) = 11
exit_group(0) = ?
root@capsula:~/dev#

ltrace

root@capsula:~/dev# ltrace ./dinamic
__libc_start_main(0x400524, 1, 0x7fff6d162488, 0x400560, 0x400550
printf(“Hello World”) = 11
Hello World+++ exited (status 0) +++
root@capsula:~/dev#

Note que o nosso softwarezinho de exemplo chama um certo número de chamadas e apenas executa a função “printf”, presente na biblioteca stdio.h ou libc conforme a string indica “__libc_start_main”.

Bom espero ter conseguido demostrar algumas formas de analisar arquivos executáveis ou binários. E espero daqui para frente ter tempo para postar. 😀

Att.

Categories: Uncategorized