Emexis-webmail

O Emexis-webmail é uma ferramenta de acesso ao correio eletrônico, através de um navegador, um Webmail.
Possui diversas funcionalidades como: Enviar e receber e-mails, lista de
contatos, agendamentos de eventos e compromissos, manipulação de
pastas, pedido de confirmação, etc. O Emexis-webmail integra-se com os
produtos Brconnection, a principio com BRMA4 e futuramente com o mais
novo produto Emexis (Email Exchange Intercept).

Baseado no Webmail Squirrelmail (www.squirrelmail.org), ferramenta que
nunca deixou nada a desejar. Porém, a interface gráfica do webmail, não
é das mais amigáveis para o usuário. Por este motivo a Brconnection,
teve como objetivo principal utilizar todos recursos e manutenção do
Squirrelmail, customizando a interface e criando seus próprios plugins.

esse webmail está disponivel para downlod sob licença GPL no endereço abaixo

http://www.srvupdate.brc.com.br/emexis-webmail/1.0/release/emexis-webmail-1.0-2.tgz


Manuais em português:
http://www.srvupdate.brc.com.br/emexis-webmail/1.0/manual/brc-mod-webmail-user-pt_BR.pdf

Manuais em inglês:
http://www.srvupdate.brc.com.br/emexis-webmail/1.0/manual/brc-mod-webmail-user-en.pdf

Para acessar a versão demonstrativa do Emexis-webmail acesse http://webmaildemo.brc.com.br:10005.

Dúvidas ou problemas com o Emexis-webmail envie um email para
emexis-webmail at brc.com.br


fonte: http://eos.brc.com.br

Owasp AppSec Brasil 2009

Tenho o prazer de anunciar que a Conferência Internacional sobre Segurança
de Aplicações, a ser realizada nos dias 27 a 29 de outubro de 2009 nas
dependências da Câmara dos Deputados, em Brasília, DF é agora o primeiro
OWASP AppSec Brazil 2009.

Isso é uma vitória do Capítulo OWASP Brasil que está tentando trazer o
evento para o nosso país desde novembro de 2008 e finalmente conseguiu
discutir o assunto com todos os envolvidos e conseguir a aprovação
necessária para isso.

A Conferência será promovida pelo OWASP Brasil com o suporte da Comunidade
TI-Controle (www.ti-controle.gov.br) para tratar os diferentes assuntos
relacionados a Segurança de Aplicações, tais como:

 - desenvolvimento seguro,
 - segurança e arquitetura de software,
 - processos de desenvolvimento de sistemas seguros,
 - ferramentas para análise de segurança de aplicações,
 - bibliotecas e frameworks de segurança para aplicações web,
 - auditoria e testes de segurança em aplicações,
 - metodologias gerenciais para melhoria da segurança no desenvolvimento de
software,
 - análise de ataques a aplicações,
 - avaliação de riscos de negócio em aplicações web,
 - segurança de webservices.

A Conferência terá dois dias de treinamentos (27 e 28 de outubro) seguidos
de dois dias de palestras(29 e 30 de outubro). A página com as informações 
relacionadasestá disponível na Wiki da OWASP em
<a href="https://www.owasp.org/index.php/AppSec_Brasil_2009.">https://www.owasp.org/index.php/AppSec_Brasil_2009.</a>

Por favor Divulguem

Vulnerabilidade DOS Openswan/Strongswan/SuperFreeswan

Notícia creio que um pouco atrasada... saiu no mes 4 a vulnerabilidade,
mas como nao vi nada na lista achei melhor postar (antes tarde do que
nunca =D  )

Foi encontrada uma vulnerabilidade nas versões
inferiores a 2.6-21 do Openswan e também no Stongswan e SuperFreeswan,
onde o daemon do IKE (pluto) permite que uma origem remota cause um DOS
fazendo com que o pluto "trave e reinicie" assim que uma requisição de
DPD sem criptografia (RFC-3706) e com estado desconhecido ou deletado
for recebido


Os desenvolvedores do Openswan (creio que strongswan tbm) ja
liberaram um patch para correção do mesmo, quem preferir pode atualizar
o Openswan para versão 2.6-21.
---

RFC 3706                Detecting Dead IKE Peers           February 2004



   The R-U-THERE message corresponds to a "HELLO" and the R-U-THERE-ACK
   corresponds to an "ACK."  Both messages are simply ISAKMP Notify
   payloads, and as such, this document defines these two new ISAKMP

   Notify message types:

      Notify                      Message Value
      R-U-THERE                   36136
      R-U-THERE-ACK               36137

   An entity that has sent the DPD Vendor ID MUST respond to an R-U-

   THERE query.  Furthermore, an entity MUST reject unencrypted R-U-
   THERE and R-U-THERE-ACK messages.

---
Nist:
http://web.nvd.nist.gov/view/vuln/detail;jsessionid=4348fc4ff311f0845537d203a2ef?execution=e1s1


RFC:
http://www.ietf.org/rfc/rfc3706.txt

EOS-Linux é Open Source

Atualmente sou mantenedor do EOS-Linux, trabalho esse que divido com minhas funções na BRC, é um projeto muito bacana e inovador... um linux criado do zero sem depender de nada... que pode ficar com a cara que vc quiser... é muito facil e prático trabalhar com ele... basta conhecer um pouco de gerenciamento de pacotes e shell Script.

duvidas e/ou sugestões podem me procurar

"Criado a partir do zero, o EOS® segue o projeto do e-book Linux®
From Scratch como referência e inicialmente concebido para ser a
plataforma das soluções comerciais da BRconnection®, mas agora está
aberto para uso irrestrito.

Seu instalador é
inovador – não utiliza outros como referência – e facilita a vida de
profissionais que pouco conhecem de desenvolvimento, ou seja, qualquer
um com conhecimentos básicos em shell script pode desenvolver roteiros
de instalação de acordo com as necessidades específicas de cada
projeto."

Fonte: http://www.brc.com.br/index.php?option=com_content&task=view&id=731&Itemid=405&lang=pt_BR

Site EOS: http://eos.brc.com.br


Felipe Santos - Rasputin
MSN: flph2@hotmail.com
Gtalk: felipe.nix@gmail.com

Instalação Openswan 2.6 + Klips

Bom dia pessoal, a alguns dias estou utilizando a versão 2.6.18 do Openswan para testes, devido algumas alterações em versões anteriores 2.6.X se não me engano, não é mais necessário ficar aplicando patch para utilizar Klips no Openswan, basta compila-lo com alguns parâmetros e na hora de configurar adicionar o parâmetro protostack=klips dentro do conf, além de disponibilizar uma nova stack baseada no Klips (Creio EU que seu sucessor) chamada mast

--- Obtido da Manpage do ipsec.conf ---

protostack
decide which protocol stack is going to be used. Valid values are "auto", "klips", "netkey" and "mast". The "mast" stack is a variation for the klips stack.

-------

Com isso segue um tutorial bem básico de como compilar o Openswan + Klips utilizando a versão 2.6.18 do Openswan sem aplicar patch

- Requisitos:
libgmp e libgmp-devel
bison
flex
gawk


- Primeiro de tudo, descompactar o pacote do openswan...
#tar -zxvf openswan-2.6.18.tar.gz

Após isso executar o Make para fazer o build do openswan e dos modulos

#make KERNELSRC=/usr/src/linux-2.6.18 module programs

com o término do make se utilizar kernel 2.6 execute:

#make KERNELSRC=/usr/src/linux-2.6.18/build minstall install



com isso o openswan já estará instalado e com o klips ativado e com suporte a mast e netkey, caso habilitado no kernel, a jogada é bem simples..

protostack=klips
ou
protostack=netkey
ou
protostack=mast

Basta restartar o ipsec para alterar entre eles...

Obs.: se for utilizar netkey, utilize-o com kernel 2.6.6 ou superior... é conhecido que as versões anteriores possuem bugs na pilha IPSEC

Mascaramento IPSEC

Hoje na lsita de discussão a qual sou criador (Openswan-BR), houve um questionamento quanto a mascaramento de ipsec, se era necessário criar um mascaramento para que as estações se comunicassem pela VPN, o post de hoje é a resposta desse e-mail que acei legal explicar o motivo e quando é utilizado um mascaramento + IPSEC sem causar problemas nem precisar de NAT-T

Na verdade não se deve fazer isso... se o mascaramento for efetuado após a encriptação, creio eu que o unico
caso de ser necessário um mascaramento que conheço é quando ambas subnets são
iguais, ou por questões gerenciais (algumas empresas solicitam um range
específico para se fechar a vpn para evitar duplicidade), então devido
a isso se faz necessário fechar o túnel com a rede estipulada e criar
mascaramentos e Dnat para os acessos necessários.


Ex.:

Rede A = 192.168.0.0/24
ips de acesso rede B = 172.16.0.1 (outra ponta estipulou apenas um ip para conexão)

a conf do túnel fica:


leftsubnet=172.16.0.1/32
rigthsubnet=192.168.0.0/24

além disso é necessário criar uma interface que responda por esse ip e suas respectivas regras de mascaramento e DNAT


ifconf eth0:0 172.16.0.1

iptables -t nat -I PREROUTING -d 172.16.0.1 -p tcp --dport 80 -l DNAT --to 10.0.0.1 - Dnat para o servidor real


iptables -t nat -I POSTROUTING -s 10.0.0.1 -j SNAT --to 172.16.0.1 - Snat para o ip permitido no túnel.


(Detalhe,
note que todo o mascaramento foi efetuado antes de passar pelo ipsec,
sendo assim o pacote so é criptografado após o mascaramento, caso seja
efetuado o contrário, mascarar a saida do ipsec, o resultado não terá
sucesso, pois o dado ja estará encriptado e com um novo cabeçalho
criado para o túnel)


ex.:

Cabeçalho antes do IPSEC:

+----------------------------------------------+

| Cabeçalho IP | Cabeçalho TCP | Dados |
+----------------------------------------------+


Cabeçalho apos o IPSEC em modo transport: Cabeçalho IPSEC apenas é
adicionado para protoger os cabeçalhos de camadas superiores (
Transporte até Aplicação) devido a isso so pode ser utilizado no
Gateway IPSEC

+--------------------------------------------------------------------------------+
| Cabeçalho IP | Cabeçalho IPSEC | Cabeçalho TCP | Dados |
+----------------------------------------------------------------------+

Cabeçalho após IPSEC em modo túnel: Cabeçalho IPSEC protege todo o pacote
anterior e adiciona um novo cabeçalho IP (Encapsula) dessa forma
podendo ser utilizado em um Lan-To-Lan


+--------------------------------------------------------------------------------------------------+
| Cabeçalho IP | Cabeçalho IPSEC | Cabeçalho IP | Cabeçalho TCP | Dados |
+----------------------------------------------------------------------------------------+


Devido a isso caso seja alterado o pacote após o encapsulamento do ipsec o
pacote como um todo será alterado, impossibilitando a comunicação da
VPN, ja com o mascaramento antes do pacote ser encapsulado e possivel
pois um novo cabeçalho IP é criado no Modo Tunnel.

Métodos de Negociação do IPSEC

ISAKMP-SA (Internet Security Association Key Management Protocol Security Association)

É um “ID” obtido atraves do ip, id, email e DN (caso utilizados), esse id e criado automaticamente pelo isakmp durante a negociação da Fase I somados com a chave RSA/PSK utilizada.

Para que a Fase 1 seja negociada com sucesso e necessário que se utilize um método de negociação que pode ser Main Mode ou Aggressive Mode

Main Mode

Para que a Fase um seja estabelecida com sucesso é necessário que uma série de requisições seja enviada entre os Gateways vpn, o metodo normal dessa negociação ser feita chama-se Main Mode.

Esse Método possui uma latência maior, pois depende do envio e recebimento de vários pacotes para a negociação, devido a essa maior quantidade de requisições efetuadas sua segurança é maior.

Aggressive Mode

Muitos Fabricantes Utilizam esse modo de nogociação devido ter uma menor latência, pois envia menos requisições para estabelecer a fase 1, ISAKMP-SA, que é menor, esse modo é chamado de Aggressive Mode e reduz a quantidade de pacotes enviados, esse metodo requer mais CPU, pois tarefas relaionadas ao Diffie Hellman precisam ser concluídas antes do primeiro pacote ser reenviado. Devido a esse problema este método de negociação está sujeito a um Denial of Service, enviando ao IPSEC simples pacotes solicitando uma ISAKMP-SA

Main Mode X Aggressive Mode

A grande Vulnerabilidade do Aggressive Mode devido a redução de requisições efetuadas o hash da chave PSK é enviado antes da Encriptação ser habilitada, esse pacote pode ser capturado e uma ferramenta de brute force ou de dicionário pode obter a Chave utilizada. Já no Main mode o hash só é enviado após a encriptação ser habilitada

Com Aggressive Mode o pacote inicial da negociação contém todos os dados necessários para a fase 1, dessa forma o IPSEC remoto apenas verifica se pode efetuar ou não a solicitação. Dessa forma também está vulnerável a um ataque man-in-the-middle, caso esse pacote seja interceptado, um atacante pode obter uma conexão VPN válida.

Agressive Mode consome menos recursos de rede, devido fazer menos requisições porem requer mais CPU por ter que processar a SA inteira antes de terminar a Fase I

Main Mode consome mais recursos de rede, por enviar mais requisições, por outro lado consome menos cpu, por processar a SA aos poucos, conforme as requisições são recebidas/enviadas

VPN SSL através de Browser

Semana passada estava testando uma solução chamada SSL-explorer, uma
ferramenta que prove acesso remoto criptografado (ssl) , através de
browser, com ele basta o administrador configurar o que deseja
"compartilhar/publicar" e criar as politicas para seus usuários, após
isso o usuário remoto necessita apenas de um acesso https (443/tcp), ou
a porta que desejar configurar, para acessar recursos da rede como
servidores de FTP, Terminal Service, SSH, Compartilhamento Windows,
servidores de arquivos, etc... vale a pena dar uma olhada....

http://sourceforge.net/projects/sslexplorer

BackTrack 3 Final - Released

BackTrack 3 Final - Release Information

Released yesterday exclusively on pauldotcom.com



Muts, Martin and I have slaved for weeks and months, together with the

help of many remote-exploit'ers to bring you this fine release. As

usual, this version overshadows the previous ones with extra cool

things.



SAINT

SAINT has provided BackTrack users with a functional version of SAINT,

pending a free request for an IP range license through the SAINT

website, valid for 1 year.



Maltego

The guys over at Paterva have created a special version of Maltego

v2.0 with a community license especially for BackTrack users. We would

like to thank Paterva for co-operating with us and allowing us to

feature this amazing tool in BackTrack.



Nessus

Tenable would not allow for redistribution of Nessus on BackTrack 3.



Kernel

2.6.21.5. Yes, yes, stop whining....We had serious deliberations

concerning the BT3 kernel. We decided not to upgrade to a newer kernel

as wireless injection patches were not fully tested and verified. We

did not want to jeopardize the awesome wireless capabilities of BT3

for the sake of sexiness or slightly increased hardware

compatibilities. All relevant security patches have been applied.



Tools

As usual, updated, sharpened, SVN'ed and armed to the teeth. This

release we have some special features such as spoonwep, fastrack and

other cool additions.



Availability

For the first time we distribute three different version of Backtrack 3

- CD version

- USB version

- VMWare version



BackTrack 3 final download page is here:

http://remote-exploit.org/backtrack_download.html





Final Requests

We request the community to not mirror or torrent this release, or

otherwise distribute it online without our knowledge.

We are trying to gather statistics about bt3 downloads. If you would

like to mirror BT3 then please:



1) Think again! Traffic generated by BT3 downloads is CRAZY.

2) Please contact us before doing so.

3) Send us monthly statistics of downloads for the iso.



If you would like to add a link to BackTrack downloads to your

website, please use:



http://www.remote-exploit.org/backtrack_download.html as the download link.





Rants

Problems, fixes, bugs, opinions - should all end up in our Remote

Exploit community forums, and our wiki:



http://forums.remote-exploit.org

http://wiki.remote-exploit.org

Openswan-BR

Pessoal, á partir de hoje inicio uma lista de discussão sobre Openswan, chamada Openswan-BR, a intenção é reunir usuários e interessados em VPN e Openswan/Freeswan, com intuíto de tirar dúvidas e compartilhar informações em geral sobre VPN

Aos interessados segue as informações:



Página do Grupo

http://br.groups.yahoo.com/group/openswan-br

Endereços de e-mail do grupo

Enviar mensagem:	openswan-br@yahoogrupos.com.br
Entrar no grupo:	openswan-br-subscribe@yahoogrupos.com.br
Sair do grupo:	openswan-br-unsubscribe@yahoogrupos.com.br
Proprietário da lista:	openswan-br-owner@yahoogrupos.com.br