wmsuper 发表于 2020-4-8 20:27

从安全设计角度看网络验证

本帖最后由 wmsuper 于 2020-4-12 10:47 编辑

背景
    由于个人软件的兴起,越来越多网络验证如雨后春笋不断冒出来。但是由于验证的作者个人安全意识水平参差不齐,导致有些验证作者根本不懂安全,又何谈防破解?本文将从安全设计的角度来谈谈一些
网络验证历史上曾出现的漏洞和简单的防御措施(本文出现的漏洞均已被修复)。

服务端安全
    对于网络验证行业来说,由于不同网络验证作者的技术栈,使用开发语言多种多样,有java,php,asp甚至是易语言开发的网络验证,但是无论用什么开发语言,由于安全意识的缺乏导致的安全漏洞还是层出不穷。
   
0x00 SQL注入
    sql注入漏洞拥有悠久的历史,稍微有些开发经验的开发者很容易能避免出现这类问题,但是在有一些网络验证中仍然出现。
    有直接在充值卡号进行注入的:
   
    有些可以直接在验证客户端直接注入:
   
    sql注入漏洞轻则数据泄露,重则数据被修改,甚至远程代码执行,对于这类漏洞开发人员一定重视起来。
    安全措施:过滤或者屏蔽恶意的注入代码(sql语句预编译也能很好解决此类问题)

0x01 XSS 攻击
    这类漏洞对于验证的开发人员最容易出现的问题,忽略了前端的安全,导致很多网络验证都出现过类似的问题,这里就不一一列举:
   

   攻击者可以注入恶意的用户名,来劫持软件作者后台的管理权限,甚至可以影响到验证作者管理软件作者的后台。
   安全措施:对要显示到前端的字符串进行有效地转义。

0x02 远程函数漏洞
    为了增加软件破解成本,验证作者会支持软件作者自定义的一些变量或者远程函数,这类功能往往会出现一些逻辑设计问题,比如有些网络验证会
会让用户自定义javascript函数来让软件去远程调用。但是没有考虑到eval之类的全局函数,导致攻击者可以恶意构造请求包获取自定义的远程函数的源代码:

危险的js全局函数列表:

   
甚至有些远程函数是设计成直接调用php语句,由于过滤机制不严谨,导致恶意的软件作者可以在验证服务器上执行任意代码。
安全措施:过滤敏感函数,可以使用docker技术运行远程函数,与宿主机隔离。


0x03 横向越权
很多网络验证在设计初期没有处理好验证作者之间的关系,在数据库操作时没有加上限定语句,导致一个软件作者可以修改另一个软件作者的信息,比如为其他软件作者添加卡密,添加或者删除其他软件作者的用户等。
如下,某个所谓军工级加密的网络验证,可以为其他软件作者的软件添加用户,并且增加时长:

安全措施:数据库操作时增加限定语句

0x04 CSRF攻击

    在网络验证实际测试中,CSRF漏洞出现得特别多,这类漏洞通过结合社工,比如让一个已登录得软件作者点击一个恶意的网站中的链接即可获取或者修改后台信息,比如隐蔽性比较高的就是获取软件的所有卡密:

去掉Referer字段,发现仍然可以获取到卡密列表,说明存在CRSF漏洞

安全措施:对Referer字段校验或者加crsf-token。
前面说了有的网络验证会用易语言去实现,那么这类网络验证又存在什么问题呢?

0x05 目录穿越

有些网络验证为了提供下载文件的能力,会开放文件下载接口,去下载特定目录下的文件,用户只要提交文件名就可以返回文件数据,但是由于对文件名没有校验,导致目录穿越,可以下载远程主机的任意文件。
字母盾历史上出现的漏洞:

安全措施:过滤“..”等恶意字符

0x06 组件安全
易语言的很多模块或者组件是由第三方维护的,其中会出现很多安全隐患,但是不是用官方的组件就安全呢?并不是,下面是易语言远程服务组件的0day攻击,可以造成远程拒绝服务:

安全措施:更换更安全的网络组件



客户端

客户端指的是软件这一边的安全性,一些安全性缺失导致破解频出:

0x00 明文通信
    通信不加密可以直接让攻击者不修改软件的情况下,劫持流量来进行破解:


安全措施:加密数据流量。

0x01 耦合性缺失
    验证与软件耦合性缺失直接导致软件更加容易被破解,特别是一些所谓的一键集成(软件作者为了方便小白作者提供的无源码对接验证的功能,上传exe就可以进行加密),有些一键集成使用了VMP的dllbox功能,把验证功能写到dll里面
如果直接在验证的dllmain进行返回(retn),就可以直接绕过验证:

甚至有些能直接脱壳

安全措施:增加耦合性,比如在软件运行后仍然需要读取验证服务器的数据。

0x02 算法缺陷

   在有些一键集成中,需要在登陆后获取解密密钥才能解密代码段,但是加解密算法设计缺陷可以造成不需要登陆,就可以解密出代码段:
如下就是简单的xor加密:
解密前:


解密后:


反推密钥:

由于以上xor算法缺陷,可以导致无卡解密代码段(通过爆破或者特征值)

安全措施:使用更加安全的算法。
0x03 虚拟机强度缺失

有些验证作者为了增加软件的耦合性,选择自研虚拟机保护,但是开发投入有限,强度往往偏低,导致在虚拟化的情况下仍然可以进行有效的代码分析:


安全措施:在对虚拟化保护技术的研究投入资源有限的情况下应该选择市面上更加成熟的虚拟化产品。


总结

破解与反破解的技术一直在对抗中成长,希望未来(或许已经出现?)有更加好的网络验证产品为合法的中小软件开发者保驾护航。

免责声明
    本文所有的素材由群友提供,本人不赞成也不鼓励任何非授权情况下的渗透测试活动,本篇文章只用于技术学习,严禁任何非法用途。

qzhsjz 发表于 2020-7-31 10:42

网络验证的安全性是整个系统的,任何一个部分强度不够都不行。

xyx0826 发表于 2020-4-10 16:14

HTTP通信即便上HTTPS也能被本机中间人攻击,比如Fiddler或mitmproxy
这种情况下需要certificate pinning/证书锁定,即便操作系统证书验证通过也只信任预先设好的服务器证书

魔道书生 发表于 2020-4-11 09:49

390浏览 2回复惨案
这么好的文章
我TM直接战术挠头

spy7 发表于 2020-4-15 13:52

学习了,长见识

mao622732 发表于 2020-4-15 16:19

战术挠头。。。
{:1_907:}

作为技术很菜的C#程序员,真不知道该怎么加密才好

xuhaosen 发表于 2020-4-16 13:07

谢谢!学习了

waterline 发表于 2020-4-18 20:03

这个是看雪上面发表的

wmsuper 发表于 2020-4-19 11:55

waterline 发表于 2020-4-18 20:03
这个是看雪上面发表的

都是我发的,没啥人看{:301_972:}

as2788 发表于 2020-4-19 15:26

6666,学习了

hua111 发表于 2020-4-20 09:33

页: [1] 2 3 4 5
查看完整版本: 从安全设计角度看网络验证