Um estudo de caso na vulnerabilidade de segurança de banco de dados

Neste estudo de caso, Chip Andrews, um especialista em segurança do SQL Server, compartilhou essa experiência de (eticamente) invadir um banco de dados de clientes para descobrir falhas de segurança. Este exemplo fornece um conto preventivo para proteger sua informação importante ao insistir na segurança de banco de dados de som.

A situação

Durante um teste de penetração de rotina, o Sr. Andrews realizadas as pesquisas obrigatórias Google, pesquisa de nome de domínio, fingerprinting sistema operacional, e varreduras de portas, mas este determinado site foi bloqueado apertado. Passando para o aplicativo baseado na web em execução no sistema, ele foi imediatamente confrontado com uma página de login usando a autenticação de formulários criptografados por SSL.

Ao verificar o código fonte da página web, ele notou que um oculto Nome do aplicativo campo foi sendo passado para a aplicação sempre que um utilizador tentou log in para o local. Será que os desenvolvedores pode ter falhado para executar a validação de entrada adequada sobre este parâmetro de aparência inocente? A caçada começou.

O resultado

Primeiro, era hora de montar o kit de ferramentas. Na altura deste teste de penetração, Andrews preferido utilizar o seguinte: Paros proxy, absinto, Cain & Abel, Ladrão dos dados, eo SQL Server Microsoft SQL Server Management Studio / (Express Edition), todos os quais estão disponíveis gratuitamente.

Para começar, ele usou Paros Proxy para permitir mais controle e visibilidade aos pedidos web feitas ao servidor web.

Depois de spidering o site para páginas disponíveis e realizando uma verificação de vulnerabilidade rápida para injeção de SQL, foi confirmado que o Nome do aplicativo parâmetro apareceu para causar o aplicativo para lançar uma exceção de erro 500, indicando uma falha de aplicativo. testes de penetração são uma das raras ocasiões em que uma falha de aplicativo é um resultado desejável.

Porque a falha da aplicação indicou que o Sr. Andrews pode injetar caracteres não intencionais no código SQL sendo enviadas a partir do aplicativo de banco de dados, ele poderia ver se ele foi uma condição de vulnerabilidade.

Um teste comum que trabalha com bancos de dados Microsoft SQL Server é injetar um comando, como WAITFOR DELAY `00: 00: 10’, que faz com que o servidor de banco de dados para parar por 10 segundos. Em um aplicativo que normalmente retorna uma página em um segundo ou menos, um atraso consistente de 10 segundos é um bom indicador de que você pode injetar comandos no fluxo de SQL.

Em seguida, o Sr. Andrews tentou usar a ferramenta Ladrão dos dados para atacar a página de login. Esta ferramenta tenta forçar o banco de dados para usar um OPENROWSET comando para copiar os dados do banco de dados alvo a base de dados do Sr. Andrews localizado na Internet.

Isso geralmente é uma maneira muito eficiente de sifão grandes quantidades de dados de bancos de dados vulneráveis, mas neste caso, o ataque foi frustrado! O administrador de banco de dados para o alvo tinha desativado o OPENROWSET funcionalidade, configurando corretamente a opção Disable Adhoc consultas distribuídas.

Com diligência como a sua palavra de ordem, o Sr. Andrews persistiu com a próxima ferramenta - o absinto. Esta ferramenta usa uma técnica chamada injeção SQL blind para fazer determinações sobre dados usando simples sim ou não perguntas do banco de dados. Por exemplo, a ferramenta pode pedir ao banco de dados se a primeira letra de uma tabela é menor do que “L.”

Se sim, o aplicativo pode não fazer nada, mas se não, o aplicativo pode lançar uma exceção. Usando essa lógica binária simples, é possível usar esta técnica para revelar a estrutura de banco de dados inteiro e mesmo os dados armazenados dentro - embora muito lentamente. Usando a ferramenta, ele identificou uma tabela de informações confidenciais de clientes e descarregado várias centenas de registros para mostrar ao cliente.

Finalmente, chegou a hora de tentar um último ato de dastardliness banco de dados. Em primeiro lugar, o Sr. Andrews carregou a ferramenta chamada Cain & Abel e configurá-lo para entrar no modo de sniffing. Em seguida, usando Paros Proxy eo parâmetro vulneráveis ​​já identificadas, ele usou a xp_dirtree procedimento armazenado estendido, que está disponível para usuários de banco de dados SQL Server, para tentar mostrar um diretório em sua máquina conectado à Internet usando um caminho Universal Naming Convention.

Isto forçou o banco de dados destino para realmente tentar autenticar-se contra a máquina do Sr. Andrews. porque Cain & Abel estava ouvindo no fio, obteve o hash do desafio usado para autenticar o compartilhamento de arquivo exposta.

Ao passar este hash para o cracker de senha embutido para Cain & Abel, o Sr. Andrews teria o nome de usuário e senha da conta na qual o SQL Server vulneráveis ​​foi executado em apenas uma questão de tempo.

Será que isso conta hackeada usar a mesma senha como a conta de administrador da aplicação web? Será que essa senha ser o mesmo que a conta de administrador local no host? Aqueles eram questões para outro dia. Era hora de reunir todos os dados coletados, preparar um relatório para o cliente, e colocar as ferramentas afastado para outro dia.

Chip Andrews é uma co-fundador da empresa de consultoria de segurança Special Ops Security, Inc. e proprietário da SQLSecurity.com, que tem vários recursos sobre a segurança do Microsoft SQL Server, incluindo a ferramenta SQLPing3. A co-autor de vários livros sobre a segurança do SQL Server e um apresentador Black Hat, Sr. Andrews tem vindo a promover SQL Server e segurança de aplicativos desde 1999.