Este post, talvez será refeito durante o tempo, mas uma coisa que reparei, é que principalmente na internet, se você não publicar algo, quer dizer que você não sabe ou não fez ainda.
Qual vez você vê um artigo e se fala: "Já pensei isso antes, já fiz isso antes, estava escrevendo um artigo sobre isso e outra pessoa fez..." e por ai vai...
De 1989 até 2002 eu fiz muita coisa na minha carreira profissional, mas só fui descobrir o que é internet (usando) em 2002 quando fiz um curso para MCP em VB6 (antigo VB6) em uma franquia Microsoft.
Hoje tenho essa box ainda em casa e só foi usar (o que já sabia quase tudo, menos ActiveX e algumas coisas para DB SQL) em uma empresa de Energia e Gás (multinacional) como trabalhei como consultor em 2004/2005.
Nunca mais usei tais conhecimentos, mas o conceito foi herdado nos próximos anos.
Há muita coisa na minha mente, que foi, que está e que estará em artigos, mas com sempre falta de recursos, como equipamentos, tempo e um pouco dinheiro, fazem boas ou más idéias não acontecerem (sabe que más idéias, são boas também? Porque? Porque pode aparecer alguém com uma boa idéia mediante ao conhecimento da má idéia.)
Ser generalista foi ruim na minha carreira, eu acho...eu sempre quis me aprofundar em algo, mas o mercado não tem interesse ou simplesmente o nicho para mim, não foi muito claro...
Eu devia ter arriscado mais ainda...mas a vontade sempre este comigo...mas a dúvida me levou a não tentar.
Quem sabe agora mais experiente...já venho arriscando mais, mas pretendo muito mais...
(Continuamos outro dia...)
@firebitsbr
terça-feira, 31 de maio de 2011
segunda-feira, 30 de maio de 2011
PoC sobre SNMP com snmpwalk
Hoje montei um PoC sobre SNMP com snmpwalk em uma VM e vou demonstrar no próximos posts os perigos de ter esse daemon ativado nos ambientes, sem uma mitigação em segurança, caso seja realmente necessário estar ativado.
sexta-feira, 27 de maio de 2011
Gelo v1.031! Exploits em LUA!!!
“Gelo is a Lua extension library that aims to simplify and accelerate the development of exploit-oriented tools. Gelo extends Lua with a set of objects and functions that allow you to write scripts for performing complex pen-testing tasks. Gelo is currently being used to build extensions in Sandcat.“
This is the official change log:
Added new functions and methods (See the Readme.txt for details)
Improved IPv6 support.
Since we last wrote about Gelo, it now supports Ruby scripting and a lot of updated example scripts!
Download Gelo v1.031 (gelo-1.031.zip).
This is the official change log:
Added new functions and methods (See the Readme.txt for details)
Improved IPv6 support.
Since we last wrote about Gelo, it now supports Ruby scripting and a lot of updated example scripts!
Download Gelo v1.031 (gelo-1.031.zip).
Scanner de Hardening - HardeningOne - Recoding de plugins para o OpenVAS.
Tive uma idéia há umas semanas atrás e depois foi reforçada pela meu amigo Rafael Lachi: A de fazer o Scanner de Hardening - HardeningOne o recoding de plugins para o OpenVAS e estou em rápida conversão.
Vou publicar os plugins aqui no blog ao terminar.
@firebitsbr
Vou publicar os plugins aqui no blog ao terminar.
@firebitsbr
quinta-feira, 12 de maio de 2011
SWFRETools: A Tool to Reverse Engineer SWF Files!
The SWFRETools are a collection of tools built for vulnerability analysis of the Adobe Flash player and for malware analysis of malicious SWF files. The tools are partly written in Java and partly in Python and are licensed under the GPL 2.0 license.
The basic architecture of SQFRETools is as follows:
The list of tools are part of the SWFRETools:
Flash Dissector: Flash Dissector is a GUI tool that allows you to inspect SWF files on a binary level. When you open a SWF file in Flash Dissector you have the ability to look through the structures defined in the SWF file in a hex editor and in a structure viewer. This makes it easy to understand what bytes of a SWF file hold what functionality.
SWF Parser: SWF Parser is an open-source SWF file parser implemented in Java that you can build upon when you want to create your own Flash reverse engineering tools.
Minimizer: The Minimizer program takes a SWF input that makes Flash Player crash and automatically removes the parts of the SWF file that are not related to the crash. This makes it easier to determine what the root cause of a crash is.
FP Debugger: This Flash Player hooking script hooks important functionality in Flash Player at runtime and dumps information about what Flash Player is parsing and executing. This is very useful in situations where Flash Player trips up and static analysis are out of sync with what Flash Player is doing.
StatsGenerator: Generate stats over SWF files.
Detailed information about using the above mentioned tools can be found in the “readme” files in the each of their directories. Application testing or code review businesses are in boom in the IT and Financial sectors. Tools such as SWFREtools help you as you try to analyze SWF file based exploits or even with stuff such as metadata from the extracted images.
This SWF file reverse engineering framework depends on the following lists of files and softwares:
Java FileDrop
JHexView
Java
splib
Buggery
Link:https://github.com/sporst/SWFREtools
Download SWFREtools (swfretools_100.zip)
@firebitsbr
The basic architecture of SQFRETools is as follows:
The list of tools are part of the SWFRETools:
Flash Dissector: Flash Dissector is a GUI tool that allows you to inspect SWF files on a binary level. When you open a SWF file in Flash Dissector you have the ability to look through the structures defined in the SWF file in a hex editor and in a structure viewer. This makes it easy to understand what bytes of a SWF file hold what functionality.
SWF Parser: SWF Parser is an open-source SWF file parser implemented in Java that you can build upon when you want to create your own Flash reverse engineering tools.
Minimizer: The Minimizer program takes a SWF input that makes Flash Player crash and automatically removes the parts of the SWF file that are not related to the crash. This makes it easier to determine what the root cause of a crash is.
FP Debugger: This Flash Player hooking script hooks important functionality in Flash Player at runtime and dumps information about what Flash Player is parsing and executing. This is very useful in situations where Flash Player trips up and static analysis are out of sync with what Flash Player is doing.
StatsGenerator: Generate stats over SWF files.
Detailed information about using the above mentioned tools can be found in the “readme” files in the each of their directories. Application testing or code review businesses are in boom in the IT and Financial sectors. Tools such as SWFREtools help you as you try to analyze SWF file based exploits or even with stuff such as metadata from the extracted images.
This SWF file reverse engineering framework depends on the following lists of files and softwares:
Java FileDrop
JHexView
Java
splib
Buggery
Link:https://github.com/sporst/SWFREtools
Download SWFREtools (swfretools_100.zip)
@firebitsbr
terça-feira, 10 de maio de 2011
Site www.backtrack-linux.org sofrendo ataque DoS dias antes do lançamento do backtrack5 (resolvido)
Até umas 13:30 do horário do Brasil, estavam rolando DoS no site www.backtrack-linux.org, qual inclusive até mandei um artigo para br-linux.org.
Site www.backtrack-linux.org sofrendo ataque DoS dias antes do lançamento do backtrack5
Site www.backtrack-linux.org sofrendo ataque DoS dias antes do lançamento do backtrack5 é o que fala no twitter oficial do projeto em http://twitter.com/#!/backtracklinux.
Ubuntu 10.10 64 Bits Oracle 11G R2 64 Bits (ideal para PoCs)
http://barrasbin.wordpress.com/2011/05/09/ubuntu-10-10-64-bits-oracle-11g-r2-64-bits/
LOIC: Ferramenta para Ataques Dos/DDoS
LOIC (Low Orbit Ion Cannon), basicamente, transforma a conexão de rede de seu computador em uma firehose of garbage requests (pedidos de lixo), direcionada para um servidor web de destino. Ele é um aplicativo escrito em C# e explorado para facilitar ataques Dos.
Por si só, um computador raramente gera bastante TCP, UDP, HTTP ou pedidos de uma só vez para oprimir um web-server - garbage-requests, que podem ser facilmente ignorados, enquanto os pedidos legítimos para páginas da web são respondidos de forma normal.
Mas, quando milhares de usuários estiverem executando LOIC pelo menos uma vez, a onda de pedidos tornar-se-á avassaladora (muitas vezes), fechando um servidor web (ou uma de suas máquinas ligadas, como um servidor de banco de dados ). Em alguns casos, poderá haver impedimento de solicitações legítimas à serem respondidas.
LOIC é mais focado em aplicações Web, o que também podemos chamá-lo de ataques baseados em aplicações DoS. LOIC pode ser utilizado em um site de destino, inundando o servidor com os pacotes TCP, UDP, HTTP ou pedidos com a intenção de interromper o serviço de um determinado host.
O que podemos falar resumidamente sobre LOIC? Sem dúvidas, ele é uma boa ferramenta para realizar ataques DoS ou DDoS, mas quem ousar a testá-lo, deve assim fazê-lo por sua conta e risco, pois essas atitudes são consideradas ilegais pelo FBI e outras agências da lei. Lembrando que ele não possui a funcionalidade de ocultar o seu endereço IP. Além disso, o seu código fonte está disponível, e a versão mais atual, a 1.0.4, está liberada através do SourceForge. Mais detalhes sobre esta ferramenta tão interessante podem ser lidos através do PentestIT.
Saiba Mais:
[1] SourceForge: http://sourceforge.net/projects/loic/files/loic/
Por si só, um computador raramente gera bastante TCP, UDP, HTTP ou pedidos de uma só vez para oprimir um web-server - garbage-requests, que podem ser facilmente ignorados, enquanto os pedidos legítimos para páginas da web são respondidos de forma normal.
Mas, quando milhares de usuários estiverem executando LOIC pelo menos uma vez, a onda de pedidos tornar-se-á avassaladora (muitas vezes), fechando um servidor web (ou uma de suas máquinas ligadas, como um servidor de banco de dados ). Em alguns casos, poderá haver impedimento de solicitações legítimas à serem respondidas.
LOIC é mais focado em aplicações Web, o que também podemos chamá-lo de ataques baseados em aplicações DoS. LOIC pode ser utilizado em um site de destino, inundando o servidor com os pacotes TCP, UDP, HTTP ou pedidos com a intenção de interromper o serviço de um determinado host.
O que podemos falar resumidamente sobre LOIC? Sem dúvidas, ele é uma boa ferramenta para realizar ataques DoS ou DDoS, mas quem ousar a testá-lo, deve assim fazê-lo por sua conta e risco, pois essas atitudes são consideradas ilegais pelo FBI e outras agências da lei. Lembrando que ele não possui a funcionalidade de ocultar o seu endereço IP. Além disso, o seu código fonte está disponível, e a versão mais atual, a 1.0.4, está liberada através do SourceForge. Mais detalhes sobre esta ferramenta tão interessante podem ser lidos através do PentestIT.
Saiba Mais:
[1] SourceForge: http://sourceforge.net/projects/loic/files/loic/
Microsoft: Atualização para Índices de Exploits
A Microsoft apresentou uma notificação relacionada às alterações feitas nas classificações do seu Exploit Index. Este índice foi projetado para fornecer informações adicionais, para ajudar os clientes a priorizar a implantação de atualizações de segurança da Microsoft.
Microsoft Exploit Index
1. Consistent exploit code likely
2. Inconsistent exploit code likely
3. Functioning exploit code likely
De uma forma aparente, essa publicação se traduz em código fácil de ser criado, ou que já tenha sido criado; código de criação moderada ou talvez uma ocorrência de DoS na qual os resultados não apresentem consistência e vulnerabilidades nas quais o risco não seja considerado alto.
Houve também a inclusão na notificação de um alerta adiantado de um patch mensal, que reúne um conjunto de patches do Microsoft Office e patches dos Windows Servers 2003 a 2008 R2. A Microsoft afirmou que irá agregar seus Exploit Index nos programas atuais e nos antigos também. Outras informações podem ser vistas nos links da Microsoft disponíveis no Security Technet.
Saiba Mais:
Security Technet: http://technet.microsoft.com/en-us/s.../cc998259.aspx
Microsoft Exploit Index
1. Consistent exploit code likely
2. Inconsistent exploit code likely
3. Functioning exploit code likely
De uma forma aparente, essa publicação se traduz em código fácil de ser criado, ou que já tenha sido criado; código de criação moderada ou talvez uma ocorrência de DoS na qual os resultados não apresentem consistência e vulnerabilidades nas quais o risco não seja considerado alto.
Houve também a inclusão na notificação de um alerta adiantado de um patch mensal, que reúne um conjunto de patches do Microsoft Office e patches dos Windows Servers 2003 a 2008 R2. A Microsoft afirmou que irá agregar seus Exploit Index nos programas atuais e nos antigos também. Outras informações podem ser vistas nos links da Microsoft disponíveis no Security Technet.
Saiba Mais:
Security Technet: http://technet.microsoft.com/en-us/s.../cc998259.aspx
Gated- Daemon para roteamento dinâmico no linux
É uma daemon de roteamento que trabalha com varios protocolos e substitui o routed(admn) e outros daemons de roteamento.
O gated trabalha com os protocolos de roteamento RIP, BGP e OSPF.
para utiliza-lo voce deverá usar o caminho /etc/gated e não /usr/sbin/in.gated com uma das opções baixo:
/etc/gated [ -c ] [ -C ] [ -n ] [ -N ] [ -t trace_options ] [ -f config_file ] [ trace_file ]
-c
Verifica se o arquivo tem erros de sintaxe na configuração e cria uma area de despejo no diretorio /usr/tmp/gated_dump, é necessário rodar como root.
-C
especifica que o arquivo de configuração so será lido ser houver erros de sintaxe, marca 1 se houver erros e 0 caso não tenha erros.
-n
Especifica que o gate não irá modificar tabela de roteamento do kernel. É usado para testar as configurações atuais.
-N
Specifies that gated will not daemonize. Normally, if tracing to stderr is not specified, gated will daemonize if the
parent process ID is not 1. This allows the use of an /etc/inittab-like method of invoking gated that does not have a PID of
1.
-t
Especifica uma lista separada por vírgula de opções de trace para serem ativados na inicialização. Se nenhuma opção for especificada, será assumida as configurações padroes, Nenhum espaço é permitido entre esta opção e os seus argumentos.
Esta opção deve ser usada para buscar eventos que ocorrem antes do arquivo de configuração ser analisado, como a determinação da configuração da interface e leitura de rotas a partir do kernel. Essas opções são explicadas em maiores detalhes em gated.conf.
-f
Use um arquivo de configuração alternativo ao invés do padrão gated.conf.
Arquivo do gated:
/etc/gated
Binario do gated
/etc/gated.conf
arquivo de configuração padrao
/etc/gated.conf+
Arquivo de configuração mais recente
/etc/gated.conf-
older configuration file
/etc/gated.conf--
Arquivo de configuração mais velho
/etc/gated.pid
Arquivo onde contem o pid do gated
/var/tmp/gated_dump
Arquivo de dump do gate(despejo do grated)
/var/tmp/%s_parse
Arquivos de armazenamento de erros
Download da pacote rmp do gated:
http://rpmfind.net/linux/rpm2html/search.php?query=gated
O gated trabalha com os protocolos de roteamento RIP, BGP e OSPF.
para utiliza-lo voce deverá usar o caminho /etc/gated e não /usr/sbin/in.gated com uma das opções baixo:
/etc/gated [ -c ] [ -C ] [ -n ] [ -N ] [ -t trace_options ] [ -f config_file ] [ trace_file ]
-c
Verifica se o arquivo tem erros de sintaxe na configuração e cria uma area de despejo no diretorio /usr/tmp/gated_dump, é necessário rodar como root.
-C
especifica que o arquivo de configuração so será lido ser houver erros de sintaxe, marca 1 se houver erros e 0 caso não tenha erros.
-n
Especifica que o gate não irá modificar tabela de roteamento do kernel. É usado para testar as configurações atuais.
-N
Specifies that gated will not daemonize. Normally, if tracing to stderr is not specified, gated will daemonize if the
parent process ID is not 1. This allows the use of an /etc/inittab-like method of invoking gated that does not have a PID of
1.
-t
Especifica uma lista separada por vírgula de opções de trace para serem ativados na inicialização. Se nenhuma opção for especificada, será assumida as configurações padroes, Nenhum espaço é permitido entre esta opção e os seus argumentos.
Esta opção deve ser usada para buscar eventos que ocorrem antes do arquivo de configuração ser analisado, como a determinação da configuração da interface e leitura de rotas a partir do kernel. Essas opções são explicadas em maiores detalhes em gated.conf.
-f
Use um arquivo de configuração alternativo ao invés do padrão gated.conf.
Arquivo do gated:
/etc/gated
Binario do gated
/etc/gated.conf
arquivo de configuração padrao
/etc/gated.conf+
Arquivo de configuração mais recente
/etc/gated.conf-
older configuration file
/etc/gated.conf--
Arquivo de configuração mais velho
/etc/gated.pid
Arquivo onde contem o pid do gated
/var/tmp/gated_dump
Arquivo de dump do gate(despejo do grated)
/var/tmp/%s_parse
Arquivos de armazenamento de erros
Download da pacote rmp do gated:
http://rpmfind.net/linux/rpm2html/search.php?query=gated
quarta-feira, 4 de maio de 2011
Google negociando com operadoras dos EUA para dificultar uso de celulares Android como modem 3G
Dar uma olhada em tethering e criar um táctica.
A prática do tethering, ou compartilhamento da conexão de dados do celular com um computador ou tablet, é bastante desejada pelos usuários, mas incomoda o modelo de negócio das operadoras dos EUA, que têm planos especiais (leia-se: mais caros) para quem quer usar este tipo de serviço.
Não é de surpreender, portanto, que elas tentem pressionar de todas as formas contra os hacks e aplicativos que elas consideram “abusivos” por permitir que usuários de planos de dados contratualmente exclusivos para uso pelo celular façam este tipo de conexão, vulgarmente conhecida como “usar o celular como modem” (via USB ou Bluetooth) ou “usar o celular como roteador Wi-Fi”.
No Brasil a situação dos planos é diferente, mas nos EUA a pressão das operadoras aparentemente está chegando ao Google, que está operando em conjunto com elas para restringir determinados aplicativos do Android Market que permitiam oferecer capacidade de compartilhamento que excede a do plano de dados contratado. Caso interessante a ser acompanhado! (via osnews.com)
A prática do tethering, ou compartilhamento da conexão de dados do celular com um computador ou tablet, é bastante desejada pelos usuários, mas incomoda o modelo de negócio das operadoras dos EUA, que têm planos especiais (leia-se: mais caros) para quem quer usar este tipo de serviço.
Não é de surpreender, portanto, que elas tentem pressionar de todas as formas contra os hacks e aplicativos que elas consideram “abusivos” por permitir que usuários de planos de dados contratualmente exclusivos para uso pelo celular façam este tipo de conexão, vulgarmente conhecida como “usar o celular como modem” (via USB ou Bluetooth) ou “usar o celular como roteador Wi-Fi”.
No Brasil a situação dos planos é diferente, mas nos EUA a pressão das operadoras aparentemente está chegando ao Google, que está operando em conjunto com elas para restringir determinados aplicativos do Android Market que permitiam oferecer capacidade de compartilhamento que excede a do plano de dados contratado. Caso interessante a ser acompanhado! (via osnews.com)
Re-post Analisando aplicações Linux com strace e ltrace
Neste artigo vamos estudar o uso das ferramentas strace e ltrace para analisar aplicações Linux.
Alguma vez você já tentou executar uma aplicação de linha de comando em Linux que simplesmente retornava sem exibir nenhuma mensagem de erro? Ou então um erro de segmentation fault que não fazia sentido? Já precisou entender porque uma aplicação estava demorando demais para executar? Ou travando sem nenhuma explicação?
Estas são situações bastante comuns em Linux, seja no universo desktop ou embarcado. Mas você não precisa se desesperar! Você esta em um ambiente ideal para debugar aplicações.
Olhe só este exemplo. O netcat (ou nc) é uma popular ferramenta de rede para trabalhar com o protocolo TCP/IP. O comando abaixo visa se conectar em um servidor na máquina local e na porta 1234.
$ nc localhost 1234
$
Veja que o comando simplesmente retornou sem exibir nenhuma mensagem de erro. O que aconteceu? Qual a melhor forma de analisar este tipo de situação?
É aí que entram as ferramentas strace e ltrace.
STRACE
O strace é uma ferramenta que monitora as chamadas de sistema (system calls) e os sinais recebidos pela aplicação. A maneira mais comum de executá-la é passando a aplicação a ser monitorada como parâmetro.
Voltando ao nosso exemplo, veja como ela funciona:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ strace nc localhost 1234
execve("/bin/nc", ["nc", "localhost", "2000"], [/* 37 vars */]) = 0
brk(0) = 0x9864000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7835000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127096, ...}) = 0
mmap2(NULL, 127096, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7815000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
..........
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(2000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, NULL, [3], NULL, NULL) = 1 (out [3])
getsockopt(3, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
close(3) = 0
close(-1) = -1 EBADF (Bad file descriptor)
exit_group(1) = ?
Cada linha é uma chamada de sistema com os parâmetros e o código de retorno. Foram 262 chamadas ao sistema no total, e por questões de espaço, estou exibindo apenas as 10 primeiras e as 10 últimas linhas. Mas estas linhas são suficientes para entender o que esta acontecendo ao executar o comando nc.
Na linha 16, a chamada à função connect() esta retornando erro (-1) ao se conectar na minha máquina (127.0.0.1) na porta 1234 (não existe nenhum servidor na minha máquina escutando a porta 1234).
O exemplo foi bem simples, mas nos dá uma noção do poder desta ferramenta. A grande vantagem é que não precisamos do código-fonte da aplicação, nem de símbolos no arquivo binário. Tudo isso funciona através de uma funcionalidade fornecida pelo kernel, chamada de ptrace, que possibilita que um processo possa controlar outro processo, manipulando seus descritores de arquivo, memória, registradores, etc. É isso que faz o strace.
É claro que existem muitas outras aplicações para o strace. Basta usar a imaginação.
Você já instalou alguma aplicação mas não sabia onde ela buscava o arquivo de configuração? O comando abaixo pode te responder:
$ strace app_name 2>&1 | grep "open" | grep "\/etc"
Com este comando, buscamos todas as chamadas open() em arquivos dentro de “/etc”.
Perceba também que o strace não serve apenas para debug. É também a ferramenta perfeita para você entender o funcionamento de uma aplicação e até fazer engenharia reversa quando o que você tem é apenas o binário.
Além disso, com o strace podemos fazer análise de performance através do parâmetro “–c”.
$ strace -c du /home/sprado
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
70.16 0.273238 12 23144 getdents64
28.63 0.111506 1 104334 fstatat64
0.43 0.001680 0 11559 write
0.29 0.001130 0 23734 close
0.24 0.000927 0 34716 fcntl64
0.23 0.000881 0 12148 openat
0.02 0.000096 0 12166 fstat64
0.00 0.000000 0 3 read
0.00 0.000000 0 30 13 open
0.00 0.000000 0 1 execve
0.00 0.000000 0 3 3 access
0.00 0.000000 0 14 brk
0.00 0.000000 0 2 munmap
0.00 0.000000 0 4 mprotect
0.00 0.000000 0 21 mmap2
0.00 0.000000 0 1 set_thread_area
------ ----------- ----------- --------- --------- ----------------
100.00 0.389458 221880 16 total
Temos algumas informações valiosas na saída deste comando. Os contadores de cada chamada do sistema (calls) e tempo de processamento (seconds) são extremamente úteis quando queremos saber onde esta o gargalo na execução da nossa aplicação.
Existem ainda muitas outras funcionalidades. Você pode monitorar apenas as chamadas de sistema relacionadas à rede usando “trace=network” como parâmetro, ou então a comunicação entre processos usando “trace=ipc”. Uma descrição completa das funcionalidades do strace podem ser encontradas no manual da ferramenta.
$ man strace
LTRACE
O ltrace tem as mesmas características do strace, mas ao invés de monitorar as chamadas do sistema, ele monitora as chamadas às funções das bibliotecas carregadas dinamicamente.
Veja como ficaria o nosso exemplo do “nc” com o ltrace:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ ltrace nc localhost 1234
__libc_start_main(0x804a700, 3, 0xbf868d94, 0x804caa0, 0x804ca90
getopt(3, 0xbf868d94, "46Ddhi:jklnP:p:q:rSs:tT:Uuvw:X:x"...) = -1
getservbyname("1234", "tcp") = NULL
strchr("1234", '-') = NULL
strtoul(0xbf86a695, 0xbf866b4c, 10, 0xbf868d94, 0x804d0f8) = 1234
calloc(1, 6) = 0x091c0520
getaddrinfo("localhost", "1234", 0xbf866b78, 0xbf866b4c) = 0
socket(2, 1, 6) = 3
fcntl(3, 3, 0, 0xbf866b4c, 0x8e49ae) = 2
fcntl(3, 4, 2050, 0xbf866b4c, 0x8e49ae) = 0
connect(3, 0x91c0cf0, 16, 0xbf866b4c, 0x8e49ae) = -1
__errno_location() = 0xb77eb688
select(4, 0, 0xbf866a98, 0, 0) = 1
getsockopt(3, 1, 4, 0xbf866b44, 0xbf866b40) = 0
fcntl(3, 4, 2, 0xbf866b44, 0xbf866b40) = 0
close(3) = 0
freeaddrinfo(0x091c0cd0) =
close(-1) = -1
exit(1
+++ exited (status 1) +++
Veja que, da mesma forma, conseguimos identificar o problema na chamada a connect() na linha 12.
O detalhe aqui é que esta ferramenta monitora apenas a chamada às funções de biblioteca linkadas dinamicamente com a aplicação, e por isso você não conseguirá usá-la se a aplicação for linkada estaticamente com as bibliotecas do sistema.
NO UNIVERSO EMBEDDED
A utilização destas ferramentas em Linux embarcado é idêntica. A única diferença é que você irá precisar cross-compilar o strace e o ltrace para executar na sua arquitetura-alvo.
O conhecimento e o uso deste tipo de ferramenta é essencial para o desenvolvedor Linux. Seja para debugar um problema em determinada aplicação, monitorar sua performance ou aprender sobre seu funcionamento, investir um tempo para conhecê-la mais profundamente é extremamente válido. Mas não existe conhecimento sem prática. Portanto, mãos à obra!
Um abraço,
Sergio Prado
Alguma vez você já tentou executar uma aplicação de linha de comando em Linux que simplesmente retornava sem exibir nenhuma mensagem de erro? Ou então um erro de segmentation fault que não fazia sentido? Já precisou entender porque uma aplicação estava demorando demais para executar? Ou travando sem nenhuma explicação?
Estas são situações bastante comuns em Linux, seja no universo desktop ou embarcado. Mas você não precisa se desesperar! Você esta em um ambiente ideal para debugar aplicações.
Olhe só este exemplo. O netcat (ou nc) é uma popular ferramenta de rede para trabalhar com o protocolo TCP/IP. O comando abaixo visa se conectar em um servidor na máquina local e na porta 1234.
$ nc localhost 1234
$
Veja que o comando simplesmente retornou sem exibir nenhuma mensagem de erro. O que aconteceu? Qual a melhor forma de analisar este tipo de situação?
É aí que entram as ferramentas strace e ltrace.
STRACE
O strace é uma ferramenta que monitora as chamadas de sistema (system calls) e os sinais recebidos pela aplicação. A maneira mais comum de executá-la é passando a aplicação a ser monitorada como parâmetro.
Voltando ao nosso exemplo, veja como ela funciona:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ strace nc localhost 1234
execve("/bin/nc", ["nc", "localhost", "2000"], [/* 37 vars */]) = 0
brk(0) = 0x9864000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7835000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127096, ...}) = 0
mmap2(NULL, 127096, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7815000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
..........
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(2000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, NULL, [3], NULL, NULL) = 1 (out [3])
getsockopt(3, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
close(3) = 0
close(-1) = -1 EBADF (Bad file descriptor)
exit_group(1) = ?
Cada linha é uma chamada de sistema com os parâmetros e o código de retorno. Foram 262 chamadas ao sistema no total, e por questões de espaço, estou exibindo apenas as 10 primeiras e as 10 últimas linhas. Mas estas linhas são suficientes para entender o que esta acontecendo ao executar o comando nc.
Na linha 16, a chamada à função connect() esta retornando erro (-1) ao se conectar na minha máquina (127.0.0.1) na porta 1234 (não existe nenhum servidor na minha máquina escutando a porta 1234).
O exemplo foi bem simples, mas nos dá uma noção do poder desta ferramenta. A grande vantagem é que não precisamos do código-fonte da aplicação, nem de símbolos no arquivo binário. Tudo isso funciona através de uma funcionalidade fornecida pelo kernel, chamada de ptrace, que possibilita que um processo possa controlar outro processo, manipulando seus descritores de arquivo, memória, registradores, etc. É isso que faz o strace.
É claro que existem muitas outras aplicações para o strace. Basta usar a imaginação.
Você já instalou alguma aplicação mas não sabia onde ela buscava o arquivo de configuração? O comando abaixo pode te responder:
$ strace app_name 2>&1 | grep "open" | grep "\/etc"
Com este comando, buscamos todas as chamadas open() em arquivos dentro de “/etc”.
Perceba também que o strace não serve apenas para debug. É também a ferramenta perfeita para você entender o funcionamento de uma aplicação e até fazer engenharia reversa quando o que você tem é apenas o binário.
Além disso, com o strace podemos fazer análise de performance através do parâmetro “–c”.
$ strace -c du /home/sprado
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
70.16 0.273238 12 23144 getdents64
28.63 0.111506 1 104334 fstatat64
0.43 0.001680 0 11559 write
0.29 0.001130 0 23734 close
0.24 0.000927 0 34716 fcntl64
0.23 0.000881 0 12148 openat
0.02 0.000096 0 12166 fstat64
0.00 0.000000 0 3 read
0.00 0.000000 0 30 13 open
0.00 0.000000 0 1 execve
0.00 0.000000 0 3 3 access
0.00 0.000000 0 14 brk
0.00 0.000000 0 2 munmap
0.00 0.000000 0 4 mprotect
0.00 0.000000 0 21 mmap2
0.00 0.000000 0 1 set_thread_area
------ ----------- ----------- --------- --------- ----------------
100.00 0.389458 221880 16 total
Temos algumas informações valiosas na saída deste comando. Os contadores de cada chamada do sistema (calls) e tempo de processamento (seconds) são extremamente úteis quando queremos saber onde esta o gargalo na execução da nossa aplicação.
Existem ainda muitas outras funcionalidades. Você pode monitorar apenas as chamadas de sistema relacionadas à rede usando “trace=network” como parâmetro, ou então a comunicação entre processos usando “trace=ipc”. Uma descrição completa das funcionalidades do strace podem ser encontradas no manual da ferramenta.
$ man strace
LTRACE
O ltrace tem as mesmas características do strace, mas ao invés de monitorar as chamadas do sistema, ele monitora as chamadas às funções das bibliotecas carregadas dinamicamente.
Veja como ficaria o nosso exemplo do “nc” com o ltrace:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ ltrace nc localhost 1234
__libc_start_main(0x804a700, 3, 0xbf868d94, 0x804caa0, 0x804ca90
getopt(3, 0xbf868d94, "46Ddhi:jklnP:p:q:rSs:tT:Uuvw:X:x"...) = -1
getservbyname("1234", "tcp") = NULL
strchr("1234", '-') = NULL
strtoul(0xbf86a695, 0xbf866b4c, 10, 0xbf868d94, 0x804d0f8) = 1234
calloc(1, 6) = 0x091c0520
getaddrinfo("localhost", "1234", 0xbf866b78, 0xbf866b4c) = 0
socket(2, 1, 6) = 3
fcntl(3, 3, 0, 0xbf866b4c, 0x8e49ae) = 2
fcntl(3, 4, 2050, 0xbf866b4c, 0x8e49ae) = 0
connect(3, 0x91c0cf0, 16, 0xbf866b4c, 0x8e49ae) = -1
__errno_location() = 0xb77eb688
select(4, 0, 0xbf866a98, 0, 0) = 1
getsockopt(3, 1, 4, 0xbf866b44, 0xbf866b40) = 0
fcntl(3, 4, 2, 0xbf866b44, 0xbf866b40) = 0
close(3) = 0
freeaddrinfo(0x091c0cd0) =
close(-1) = -1
exit(1
+++ exited (status 1) +++
Veja que, da mesma forma, conseguimos identificar o problema na chamada a connect() na linha 12.
O detalhe aqui é que esta ferramenta monitora apenas a chamada às funções de biblioteca linkadas dinamicamente com a aplicação, e por isso você não conseguirá usá-la se a aplicação for linkada estaticamente com as bibliotecas do sistema.
NO UNIVERSO EMBEDDED
A utilização destas ferramentas em Linux embarcado é idêntica. A única diferença é que você irá precisar cross-compilar o strace e o ltrace para executar na sua arquitetura-alvo.
O conhecimento e o uso deste tipo de ferramenta é essencial para o desenvolvedor Linux. Seja para debugar um problema em determinada aplicação, monitorar sua performance ou aprender sobre seu funcionamento, investir um tempo para conhecê-la mais profundamente é extremamente válido. Mas não existe conhecimento sem prática. Portanto, mãos à obra!
Um abraço,
Sergio Prado
segunda-feira, 2 de maio de 2011
domingo, 1 de maio de 2011
Pytbull: IDS-IPS Testing Framework para Snort e Suricata
Para aqueles que procuram por uma opção de fonte aberta com o intuito de testar seus dispositivos IDS/IPS, Pytbull é a escolha adequada para esta finalidade. Ele é um framework de testes de Intrusion Detection / Prevention System (IDS / IPS) para Snort e Suricata. Muitos de nós temos conhecimento da importância e da grandiosidade destes dois projetos.
Mesmo que se concentre sobre o Snort e sobre o Suricata, ele também pode ser utilizado para testar a capacidade de detecção e bloqueio de outros IDS / IPS. Além disso, você também pode usá-lo para comparar IDS / IPS, comparar suas modificações de configuração, ou simplesmente para verificar / validar essas configurações. O framework está bem equipado, com cerca de 300 testes agrupados em 8 módulos de testes, tais como:
- clientSideAttacks: Este módulo usa um shell reverso para fornecer ao servidor as instruções para download remoto de arquivos maliciosos.
- testRules: É um teste de regras básicas do módulo. Estes ataques deveriam ser detectados pelas regras definidas e fornecidas com o IDS / IPS.
-badTraffic: Este módulo não transmite pacotes compatíveis com RFC para o servidor para testar como os pacotes são processados e respondidos.
-fragmentedPackets: Este módulo transmite vários payloads para um servidor, na intenção de testar sua capacidade de recompor-los e detectar os ataques.
-multipleFailedLogins: Este módulo testa a capacidade do servidor para controlar vários logins falhos (por exemplo, FTP). Ele faz uso de regras personalizadas sobre o Snort e Suricata.
-evasionTechniques: Este módulo utiliza várias técnicas de evasão para verificar se o IDS/IPS pode detectá-los.
-shellcodes: Este módulo transmite shellcodes diversos para o servidor na porta 21/tcp, para testar a capacidade do servidor de detectar e rejeitar shellcodes.
-denialOfService: Este módulo transmite testa a capacidade do IDS / IPS para se proteger contra tentativas de DoS simples.
Pytbull é facilmente configurável e pode integrar novos módulos no futuro. Depois de baixá-lo, você precisa editar o arquivo config.cfg que acompanha a ferramenta.
Saiba Mais:
[1] Pytbull: An IDS/IPS Testing Framework: http://www.pentestit.com/2011/04/30/pytbull-idsips-testing-framework/
Mesmo que se concentre sobre o Snort e sobre o Suricata, ele também pode ser utilizado para testar a capacidade de detecção e bloqueio de outros IDS / IPS. Além disso, você também pode usá-lo para comparar IDS / IPS, comparar suas modificações de configuração, ou simplesmente para verificar / validar essas configurações. O framework está bem equipado, com cerca de 300 testes agrupados em 8 módulos de testes, tais como:
- clientSideAttacks: Este módulo usa um shell reverso para fornecer ao servidor as instruções para download remoto de arquivos maliciosos.
- testRules: É um teste de regras básicas do módulo. Estes ataques deveriam ser detectados pelas regras definidas e fornecidas com o IDS / IPS.
-badTraffic: Este módulo não transmite pacotes compatíveis com RFC para o servidor para testar como os pacotes são processados e respondidos.
-fragmentedPackets: Este módulo transmite vários payloads para um servidor, na intenção de testar sua capacidade de recompor-los e detectar os ataques.
-multipleFailedLogins: Este módulo testa a capacidade do servidor para controlar vários logins falhos (por exemplo, FTP). Ele faz uso de regras personalizadas sobre o Snort e Suricata.
-evasionTechniques: Este módulo utiliza várias técnicas de evasão para verificar se o IDS/IPS pode detectá-los.
-shellcodes: Este módulo transmite shellcodes diversos para o servidor na porta 21/tcp, para testar a capacidade do servidor de detectar e rejeitar shellcodes.
-denialOfService: Este módulo transmite testa a capacidade do IDS / IPS para se proteger contra tentativas de DoS simples.
Pytbull é facilmente configurável e pode integrar novos módulos no futuro. Depois de baixá-lo, você precisa editar o arquivo config.cfg que acompanha a ferramenta.
Saiba Mais:
[1] Pytbull: An IDS/IPS Testing Framework: http://www.pentestit.com/2011/04/30/pytbull-idsips-testing-framework/
Assinar:
Postagens (Atom)