某游戏公司后台数据库SQL注入事件分析

某游戏公司后台数据库SQL注入事件分析

人物关系简介

Blank –SA

Dawn(Boss)

Ryan –DBA

Fred –离开公司的安全顾问

本案例出自于《Unix/Linux网络日志分析与流量监控》一书,该事例详细描述了一家公司的后台服务器被入侵,黑客从中获取了大量游戏币帐号,并发送邮件相威胁的案例。主要遇到的问题是服务器被SQL注入或受到了SQL注入攻击

Blank是XX公司的网络架构师,技术好人缘也不错,他实际的工作室XX公司的“首席救火队员”,每件事他都要自己做,就连做网线也不放过。

这一天跟其他日子一样Blank正在上网,突然他的上司突然打断了他说

“Blank,我有事找你。”她表情严肃地说。

“我刚收到这封电子邮件。”Dawn在和Blank一起去她的办公桌时边走边说。

我发现你的网站有一个安全问题。它泄漏了你所有用户的记录和信用卡号。我是一个为了通过咨询来挣钱的、努力的学生。如果你给我1000万,那么我会告诉你怎么修复这个问题。如果你不给我钱,那么我就要公开这些信息了。

为了让你相信,下面是你的几个客户。

Shane Mason – 5111111111111111

Dan Burnham – 4111111111111111

Dana Mueller - 5555511111111111

Blank惊呆了。他穿过防火墙获得了账号。那些在影视剧里才有的敲诈勒索事件就出现在Blank的公司。

为了查明原因Blank迅速与公司的DBA联系,确定了那些用户账号和密码的真实性,结果完全一致。Blank十分害怕下面将要发生的事情。通常来说,坏的事情总是发生在最后。

“嗯,Dawn,我真的不知道。Fred负责所有的安全问题。他离开公司后,没有人负责这一块了。

“现在Fred在哪里?”她问。

“他在某个咨询公司。我有他的名片。”

“赶快打电话给他,叫他现在到这里来,”她说。“我不在乎花多少钱。”

“可能我们应该叫警察?”Blank小心地提议到。

“我不想让这件事泄露出去。我们公司正准备上市,如果他们知道了我们有安全问题,那么我们就完了。去叫Fred,快!”

Blank快速回到他的写字间,他的脑中还萦绕着这个事件方方面面的问题。他慢慢整理成堆的商务名片,试图找到Fred的名片。Blank找出了Fred的名片:“Fred  ,CISSP。”Blank想像某一天自己也会成为CISSP。现实把他猛然拽了回来。Blank拿起电话,拨了Fred的电话号码。

“我是Fred Langston。”

“嗨,Fred,我是XX公司的Blank。”

“嗨,Blank,很高兴接到你的电话。真希望你一切都好。”Fred兴高采烈地说

“一点也不好,Fred。我们有一个安全问题,我们非常需要你的帮助。”

“我已经安排了一个会,五点钟开完。”

“太好了,Fred。那太好了,我等你。”Blank说。

“同时,我会叫我办公室的人把我们的标准文书传真过去,  以备我们的进一步合作。

“Fred,我确实想进一步合作。我们这里有很大的麻烦了,现在分秒必争。”Blank恳求道。

“真的?发生了什么?”

“公司服务器被黑了”

Fred想了一下之后说:“好吧,Blank,给我五分钟,我会给你回电话的。”

Blank挂断电话,等了三分钟,可是他觉得像过了一个小时一样。电话响了。“我是Blank。”

“嗨,Blank,我是Fred。我在十分钟之内过去。

Blank快速回到他的写字间,Blank拿起电话,拨了Fred的电话号码。

Fred打开门,对Blank今天的落魄感到吃惊。

“嗨,Blank,你把文件签署好了吗?”

那么让我们开始工作吧。”Blank和Fred占用了一个会议室,迅速开始工作。Blank快速告诉了Fred有关细节。Fred靠在他的椅子上,考虑了一会说:“Blank,你应该叫警察,这是敲诈勒索。”

“Dawn说不能惊动警察,”Blank说。“她不想让这件事公开。”

“好吧。那么我需要一个网络图、防火墙规则,还有那份电子邮件所有信头的信息。看我们是否能搞清楚他是怎么入侵的。”

Blank跑去收集Fred需要的数据。Fred靠在椅子上,清理着他的思路。Fred的思绪飘回到了他在Widgets.com公司的时候,那时他设计网络的体系结构。他回忆起严格的火墙规则和完美的DMZ设计。他怀疑Blank改动了许多设计,因为他当时也负责这事情。Blank拿着一叠纸走进房间。

“这是所有的数据,Fred。”

Fred在桌子上展开了这些文件。下图是Widgets.com公司的网络结示意构图。

Widgets.com公司的WEB防火墙规则:

Conduit permit tcp host 192.150.50.5 eq www any

Conduit permit tcp host 192.150.50.5 eq 443 any

如下是Widgets.com公司的数据库防火墙规则:

Conduit permit tcp host 192.150.52.4 eq 1443 host192.168.50.5

下面是Fred从Blank那里得到的带有全部头信息的电子邮件:

Received: fromns1.widgets.com(10.1.2.11[10.1.2.11])by mx01.widgets.com with SMTP (MicrosoftExchang internet Mail Service Version 5.5 .2656.59) id R44ZWRCF2;Mon,13 Mar2010 14:57:00-0400

Received: fromweb21501.mail.webmail.com(web21501.mail.webmail.com[10.163.169.12])

by ns1.widget.com(8.11.6/8.11.2) withSMTP id g81J4PM30909

for <[email protected]>; Mon,13Mar 2010 15:04:25 -0400

Message-ID:<[email protected]>

Received:from [10.9.212.210] by web21501.mail.webmail.com via HTTP;Sun,01 Sep 201011:54:30 PDT

Date:Mon,13 Mar 2010 11:54:30 -0700(PDT)

From:KunFoo<[email protected]>

subject:Security Issue

To:[email protected]

MIME-Version:1.1

conten-type:mutipart/alternative;boundary="0-259684995-1030906470=:84428"

--0-259684995-1030906470=:84418

content-Type:text/plain;charset=us-ascii

--0-259684995-1030906470=:84418

Conten-Type:text/html;charset=us-ascii

I have discovered a securityproblem whith your web site. It reveals all your user records and credit cardnumbers  I am a struggling student thatmaked money going consulting .I will tell you how to fix this problem if youpay me $150000.If you decide not to pay me I will go public with thisinfomation. In case you are curious here are a few of your customers.

Shane Mason - 5111111111111

Dan burnham - 4111111111111

Dana Mueller -3111111111111

Fred认真检查了网络图和防火墙规则。“我走后你改动了什么吗,Blank?”

“不,伙计,我太忙了,一直忙着救火,没有空改任何东西。应该还和以前都一样。”

“那补丁呢?”Fred问。

“所有的Windows Server 2003服务器都运行了最新的补丁,我很肯定SQL服务器是打了补丁的。”

“好吧,看起来惟一能进入的通道就是Web服务器。让我们从那里着手。”

Fred从他的背包里抽出笔记本电脑,开始了工作(黑色瑞士***牌双肩背包里抽出笔记本电脑)。“我准备检查一下Web服务器的漏洞(采用了什么方法检查Web服务器漏洞的),“他说。“这些天谁看了Web服务器的日志?”

“我很肯定负责市场的Alex看了它们。”Blank说。

“好的。我需要最近几周的日志。”

Blank再一次走出门。Blank开始跑来跑去一点一点收集文档。他拿回来一大堆的设备归档日志,扔在Fred面前。

“这是你要的所有日志。”

Fred开始反复查阅Blank获得的日志记录,但是在这些日志中丝毫没有找到线索, Fred都快要发疯了,这时候,Ryan冲进门来。

“Blank,我有事找你。昨天晚上SQL服务器发生了奇怪的事情。”

“我现在真的没有时间,Ryan,”Blank呻吟道。

“你发现了什么,Ryan?”Fred迫不及待问到。

“只是一些奇怪的错误,”Ryan边说边递过来一张纸。下面就是他发现的代码:

3/12/10 1:24:12 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBC Drivers->AuthenticateCustomer[Microsoft][ODBCSQL Server Driver][SQL Server]Line 1: Incorrect syntax near`:`.

3/12/10 1:24:36 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->AuthenticateCustomer[Microsoft][ODBC SQL Server Driver][SQLServer]Line 1: Incorrect syntax near`,`.

3/12/10 1:24:55 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->AuthenticateCustomer[Microsoft][ODBC SQL Server Driver][SQLServer]Line 1: Incorrect syntax near the keyword`OR`.

3/12/10 1:25:10 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->AuthenticateCustomer[Microsoft][ODBC SQL Server Driver][SQLServer]Line 1: Incorrect syntax near the keyword`UNION`.

3/12/10 1:25:19 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->AuthenticateCustomer[Microsoft][ODBC SQL Server Driver][SQLServer]Line 1: Incorrect syntax near the keyword`)`.

3/12/10 1:25:32 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->AuthenticateCustomer[Microsoft][ODBC SQL Server Driver][SQLServer]The identifier that starts with `UNION ALL SELECTO ther Field FROMOt` istoo long. Maximum lenth is 30.

3/12/10 1:25:10 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->AuthenticateCustomer[Microsoft][ODBC SQL Server Driver][SQLServer]Line 1: Incorrect syntax near `UNION SELECT NAME,PASSWORD,FROM USERSWHERE`:`.

3/12/10 1:25:31 AMecom systemFailure:80040E14 Microsoft OLE DB Provider for ODBCDrivers->getParNo [Microsoft][ODBC SQL Server Driver][SQL Server]Invalidobject name `USERS`.

这时Fred眼前一亮。他从光盘上打开IIS服务器的日志文件,开始一页一页地看,直到找到第一个SQL服务器错误的时间记录:

03/12/2010 1:24 10.9.212.210W3SVC1 WWW-2K WWW-www.widgets.com 80 POST/catalog/search.asp501 749 492 32 www.widgets.comMozilla/5.0+(compatible;+MSIE+5.1;+Windows+98)

“啊哈!”Fred大叫一声。

他似乎有了重大发现,接下来该怎么办?在《Unix/Linux网络日志分析与流量监控》一书中进行详细分析。

时间: 2024-08-01 10:33:10

某游戏公司后台数据库SQL注入事件分析的相关文章

Oracle数据库SQL注入浅析与防护建议

作者:安华金和 思成 SQL注入是在信息安全领域一种常见的攻击手段.但是大部分人理解的SQL注入就是通过把SQL命令插入到Web表单提交或在输入域名.页面请求时加入的查询字符串,最终达到欺骗服务器执行偏离预期的SQL命令.这种情况下的SQL注入,引发原因基本是网页对用户输入的信息缺乏校验而导致. 很多人认为只有网页才可以进行 SQL 注入,才有注入点.这是一个普遍对SQL 注入的错误认识.SQL注入严格来讲应该叫做数据库SQL注入.SQL注入的最终目的是获取数据库中存储的敏感信息.事实上,任何可

sql注入实例分析

什么是SQL注入攻击?引用百度百科的解释: sql注入_百度百科: 所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令.具体来说,它是利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句.[1]比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表

PHPCMS \phpcms\modules\member\index.php 用户登陆SQL注入漏洞分析

catalog 1. 漏洞描述 2. 漏洞触发条件 3. 漏洞影响范围 4. 漏洞代码分析 5. 防御方法 6. 攻防思考 1. 漏洞描述2. 漏洞触发条件 0x1: POC http://localhost/phpcms_v9/index.php?m=member&c=index&a=login dosubmit=1&username=phpcms&password=123456%26username%3d%2527%2bunion%2bselect%2b%25272%2

JDBC的SQL注入漏洞分析和解决

1.1.1 SQL注入漏洞分析 1.1.2 SQL注入漏洞解决 需要采用PreparedStatement对象解决SQL注入漏洞.这个对象将SQL预先进行编译,使用?作为占位符.?所代表内容是SQL所固定.再次传入变量(包含SQL的关键字).这个时候也不会识别这些关键字. public class UserDao { ????????? ????????public boolean login(String username,String password){ ????????????????C

优客365 v2.9版本 后台存在SQL注入

安装 打开后台登陆界面 http://localhost:9096/yk365/system/login.php 输入单引号报错 得到表名 经过跟踪后在\module\login.php文件出现错误 代码处理不严谨.根据上图,经测试,用户名可以用1' or '1'='1进行绕过 但密码经过md5加密 接下来通过SQL注入得到md5加密后的密码 payload:' and (select 1 from(select count(*),concat(0x7e,(select user_pass fr

MySQL-注释-Navicat基本使用-复杂查询练习题-解题思路-pymysql操作数据库-SQL注入-05

目录 mysql语句注释 navicat 的基本使用 特色(个人总结) 与数据服务器建立连接 创建&打开数据库.表 创建 打开 修改操作表结构 修改表结构 查询修改操作表数据 基本语句对应的操作 模型 ***** 特色功能 从数据库建立模型 模型页面基本操作 用模型设计数据库并导出 结构.数据导入导出 导出 导入 附属小功能 刷新小按钮 查看操作对应sql语句 执行时间查看 手动筛选数据 练习 数据准备 使用SQL语句导入表结构与数据 如何验证答案是否正确 题目 部分参考答案(只放了两题的) 少

java后台防止sql注入的方法

1.采用预编译语句集,它内置了处理SQL注入的能力,只要使用它的setString方法传值即可: String sql= "select * from users where username=? and password=?; PreparedStatement preState = conn.prepareStatement(sql); preState.setString(1, userName); preState.setString(2, password); ResultSet rs

Discuz!7.2 faq.php文件SQL注入漏洞分析及利用实战

[antian365.com] simeon 最近网上公开了Discuz!7.2版本faq.php文件SQL注入0day,通过对文件漏洞分析以及实战测试,效果不错,公开利用exp的利用需要对SQL语句以及数据库等相当了解,在某些情况下需要多种技术配合才能最终攻克目标,下面就漏洞代码以及实战利用等进行探讨,对获取管理员密码的利用,uc_key获取webshell,插件导入获取Webshell等进行探讨. 1. faq.php文件SQL注入漏洞代码分析 本次存在漏洞的文件为faq.php,打开该文件

手动SQL注入原理分析与实践

代码仓库 本文所用代码的代码库地址: 点击这里前往Github仓库 了解SQL注入 定义 SQL注入攻击(SQL Injection),简称注入攻击,是Web开发中最常见的一种安全漏洞.可以用它来从数据库获取敏感信息,或者利用数据库的特性执行添加用户,导出文件等一系列恶意操作,甚至有可能获取数据库乃至系统用户最高权限. 原理 造成SQL注入的原因是因为程序没有有效过滤用户的输入,使攻击者成功的向服务器提交恶意的SQL查询代码,程序在接收后错误的将攻击者的输入作为查询语句的一部分执行,导致原始的查