厚客户端渗透介绍(二):网络测试
导语:厚客户端于服务端之间网络方面的问题测试
概述
上一篇文章中,我们介绍了厚客户端GUI方面的问题,本篇文章我们继续来测试网络方面的问题,以及在不同的架构中它是如何运行的。
BetaFast是采用三层架构编写的:
第一层:客户端显示和采集数据
第二层:服务端接受web请求并处理业务逻辑
第三层:数据库服务器修改和获取应用服务器的数据
Beta Bank采用双层架构编写:
第一层:客户端显示和采集数据
第二层:数据库服务器处理业务逻辑,执行客户端数据查询和修改
单层架构也是存在的,客户端,业务逻辑,数据存储都在同一台系统上,本文就不去讲解单层架构了。当然也有三层以上的架构,下面介绍的工具和方法也都是适用的。
双层架构
wireshark工具
一般我开始测试厚客户端时,第一件事就是分析网络请求流量。通常都是用wireshark来捕获和过滤网络流量。
这个例子中,我会测试Beta Bank这个应用。设置好合适的过滤规则,就可以在客户端中进行操作了,如提交表单,浏览应用程序,修改数据等,然后查找wireshark看是否有敏感信息:
· 数据库连接是否未加密?
· 社保账号和医疗信息等敏感信息是否明文传输?
有一次我使用blogger这个用户尝试进行认证,然后再wireshark的数据包流量中搜索blogger,blogger显示在一个登录过程中,这就表明在数据库连接时,用户名未加密,能够访问这个网络的人,都可以轻易的捕获这个数据,好在密码是加密的,这样攻击者就访问不到我的账户了。
真的访问不到吗?
从客户端发送的任何形式的密码,无论是明文的,加密的,还是hash值,其实都可以算是密码。虽然密码加密了,但是获取到这个密码,然后发送到服务端,就可以通过应用的认证。可以看到除了参数值混淆外,没有其他的防御措施,整个传输过程没有进行安全地加密。通过wireshark还观察到登录过程中的输出参数GUID,在应用程序的认证部分,这个过程接受GUID参数。
这个GUID就是我们业务中常说的会话ID,有了这个值,只要blogger用户会话保持在线,攻击者就可以执行通过认证的操作。
即便如此,攻击者没有拿到账号或权限,也已经造成一定的影响了。
Echo Mirage工具
在这个例子中,我是一个精通电脑的高手,并且从登陆过程中,嗅探到了blogger的用户名和加密的密码。
现在我们要用到echo mirage这款软件,这款软件可以截获并修改tcp流量。我们首先输入用户名blogger和任意密码,然后截获数据包:
然后修改密码为刚才我们用wireshark截获到的密码:
发送请求之后,可以看到我们已经成功登录,现在我们来看看这个账户余额有多少钱。
尴尬了,一分都没有,啥也不是。没关系,我们接着看看Beta Bank还有哪些客户。
如下图,取钱按钮已经禁用了,不过上篇文章中讲过一种技术,我们可以启用这个按钮。
抓包,观察wireshark,可以看到这个函数执行了一个sql查询:
Echo Mirage可以直接修改sql语句,虽然不能改变数据包的长度,但是可以注释掉后面的sql语句:
服务端响应了用户表信息,显然,连接到数据库的这个账户权限过高,现在我们获取到了每个用户的信息:
现在攻击面就更加广泛了。数据库层面还有很多可以挖掘和修改的,不过The_Chairman这个账户吸引了我的注意,一听名字就知道是个有钱人,精英人士,那就登录去看看吧:
这么多钱,吓得我一个激灵
三层架构
Burpsuite
Burpsuite可能是我在测试过程中用的最多的工具。在测试过程中,可以进行抓包代理,测试HTTP请求和响应方面,堪称神器。如果你没用过的话,可以参考这篇指南。
如果厚客户端采用三层架构编写,网络部分的测试其实跟web应用差不多,设置代理,在代理选项中设置监听端口,我就不多啰嗦了。
接下来我们设置系统代理,不是浏览器代理:
可能会有很多流量是不属于被测试应用的,所以我们需要知道哪些流量是来自厚客户端的,只要我们知道跟应用程序交互的主机和地址后,设置一个scope就可以了。比如测试BetaFast,我们发现它只向http://www.betafast.net:8080发请求,那我们把它添加到scope就可以了。
其他操作就跟web测试一样,抓包,查看请求。如下,我发现了一个请求,并发送到repeater,并尝试fuzz,发现了一个sql注入:
总结
网络是非常重要的,所以在测试厚客户端应用的时候,不要只关注于客户端。
Beta Bank和BetaFast如何保护他们的系统呢?措施肯定有很多,这里我提出以下几条作为参考:
Beta Bank修复措施
· 加密数据库连接—加密连接,隐藏敏感数据,防止网络窃取。只要执行了安全加密,也可以保护流量无法被修改。
· 最小权限原则—因为Beta Bank使用高权限用户连接数据库,因此当攻击者找到漏洞并加以利用,就可以完全控制数据库,执行任意操作。如果连接数据库的用户只拥有最小权限,那么攻击者只能执行权限以内的正常功能,可以减小危害。
· 密码加盐或者进行hash存储—加密本质上是可以逆向的。在接下来的文章中,我们会重点讲到。
· 强化身份验证逻辑—不要直接把通过网络发送的密码与数据库中存储的密码比对,这样的话,如果攻击者嗅探到密码,甚至不需要解密和破解hash,就可以直接利用。首先密码应该加密传输,然后服务器端对密码进行加盐或者hash处理,再与数据库中加盐过或经过hash加密的密码进行比对。
BetaFast修复措施
· 输入验证和参数化查询—跟Beta Bank不同,不是流量拦截和修改的问题,BetaFast问题出在应用服务器处理用户输入上。客户端输入的任何数据,服务端都应该进行验证,而且sql语句应该采用参数化查询。
ok,本篇文章就到这里,如果想要实战的话,可以去我们的github主页下载BetaFast和Beta Bank。各位表哥们,下篇文章见。
发表评论