Google não ajuda a descobrir senhas de blogs

A Juliana Barreto, da Info, divulgou que o Google ajuda a descobrir senhas de blogs, especificamente o WordPress. Outros meios de comunicação também divulgaram, mas mencionei a Info por ser um canal de renome quanto as informações de tecnologia (embora o MeioBit já tenha se tornado o canal mais influente e correto em minha opinião).

Tudo não passou de uma notícia divulgada apressadamente, sem uma apuração cuidadosa do fato. Levo em conta que uma jornalista que esteja trabalhando na Info conheça algo de tecnologia, ou pelo menos sabe onde procurar informações que dêem embasamento às suas informações e notícias. Tivemos, infelizmente, uma disseminação da insegurança àqueles que utilizam o wordpress.

O Élcio, preocupado com a falta de segurança noticiada, resolveu apurar e o resultado é muito diferente do divulgado. Convido-os a visitar o Blog Fecha Tag para ver o que ele escreveu (e também convido-os a acompanhar, pois há conteúdo de primeira qualidade). De qualquer forma, peço licença a ele para copiar aqui:

Para começar, leia o trecho a seguir desta notícia na INFO Online:

Mas, quando tentou o Google, o especialista descobriu que serviço de publicação de blogs WordPress é vulnerável a pesquisas específicas. O site armazena dados como hashes MD5, que podem conter senhas, de uma maneira visível ao buscador. Bastaria informar um trecho do algoritmo para encontrar dados relacionados ao usuário e suas senhas.

Uau, belo trabalho jornalístico esse hein? Espalhando o medo. Imagine a reação de um leigo, que tenha um um blog WordPress, ao ler essa pérola da desinformação. Não parece, lendo esse texto, que o WordPress tem uma seríssima falha de segurança que pode ser explorada usando o Google? Que se alguém "informa um trecho do algoritmo" vai descobrir uma porção de dados seus? Bom, fui ao site do sujeito e li o artigo em que ele explica como quebrou a senha.

O que aconteceu é que o WordPress do tal Murdoch foi invadido por um cracker, que criou uma conta de usuário. O WordPress guarda suas senhas em um formato chamado MD5, um formato de criptografia que transforma qualquer senha num hexadecimal de 32 caracteres, assim:

  • "Sylar" = 7bef5e9683a92c37a266283bf229c2e8
  • "Cap. Nascimento" = 40a4b69d3132bd562dc03e2de30fda3e
  • "Pat Morita" = 261f3880c4eab23075356dbc6b5befc3

O WordPress faz isso para proteger você. Se alguém invadir seu blog, mesmo assim não vai descobrir sua senha. Então o Murdoch não tinha a senha do sujeito que invadiu o blog dele, tinha apenas o texto "20f1aeb7819d7858684c898d1e98c1bb". O jeito comum de se descobrir essa senha é o chamado ataque de dicionário. Você consegue um enorme dicionário de palavras e nomes comuns, e faz um programa que converte cada um deles para MD5. Se, ao converter algum, você encontrar o tal texto "20f1…", pronto, você descobriu qual é a senha.

O problema é que esses ataques levam tempo, pois o computador tem que processar milhões de palavras. E se a senha não for uma palavra comum do dicionário, ela não vai ser encontrada. Assim, "banana" vai ser encontrada, mas "Xbanana43" não. Acontece que palavras muito, muito comuns, como "banana", ou nomes de pessoas, provavelmente já tem seu hash MD5 publicados em alguma página na web. E, se está publicado, o Google encontra. Por exemplo, procure pelo MD5 de banana.

Então, ao procurar o MD5 da senha do invasor, o Murdoch achou páginas como essa aqui, uma lista de pessoas chamadas "Anthony". Ele resolveu tentar então "Anthony" como senha, e funcionou.

Perceba que isso não torna o WordPress mais vulnerável, porque a senha ia ser descoberta de qualquer maneira, só ia levar um pouco mais de tempo. E para fazer isso, o sujeito tem que ter acesso ao banco de dados com as senhas. Ou seja, já tem que ter invadido o sistema.

Foi só isso. Não há nenhuma vulnerabilidade no WordPress que, se alguém vai ao Google e "informa um trecho do algoritmo", vai descobrir seu CPF e número de cartão de crédito. Aliás, será que esse repórter sabe o que significa "algoritmo"? Aprendi quando era criança, quando minha mãe ouviu meu primeiro palavrão, que gente não devia usar palavras que a gente não sabe o que significa.

Você que usa WordPress, não precisa se desesperar. Só não use senhas óbvias, não acredite em tudo o que você lê por aí e não entre em pânico.

Videos da Campanha Antispam.br

A CGI.br trabalhando por uma internet mais fácil. Excelentes vídeos, vale a pena assistir sejam profissionais ou leigos.

Estão disponíveis 2 vídeos da Campanha Antispam.br:

   * Navegar é Preciso -- trata do funcionamento da Internet, com suas vantagens, riscos e necessidade de proteção;
   * Os invasores -- apresenta os tipos de códigos maliciosos, seus efeitos e como eles podem entrar no computador do usuário.

Eles podem poder obtidos para download na seguinte URL:

* Vídeos Antispam.br
http://www.antispam.br/videos/

Os vídeos estão disponíveis na área de downloads do site Antispam.br e podem ser baixados em diferentes formatos, permitindo a sua visualização em diversos sistemas operacionais. Estes vídeos também possuem diferentes tamanhos e resoluções para download via conexão discada ou banda larga.

Outros dois vídeos serão divulgados futuramente: "Spam", aborda os tipos de spam existentes, suas diferenças e malefícios, incluindo códigos maliciosos e fraudes; e "A Defesa", cujo enfoque é o aspecto comportamental, enfatizando como usuário pode evitar a maioria das ameaças.

Atenciosamente,
--
CERT.br
https://listas.cert.br/mailman/listinfo/certbr-anuncios

Segurança no PHP

Os 6 requisitos mínimos

por Er Galvão Abbott (http://www.galvao.eti.br/) na revista PHPMagazine (http://www.phpmagazine.org.br/)

logo-phpmagazine

Apresentareremos neste artigo 6 requisitos que todo o desenvolvedor PHP deveria contemplar em sua aplicação. São boas práticas e hábitos simples que implementam um nível mínimo de segurança em qualquer sistema ou ferramenta desenvolvida com a linguagem.

A linguagem PHP é, sem dúvida, uma das mais populares quando o assunto é desenvolvimento de aplicações web. Existe, porém, um preconceito muito grande com a linguagem quando a questão é segurança. Neste artigo veremos 6 requisitos básicos que toda aplicação deveria possuir e que implementarão o mínimo de segurança em tudo o que você desenvolver.

Conceito: PHP é uma linguagem mais vulnerável do que as outras?

Atualmente impera no mercado de desenvolvimento um preconceito relacionado à segurança de aplicações PHP. A linguagem é freqüentemente alvo de duras críticas por parte da própria comunidade de desenvolvimento, e não é raro presenciarmos aplicações extremamente vulneráveis que, com toda a certeza, dão razão a essas críticas.

Este preconceito, totalmente equivocado, tem suas origens na extrema flexibilidade de configuração e uso da linguagem e no número cada vez maior de desenvolvedores inexperientes que começam sua carreira desenvolvendo aplicações PHP, ignorando questões básicas, seja por falta de conhecimento ou porque estão procurando agilizar sua produção pessoal.

Este artigo não é destinado apenas aos que estão começando. É surpreendente o número de desenvolvedores mais experientes que, por terem adquirido vícios, ainda ignoram as questões que apresentaremos aqui.

Requisito #1: Esqueça register_globals!

Register_globals é, sem dúvida alguma, a diretiva de configuração mais popular e polêmica já implementada no PHP. É popular entre os desenvolvedores por tornar o processo de programação muito mais ágil e prático. É polêmica porque retira tanto do programador quanto do interpretador da linguagem a responsabilidade em definir a origem das informações utilizadas pela aplicação.

Esta diretiva causou tantos problemas que começou a vir desabilitada por default a partir da versão 4.2.0 e será eliminada na versão 6. Por isso, se você ainda programa com register_globals ligada, está mais do que na hora de mudar.

Observe o seguinte exemplo de código:

$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$autenticado) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}

Este código verifica por uma variável booleana chamada $autenticado, que tipicamente viria de uma sessão aberta quando o usuário se autenticou em nossa aplicação ou mesmo de um cookie. Ao utilizarmos os recursos da register_globals, porém, não estamos dizendo ao interpretador PHP que este dado deve vir obrigatoriamente de uma destas duas fontes.

Sendo assim, o interpretador procurará por esta variável em diversas fontes (variável do servidore web, dados de formulário, cookie, arquivos enviados por upload, query string ou sessões) das quais ele obteve informações até encontrá-la, desprezando se esta fonte está correta.

Torna-se extremamente simples "enganar" a sua aplicação PHP, basta que eu chame o seu arquivo passando a variável esperada por query string.

http://www.meusite.com.br/script.php?autenticado=1

Ao receber a query string contendo a informação "autenticado", este dado será automaticamente interpretado como uma variável pelo interpretador, quer exista sessões ou cookies ou não.

Uma dúvida freqüente é "se não tenho autorização para desligar a register_globals o que eu posso fazer?". A resposta para isso é tão simples quanto tudo o mais na linguagem: programe como se ela estivesse desligada! Veja como fica o nosso código ao não utilizar a register_globals:

$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$_SESSSION['autenticado']) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}

Observe a mudança: ao utilizarmos o array super global $_SESSION, estamos explicitando para o interpretador que a informação "autenticado" tem que, obrigatoriamente, vir de uma sessão. Isto significa que será impossível para o interpretador confundir este dado com um dado enviado pela query string, pois este fica armazenado em um array super global diferente:

  • $_SERVER - Informações definidas pelo servidor web (Apache, IIS etc)
  • $_GET - Informações passadas por query string ou por um formulário web utilizando o método GET
  • $_POST - Informações enviadas, tipicamente, por um formulário web utilizando o método POST
  • $_COOKIE - Informações fornecidas por um cookie HTTP
  • $_FILES - Informações fornecidas por arquivos que foram enviados via upload HTTP
  • $_ENV - Informações fornecidas pelo ambiente do servidor
  • $_REQUEST* - Informações fornecidas por GET, POST ou COOKIE

* Cuidado: O uso do array super global $_REQUEST é quase tão perigoso quanto a register_globals em si, pois nesse caso a informação pode vir de qualquer um dos 3 métodos: GET, POST ou COOKIE.

Requisito #2: Use require e não include

O comando include e seus derivados - como include_once - são freqüentemente usados em detrimento do comando require. Este fato curioso a princípio é conseqüência da similaridade do comando include com outras linguagens, como C e Java.

O que muita gente não sabe, porém, é que este comando carrega consigo um risco muito grande para sua aplicação: se por algum motivo a inclusão do arquivo falhar - erro de digitação, disco corrompido etc - será gerado um erro de nível warning, um nível leve de erro que não causa a parada da execução do script.

Utilizando o comando require, garantimos que, no caso de falha na carga do arquivo, seja gerado, além do erro de nível warning, um erro de nível fatal. Em bom português isso significa que a execução do seu script será imediatamente interrompida neste caso. Por que é bom que seu script seja interrompido no caso de falha de inclusão de outro arquivo? Simples: no caso de falhas, as variáveis, as funções, as constantes e o que mais este arquivo carregava consigo, simplesmente, não estarão disponíveis.

Requisito #3: Filtre a entrada de dados!

Um dos principais conceitos de segurança é a filtragem dos dados que são recebidos antes de utilizá-los. A falta de fitlragem é a causa de inúmeros problemas de segurança, incluindo o infame SQL Injection, ou Injeção de SQL. Observe o seguinte código:

require_once("conecta.php");
$conn = conecta();
$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
mysql_close();

O problema deste código é utilizar um dado informado pela query string (uid) sem fazer nenhuma filtragem, ou seja, nosso script aceitará cegamente qualquer coisa que for digitada como valor de uid. Observe a seguinte URL:

http://www.meusite.com.br/script.php?uid=198%20OR%20'x'='x'

Após a conversão dos caracteres especiais desta URL, o valor de uid será (sem aspas duplas): "198 or 'x'='x'". Note que, quando concatenarmos isto à nossa query, ela terá sofrido uma grande modificação:

SELECT email FROM usuarios WHERE usuario_id = 198 or 'x'='x'

É por isso que a chamamos de "Injeção de SQL". A parte em vermelho acima é formada de SQL válido, mas completamente alienígena à nossa plicação: ele modifica o comportamento original da query.

Observe que, com um mínimo de esforço, um usuário conseguiu expor todos os e-mails cadastrados em nossa base de dados: como foi utilizado o operador "OR" e a segunda condição ('x'='x') é sempre verdadeira, serão exibidos todos os registros.

Para evitarmos este tipo de problema, devemos aplicar um tratamento à informação antes de utilizá-la. Caso a minha query - como neste exemplo - esteja esperando um número inteiro, a solução é simples: forçamos a conversão do dado recebido para número inteiro:

require_once("conecta.php");
$conn = conecta();

settype($_GET['uid'], integer);

$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
mysql_close();

A partir de agora, qualquer dado enviado pela query string será primeiro convertido para inteiro e somente depois desta conversão é que o utilizaremos. No caso de uma tentativa de Injeção de SQL, nosso script considerará apenas a parte numérica (198), como deveria ser. Além disso, se por um acaso nosso script receber apenas texto, a função settype converterá isto para o número 0.

Caso a minha query esteja esperando uma string a solução reside em criar um tratamento que valide esta string. Vejamos um exemplo: possuo uma query que busca dados de um usuário através de seu endereço de e-mail:

$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . "'";

Sabemos que um endereço de e-mail é formado por um nome de usuário, uma arroba e um domínio. Para fins de simplificação do exemplo, trabalharemos como se o usuário só pudesse usar letras, números e o caracterese de ponto - para quem levar a validação de e-mail a sério consulte a RFC 822. Podemos representar isso através de uma expressão regular:

/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/

Sendo assim, só aceitaremos o dado de endereço de e-mail se ele estiver dentro dos padrões de minha expressão regular. Nosso código então ficaria assim:

require_once("conecta.php");
if (preg_match('
/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/', $_GET['email'])) {
$conn = conecta();

$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . "'";
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
} else {
die("O dado informado não é um endereço de e-mail válido.");
}
mysql_close();

Livro da Cartilha de Seguranca para Internet

A Cartilha de Segurança para Internet é um documento com recomendações e dicas sobre como o usuário de Internet pode aumentar a sua segurança e se proteger de possíveis ameaças.Publicada esta semana, a versão 3.1 da Cartilha de Segurança para Internet passou a ser editada também como livro, disponível gratuitamente em http://cartilha.cert.br/livro/. Esta versão também incluiu correções de erros de digitação, atualização de URLs de referência e de exemplos nas seções sobre senhas e sobre adware.

Este documento foi produzido pelo Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil - CERT.br, com o apoio do Comitê Gestor da Internet no Brasil - CGI.br.