Olá, pessoal. Nesta coluna vou apresentar uma técnica de recuperação da senha do banco de dados que tive que utilizar quando ninguém mais lembrava a senha que o sistema utilizava. A idéia é apresentar uma técnica que não invalide a senha, não faça uso de técnicas de força bruta e que possa ser utilizada sem a modificação de código fonte da aplicação.

Antes de começar a explicar a técnica utilizada vou apresentar o contexto no qual tive que aplicá-la. Há algum tempo prestei uma consultoria de banco de dados em uma empresa onde vários sistemas utilizam diversos bancos de dados de um mesmo servidor.

Com o passar do tempo o servidor começou a ficar sobrecarregado. Coube a mim então conduzir a tarefa de migração de todos os bancos de dados para um servidor mais potente. Durante o levantamento dos objetos que precisavam ser transferidos e de qual sistema utilizava qual banco de dados, me deparei com um sistema que poucas pessoas conheciam. Este dito-cujo era utilizado por alguns usuários e funcionava da seguinte maneira: cada usuário tinha seu login e senha para entrar no sistema. Uma vez que os usuários estivessem logados, eles poderiam fazer seu trabalho. O sistema funcionava sem problemas nesta configuração.

Porém, analisando com cuidado, descobri que o sistema utilizava apenas uma conta de usuário para se conectar no SQL Server no modo de autenticação misto, aquele onde é preciso fornecer um usuário e a senha. Até aí tudo bem, o que eu precisava fazer era mover a base e também o login do SQL Server que o sistema utilizava para se conectar. O problema é que ninguém conhecida a senha do login que o sistema utilizava para se conectar na base e, obviamente, o SQL Server criptografa todas as senha armazenadas.

Após conversar com algumas pessoas, descobri que este sistema foi comprado há um bom tempo por um gerente que não trabalhava mais na empresa. Infelizmente este gerente era o único que sabia a senha do login utilizado pelo sistema para se conectar com o SQL Server. Como o gerente saiu da emprega de forma não amigável, eu fiquei com poucas alternativas.

Procurei estudar o sistema para ver se conseguiria mudar o login ou a senha que ele utilizava para se conectar à base. Porém o máximo que consegui foi encontrar um arquivo de configuração que continha o endereço IP do servidor, o login e a senha. Detalhe: apenas a senha estava criptografada. O que fazer? Se eu mudasse o login não saberia como colocar a senha criptografada. Se eu deixasse a senha sem ser preenchida no arquivo de configuração, o sistema não funcionava. Até tentei entrar em contato com o pessoal da empresa que fez o sistema, mas a senha padrão que eles me forneceram não funcionou.

Sem muita perspectiva tive que improvisar e tentar alguma técnica para descobrir a senha, pois além da migração eu queria deixar a documentação do servidor correta com todos os logins e senhas em um documento restrito. Ao invés de tentar algum ataque de força bruta ou tentar descompilar de aplicação, eu decidi descobrir a senha do login que estava sendo utilizado por meio de uma técnica que envolvia o redirecionamento de conexões. Para facilitar o entendimento do cenário, a Figura 1 mostra como uma estação cujo endereço IP era 192.168.1.10 se conectava diretamente ao servidor de banco de dados 192.168.1.50 na porta TCP 1433, que é o padrão do SQL Server. Este era o cenário de utilização do sistema antes que eu colocasse em prática a minha idéia para descobrir a senha.

Figura 1. Cenário antes da aplicação do redirecionamento.

A idéia era a seguinte: ao invés das estações se conectarem diretamente ao servidor SQL Server, eu colocaria uma outra estação para redirecionar o tráfego entre o cliente e o servidor. Eu poderia fazer isso modificando apenas o endereço IP do servidor no arquivo de configuração do sistema, pois apenas a senha era criptografada. Esta estação que redirecionaria a conexão seria completamente transparente tanto para o banco de dados como para o sistema, ou seja, não haveria nenhuma mudança de comportamento da aplicação pois apenas o endereço IP do servidor seria modificado. O cenário após a aplicação do redirecionamento ficou como a Figura 2 mostra.

Figura 2. Novo cenário após o mapeamento de conexões.

Antes do mapeamento, o arquivo de configuração da estação cliente indicava que o servidor de conexão era 192.168.1.50. Depois do mapeamento o endereço IP do servidor foi 192.168.1.25, o servidor que faria o mapeamento de porta. Este mapeamento manteve o número da porta padrão do SQL Server, 1433, igual. Isso quer dizer que todas as conexões que chegassem à estação 192.168.1.25 na porta 1433 eram automaticamente redirecionadas para o servidor 192.168.1.50 na porta 1433.

A propósito, este mapeamento foi feito utilizando uma ferramenta gratuita chamada PortTunnel, que já foi comentada aqui em uma coluna minha chamada “Ferramentas de Rede para o DBA”, disponível aqui. Acessando a coluna é possível fazer o download da ferramenta PortTunnel.

Bom, o redirecionamento de portas funcionou sem problemas. Mas qual é a vantagem deste redirecionamento? A vantagem é que o PorTunnel permite gravar em um arquivo texto separado todos os bytes que “entram” e que “saem”, ou seja, ela faz um log completo de todos os dados que passam pelas portas mapeadas.

Analisando todos os dados, pude ver tudo que é enviado do sistema para o banco de dados e vice versa. E advinhem só? Nada é criptografado! Pois é, os dados são trafegados sem nenhum tipo de embaralhamento. Apesar disso, a Microsoft disponibiliza técnicas para a criptografia de informações, porém em 99% das aplicações e ambientes de bancos de dados em que já trabalhei não vi ninguém utilizando esta opção de criptografia. E você, leitor, criptografa os dados que trafegam entre a sua aplicação e o seu banco de dados, seja ele qual for? Aguardo respostas nos comentários…

Voltado ao assunto, eu analisei os dados e não entendi onde ficavam as informações de login. Porém sabia que o SQL Server utilizava o protocolo TDS e que este protocolo tem a especificação livre. Com base no código fonte da biblioteca de código livre FreeTDS, disponível para o Linux e já comentado nesta coluna anteriormente, montei rapidamente um programa em C que lia os dados de acordo com o protocolo e facilmente descobri a senha do login sem utilizar força bruta, descompilar a aplicação ou mesmo invalidar a senha.

O que fiz em seguida foi voltar ao SQL Server e testar a senha do login utilizado no sistema, que acertei em cheio. O próximo passo foi copiar a base e recriar o login no novo servidor, finalizando a tarefa com a mudança do endereço IP no arquivo de configuração do sistema.

Esta técnica que apresentei pode ser reutilizada em outros contextos, desde que possamos trocar o endereço IP no cliente temporariamente. É preciso também saber se os dados são criptografados e se há como saber como funciona o protocolo. Caso positivo, é necessário um pouco de programação para tentar fazer o parser dos dados e descobrir onde está a senha dentro do que foi enviado ao servidor.

Outro detalhe que talvez possa tornar esta técnica mais fácil é a utilização de um sniffer de rede. Não tenho muita experiência com este tipo de ferramenta, mas é possível que ele capture de alguma forma os dados trafegados entre os clientes e o servidor.

É isso aí, pessoal, um grande abraço e até a próxima.