Archive

Posts Tagged ‘App Sec’

CQC: Matéria sobre o hacking no Brasil, entrevista com o LulzSec


Comentário:

Hoje, 05.07.2011, é possível ainda encontrar o arquivo ui.txt dentro do site da prefeitura de Corumbataí. O arquivo foi modificado (talvez por outro hacker) e agora contém a informação “porra Marcelo, jogou fora o relatorio do Esqueleto? larga essa bichice de Twilight e arruma logo essa merda”. O link para o arquivo é http://www.corumbatai.sp.gov.br/ui.txt.

Pelo que disse o integrante do LulzSec Brasil, dá a impressão de que eles querem fazer algo parecido com o que faz o WikiLeaks, divulgando informações que eles acreditam que deve ser do conhecimento da população. O problema é que isso está mais para vandalismo do que para protesto, já que nos sites onde eles não conseguiram entrar, eles tiraram do ar usando ataque de DDoS. Independentemente do que parece, é crime.

É sabido que os órgãos do governo não estão capacitados para tratar segurança da informação com a seriedade que o assunto necessita, no entanto acredito que o grupo poderia fazer como os pesquisadores de segurança fazem no mundo inteiro: descobrem a falha, alertam os responsáveis, combinam um período para que o problema seja resolvido e depois divulgam a falha ao público levando o crédito pela descoberta (e muitas vezes pela correção também).

Segurança da informação é construída com processos, ferramentas e pessoas. É necessário ter as ferramentas adequadas e pessoas capacitadas para usar essas ferramentas. Em muitos casos o maior problema é a ausência de um processo de gestão que periodicamente avalie as necessidades do negócio, identifique ameaças e vulnerabilidades e determine ações corretivas para o tratamento dos riscos identificados como não aceitáveis. No caso do governo, com a agilidade necessária para proteger as informações do governo (que envolvem segurança e soberania) e a privacidade dos cidadãos.

Atualização das 19h44: Agora ao tentar acessar o link, o servidor web retorna a mensagem: “You don’t have permission to access /ui.txt on this server.” O arquivo não está mais disponível. Fica a dúvida com relação à vulnerabilidade.

Declaração de IR 2011

Neste ano de 2011 a declaração do Imposto de Renda do Exercício de 2010 será exclusivamente entregue em formato eletrônico. Fica então algumas recomendações para aqueles que não estão habituados com a mordida online do Leão, que valem para todos que já faziam a declaração pela Internet:

  • Não faça ou envie a declaração a partir de terminais públicos, como Lan Houses e Cybercafés. Muitos computadores e redes possuem trojans ou outros mecanismos de captura de senhas e outras informações pessoais. Se você não possui um computador, faça a partir do trabalho ou do computador de um amigo. Isso já reduz o risco de vazamento de informações pessoais.
  • Para fazer o download, utilize o site da Receita Federal. Digite o endereço do site na barra de endereços do seu navegador, não clique em links de outros sites. O endereço é http://www.receita.fazenda.gov.br
  • A Receita Federal não envia e-mails. Não clique em qualquer link contido em um suposto e-mail da Receita. Ele é falso.
  • Utilize antivírus e mantenha o sistema operacional e o antivírus atualizados. É uma maneira simples e eficaz de reduzir o risco de código malicioso instalado na estação no momento em que você estiver digitando informações ou enviando para o site da Receita.
  • Não utilize software pirata. Muitos dos softwares piratas disponíveis na Internet ou na rua estão contaminados com trojans.
  • Grave em CD ou pendrive as declarações e recibos após o envio para a Receita.
  • Para reduzir ainda mais o risco, o usuário pode considerar obter um certificado digital da ICP-Brasil, conhecido como e-CPF. Através do certificado digital, é possível garantir o não-repúdio, ou seja, o usuário garante que foi ele mesmo quem enviou a declaração, eliminando a oportunidade de outra pessoa fazer o envio em seu nome.

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

25 . fevereiro . 2010 3 comentários

O SANS, o Mitre e alguns fabricantes de software de segurança nos EUA e Europa se juntaram e criaram uma relação com as 25 maiores vulnerabilidades de aplicações, assim como o OWASP compila a relação Top Ten de vulnerabilidades (também de aplicações).

Para ler a relação das 25 maiores vulnerabilidades (em inglês), clique aqui.

Comentário meu:

Os desenvolvedores não são os únicos culpados pelas vulnerabilidades existentes nos ativos de informação, mas com certeza tem grande responsabilidade, já que cada vez mais as empresas precisam desenvolver ou customizar suas aplicações web internas e externas, por exemplo. Para comprovar isso basta verificar o número de vagas abertas para programadores nas principais linguagens e bancos de dados usados hoje em dia. Além disso, como há uma tendência crescente de exibição de conteúdo dinâmico em portais e intranets, cada vez mais utiliza-se acesso a bancos de dados e a outros sites para relacionar as informações.

Um dos problemas dessa história é que alguns recrutadores vêem os desenvolvedores como commodities, como sacas de café, por exemplo. Se precisam que uma aplicação seja desenvolvida, vão nos sites de vagas de TI e contratam um, sem levar em consideração o conhecimento em segurança da informação e segurança no desenvolvimento de aplicações (principalmente nas linguagens e bancos de dados que serão usados). Quero dizer que, contratar um serviço personalizado como esse, levando em consideração as regras de negócio (ou necessidades do cliente), as linguagens de programação que serão utilizadas, as particularidades da infraestrutura existente e ainda as vulnerabilidades intrínsecas da comunicação na Internet, não é a mesma coisa que comprar bananas no supermercado. Por outro lado, as empresas investem pouco na capacitação de seus colaboradores, deixando a cargo do indivíduo se manter atualizado no que tange tecnologia e ainda, antenado em relação à segurança da informação, que para a maioria das pessoas é um mundo completamente novo.

O processo de desenvolvimento também está mal formatado em muitos lugares. Deixam para pensar em segurança em uma determinada etapa do projeto, quando muitas vezes já não é mais possível corrigir as vulnerabilidades encontradas, pois seria necessário desconstruir um trabalho de meses. Quando chega nesse nível de complicação, o software acaba indo para a “prateleira” com alguns bugs (leia-se vulnerabilidades) que serão corrigidas no projeto que criará a versão seguinte. Para reduzir esse risco, segurança da informação tem que acompanhar o desenvolvimento em todas as suas etapas.

Guias como esse e o do OWASP servem para preencher essa lacuna de conhecimento, divulgar as vulnerabilidades e permitir a criação de checklists para verificação de código-fonte. Vale a pena conferir ambos os trabalhos!

OWASP retorna ao Brasil em 2010

24 . fevereiro . 2010 Deixe um comentário

Após o sucesso da conferência de 2009, em Brasília, que contou com mais de 200 participantes, o OWASP AppSec Brasil está organizando um novo evento. A conferência deve acontecer ainda este ano em Campinas, SP.

O anúncio foi feito esse mês no blog do grupo e também foi anunciada a intenção de executar um evento maior ainda, o OWASP AppSec Latin America 2011. Membros poderão propor locais para o evento, que ainda não está definido.

Veja aqui o texto (em inglês) no blog do OWASP.

Relatório sobre segurança no Mac OS X

23 . fevereiro . 2010 Deixe um comentário

Depois de tudo o que já foi dito sobre a segurança do Mac, é bom ficar atento.

Veja o post do blog WebAppSec, do capítulo Portugal do OWASP:

Intego, uma empresa que comercializa um software chamado VirusBarrier, um dos melhores software anti-virus disponíveis para a plataforma Mac OS X (linha Mac e iPhone), disponibilizou o seu relatório anual de segurança em que fala das principais ameaças a que os dispositivos da marca da maçã estiveram sujeitos durante 2009.

Deste relatório é possível destacar o seguinte:

  1. Que as ameaças continua ainda a ser muito limitadas, embora se note uma tendência para que as mesmas cresçam;
  2. As principais ameaças resultam da instalação de software pirateado (iWork’09, Adobe CS4), ou resultam de fazer Jailbreak ao iPhone e instalar o OpenSSH;
  3. Que apesar de tudo, grande parte destas ameaças necessitam de uma colaboração total por parte dos utilizadores dos dispositivos;
  4. Apesar de tudo, começam já a existir software de segurança de qualidade que podem ajudar a detectar e corrigir estes mesmos problemas.

Apesar da plataforma Mac continuar a ser pouco visada pelos atacantes, a verdade é que esses mesmos ataques mostram uma tendência para crescer. Estes ataques parecem visar para já apenas software de terceiros, em que existe uma implantação mais alargada do mesmo, mas a verdadeira exposição poderá acontecer (se nada for feito) quando os ataques acontecerem ao nível do próprio sistema operativo.

O relatório pode ser visto diretamente no link http://blog.intego.com/images/yims2009.pdf.

Golpe: Componente de segurança BB

22 . fevereiro . 2010 Deixe um comentário

A dica é da Estela, leitora do Administrando Riscos.

O e-mail recebido contém apenas a imagem abaixo (clique nela para ampliar). Apesar de o remetente constar como sendo seguranca@bb.com.br, é fácil perceber o golpe. Quando colocamos o cursor do mouse em qualquer parte de imagem (não apenas no botão azul “Clique e saiba mais”), o navegador indica na parte inferior da janela o link para onde um clique com o botão esquerdo irá nos levar. Destaquei o link dentro da imagem, em vermelho. Além de ser um site da Alemanha (.de), o link termina com um arquivo executável (Componente_Seguranca.exe) que é uma das maiores características de trojans (programas maliciosos criados para roubar informações de usuários desavisados). Bancos não pedem para seus clientes baixarem e instalarem arquivos executáveis. Na dúvida, verifique com o banco através da Internet ou telefone. Os links no rodapé (parte azul escuro) da imagem sequer funcionam, já que tudo é uma imagem só, e não um e-mail com conteúdo HTML.

Para evitar esses golpes verifique com frequência o site do seu banco e fique atento aos alertas. Para acessar o site do banco nunca clique em qualquer link de e-mail ou de qualquer site na Internet. Sempre (eu disse SEMPRE) digite o endereço completo do site. Essa é a melhor maneira de evitar ser redirecionado para um site falso, que roubou a identidade visual do site do banco. Além disso, confira sempre o destino do link ou imagem na parte inferior do navegador, antes de clicar. Se você não for cliente do banco em questão, fica mais fácil ainda.

Detalhe: e-mails falsos costumam ter algum tipo de erro de digitação ou de ortografia mesmo. Nesse caso, o termo “Auto-Atendimento” aparece escrito dessa forma no fundo amarelo. Logo abaixo aparece escrito como “Auto atendimento”. Erros de escrita e formatação são outras características de sites e e-mail falsos, mas não as únicas. Portanto, mesmo que não haja nenhum erro, desconfie.

Seja invadido: use senhas de fácil dedução!

28 . janeiro . 2010 4 comentários

Recentemente estudei algumas centenas de senhas (de usuários) de aplicações usadas por alguns clientes e pude constatar que, de uma forma geral, o vazamento de informações e o acesso lógico não autorizado só não acontece se o hacker não quiser ou estiver muito ocupado para isso.

Leia mais…

%d blogueiros gostam disto: