网络安全漏洞分析，从零基础到精通，收藏这篇就够了！_cwe id漏洞分类

企业开发 2025-04-08 06:47:11 阅读次数: 0

漏洞分析葵花宝典

网络安全开源软件漏洞深度剖析与实战复现

各位安全界的大侠们，是不是经常遇到这种情况：一堆CVE漏洞摆在你面前，描述信息惜字如金，想找个现成的PoC（Proof of Concept）或者Exp（Exploit）练练手，结果发现比登天还难？别怀疑人生，这很正常！那些没公开PoC/Exp的Nday漏洞，就像深藏不露的高手，往往因为过于低调、修复太快或者利用条件太苛刻而被忽略。但！是！它们潜在的风险可一点都不小！今天，就给大家带来一份“武功秘籍”，系统化拆解无PoC/Exp漏洞的分析方法，尤其针对开源软件，从漏洞挖掘到补丁逆向，再到PoC构造和修复方案设计，手把手教你练成绝世神功！

漏洞情报搜集：当一次“朝阳群众”，盯紧每一个线索

漏洞分析的第一步，就是像“朝阳群众”一样，对漏洞的基本信息进行全方位、无死角的情报搜集。你可以手动收集，也可以用自动化工具辅助，总之，目标只有一个：把漏洞的底裤都扒下来！

信息来源主要有以下四大渠道：

1. 官方渠道：官方出品，必属精品！

· 软件官网的“安全公告”页面：这里通常会记录CVE编号、影响版本和修复Commit等关键信息，是你的首选情报站。

· 订阅官方邮件列表或RSS：第一时间获取漏洞动态，快人一步！

2. 代码托管平台：开源的精髓，都在这里！

针对开源项目的CVE漏洞提交，通常会通过Issue通知维护者。而维护者也会在版本发布或PR中披露漏洞修复情况。通过commit的具体内容（也就是漏洞补丁），你可以逆向分析漏洞的原理和修复方式，进而推导出漏洞成因，为编写PoC打下基础。当然，也有热心网友会分享已经分析过的CVE漏洞的PoC或Exp，但要注意，部分PoC可能暗藏恶意后门，使用需谨慎！

· GitHub：全球最大的代码“相亲”平台，也是主流的开源托管平台。

· GitLab/Gitee：部分企业级开源项目可能会选择其他平台“安家”。

3. 漏洞数据库扩展：站在巨人的肩膀上，看得更远！

基于官方漏洞信息，漏洞数据库会进行进一步的补充，例如漏洞描述、漏洞评分、第三方链接、CWE-ID等等。从漏洞描述和CWE-ID，你可以了解漏洞的类型。部分描述甚至会透露漏洞产生的文件、函数或原因（当然，这取决于漏洞提交者的心情）。第三方链接可能会指向利用链接或修复通告。

· NVD：重点关注“漏洞描述”中的代码片段和“CWE-ID”分类（例如CWE-125越界读取）。

· Exploit-DB/Packet Storm：在这里，你可以淘到未公开的利用代码或技术讨论。

· CVE Details：通过分析漏洞的CVSS评分及历史关联漏洞，推测攻击面。

4. 社区与暗网情报：八卦小道消息，有时也能挖到宝！

当然，你也可以直接通过Google搜索漏洞编号，可能会有安全人员通过博客或官网补充漏洞信息，或者进行更深入的漏洞分析。

· Reddit的netsec频道：安全人员经常在这里发布漏洞预警和分析分享。

· Twitter：安全研究人员喜欢在这里分享初步分析或者进行0-day漏洞预警。

· Telegram/Discord漏洞频道：部分“黑产”论坛会泄露未公开的Exp片段。

除了以上渠道，还可以结合CVE-Search等开源工具，提升你的漏洞情报和信息跟踪效率。

补丁分析：像福尔摩斯一样，从蛛丝马迹中寻找真相

补丁分析的本质，就是代码安全审计和逻辑推理。以CVE-2021-35515为例，补丁分析可以分为以下三个步骤：

1. 代码比对：找出“不一样”的地方

使用git diff提取补丁内容，重点关注新增的条件判断（例如空指针检查、循环终止条件）。

2. 漏洞根因定位：抽丝剥茧，找到真凶

根据上图的代码差异，我们发现补丁是对数组的成员进行了校验，校验语句是l.contains(coders[current])。漏洞信息显示，这是一个无限循环漏洞。由此可以推测，漏洞成因可能是该while循环会无限制地迭代，也就是current未校验导致无限循环。

想要该循环无限循环，就需要让current的值始终大于或等于0，且current不能一直增长，所以current最好能恒等于0。

根据代码中current的赋值代码分析，我们发现只要让bindPairs[pair].inIndex恒等于0即可。

final int pair = findBindPairForOutStream(current);

3. 漏洞逻辑验证：实践是检验真理的唯一标准

如果后续要编写PoC进行漏洞验证，那么我们需要构造能够让其无限循环的数据。但前提是需要对上述的漏洞分析和推导结果进行验证。你可以实际部署后通过观察和理解程序的功能结构执行，也可以通过常用的请求变更观察响应结果，还可以通过CodeQL做详细的漏洞代码跟踪。如果是二进制文件，则可以使用Ghidra/IDA Pro进行逆向验证，或者使用这些工具对二进制的补丁进行补丁分析。

PoC编写：纸上谈兵终觉浅，绝知此事要躬行

为了验证漏洞的存在，我们需要编写PoC（PoC的核心是模拟攻击，验证漏洞的可利用性，但并非攻防中实际利用的方式）。通过PoC，我们可以验证漏洞的效果是否符合预期。不同的漏洞利用效果差异很大，但通常会基于漏洞原理，利用最简单的效果来证明漏洞的存在。例如，对于Java反序列化、XXE或任意命令执行漏洞，我们可以通过touch命令创建文件，或者通过calc命令弹出计算器，又或者访问dnslog生成的网址来判断命令执行是否成功（例如CVE-2021-44228）。但这些现象只是漏洞存在的证明，并非漏洞本身！ 笔者就曾经见过，有人用弹框证明XSS漏洞的存在，然后开发人员直接禁用alert方法来“修复”漏洞，简直是掩耳盗铃！

部分漏洞的产生原因只是在于一个函数的使用或不恰当使用。这种情况下，将构造好的数据传入漏洞函数，便可以验证效果。步骤大致如下：

编写调用漏洞函数的Java代码；
执行该Java文件，并传入构造好的恶意数据；
查看漏洞利用效果。

对于DoS等拒绝服务漏洞，可以通过调用函数查看是否Java出现异常来判断。下图是一个内存耗尽漏洞的报错示例。

对于无限循环漏洞，可以通过源代码调试进行分析和验证。例如，下图中程序使用一个参数Count记录代码的执行次数，执行次数过大时程序出现了异常。也可以通过软件调试进行逻辑分析，观察循环过程中的变量情况，推理是否存在无限循环漏洞。

漏洞修复：亡羊补牢，犹未晚矣

通常，一个漏洞得到及时反馈和厂商响应后，会有针对漏洞的产品更新或版本更新。对于受影响的企业而言，通用的修复方案是将漏洞版本升级至不存在漏洞的版本。修复版本一般可以从NVD或组件官网上得知。

但很多漏洞并没有这样的待遇（主要取决于漏洞发现者的心情），或者漏洞虽然被通报，但产品更新和升级需要很长时间，因此会产生漏洞爆出后的漏洞利用窗口期（平均是1.5年左右）。这时，可以利用已有的安全设备或产品进行应急防护，例如防火墙、WAF或RASP等。例如，对于需要通过Web服务利用的漏洞，可以通过流量检测进行检测，对传输的数据包进行过滤。如果是反序列化漏洞的利用，其流量数据中会存在一些利用链使用到的类的字符，使用WAF、IPS对其进行过滤可以防止漏洞的利用。当然，这些只是缓兵之计，最重要的还是要从源码层面进行彻底的修复。

当官方没有对已有的漏洞进行修复，也就是不存在修复版本的时候，就需要手动对代码进行打补丁。这里分为两种情况：