Batori Blog

Existem algumas considerações de segurança que devem ser levadas em consideração quando falamos na adoção da tecnologia MPLS (Multi Protocol Label Switching). Apesar da tecnologia MPLS permitir a criação de circuitos virtuais para cada cliente, o backbone do provedor será o mesmo para todos os clientes, ou seja, os dados de todos os clientes estarão passando fisicamente pelo mesmo meio.

Assim, como nos casos da terceirização de hospedagem de serviços/servidores, a empresa contratante do serviço deverá confiar não só na qualidade do serviço contrato, mas também nas práticas de segurança adotada pela empresa prestadora do serviço.

Apesar da tecnologia MPLS criar circuitos virtuais fechados para cada empresa, os dados que trafegam entre uma matriz e uma filial, por exemplo, não são alterados. Em outras palavras, a tecnologia MPLS não vai criptografar os dados em nenhum momento da comunicação.

Falhas de segurança encontradas na tecnologia MPLS

As falhas de segurança encontradas na tecnologia MPLS são as seguintes:

1- Se a configuração dos roteadores não for feita corretamente, seja por parte do cliente ou do provedor, a disponibilidade da rede MPLS e a confidencialidade dos dados que nela trafegam estarão comprometidas através da realização de ataques de DoS e Label Spoofing.

2- A tecnologia MPLS não utiliza qualquer tipo de criptografia para os dados que trafegam na rede MPLS, ou seja, se os dados que a empresa contratante planeja passar pela rede MPLS exigem determinado nível de confidencialidade, a tecnologia MPLS não é a opção mais recomendada.

Considerações finais

Todo sistema de segurança de uma empresa varia de acordo com o tipo de ativo que será protegido, de quais ameaças ele será protegido e qual será esse nível de proteção. Essas métricas só podem ser definidas pela empresa contratante. Por exemplo, se as informações que irão trafegar pela rede MPLS são confidenciais e estão ligadas diretamente ao negócio da empresa, é recomendável que se utilize o protocolo IPSec em conjunto com a tecnologia MPLS, caso os dados não possuam nenhuma criptografia nativa, como o SSL por exemplo.

Um ponto que muitas vezes não é analisado diz respeito à infra-estrutura da empresa que prestará o serviço. Não estamos falando somente de infra-estrutura de atendimento, disponibilidade etc. É necessário analisar as práticas de segurança da informação que empresa adotou. Alguns pontos que devem ser analisados: a empresa possui um SGSI? A configuração dos equipamentos direcionados ao serviço contratado segue as recomendações do fabricante e/ou alguma RFC? A empresa já fez alguma análise de risco deste serviço? Com que freqüência o sistema de segurança é testado?

Se utilizada corretamente, a tecnologia MPLS, em alguns casos até combinada com outras tecnologias como o IPSec, pode atender todas as necessidades de comunicação da empresa sem comprometer a confidencialidade e a integridade das informações que nela trafegam. Mas para que isso ocorra, os dois itens listados acima devem ser atendidos.

Existe uma RFC que fala exclusivamente sobre a segurança na tecnologia MPLS. Ela pode ser acessada em http://www.ietf.org/rfc/rfc4381.txt.

Recebemos um e-mail em nome do YouTube com a mensagem de que alguém havia indicado um vídeo para mim, baixei o vírus e iniciei a análise.

E-mail do phishing:

Pela engenharia social utilizada pode-se perceber que a pessoa aproveita-se do medo de que no vídeo as imagens tenham sido alteradas, e que ele possa conter cenas comprometedoras da pessoa que recebe o e-mail.

Clicando no link do e-mail é aberta uma caixa de download onde se instruí a clicar em “abrir”. Esse arquivo é um pequeno executável que quando aberto faz o download do trojan (Virus.Win32.Parite.b) e a sua instalação.
O malware é ativado no browser e aberto o site do internet banking. No teste os bancos Real, Itaú, Bradesco, Santander, Unibanco, Nossa Caixa e Caixa Econômica Federal ativaram o vírus.
Sempre que o vírus é ativado ele substitui os campos de agência e conta por uma imagem sobreposta às imagens originais do banco. Quando se digita seus dados de agência e conta e clica-se em “ok” para prosseguir o acesso, o malware exibe então a tela para a senha eletrônica.
No caso do Banco Itaú ele exibe o teclado numérico exatamente como deve ser o teclado da senha: dois números em cada botão. Depois são solicitadas duas vezes a senha eletrônica, com a ordem dos números alterada na segunda tentativa para se ter a certeza da senha. Após cadastrar a senha para acesso ao internet banking, o usuário é encaminhado para uma tela onde se lê: “Você deve recadastrar o seu cartão de segurança Itaú”. Solicita-se então todos os números do seu cartão de segurança, o número de série do cartão, data de nascimento e os 5 números do cartão magnético. Quando as informações foram digitadas e clica-se em “concluir” todas as informações são enviadas para dois e-mails: acristiane345@itelefonica.com.br e kalamazu2008@bol.com.br.

Veja o vídeo do trojan em ação

A melhor maneira de se evitar a infecção por malwares é ter sempre um antivírus instalado, um firewall e um antispyware, mantendo-os sempre atualizados. E ter consciência de que somente isso não basta. Tome muito cuidado ao abrir e-mails de origem duvidosa ou que você não tenha solicitado. E tenha precaução ao clicar nos links exibidos em e-mails. Se tiver que clicar ou acessar, e confirmar o endereço para o qual estiver apontando, não faça downloads ou abra arquivos de programas desconhecidos.
Finalmente, verifique sempre a correspondência de segurança do seu banco para saber como e quando são solicitados os dados do seu cartão de segurança e outras informações. Sempre que algo estranho surgir, acesse imediatamente o suporte do banco para ter certeza das atitudes que você irá tomar.

Autor: Ricardo Lino Gonzalez

Nossa equipe elaborou uma estatística sobre as principais vulnerabilidades encontradas em diversas aplicações. Para isso usamos os dados do histórico dos projetos realizados pela Batori nos últimos anos. Agrupamos as vulnerabilidades em categorias e contabilizamos a quantidade de vulnerabilidades por categoria.

Observamos que grande parte das vulnerabilidades não é detectada por ferramentas como scanners e analisadores de código e, quando analisados, não têm a devida eficácia.

Ver gráfico

1) Cross-site scripting (XSS) – Técnica de ataque que representa 13% das ocorrências. Ela permite executar scripts maliciosos no navegador do usuário da aplicação vulnerável.

2) Manipulação de dados ocultos – Ela responde, também, por 13% das ocorrências. A aplicação vulnerável permite acesso indevido quando dados ocultos são manipulados indevidamente.

3) Falha ao restringir acesso a URL ou funcionalidade – Essa vulnerabilidade, que ocorre porque a aplicação não restringe adequadamente suas áreas restritas, representa 11% das ocorrências.

4) Tratamento indevido de erro, revelação de informações sensíveis – A aplicação revela informações sensíveis através de uso não esperado. Responde por 9% das ocorrências.

5) Armazenamento inseguro de criptografia – Esse tipo de brecha, que representa 9% das ocorrências, expõe dados sensíveis, que deveriam ser armazenados de forma criptografada e estão em texto livre ou com criptografia inadequada.

6) Comunicação insegura – Vulnerabilidade responsável por 8% das ocorrências. A aplicação trafega dados sensíveis através de canais não-seguros.

7) Falha da especificação de requisitos – Deficiência que representa 8% das ocorrências. Os controles de segurança, que deveriam existir, não existem devido a falha na especificação.

8) Injeção de comandos – Técnica de ataque responsável por 8% das ocorrências e que explora injeção de comandos através de aplicação para serem processados por outros sistemas ou camadas. Por exemplo: SQL Injection, SMTP Injection, HTML Injection etc.

9) Processo inadequado de cadastro de usuários – Procedimento que causa 5% das ocorrências. O cadastro de usuário deve respeitar algumas recomendações de segurança, que se não forem seguidas podem expor a aplicação a diversos incidentes.

10) Quebra de autenticação e gerenciamento de sessão – Responsável por 5% das ocorrências, as aplicações vulneráveis permitem burlar o processo de autenticação através de gestão fraca de sessão ou procedimentos inseguros.

Autor: Ricardo Kiyoshi Batori