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 do cliente 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 a fonte da página web, ele notou que uma escondidos Nome do aplicativo campo foi sendo passado para a aplicação sempre que um usuário tentou efetuar login no site. Poderia 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 época deste teste de penetração, o Sr. Andrews preferiu usar 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 às solicitações da web feitas para o servidor web.

Depois de spidering o site para páginas disponíveis e realizar uma verificação de vulnerabilidade rápida para injeção de SQL, confirmou-se que o Nome do aplicativo parâmetro apareceu para causar o aplicativo para lançar uma exceção de erro 500, indicando uma falha no 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 poderia injetar caracteres não intencionais no código SQL sendo enviadas a partir do aplicativo para o 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 destino à base de dados do Sr. Andrews localizado na Internet.

Isso geralmente é uma maneira muito eficiente para 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 o seu lema, o Sr. Andrews persistiu com a próxima ferramenta - o absinto. Esta ferramenta utiliza uma técnica chamada injeção SQL blind para fazer determinações sobre dados utilizando simples sim ou não perguntas do banco de dados. Por exemplo, a ferramenta pode pedir a base de dados se a primeira letra de uma tabela é inferior # 147-L # 148.;

Se sim, a aplicação pode não fazer nada, mas se não, o aplicativo pode lançar uma exceção. Utilizando essa lógica binária simples, é possível utilizar esta técnica para revelar a estrutura de base de dados inteira 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, era 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 o 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 conectada à Internet usando um caminho Universal Naming Convention.

Isto forçou o banco de dados de 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 expostos.

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 sob a qual o SQL Server vulnerável 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 esta palavra-passe 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, elaborar um relatório para o cliente, e colocar as ferramentas de distância 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. Um co-autor de vários livros sobre a segurança do SQL Server e um apresentador Black Hat, Sr. Andrews tem vindo a promover o SQL Server e segurança de aplicações desde 1999.