网络安全

踩坑实录：在 VMware Ubuntu 22.04 Server 上部署 Minikube 的血泪史 背景与环境 最近想重新学习一下 Kubernetes，为了图方便，决定在本地 VMware 虚拟机里装一个 Minikube。原本以为是一路回车的事，没想到硬是折腾了一下午，经历了各种网络、内存、镜像和 CNI 的折磨。 环境信息： 虚拟机：VMware Workstation，Ubuntu 22.04 Server（无图形界面） 虚拟机 IP：192.168.65.194（NAT 模式） 宿主机代理：192.168.65.1:7890（HTTP/HTTPS 代理） 虚拟机配置：中途扩容至 4 核 8G，60G 硬盘 目标：使用 Docker 驱动启动 Minikube，并运行 Dashboard 及测试应用 本文记录了我这一路遇到的各种报错和最终的成功配置，希望能帮到遇到类似问题的朋友。 第一坑：宿主机代理与 GitHub 连接被拒 一开始按照官方文档下载 Minikube 二进制文件： x12@chenjx12:~$ curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:21 --:--:-- 0 curl: (7) Failed to connect to github.com port 443 after 21059 ms: Connection refused [sudo] password for x12: install: cannot stat 'minikube-linux-amd64': No such file or directory 原因：虚拟机是 NAT 网络，无法直接访问外网，需要走宿主机的代理。但宿主机默认只监听 127.0.0.1。 ...

Nginx cve-2013-2028漏洞环境搭建与复现 声明：测试环境为 Ubuntu 16.04 + Nginx 1.4.0，仅供安全研究使用 环境搭建 由于 cve-2013-2028 漏洞影响到的Nginx版本 1.3.9 和 1.4.0 已经在官方网站中被移除 所以我们需要在其他地方获取有漏洞的版本 方法一：Nginx官方GitHub仓库 这是目前最可靠的方法，Nginx 官方 GitHub 保留了所有历史版本 # 克隆 1.4.0 分支 git clone --single-branch --branch release-1.4.0 https://github.com/nginx/nginx.git nginx-1.4.0 cd nginx-1.4.0 # 验证分支 git log --oneline -3 方法二：从 GitHub 安全研究项目获取 有安全研究者专门整理了包含漏洞的 Nginx 版本 # 下载包含预编译二进制和源码的项目 git clone https://github.com/m4drat/CVE-2013-2028-Exploit.git cd CVE-2013-2028-Exploit # 项目中包含 Dockerfile 和 docker-compose，可以直接构建环境 准备环境 因为笔者自己是学习二进制安全方向的，所以将以源码分析为主要目标 这里我们结合前面两种方法的优点 用docker起 nginx1.4.0 的原生 Ubuntu 16.04 环境，但是下载官方的源码进行分析，这样既避免了编译器系统环境差异，也能做到二进制分析 ...

我的AFL++fuzzing入门之路（4） 00 引言：跨越鸿沟 回顾前三天： Day 1：在"教科书式test.c"上跑通AFL++，理解状态界面 Day 2：深入插桩原理，发现"平墙式memcmp让AFL失明"的致命问题 Day 3：用ASAN将"隐形漏洞"转化为"显性崩溃" 提出问题： 真实项目不是afl-cc test.c这么简单。面对libpng这类真实解析器： 如何编译带依赖的开源项目？ 如何应对无处不在的"平墙式"魔数检查（memcmp(header, "\x89PNG", 4)）？ 如何让AFL++不再"瞎猜"？ 本章目标： 以libpng 1.6.54为演示目标，掌握实战前的三大核心准备： 编译真实项目（带ASAN插桩） 构建高质量种子语料库 用字典破解"平墙式"困境 01 实战目标编译：以libpng为例 1st. 为什么选libpng 理由 说明 经典攻击面 图片解析器天生处理不可信输入（用户上传） 代码规模适中 约3万行，比内核简单，比test.c真实 历史漏洞丰富 CVE-2018-14550、CVE-2019-7317等，有参考案例 格式相对简单 PNG结构清晰：文件头+Chunk（IHDR/IDAT/IEND） 官方支持完善 Google OSS-Fuzz已集成，有现成字典参考 选什么版本？看了一下，最后决定选择1.6.54，存在已知CVE，CVE-2026-25646（png_set_quantize()堆溢出），1.6.55修复 CVE-2026-25646速览：png_set_quantize()函数在处理调色板（PLTE Chunk）时存在堆缓冲区溢出，存在30年之久。这正是ASAN的检测目标，也是我们Fuzzing的"猎物"。 2nd. 下载与依赖 # 下载源码 wget https://download.sourceforge.net/libpng/libpng-1.6.54.tar.gz tar -xzf libpng-1.6.54.tar.gz && cd libpng-1.6.54 # 验证版本 head -5 README README for libpng version 1.6.54 ================================ # 安装依赖 sudo apt update sudo apt install zlib1g-dev # libpng依赖zlib 3rd. 用afl-cc + ASAN编译 命令如下： ...

我的AFL++fuzzing入门之路（3） 00 前言回顾 在笔者的上一篇，也是 AFL++ Fuzzing 系列的第二篇中，我们从“汇编指令”深入到“策略机制”，完成了对 AFL++ 核心能力的解构： 插桩底层：通过 IDA 反编译，直观观察了 LLVM SanitizerCoverage 的内联插桩实现，解析了 __afl_area_ptr 与 guard 变量如何协作，以及 NeverZero 机制如何防止计数溢出，从指令级掌握了覆盖率追踪的底层逻辑； 反馈机制：通过“阶梯式”与“平墙式”代码的对比实验，量化了覆盖率反馈对 fuzzing 效率的决定性影响，验证了“覆盖率引导是 AFL 灵魂”这一核心思想，揭示了为何 memcmp 类检查是 fuzzing 的噩梦； 崩溃分析：借助 GDB 与 xxd 工具，我们完成了“触发崩溃→定位根因→验证输入”的完整闭环，学会了如何区分 ud2 指令触发的逻辑崩溃与内存破坏导致的异常。 虽然我们已经掌握了发现和分析崩溃的方法，但在真实漏洞挖掘中，存在一个更棘手的问题：并非所有的内存错误都会立即崩溃。大量的堆溢出、Use-After-Free 往往会“沉默”地破坏内存，直到程序运行很久后才随机崩溃，这让 AFL++ 难以捕获到有效的反馈信号。 为了解决“漏洞隐形”的问题，本文将引入 Sanitizer（消毒器） 机制。我们将重点探索 ASAN（地址消毒器）如何通过影子内存将“隐形漏洞”转化为“显性崩溃”，并结合实战演示其在 AFL++ 中的集成方法与性能权衡，进一步提升漏洞挖掘的深度与广度。 01 ASAN 深度解析（核心重点） 1st. 为什么需要ASAN 要回答这个问题，我们首先得知道 ASAN 是什么： ASAN 全名 AddressSanitizer（整合了 LeakSanitizer (LSAN)），是一个由 Google 开发的内存错误检测工具，能够精准捕捉堆溢出、栈溢出、Use-After-Free（UAF）等常见的内存安全问题。 那么，为什么我们的 Fuzzing 特别需要它？ 1. 很多内存错误是“沉默”的 在上一篇文章中，我们遇到的崩溃都是“立即触发”的（如 __builtin_trap 或空指针解引用）。但在真实世界中，很多严重的漏洞并不会立即让程序崩溃： ...

我的AFL++fuzzing入门之路（2） 00 前篇回顾 在笔者的上一篇，也是 AFL++ Fuzzing 系列的第一篇中，我们完成了以下工作： 理论基础：建立了对 AFL++ 的基础认知，包括其作为覆盖率引导模糊测试框架的定位、核心漏洞挖掘能力，以及编译时插桩的工作原理； 环境搭建：在 Ubuntu 24.04 虚拟机中完成了 AFL++ 的源码编译安装，解决了 Ubuntu Apport 与 core_pattern 的系统冲突； 实战入门：构造并测试了首个漏洞程序，在 2.7 秒内成功触发崩溃，同时掌握了 AFL++ 状态界面 8 区域的核心指标解读方法。 基于昨日的实践基础，本文将推进三个层面的深入探索： 插桩汇编表现：通过 IDA 反编译观察 AFL++ 使用 LLVM 的 SanitizerCoverage 在二进制层面插入的 inline 代码，理解 AFL++ 如何记录边覆盖率，从汇编指令级掌握覆盖率追踪的底层机制； 难度进阶：通过修改触发条件（从 “AFL++” 阶梯式扩展至平墙式），测试 AFL++ 的变异深度与效率边界，观察 havoc 策略在长模式匹配场景下的表现； 崩溃分析：引入 GDB 调试器对发现的崩溃进行根因定位，掌握调用栈回溯、寄存器状态检查等漏洞分析基础技能，完成从"发现崩溃"到"理解崩溃"的闭环。 01 汇编插桩 为了简单，咱直接素材复用，上一篇中的test.c使用afl-cc编译的，现在再用gcc编译一遍，然后放到不同的工具下比对 ❯ cat test.c #include <stdio.h> #include <string.h> int main(int argc, char *argv[]) { char buf[100]; FILE *f = fopen(argv[1], "r"); if (!f) return 1; fread(buf, 1, sizeof(buf), f); fclose(f); // 漏洞触发点：输入 "AFL++" 会崩溃 if (buf[0] == 'A' && buf[1] == 'F' && buf[2] == 'L') if (buf[3] == '+') if (buf[4] == '+') __builtin_trap(); // 触发崩溃（SIGTRAP） return 0; } afl-cc -o test test.c gcc -o test-gcc test.c 这里就得到了两个不同的可执行程序版本：有afl插桩的test和gcc编译的无插桩的test-gcc ...

我的AFL++fuzzing入门之路（1） 00 前言 最近学校上的事渐渐变少，遂想着找份实习充实一下自己，学习更多先进的前沿技术。 但是真正开始写简历时便越发惶恐，觉得能写的实在太少了， 思来想去再学点东西来扩充一下自己的技术栈，翻着网页发现收藏夹里的fuzz测试介绍。 而fuzz模糊测试是我在去年就见到过的，但是当时也只是匆匆一瞥，知道fuzz是一种自动输入寻找崩溃点的技术。 现在有空了，多篇介绍AFL的文章看下来发现这个功能很强大，而且和二进制方向有一定的互补， 所以就开始尝试学习了。 由于笔者也刚在这个领域入门，所以文章可能会有写不够准确甚至谬误，欢迎各位大佬斧正。 01 AFL++Fuzzing介绍 AFL++（American Fuzzy Lop Plus Plus）是目前最流行和最先进的模糊测试（Fuzzing）框架之一，是经典AFL（American Fuzzy Lop）的社区维护增强版。 它是由Google安全工程师Michał Zalewski开发的一款开源fuzzing测试工具。 其可以高效地对二进制程序进行fuzzing，挖掘可能存在的内存安全漏洞，如_栈溢出、堆溢出、UAF、double free_等。 由于需要在相关代码处插桩，因此AFL主要用于对开源软件进行测试。 配合QEMU等工具，也可对闭源二进制代码进行fuzzing，但执行效率会受到影响。 工作原理：通过对源码进行重新编译时进行插桩（简称编译时插桩）的方式利用自动产生测试用例来探索二进制程序内部新的执行路径。AFL也支持直接对没有源码的二进制程序进行测试，但需要QEMU的支持。 02 环境搭建 这里有两种选择，可以使用docker容器，也可以直接安装到本机 先附上docker容器搭建的方法： docker pull aflplusplus/aflplusplus:latest docker run -ti -v /path/to/your/code:/src aflplusplus/aflplusplus 为了能够详细的学习（？，笔者决定直接安装到Ubuntu24.04虚拟机里。 先更新系统和软件包： sudo apt update && sudo apt upgrade -y 安装依赖（没错，就是这么多），有LLVM/Clang、Python、Rust等： sudo apt install -y build-essential python3-dev automake cmake git \ flex bison libglib2.0-dev libpixman-1-dev python3-setuptools \ cargo libgtk-3-dev lld llvm llvm-dev clang \ gcc-$(gcc --version|head -n1|sed 's/\..*//'|sed 's/.* //')-plugin-dev \ libstdc++-$(gcc --version|head -n1|sed 's/\..*//'|sed 's/.* //')-dev \ ninja-build cpio libcapstone-dev wget curl python3-pip 找个好地方，克隆源码 ...

源码防护-fortify_source 由于第一篇FORTIFY刚接触也没咋碰到，了解的也不多 现在回过头来发现当时写的糊里糊涂， 所以本篇继续深入FORTIFY防护 Fortify Source 是什么 本质：GCC 的编译时/运行时缓冲区溢出检测机制，属于源码级保护（不是二进制层面的 NX/Canary 那种） 保护对象：标准库中的高风险函数（strcpy、memcpy、sprintf、gets 等），一般主要是和字符串相关的函数。 FORTIFY_SOURCE 是 GCC/glibc 提供的一种编译时 + 运行时联合防护机制，通过将危险的 C 库函数替换为带边界检查的安全版本（__*_chk 后缀函数），在编译期和运行期检测缓冲区溢出。 核心思想： 编译器在编译时尽可能推断出缓冲区大小，如果能在编译期判定溢出就直接报错；如果编译期无法确定，就插入运行时检查代码，在溢出发生的瞬间终止程序。 Fortify Source干了什么 要想知道Fortify Source干了什么，那就要先看看如果没有Fortify Source会发生什么 char buf[32]; strcpy(buf, user_input); //① memcpy(buf, src, len); //② sprintf(buf, "%s", str); //③ read(fd, buf, 1024); //④ 先来看这段源码，毫无疑问的，①②③④这四条语句都有安全漏洞： ①完全没有长度检查，溢出 ②len作为变量可能会>32 ③str也可能长度>32 ④1024>32毫无疑问的溢出 而编译器对这些代码没有任何反应，也就是说，对生成的代码不会做任何的边界检查 Fortify Source的工作机制 工作流程： 源代码：strcpy(buf, src) │ ▼ ┌───────────────────────────┐ │ 预处理阶段（宏替换） │ │ #include <string.h> │ │ FORTIFY 宏将 strcpy 替换为 │ │ __builtin___strcpy_chk() │ └───────────┬───────────────┘ │ ▼ ┌───────────────────────────────────┐ │ 编译阶段（GCC 内置函数处理） │ │ │ │ GCC 尝试用 __builtin_object_size() │ │ 推断 buf 的大小 │ │ │ ├──── 能确定大小 ────────────────────┤ │ │ │ │ ├─ 编译期可判定溢出 │ │ │ → 编译错误/警告 │ │ │ │ │ ├─ 编译期可判定安全 │ │ │ → 优化为普通 strcpy（零开销） │ │ │ │ │ └─ 编译期无法确定 │ │ → 插入运行时检查 │ │ → 调用 __strcpy_chk() │ │ │ ├──── 不能确定大小 ──────────────────┤ │ → 退化为普通 strcpy（无法保护） │ └──────────────────────────────────┘ 而工作流程中的三个关键组件： ...

FORTIFY fortify是轻微的检查，用于检查是否存在缓冲区溢出的错误。适用于程序采用大量的字符串或者内存操作函数，如: memcpy(): 描述：void *memcpy(void str1, const void str2, size_t n) 从存储区str2复制n个字符到存储区str1 参数：str1 – 指向用于存储复制内容的目标数组，类型强制转换为 void 指针 str2 – 指向要复制的数据源，类型强制转换为 void 指针 n – 要被复制的字节数 返回值：该函数返回一个指向目标存储区 str1 的指针 memset(): 描述：void *memset(void *str, int c, size_t n) 复制字符 c（一个无符号字符）到参数 str 所指向的字符串的前 n 个字符 参数：str – 指向要填充的内存块 c – 要被设置的值。该值以 int 形式传递，但是函数在填充内存块时是使用该值的无符号字符形式 n – 要被设置为该值的字节数 返回值：该值返回一个指向存储区 str 的指针 strcpy(): 描述：char *strcpy(char *dest, const char *src) 把 src 所指向的字符串复制到 dest，容易出现溢出 参数：dest – 指向用于存储复制内容的目标数组 src – 要复制的字符串 返回值：该函数返回一个指向最终的目标字符串 dest 的指针 ...

RELRO RELRO（RELocation Read Only） 先从名字上看，翻译一下：重定位只读 只读很好理解，重定位又是什么呢 重定位（RELocation） 在Linux系统安全领域数据可以写的存储区就会是攻击的目标，尤其是 存储函数指针的区域 。 所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处。 GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术: read only relocation。大概实现就是由linker指定binary的一块经过dynamic linker处理过 relocation之后的区域为 只读 . 设置符号重定向表格为只读或在程序启动时就解析并 绑定所有动态符号 ，从而减少对GOT（Global Offset Table）攻击。RELRO为” Partial RELRO”，说明我们对GOT表具有写权限。 那么GOT表又是干什么的呢？ GOT表，PLT表 这涉及到 动态链接 的知识了： 动态链接，是 提高程序空间效率的重要方法 。通过动态链接， 我们可以调用外部共享库中的函数，而不需要将其编译在 可执行文件 中。在运行时动态链接的过程中，PLT表和GOT表起到了至关重要的作用。 GOT: Global Offset Table， 全局偏移表，包含所有需要动态链接的外部函数的地址（在第一次执行后） PLT: Procedure Link Table， 过程链接表 ，包含调用外部函数的 跳转指令 （跳转到GOT表中），以及 初始化外部调用指令 （用于链接器动态绑定dl_runtime_resolve） .plt 段的工作流程： ...

PIE/ASLR 区别 ASLR 是什么？ ASLR 是 Linux操作系统 的功能选项，作用于程序（ELF）装入内存运行时。是一种 针对缓冲区溢出的安全保护技术，通过对加载地址的随机化 ，防止攻击者直接定位攻击代码位置，到达 阻止溢出攻击 的一种技术。 开启、关闭ASLR 查看当前系统ASLR的打开情况： sudo cat /proc/sys/kernel/randomize_va_space ASLR 有三个安全等级： 0： ASLR 关闭 1：随机化栈基地址（stack）、共享库（.so\libraries）、mmap 基地址 2：在1基础上，增加随机化堆基地址（chunk） PIE 是什么？ PIE 是 gcc 编译器 的功能选项，作用于程序（ELF）编译过程中。是一个针对代码段（ .text ）、数据段（ .data ）、未初始化全局变量段（ .bss ）等固定地址的一个防护技术，如果程序开启了PIE保护的话，在_每次加载程序时都变换加载地址_，从而不能通过 ROPgadget 等一些工具来帮助解题。 开启 PIE： 在使用 gcc 编译时加入参数-fPIE。 gcc -o test test.c // 默认情况下，不开启PIE gcc -fpie -pie -o test test.c // 开启PIE，此时强度为1 gcc -fPIE -pie -o test test.c // 开启PIE，此时为最高强度2 gcc -fpic -o test test.c // 开启PIC，此时强度为1，不会开启PIE gcc -fPIC -o test test.c // 开启PIC，此时为最高强度2，不会开启PIE -no-pie / -pie (关闭 / 开启) PIE 开启后会随机化代码段（ .text ）、初始化数据段（ .data ）、未初始化数据段（ .bss ）的加载地址。 ...