terça-feira, 31 de maio de 2011

Escrito nem sempre é o que é realmente vivido.

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

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).

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

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

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/

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

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

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)

Re-post Analisando aplicações Linux com strace e ltrace

Neste artigo vamos estu­dar o uso das fer­ra­men­tas strace e ltrace para anal­isar apli­cações Linux.

Alguma vez você já ten­tou exe­cu­tar uma apli­cação de linha de comando em Linux que sim­ples­mente retor­nava sem exibir nen­huma men­sagem de erro? Ou então um erro de seg­men­ta­tion fault que não fazia sen­tido? Já pre­cisou enten­der porque uma apli­cação estava demor­ando demais para exe­cu­tar? Ou tra­vando sem nen­huma explicação?

Estas são situ­ações bas­tante comuns em Linux, seja no uni­verso desk­top ou embar­cado. Mas você não pre­cisa se deses­perar! Você esta em um ambi­ente ideal para debugar apli­cações.

Olhe só este exem­plo. O net­cat (ou nc) é uma pop­u­lar fer­ra­menta de rede para tra­bal­har com o pro­to­colo TCP/IP. O comando abaixo visa se conec­tar em um servi­dor na máquina local e na porta 1234.

$ nc localhost 1234
$

Veja que o comando sim­ples­mente retornou sem exibir nen­huma men­sagem de erro. O que acon­te­ceu? Qual a mel­hor forma de anal­isar este tipo de situ­ação?

É aí que entram as fer­ra­men­tas strace e ltrace.

STRACE

O strace é uma fer­ra­menta que mon­i­tora as chamadas de sis­tema (sys­tem calls) e os sinais rece­bidos pela apli­cação. A maneira mais comum de executá-la é pas­sando a apli­cação a ser mon­i­torada como parâmetro.

Voltando ao nosso exem­plo, veja como ela fun­ciona:

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 sis­tema com os parâmet­ros e o código de retorno. Foram 262 chamadas ao sis­tema no total, e por questões de espaço, estou exibindo ape­nas as 10 primeiras e as 10 últi­mas lin­has. Mas estas lin­has são sufi­cientes para enten­der o que esta acon­te­cendo ao exe­cu­tar o comando nc.

Na linha 16, a chamada à função con­nect() esta retor­nando erro (-1) ao se conec­tar na minha máquina (127.0.0.1) na porta 1234 (não existe nen­hum servi­dor na minha máquina escu­tando a porta 1234).

O exem­plo foi bem sim­ples, mas nos dá uma noção do poder desta fer­ra­menta. A grande van­tagem é que não pre­cisamos do código-fonte da apli­cação, nem de sím­bo­los no arquivo binário. Tudo isso fun­ciona através de uma fun­cional­i­dade fornecida pelo ker­nel, chamada de ptrace, que pos­si­bilita que um processo possa con­tro­lar outro processo, manip­u­lando seus descritores de arquivo, memória, reg­istradores, etc. É isso que faz o strace.

É claro que exis­tem muitas out­ras apli­cações para o strace. Basta usar a imag­i­nação.

Você já instalou alguma apli­cação mas não sabia onde ela bus­cava o arquivo de con­fig­u­ração? O comando abaixo pode te respon­der:

$ strace app_name 2>&1 | grep "open" | grep "\/etc"

Com este comando, bus­camos todas as chamadas open() em arquivos den­tro de “/etc”.

Perceba tam­bém que o strace não serve ape­nas para debug. É tam­bém a fer­ra­menta per­feita para você enten­der o fun­ciona­mento de uma apli­cação e até fazer engen­haria reversa quando o que você tem é ape­nas o binário.

Além disso, com o strace podemos fazer análise de per­for­mance 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 algu­mas infor­mações valiosas na saída deste comando. Os con­ta­dores de cada chamada do sis­tema (calls) e tempo de proces­sa­mento (sec­onds) são extrema­mente úteis quando quer­e­mos saber onde esta o gar­galo na exe­cução da nossa aplicação.

Exis­tem ainda muitas out­ras fun­cional­i­dades. Você pode mon­i­torar ape­nas as chamadas de sis­tema rela­cionadas à rede usando “trace=network” como parâmetro, ou então a comu­ni­cação entre proces­sos usando “trace=ipc”. Uma descrição com­pleta das fun­cional­i­dades do strace podem ser encon­tradas no man­ual da fer­ra­menta.

$ man strace

LTRACE

O ltrace tem as mes­mas car­ac­terís­ti­cas do strace, mas ao invés de mon­i­torar as chamadas do sis­tema, ele mon­i­tora as chamadas às funções das bib­liote­cas car­regadas dinami­ca­mente.

Veja como ficaria o nosso exem­plo 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, con­seguimos iden­ti­ficar o prob­lema na chamada a con­nect() na linha 12.

O detalhe aqui é que esta fer­ra­menta mon­i­tora ape­nas a chamada às funções de bib­lioteca linkadas dinami­ca­mente com a apli­cação, e por isso você não con­seguirá usá-la se a apli­cação for linkada esta­ti­ca­mente com as bib­liote­cas do sistema.

NO UNIVERSO EMBEDDED

A uti­liza­ção destas fer­ra­men­tas em Linux embar­cado é idên­tica. A única difer­ença é que você irá pre­cisar cross-compilar o strace e o ltrace para exe­cu­tar na sua arquitetura-alvo.

O con­hec­i­mento e o uso deste tipo de fer­ra­menta é essen­cial para o desen­volve­dor Linux. Seja para debugar um prob­lema em deter­mi­nada apli­cação, mon­i­torar sua per­for­mance ou apren­der sobre seu fun­ciona­mento, inve­stir um tempo para conhecê-la mais pro­fun­da­mente é extrema­mente válido. Mas não existe con­hec­i­mento sem prática. Por­tanto, mãos à obra!

Um abraço,

Ser­gio Prado

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/

Hardware OpenSource

http://opencores.org/donation