攻防演练在即：如何高效全面地排查信息系统用户状态和弱密码

回归写写专业内容。

接下来的7、8月，已经成了传统的攻防演练月，所以网络安全这个细分领域无论甲方乙方都是没有暑假的。

那么，6月就是工作准备月。被选中是靶标的单位自然要提起十二万分的小心，没被选中的也断然不能掉以轻心，总不能让攻击队轻易地就顺手在自己这里拿个分吧。

关于准备工作，大多数公众号内容都是老调重弹：弱口令排查，权限清理，离职账户关闭，应用系统漏洞修补，操作系统补丁升级，安全设备防御规则审核，有条件的再提前自己安排做渗透测试，等等。

就这样了？

并不是。我这还有些其它角度的准备措施，不过说实话我这些措施非常强调个人能力，对于大多数甲方和乙方（指网络安全运维服务商）都是难以实施的，仅供参考。

今天说说最基本的：信息系统用户账户状态和弱密码的检查。

有网络安全运维经验的读者都知道，信息系统用户账户的排查，用常规检查方法是难以确保100%覆盖和完成的。

具体到账户控制、密码强度以及用户角色、权限甚至数据访问控制级别等等具体属性，就算导出清单弄成 EXCEL 表也要花很多时间去甄别。

而且关键的弱密码问题，即使信息系统本身有较好的安全设计，强制了口令强度，用户都还是有可能找到弱化的办法并长期利用。

这最典型的就是符合强密码规律的弱密码。比如你要求我是大小写字母加数字符号都要有，那我就来个 Abcdef!1234。

强吗？看上去是很强。弱吗？事实上就是弱密码。

没几个信息系统会在强密码规则的基础上进一步实现弱密码检查，其实也不是所有的密码强度检查工具都会说这个密码是弱密码：

例如上图这个工具就会认为这个密码是个强密码，破解时间高达10.8亿世纪......实质并不是。

所以最直接的方法就是跳过信息系统这一层，直接面对数据库，从数据库存储系统用户账户信息的表内容直接下手进行检查。

这个检查的过程有点复杂。首先要：

可能马上就有读者想说，这怎么能拿得到？

实际上，这一条应该是作为信息系统建设的必要要求而被写入合同。否则从信息系统审计角度就已经明确地构成了风险因素：甲方不掌握数据字典，等同于不掌握自己的数据。

如果当初合同没有约定，那么可以考虑以下两种做法：

第一种，最低限度地，基于网络安全的前提要求厂商提供和用户账户信息有关的表的数据字典。

第二种，自行发掘。大多数信息系统的用户信息表名都有明显特征很容易找出来，比如 User，Account 甚至 Zhanghao，Yonghu 之类，难点只在于字段的含义。

有些信息系统的设计，表的字段名是有含义的，很容易理解，比如我下面给出的示范例子。

而有些信息系统是通过预设表字段的方式设计的（为了避免在系统运行时加字段导致出问题），字段名通常会是 U01，U02，U03 这样，这就需要根据字段内容和开发经验去猜。

可行的办法比如在信息系统里面创建一个测试用户，然后不断修改用户各项属性，比对表内字段值的变化从而确定字段的用途。

当然说是很轻巧，实际过程要耗费不少时间。

为方便下文的说明，在这里我设计了一个高度精简的示范，表名为 sys_users，只有三个字段：账号名、密码、账号状态：

sys_users 表

这可以分为两种情况，我将之区分为直观信息和不直观信息。

第一种是直观信息，典型如示范中的 UserIsEnabled 字段。

按网络安全要求，离职人员账户应禁用（而不是删除），那就可以根据表示账户是否启用的字段的值筛选出正在启用状态的账户，然后和人力资源管理部门共同核对。

比如对于刚才给出的示范表，我们就可以用如下的 SQL 命令进行筛查：

SELECT * FROM sys_users WHERE UserIsEnabled<>0

值得注意的是，这个查询的 WHERE 条件，实质筛查的是“可能处于启用状态的账户”而不是“处于启用状态的账户”。作为排查，务必要设计为筛查目标对象的超集。

原因是，开发信息系统的程序员是有可能没有准确地按照数据字典的要求去写程序的。

如下是很典型的一种偏差：

（1）在信息系统的用户管理界面上，筛选启用了的账户，所显示的是 UserIsEnabled 字段为1的用户，也即是如下的筛选查询条件：

SELECT * FROM sys_users WHERE UserIsEnabled=1

（2）但在用户登录检查逻辑中，检查账户是否启用，所用的筛选条件却是判断 UserIsEnabled 字段不为0：

SELECT * FROM sys_users WHERE UserIsEnabled<>0

很明显不为0就是为1的超集。这样的逻辑判断，会导致 UserIsEnabled 字段值为1之外非0值的账号也能登录，但在用户管理界面上就筛选不出来，会被误以为已经禁用。

后果就会很严重，读者可以自己发散想想。

所以在排查时，就要找出超集的条件，然后按超集进行筛查。

第二种情况是对非直观信息进行排查，比如弱密码问题。

现在不应该还有账户密码不加密就直接存进去数据库的信息系统，也就是用户的密码经过了如下的过程才保存进去数据库表字段里面：

用户输入（明文密码）- 加盐加密（密文密码）- 保存到数据库（密文密码）

面对一堆密文，如何确定其是否弱密码，表面上看是不可能的，即使明文密码只是做了一次 MD5，从 MD5 的结果用彩虹表倒推原来的密码也是非常耗时耗力的事。

不过还是有个办法，那就是：

具体一点：使用和信息系统对密码进行加密的相同的算法，用弱密码字典产生弱密码加密结果表，然后比对存在用户信息表里面的密码加密是否弱密码。

肯定又有读者第一反应是：“道理我都懂，但这算法从哪里来”了。

答案其实就是刚才获得数据字典的两种方法：要么找信息系统的厂家拿，要么自己做逆向工程。

找厂家拿就不说了。而逆向工程完全就是个人能力问题。所以我在一开始就说了我这些办法不是随便哪个甲乙方人员都有能力做到的。

说起来，前不久我在某论坛上就现在的程序员没几个懂汇编语言（逆向工程懂汇编是基本功）发表了一下看法，居然还有人觉得不爽认为汇编已经过时没必要再学。

就这行业平均水平，果然中国软件行业正在走向全军覆没。

如何实施逆向工程，这超出了本文的主题，不具体展开。关键在于，由于我们的目的是利用信息系统的密码加密算法，从常见弱密码字典产生弱密码的密文，也就是计算的方向和加密算法本身是一致的，所以在逆向工程中，并不需要搞懂加密算法究竟是如何加密的，只需要实现能调用即可。

尤其是很多程序员喜欢在这事上面弄点自己种的花，要读懂真不一定是容易的事。

有个例子是笔者手头处理过的一套信息系统，那边的程序员自己弄的单向加密算法，加密结果在字符序列上呈现出非常明显的统一特征。本来想放截图，想想还是算了，没必要显得在怼别人。

关于“统一特征”，熟悉密码学的读者马上就会知道，这系统的密码加密算法很容易产生碰撞，也就是会把不同的密码加密为一样的密文，所以它的加密效果实际还不如常见的做法：加盐之后迭代两次 SHA256。

既然都预见到了缺陷，我当然是没兴趣去研究他这棵自己种的花啦。

除了算法之外，弱密码字典也需要有足够的数据量，还可以包括已泄漏密码字典，这些网络上都有，也可以自己写个程序生成，不是难事。

最后的比对过程直接在数据库里面建表，然后和用户账号表的密码字段比对即可。

由于大多数甲方信息系统内的用户数量都是有限的，所以这个比对过程虽然时间复杂度是 O(n*m)，但实际并不会特别长。而且还可以想办法优化缩短排查时间。

数据量少的时候，甚至用 VLOOKUP 都可以搞定了。

信息系统用户排查的其他方面，比如角色、权限甚至细粒度的数据访问控制，其原理和直观信息的排查过程基本一致，读者可以触类旁通。

原文始发于微信公众号（wavecn）：攻防演练在即：如何高效全面地排查信息系统用户状态和弱密码