FISL11: Segurança Cripto Caixa

Nessa palestra foi apresentado o case da CEF em relação ao uso de criptografia sendo implementado dentro da empresa, principalmente em notebooks. É uma solução baseada no TrueCrypt, que ganhou uma certa fama depois do caso do banqueiro Daniel Dantas, onde nem o FBI conseguiu quebrar a criptografia dos HDs sendo investigados.

A grande questão em adotar essa solução foi pela necessidade da empresa ter controle sobre as informações de seus funcionários. Uma solução convencional, corre o risco do usuário esquecer a senha depois de algum tempo, ou até mesmo acarretar sérios problemas para a instituição, no caso de algum processo judicial exigir que essas informações sejam auditadas ou apresentadas a um juiz.

No caso da CEF, a solução é composta de servidores que armazenam a chave e são repassadas aos usuários (caso seja necessário), por meio do CPF do funcionário e de seu certificado digital. Devido essa solução alterar o cabeçalho do arquivo de criptografia, ele  a torna incompatível com o TrueCryp original.

Não sei se essa alternativa adotada pela Caixa é a melhor, mas é certo que com a disseminação do uso de notebooks e discos rígidos externos, devemos buscar uma opção mais robusta para a segurança dos dados. É temeroso pensar que a maioria das pessoas não se preocupam com isso. Talvez daqui algum tempo tenhamos notícias de sérias implicações em relação a isso, e já estou considerando isso tão importante quanto manter um backup atualizado e funcional.

Eu já uso criptografia em minha pasta /home do meu notebook a muito tempo, mas é fato que a maioria das pessoas não tem nenhum cuidado com suas informações. De qualquer forma, o grande problema é que as empresas tem que ter o direito a acessar as informações nos equipamentos dos seus funcionários e creio ser louvável essa tentativa que a CEF está realizando de implementar isso.

Vulnerabilidades XSS: A Saga Continua…

Ainda bestificado com as Lojas Ame… sofrendo de cross site scripting e principalmente de ver uma das minhas caixas postais com o “famoso” e-mail citado no FISL 9 (ainda bem que eu assisti a palestra antes, pois talvez eu fosse um atingido agora – quero dizer, isso se o programa que o e-mail tentou instalar em minha máquina rodasse no Linux, né), decidi procurar um pouco mais sobre o assunto.

Não foi muito difícil encontrar uma site que lista páginas com falha de XSS. E as Lojas Ame. está listada lá desde fevereiro de 2007. Junto com ela, tem mais algumas lojas famosas, como Sub., Sarai… Muitas. Até meu banco está listado. E tem mais alguns outros bancos também.

Mas não são todos. Tem muitos sites famosos que parecem não ter este tipo de vunerabilidade (ou pelo menos não estão listados).

Eu creio que ninguém é perfeito, todos podemos cometer erros, agora não corrigir uma falha e fazer pouco caso disso, só porque é algo client-site é muita falta de consideração destas grandes empresas.

No fim, eu creio (pelo menos no caso das grandes lojas), que a falha está tão difundida devido a todas elas usarem um mesmo sistema (até pq todas elas tem a mesma cara, já notaram isso?), que provavelmente deve ser tercerizado por uma empresa que não se preocupa muito com segurança.

Eu já estou avisando todas as pessoas conhecidas para nunca mais confiar em e-mails destas lojas. Nunca mais eu clico em link do tipo “oferta só via este e-mail”. Agora eu só compro direto pelo site. Até vou ver as ofertas via e-mail, mas não clico mais em comprar. Na verdade, estou pensando até em radicalizar e abolir o e-mail da minha vida! Será que resolve? 😛

Bah, fico pensando nas pessoas que eu dizia “pode comprar pela Internet, não é tão inseguro assim como dizem, se for de lojas de renome”. Acho que vou dizer para elas agora: “lembra quando eu disse que não era tão inseguro? Pois é… É pior do que dizem”!

---

Estava pensando em algo para solucionar isso, haja visto que estas empresas nem se preocupam com nós usuários. Bem que podiam inventar uma extensão para o Firefox que alerte o usuário quando ele entrar em um site que sofre de vulnerabilidades tão banais assim. Quem sabe esta “gente” criasse vergonha na cara com isso.

FISL: Drupal

Confesso que foi com muita desconfiança que fui conferir a palestra do CMS Dupral do dia 19/04. Como envolvia um partido político, fiquei com receio de ser algum tipo de palestra-propaganda, mas não foi o caso.

Não foi uma palestra do tipo “técnica”, mas foi interessante para ter uma noção do que é o Dupral. Eu já estou algum tempo tendo que avaliar um CMS e inclusive já pediram para desenvolver um, mas não gosto de ficar reinventando as coisas.

Neste link, é possível ver um post do blog de um dos palestrantes e inclusive tem um link para o PDF da apresentação do fórum.

Me pareceu um CMS bastante robusto e simples de implementar, e pretendo usá-lo, pelo menos em teste, brevemente.

Uma pergunta interessante que foi feita após a palestra é relativa a segurança. Uma pessoa levantou a hipótese de que se soubermos o código fonte do Drupal, principalmente em relação ao esquema do banco de dados (que por padrão é em MySQL), isso poderia facilitar ataques, como por exemplo, de SQL Injection.

Os palestrantes, com ajuda da Chuva Inc. deu uma resposta bastante aceitável: conhecer o código fonte e a estrutura do banco de dados, não significa que vai se conseguir invadir ou roubar os dados, pois o próprio CMS implementa vários mecanismos de segurança. Como complemento ao que eles disseram, vale seguir as dicas do que foi mostrado na palestra sobre segurança no PostgreSQL (aplicável, também, ao MySQL).

Por fim, vale citar o link da comunidade Dupral Brasil. Fica a reclamação que os palestrantes não divulgaram o valor cobrado para implementar a solução, hehehe

FISL: Primeiras palestras do último dia

As duas primeiras palestras do dia 19/04 foram sobre vulnerabilidades de aplicações na web.

A primeira foi apresentada pelo grupo OWASP-BR, uma entidade que se preocupa em melhorar a segurança de aplicativos web. Em seguida, assisti uma palestra de Er Galvão Abbott sobre métodos para evitar cross-site-scripting.

O grupo OWASP-BR apresentou as 10 vulnerabilidades mais críticas encontradas em aplicações WEB, sendo que as mais críticas, em ordem, são:

• Cross Site Scripting (XSS), que consiste em rodar código script malicioso no navegador web do cliente;
• SQL Injection, que em geral se inicia forçando um erro na página, para que o cracker consiga determinar mais informações sobre o SGDB. Depois o cracker injeta código SQL, a fim de ter acesso não autorizado de informações;
• Execução maliciosa de arquivos, que ocorre em sistema que aceitam arquivos de usuários remotos. Em geral, o cracker com acesso ao sistema envia uma página ou arquivo preparado, que depois é executado dentro do sistema web, podendo causar sérios danos ao sistema;
• Referência insegura direta a objetos, onde o desenvolvedor expõe de forma direta informações internas que não deveriam aparecer, como por exemplo, diretórios, nome de arquivos, ID de usuários, etc, por meio de URL ou parâmetros de formulário.

Estas vunerabilidades correspondem a cerca de 70%. Este documento informa as outras vunerabilidades e dá mais detalhes sobre o assunto.

Sobre a palestra do Er. Galvão Abbott, uma curiosidade é que ele havia recebido um link de uma grande empresa com ataque XSS no e-mail. Ele, que é um usuário experiente, quase foi enganado pelo ataque, dada a sofisticação do mesmo. No slide, ele mostra o código mas protege e não divulga qual seria esta empresa. Perguntei para o “santo Google” e ele me respondeu: Lojas Ame…!!! Cheat!!!

Pior, a vunerabilidade não foi resolvida até agora! Isso é muito triste. Pelo que eu percebo, não dá mais para confiar nem quando o site tem SSL, está com o link correto, etc. Eu creio que ninguém está livre de falhas, mas não resolve-las é extremamente grave.

Fica uma das mensagem dele na palestra: Não se deve dar crédito excessivo à uma aplicação, e relaxar em cuidados com segurança, porque ela foi desenvolvida em linguagem x, foi desenvolvida pela empresa y, pertence a empresa z, ou está utilizando o sistema operacional xyz… E sempre procurar aplicar segurança concentrando no que deve ser permitido e não no que deve ser proibido, pois por melhor que seja o desenvolvedor, jamais ele irá prever todas as possibilidades de falha de segurança.

Ah, fazia algum tempo que eu não comprava mais nas Lojas Ame…, creio que vou continuar não comprando, hehehehe (ainda bem que recebi o brinde que o Terra me prometeu, quando eles mandaram um e-mail em massa solicitando atualização de dados, porque senão eu estaria seriamente preocupado agora, hehehe – bom, um cracker não mandaria um brinde real, né? vixe…)

---

Seguindo conselhos resolvi remover o nome da empresa, mas não fica difícil adivinhar quem é.

FISL 9: Dia do PostgreSQL!!!

Depois do primeiro dia de FISL, daria para “apelidar” hoje como o dia do PostgreSQL. Amanhã, ainda, terá pelo menos mais uma palestra sobre replicação de dados, mas somente hoje eu participei de 4 palestras sobre este SGDB.

---

Logo cedo, assisti a palestra sobre replicação de dados, onde foram abordados conceitos como replicação síncrona e assíncrona e que às vezes uma solução mais simples pode ser a mais indicada. O palestrante usou uma analogia com vários tipos de carros de velocidade, passando por carros que desenvolviam mais de 400Km/h mas que só andavam em linha reta, sem muito controle, passando por fusca, que chega a 120Km/h por hora com algum esforço, mas anda para todos os lados e pode ser usado na cidade, até chegar no carrinho de rolimã, que não tem motor, mas em compensação tem custo quase zero de manutenção.
Mostrou várias ferramentas para replicação, sendo que eu destacaria o skytools da Skype, uma solução de replicação síncrona com centenas de servidores rodando em ambiente de produção, soluções mais clichês, como o Slony (que usa triggers para replicações assíncronas, mais indicado para replicação de tabelas), Warm-Standby (baseado em log), que aparentemente seria algo similar ao sistema de replicação do MySQL, mas que precisa que o slave fique em modo de espera, sem poder ser usado.
Fiquei surpreso com a afirmação de que pg_cluster é extremamente instável com base de dados grande (ele citou ser impossível em usar em uma base de dados de mais de 10GB, porque simplesmente o SGBD pára de funcionar com ele). Pensava em adotar esta solução em um projeto.

Depois, teve uma palestra muito interessante sobre segurança de dados no PostgreSQL. O palestrante, usou a frase “Safe Data Is Happy Data” (Dado seguro é dados feliz) como referência em toda a apresentação.

Basicamente, ele falou que a maioria das soluções de sistemas de banco de dados não se preocupavam com a segurança do lado de dentro do firewall, apenas definindo políticas de segurança no roteador, servidor web, etc. Esta despreocupação com a segurança interna é uma das principais causas de “dado infeliz”. Ele citou, que cerca de 2/3 das invasões são internas, com roubo de dados por funcionários, etc.

Para ter uma base de dados realmente segura, é necessário várias ações, entre elas, definir corretamente uma política de acesso de senhas no arquivo pg_hda.conf (por exemplo, usando ident apenas para usuários tipo administradores logados em rede local e segura e md5 para usuários web com conexão ssl, etc.).

Outra atitude a ser adotada é definir corretamente os direitos de acesso as tabelas. Por exemplo, definir usuários web com acesso apenas de select e os usuários da sua rede interna com acesso total, bem como definir acesso apenas as tabelas necessárias para cada grupo.

Infelizmente não lembro mais de todas as práticas de segurança que foram sugeridas, mas tem uma que achei muito interessante, que nem sempre é utilizada, que se trata da auditoria do sistema. Eventualmente, pessoas mal intencionadas com acesso ao sistema ou a base de dados podem roubar informações ou alterar dados por má fé ou até mesmo erro. A auditoria ajuda a detectar estes problemas e até mesmo corrigir, voltando ao estado anterior. Para isso, é essencial usar triggers e definir corretamente o acesso as tabelas de auditoria, para que um invasor não consiga comprometer esta auditoria, também.

Em seguida, teve uma palestra sobre “Postgres Application Server” (aliás, a palestra poderia ser chamada de Perl no PostgreSQL, hehehe), que seria basicamente mover parte da aplicação para o SGDB, como por exemplo, validação de dados, uso de store procedures para processamentos em lote, etc.

Podem ser usadas várias linguagens para a implementação, sendo que o palestrante citou o pl/sql que seria uma linguagem segura e que não precisa de nada, pois é como se fosse um “default” do PostgreSQL e linguagens ditas “inseguras”, as quais poderiam fazer um bom estrago na base de dados ou no sistema (se forem mal utilizadas), pois implementam acesso a disco, etc. Entre estas linguagens, o palestrante deu destaque para a Lua e o Perl, mas também poderia ser usado PHP, C, etc.

Destaque para a implementação de um domain email (tipo de dado), validado via Perl, com poucas linhas (graças ao uso do CPAN).

A última palestra de PostgreSQL do dia foi sobre boas práticas em desenvolvimento em banco de dados. Foi a palestra mais genérica sobre PostgreSQL, mas certamente foi a mais interessante. Para quem tiver interesse, dá para conferir o pdf dos slides da palestra, aqui (foi alterado um pouco para o FISL, pelo que eu pude ver, mas a idéia original da mensagem continua a mesma).
As partes que eu acredito que valem a pena destacar, são:

1. Uma pessoa sem bom senso não se preocupa com melhores práticas;
2. Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas;
3. Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas.

A maioria dos desenvolvedores devem procurar se enquadrar no segundo item e apenas quando tiverem muita “estrada” e muitas “melecas” (como o palestrante gostava de dizer) feitas é que pode pensar em ir para o terceiro grupo de pessoas.

Além disso, vale a pena citar uma frase de Eric Raimond: “Estrutura de dados inteligente e código burro trabalham muito melhor do que o contrário”, ou seja, se a estrutura de dados for mal definida, nada salva o projeto, nem programadores fenomenais. Tudo parte de uma boa definição da modelagem dos dados. Nos slides tem várias dicas boas para se conseguir isso. Vale a pena conferir.

Incrementando o POSTFIX

Assisti a palestra sobre Access Policy Delegation do Miguel Filho. Muito boa. Isso até não é algo que me interessa muito. Tenho lá meu Postfix rodando numa boa, fazendo o “feijão-com-arroz”, sem grandes necessidades.

Mas valeu para ver que quando algo é bem feito, as coisas ficam muito simples de serem estendidas e melhoradas. É muito fácil criar um programa para controlar isso no Postfix e estender as funcionalidades dele. O Miguel fez um exemplo até em schell script para demonstra a facilidade disso. Greylists fica muito fácil de ser feito assim.

Sendmail/qmail nunca mais eu quero isso em minha vida, hehehe

Além disso, a performance é muito boa. Como ele disse, o segredo de tudo, está em processar isso antes do seu antívirus e antispam (se você tiver isso em seu MTA), e já eliminar na hora o que não deve passar à frente, para os outros filtros.

Ele implementou uma solução completa para estender o controle sobre o Postfix usando o Python, que usa um arquivo de configuração com sintaxe muito similar ao squid, para facilitar a curva de aprendizado.

O projeto dele está listado no site do postfix e pode ser encontrado neste endereço.

Que horror!!! Quem salva meu DNS?

Assisti a palestra sobre DNSSEC do Frederico Neves e voltei apavorado!

Eu sempre soube que na implementação da Internet, houve muitas falhas de definição em termos de segurança, principalmente porque não se imaginava que haveria tantas pessoas mal-intencionadas como existem agora. Mas de certa forma, o que fez a Internet ser tão popular, foi a simplicidade toda que envolve ela.

Pergunta: Será que ela teria aceitação mundial tão fácil, se fosse muito complicada de implementar seus protocolos?

Um dos tipo de falha muito comentadas atualmente é os ataque de Pishing. São graves, porque tentam roubar informações confidenciais, principalmente roubo de dados financeiros, como número de cartão de crédito e roubo de senha de acesso a home/office banking. Mas sempre tive a ilusão que um ataque destes não seria tão simples, que implicaria em falha do usuário em algum nível, etc.

A algum tempo atrás, me dei conta que tinha muita gente usando qualquer DNS que funcionasse bem, em suas configurações de rede. Fiquei “pasmo” quando vi que tinha um cliente que configurou um endereço de servidor DNS, sabe-se de lá de onde, em todas as suas máquinas. Imagina se este endereço é comprometido ou mesmo é de algum cracker? Bah…

Mas tudo bem, eu pensei: “se tivessem roubado dados, a culpa era de quem tinha tido a incrível idéia de usar um servidor dns rápido sabe-se-lá-de-onde”…

Mas a palestra do Frederico destruiu minha ilusão de “segurança”. Nunca imaginei que poderia ser tão simples burlar uma requisição DNS.

Resumidamente, a resolução de nome é composta por um cliente, um servidor recursivo (que em geral é o servidor DNS que você informa nas suas configurações de rede) e um ou mais autoritativos. Pois bem, toda esta comunicação para resolução de nomes, em geral é feita por UDP, que é muito fácil de falsificar. Então, se um cracker fizer um sniffer na rede, e “descobrir” uma requisição DNS e responder antes do servidor autoritativo ou recursivo, ele simplesmente consegue realizar ataques de comprometimento de cache, por exemplo, e “mentir” o endereço IP de um nome. Isso porque no protocolo DNS, o que vale é a primeira requisição que chegar até o servidor, ou seja, se um cracker conseguir ser mais rápido que um servidor recursivo ou autoritativo ele consegue fazer um phishing praticamente perfeito.

Neste caso, a única coisa que poderia garantir a autenticidade de um servidor é o https (mas até quando?).

Segundo o palestrante, a coisa é tão grave que as grandes instituições financeiras pagam empresas para ficarem verificando a rede, para certificar que não existem crackers tentando se utilizar destas técnicas contra elas.

Para solucionar estes problemas de falta de segurança no protocolo, foi criado o DNSSEC. No Brasil, ele já foi implementado em quase todos os domínios, com excessão de 2… O .com.br e o .org.br, ou seja, os mais importantes. Isso porque estes domínios são muito grandes e porque eles não provem segurança total (não garantem proteção contra DOS e confidencialidade dos dados). A terceira implementação promete resolver estes problemas e já pode ser usada em teste, com o domínio SEC3.BR. O registro nesta categoria é gratuita enquanto estiver em fase beta. Depois, será descontinuada.

Mais informações sobre o DNSSEC pode serem encontradas neste link de tutorial em PDF.