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

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

随着7、8月攻防演练月的临近，网络安全领域的工作进入关键时期。本文从数据库层面出发，详细介绍了如何全面排查信息系统用户状态和弱密码，为攻防演练做好充分准备。

在攻防演练前，信息系统用户账户状态和弱密码的检查是至关重要的准备工作。然而，使用常规检查方法往往难以确保100%覆盖和完成。本文将从数据库层面出发，介绍如何全面排查信息系统用户状态和弱密码。

如何实现100%覆盖的检查？

信息系统用户账户的排查，使用常规检查方法难以确保100%覆盖和完成。具体到账户控制、密码强度以及用户角色、权限甚至数据访问控制级别等具体属性，即使导出清单弄成EXCEL表也要花很多时间去甄别。

而且关键的弱密码问题，即使信息系统本身有较好的安全设计，强制了口令强度，用户都还是有可能找到弱化的办法并长期利用。这最典型的就是符合强密码规律的弱密码。比如要求大小写字母加数字符号都要有，那用户就可能使用类似Abcdef!1234这样的密码。

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

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

获取信息系统的数据库字典

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

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

• 第一种，最低限度地，基于网络安全的前提要求厂商提供和用户账户信息有关的表的数据字典。
• 第二种，自行发掘。大多数信息系统的用户信息表名都有明显特征很容易找出来，比如User，Account甚至Zhanghao，Yonghu之类，难点只在于字段的含义。

有些信息系统的设计，表的字段名是有含义的，很容易理解，比如下面给出的示范例子。而有些信息系统是通过预设表字段的方式设计的（为了避免在系统运行时加字段导致出问题），字段名通常会是U01，U02，U03这样，这就需要根据字段内容和开发经验去猜。

可行的办法比如在信息系统里面创建一个测试用户，然后不断修改用户各项属性，比对表内字段值的变化从而确定字段的用途。当然说是很轻巧，实际过程要耗费不少时间。

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

理解字典后，设计需要排查的情况和编写SQL查询

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

直观信息

典型如示范中的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都可以搞定了。

结论：检查数据是最直接的检查手段

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