作者简介
北京工业大学国家等级保护2.0与可信计算3.0攻关示范基地管理办公室副主任、北工大-可信云科重明研究院院长 胡俊
1. 迎接挑战
一个多月前，我刚刚结束了系统安全综合课设课程，正准备认真完成国赛创新能力赛决赛的可信赛题设计工作时，永信至诚的陈泽楷发来了消息，问我能否为信安国赛决赛的Build环节设计一道可信赛题。最初的要求是：给每个决赛团队一个docker容器，选手随意编写容器，完成解答后提交，平台载入容器后，导出解答文件并自动进行裁决，生成选手的分数。实际上，我们刚刚做了这一开发的尝试，初赛中的赛题实际已经具备了一定的自动裁决功能，这个提议与我设想的后续工作比较一致，因此引起了我的兴趣。我又询问了一些情况，并在当晚研究院的学术讨论会中进行了讨论，大家认为，这个任务开发工作量很大，而我们的赛题机制和裁决机制还不够稳定，并且这方面的工作很可能会影响决赛赛题的设计。因此大家决定放弃这次机会。但是，第二天我答复泽楷时，泽楷的一个回复让我改变了想法。泽楷说，决赛第一天可信赛题和AWDP同时进行，如果大家不熟悉可信赛题，很可能放弃这些题目，但如果有Build环节赛题的体验，可能愿意体验的队伍就会多一些。我想到当初某比赛大家对可信赛题“交白卷”，以及去年初赛时可信赛题只有三队完成解题的情况，最终决定，还是接下这个任务，就当是为决赛赛题设计教程了。当然，接下这个任务，我还是有一定的底气的，这个底气除了来自于线上初赛已实现的裁决机制，还有一个则是我在刚刚结课的系统安全综合课设中，给学生们提供的一个模拟工控安全环境，以及与这个环境配套的四十余页的说明文档。模拟环境的框架设计如图1所示：图1 2024国赛Build环节赛题背景-模拟工控场景
我用自行开发的通用可信基础软件原型架构实现了这个环境的模拟，在课设中，我要求学生们围绕这个场景设想威胁，寻找脆弱性，确定其中的某项或某几项风险，再根据风险，从访问控制或者密码保护角度提供解决方案。我认为，这一场景下，是可以找到足够多的、循序渐进的问题，来满足Build环节比赛要求的。而自动裁决机制则可以基于线上初赛时开发的裁决机制来改造实现。因此，我设计了一个赛题方案并提交给了泽楷。赛题方案包括了基于以前出的部分可信赛题的练习部分，基于课设的模拟工控场景及相关安全分析，覆盖攻击模拟、访控练习和密码练习的安全模拟部分，以及基于可信密码机制的进阶学习部分。方案提供给泽楷后，泽楷建议练习部分不算分，进阶学习部分留到决赛可信赛题阶段应用，对第二部分，泽楷提出了一个要求：需要我们提供对不同任务的验证模拟方法。根据泽楷的意见，我们修订了赛题方案，仅仅保留了第二阶段作为赛题的正式内容，并将其拆分成了十多个小任务，初步拟定Build环节赛题解题时间为三天。这一方案也得到了组织比赛的川大老师的认可。后来在赛题讨论会上，有老师提出这一赛题模式很新，担心学生们难以适应，我们又去掉了一个综合任务，并且将Build环节解题时间定为了五天。在讨论赛题细节的同时，7月1日晚上研究院例会时，我正式确定了Build环节赛题开发任务，并动员研究院的学生们，正式启动了赛题设计与开发工作。2. 没有可信的可信赛题
本次Build环节赛题设计，我一开始就确定了题目设计的思路：设计一个来自于实际工控环境安全需求的，体现可信3.0技术特点，又没有可信方面专业知识的可信赛题。作为安全可信的入门练习，我们不希望用太专业的知识给同学们增加难度，希望同学们能够使用教科书或者网上可以查到的知识，以循序渐进的方式解出题目。我们为题目设定了三个与传统赛题有所不同的创新特色：- 以模拟工控环境为背景，展示安全的目标是保护业务流程。
- 以访控、密码等合规的防御技术为主要考核内容，以符合《密码法》和《网络安全法》指出的网络安全方向。
- 以主动拦截防御方式添加安全机制，让学生体验可信3.0对应用透明的原理。
在这一思路下，我们将赛题划分成了四个板块：新手板块、攻击模拟板块、访问控制模拟板块与密码应用板块。新手板块
新手板块主要用来让选手们熟悉赛题实现框架与相关应用，我们将其设定为不需要编程，只需要配置和阅读代码的任务。这里我们设置了三个任务。任务1-1实际上就是让选手体会一下模拟环境中的业务流操作，并且了解这些业务流的配置方法。这些业务流就是本次Build环节任务的保护对象。
任务1-2则是让选手们进行重放攻击模拟。这里攻击路线、攻击模块都已经准备好，题目要求选手通过修改配置文件来启用模块，同时通过阅读模块源码来寻找攻击者预设口令。但我们希望选手是通过这两个行为了解赛题以模块化方式模拟攻击和防御的方法，以及模块实现的基本原理。
任务1-3要求选手将身份认证机制改为挑战-应答机制以防范任务1-2的重放攻击。这里我们想给选手展示的就是以切面方式添加安全机制的方法。切面方式添加安全机制，可以在不改变原有流程的情况下，通过复制或拦截方式，增加安全处理过程，这种方法可以让新增的安全机制与旧流程解耦，对系统添加安全机制后的稳定性有很大便利。可信3.0要求以主动拦截方式添加安全机制，而蚂蚁公司提出的“切面安全”理念可以视为可信3.0在业务流程安全机制添加上的具体实现。
图2 以切面方式添加挑战-应答过程
攻击模拟板块
攻击模拟板块展示了一些简单的攻击方法，但其主要还是服务于后续的访问控制和密码保护任务，本板块中模拟的攻击行为，实际上就是第三板块、第四板块中需要应对的攻击威胁。任务2-1实际上就是找到系统中未控制的访问行为，并通过设置输入样本来执行这些访问行为。
任务2-2模拟对工控PLC上传逻辑的攻击。我们要求攻击者完成file_replace模块中的文件替换代码，以在上传过程中用恶意代码模块替换正常的模块。这里的代码非常简单，用system函数调用一个文件复制命令即可。
任务2-3略微有点难度，它需要选手了解modbus工控协议的一些基本概念，并根据工控协议的内容，获取当前温度的信息，并在温度过高时，隐藏温度过高的现象。这里选手要了解modbus协议的基本格式，确定协议功能码的位置和当前温度对应寄存器的地址参数，并在功能码为读寄存器，寄存器起始地址为当前温度对应寄存器地址时，检查温度值，并在越界时篡改。
在任务2-3中，我们还增加了一个隐藏要求。温度高于43度时，我们要求选手修改后的温度具备一定的波动性，否则将因这一欺骗容易引起怀疑而被扣2分。我们的示范答案是取温度值%2后的余数加上41度作为欺骗温度。访问控制模拟板块
访问控制模拟板块中，我们用前两个任务对应任务2-1的威胁，用第三个任务来应对操作员对恶意逻辑的处理，以及管理员对操作员恶意操作的处理行为。任务3-1是通过严格实现鉴别机制来防止越权访问，简单来说，就是让工程师、操作员和监视员只能在自己的设备上登录。只要以切面方式在用户登录过程中添加一个裁决机制，该机制根据用户名查询用户身份，并根据用户身份对比设备名称，以确定用户身份与设备是否一致即可。
任务3-2则是为用户提供更多便利的思路，工程师、操作员和监视员可以在其它角色的设备上登录并操作，只是不能执行其无权执行的操作。这一访控机制不能接入到用户登录过程，而应接入到命令执行流程中。在管理中心位置，则应接入到代码上传流程和命令执行流程中。逻辑本身则比较简单，根据用户名检查身份，并根据身份比对操作，判断是否合规即可。
任务3-3的两问都需要两个逻辑的组合来实现，逻辑1是判断操作员/管理员是否启动了操作行为，如启动则设置状态为访控状态，否则为非访控状态；逻辑2则是模块在访控状态时，执行命令拦截，否则放行。这里只要为系统上下文设置一个状态参数，并对应两种逻辑的输入信息，为系统编写两个判断逻辑，再将其接入到合适的业务流程中位置即可。
密码应用板块
密码应用板块只有两个子任务，但这两个子任务的复杂程度和技术难度和前面的任务相比，还是有一定的提升。任务4-1是对应任务2-2的恶意逻辑替换攻击行为，通过提供签名机制来防止攻击者篡改逻辑。在签名之前，需要进行密钥载入的过程。而模块的位置不同时，其密钥载入和签名/验证的逻辑也不一样。因此，这一任务的代码量是所有任务中最多的，但其逻辑并不复杂，参考系统中sm2签名、验证的相关代码，即可完成这里的签名与验证代码。
任务4-2对应任务2-3的恶意篡改攻击行为，通过祖冲之密码算法对modbus协议返回值的数值部分进行加密。这里我们针对序列密码算法加密方式的特点，设置了三个考察点：
1.正确使用祖冲之序列密码算法进行加密。
2.同样数值每次加密结果应充分随机。
3.加解密机制应能对应丢包现象。
要满足后两个要求，不但需要熟悉序列密码算法的原理，还需要深入分析题目中modbus协议的执行方式。序列密码算法可以适应modbus协议中数据项长度不定的特点，但是一但出现丢包现象，发送方和接收方之间的序列密码就容易出现失步，从而导致双方无法正确加解密数据。因此，需要在发送方和接收方之间找到一个合适的同步机制。我们知道modbus协议中数据报大小不会超过255字节，而在本场景的modbus协议中，modbus协议开头的trans_id是一个从1开始持续递增的值。因此，我们就可以利用trans_id来实现序列密码的同步，具体为：每一次发送时，序列密码输出255字节的密钥流用于异或加密，接收时，获取modbus协议的trans_id，记录trans_id并与上一次记录值对比，如新的trans_id为旧trans_id加一，则无丢包，序列密码输出255字节密钥流用于解密；否则，应是出现丢包现象，根据新旧trans_id的插值，序列密码可以多输出适当数目的255字节密钥流以恢复发送方和接收方的密钥同步，这样即可同时满足第二、第三个考察点。总之，我们在本次题目设计上，给出的都是基本的系统安全知识类型题目，部分题目结合了modbus工控协议的特点。我们认为，这类题目是同学们完全可以理解的，而解题所需的框架知识，同学们也完全可以从说明文档、题目示例中得到，因此，大部分战队应该是有能力解出相当数量的题目的。但如果战队不掌握C语言，那么可能能够解答的问题就仅限于新手任务和任务2-1了。3. 极限裁决
在本次Build环节任务中，得益于前期的课设和题目设计基础，出题过程并没有给我们带来太多困难，主要的工作量和技术难点来自于裁决机制的开发过程。在今年线上初赛的时候，我们已经开发了一个裁决机制原型，其原理如图3所示：图3 线上初赛可信赛题裁决机制原理
但线上初赛时，通用评分机制部分只提供了简单的分数累加和事件计数功能，自动运行、事件处理等机制也没有经过充分验证，实际上是一种“赶鸭子上架”的状况。而当我们完成为选手准备的赛题环境docker，并测试了正确答案后，时间已经到了7月10日。我们当时做的最后准备是由研究院的同学们人工完成答案的检查工作，但是如果能够提供自动裁决机制，选手体验将会好很多。因此，我们决定稍微拉长一些时间，先提供新手任务的自动裁决方法，在选手解题的同时，我们同步优化好剩余的裁决机制开发工作。在7月11日时，我们在虚拟机中完成了任务1-1的裁决机制，并提交给泽楷进行验证，同时，我开始采用类似的机制来实现任务1-2、1-3和2-1的裁决机制。在验证过程中，永信至诚的技术人员发现了不少问题，有些问题是计分机制中的小bug，很容易就解决了；但还时常出现莫名奇妙卡在某个评分阶段的问题，这些问题仅在线上裁决环境中才会出现，在我们自己的虚拟机开发环境中则不会出现。此时，裁决机制自身的实现难度、系统不稳定的问题，已经裁决机制中程序并发可能带来的隐患摆在面前，我对完成裁决机制的信心已经有些不足了。此时，我突然想到，我们的可信基础软件架构自身的日志机制其实可以用来分析问题，更进一步，我们对选手答案的裁决也可以通过读取日志机制来实现，这样裁决机制可以在题目环境运行后进行，不需要同步进行，可以大幅提升系统稳定性。因此，我和泽楷联系，请他提供相关的日志信息，同时我编写了日志读取的函数，准备从任务2-2开始，基于日志读取来实现赛题的裁决机制。而前四道题目因为裁决机制已实现，就不再修改。通过日志信息的阅读，我们迅速找到了系统卡住的原因。大概是因为docker环境的特点，使得系统中资源释放、文件复制等操作的响应情况与虚拟机中不同。我们通过调整执行顺序、恢复环境、增加时长等方式，解决了任务1系列中卡的问题，同时，泽楷对每个任务单独测试，也避免了不同裁决机制互相干扰的问题，这样，终于在12日下午五点时，新手任务系列的验证机制测通并成功上线了。有了新手验证机制的基础，后面的攻击裁决机制、访问控制裁决机制和密码裁决机制就都比较顺利了。我们为每个任务设计了包含完整的场景还原和预处理过程执行的脚本，并且为裁决的事件处理机制增加了事件序列处理、倒扣分等机制，还解决了原始模拟环境中的一个bug，最终分别于13日和14日实现了访问控制任务和密码任务的裁决机制，到15日上午，所有的裁决机制都经过了测试并陆续上线，并成功地实现了对选手提交答案的自动裁决。这次的裁决机制虽然实现的很仓促，但它是一个完全创新的机制。不同于传统CTF的夺旗模式，它是通过分析日志，判断背景应用和系统安全机制的执行情况是否符合预期来进行判决打分的。这使其具备了高度的灵活性和可扩展性。以任务4-2为例，我们进行裁决时，并没有检查安全机制，而是直接在操作员站检查解密前的温度和解密后的温度，判断其是否具备题目设定的加解密要求。而本次我们确定和实现了通过读日志实现静态裁决的方法，而前四个子任务提供的动态裁决机制，则有扩展成互动执行过程的潜力。因此我们认为，本次Build环节赛题的裁决机制建设，我们达到了预期的目标。4. 遗憾与展望
本次比赛因为时间仓促，我们的工作还有不少不足，在赛题支持过程中还是留下了不少遗憾。包括文件说明不够清晰，不同任务间切换时状态还原处理的不够好，考察点计分不够准确等等。总结相关经验后，我们在下一次出题活动中能够避免这次的绝大部分问题。经过这次Build环节后，我们也明确了本类题型建设下一阶段的主要工作。首先，是将这一题型移植到有完整安全可信环境的平台上。我们对该题型的模拟实现不依赖于其它软件，因此整个赛题环境既可以在docker中运行，也可以移植到pc机或虚拟机上，而在pc机和虚拟机上运行时，可以引入真实的攻击手段，也可以在操作系统中部署安全可信机制，使用真正的安全可信机制来为系统提供保护，这样可以为选手提供真实的软件安全环境。解题、验证过程也可以通过软件安全环境提供的可信机制，来实现远程解题与验证支持。其次，我们可以搜集更多的应用场景，依托这些场景分析应用的安全需求、所面临的威胁以及系统的脆弱性，并依托这些场景，建设覆盖各类应用环境的实训/赛题用例。未来甚至可以为不同行业建立安全相关的数据库，基于数据库来构造针对性的实训环境，通过数字孪生等技术提供轻量级的模拟靶场，以为网络安全从业人员提供体系化安全、安全防御、安全协作等方面的训练比赛环境。最后，我们在题目机制设计和改造上，将增强赛题的标准化设计，并重点突破赛题的可视化配置问题。从本次Build环节和决赛解题状况来看，不少选手未能适应赛题特殊的配置方式，并且当前的配置方式也很容易在写配置文件时出现不易察觉的错误。实际上，赛题的配置方式可以简单地以从信息流和监控流角度理解，而安全机制的添加、监控流程的设计等工作实际上是可以通过可视化的划线、模块拖曳和选择等方式简单实现，这样，实训/赛题环境上手将非常容易，排错工作也可以大幅简化，而可视化的配置过程对选手们理解基于信息流的安全机制和基于监控流的可信机制也会有很大帮助。本次Build环节赛题设计是我们在可信3.0设计思想下，基于工控环境安全可信的研究工作，做的一个以访问控制、密码保护等防御机制为核心的综合实训赛题的尝试。赛题的设计与裁决机制开发基本达到了我们的预期，为安全可信的实训探索了一条新的途径。后续我们将以开放的方式建设安全可信训练环境，希望能够与网络安全领域的教师、学生、科研人员一起，打造一个真正来自于实践需求，攻防兼备的训练环境。
还没有评论，来说两句吧...